CS605

MID SEM BREAK ASSGNMENT Server Side Programming-CS605

Alok Singh 20098019 IT-1

CS605

1 The IO::Socket Module

The IO::Socket module included in the core Perl distribution provides an objectoriented approach to socket programming. This module provides a convenient way to handle the large number of options you have to deal with, and it handles the laborious task of forming addresses. IO::Socket is built upon the Socket module provided in the standard library. It inherits from IO::Handle, which supports a class of filehandle objects for much of the IO library. The following IO::Socket functions are simply frontends for the corresponding built-in functions and use the same syntax: socket socketpair bind listen send recv peername (same as getpeername) sockname (same as getsockname) The accept function in IO::Socket is slightly different from the equivalent function, however, and is described later in the chapter. Client-Side Sockets IO::Socket greatly simplifies the implementation of a socket for client communications. The following example creates an Internet-domain socket (using the INET subclass) and attempts to connect to the specified server: use IO::Socket; $sock = new IO::Socket::INET (PeerAddr => 'www.ora.com', PeerPort => 80, Proto => 'tcp'); die "$!" unless $sock; IO::Socket::INET::new creates an object containing a socket filehandle and connects it to the host and port specified in PeerAddr and PeerPort .

CS605

The object $sock can then be written to and read from like other socket filehandles. Server-Side Sockets On the server side, IO::Socket provides a nice wrapper for creating server sockets. The wrapper encompasses the socket , bind , and listen procedures, while creating a new IO::Socket object. For example, we can create an Internet-domain socket with IO::Socket::INET : use IO::Socket; $sock = new IO::Socket::INET (LocalAddr => 'maude.ora.com', LocalPort => 8888, Proto => 'tcp', Listen => 5); die "$!" unless $sock; The parameters for the new socket object determine whether it is a server or a client socket. Because we're creating a server socket, LocalAddr and LocalPort provide the address and port to bind to the socket. The Listen parameter gives the queue size for the number of client requests that can wait for an accept at any one time. When the server receives a client request, it calls the accept method on the socket object. This creates a new socket object on which the rest of the communication can take place: $new_sock = $sock->accept(); IO::Socket Methods: The following methods are defined in IO::Socket and can be used on socket objects of either the INET or UNIX class:

accept timeout sockopt sockdomain socktype protocol

CS605

SRS:
A software requirements specification (SRS) a requirements specification for a software system is a complete description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains nonfunctional requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). Software requirements is a sub-field of software engineering that deals with the elicitation, analysis, specification, and validation of requirements for software. The software requirement specification document enlists all necessary requirements for project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with project team and the customer. A general organization of an SRS is as follows

Introduction o Purpose o Scope o Definitions o System overview o References Overall description o Product perspective o Product functions o User characteristics o Constraints, assumptions and dependencies Specific requirements o External interface requirements o Functional requirements o Performance requirements o Design constraints o Logical database requirement o Software System attributes o Other requirements

CS605

USE OF SRS:
Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs. Reduce the development effort. The preparation of the SRS forces the various concerned groups in the customers organization to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct. Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates. Provide a baseline for validation and verification. Organizations can develop their validation and Verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured. Facilitate transfer.The SRS makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers. Serve as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued production evaluation

CS605

Software Development Phases:

Software development is achieved through a collection activities that lead to the building of a software product. Software development is traditionally divided into various phases. For small projects, the phases are carried out in the order shown; for larger projects, the phases are interleaved or even applied repetitively with gradually increasing refinement.. The strict definition and organization of these phases is called a software process.

Requirements Analysis
Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements. Requirements analysis can itself be broken down in sub-activities. This phase is often the topic of processes itself, often refered to as the requirements process, or even requirements engineering process, the latter title being debatable. Requirements analysis methodologies have been created, one of the most popular being the use case driven methodology.

Specification
Specification is the task of precisely describing the problem description, often in a mathematically rigorous way, in most cases actually building a more or less complete model of the problem to be solved. A wide array of specification techniques exist, and many application areas rely on dedicated specification techniques. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed. Specifications are most important for external interfaces, that must remain stable. This is often refered to as software interface specifications. Note that internal software interfaces are generally established in the design phase of development, which makes this kind of specification a design artifact. However, some systems have external software interfaces with other existing systems. The specification of these interfaces then becomes something that is very important to specify in the early phases of development, and is thus really considered a specification artifact.

CS605

Design
Design refer to conceptually determining how the software is to function in a general way without being involved in low-level operational details. Usually this phase is divided into two sub-phases, such as architectural design, detailed design, or algorithmic design. Design can also be categorized into different focus such as graphical user interface (GUI) design, or database design, depending on the nature of the application. Design is anextremely important phase in the development of the software, as it permits the developers to think in relatively abstract terms about the solution. This is in contrast with the implementation phase, where the solution is approached from a very concrete and often short-sighted point of view. Approaching the problem from an abstract point of view permits to 'see the big picture', and develop abstract models of the solution that can be easily modified as details are grafted and the solution become more and more concrete. At a certain point, the designed solution will be concrete enough so that the implementation (i.e. coding) phase can start.

Implementation
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. A common fallacy in software development practice is that coding should be the main focus in software development. Such a misconception is a popular reason for low software quality or software project failure. Note that effective programmers have to deal with quality factors, and provide qualities such as code readability, maintainability, and often test the code as they are writing it.

Testing
Another common fallacy of software development is that tesing is mostly about executing the application and making sure that it does not crash before it is made operational. Testing is basically about verifying the quality of the product, and validate that it meets its requirements. In fact, "testing" is about the validation and verification of the various artifacts produced during the development of the software. Not only the code. For example, when requirements are established, one has to assess their quality in order to prevent that further phases be implementing a faulty or incomplete solution. The keyword "Testing" is most often refering to quality assurance of the code itself, but real software engineering will care about the quality of all artifacts produced, not only the code or the final application.

CS605

Documentation
An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement. Without documentation, software maintainers (who are in most cases the authors of the code they maintain) only have extremely low level design information, i.e. the code itself, to unserstand the software they have to change. For example, good software documentation presents the software in various levels of abstraction, permitting the reader to easily understand the functioning of the software and to assess the location and impact of the chages to be applied.

Maintenance
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more effort than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort. About 2/3 of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, or adapti it to a new environment, which in many ways can be considered new work. Similarly, about 2/3 of all civil engineering, architecture, and construction work is maintenance.

______________________________***________________________________