You are on page 1of 61

Yeshwantrao Chavan College of Engineering

Wanadongri Hingna Road, Nagpur-441 110

Department of Computer Technology

LAB MANUAL ON

SOFTWARE ENGINEERING
SIXTH SEMESTER 2011-2012

YESHWANTRAO CHAVAN COLLEGE OF ENGINEERING DEPARTMENT OF COMPUTER TECHNOLOGY
SIXTH SEMESTER Term II (2010-2011) SOFTWARE ENGINEERRING MANUAL

INDEX Sr. No. 1 2 3 4 5 6 7 8 9 10 1 2 Practical Name
Introduction to Software Engineering fundamentals Overview of UML and Introduction to Rational Rose Interface To identify use cases and draw Use Case diagram for the given case study. To create use case documents for the given case study. To study Software Requirement Specification template Detailed analysis and design of Mini Project(SRS) To study E-R Diagram and Data Flow Diagrams. To draw Use Case Diagram and E-R diagram for Mini
project.

To study and draw UML Class diagrams. To study and draw Activity diagrams. BEYOND SYLLABUS: To study Manual/Automated testing. To study Microsoft Project Plan.

PRACTICAL NO: 1 AIM: Introduction to Software Engineering fundamentals.
THEORY:
1. Software:
A textbook description of software might take the following form: Software is (1)instructions (computer programs) that when executed provide desired function and performance,(2) data structures that enable the programs to adequately manipulate information, and (3) documents that describe the operation and use of the programs. There is no question that other, more complete definitions could be offered. But we need more than a formal definition.

2. Software Characteristics:
To gain an understanding of software (and ultimately an understanding of software engineering), it is important to examine the characteristics of software that make it different from other things that human beings build. When hardware is built, the human creative process (analysis, design, construction, testing) is ultimately translated into a physical form. If we build a new computer, our initial sketches, formal design drawings, and bread boarded prototype evolve into a physical product (chips, circuit boards, power supplies, etc.). Software is a logical rather than a physical system element. Therefore, software has characteristics that are considerably different than those of hardware:

I.

Software is developed or engineered; it is not manufactured in the classical sense.

Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. Both activities are dependent on people, but the relationship between people applied and work accomplished is entirely different. Both activities require the construction of a "product" but the approaches are different. Software costs are concentrated in engineering. This means that software projects cannot be managed as if they were manufacturing projects.

II.

Software doesn't "wear out."
Figure 1 depicts failure rate as a function of time for hardware. The relationship, often called the "bathtub curve," indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected and the failure rate drops to a steady-state level (ideally, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer

The design engineer draws a simple schematic of the digital circuitry. abuse. As changes are made. most software continues to be custom built. it can be ordered off the shelf. that is. When a hardware component wears out. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. another change is requested. Although the industry is moving toward component-based assembly. these are corrected (ideally.from the cumulative effects of dust. software will undergo change (maintenance). Stated simply. a collection of standard design components is created. temperature extremes. As an engineering discipline evolves. it is likely that some new defects will be introduced. Idealized and actual failure curves for Software III. Therefore. vibration. The reusable components have been created so that the engineer can concentrate on the truly innovative elements of a design. Slowly. Each integrated circuit (called an IC or a chip) has a part number. does some fundamental analysis to assure that proper function will be achieved. the failure rate curve for software should take the form of the ―idealized curve‖ shown in Figure 2. a defined and validated function. Failure curve for hardware FIGURE 2. it is replaced by a spare part. Undiscovered defects will cause high failure rates early in the life of a program. without introducing other errors) and the curve flattens as shown. There are no software spare parts. After each component is selected. Another aspect of wear illustrates the difference between hardware and software. a well defined interface. causing the failure rate curve to spike as shown in Figure 2. However. But it does deteriorate! This seeming contradiction can best be explained by considering the ―actual curve‖ shown in Figure 2. causing the curve to spike again. However. Software is not susceptible to the environmental maladies that cause hardware to wear out. and then goes to the shelf where catalogs of digital components exist. the implication is clear—software doesn't wear out. the parts of the design that represent something . In theory. Standard screws and off-the-shelf integrated circuits are only two of thousands of standard components that are used by mechanical and electrical engineers as they design new systems. and a standard set of integration guidelines. the hardware begins to wear out. FIGURE 1. Before the curve can return to the original steady-state failure rate. During its life. therefore. software maintenance involves considerably more complexity than hardware maintenance. The idealized curve is a gross oversimplification of actual failure models for software. Consider the manner in which the control hardware for a computer-based product is designed and built. the minimum failure rate level begins to rise—the software is deteriorating due to change. and many other environmental maladies.

For example.g. but determinate. Other systems applications (e. and produces output that varies as a function of environment and time. component reuse is a natural part of the engineering process..g. Such applications are determinate. It is somewhat difficult to develop meaningful generic categories for software applications.g. Modern reusable components encapsulate both data and the processing applied to the data. editors. In the hardware world. Information determinacy refers to the predictability of the order and timing of information. we have extended our view of reuse to encompass not only algorithms but also data structure. In the software world.. it is something that has only begun to be achieved on a broad scale. Today.. drivers. Software Applications: Software may be applied in any situation for which a prespecified set of procedural steps (i. compilers. Applications with these characteristics are indeterminate.‖ Software that controls an automated machine (e. A multiuser operating system. As software complexity grows. on the other hand. the system software area is characterized by heavy interaction with computer hardware. resource sharing. executes algorithms that can be interrupted by external conditions. an algorithm) has been defined (notable exceptions to this rule are expert system software and neural network software). executes the analysis algorithm(s) without interruption. Some system software (e. telecommunications processors) process largely indeterminate data. today's graphical user interfaces are built using reusable components that enable the creation of graphics windows. . neat compartmentalization disappears.new.e. For example. System software is a collection of programs written to service other programs. The following software areas indicate the breadth of potential applications: 1) System software. we built scientific subroutine libraries that were reusable in a broad array of engineering and scientific applications. heavy usage by multiple users. a numerical control) accepts discrete data items with limited structure and produces individual machine commands in rapid succession.. These subroutine libraries reused well defined algorithms in an effective manner but had a limited domain of application. The data structure and processing detail required to build the interface are contained with a library of reusable components for interface construction. Most software continues to be custom built. A software component should be designed and implemented so that it can be reused in many different programs. Content refers to the meaning and form of incoming and outgoing information. In either case. and sophisticated process management. enabling the software engineer to create new applications from reusable parts. and multiple external interfaces. Information content and determinacy are important factors in determining the nature of a software application. and file management utilities) process complex. and produces resultant data in report or graphical format. accepts inputs that have varied content and arbitrary timing. information structures. IV. many business applications use highly structured input data (a database) and produce formatted ―reports. pull-down menus. In the 1960s. and a wide variety of interaction mechanisms. concurrent operation that requires scheduling. complex data structures. operating system components. An engineering analysis program accepts data that have a predefined order.

. Elements of real-time software include a data gathering component that collects and formats information from an external environment. Word processing. Perl.. 7) Web-based software. inventory) have evolved into management information system (MIS) software that accesses one or more large databases containing business information.. the network becomes a massive computer providing an almost unlimited software resource that can be accessed by anyone with a modem. hypertext and a variety of visual and audio formats). entertainment. keypad control for a microwave oven) or provide significant function and control capability (e. However. computer graphics. database management.g. external network. theorem proving. Applications in this area restructure existing data in a way that facilitates business operations or management decision making. HTML. Applications range from astronomy to volcanology. Business information processing is the largest single software application area. or Java).g. and data (e. 6) Personal computer software. an analysis component that transforms information as required by the application.. and a monitoring component that coordinates all other components so that real-time response (typically ranging from 1 millisecond to 1 second) can be maintained. Discrete "systems" (e. In essence. digital functions in an automobile such as fuel control. Expert systems. 3) Business software. Computer-aided design. business software applications also encompass interactive computing (e. 4) Engineering and scientific software. and game playing are representative of applications within this category. modern applications within the engineering/scientific area are moving away from conventional numerical algorithms. Embedded software can perform very limited and esoteric functions (e. CGI.. The personal computer software market has burgeoned over the past two decades. payroll. 5) Embedded software. Engineering and scientific software have been characterized by "number crunching" algorithms. a control/output component that responds to the external environment.. and braking systems). spreadsheets. Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets. Intelligent products have become commonplace in nearly every consumer and industrial market.g. system simulation. In addition to conventional data processing application.g. The Web pages retrieved by a browser are software that incorporates executable instructions (e. and from molecular biology to automated manufacturing.g. point of. from automotive stress analysis to space shuttle orbital dynamics. . and database access are only a few of hundreds of applications.2) Real-time software. accounts receivable/payable. also called knowledge based systems. personal and business financial applications. pattern recognition (image and voice). 8) Artificial intelligence software. and other interactive applications have begun to take on real-time and even system software characteristics. dashboard displays. Artificial intelligence (AI) software makes use of nonnumeric algorithms to solve complex problems that are not amenable to computation or straightforward analysis.g. Software that monitors/analyzes/controls real-world events as they occur is called real time. artificial neural networks.sale transaction processing). multimedia.

CASE combines software.) are produced. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. quality is ensured. The bedrock that supports software engineering is a quality focus. Process defines a framework for a set of key process areas (KPAs) [PAU93] that must be established for effective delivery of software engineering technology. called computer-aided software engineering. When tools are integrated so that information created by one tool can be used by another. a system for the support of software development. forms. and support. the application of engineering to software. milestones are established. documents. Software engineering methods provide the technical how-to's for building software. program construction.How do we define software engineering? A definition proposed by Fritz Bauer [Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines The IEEE [IEE93] has developed a more comprehensive definition when it states: Software Engineering: (1) the application of a systematic. V. The key process areas form the basis for management control of software projects and establish the context in which technical methods are applied. testing. that is. quantifiable approach to the development. Software engineering tools provide automated or semi-automated support for the process and the methods. is established. Total quality management and similar philosophies foster a continuous process improvement culture. and change is properly managed. Methods encompass a broad array of tasks that include requirements analysis. and a software engineering database (a repository containing important information about analysis. Software engineering layers . etc. program construction. reports. design. hardware. and testing) to create a software engineering environment analogous to CAD/CAE (computer-aided design/engineering) for hardware. design. Software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. data. work products (models. any engineering approach (including software engineering) must rest on an organizational commitment to quality. The foundation for software engineering is the process layer. and this culture ultimately leads to the development of increasingly more mature approaches to software engineering. SOFTWARE ENGINEERING: A LAYERED TECHNOLOGY: Software engineering is a layered technology. (2) The study of approaches as in (1). disciplined. operation. and maintenance of software.

you probably wouldn't start by just buying a bunch of wood and nailing it together until it looks about right. A blueprint helps you plan an addition before you build it. and back again. As you gather requirements for your system. By producing visual models of a system. You wouldn't want the whole thing to come crashing down with the slightest rain. Communication between users. Similarly. You'd want some blueprints to follow so you can plan and structure the addition before you start working. testers. we can show how the system works on several levels. you'll take the business needs of the users and map them into requirements that your team can use and understand. They are the blueprints for systems. We can model the interactions between the users and a system. and anyone else involved with a project is the primary purpose of visual modeling. you'd be more than a little concerned if the contractor doing the job decided to "wing it" and work without plans. analysts. if we so desire. We can even model the interactions between systems. It can help you be sure the design is sound. You could accomplish this communication using nonvisual (textual) information. and the system can withstand even a hurricane of requirement changes. Visual modeling is the process of taking the information from the model and displaying it graphically using a standard set of graphical elements. We can model the interactions of objects within a system. you'll want to take these requirements and generate code from them. Eventually. the requirements have been met.PRACTICAL NO: 2 AIM: Overview of UML and Introduction to RATIONAL ROSE Interface. THEORY: What Is Visual Modeling? If you were building a new addition to your house. humans are visual creatures. managers. Odds are. Models do the same thing for us in the software world. developers. By formally mapping the requirements to the code. a model helps you plan a system before you build it. the addition will last longer this way. . We seem to be able to understand complexity better when it is displayed to us visually as opposed to written textually. but on the whole. A standard is vital to realizing one of the benefits of visual modeling: communication. This process is called modeling. without getting lost along the way. and that the code can easily be traced back to the requirements. you can ensure that the requirements are actually met by the code. The result of the modeling process is the ability to trace the business needs to the requirements to the model to the code.

And chief information Officers can look at high−level models and see how systems in their organization interact with one another. users can visualize the interactions they will make with the system from looking at a model. Rational Rose supports these three notations. For example. however. He has written several books discussing the needs and benefits of visual modeling.After creating these models. All in all. Object Modeling Technology (OMT). For example. Figure 1is a sampling of the objects and relationships represented in the Booch notation. visual models provide a powerful tool for showing the proposed system to all of the interested parties. objects in this notation are represented by clouds. Systems of Graphical Notation One important consideration in visual modeling is what graphical notation to use to represent various aspects of a system. Analysts can visualize the interactions between objects from the models. UML is a standard that has been adopted by the majority of the industry as well as the standards' governing boards such as ANSI and the Object Management Group (OMG). and has developed a notation of graphical symbols to represent various aspects of a model. Some of the popular notations that have strong support are Booch. Grady Booch. we can show them to all interested parties. illustrating the fact that objects can be almost anything. at Rational Software Corporation. and UML. Testers can visualize the interactions between objects and prepare test cases based on these interactions. and those parties can glean the information they find valuable from the model. . Many people have proposed notations for visual modeling. Booch Notation: The Booch method is named for its inventor. Booch's notation also includes various arrows to represent the types of relationships between objects. Project managers can see the whole system and how the parts interact. Developers can visualize the objects that need to be developed and what each one needs to accomplish.

James Rumbaugh. Object−Oriented Modeling and Design (Prentice Hall. 1990).1: Examples of symbols in the Booch notation Object Management Technology (OMT): The OMT notation comes from Dr. . who has written several books about systems analysis and design. A sampling of the objects and relationships represented in the OMT notation follows in Figure 1. Rumbaugh discusses the importance of modeling systems in real−world components called objects. OMT uses simpler graphics than Booch to illustrate systems.Figure 1.1. In an aptly titled book.

" all work at Rational Software Corporation and focus on the standardization and refinement of UML. Rumbaugh. commonly referred to as the "three amigos. Rebecca Wirfs−Brock.2: Examples of symbols in the OMT notation Unified Modeling Language (UML): UML notation comes from a collaborative effort of Grady Booch. Dr. Ivar Jacobson. and many others. Jacobson is a scholar who has written about capturing system requirements in packages of transactions called use cases. Booch. and also include elements from other notations. Shows a sample of UML notation. Peter Yourdon. .3. Jacobson also developed a method for system design called Object−Oriented Software Engineering (OOSE) that focused on analysis.Figure 1. We will discuss use cases in detail in Chapter 4. and Jacobson. James Rumbaugh. Figure 1. UML symbols closely match those of the Booch and OMT notations.

. The latest release is UML 1.Figure 1. which was ratified in 2000.1 as an industry standard. associations and others. It also displays relationships such as containment. packages and objects.3. and many major software development companies began adopting it. UML has evolved to incorporate new ideas such as web−based systems and data modeling. Class Diagram models class structure and contents using design elements such as classes.8 of the Unified Method was introduced. UML 1.0 was ratified and given to the Object Technology Group in 1997. This consists of the vertical dimension (time) and horizontal dimension (different objects) Collaboration Diagram displays an interaction organized around the objects and their links to one another. http://www. when version 0. Interaction Diagrams   Sequence Diagram displays the time sequence of the objects participating in the interaction.omg.3 can be found at the Object Management Group's website. inheritance. Numbers are used to show the sequence of messages. UML diagrams commonly created in visual modeling tools include: Use Case Diagram displays the relationship among actors and use cases. Types of UML Diagrams Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. Over the past years. In 1997. The specification for UML 1. OMG released UML 1. The Unified Method was refined and changed to the Unified Modeling Language in 1996. Official unification of the methodologies continued until late 1995.3: Examples of symbols in UML notation Each of the three amigos of UML began to incorporate ideas from the other methodologies.org/.

Deployment Diagram displays the configuration of run-time processing elements and the software components. at run times well as at more than one time. and executable components. Dependencies among components are shown. Implementation: The implementation characteristic of a system is an entirely new feature that describes the different elements required for deploying a system.State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli. let us take a quick look at exactly what these characteristics are. an additional characteristic that a software system possesses is related to implementation. In addition to these two characteristics. The static characteristics define what parts the system is made up of. for example. the ways a system behaves in response to certain events or actions are the dynamic characteristics of a system. together with its responses and actions. Some components exist at compile time. Before we categorize UML diagrams into each of these three characteristics. Dynamic: The behavioral features of a system. binary code components. Dynamic. "static" part and a behavioral. and Implementation A software system can be said to have two distinct characteristics: a structural. and objects that live on them. at link time. including source code components. This diagram focuses on flows driven by internal processing Physical Diagrams   Component Diagram displays the high level packaged structure of the code itself.    Static: The static characteristic of a system is essentially the structural aspect of the system. Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. "dynamic" part. processes. Software component instances represent run-time manifestations of code units UML Diagram Classification—Static. The UML diagrams that fall under each of these categories are:  Static Use case diagram Class diagram Dynamic o State diagram o Activity diagram o Sequence diagram o Collaboration diagram Implementation o Component diagram o Deployment diagram o o   .

The 4+1 view offers a different perspective to classify and apply UML diagrams. These different views are:      Design View: The design view of a system is the structural view of the system. and collaboration diagram are used in this view. Process View: The dynamic behavior of a system can be seen using the process view.Finally. Component View: Next. Use case diagrams of UML are used to view a system from this perspective as a set of discrete activities or transactions. 4+1 View of UML Diagrams Considering that the UML diagrams can be used in different stages in the life cycle of a system. Each of these views represents how a system can be modeled. . This will enable us to understand where exactly the UML diagrams fit in and their applicability. The 4+1 view is essentially how a system can be viewed from a software life cycle perspective. Use case View: Finally. Class diagrams and object diagrams form the design view of the system. sequence diagram. let us take a look at the 4+1 view of UML diagrams. Deployment View: The deployment diagram of UML is used to identify the deployment modules for a given system. This gives an idea of what a given system is made up of. The different diagrams such as the state diagram. This is the deployment view of the system. we have the use case view. activity diagram. you have the component view that shows the grouped modules of a given system modeled using the component diagram.

Sequence Diagram for the Add a Course Scenario . Use case diagram 2.UML diagrams for case study: 1.

.

Course Reporting Class Diagram in the University Artifacts Package .3. Main Class Diagram for the University Artifacts Package 4.

a software designer uses Rational Rose to visually create (model) the framework for an application by blocking out . In much the same way a theatrical director blocks out a play. Activity diagram Rational Rose: Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool intended for visual modeling and component construction of enterprise-level software applications.5.

) Then. ROSE is Rational Object Oriented Software Engineering.  C++ Analyzer was also easy to use (though it‘s functionality could be included in the Rose itself) Negative factors  At first the tool seems to be quite complex. Oracle8. Rational Rose documents the diagram as it is being constructed and then generates code in the designer's choice of C++. Rose also supports Round-Trip engineering with several lan4guages.  The creation of the different diagrams can be learned quite fast.  Separate tool had to be used (and learned) to reverse-engineer files. Rational Rose can perform what is called "roundtrip engineering" by going back and updating the rest of the model to ensure the code remains consistent. as the developer begins to understand how the components interact and makes modifications in the design. RATIONAL ROSE INTERFACE: Parts of the Screen: . It supports two essential elements of modern software engineering: component based development and controlled iterative development. Two popular features of Rational Rose are its ability to provide iterative development and round-trip engineering. Rose uses the UML to provide graphical methods for non-programmers wanting to model business processes as well as programmers modeling application logic. Rational Rose includes tools for reverse engineering as well as forward engineering of classes and component architectures.  Some minor bugs were found. Summary of the Rational Rose Positive factors  The tool itself was quite easy to install.  Generated code was a bit obfuscated. Rose offers a fast way for clients and new employees to become familiar with system internals. (This is in contrast to waterfall development where the whole project is completed from start to finish before a user gets to try it out. Rational Rose allows designers to take advantage of iterative development (sometimes called evolutionary development) because the new application can be created in stages with the output of one iteration becoming the input to the next. Java.  Layout manager could have been a bit more effective. Rational Rose is a set of visual modeling tools for development of object oriented software. Models created with Rose can be visualized with several UML diagrams. use case elements (ovals). objects (rectangles) and messages/relationships (arrows) in a sequence diagram using drag-and-drop symbols.  Code generation is simple. You can gain valuable insights to your actual constructed architecture and pinpoint deviations from the original design. Visual Basic. CORBA or Data Definition Language.classes with actors (stick figures). Rational Rose is commercial case-tool software.

we'll look at each of these. the documentation window. their purposes are: Browser Used to quickly navigate through the model Documentation window Used to view or update documentation of model elements Toolbars Used for quick access to commonly used commands Diagram window Used to display and edit one or more UML diagrams Log Used to view errors and report the results of various commands . and the log.The five primary pieces of the Rose interface are the browser. In this section. Briefly. the diagram window. the toolbars.

And when you model Use Cases in Rational Rose. you can be sure your solution is being built for the user. Use Cases A use case is a scenario that describes the use of a system by an actor to accomplish a specific goal. systems and data analysts by enabling them to create and manage models in one tool with one modeling language. A scenario is a sequence of steps that describe the interactions between an actor and the system. Data analysts can model database designs in Rational Rose. Actors are generally people although other computer systems may be actors. What does this mean? An actor is a user playing a role with respect to the system. Use cases help us       capture the system's functional requirements from the users' perspective actively involve users in the requirements-gathering process provide the basis for identifying major classes and their relationships serve as the foundation for developing system test cases Means of capturing requirements Document interactions between user(s) and the system • • User (actor) is not part of the system itself But an actor can be another system An individual use case represents a task to be done with support from the system (thus it is a ‗coherent unit of functionality‘) . improving their communication with developers. Business analysts can use Rational Rose to model and visualize business processes and highlight opportunities to increase efficiency.PRACTICAL NO: 3 AIM: To identify use cases and draw Use Case diagram for the given case study. THEORY: Rational Rose is the world's leading visual modeling tool. The use case model consists of the collection of all actors and all use cases. Rational Rose unifies business.

Creating Use-case in Rational Rose: Use Case View: Capturing Some Requirements Expand the Use Case View and double click on Main to open the use case diagram window to get: Using the toolbar. and the ovals represent the individual use cases. collectively define the boundaries of the system to be implemented and provide the basis for defining development iterations (Use language of user).The rectangle represents the system boundary. Use case is actually defined as text. the system does…). insert the use cases and actors into the main use case diagram to get: . They do not reveal the structure of the system (i.e. the stick figures represent the actors (users of the system). this notation tells us very little about the actual functionality of the system. Unfortunately. including descriptions of all of the normal and exception behaviour expected.

. Cancel that and you will see something like this.Next. using the Unidirectional Association button on the toolbar to establish the following associations between the actors and use cases. 1. Start --> Programs --> Programming Tools -->Rational Suite Development Studio -->Rational Rose Enterprise Edition 2. You will be presented with a ―Create Model‖ Screen. Open Rational Rose.

There are three types of relationships Include: An include relationship is a stereotyped relationship that connects a base use case to an inclusion use case.You cancel the ―Create Model‖ screen since you are not creating any particular type of model. 3. etc. 5. you would create a new ―Use Case ―by right clicking on ―Use Case View‖. right click on the toolbar and click on the Customize link. Here as an example. To add a Use Case diagram. An include relationship specifies how behaviour in the inclusion use case is used by the base use case Extends: An extend relationship is a stereotyped relationship that specifies how functionality of one use case can be inserted into the functionality of another use case. 6. The list box on the left contains the actor entity. White diagram sheet with its associated toolbox would appear in right frame. Activity Diagram. you can open an existing model by selecting ―Existing‖ tab from ―Create New Model‖ screen. 8. right click on the use case name ―Enter System‖ and select New Use Case Diagram. I have added a Use Case diagram which shows user of the computerized scheduling system trying to ―log in‖ the system by entering username and password. As mentioned earlier you can have multiple use cases. Select an actor and a Use case from the toolbox. Let us name this use case diagram as ―Login‖. Now you may want to specify relationships between those use cases. Add it to the right hand side and click Close. Enter the brief description of the Use Case in the ―Documentation‖ area of the specification. . If a diagram sheet does not appear then doubleclick on the newly created Use case diagram. the Refine: A refine relationship is a stereotyped relationship that connects two or more model elements at different semantic levels or development stages. Additional information about ―Use Case View‖ package can be entered in ―Open Specification‖ option. 7. Use Case Diagram. Now since you are only interested in creating Use Cases. However once you have a model. Additionally all missing components can be added using the customize menu. Relationships among Use Cases 1. 4. You can add Class Diagram. Optional Step: If the symbol for drawing an actor does not appear on the toolbar (situated vertically in the middle of the screen). Click Ok. State Diagram. selecting ―New‖ and then ―Use Case‖ from the list of options (Make sure that you don‘t select the Use Case Diagram option). select ―Open Specification‖. you can add any type of diagram to this particular Use Case. Once the specification is filled out. Next step is to draw the diagram. Once you have opened a Use Case. enter ―Enter System‖ as the name for the Use Case and then right click on it.

Bi-directional association: If you prefer. classes or interfaces. Associations are the most general of all relationships and consequentially the most semantically weak. you can also customize the toolbox to include the bi-directional tool to the use-case toolbox. the association tool on the toolbox is uni-directional and drawn on a diagram with a single arrow at one end of the association. . The communication can be between use cases. the relationship is an association By default. If two objects are usually considered independently. actors. The end with the arrow indicates who or what is receiving the communication.Relations: Association Relationship: An association provides a pathway for communication.

Course Registration System Use-Case Model Main Diagram .

THEORY: Use cases for case study: (Samples) 1. the system displays an error message. 1.1 Basic Flow This use case starts when the actor wishes to log into the Course Registration System. the actor enters an invalid name and/or password.3 Special Requirements None.2.4 Pre-Conditions None.PRACTICAL NO: 4 AIM: To create use case documents for the given case study. 1. the actor is now logged into the system.5 Post-Conditions If the use case was successful.2 Alternative Flows 1.6 Extension Points .1 Invalid Name/Password If. The system requests that the actor enter his/her name and password. in the Basic Flow.1 Brief Description This use case describes how a user logs into the Course Registration System. 1.2. the system state is unchanged.2 Flow of Events 1. Login 1. If not. 1. The actor enters his/her name and password. The actor can choose to either return to the beginning of the Basic Flow or cancel the login.2. 3.2. 1. 2. at which point the use case ends. 1. The system validates the entered name and password and logs the actor into the system. 1.

The Submit Schedule subflow is executed. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of available offerings.g. Once the student has made his/her selections.. 2. 3.2 Update a Schedule 1.. the Delete a Schedule subflow is executed. The Student may update the course selections on the current selection by deleting and adding new course offerings. 3.g. If the Registrar selected ―Create a Schedule‖. 2. the system creates a schedule for the Student containing the selected course offerings.1 Basic Flow This use case starts when a Student wishes to register for course offerings. 2.2. The Student verifies the deletion. 3. 2.1. If the Registrar selected ―Update a Schedule‖. or to change his/her existing course schedule. The system retrieves and displays the Student‘s current schedule (e. The Course Catalog System provides a list of all the course offerings for the current semester. Update a Schedule. 5. . The Student also selects any course offerings to delete from the existing schedule. The Submit Schedule subflow is executed. Once the student has made his/her selections. The system retrieves and displays the Student‘s current schedule (e. 2.2. one of the sub flows is executed.1 Create a Schedule 1.2 Flow of Events 2. The system prompts the Student to confirm the deletion of the schedule.3 Delete a Schedule 1. Register for Courses 2.2. the system updates the schedule for the Student using the selected course offerings. 4. the Update a Schedule subflow is executed. The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student. the schedule for the current semester).2. 2. If the Registrar selected ―Delete a Schedule‖. 2.1. The system requests that the Student specify the function he/she would like to perform (either Create a Schedule.1. The Student can also update or delete course selections if changes are made within the add/drop period at the beginning of the semester.None. or Delete a Schedule). 2. The Student selects the course offerings to add from the list of available course offerings.1 Brief Description This use case allows a Student to register for course offerings in the current semester. 1. the Create a Schedule subflow is executed. 2. the schedule for the current semester). The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student. Once the Student provides the requested information. 4.

the Student may choose to save a schedule rather than submitting it.1 Save a Schedule At any point.5 Course Registration Closed When the use case starts. If this occurs. 2. as is (see Save a Schedule subflow).2. The system deletes the Schedule. and the use case terminates.2.4. The course offering is marked as “enrolled in” in the schedule.2. if it is determined that registration for the current semester has been closed.2.2.2. If the schedule contains ―enrolled in‖ course offerings. the system will display an error message to the Student. the Student must be removed from the course offering. and the Basic Flow is restarted at the beginning. and the use case terminates. or that the selected course offering is full. or Schedule Conflicts If. the system is unable to retrieve the Student‘s schedule.2. The system then adds the Student to the selected course offering. the system determines that the Student has not satisfied the necessary prerequisites. Students cannot register for course offerings after registration for the current semester has been closed. that the course offering is open. or that there are schedule conflicts.2. The schedule is saved in the system. the Submit Schedule step is replaced with the following: The course offerings not marked as ―enrolled in‖ are marked as ―selected‖ in the schedule. in the Submit Schedule sub-flow.2 Unfulfilled Prerequisites. The schedule is saved in the system. Course Full. The Student can either select a different course offering and the use case continues. the Student decides not to delete the schedule. 2. 2. save the schedule.6 Delete Cancelled If. at which point the Basic Flow is re-started at the beginning.2. the delete is cancelled. 2.3 No Schedule Found If. in the Delete A Schedule sub-flow.3 Special Requirements .1.2. 2. The Student acknowledges the error. 2. the system verifies that the Student has the necessary prerequisites. and that there are no schedule conflicts. an error message is displayed.2. or cancel the operation.2.2 Alternative Flows 2.4 Course Catalog System Unavailable If the system is unable to communicate with the Course Catalog System.2. an error message is displayed. 2. a message is displayed to the Student. and the Basic Flow is re-started at the beginning.2. in the Update a Schedule or Delete a Schedule sub-flows.4 Submit Schedule For each selected course offering on the schedule not already marked as “enrolled in”. The Student acknowledges the error message. 2.

PRACTICAL NO: 5 AIM: To study Software Requirement Specification template. 20XX Ayşe Güzel Mehmet Güçlü . THEORY: Student Course Registration System REQUIREMENTS REPORT CENG XXX Fall 2001 October xx.None. 2.4 Pre-Conditions The Student must be logged onto the system before this use case begins.

Computer Engineering Department Middle East Technical University .

Criticality 3.1. 3.3 User Characteristics –2.5 User Objectives –2.Technical issues 4.1 Student Log-in {This is a ―System Function‖}  Corresponds to a USE CASE (one oval in the use case diagram)  Draw a COLLABORATION Diagram  Description paragraph.3 Overview –1. General Description –2.Others as appropriate 3.1.4 User Problem Statement –2.6 General Constraints 3.Cost and schedule 5.Student Course Registration System Requirements Analysis Report date 1.1 Registration {Top level functions are called: ―Capability‖}  Description about the top-level system function (Capability).1.1.1 Every student has a Username 3.Risks 6.Dependencies with other requirements 7.Description 2.1 Product Functions –2.2 Similar System(s) Information –2.1.Functional Requirements Descriptions about what the system should accomplish – not how. Introduction –1.1.  USE CASE DIAGRAM 3.  Then comes numbered requirements: One sentence each! 3.2 Usernames are unique IEEE suggests every requirement to come with (include only if appropriate): 1.2 Scope of this Document –1.2 Student Authentication .1 Purpose of this Document –1.4 Business Content 2.

1 Abstract or Concrete: 8.2.Reusability 8.2.others -{NOTE: Titles have to be written.Preliminary Schedule 11. Abbreviations 12.3 Application Programming Int.3 List of Subclasses: 8.1.2.4 Software Interfaces 5.1.1 Definitions.2.1 Inheritance Relationships 8.1.2. --.4 Purpose: 8.2.4 Diagnostic interface 4.1.1.2 Class Descriptions IEEE Suggests each class to be described as: 8.2 Hardware Interfaces 4.Serviceability 11.2 References -.Extensibility 7.1. 4. Acronyms.1 Student 8.1. Affinity/compatibility 9.Design Constraints 6.7 Operations: 8.1 GUI {Screen Dumps} 4.8 Constraints: {on general state and behavior} 9.Binary Compatibility 3.1.1 Standards Compliance 7.3 Communications Interfaces 4.2 Command Line Interface 4.Other Non Functional Attributes 1.4.6 Attributes: 8.2.others --- 8.Interface Requirements 4.Portability 6.5 Collaborations: {other classes} 8.Preliminary Budget 12.Operational Scenarios {A proposed specific use} 10. even if there is nothing to write under} .2 List of Superclasses: 8.Resource Utilization 10.2.Preliminary Object-Oriented Analysis 8.2.Maintainability 5.1.Appendices 12.1.Appl.1 User Interfaces 4.Security 2.1.Performance Requirements 6.1.Reliability 4.

PRACTICAL NO: 6 AIM: Detailed analysis and design of Mini Project (SRS). THEORY: Note: Students are expected to create SRS document for their Mini project PRACTICAL NO: 7 .

Attributes are the data we collect about the entities. ERD's look likes this: Developing an ERD. There are three basic elements in ER models: Entities are the "things" about which we seek information. Developing an ERD requires an understanding of the system and its components. Relationships provide the structure needed to draw information from multiple entities. . THEORY: Entity-Relationship Diagrams (ERD): Data models are tools used in analysis to describe the data requirements and assumptions in the system from a top-down perspective.AIM: To study E-R Diagram and Data Flow Diagrams. Generally. They also set the stage for the design of databases later on in the SDLC.

identified in the narrative. identified in the narrative (see highlighted items above). 2. The system must record details concerning patient treatment and staff payment.Consider a hospital: Patients are treated in a single ward by the doctors assigned to them. The system will also need to track what treatments are required for which patients and when and it should be capable of calculating the cost of treatment per week for each patient (though it is currently unclear to what use this information will be put). Healthcare assistants also attend to the patients. Some staff is paid part time and doctors and care assistants work varying amounts of overtime at varying rates (subject to grade). but in rare cases they will have two. or in documentation. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules (entity ______ entity). Initially the system will be concerned solely with drug treatment. . Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time. Define Entities: these are usually nouns used in descriptions of the system. Usually each patient will be assigned a single doctor. in the discussion of business rules. How do we start an ERD? 1. a number of these are associated with each ward.

Which assistants work for Dr.g. Sometimes involves introduction of a link entity (which will be all foreign key) Examples: Patient-Drug.3. and may also suggest new entities. This flexibility allows us to consider a variety of questions such as: a. Which doctors work in which wards? b. Which patients are families related? 6. How much will be spent in a ward in a given week? c. Represent that information with symbols. X? c. How much does a doctor cost per week? e. Add cardinality to the relations. Add attributes to the relations. or they may suggest the need for keys or identifiers. Generally E-R Diagrams require the use of the following symbols: Reading an ERD It takes some practice reading an ERD. but they can be used with clients to discuss business rules. How many doctors are there in the hospital? e. What questions can we ask? a. grade. Which drugs are being used? 4. 5. Many-to-Many must be resolved to two one-to-many with an additional entity Usually automatically happens. Which beds are free? b. e. These allow us to represent the information from above such as the E-R Diagram below: . these are determined by the queries. What is the least expensive prescription? d. Which assistants can a patient expect to see? f. How much will a patient cost to treat? d.

However. 2. Descriptive Specification 1. Algebraic Specifications. i. Petri nets.. • Operational Specification 1. 4. Operational specifications describe the desired behavior of the system. 2. A prototype to test whether specifications reflect the user‘s expectations cannot be derived directly from a DFD since no machine execution is possible without precise semantics for the notation. and boxed is defined precisely. The syntax. arrows. Entities and their relationships. relationships and attributes might you consider? Look at this simplified view. Entity-Relationship Diagrams. 2. Data Flow Diagrams (DFD) DFD provide a graphical notation for capturing the flow of data and operations involved in an information system. What entities. 3. 3. but the semantics of DFDs is not specified precisely.e. What data needs to be stored? 5. Specification Styles Informal specifications are written in a natural language. Formal specifications are written using a notation that has precise syntax and semantics (meaning). Ambiguities. Descriptive specifications – state desired properties of the system. There is also an example of a simplified view of an airline on that page. think about a university in terms of an ERD.ERD brings out issues: 1. The Degree of a relationship. way of composing bubbles. 3. Data Flow Diagrams. Logic Specifications. Many-to-Many. Semi-formal specifications use a notation with precise syntax but imprecise semantics. they lack precise semantics. (Therefore DFD‘s provide a semiformal notation for specifying systems). Finite State Machines. Now. • External Entity Process Output .

Importance of DFDs in a good software design The main reason why the DFD technique is so popular is probably because of the fact that DFD is a very simple formalism – it is simple to understand and use. Starting with a set of high-level functions that a system performs, a DFD model hierarchically represents various sub-functions. In fact, any hierarchical model is simple to understand. Human mind is such that it can easily understand any hierarchical model of a system – because in a hierarchical model, starting with a very simple and abstract model of a system, different details of the system are slowly introduced through different hierarchies. The data flow diagramming technique also follows a very simple set of intuitive concepts and rules. DFD is an elegant modeling technique that turns out to be useful not only to represent the results of structured analysis of a software problem, but also for several other applications such as showing the flow of documents or items in an organization. Data dictionary A data dictionary lists all data items appearing in the DFD model of a system. The data items listed include all data flows and the contents of all data stores appearing on the DFDs in the DFD model of a system. A data dictionary lists the purpose of all data items and the definition of all composite data items in terms of their component data items. For example, a data dictionary entry may represent that the data grossPay consists of the components regularPay and overtimePay. grossPay = regularPay + overtimePay For the smallest units of data items, the data dictionary lists their name and their type. Composite data items can be defined in terms of primitive data items using the following data definition operators: +: denotes composition of two data items, e.g. a+b represents data a and b. [,,]: represents selection, i.e. any one of the data items listed in the brackets can occur. For example, [a,b] represents either a occurs or b occurs. (): the contents inside the bracket represent optional data which may or may not appear. e.g. a+(b) represents either a occurs or a+b occurs. {}: represents iterative data definition, e.g. {name}5 represents five name data. {name}* represents zero or more instances of name data. =: represents equivalence, e.g. a=b+c means that a represents b and c. /* */: Anything appearing within /* and */ is considered as a comment.

PRACTICAL NO: 8 AIM: To draw Use Case Diagram and E-R diagram for Mini project.
THEORY: Note: Students are expected to draw Use Case Diagram and E-R Diagram for their Mini project

PRACTICAL NO: 9 AIM: To study and draw UML Class diagrams.
THEORY:
CLASS DIAGRAM:
Introduction: UML stands for Unified Modeling Language. It represents a unification of the concepts and notations presented by the three amigos in their respective books the goal is for UML to become a common language for creating models of object oriented computer software. In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML. The Meta-model: UML is unique in that it has a standard data representation. This representation is called the meta-model. The meta-model is a description of UML In UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software application. This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also make it easier to write ancillary tools for browsing, summarizing, and modifying UML models. A deeper discussion of the metamodel is beyond the scope of this column. Interested readers can learn more about it by downloading the UML documents from the rational web site The Notation: The UML notation is rich and full bodied. It is comprised of two major subdivisions. There is a notation for modeling the static elements of a design such as classes, attributes, and relationships. There is also a notation for modeling the dynamic elements of a design such as objects, messages, and finite state machines. In this article we will present some of the aspects of the static modeling notation. Static models are presented in diagrams called: Class Diagrams. Class Diagrams: 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. A class icon is simply a rectangle divided into three

1. Inheritance: The inheritance relationship in UML is depicted by a peculiar triangular arrowhead. Even when they are present. Composition also indicates that the lifetime of Point is dependent upon Circle. Notice that each member variable is followed by a colon and by the type of the variable. or otherwise unnecessary. Point will be destroyed with it. which looks rather like a slice of pizza. This means that if Circle is destroyed. and the bottom compartment contains a list of operations (member functions). One or more lines proceed from the base of the arrowhead connecting it to the derived classes.compartments. Finally. It is placed on the Circle class because it is the Circle that is composed of a Point. . The middle compartment contains a list of attributes (member variables). the bottom two compartments are omitted. 2. Composition Relationships: The black diamond represents composition. Composition relationships are a strong form of containment or aggregation. The goal is to show only those attributes and operations that are useful for the particular diagram. notice that the member function arguments are just types. these can be omitted. it can be omitted. Again. If the type is redundant. That is. Point does not know About Circle. points to the base class. This arrowhead. Notice also that the return values follow the member functions in a similar fashion. they typically do not show every attribute and operations. The topmost compartment contains the name of the class. The arrowhead on the other end of the relationship denotes that the relationship is navigable in only one direction. In many diagrams.

Aggregation denotes whole/part relationships whereas associations do not. This indicates that the Window contains many Shape instances. The difference between an aggregation and an association is one of implication. Aggregation The Window class contains many Shape instances. Notice that the role at the Shape end of the aggregation is marked with a ―*‖. there is not likely to be much difference in the way that the two relationships are implemented.Aggregation / Association: The weak form of aggregation is denoted with an open diamond. Notice also that the role has been named. it is pretty safe to ignore the aggregation relationship altogether. That is. For this reason. it would be very difficult to look at the code and determine whether a particular relationship ought to be aggregation or association. and the other class in the relationship is somehow ―part‖ of that whole. However. . This relationship denotes that the aggregate class (the class with the white diamond touching it) is in some way the ―whole‖. An association is nothing but a line drawn between the participating classes. In UML the ends of a relationship are referred to as its ―roles‖. It is the name of the instance variable within Window that holds all the Shapes. In Figure above the association has an arrowhead to denote that Frame does not know anything about Window.

Association How to construct a Class diagram in Rational Rose SE: .

.

.

Class Diagram for the case study: .

PRACTICAL NO: 10 AIM: To study and draw Activity diagrams. which show who is responsible for performing the tasks on the diagram. which show when two or more steps in the workflow occur simultaneously. which show how the workflow moves from one activity to another. which are entities affected by the workflow. Guard conditions are placed in square brackets. and the objects that are affected by the workflow. They let you know that two or more activities occur simultaneously. The diagram shows the steps in the workflow. We can place guard conditions on the transitions to show when the transition occurs. which show where a decision needs to be made during the workflow. _ Activities. you can list the actions that occur for that activity. The arrows connecting the activities are known as transitions. you can use an activity diagram to model the workflow through a particular business use case. _ Business objects. The main elements on an activity diagram are: _ Swimlanes. It is a task that a business worker performs. exiting the activity. . Actions are simply steps within the activity. THEORY: Activity Diagrams: An activity diagram is a way to model the workflow of a use case in graphical form. while inside the activity. _ Synchronizations. or upon a specific event. which are steps within an activity. _ Decision points. The horizontal bars are called synchronizations. A transition lets you know which activity is performed once the current activity has completed. which are steps in the workflow. An activity is simply a step in the workflow. _ Actions. In Rose. Within an activity. the decision points in the workflow. who is responsible for completing each step. In this example. _ Transitions. the activity ―create rejection letter‖ is only performed if the guard condition ―missing documentation‖ is true. Actions may occur when entering the activity.

Activity diagrams for the case study: . which shows where the workflow begins. _ The end state._ The start state. which shows where the workflow ends.

.

.

potentially creating a time . speculative. computers. THEORY: Manual testing is the oldest and most rigorous type of software testing. or they may be written utilizing a generic Test automation framework that can be purchased from a third party vendor. and the automation tools that are chosen. Manual testing is the process of manually testing software for defects. Choose a high level test plan where a general methodology is chosen. Manual testing. innovative. creative. and resources such as people. at least one recent study did not show a dramatic difference in defect detection efficiency between exploratory testing and test case based testing. Comparison to Automated Testing Test automation is the technique of testing software using software rather than people. open-minded. the tester often follows a written test plan that leads them through a set of important test cases. the labour that is saved in actual testing must be spent instead authoring the test program. Manual testing requires a tester to perform manual test operations on the test software without the help of Test automation. A computer can follow a rote sequence of steps more quickly than a person. resourceful and skillful. it is used by engineers to identify and correct the problems. and software licenses are identified and acquired. with expected outcomes. A test program is written that exercises the software and identifies its defects. 2. Compare with Test automation. To ensure completeness of testing. However. 3. A rigorous test case based approach is often traditional for large software engineering projects that follow a Waterfall model. and use most of all features of the application to ensure correct behaviour. 4. detailing the findings of the testers. Test automation may be able to reduce or eliminate the cost of actual testing. some testing tools present a very large amount of data. and it can run the tests overnight to present the results in the morning. It requires a tester to play the role of an end user. who manually follow the steps and record the results. and if not. observant. In addition. Write detailed test cases.PRACTICAL NO: 11 AIM: To study Manual/Automated testing. identifying clear and concise steps to be taken by the tester. Depending on the type of application to be tested. Author a test report. this may require more labour than a manual approach. to be patient. The report is used by managers to determine whether the software can be released. Test automation can be used to automate the sometimes menial and time consuming task of following the steps of a use case and reporting the results. 1. These test programs may be written from scratch. However. Manual testing is a laborious activity that requires the tester to possess a certain set of qualities. Assign the test cases to testers.

Conversely. Unfortunately. Overview Although manual tests may find many defects in a software application. Automation can only be justified where repeatable consistent tests can be run over a stable environment. In addition. test automation becomes more cost effective when the same tests can be reused many times over. Advantage of manual testing.g. There is no complete substitute for manual testing. If future reuse of the test software is unlikely. test automation involves automating a manual process already in place that uses a formalized testing process. In addition it may not be effective in finding certain classes of defects. these recordings may not work properly when a button is moved or relabeled in a subsequent release. There are test frameworks that can be used for regression testing of user interfaces. Although ways of automating this process have been available for over 20 years it is often not appropriate or convenient to automate. such as for regression testing and test-driven development. Commonly. There are two general approaches to test automation: . testing of large numbers of users (performance testing and load testing) is typically simulated in software rather than performed in practice. the comparison of actual outcomes to predicted outcomes. An automatic regression test may also be fooled if the program output varies significantly (e. the setting up of test preconditions. it is a laborious and time consuming process. From the perspective of practicality. Things such as device drivers and software libraries must be tested using test programs. the display includes the current system time). then a manual approach is preferred. because even minor patches over the lifetime of the application can cause features to break which were working at an earlier point in time. graphical user interfaces whose layout changes frequently are very difficult to test automatically. they can be run quickly. software that does not have a graphical user interface tends to be tested by automatic methods.consuming task of interpreting the results. From a cost-benefit perspective. and other test control and test reporting functions. then playing them back and observing that the user interface responds in the same way every time. manual testing may be more effective. When this isn't the case (for example during the early stages of the test cycle or when the application is complicated and the business risk is large) then testing teams almost always revert back to manual testing. Once tests have been automated. This is often the most cost effective method for software products that have a long maintenance life. and when the results can be interpreted quickly. In cases such as these. Test automation is a process of writing a computer program to do testing that would otherwise need to be done manually. Manual testing is crucial for the thorough testing of software applications. They rely on recording of sequences of keystrokes and mouse gestures. Automated testing:Test automation is the use of software to control the execution of tests.

The developer discovers defects immediately upon making a change. Automating unstable features or features that are undergoing changes should be avoided. to validate that the observable behaviour of the program is correct. but research continues into a variety of alternative methodologies for doing so. What to automate. and it is usually employed in combination with manual testing. Relabeling a button or moving it to another part of the window may require the test to be rerecorded. the "interface" is the web page. Graphical User Interface (GUI) testing Many test automation tools provide record and playback features that allow users to interactively record user actions and replay it back any number of times. Selecting the correct features of the product for automation largely determines the success of the automation. A variation on this type of tool is for testing of web sites. but equivalent behaviour. Test cases describe tests that need to be run on the program to verify that the program runs as expected. Record and playback also often adds irrelevant activities or incorrectly records some activities. comparing actual results to those expected. code refactoring is safer.Code-driven testing. One way to generate test cases automatically is model-based testing through use of a model of the system for test case generation. However. such a framework utilizes entirely different techniques because it is reading html instead of observing  . Unit tests are written to define the functionality before the code is written. Code-driven testing A growing trend in software development is the use of testing frameworks such as the xUnit frameworks (for example. A testing framework generates user interface events such as keystrokes and mouse clicks. It can be made cost-effective in the longer term. This type of tool also requires little or no software development. modules. or even whether one really needs automation are crucial decisions which the testing (or development) team must make. and because it is run constantly during development rather than once at the end of a waterfall development cycle. especially when used repeatedly in regression testing. when it is least expensive to fix. transforming the code into a simpler form with less code duplication. where it is known as Test-driven development (TDD). or libraries are tested with a variety of input arguments to validate that the results that are returned are correct. and observes the changes that result in the user interface. This approach can be applied to any application that has a graphical user interface. Test automation tools can be expensive.  Graphical user interface testing. It is considered more reliable because the code coverage is better. The public (usually) interfaces to classes. Proponents argue that it produces software that is both more reliable and less costly than code that is tested by manual exploration. Here. The advantage of this approach is that it requires little or no software development. Code driven test automation is a key feature of agile software development. JUnit and NUnit) that allow the execution of unit tests to determine whether various sections of the code are acting as expected under various circumstances. However. when to automate. Only when all tests pass is the code considered complete. is much less likely to introduce new defects. reliance on these features poses major reliability and maintainability problems. Finally.

 Data driven capability (Input Data. that means Ant or Maven and the popular IDEs). Another variation is scriptless test automation that does not use record and playback. test data sources. There are various types of frameworks. in the Java development ecosystem. One must keep following popular requirements when thinking of test automation:  Platform and OS independence.  Supports unattended test runs for integration with build processes and batch runs. framework provides the basis of test automation and hence simplifying the automation effort. but has all the power and flexibility of a scripted approach. but instead builds a model of the application under test and then enables the tester to create test cases by simply editing in test parameters and conditions. Meta Data.  Email Notifications (Automated notification on failure or threshold levels). test data creation. etc. These are:  Data-driven testing  Modularity-driven testing  Keyword-driven testing  Hybrid testing  Model-based testing . crystal reports. Thus.)  Common Driver (For example.  Support distributed execution environment (distributed test bed)  Distributed application support (distributed SUT) Framework approach in automation A framework is an integrated system that sets the rules of Automation of a specific product. Test-case maintenance is easy.)  Customizable Reporting (DB Access.window events. object details and various reusable modules. This system integrates the function libraries. Output Data. GUI interaction. without necessarily automating tests in an end-to-end fashion. problem detection (consider parsing or polling agents equipped with oracles). What to test? Testing tools can help automate tasks such as product installation.  Extensible & Customizable (Open APIs to be able to integrate with other tools. defect logging. This requires no scripting skills. These may be the test runner or tooling that executes it.)  Easy debugging and logging.. They are categorized on the basis of the automation component they leverage. It can be applied to any GUI-based software application.  Version control friendly – minimum or zero binary files. This enables tests to integrate with the developers' workflows.  Continuous Integration servers require this. as there is no code to maintain and as the application under test changes the software objects can simply be re-learned or added. These components act as small building blocks which need to be assembled in a regular fashion to represent a business process.

For each release of the software it may be tested on all supported operating systems and hardware configurations. Automated software tests can easily execute thousands of different complex test cases during every test run providing coverage that is impossible with manual tests. Software tests have to be repeated often during development cycles to ensure quality. Because of this. Companies like Corel. 1. 3. Automated Software Testing Improves Accuracy 7. data tables. file contents. Intel. An automated software testing tool is able to playback pre-recorded and predefined actions. Autodesk. savvy managers have found that automated software testing is an essential component of successful development projects.Why Automated Testing? Every software development group tests its products. trying various usage and input combinations. Automated Software Testing Increases Test Coverage 9. 2. and internal program states to determine if the product is behaving as expected. Intuit. Symantec and Sony all use TestComplete. Automated software testing can reduce the time to run repetitive tests from days to hours. Even the most conscientious tester will make mistakes during monotonous manual testing. They can even be run on multiple computers with different configurations. Automated tests perform the same steps precisely every time they are executed and never forget to record detailed results. Adobe. compare the results to the expected behavior and report the success or failure of these manual tests to a test engineer. 6. What makes automated software testing so important to these successful companies? 4. . Every time source code is modified software tests should be repeated. AutomatedQA‘s TestComplete is affordable enough for single developer shops and yet powerful enough that our customer list includes some of the largest and most respected companies in the world. Once created. Automated software testing can increase the depth and scope of tests to help improve software quality. efficiency and coverage of your software testing. Automated software testing is the best way to increase the effectiveness. automated tests can be run over and over again at no additional cost and they are much faster than manual tests. Once automated tests are created they can easily be repeated and they can be extended to perform tasks impossible with manual testing. A time savings that translates directly into cost savings. McDonalds. comparing the results to the expected behavior and recording their observations. yet delivered software always has defects. Manual software testing is performed by a human sitting in front of a computer carefully going through application screens. even with the best manual testing processes. Test engineers strive to catch them before the product is released but they always creep in and they often reappear. Lengthy tests that are often avoided during manual testing can be run unattended. Automated software testing can look inside an application and see memory contents. Motorola. Automated Software Testing Saves Time and Money 5. 8. Manually repeating these tests is costly and time consuming. Manual tests are repeated often during development cycles for source code changes and other situations like multiple operating environments and hardware configurations. Automated software testing has long been considered critical for big software development organizations but is often thought to be too expensive or difficult for smaller companies to implement.

Tests can run automatically whenever source code changes are checked in and notify the team or the developer if they fail. . hundreds or thousands of virtual users interacting with network or web software and applications. it is absolutely imperative that you develop and maintain a document that clearly outlines the project milestones and major activities required to implement your project. This is hard to measure but we‘ve experienced it first hand.Testers freed from repetitive manual tests have more time to create new automated software tests and deal with complex features. 14. 16. Team members improve their skill sets and confidence and. and the owner of each. Automated Software Testing Helps Developers and Testers 13. Automated Software Testing Does What Manual Testing Cannot 11. Automated testing can simulate tens. in turn. This document needs to include the date each milestone or major activity is to be completed. Shared automated tests can be used by developers to catch problems quickly before sending to QA. pass those gains on to their organization. Even the largest software departments cannot perform a controlled web application test with thousands of users. 12. 10. Your project plan also needs to be created at the beginning of the project. Automating repetitive tasks with automated software testing gives your team time to spend on more challenging and rewarding projects. THEORY: Introduction: Whether you call it a project plan or a project timeline. and a baseline version approved by the team as soon as possible. Automated Software Testing Improves Team Morale 15. TestComplete is a Powerful and Affordable Automated Software Testing Tool. Features like these save developers time and increase their confidence. PRACTICAL NO: 12 AIM: To study Microsoft Project Plan. automated software testing can improve team morale.

After you have fleshed out your draft with your core team. Take some time and really think through what you know about the objective of your project. That way you aren't standing there looking crazy. it is important that you create a draft of the activities you think may need to be tracked via a formal document.And trust me. You'll be surprised how good a draft you can develop if you put in a little effort. If the actual completion date differs from your baseline date at anytime. . You can even have a few informal meetings with knowledgeable individuals you can use as a sounding board to make sure you aren't completely off base. trying to go through the crevices of your memory. Any tasks that need to happen before other tasks can begin. If you don't make some level of effort to develop a rough draft. Percent complete of each task. and some other SMEs that may not be a part of your team. and why. you should give the document a baseline status. if any. With this draft you will be able to speak with subject matter experts (SMEs) and stakeholders to flesh out the project plan.Although you will probably not know all of the major activities required to implement your project in the beginning. The actual date the task was completed. you may give a bad impression which will make it harder for you to obtain the support of the persons you need to implement the project. You should document the actual date your project activities are completed. When the task should finish. someone will ask. after it achieves baseline status. You or the Project Sponsor you represent may decide to track or maintain more than what has been outlined above in your project plan. A few key items to include in your timeline are:         A unique ID that your team can reference when giving an update. When the task should start. The name of the task. It is also a good idea to notate where things are deleted or added. and a good foundation to build upon. Look at some historical data from similar projects. This is absolutely fine. These are just the items I have found to be vital. you'll still have documented the date it was supposed to be completed for historical purposes. The owner of the task. Your timeline project plan should not undergo many edits. when someone asks you why something you deleted isn't in the document.

Enter your start date in the Start date box. Communicate and present project information. do yourself and your project team a favour. Microsoft Project also provides functionality that allows the user to create reports that communicate the status and progress of a project. 2d . modelling your project schedule. 4. Furthermore. as well as cost information. enter each task. Save the Project file by clicking Save and specifying a project name. Create a new project file by clicking on New in the File menu. Enter durations by clicking on the Duration field. 5. Choose Blank Project. 2. Microsoft Project can help you facilitate all processes in the project management life cycle.It is completely possible to run a project without a project plan or timeline. The program allows users to:    Understand and control project schedules and finances. and you'll be that much closer to a well managed project. project management standards can be established and disseminated throughout your enterprise. How to Create a Project Plan in Microsoft Project The basic steps of creating and working with a project plan in Microsoft Project (which are saved as MPP files) is as follows: 1. The small letter "d" represents days. keep up with the status. 3. Now the project manager can plan the steps of the project. In the Task Name field. So. including details such as milestones. from developing your scope. What is Microsoft Project? Microsoft Office Project is a software application sold by Microsoft that provides project management tools to manage projects. called tasks. and tracking and communicating progress to saving knowledge gained from the closed project. Go to View | Gantt Chart. Document milestones and important tasks. with Microsoft Office Project Professional 2003. Overview of Microsoft Project Microsoft Project allows the project manager to enter the tasks of a project (also known as the "work breakdown structure" or WBS) and assign workers (known as "resources") to those tasks. it's just not very smart. Organize work and people to make sure that projects are completed on schedule. Set a project start date by choosing Project | Project Information.

8. task type must be set in order for Project to lay out the schedule That task type may be duration. If the project plan was useful to the management of the project. or units. 6. but it can also include non-human entities. 11. Don‘t enter start and finish dates for the tasks. allow the Duration field to set these automatically. actual durations. resources. The upper bar represents the actual project status. select the task and click Task Information | Advanced. or costs. then select the task to which to assign a resource. 7. . Once the project has been approved.represents two days. work. Choose the task to be updated. Link tasks (for example. Individual tasks may also have their own type. choose View | Tracking Gantt. The project manager must now keep the project plan up to date through Microsoft Project. 9. either in the form percentage complete. The project manager can set a default task type in Tools | Options | Schedule. choose Report | Visual Reports. then choose Tools | Tracking | Update tasks. Click View | Resource Sheet. To close the project. Go to View | Gantt Chart. such as equipment or expenses. create a final report by the means in step 12. "this task must be done before that task") by selecting the tasks that are related and clicking the Link Tasks button on the toolbar. enter progress data. 10. enter all resources to be used in the project. Now the project manager is ready to set the project baseline in Microsoft Project. In the dialog box. this baseline can be fixed and used throughout the duration of the project to monitor how well project is tracking against expectations. the project manager may wish to create a template plan to use in the future. 12. create a resource pool from which to allocate resources to the project. A resource is typically a person. The lower bar in the chart is the baseline. Once resources are assigned. Designate a milestone by entering 0d duration. To view project progress in Microsoft Project. actual dates. Choose the Assign Resources button and in the dialog box choose the resource names and choose Assign. Next. To view the baseline against actual duration. Choose File | Save As | Template. or actual work. 13. In the Resource Name field. Now the project manager must assign resources to each task.

Mrs. Mrs. Payal Thakre 5. Sheetal Ugemuge . Amreen Khan 4. Ms. Ms.List of faculty engaging SOFTWARE ENGINEERING Practicals. Gauri Chaudhary 3. Gauri Dhopavkar 2. Ms. 1.