SOFTWARE ENGINEERING LAB MANUAL

DEPARTMENT OF CSE
L.B.S ENGINEERING COLLEGE, KASARAGOD

Prepared By: Neethu George

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. The term software engineering first appeared in the 1968 NATO Software Engineering Conference and was meant to provoke thought regarding the current "software crisis" at the time. Since then, it has continued as a profession and field of study dedicated to creating software that is of higher quality, more affordable, maintainable, and quicker to build. Since the field is still relatively young compared to its sister fields of engineering, there is still much debate around what software engineering actually is, and if it conforms to the classical definition of engineering. It has grown organically out of the limitations of viewing software as just computer programming. A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. What is a software life cycle model? A software life cycle model is either a descriptive or prescriptive characterization of how software is or should be developed. A descriptive model describes the history of how a particular software system was developed. Descriptive models may be used as the basis for understanding and improving software development process or for building empirically grounded prescriptive models. A prescriptive model prescribes how a new software system should be developed. Prescriptive models are used as guidelines or frameworks to organize and structure how software development activities should be performed, and in what order. Typically, it is easier and more common to articulate a prescriptive life cycle model for how software systems should be developed. This is possible since most such models are intuitive or well reasoned. This means that many idiosyncratic details that describe how a software system is built in practice can be ignored, generalized, or deferred for later consideration. This, of course, should raise concern for the relative validity and robustness of such life cycle models when developing different kinds of application systems, in different kinds of development settings, using different programming languages, with differentially skilled staff, etc. However, prescriptive models are also used to package the development tasks and techniques for using a given set of software engineering tools or environment during a development project. Descriptive life cycle models, on the other hand, characterize how particular software systems are actually developed in specific settings. As such, they are less common and more difficult to articulate for an obvious reason: one must observe or collect data throughout the life cycle of a software system, a period of elapsed time often measured in years. Also, descriptive models are specific to the systems observed and only generalizable through systematic comparative analysis. Therefore, this suggests that the prescriptive software life cycle models will dominate attention until a sufficient base of observational data is available to articulate empirically grounded descriptive life cycle models. These two characterizations suggest that there are a variety of purposes for articulating software life cycle models. These characterizations serve as a:

Guideline to organize, plan, staff, budget, schedule and manage software project work over organizational time, space, and computing environments. Prescriptive outline for what documents to produce for delivery to client. Basis for determining what software engineering tools and methodologies will be most appropriate to support different life cycle activities. Framework for analyzing or estimating patterns of resource allocation and consumption during the software life cycle. Basis for conducting empirical studies to determine what affects software productivity, cost, and overall quality.

What is a software process model? In contrast to software life cycle models, software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing. Software process networks can be viewed as representing multiple interconnected task chains. Task chains represent a non-linear sequence of actions that structure and transform available computational objects (resources) into intermediate or finished products. Non-linearity implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. Task actions in turn can be viewed as non-linear sequences of primitive actions which denote atomic units of computing work, such as a user's selection of a command or menu entry using a mouse or keyboard. Winograd and others have referred to these units of cooperative work between people and computers as "structured discourses of work" (Wino grad 1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998). Task chains can be employed to characterize either prescriptive or descriptive action sequences. Prescriptive task chains are idealized plans of what actions should be accomplished, and in what order. For example, a task chain for the activity of object-oriented software design might include the following task actions: Develop an informal narrative specification of the system. Identify the objects and their attributes. Identify the operations on the objects. Identify the interfaces between objects, attributes, or operations. Implement the operations. Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive action invocations in the course of incrementally progressing towards an object-oriented software design. Task chains join or split into other task chains resulting in an overall production network or web (Kling 1982). The production web represents the "organizational production system" that transforms raw computational, cognitive, and other organizational resources into assembled, integrated and usable software systems. The production lattice therefore structures how a software system is developed, used, and maintained. However, prescriptive task chains and actions cannot be formally guaranteed to anticipate all possible circumstances.

Planning The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

Implementation, testing and documenting Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal. Deployment and Maintenance Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control.

Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues. Software Requirements Specification (SRS) A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). Requirements Analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements can be functional and non-functional. Conceptually, requirements analysis includes three types of activity:

Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications. Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. In other words it helps the software engineers to identify the exact problem behind the development of the software and to find the exact requirements for developing the software or the system: - It helps us to understand, interpret, classify and organize the software requirements in order to assess the completeness, correctness, and consistency of the software.

UML Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group.UML includes a set of graphical notation techniques to create visual models of software-intensive systems. The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software intensive system under development. UML offers a standard way to visualize a system's architectural blueprints, including elements such as:

actors business processes (logical) components activities programming language statements database schemas, and reusable software components.

UML combines best techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies. UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is a de facto industry standard, and is evolving under the auspices of the Object Management Group (OMG). OMG initially called for information on object-oriented methodologies that might create a rigorous software modeling language. Many industry leaders have responded in earnest to help create the UML standard. UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG. UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 2.0 major revision. The important point to note here is that UML is a 'language' for specifying and not a method or procedure. The UML is used to define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process. UML defines the notation and semantics for the following domains: - The User Interaction or Use Case Model - describes the boundary and interaction between the system and users.

- The Interaction or Communication Model - describes how objects in the system will interact with each other to get work done. - The State or Dynamic Model - State charts describe the states or conditions that classes assume over time. Activity graphs describe the workflows the system will implement. - The Logical or Class Model - describes the classes and objects that will make up the system. - The Physical Component Model - describes the software (and sometimes hardware components) that make up the system. - The Physical Deployment Model - describes the physical architecture and the deployment of components on that hardware architecture. Class Diagrams Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure of a system. The purpose of a class diagram is to depict the classes within a model. In an object oriented application, classes have attributes (member variables), operations (member functions) and relation- ships with other classes. The UML class diagram can depict all these things quite easily. The fundamental element of the class diagram is an icon the represents a class. A class icon is simply a rectangle divided into three compartments. The topmost compartment contains the name of the class. The middle compartment contains a list of attributes (member variables), and the bottom compartment contains a list of operations (member functions).In many diagrams, the bottom two compartments are omitted. Even when they are present, they typically do not show every attribute and operations. The goal is to show only those attributes and operations that are useful for the particular diagram. This ability to abbreviate an icon is one of the hallmarks of UML. Each diagram has a particular purpose. That purpose may be to highlight on particular part of the system, or it may be to illuminate the system in general. The class icons in such diagrams are abbreviated as necessary. There is typically never a need to show every attribute and operation of a class on any diagram. Basic Class Diagrams symbols and notations Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes. Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition, and write operations into the third.

Active Class Active classes initiate and control the flow of activity, while passive classes store data and serve other classes. Illustrate active classes with a thicker border.

Visibility Use visibility markers to signify who can access the information contained within a class. Private visibility hides information from anything outside the class partition. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent class.

Associations Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other.

Multiplicity (Cardinality) Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for one company only.

Simple Constraint

Constraint Place constraints inside curly braces {}. Composition and Aggregation Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the two classes are not dependent on each other. The diamond end in both a composition and aggregation relationship points toward the "whole" class or the aggregate.

Generalization Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between two classes where one class is a specialized version of another. For example, Honda is a type of car. So the class Honda would have a generalization relationship with the class car.

In real life coding examples, the difference between inheritance and aggregation can be confusing. If you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions of the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC and PROTECTED functions of the super class. Use case diagrams model the functionality of a system using actors and use cases. Use cases are services or functions provided by the system to its users. Basic Use Case Diagram Symbols and Notations System Draw the system's boundaries using a rectangle that contains use cases. Place actors outside the system's boundaries.

Use Case Draw use cases using ovals. Label ovals with verbs that represent the system's functions.

Actors Actors are the users of a system. When one system is the actor of another system, label the actor system with the actor stereotype.

Relationships Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends" relationship indicates alternative options under a certain use case.

BEHAVIOR DIAGRAMS: INTERACTION DIAGRAM Diagrams that describes how group of objects are collaborated.

SEQUENCE DIAGRAM: Describes the behavior of the system through interaction between the system and the environment in time sequence. Two dimensions: Vertical dimension represents time. Horizontal dimension represents objects. Life line Object's existence during the interaction.
Object 1 Object 2

<Event>

COLLABORATION DIAGRAM:

An interaction diagram that shows the order of messages that implement an operation or a transaction. Collaboration diagrams show objects, their links, and their messages.
Object 1

1. <Event >

Object 2

Object: An object has state, behavior, and identity. Objects interact through their links to other objects. Link:A link is an instance of an association, analogous to an object. Message:A message is the communication carried between two objects that trigger an event.

STATECHART DIAGRAM Models the dynamic behavior of individual classes or any other kind of object. Shows the sequences of states, events, and actions. State:Represents a condition or situation during the life of an object during which it satisfies some condition or waits for some event.
<State>

Start State:Shows the beginning of workflow. End state::Represents the final or terminal state.

ACTIVITY DIAGRAM Used for modeling the sequence of activities in a process Special case of a state machine in which most of the states are activities and most of the transitions are implicitly triggered by completion of the actions in the source activities. Activity:Represents the performance of task or duty in a workflow.
<Activity>

Swim lanes:-

Represents organizational units or roles within a business model.

IMPLEMENTATION DIAGRAM Shows the implementation phase of system development. Two types of implementation diagrams: Component diagram Deployment diagram COMPONENT DIAGRAM Models the physical components in the design. A graph of the designs components connected by dependency relationships. Includes concept of packages. Package is used to show how classes are grouped together.

DEPLOYMENT DIAGRAM Shows the configuration of runtime processing elements and software components. It is a graph of nodes connected by communication association. Nodes are the components that are connected to other components through dependencies. Used in conjunction with component diagrams to show the distribution of physical modules.

INTRODUCTION TO RATIONAL ROSE

RATIONAL ROSE:

Rational Rose is an automated tool for software design. It is mainly based on UML diagrams. Rational Rose helps customers design and develop software in an Internet connected global economy. As the Internet has grown to dominate business and technology decisions, all organizations face an e-software paradox. Rational Rose helps companies overcome the e-software paradox by unifying the communities that develop software with a common visual language that accelerates the creation of flexible applications with robust, resilient architectures. Rational Rose Data Modeler is a database modeling and design tool that uses UML (Unified Modeling Language) Notation. It allows you to work with UML object models such as logical models, data models and physical models, and helps you to maintain synchronization between the data model and the database. The Rational Rose Web Modeler provides visualization, modeling and tools for developing Web Applications. To visualize and model N-tier Web Applications, Rose Web Modeler designs a set of stereotypes and tagged values to your Web artifacts, Unified Modeling Language (UML) extensibility features allow you to model the artifacts required to build the web applications. Stereotypes and tagged values represent an extension of UML. Start-Up Rational Rose should be located under Program Files>Rational Suite Enterprise>Rational Rose from the Start Menu. Rose appears and displays the Create New Model dialog box. Click Cancel to start a new model. You will see the default window for Rational Rose. The window is divided into four parts: on the upper left-hand side, you have the browser that contains the different views of your model; on the lower left-hand side, you have the documentation window; to the right of the browser and documentation window, you have the diagram toolbar (hovering over the icons will display a description of what the buttons do); on the right-hand side of the window you have the diagram working area. The Main Screen Before we dive into making the diagrams it is important that we know the important features of the main window. If you look to the far left you will see a side panel as shown in Figure below:

Steps to be followed for creating use case diagrams: Use case diagrams are one of the easiest diagrams to create. In a few simple steps, one will have a diagram similar to the one shown above. First one must create a use case window this can be done in the following steps: 1. Right click on Use Case View in the side bar 2. Go to new and click Use Case Diagram 3. Type the name of the diagram and hit enter 4. Double click on the name you just typed in. The next step is to create an actor. To create an actor: 1. Right click on Use Case View in the side bar 2. Go to new and this time click Actor 3. Click where you want the actor to be on your screen 4. Type in the name of the actor. The next step is to create the use case. This is done in the same fashion as the previous two. 1. Right click on the Use Case View in the side bar 2. Go to new and then Use Case 3. Click where one wants the use case to be on your screen and type in the name. After the creation of an actor and a use case one must connect the two together by an association. To do this 1. Click on the unidirectional association in the toolbox 2. Draw a line starting from the actor and going to the use case that one wants to connect by clicking and dragging. These steps are repeated until one is done with the creation of all the use cases and connecting that properly to the actors, depending on how complicated the drawing is. To rename use case or actor just double click on the original name and type in the new name.

Creating a Class Diagram

When creating a class diagram the first thing that one needs to do is to create the class diagram window. To do this: 1. Right click on Logical View shown on the side bar 2. Go to new and Class Diagram 3. Type in the name of the class diagram 4. Double click on the name you just typed to bring the window up. Now that we have our window ready, lets create our first class . 1. On the toolbox click the fifth button from the top. Refer to Figure 2. 2. Now just drag where one wants the class to be in the window. Now that we have a class lets put some attributes and operations into it. When one double clicks on the class that one just created a box will pop up like in Figure above. This is where one will be editing the class. Here one can do many things including changing the name of the class and adding attributes and operations.

Now one should see a box like in Figure above. To add operations: 1. Click on the tab that reads operations 2. Right click anywhere on the white part and select insert 3. Type in the name of the operation and then hit enter If one double clicks on the operation you created another box will pop up that allows you Once one creates ones class one can make another class in the same fashion, and connect the two classes with an association.

The first thing to be done, as in all the other diagrams, is to create the sequence diagram window. To create the window: 1. Right click on Logical View shown on the side bar 2. Go to new and then sequence diagram 3. Type in the name of the sequence diagram 4. Double click on the name that one just typed in Once one has ones own window all set the first thing to do is to drag actor from the use case diagram into the window. To do this: 1. On the side bar under Use Case View one should see the actor one created with the use case diagram. 2. Click on it and drag it into the sequence diagram window. Now it is time to add objects to sequence diagram. To do this: 1. On the side bar under Logical View one should see all the classes one created. 2. Click on them one at a time and drag them onto the sequence diagram. 3. Order the objects in the order in which methods will be called on them.

Now we must associate the actor with the first class. To do this: 1. Click on create association on the toolbox 2. Below the actor one should see the tip of a lifeline starting. Drag from here to the class one wants to associate with. 3. Now one must label the association with the proper label. 4. Right click on the association created and one can see all the different methods that could be called from the association between those two objects. Choose one of them. Now start from just below the end point of the association created and repeat the process, connecting the next class with this one. Continue this until sequence diagram is complete. Creating a Statechart diagram 1. Open rational rose enterprise edition. 2. Then right click the logical view to open a new state chart diagram. 3. A new window with suitable toolbox containing different styles appears for creating state chart diagram. 4. Rounded rectangle represents state of project. 5. The state is a set of values that describes an object at a specific point in time and is represented by state symbols. 6. Transitions are represented by arrows connecting state symbols. 7. This diagram shows sequence of states that an object goes through during its lifetime in response to messages. 8. Save and terminate. CREATING ACTIVITY DIAGRAM To create an activity diagram: 1. In the browser, right click any model element except for attributes associations or model elements that appear in the component view. 2. Click New Activity Diagram. 3. Resume or double click to display the New Diagram icon in then browser. 4. Another way to create an activity diagram. Click the browser State Machine Diagram button from the toolbar. Click New. Select the activity diagram check box in the New State Machine dialogue box. Enter the activity diagram title Click OK. 5. Tools on the activity diagram toolbox to model activity diagram: Decision states Swim lanes _ Synchronizations Object Transitions

Object flow Start State Activities End State

Component Diagrams and Deployment Diagrams: 1. Open the corresponding Sequence Diagram. 2. Press F5 to auto generate the collaboration diagram and arrange the diagram elements. 3. Save the collaboration diagram. 4. Select the Component view package in the browser window and right click it. 5. Select New Component Diagram 6. Add components to the diagram. 7. Add links between the components to the diagram. 8. To arrange the components align with the user workspace in the Rational Rose package. 9. Save the component diagram. 10. Select the Component view package in the browser window and right click it. 11. Select New Deployment Diagram 12. Add Deployment components to the diagram. 13. Add links between the Deployment components to the diagram. 14. To arrange the Deployment components align with the user workspace in the Rational Rose package. 15. Save the Deployment Diagram.