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
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
8/61
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
10/61
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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.htm7/31/2019 Software Engg Lab Manual 2011-12
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.htm7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
15/61
UML diagrams for case study:
1. Use case diagram
2.Sequence Diagram for the Add a Course Scenario
7/31/2019 Software Engg Lab Manual 2011-12
16/61
7/31/2019 Software Engg Lab Manual 2011-12
17/61
3.Main Class Diagram for the University Artifacts Package
4.Course Reporting Class Diagram in the University Artifacts Package
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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:
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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)
7/31/2019 Software Engg Lab Manual 2011-12
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:
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
26/61
Course Registration System Use-Case Model Main Diagram
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
31/61
Computer Engineering Department
Middle East Technical University
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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}
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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:
7/31/2019 Software Engg Lab Manual 2011-12
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.HTM7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
44/61
Association
How to construct a Class diagram in Rational Rose SE:
7/31/2019 Software Engg Lab Manual 2011-12
45/61
7/31/2019 Software Engg Lab Manual 2011-12
46/61
7/31/2019 Software Engg Lab Manual 2011-12
47/61
Class Diagram for the case study:
7/31/2019 Software Engg Lab Manual 2011-12
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.
7/31/2019 Software Engg Lab Manual 2011-12
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:
7/31/2019 Software Engg Lab Manual 2011-12
50/61
7/31/2019 Software Engg Lab Manual 2011-12
51/61
7/31/2019 Software Engg Lab Manual 2011-12
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/7/31/2019 Software Engg Lab Manual 2011-12
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_testing7/31/2019 Software Engg Lab Manual 2011-12
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_interface7/31/2019 Software Engg Lab Manual 2011-12
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_platform7/31/2019 Software Engg Lab Manual 2011-12
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/7/31/2019 Software Engg Lab Manual 2011-12
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