Software Engg Lab Manual 2011-12

7/31/2019 Software Engg Lab Manual 2011-12

1/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


2/61

YESHWANTRAO CHAVAN COLLEGE OF ENGINEERING

DEPARTMENT OF COMPUTER TECHNOLOGY

SIXTH SEMESTER Term II (2010-2011)

SOFTWARE ENGINEERRING MANUAL

INDEX

Sr.

No.

Practical Name

1 Introduction to Software Engineering fundamentals

2 Overview of UML and Introduction to Rational RoseInterface

3 To identify use cases and draw Use Case diagram for thegiven case study.

4 To create use case documents for the given case study.

5 To study Software Requirement Specification template

6 Detailed analysis and design of Mini Project(SRS)

7 To study E-R Diagram and Data Flow Diagrams.

8 To draw Use Case Diagram and E-R diagram for Miniproject.

9 To study and draw UML Class diagrams.

10 To study and draw Activity diagrams.

BEYOND SYLLABUS:

1 To study Manual/Automated testing.

2 To study Microsoft Project Plan.


3/61

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. Thereis 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 softwareengineering), 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 anew 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 classicalsense.Although some similarities exist between software development and hardware manufacture,

the two activities are fundamentally different. In both activities, high quality is achieved throughgood 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 activitiesrequire 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 itslife (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


4/61

from the cumulative effects of dust, vibration, abuse, temperature extremes, and many other

environmental maladies. Stated simply, the hardware begins to wear out.Software is not susceptible to the environmental maladies that cause hardware to wear

out. In theory, therefore, the failure rate curve for software should take the form of the idealized

curve shown in Figure 2. Undiscovered defects will cause high failure rates early in the life of a

program. However, these are corrected (ideally, without introducing other errors) and the curveflattens as shown. The idealized curve is a gross oversimplification of actual failure models for

software. However, the implication is clearsoftware doesn't wear out. But it does deteriorate!

This seeming contradiction can best be explained by considering the actual curve shown inFigure 2. During its life, software will undergo change (maintenance).

As changes are made, it is likely that some new defects will be introduced, causing the

failure rate curve to spike as shown in Figure 2. Before the curve can return to the originalsteady-state failure rate, another change is requested, causing the curve to spike again. Slowly,

the minimum failure rate level begins to risethe software is deteriorating due to change.

Another aspect of wear illustrates the difference between hardware and software. When a

hardware component wears out, it is replaced by a spare part. There are no software spare parts.

Every software failure indicates an error in design or in the process through which design wastranslated into machine executable code. Therefore, software maintenance involves considerably

more complexity than hardware maintenance.

FIGURE 1. Failure curve for hardware FIGURE 2. Idealized and actual failure curves for

Software

III. Although the industry is moving toward component-based assembly, mostsoftware continues to be custom built.

Consider the manner in which the control hardware for a computer-based product is

designed and built. The design engineer draws a simple schematic of the digital circuitry, does

some fundamental analysis to assure that proper function will be achieved, and then goes to the

shelf where catalogs of digital components exist. Each integrated circuit (called an ICor a chip)has a part number, a defined and validated function, a well defined interface, and a standard set

of integration guidelines. After each component is selected, it can be ordered off the shelf.As an engineering discipline evolves, a collection of standard design components is

created. 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 newsystems. The reusable components have been created so that the engineer can concentrate on the

truly innovative elements of a design, that is, the parts of the design that represent something


5/61

new. In the hardware world, component reuse is a natural part of the engineering process. In the

software world, it is something that has only begun to be achieved on a broad scale.A software component should be designed and implemented so that it can be reused in

many different programs. In the 1960s, we built scientific subroutine libraries that were reusable

in a broad array of engineering and scientific applications. These subroutine libraries reused well

defined algorithms in an effective manner but had a limited domain of application. Today, wehave extended our view of reuse to encompass not only algorithms but also data structure.

Modern reusable components encapsulate both data and the processing applied to the data,

enabling the software engineer to create new applications from reusable parts. For example,today's graphical user interfaces are built using reusable components that enable the creation of

graphics windows, pull-down menus, and a wide variety of interaction mechanisms. The data

structure and processing detail required to build the interface are contained with a library ofreusable components for interface construction.Most software continues to be custom built.

IV. Software Applications:

Software may be applied in any situation for which a prespecified set of procedural steps

(i.e., an algorithm) has been defined (notable exceptions to this rule are expert system software

and neural network software). Information content and determinacy are important factors indetermining the nature of a software application. Content refers to the meaning and form of

incoming and outgoing information. For example, many business applications use highly

structured input data (a database) and produce formatted reports. Software that controls anautomated machine (e.g., a numerical control) accepts discrete data items with limited structure

and produces individual machine commands in rapid succession.

Information determinacy refers to the predictability of the order and timing of

information. An engineering analysis program accepts data that have a predefined order,executes the analysis algorithm(s) without interruption, and produces resultant data in report or

graphical format. Such applications are determinate. A multiuser operating system, on the otherhand, accepts inputs that have varied content and arbitrary timing, executes algorithms that can

be interrupted by external conditions, and produces output that varies as a function of

environment and time. Applications with these characteristics are indeterminate. It is somewhat

difficult to develop meaningful generic categories for software applications. As softwarecomplexity grows, neat compartmentalization disappears. The following software areas indicate

the breadth of potential applications:

1) System software. System software is a collection of programs written to service other

programs. Some system software (e.g., compilers, editors, and file management utilities)process complex, but determinate, information structures. Other systems applications

(e.g., operating system components, drivers, telecommunications processors) processlargely indeterminate data. In either case, the system software area is characterized by

heavy interaction with computer hardware; heavy usage by multiple users; concurrent

operation that requires scheduling, resource sharing, and sophisticated processmanagement; complex data structures; and multiple external interfaces.


6/61

2) Real-time software. Software that monitors/analyzes/controls real-world events as theyoccur is called real time. Elements of real-time software include a data gatheringcomponent that collects and formats information from an external environment, an

analysis component that transforms information as required by the application, a

control/output component that responds to the external environment, and a monitoring

component that coordinates all other components so that real-time response (typicallyranging from 1 millisecond to 1 second) can be maintained.

3) Business software. Business information processing is the largest single softwareapplication area. Discrete "systems" (e.g., payroll, accounts receivable/payable,inventory) have evolved into management information system (MIS) software that

accesses one or more large databases containing business information. Applications in

this area restructure existing data in a way that facilitates business operations ormanagement decision making. In addition to conventional data processing application,

business software applications also encompass interactive computing (e.g., point of- sale

transaction processing).

4) Engineering and scientific software. Engineering and scientific software have been

characterized by "number crunching" algorithms. Applications range from astronomy tovolcanology, from automotive stress analysis to space shuttle orbital dynamics, and from

molecular biology to automated manufacturing. However, modern applications within theengineering/scientific area are moving away from conventional numerical algorithms.

Computer-aided design, system simulation, and other interactive applications have begun

to take on real-time and even system software characteristics.

5) Embedded software. Intelligent products have become commonplace in nearly everyconsumer and industrial market. Embedded software resides in read-only memory and is

used to control products and systems for the consumer and industrial markets. Embedded

software can perform very limited and esoteric functions (e.g., keypad control for amicrowave oven) or provide significant function and control capability (e.g., digital

functions in an automobile such as fuel control, dashboard displays, and braking

systems).

6) Personal computer software. The personal computer software market has burgeonedover the past two decades. Word processing, spreadsheets, computer graphics,

multimedia, entertainment, database management, personal and business financial

applications, external network, and database access are only a few of hundreds ofapplications.

7) Web-based software. The Web pages retrieved by a browser are software thatincorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g.,hypertext and a variety of visual and audio formats). In essence, the network becomes a

massive computer providing an almost unlimited software resource that can be accessed

by anyone with a modem.

8) Artificial intelligence software. Artificial intelligence (AI) software makes use ofnonnumeric algorithms to solve complex problems that are not amenable to computation

or straightforward analysis. Expert systems, also called knowledge based systems, pattern

recognition (image and voice), artificial neural networks, theorem proving, and game

playing are representative of applications within this category.


7/61

How do we definesoftware engineering?

A definition proposed by Fritz Bauer [Software engineering is] the establishment and use ofsound 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, disciplined, quantifiable approach to thedevelopment, operation, and maintenance of software; that is, the application of engineering to

software. (2) The study of approaches as in (1).

V. SOFTWARE ENGINEERING: A LAYERED TECHNOLOGY:

Software engineering is a layered technology, any engineering approach (including

software engineering) must rest on an organizational commitment to quality. Total quality

management and similar philosophies foster a continuous process improvement culture, and this

culture ultimately leads to the development of increasingly more mature approaches to softwareengineering. The bedrock that supports software engineering is a quality focus.

The foundation for software engineering is theprocess layer. Software engineering process is theglue that holds the technology layers together and enables rational and timely development of

computer software. Process defines a framework for a set ofkey process areas (KPAs) [PAU93]that must be established for effective delivery of software engineering technology. The key

process areas form the basis for management control of software projects and establish the

context in which technical methods are applied, work products (models, documents, data,reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is

properly managed.

Software engineering methods provide the technical how-to's for building software.Methods encompass a broad array of tasks that include requirements analysis, design, program

construction, testing, and support. Software engineering methods rely on a set of basic principlesthat govern each area of the technology and include modeling activities and other descriptivetechniques.

Software engineering tools provide automated or semi-automated support for the processand the methods. When tools are integrated so that information created by one tool can be used

by another, a system for the support of software development, called computer-aided softwareengineering, is established. CASE combines software, hardware, and a software engineering

database (a repository containing important information about analysis, design, programconstruction, and testing) to create a software engineering environment analogous to CAD/CAE

(computer-aided design/engineering) for hardware.

Software engineering layers


8/61


9/61

After creating these models, we can show them to all interested parties, and those parties

can glean the information they find valuable from the model. For example, users can visualizethe interactions they will make with the system from looking at a model. Analysts can visualize

the interactions between objects from the models. Developers can visualize the objects that need

to be developed and what each one needs to accomplish. Testers can visualize the interactions

between objects and prepare test cases based on these interactions. Project managers can see thewhole system and how the parts interact. And chief information

Officers can look at highlevel models and see how systems in their organization interact with

one another. All in all, visual models provide a powerful tool for showing the proposed system toall of the interested parties.

Systems of Graphical Notation

One important consideration in visual modeling is what graphical notation to use to

represent various aspects of a system. Many people have proposed notations for visual modeling.

Some of the popular notations that have strong support areBooch, Object Modeling Technology

(OMT), and UML. Rational Rose supports these three notations; however, 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).

Booch Notation:

The Booch method is named for its inventor, Grady Booch, at Rational SoftwareCorporation. He has written several books discussing the needs and benefits of visual modeling,

and has developed a notation of graphical symbols to represent various aspects of a model. For

example, objects in this notation are represented by clouds, illustrating the fact that objects can

be almost anything. Booch's notation also includes various arrows to represent the types ofrelationships between objects. Figure 1is a sampling of the objects and relationships represented

in the Booch notation.


10/61


11/61

Figure 1.2: Examples of symbols in the OMT notation

Unified Modeling Language (UML):

UML notation comes from a collaborative effort of Grady Booch, Dr. James Rumbaugh,

Ivar Jacobson, Rebecca WirfsBrock, Peter Yourdon, and many others. Jacobson is a scholarwho has written about capturing system requirements in packages of transactions called use

cases. We will discuss use cases in detail in Chapter 4. Jacobson also developed a method forsystem design called ObjectOriented SoftwareEngineering (OOSE) that focused on analysis.Booch, Rumbaugh, and Jacobson, commonly referred to as the "three amigos," all work at

Rational Software Corporation and focus on the standardization and refinement of UML. UML

symbols closely match those of the Booch and OMT notations, and also include elements fromother notations. Figure 1.3. Shows a sample of UML notation.


12/61

Figure 1.3: Examples of symbols in UML notation

Each of the three amigos of UML began to incorporate ideas from the other

methodologies. Official unification of the methodologies continued until late 1995, when version0.8 of the Unified Method was introduced. The Unified Method was refined and changed to the

Unified Modeling Language in 1996. UML 1.0 was ratified and given to the Object Technology

Group in 1997, and many major software development companies began adopting it. In 1997,OMG released UML 1.1 as an industry standard. Over the past years, UML has evolved to

incorporate new ideas such as webbased systems and data modeling. The latest release is UML

1.3, which was ratified in 2000. The specification for UML 1.3 can be found at the Object

Management Group's website, http://www.omg.org/.

Types of UML DiagramsEach UML diagram is designed to let developers and customers view a software system from a

different perspective and in varying degrees of abstraction. UML diagrams commonly created invisual modeling tools include:

Use Case Diagramdisplays the relationship among actors and use cases.

Class Diagram models class structure and contents using design elements such as classes,packages and objects. It also displays relationships such as containment, inheritance, associations

and others.

Interaction Diagrams

Sequence Diagramdisplays the time sequence of the objects participating in theinteraction. This consists of the vertical dimension (time) and horizontal

dimension (different objects)

Collaboration Diagramdisplays an interaction organized around the objects andtheir links to one another. Numbers are used to show the sequence of messages.
http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/interaction.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/interaction.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/interaction.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/interaction.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm


13/61

State Diagram displays the sequences of states that an object of an interaction goes through

during its life in response to received stimuli, together with its responses and actions.

Activity Diagramdisplays 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. This

diagram focuses on flows driven by internal processing

Physical Diagrams

Component Diagram displays the high level packaged structure of the codeitself. Dependencies among components are shown, including source code

components, binary code components, and executable components. Some

components exist at compile time, at link time, at run times well as at more than

one time.

Deployment Diagramdisplays the configuration of run-time processing elements

and the software components, processes, and objects that live on them. Software

component instances represent run-time manifestations of code units

UML Diagram ClassificationStatic, Dynamic, and Implementation

A software system can be said to have two distinct characteristics: a structural, "static" part and abehavioral, "dynamic" part. In addition to these two characteristics, an additional characteristic

that a software system possesses is related to implementation. Before we categorize UMLdiagrams into each of these three characteristics, let us take a quick look at exactly what these

characteristics are.

Static: The static characteristic of a system is essentially the structural aspect of the

system. The static characteristics define what parts the system is made up of. Dynamic: The behavioral features of a system; for example, the ways a system behaves

in response to certain events or actions are the dynamic characteristics of a system.

Implementation: The implementation characteristic of a system is an entirely new

feature that describes the different elements required for deploying a system.

The UML diagrams that fall under each of these categories are:

Static

o Use case diagram

o Class diagram

Dynamico State diagram

o Activity diagram

o Sequence diagram

o Collaboration diagram

Implementation

o Component diagram

o Deployment diagram
http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/state.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/state.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/physical.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/physical.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/physical.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htmhttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/state.htm


14/61

Finally, let us take a look at the 4+1 view of UML diagrams.

4+1 View of UML Diagrams

Considering that the UML diagrams can be used in different stages in the life cycle of a system.

The 4+1 view offers a different perspective to classify and apply UML diagrams. The 4+1 viewis essentially how a system can be viewed from a software life cycle perspective. Each of theseviews represents how a system can be modeled. This will enable us to understand where exactly

the UML diagrams fit in and their applicability.

These different views are:

Design View: The design view of a system is the structural view of the system. This

gives an idea of what a given system is made up of. Class diagrams and object

diagrams form the design view of the system.

Process View: The dynamic behavior of a system can be seen using the process view.The different diagrams such as the state diagram, activity diagram, sequence diagram,

and collaboration diagram are used in this view.

Component View: Next, you have the component view that shows the grouped

modules of a given system modeled using the component diagram.

Deployment View: The deployment diagram of UML is used to identify the

deployment modules for a given system. This is the deployment view of the system.

Use case View: Finally, we have the use case view. Use case diagrams of UML are

used to view a system from this perspective as a set of discrete activities or

transactions.


15/61

UML diagrams for case study:

1. Use case diagram

2.Sequence Diagram for the Add a Course Scenario


16/61


17/61

3.Main Class Diagram for the University Artifacts Package

4.Course Reporting Class Diagram in the University Artifacts Package


18/61

5. 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. In much the same way a theatrical director blocks out a play, a software designer

uses Rational Rose to visually create (model) the framework for an application by blocking out


19/61

classes with actors (stick figures), use case elements (ovals), objects (rectangles) and

messages/relationships (arrows) in a sequence diagram using drag-and-drop symbols. Rational

Rose documents the diagram as it is being constructed and then generates code in the designer's

choice of C++, Visual Basic, Java, Oracle8, CORBA or Data Definition Language.

Rational Rose is commercial case-tool software. It supports two essential elements ofmodern software engineering: component based development and controlled iterative

development. Models created with Rose can be visualized with several UML diagrams. Rosealso supports Round-Trip engineering with several lan4guages.

Two popular features of Rational Rose are its ability to provide iterative development and

round-trip engineering. 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. (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.) Then, as the developer begins to understand how the componentsinteract and makes modifications in the design, Rational Rose can perform what is called "round-

trip engineering" by going back and updating the rest of the model to ensure the code remains

consistent.

Summary of the Rational Rose

Positive factors

The tool itself was quite easy to install.

The creation of the different diagrams can be learned quite fast.

Code generation is simple.

C++ Analyzer was also easy to use (though its functionality could be included in the

Rose itself)Negative factors

At first the tool seems to be quite complex.

Some minor bugs were found.

Separate tool had to be used (and learned) to reverse-engineer files.

Layout manager could have been a bit more effective.

Generated code was a bit obfuscated.

ROSE is Rational Object Oriented Software Engineering. Rational Rose is a set of visual

modeling tools for development of object oriented software. Rose uses the UML to provide

graphical methods for non-programmers wanting to model business processes as well asprogrammers modeling application logic. Rational Rose includes tools for reverse engineering

as well as forward engineering of classes and component architectures. You can gain valuable

insights to your actual constructed architecture and pinpoint deviations from the original design.Rose offers a fast way for clients and new employees to become familiar with system internals.

RATIONAL ROSE INTERFACE:

Parts of the Screen:


20/61

The five primary pieces of the Rose interface are the browser, the documentation window, the

toolbars, the diagram window, and the log. In this section, we'll look at each of these. Briefly,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 commandsDiagram window Used to display and edit one or more UML diagrams

Log Used to view errors and report the results of various commands


21/61

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. Business analysts can use

Rational Rose to model and visualize business processes and highlight opportunities to increase

efficiency. Data analysts can model database designs in Rational Rose, improving their

communication with developers. And when you model Use Cases in Rational Rose, you can be

sure your solution is being built for the user. Rational Rose unifies business, systems and dataanalysts by enabling them to create and manage models in one tool with one modeling language.

Use Cases

A use case is a scenario that describes the use of a system by an actor to accomplish a specificgoal. What does this mean? An actor is a user playing a role with respect to the system. Actors

are generally people although other computer systems may be actors. A scenario is a sequence of

steps that describe the interactions between an actor and the system. The use case model consists

of the collection of all actors and all use cases. 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 anothersystem

An individual use case represents a task to be done with support from the system (thus it

is a coherent unit of functionality)


22/61

The rectangle represents the system boundary, the stick figures represent the actors (users

of the system), and the ovals represent the individual use cases. Unfortunately, thisnotation tells us very little about the actual functionality of the system. Use case is

actually defined as text, including descriptions of all of the normal and exception

behaviour expected. They do not reveal the structure of the system (i.e. the system

does), collectively define the boundaries of the system to be implemented and providethe basis for defining development iterations (Use language of user).

Creating Use-case in Rational Rose:

Use Case View: Capturing Some Requirements

Expand the Use Case View and double click onMain to open the use case diagram window to

get:

Using the toolbar, insert the use cases and actors into the main use case diagram to get:


23/61

Next, using the Unidirectional Association button on the toolbar to establish the following

associations between the actors and use cases.

1. Open Rational Rose, Start --> Programs --> Programming Tools -->Rational Suite

Development Studio -->Rational Rose Enterprise Edition

2. You will be presented with a Create Model Screen, Cancel that and you will see something

like this.


24/61

You cancel the Create Model screen since you are not creating any particular type of model.

However once you have a model, you can open an existing model by selecting Existing tab

from Create New Model screen.

3. Now since you are only interested in creating Use Cases, you would create a new Use Case

by right clicking on Use Case View, selecting New and then Use Case from the list ofoptions (Make sure that you dont select the Use Case Diagram option). Additional informationabout Use Case View package can be entered in Open Specification option.

4. Once you have opened a Use Case, enter Enter System as the name for the Use Case andthen right click on it, select Open Specification. Enter the brief description of the Use Case in

the Documentation area of the specification. Click Ok.

5. Once the specification is filled out, you can add any type of diagram to this particular Use

Case. You can add Class Diagram, Use Case Diagram, Activity Diagram, State Diagram, etc.

Here as an example, 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.

6. To add a Use Case diagram, right click on the use case name Enter System and select NewUse Case Diagram. White diagram sheet with its associated toolbox would appear in right frame.

Let us name this use case diagram as Login. If a diagram sheet does not appear then double-

click on the newly created Use case diagram.

7. Optional Step:

If the symbol for drawing an actor does not appear on the toolbar (situated vertically in the

middle of the screen), right click on the toolbar and click on the Customize link. The list box onthe left contains the actor entity. Add it to the right hand side and click Close. Additionally all

missing components can be added using the customize menu.

8. Next step is to draw the diagram. Select an actor and a Use case from the toolbox.

Relationships among Use Cases

1. As mentioned earlier you can have multiple use cases. Now you may want to specifyrelationships between those use cases. 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. An include relationship specifies how behaviour in the inclusion use caseis used by the base use case

Extends: An extend relationship is a stereotyped relationship that specifies how thefunctionality of one use case can be inserted into the functionality of another use case.

Refine: A refine relationship is a stereotyped relationship that connects two or more model

elements at different semantic levels or development stages.


25/61

Relations:

Association Relationship:

An association provides a pathway for communication. The communication can be between use

cases, actors, classes or interfaces. Associations are the most general of all relationships andconsequentially the most semantically weak. If two objects are usually considered independently,

the relationship is an association

By default, 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 end with the arrow indicates who or what is

receiving the communication.

Bi-directional association:

If you prefer, you can also customize the toolbox to include the bi-directional tool to the use-case

toolbox.


26/61

Course Registration System Use-Case Model Main Diagram


27/61

PRACTICAL NO: 4

AIM: To create use case documents for the given casestudy.

THEORY:

Use cases for case study:

(Samples)

1. Login

1.1 Brief Description

This use case describes how a user logs into the Course Registration System.

1.2 Flow of Events

1.2.1 Basic Flow

This use case starts when the actor wishes to log into the Course Registration System.

1. The system requests that the actor enter his/her name and password.

2. The actor enters his/her name and password.

3. The system validates the entered name and password and logs the actor into the system.

1.2.2 Alternative Flows

1.2.2.1 Invalid Name/Password

If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error

message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at

which point the use case ends.

1.3 Special Requirements

None.

1.4 Pre-Conditions

None.

1.5 Post-Conditions

If the use case was successful, the actor is now logged into the system. If not, the system state is

unchanged.

1.6 Extension Points


28/61

None.

2. Register for Courses

2.1 Brief Description

This use case allows a Student to register for course offerings in the current semester. The Student can also

update or delete course selections if changes are made within the add/drop period at the beginning of the

semester. The Course Catalog System provides a list of all the course offerings for the current semester.

2.2 Flow of Events

2.2.1 Basic Flow

This use case starts when a Student wishes to register for course offerings, or to change his/her existing

course schedule.

1. The system requests that the Student specify the function he/she would like to perform (either Create a

Schedule, Update a Schedule, or Delete a Schedule).

2. Once the Student provides the requested information, one of the sub flows is executed. If the Registrarselected Create a Schedule, the Create a Schedule subflow is executed. If the Registrar selected Update

a Schedule, the Update a Schedule subflow is executed. If the Registrar selected Delete a Schedule, the

Delete a Schedule subflow is executed.

2.2.1.1 Create a Schedule

1. The system retrieves a list of available course offerings from the Course Catalog System and displays the

list to the Student.

2. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of available

offerings.

3. Once the student has made his/her selections, the system creates a schedule for the Student containing

the selected course offerings.

4. The Submit Schedule subflow is executed.

2.2.1.2 Update a Schedule

1. The system retrieves and displays the Students current schedule (e.g., the schedule for the current

semester).

2. The system retrieves a list of available course offerings from the Course Catalog System and displays the

list to the Student.

3. The Student may update the course selections on the current selection by deleting and adding new course

offerings. The Student selects the course offerings to add from the list of available course offerings. The

Student also selects any course offerings to delete from the existing schedule.

4. Once the student has made his/her selections, the system updates the schedule for the Student using the

selected course offerings.

5. The Submit Schedule subflow is executed.

2.2.1.3 Delete a Schedule

1. The system retrieves and displays the Students current schedule (e.g., the schedule for the current

semester).

2. The system prompts the Student to confirm the deletion of the schedule.

3. The Student verifies the deletion.


29/61

4. The system deletes the Schedule. If the schedule contains enrolled in course offerings, the Student

must be removed from the course offering.

2.2.1.4 Submit Schedule

For each selected course offering on the schedule not already marked as enrolled in, the system verifies

that the Student has the necessary prerequisites, that the course offering is open, and that there are no

schedule conflicts. The system then adds the Student to the selected course offering. The course offering

is marked as enrolled in in the schedule.

The schedule is saved in the system.

2.2.2 AlternativeFlows

2.2.2.1 Save a Schedule

At any point, the Student may choose to save a schedule rather than submitting it. If this occurs, the Submit

Schedule step is replaced with the following:

The course offerings not marked as enrolled in are marked as selected in the schedule.

The schedule is saved in the system.

2.2.2.2 Unfulfilled Prerequisites, Course Full, or Schedule Conflicts

If, in the Submit Schedule sub-flow, the system determines that the Student has not satisfied the necessary

prerequisites, or that the selected course offering is full, or that there are schedule conflicts, an error

message is displayed. The Student can either select a different course offering and the use case continues,

save the schedule, as is (see Save a Schedule subflow), or cancel the operation, at which point the Basic

Flow is re-started at the beginning.

2.2.2.3 No Schedule Found

If, in the Update a Schedule or Delete a Schedule sub-flows, the system is unable to retrieve the Students

schedule, an error message is displayed. The Student acknowledges the error, and the Basic Flow is re-

started at the beginning.

2.2.2.4 Course Catalog System Unavailable

If the system is unable to communicate with the Course Catalog System, the system will display an error

message to the Student. The Student acknowledges the error message, and the use case terminates.

2.2.2.5 Course Registration Closed

When the use case starts, if it is determined that registration for the current semester has been closed, a

message is displayed to the Student, and the use case terminates. Students cannot register for courseofferings after registration for the current semester has been closed.

2.2.2.6 Delete Cancelled

If, in the Delete A Schedule sub-flow, the Student decides not to delete the schedule, the delete is

cancelled, and the Basic Flow is re-started at the beginning.

2.3 Special Requirements


30/61

None.

2.4 Pre-Conditions

The Student must be logged onto the system before this use case begins.

PRACTICAL NO: 5

AIM: To study Software Requirement Specification

template.

THEORY:

Student Course Registration System

REQUIREMENTS REPORT

CENG XXX Fall 2001

October xx, 20XX

Aye GzelMehmet Gl


31/61

Computer Engineering Department

Middle East Technical University


32/61

Student Course Registration System

Requirements Analysis Reportdate

1. Introduction1.1 Purpose of this Document

1.2 Scope of this Document

1.3 Overview1.4 Business Content

2. General Description2.1 Product Functions

2.2 Similar System(s) Information2.3 User Characteristics

2.4 User Problem Statement2.5 User Objectives

2.6 General Constraints3.Functional Requirements

Descriptions about what the system should accomplishnot how.

3.1 Registration {Top level functions are called: Capability}

Description about the top-level system function (Capability).

USE CASE DIAGRAM

3.1.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.

Then comes numbered requirements: One sentence each!3.1.1.1 Every student has a Username

3.1.1.2 Usernames are uniqueIEEE suggests every requirement to come with (include only if appropriate):

1.Description

2.Criticality

3.Technical issues4.Cost and schedule

5.Risks

6.Dependencies with other requirements7.Others as appropriate

3.1.2 Student Authentication


33/61

4.Interface Requirements

4.1 User Interfaces

4.1.1 GUI {Screen Dumps}

4.1.2 Command Line Interface

4.1.3 Application Programming Int.

4.1.4 Diagnostic interface

4.2 Hardware Interfaces

4.3 Communications Interfaces

4.4 Software Interfaces5.Performance Requirements

6.Design Constraints6.1 Standards Compliance

7.Other Non Functional Attributes1.Security

2.Binary Compatibility

3.Reliability4.Maintainability

5.Portability

6.Extensibility

7.Reusability

8.Appl. Affinity/compatibility

9.Resource Utilization

10.Serviceability

11. --- others ---

8.Preliminary Object-Oriented Analysis8.1 Inheritance Relationships

8.2 Class Descriptions

IEEE Suggests each class to be described as:8.2.1 Student

8.2.1.1 Abstract or Concrete:

8.2.1.2 List of Superclasses:

8.2.1.3 List of Subclasses:

8.2.1.4 Purpose:

8.2.1.5 Collaborations: {other classes}

8.2.1.6 Attributes:

8.2.1.7 Operations:

8.2.1.8 Constraints: {on general state and behavior}

9.Operational Scenarios {A proposed specific use}

10.Preliminary Schedule

11.Preliminary Budget

12.Appendices12.1 Definitions, Acronyms, Abbreviations

12.2 References

-- others --

{NOTE: Titles have to be written, even if there is nothing to write under}


34/61

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


35/61

AIM: To study E-R Diagram and Data Flow Diagrams.

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. They also set the stage for the design of

databases later on in the SDLC.

There are three basic elements in ER models:

Entities are the "things" about which we seek information.

Attributes are the data we collect about the entities.

Relationships provide the structure needed to draw information from multiple entities.

Generally, ERD's look likes this:

Developing an ERD.

Developing an ERD requires an understanding of the system and its components.


36/61

Consider a hospital:

Patients are treated in a single ward by the doctors assigned to them. Usually each patient

will be assigned a single doctor, but in rare cases they will have two.

Healthcare assistants also attend to the patients, a number of these are associated with

each ward.

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.

The system must record details concerning patient treatment and staff payment. Some

staff is paid part time and doctors and care assistants work varying amounts of overtime

at varying rates (subject to grade).

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).

How do we start an ERD?

1. Define Entities: these are usually nouns used in descriptions of the system, in thediscussion of business rules, or in documentation; identified in the narrative (see

highlighted items above).

2. Define Relationships: these are usually verbs used in descriptions of the system or in

discussion of the business rules (entity ______ entity); identified in the narrative.


37/61

3. Add attributes to the relations; these are determined by the queries, and may also suggest

new entities, e.g. grade; or they may suggest the need for keys or identifiers.

What questions can we ask?

a. Which doctors work in which wards?

b. How much will be spent in a ward in a given week?

c. How much will a patient cost to treat?

d. How much does a doctor cost per week?

e. Which assistants can a patient expect to see?

f. Which drugs are being used?

4. Add cardinality to the relations.

Many-to-Many must be resolved to two one-to-many with an additional entity

Usually automatically happens. Sometimes involves introduction of a link entity (which

will be all foreign key) Examples: Patient-Drug.

5. This flexibility allows us to consider a variety of questions such as:

a. Which beds are free?b. Which assistants work for Dr. X?

c. What is the least expensive prescription?

d. How many doctors are there in the hospital?

e. Which patients are families related?

6. Represent that information with symbols. Generally E-R Diagrams require the useof the following symbols:

Reading an ERD

It takes some practice reading an ERD, but they can be used with clients to discussbusiness rules. These allow us to represent the information from above such as the E-R

Diagram below:


38/61

ERD brings out issues:

1. Many-to-Many.

2. Ambiguities.

3. Entities and their relationships.

4. What data needs to be stored?

5. The Degree of a relationship.

Now, think about a university in terms of an ERD. What entities, relationships and

attributes might you consider? Look at this simplified view. There is also an example of a

simplified view of an airline on that page.

Data Flow Diagrams (DFD)

DFD provide a graphical notation for capturing the flow of data and operations involved in an

information system. However, they lack precise semantics. A prototype to test whether

specifications reflect the users expectations cannot be derived directly from a DFD since no

machine execution is possible without precise semantics for the notation. The syntax, i.e., way ofcomposing bubbles, arrows, and boxed is defined precisely, but the semantics of DFDs is not

specified precisely. (Therefore DFDs provide a semiformal notation for specifying systems).

Specification Styles

Informal specifications are written in a naturallanguage.Semi-formal specifications usea notation withprecise syntax but imprecise semantics. Formal specifications are writtenusing a notation that has precise syntax and semantics (meaning). Operationalspecifications describe the desired behavior of the system. Descriptive specifications state desiredproperties of the system.

Operational Specification

1. Data Flow Diagrams.

2. Finite State Machines.

3. Petri nets.

Descriptive Specification1. Entity-Relationship Diagrams.

2. Logic Specifications.

3. Algebraic Specifications.

External Entity Process Output
http://www.umsl.edu/~sauterv/analysis/er/ER.HTMhttp://www.umsl.edu/~sauterv/analysis/er/ER.HTM


39/61

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 formalismit 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 easilyunderstandany hierarchical model of asystembecause in a hierarchical model, starting with avery 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 DFDmodel 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 aand 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 mayor 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 ofname data.

=: represents equivalence, e.g. a=b+c means that a represents b and c.

/* */: Anything appearing within /* and */is considered as acomment.


40/61

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


41/61

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 formUML 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 UMLmodels. 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 canlearn 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 thestatic 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


42/61

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. Notice that each member variable is followed by a colon and by the

type of the variable. If the type is redundant, or otherwise unnecessary, it can be omitted. Notice

also that the return values follow the member functions in a similar fashion. Again, these can be

omitted. Finally, notice that the member function arguments are just types.

1. Composition Relationships:

The black diamond represents composition. It is placed on the Circle class because it is the

Circle that is composed of a Point. The arrowhead on the other end of the relationship denotes

that the relationship is navigable in only one direction. That is, Point does not know About

Circle. Composition relationships are a strong form of containment or aggregation. Composition

also indicates that the lifetime of Point is dependent upon Circle. This means that if Circle is

destroyed, Point will be destroyed with it.

2. Inheritance:

The inheritance relationship in UML is depicted by a peculiar triangular arrowhead. This

arrowhead, which looks rather like a slice of pizza, points to the base class. One or more lines

proceed from the base of the arrowhead connecting it to the derived classes.


43/61

Aggregation / Association:

The weak form of aggregation is denoted with an open diamond. This relationship denotes that

the aggregate class (the class with the white diamond touching it) is in some way the whole,

and the other class in the relationship is somehow part of that whole.

Aggregation

The Window class contains many Shape instances. In UML the ends of a relationship are

referred to as its roles. Notice that the role at the Shape end ofthe aggregation is marked with a

*. This indicates that the Window contains many Shape instances. Notice also that the role has

been named. It is the name of the instance variable within Window that holds all the Shapes. An

association is nothing but a line drawn between the participating classes. In Figure above the

association has an arrowhead to denote that Frame does not know anything about Window.

The difference between an aggregation and an association is one of implication.

Aggregation denotes whole/part relationships whereas associations do not. However, there is not

likely to be much difference in the way that the two relationships are implemented. That is, it

would be very difficult to look at the code and determine whether a particular relationship ought

to be aggregation or association. For this reason, it is pretty safe to ignore the aggregation

relationship altogether.


44/61

Association

How to construct a Class diagram in Rational Rose SE:


45/61


46/61


47/61

Class Diagram for the case study:


48/61

PRACTICAL NO: 10AIM: To study and draw Activity diagrams.

THEORY:

Activity Diagrams:

An activity diagram is a way to model the workflow of a use case in graphical form. The

diagram shows the steps in the workflow, the decision points in the workflow, who is responsible

for completing each step, and the objects that are affected by the workflow. An activity is simply

a step in the workflow. It is a task that a business worker performs. Within an activity, you can

list the actions that occur for that activity. Actions are simply steps within the activity.

The arrows connecting the activities are known as transitions. A transition lets you know

which activity is performed once the current activity has completed. We can place guard

conditions on the transitions to show when the transition occurs. Guard conditions are placed in

square brackets. In this example, the activity create rejection letter is only performed if the

guard condition missing documentation is true. The horizontal bars are called

synchronizations. They let you know that two or more activities occur simultaneously.

In Rose, you can use an activity diagram to model the workflow through a particular

business use case. The main elements on an activity diagram are:

_ Swimlanes, which show who is responsible for performing the tasks on the diagram.

_Activities, which are steps in the workflow.

_ Actions, which are steps within an activity. Actions may occur when entering the activity,

exiting the activity, while inside the activity, or upon a specific event.

_Business objects, which are entities affected by the workflow.

_ Transitions, which show how the workflow moves from one activity to another.

_Decision points, which show where a decision needs to be made during the workflow.

_ Synchronizations, which show when two or more steps in the workflow occur simultaneously.


49/61

_ The start state, which shows where the workflow begins.

_ The end state, which shows where the workflow ends.

Activity diagrams for the case study:


50/61


51/61


52/61

PRACTICAL NO: 11

AIM: To study Manual/Automated testing.

THEORY:

Manual testing is the oldest and most rigorous type of software testing. Manual testing

requires a tester to perform manual test operations on thetest softwarewithout the help of Test

automation. Manual testing is a laborious activity that requires the tester to possess a certain set

of qualities; to be patient, observant, speculative, creative, innovative, open-minded, resourceful

and skillful.

Manual testing.

Compare with Test automation.

Manual testing is the process of manually testing software for defects. It requires a tester to play

the role of an end user, and use most of all features of the application to ensure correctbehaviour. To ensure completeness of testing, the tester often follows a written test plan that

leads them through a set of important test cases.

1. Choose a high level test plan where a general methodology is chosen, and resources suchas people, computers, and software licenses are identified and acquired.

2. Write detailed test cases, identifying clear and concise steps to be taken by the tester,with expected outcomes.

3. Assign the test cases to testers, who manually follow the steps and record the results.4. Author a test report, detailing the findings of the testers. The report is used by managers

to determine whether the software can be released, and if not, it is used by engineers toidentify and correct the problems.

A rigorous test case based approach is often traditional for large software engineering projects

that follow a Waterfall model. However, 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 TestingTest automation is the technique of testing software using software rather than people. A

test program is written that exercises the software and identifies its defects. These test programs

may be written from scratch, or they may be written utilizing a generic Test automation

framework that can be purchased from a third party vendor. Test automation can be used to

automate the sometimes menial and time consuming task of following the steps of a use case andreporting the results.

Test automation may be able to reduce or eliminate the cost of actual testing. A computer

can follow a rote sequence of steps more quickly than a person, and it can run the tests overnight

to present the results in the morning. However, the labour that is saved in actual testing must bespent instead authoring the test program. Depending on the type of application to be tested, and

the automation tools that are chosen, this may require more labour than a manual approach. In

addition, some testing tools present a very large amount of data, potentially creating a time
http://www.onestoptesting.com/manual-testing/http://www.onestoptesting.com/manual-testing/http://www.onestoptesting.com/manual-testing/http://www.onestoptesting.com/manual-testing/http://en.wikipedia.org/wiki/Test_automationhttp://en.wikipedia.org/wiki/Test_automationhttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Test_planhttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Test_planhttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Test_automationhttp://en.wikipedia.org/wiki/Test_automation_frameworkhttp://en.wikipedia.org/wiki/Test_automation_frameworkhttp://en.wikipedia.org/wiki/Test_automation_frameworkhttp://en.wikipedia.org/wiki/Test_automation_frameworkhttp://en.wikipedia.org/wiki/Test_automationhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Test_planhttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Test_planhttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Test_automationhttp://www.onestoptesting.com/manual-testing/http://www.onestoptesting.com/manual-testing/


53/61

consuming task of interpreting the results. From a cost-benefit perspective, test automation

becomes more cost effective when the same tests can be reused many times over, such as forregression testing and test-driven development, and when the results can be interpreted quickly.

If future reuse of the test software is unlikely, then a manual approach is preferred.

From the perspective of practicality, software that does not have a graphical user

interface tends to be tested by automatic methods. Things such as device drivers and softwarelibraries must be tested using test programs. In addition, testing of large numbers of users

(performance testing and load testing) is typically simulated in software rather than performed in

practice. Conversely, graphical user interfaces whose layout changes frequently are very difficultto test automatically. There are test frameworks that can be used for regression testing of user

interfaces. They rely on recording of sequences of keystrokes and mouse gestures, then playing

them back and observing that the user interface responds in the same way every time.Unfortunately, these recordings may not work properly when a button is moved or relabeled in a

subsequent release. An automatic regression test may also be fooled if the program output varies

significantly (e.g. the display includes the current system time). In cases such as these, manual

testing may be more effective.

Advantage of manual testing.

There is no complete substitute for manual testing. Manual testing is crucial for the thoroughtesting of software applications. Although ways of automating this process have been available

for over 20 years it is often not appropriate or convenient to automate.

Automation can only be justified where repeatable consistent tests can be run over a stable

environment. When this isn't the case (for example during the early stages of the test cycle orwhen the application is complicated and the business risk is large) then testing teams almost

always revert back to manual testing.

Automated testing:-

Test automation is the use ofsoftware to control the execution oftests, the comparison of actual

outcomes to predicted outcomes, the setting up of test preconditions, and other test control and

test reporting functions. Commonly, test automation involves automating a manual process

already in place that uses a formalized testing process.

Overview

Although manual tests may find many defects in a software application, it is a laborious and time

consuming process. In addition it may not be effective in finding certain classes of defects. Test

automation is a process of writing a computer program to do testing that would otherwise need tobe done manually. Once tests have been automated, they can be run quickly. This is often the

most cost effective method for software products that have a long maintenance life, because even

minor patches over the lifetime of the application can cause features to break which wereworking at an earlier point in time.

There are two general approaches to test automation:
http://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Test-driven_developmenthttp://en.wikipedia.org/wiki/Device_driverhttp://en.wikipedia.org/wiki/Software_libraryhttp://en.wikipedia.org/wiki/Software_libraryhttp://en.wikipedia.org/wiki/Performance_testinghttp://en.wikipedia.org/wiki/Load_testinghttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Load_testinghttp://en.wikipedia.org/wiki/Performance_testinghttp://en.wikipedia.org/wiki/Software_libraryhttp://en.wikipedia.org/wiki/Software_libraryhttp://en.wikipedia.org/wiki/Device_driverhttp://en.wikipedia.org/wiki/Test-driven_developmenthttp://en.wikipedia.org/wiki/Regression_testing


54/61

Code-driven testing. The public (usually) interfaces to classes, modules, or libraries are

tested with a variety of input arguments to validate that the results that are returned arecorrect.

Graphical user interface testing. A testing framework generates user interface events such

as keystrokes and mouse clicks, and observes the changes that result in the user interface,

to validate that the observable behaviour of the program is correct.Test automation tools can be expensive, and it is usually employed in combination with manual

testing. It can be made cost-effective in the longer term, especially when used repeatedly in

regression testing.One way to generate test cases automatically is model-based testing through use of a model of

the system for test case generation, but research continues into a variety of alternative

methodologies for doing so. What to automate, when to automate, or even whether one reallyneeds automation are crucial decisions which the testing (or development) team must make.

Selecting the correct features of the product for automation largely determines the success of the

automation. Automating unstable features or features that are undergoing changes should be

avoided.

Code-driven testing

A growing trend in software development is the use of testing frameworks such as the xUnit

frameworks (for example, JUnit and NUnit) that allow the execution ofunit tests to determine

whether various sections of the code are acting as expected under various circumstances. Testcases describe tests that need to be run on the program to verify that the program runs as

expected.

Code driven test automation is a key feature ofagile software development, where it is known asTest-driven development (TDD). Unit tests are written to define the functionality before the code

is written. Only when all tests pass is the code considered complete. Proponents argue that it

produces software that is both more reliable and less costly than code that is tested by manual

exploration. It is considered more reliable because the code coverage is better, and because it isrun constantly during development rather than once at the end of a waterfall development cycle.

The developer discovers defects immediately upon making a change, when it is least expensive

to fix. Finally, code refactoring is safer; transforming the code into a simpler form with less codeduplication, but equivalent behaviour, is much less likely to introduce new defects.

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, comparing actual results

to those expected. The advantage of this approach is that it requires little or no software

development. This approach can be applied to any application that has a graphical user interface.However, reliance on these features poses major reliability and maintainability problems.

Relabeling a button or moving it to another part of the window may require the test to be re-

recorded. Record and playback also often adds irrelevant activities or incorrectly records someactivities.

A variation on this type of tool is for testing of web sites. Here, the "interface" is the web

page. This type of tool also requires little or no software development. However, such aframework utilizes entirely different techniques because it is reading html instead of observing
http://en.wikipedia.org/wiki/Public_interfacehttp://en.wikipedia.org/wiki/Graphical_user_interfacehttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Model-based_testinghttp://en.wikipedia.org/wiki/XUnithttp://en.wikipedia.org/wiki/JUnithttp://en.wikipedia.org/wiki/NUnithttp://en.wikipedia.org/wiki/Unit_testhttp://en.wikipedia.org/wiki/Codehttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Agile_software_developmenthttp://en.wikipedia.org/wiki/Test-driven_developmenthttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Code_refactoringhttp://en.wikipedia.org/wiki/Code_refactoringhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Test-driven_developmenthttp://en.wikipedia.org/wiki/Agile_software_developmenthttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Codehttp://en.wikipedia.org/wiki/Unit_testhttp://en.wikipedia.org/wiki/NUnithttp://en.wikipedia.org/wiki/JUnithttp://en.wikipedia.org/wiki/XUnithttp://en.wikipedia.org/wiki/Model-based_testinghttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Graphical_user_interfacehttp://en.wikipedia.org/wiki/Public_interface


55/61

window events. Another variation is scriptless test automation that does not use record and

playback, but instead builds a model of the application under test and then enables the tester tocreate test cases by simply editing in test parameters and conditions. This requires no scripting

skills, but has all the power and flexibility of a scripted approach. Test-case maintenance is easy,

as there is no code to maintain and as the application under test changes the software objects can

simply be re-learned or added. It can be applied to any GUI-based software application.

What to test?

Testing tools can help automate tasks such as product installation, test data creation, GUIinteraction, problem detection (consider parsing or polling agents equipped with oracles), defect

logging, etc., without necessarily automating tests in an end-to-end fashion.

One must keep following popular requirements when thinking of test automation:

Platform and OS independence.

Data driven capability (Input Data, Output Data, Meta Data.)

Customizable Reporting (DB Access, crystal reports.)

Easy debugging and logging.

Version control friendlyminimum or zero binary files. Extensible & Customizable (Open APIs to be able to integrate with other tools.)

Common Driver (For example, in the Java development ecosystem, that means Ant orMaven and the popular IDEs). This enables tests to integrate with the developers'workflows.

Supports unattended test runs for integration with build processes and batch runs.

Continuous Integration servers require this.

Email Notifications (Automated notification on failure or threshold levels). These may bethe test runner or tooling that executes it.

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 specificproduct. This system integrates the function libraries, test data sources, object details and various

reusable modules. These components act as small building blocks which need to be assembled in

a regular fashion to represent a business process. Thus, framework provides the basis of test

automation and hence simplifying the automation effort.There are various types of frameworks. They are categorized on the basis of the automation

component they leverage. These are: Data-driven testing

Modularity-driven testing

Keyword-driven testing

Hybrid testing

Model-based testing
http://en.wikipedia.org/wiki/Computing_platformhttp://en.wikipedia.org/wiki/Operating_systemhttp://en.wikipedia.org/wiki/Crystal_reportshttp://en.wikipedia.org/wiki/Version_controlhttp://en.wikipedia.org/wiki/Apache_Anthttp://en.wikipedia.org/wiki/Apache_Mavenhttp://en.wikipedia.org/wiki/Integrated_Development_Environmenthttp://en.wikipedia.org/wiki/Continuous_Integrationhttp://en.wikipedia.org/wiki/Testbedhttp://en.wikipedia.org/wiki/System_Under_Testhttp://en.wikipedia.org/wiki/Data-driven_testinghttp://en.wikipedia.org/wiki/Modularity-driven_testinghttp://en.wikipedia.org/wiki/Keyword-driven_testinghttp://en.wikipedia.org/wiki/Hybrid_testinghttp://en.wikipedia.org/wiki/Model-based_testinghttp://en.wikipedia.org/wiki/Model-based_testinghttp://en.wikipedia.org/wiki/Hybrid_testinghttp://en.wikipedia.org/wiki/Keyword-driven_testinghttp://en.wikipedia.org/wiki/Modularity-driven_testinghttp://en.wikipedia.org/wiki/Data-driven_testinghttp://en.wikipedia.org/wiki/System_Under_Testhttp://en.wikipedia.org/wiki/Testbedhttp://en.wikipedia.org/wiki/Continuous_Integrationhttp://en.wikipedia.org/wiki/Integrated_Development_Environmenthttp://en.wikipedia.org/wiki/Apache_Mavenhttp://en.wikipedia.org/wiki/Apache_Anthttp://en.wikipedia.org/wiki/Version_controlhttp://en.wikipedia.org/wiki/Crystal_reportshttp://en.wikipedia.org/wiki/Operating_systemhttp://en.wikipedia.org/wiki/Computing_platform


56/61

Why Automated Testing?

Every software development group tests its products, yet delivered software always hasdefects. Test engineers strive to catch them before the product is released but they always creep

in and they often reappear, even with the best manual testing processes. Automated software

testing is the best way to increase the effectiveness, efficiency and coverage of your software

testing.Manual software testing is performed by a human sitting in front of a computer carefully

going through application screens, trying various usage and input combinations, comparing the

results to the expected behavior and recording their observations. Manual tests are repeated oftenduring development cycles for source code changes and other situations like multiple operating

environments and hardware configurations. An automated software testing tool is able to

playback pre-recorded and predefined actions, compare the results to the expected behavior andreport the success or failure of these manual tests to a test engineer. Once automated tests are

created they can easily be repeated and they can be extended to perform tasks impossible with

manual testing. Because of this, savvy managers have found that automated software testing is

an essential component of successful development projects.

1. Automated software testing has long been considered critical for big softwaredevelopment organizations but is often thought to be too expensive or difficult for

smaller companies to implement. AutomatedQAs 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.2. Companies like Corel, Intel, Adobe, Autodesk, Intuit, McDonalds, Motorola, Symantec

and Sony all use TestComplete.

3. What makes automated software testing so important to these successful companies?4. Automated Software Testing Saves Time and Money5. Software tests have to be repeated often during development cycles to ensure quality.

Every time source code is modified software tests should be repeated. For each release of

the software it may be tested on all supported operating systems and hardwareconfigurations. Manually repeating these tests is costly and time consuming. Once

created, automated tests can be run over and over again at no additional cost and they are

much faster than manual tests. Automated software testing can reduce the time to run

repetitive tests from days to hours. A time savings that translates directly into costsavings.

6. Automated Software Testing Improves Accuracy7. Even the most conscientious tester will make mistakes during monotonous manual

testing. Automated tests perform the same steps precisely every time they are executed

and never forget to record detailed results.

8. Automated Software Testing Increases Test Coverage

9. Automated software testing can increase the depth and scope of tests to help improvesoftware quality. Lengthy tests that are often avoided during manual testing can be rununattended. They can even be run on multiple computers with different configurations.

Automated software testing can look inside an application and see memory contents, datatables, file contents, and internal program states to determine if the product is behaving as

expected. Automated software tests can easily execute thousands of different complex

test cases during every test run providing coverage that is impossible with manual tests.
http://www.automatedqa.com/products/testcomplete/supported-testing-types/manual-testing/http://www.automatedqa.com/products/testcomplete/http://www.automatedqa.com/products/testcomplete/http://www.automatedqa.com/products/testcomplete/supported-testing-types/manual-testing/


57/61

Testers freed from repetitive manual tests have more time to create new automated

software tests and deal with complex features.10.Automated Software Testing Does What Manual Testing Cannot11.Even the largest software departments cannot perform a controlled web application test

with thousands of users. Automated testing can simulate tens, hundreds or thousands of

virtual users interacting with network or web software and applications.12.Automated Software Testing Helps Developers and Testers13.Shared automated tests can be used by developers to catch problems quickly before

sending to QA. Tests can run automatically whenever source code changes are checked inand notify the team or the developer if they fail. Features like these save developers time

and increase their confidence.

14.Automated Software Testing Improves Team Morale15.This is hard to measure but weve exper

Software Engg Lab Manual 2011-12

Documents

Transcript of Software Engg Lab Manual 2011-12