LAB COURSE FILE

Software Engineering Lab

B.Tech (CSE)

School of Computing Science & Engineering

Prepared By Priyanka Shukla

1
 Table of Contents

of Contents Page no.

1. Course Detail ………………………………………………………………………….3
2. Course objective …………………………………………………………….……….3
3. Prerequisite……………………………………………………..………..……………3
4. Learning Outcome………………………………………………………….…………3
5. Syllabus and References……………………………………………… …….…..……4
6. Mode of evaluation……………………………………………………………..……..5
7. Relationship between course outcome and program outcome………………………6-7
8. Course lab outcome Assessment………………………………………….……………7
9. Direct measurement report……………………………………………………………..7
10. List of experiment………………………………………………………………………9
11. Value added list of experiment ………………………………………………………..9
12. Experiment setup………………………………………………………………………10
13. Experiment detail……...…………………………………………………………….11-47
14. Format for continuous assessment ……………………………...……………………47
15. Internal Lab Assessment (End Semester)…………………………………………….48

2
 COURSE DETAILS

Course Objective(s)
Develop complex systems (including analysis, design, construction, maintenance, quality assurance
and project management) using the appropriate theory, principles, tools and processes.
Use appropriate computer science and mathematics principles in the development of software
systems.
Solve problems in a team environment through effective use of written and oral communication
skills.
Have knowledge of current issues presently involved in effectively performing duties as a software
practitioner in an ethical and professional manner for the benefit of society.
Practice the lifelong learning needed in order to keep current as new issues emerge.
Develop software in at least one application domain.

Learning Out come

At the end of the course student will have:
1. The ability to apply software engineering theory, principles, tools and
processes, as well as the theory and principles of computer science and
mathematics, to the development and maintenance of complex software
systems
2. The ability to design and experiment with software prototypes
3. The ability to select and use software metrics
4. The ability to participate productively on software project teams involving
students from both software engineering and other majors
5. Effective communications skills through oral and written reports and software
documentation evaluated by both peers and faculty
6. The ability to elicit, analyze and specify software requirements through a
productive working relationship with project stakeholders

3
 Syllabus & References

CSE322 Software Engineering 3 0 2 4

Version No. 1.0
Prerequisite CSE101
Objectives:  Develop complex systems (including analysis, design, construction,
maintenance, quality assurance and project management) using the
appropriate theory, principles, tools and processes.
 Use appropriate computer science and mathematics principles in the
development of software systems.
 Solve problems in a team environment through effective use of
written and oral communication skills.
 Have knowledge of current issues presently involved in effectively
performing duties as a software practitioner in an ethical and
professional manner for the benefit of society.
 Practice the lifelong learning needed in order to keep current as new
issues emerge.
 Develop software in at least one application domain.
Expected Student will be able to
Outcome:  The ability to apply software engineering theory, principles, tools and
processes, as well as the theory and principles of computer science
and mathematics, to the development and maintenance of complex
software systems
 The ability to design and experiment with software prototypes
 The ability to select and use software metrics
 The ability to participate productively on software project teams
involving students from both software engineering and other majors
 Effective communications skills through oral and written reports and
software documentation evaluated by both peers and faculty
 The ability to elicit, analyze and specify software requirements
through a productive working relationship with project stakeholders
Module I Introduction to Software Engineering
Software Components, Software Characteristics, SoftwareCrisis, Software Engineering
Processes, Similarity and Differences from ConventionalEngineering Processes, Software
Quality Attributes. Software Development Life Cycle (SDLC)Models: Water Fall Model,
Prototype Model, Spiral Model, Evolutionary Development Models,Iterative Enhancement
Models.
Module II Software Requirement Specifications (SRS)
Requirement Engineering Process: Elicitation, Analysis, Documentation, Review
andManagement of User Needs, Feasibility Study, Information Modeling, Data Flow
Diagrams,Entity Relationship Diagrams, Decision Tables, SRS Document, IEEE Standards
for SRS.
Software Quality Assurance (SQA): Verification and Validation, SQA Plans, Software
QualityFrameworks, ISO 9000 Models, SEI-CMM Model.
Module III Software Design
Basic Concept of Software Design, Architectural Design, Low Level Design:
Modularization,Design Structure Charts, Pseudo Codes, Flow Charts, Coupling and
Cohesion Measures, DesignStrategies: Function Oriented Design, Object Oriented Design,

4
 Top-Down and Bottom-UpDesign. Software Measurement and Metrics: Various Size
Oriented Measures: Halestead’sSoftware Science, Function Point (FP) Based Measures,
Cyclomatic Complexity Measures:Control Flow Graphs.
Module IV Software Testing
Testing Objectives, Module Testing, Integration Testing, Acceptance Testing, Regression
Testing,Testing for Functionality and Testing for Performance, Top-Down and Bottom-Up
TestingStrategies: Test Drivers and Test Stubs, Structural Testing (White Box Testing),
FunctionalTesting (Black Box Testing), Test Data Suit Preparation, Alpha and Beta Testing
of Products.Static Testing Strategies: Formal Technical Reviews (Peer Reviews), Walk
Through, CodeInspection, Compliance with Design and Coding Standards.
Module IV Software Maintenance and Software Project Management
Software as an Evolutionary Entity, Need for Maintenance, Categories of
aintenance:Preventive, Corrective and Perfective Maintenance, Cost of Maintenance,
Software Re-Engineering, Reverse Engineering. Software Configuration Management
Activities, ChangeControl Process, Software Version Control, An Overview of CASE
Tools. Estimation of VariousParameters such as Cost, Efforts, Schedule/Duration,
Constructive Cost Models (COCOMO),Resource Allocation Models, Software Risk
Analysis and Management.
References
1. R. S. Pressman, Software Engineering: A Practitioners Approach, McGraw Hill.
2. Rajib Mall, Fundamentals of Software Engineering, PHI Publication.
3. K. K. Aggarwal and Yogesh Singh, Software Engineering, New Age International
Publishers.
4. Pankaj Jalote, Software Engineering, Wiley
5. Carlo Ghezzi, M. Jarayeri, D. Manodrioli, Fundamentals of Software Engineering, PHI
Publication.
6. Ian Sommerville, Software Engineering, Addison Wesley.
7. Kassem Saleh,”Software Engineering”, Cengage Learning.
8. Pfleeger, Software Engineering, Macmillan Publication.

Mode of Evaluation: Quiz/Assignment/ Seminar/Written Examination

Theory Laboratory
Components Internal SEE Internal SEE Theory and
Marks 50 50 50 50 laboratory
Total Marks 100 100
Scaled Marks 75 25 100

5
Relationship between the Course Outcomes (COs) .

S. No. Course Outcomes Mapped Program

Outcomes

1. To study about requirement analysis and documentation

2. To study the different UML diagram .

3. To study the designing of different UML diagram .

4. To study and design the data flow diagram

5. To study and design the ER diagram.

6. To study and design the test cases and test suit.

Course Lab Outcomes Assessment

The laboratory component strongly contributes towards the program outcome Design/development
of solutions-PO(3). This evaluation method will be used for the evaluation of lab and program
outcomes of this course.
Direct Measurement Report
CSE342 P Report form
Measure– percent of students scoring at least 70% marks in lab.
Target – 70% of students

6
 LIST OF EXPERIMENTS
Sr. No. Title of Lab Experiments

1. Identify the project and prepare the SRS document for the project
2. Getting familiarized with the Unified Modeling Language (UML) Environment.
3. Modeling Data Flow Diagrams (at level 0,level 1 & level 2) for the chosen project.
4 Modeling E-R diagram for the chosen project.
5 Working with the Use-case diagrams and capturing Use case scenarios.
6. Working with the Activity Diagrams for the chosen project.
7. Working with the ClassDiagrams for the chosen project.
8. Working with the Sequence Diagramsfor the chosen project.
9 Working with the State chart Diagrams for the chosen project.
10. Coding of the selected project
11. Test cases design and program testing for the chosen project.

Projects (Students will chose only from the below mentioned projects)
1. Student Result management System
2. Library management system
3. Automatic Teller Machine
4. Railway/Flight Reservation System
5. Hotel/Restaurant Management System
6. Blood Bank System
7. Online Banking System
Value Added List of Experiments
1. Introduction to Any Software testing tool.
2. Integration testing of their System
3. Using COCOMO model, estimate effort for their System
4. Analyze risk related to the project and prepare RMMM plan

Name of the Course Coordinator: Mr. R. K. Rambola

Name of Lab Coordinatore:Ms. Priyanka Shukla
Signature

7
EXPERIMENTAL SETUP DETAILS FOR THE COURSE
Software Requirements
 Pentium PC

 Tools can be installed according to your requirements

Hardware Requirements
 No specific requirements.

8
EXPERIMENT DETAILS

Experiment No:1

Title Identify the project and prepare the SRS document for the project

Objective Refinement of System and Software requirements

Prerequisit Knowledge of Various process models.

e

Theory The purpose of this SRS is to describe the requirements involved in developing the
chosen project.

The Software requirements specification is produced as culmination of the analysis task

which contains:-

1. Introduction

 Goal & Objectives of Software

2. Information Description

 Problem Description
 Information Flow
 Hardware Interface

3. Functional Description

 Process Narrative for each function

4. Design Constraints

 Performance Characteristics
 Behavioral Description
 Validation Criteria
Sample A SRS document which contains detailed information about each ofthe point specified
Output above.

Post Lab 1. What is meant by software requirement definition? Elaborate on its

Assignmen Importance
t (If Any) 2. Explain varies steps involved in Requirement Engineering?

9
 Experiment No:2

Title Getting familiarized with the Unified Modeling Language (UML) Environment.

Objective To provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.

Prerequisit None
e

Theory UML stands for Unified Modeling Language. This object-oriented system of notation
has evolved from the work of Grady Booch, James Rumbaugh, Ivar Jacobson, and the
Rational Software Corporation. These renowned computer scientists fused their
respective technologies into a single, standardized model. Today, UML is accepted by
the Object Management Group (OMG) as the standard for modeling object oriented
programs.

Goals of UML

The primary goals in the design of the UML were:

1. Provide users with a ready-to-use, expressive visual modeling language so they

can develop and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development
processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as collaborations, frameworks,
patterns and components.
7. Integrate best practices.

Why use UML?

With many rapid application development environments available, developing a

software application is fairly easy so why use UML? Most people are familiar with a
drawing package can design and create forms and most people with basic programming
skills can double click on a control and enter some code. But does this approach lend
itself to professional quality applications?

Furthermore, the use of UML will help:

 The communication of the desired structure and behavior of a system between

analysts, architects, developers, stakeholders and users.
 The visualization and control of system architecture.

10
  Promote a deeper understanding of the system, exposing opportunities for
simplification and re-use.
 Manage risk.

Introduction to UML Diagrams:

Class Diagrams It is a type of static structure diagram

that describes the structure of a system
by showing the system's classes, their
attributes, operations (or methods), and
the relationships among objects.
Object diagrams An object diagram in the Unified
Modeling Language (UML) is
a diagram that shows a complete or
partial view of the structure of a
modeled system at a specific time.
Use case diagrams A use case diagram at its simplest is a
representation of a user's interaction
with the system and depicting the
specifications of a use case. A use case
diagram can portray the different types
of users of a system and the case and
will often be accompanied by other
types of diagrams as well.
Sequence Diagrams A Sequence diagram is an interaction
diagram that shows how processes
operate with one another and in what
order. It is a construct of a Message
Sequence Char
Collaboration Diagrams A collaboration diagram, also called a
communication diagram or interaction
diagram, is an illustration of the
relationships and interactions among
software objects in the Unified
Modeling Language (UML).
State Chart Diagrams The state diagram in the Unified
Modeling Language is essentially a
Harel state chart with standardized
notation which can describe many
systems, from computer programs to
business processes
Activity Diagrams Activity diagrams are graphical
representations of workflows of
stepwise activities and actionswith
support for choice, iteration and
concurrency. In the Unified Modeling
Language, activity diagrams are

11
 intended to model both computational
and organizational processes (i.e.
workflows).
Component & Deployment In the Unified Modeling Language,
Diagrams a component diagram depicts
how components are wired together to
form larger components and
or software systems. They are used to
illustrate the structure of arbitrarily
complex systems.

\
Sample
Output

Post Lab
Assignmen Practice UML for other projects
t (If Any)

12
 Experiment No:3

Title Working with the Use-case diagrams and capturing Use case scenarios.

Objectiv It will provide students graphical overview of the functionality provided by the system.
e

Prerequi Knowledge of UML

site

Theory Use case diagram is a platform that can provide a common understanding for the end-users,
developers and the domain experts. It is used to capture the basic functionality i.e. use
cases, and the users of those available functionality, i.e. actors, from a given problem
statement.

In this experiment, we will learn how use cases and actors can be captured and how
different use cases are related in a system.

Use case diagrams

Use case diagrams belong to the category of behavioral diagram of UML diagrams. Use
case diagrams aim to present a graphical overview of the functionality provided by the
system. It consists of a set of actions (referred to as use cases) that the concerned system
can perform one or more actors, and dependencies among them.

Actor

An actor can be defined as an object or set of objects, external to the system, which
interacts with the system to get some meaningful work done. Actors could be human,
devices, or even other systems. For example, consider the case where a customer
withdraws cash from an ATM. Here, customer is a human actor.

Actors can be classified as below:

 Primary actor: They are principal users of the system, who fulfill their goal by
availing some service from the system. For example, a customer uses an ATM to
withdraw cash when he needs it. A customer is the primary actor here.
 Supporting actor: They render some kind of service to the system. "Bank
representatives", who replenishes the stock of cash, is such an example. It may be
noted that replenishing stock of cash in an ATM is not the prime functionality of an
ATM.

In a use case diagram primary actors are usually drawn on the top left side of the diagram.

Use Case

A use case is simply functionality provided by a system.

13
Continuing with the example of the ATM, withdraw cash is a functionality that the ATM
provides. Therefore, this is a use case. Other possible use cases include, check balance,
change PIN, and so on.

Use cases include both successful and unsuccessful scenarios of user interactions with the
system. For example, authentication of a customer by the ATM would fail if he enters
wrong PIN. In such case, an error message is displayed on the screen of the ATM.

Subject

Subject is simply the system under consideration. Use cases apply to a subject. For
example, an ATM is a subject, having multiple use cases, and multiple actors interact with
it. However, one should be careful of external systems interacting with the subject as
actors.

Graphical Representation
An actor is represented by a stick figure and name of the actor is written below it. A use
case is depicted by an ellipse and name of the use case is written inside it. The subject is
shown by drawing a rectangle. Label for the system could be put inside it. Use cases are
drawn inside the rectangle, and actors are drawn outside the rectangle, as below:

Association between Actors and Use Cases

A use case is triggered by an actor. Actors and use cases are connected through binary
associations indicating that the two communicates through message passing.

An actor must be associated with at least one use case. Similarly, a given use case must be
associated with at least one actor. Associations among the actors are usually not shown.
However, one can depict the class hierarchy among actors.

Use Case Relationships

Three types of relationships exist among use cases:

 Include relationship
 Extend relationship

14
  Use case generalization

Include Relationship

Include relationships are used to depict common behavior that are shared by multiple use
cases. This could be considered analogous to writing functions in a program in order to
avoid repetition of writing the same code. Such a function would be called from different
points within the program.

Example

For example, consider an email application. A user can send a new mail, reply to an email
he has received, or forward an email. However, in each of these three cases, the user must
be logged in to perform those actions. Thus, we could have a login use case, which is
included by compose mail, reply, and forward email use cases. The relationship is shown
in figure - 02.

Generalization relationship is depicted by a solid arrow from the specialized (derived) use
case to the more generalized (base) use case.

Identifying Actors
Given a problem statement, the actors could be identified by asking the following
questions :

 Who gets most of the benefits from the system? (The answer would lead to the
identification of the primary actor)
 Who keeps the system working? (This will help to identify a list of potential users)
 What other software / hardware does the system interact with?
 Any interface (interaction) between the concerned system and any other system?

Identifying Use cases

Once the primary and secondary actors have been identified, we have to find out their
goals i.e. what is the functionality they can obtain from the system. Any use case name
should start with a verb like, "Check balance".

15
 Guidelines for drawing Use Case diagrams
Following general guidelines could be kept in mind while trying to draw a use case
diagram:

 Determine the system boundary

 Ensure that individual actors have well-defined purpose
 Use cases identified should let some meaningful work done by the actors
 Associate the actors and use cases -- there shouldn't be any actor or use case
floating without any connection
 Use include relationship to encapsulate common behavior among use cases , if any

Sample Use case diagrams for the chosen project is captured using above mentioned basics
Output

16
 Experiment No:4

Title
Modeling E-R diagram for the chosen project.
Objectiv Students will be able to create a logical design of database for real world objects
e

Prerequi Knowledge of UML

site

Theory Introduction
Developing databases is a very important task to develop a system. Before going to form
exact database tables and establishing relationships between them, we conceptually or
logically can model our database using ER diagrams.

In this experiment we will learn how to find the entities, its attributes and how the
relationships between the entities can be established for a system.

Entity Relationship Model

Entity-Relationship model is used to represent a logical design of a database to be created.
In ER model, real world objects (or concepts) are abstracted as entities, and different
possible associations among them are modeled as relationships.

For example, student and school -- they are two entities. Students study in school. So, these
two entities are associated with a relationship "Studies in".

As another example, consider a system where some job runs every night, which updates
the database. Here, job and database could be two entities. They are associated with the
relationship "Updates".

Entity Set and Relationship Set

An entity set is a collection of all similar entities. For example, "Student" is an entity set
that abstracts all students. Ram, John are specific entities belonging to this set. Similarly, a
"Relationship" set is a set of similar relationships.

Attributes of Entity
Attributes are the characteristics describing any entity belonging to an entity set. Any
entity in a set can be described by zero or more attributes.

For example, any student has got a name, age, an address. At any given time a student can
study only at one school. In the school he would have a roll number, and of course a grade
in which he studies. These data are the attributes of the entity set Student.

17
Keys
One or more attribute(s) of an entity set can be used to define the following keys:

 Super key: One or more attributes, which when taken together, helps to uniquely
identify an entity in an entity set. For example, a school can have any number of
students. However, if we know grade and roll number, then we can uniquely
identify a student in that school.
 Candidate key: It is a minimal subset of a super key. In other words, a super key
might contain extraneous attributes, which do not help in identifying an object
uniquely. When such attributes are removed, the key formed so is called a candidate
key.
 Primary key: A database might have more than one candidate key. Any candidate
key chosen for a particular implementation of the database is called a primary key.
 Prime attribute: Any attribute taking part in a super key

Weak Entity
An entity set is said to be weak if it is dependent upon another entity set. A weak entity
can't be uniquely identified only by it's attributes. In other words, it doesn't have a super
key.

For example, consider a company that allows employees to have travel allowance for their
immediate family. So, here we have two entity sets: employee and family, related by "Can
claim for". However, family doesn't have a super key. Existence of a family is entirely
dependent on the concerned employee. So, it is meaningful only with reference to
employee.

Entity Generalization and Specialization

Once we have identified the entity sets, we might find some similarities among them. For
example, multiple peopleinteract with a banking system. Most of them are customers, and
rest employees or other service providers. Here, customers, employees are persons, but
with certain specializations. Or in other way, person is the generalized form of customer
and employee entity sets.

ER model uses the "ISA" hierarchy to depict specialization (and thus, generalization).

Mapping Cardinalities
One of the main tasks of ER modeling is to associate different entity sets. Let's consider
two entity sets E1 and E2 associated by a relationship set R. Based on the number of
entities in E1 and E2 are associated with, we can have the following four type of mappings:

 One to one: An entity in E1 is related to at most a single entity in E2, and vice
versa
 One to many: An entity in E1 could be related to zero or more entities in E2. Any

18
 entity in E2 could be related to at most a single entity in E1.
 Many to one: Zero or more number of entities in E1 could be associated to a single
entity in E2. However, an entity in E2 could be related to at most one entity in E1.
 Many to many: Any number of entities could be related to any number of entities
in E2, including zero, and vice versa.

ER Diagram
From a given problem statement we identify the possible entity sets, their attributes, and
relationships among different entity sets. Once we have these information, we represent
them pictorially, called an entity-relationship (ER) diagram.

Graphical Notations for ER Diagram

Term Notation Remarks
Name of the set
Entity set
rectangle
Name of the attribut
Attribute
ellipse

Roll is the primary

Entity with attributes
underline

Weak entity set

Name of the relatio

Relationship set
the diamond

Related enity sets

Relationship A person can own ze
cardinality two persons can own

Relationship with
weak entity set

Importance of ER modeling
Figure - 01 shows the different steps involved in implementation of a (relational) database.

19
 Given a problem statement, the first step is to identify the entities, attributes and
relationships. We represent them using an ER diagram. Using this ER diagram, table
structures are created, along with required constraints. Finally, these tables are normalized
in order to remove redundancy and maintain data integrity. Thus, to have data stored
efficiently, the ER diagram is to be drawn as much detailed and accurate as possible.
Sample
Output

Post Dram E-R diagrams for other projects

Lab
Assign
ment (If
Any)

20
 Experiment No:5

Title Working with the State chart Diagrams for the chosen project.

Objecti It will help students to capture the dynamic view of the system.
ve

Prerequ Knowledge of UML

isite

Theory Introduction
Capturing the dynamic view of a system is very important for a developer to develop the
logic for a system. State chart diagrams and activity diagrams are two popular UML
diagram to visualize the dynamic behavior of an information system.

In this experiment, we will learn about the different components of state chart diagram and
how these can be used to represent the dynamic nature of an information system.

State chart Diagrams

In case of Object Oriented Analysis and Design, a system is often abstracted by one or
more classes with some well defined behavior and states. A statechart diagram is a
pictorial representation of such a system, with all its states, and different events that lead
transition from one state to another.

To illustrate this, consider a computer. Some possible states that it could have are: running,
shutdown, hibernate. A transition from running state to shutdown state occur when user
presses the "Power off" switch, or clicks on the "Shut down" button as displayed by the OS.
Here, clicking on the shutdown button, or pressing the power off switch act as external
events causing the transition.

Statechart diagrams are normally drawn to model the behaviour of a complex system. For
simple systems this is optional.

Building Blocks of a State chart Diagram

State

A state is any "distinct" stage that an object (system) passes through in it's lifetime. An
object remains in a given state for finite time until "something" happens, which makes it to
move to another state. All such states can be broadly categorized into following three
types:

 Initial: The state in which an object remain when created

 Final: The state from which an object do not move to any other state [optional]

21
  Intermediate: Any state, which is neither initial, nor final

As shown in figure-01, an initial state is represented by a circle filled with black. An

intermediate state is depicted by a rectangle with rounded corners. A final state is
represented by a unfilled circle with an inner black-filled circle.

Figure-01: Representation of initial, intermediate, and final states of a statechart diagram

Intermediate states usually have two compartments, separated by a horizontal line, called
the name compartment and internal transitions compartment [iv]. They are described below:

 Name compartment: Contains the name of the state, which is a short, simple,
descriptive string
 Internal transitions compartment: Contains a list of internal activities performed
as long as the system is in this state

The internal activities are indicated using the following syntax: action-label / action-
expression. Action labels could be any condition indicator. There are, however, four special
action labels:

 Entry: Indicates activity performed when the system enter this state
 Exit: Indicates activity performed when the system exits this state
 Do: indicate any activity that is performed while the system remain in this state or
until the action expression results in a completed computation
 Include: Indicates invocation of a sub-machine

Any other action label identify the event (internal transition) as a result of which the
corresponding action is triggered. Internal transition is almost similar to self transition,
except that the former doesn't result in execution of entry and exit actions. That is, system

doesn't exit or re-enter that state. Figure-02 shows the syntax for
representing a typical

intermediate) state

Figure-02: A typical state in a statechart diagram States could again be either simple or
composite (a state congaing other states). Here, however, we will deal only with simple
states.

Transition

Transition is movement from one state to another state in response to an external stimulus
(or any internal event). A transition is represented by a solid arrow from the current state to

22
the next state. It is labeled by: event [guard-condition]/[action-expression], where

 Event is the what is causing the concerned transition (mandatory) -- Written in past
tense [iii]
 Guard-condition is (are) precondition(s), which must be true for the transition to
happen [optional]
 Action-expression indicate action(s) to be performed as a result of the transition
[optional]

It may be noted that if a transition is triggered with one or more guard-condition(s), which
evaluate to false, the system will continue to stay in the present state. Also, not all
transitions do result in a state change. For example, if a queue is full, any further attempt to
append will fail until the delete method is invoked at least once. Thus, state of the queue
doesn't change in this duration.

Action

As mentioned in [ii], actions represents behaviour of the system. While the system is
performing any action for the current event, it doesn't accept or process any new event. The
order in which different actions are executed, is given below:

1. Exit actions of the present state

2. Actions specified for the transition
3. Entry actions of the next state

Figure-03 shows a typical statechart diagram with all it's syntaxes.

Figure-03: A statechart diagram showing transition from state A to B

Guidelines for drawing State chart Diagrams

Following steps could be followed, as suggested in [i] to draw a state chart diagram:

 For the system to developed, identify the distinct states that it passes through
 Identify the events (and any precondition) that cause the state transitions. Often
these would be the methods of a class as identified in a class diagram.
 Identify what activities are performed while the system remains in a given state

23
Sample
Output

.
Post Dram State diagrams for other projects
Lab
Assign
ment
(If
Any)

24
 Experiment No:6

Title Working with the Activity Diagrams for the chosen project.

Objecti Students will be able to visually represent the flow of control in the system
ve

Prerequ Knowledge of UML

isite

Theory Activity Diagrams

Activity diagrams fall under the category of behavioral diagrams in Unified Modeling
Language. It is a high level diagram used to visually represent the flow of control in a
system. It has similarities with traditional flow charts. However, it is more powerful than a
simple flow chart since it can represent various other concepts like concurrent activities,
their joining, and so on.

With many rapid application development environments available, developing a software

application is fairly easy so why use UML? Most people are familiar with a drawing
package can design and create forms and most people with basic programming skills can
double click on a control and enter some code. But does this approach lend itself to
professional quality applications?

Activity diagrams, however, cannot depict the message passing among related objects. As
such, it can't be directly translated into code. These kinds of diagrams are suitable for
confirming the logic to be implemented with the business users. These diagrams are
typically used when the business logic is complex. In simple scenarios it can be avoided
entirely

Components of an Activity Diagram

Below we describe the building blocks of an activity diagram.

Activity

An activity denotes a particular action taken in the logical flow of control. This could
simply be invocation of a mathematical function, alter an object's properties and so on [x].
An activity is represented with a rounded rectangle, as shown in table-01. A label inside the
rectangle identifies the corresponding activity.

There are two special type of activity nodes: initial and final. They are represented with a
filled circle, and a filled in circle with a border respectively (table-01). Initial node
represents the starting point of a flow in an activity diagram. There could be multiple initial
nodes, which means that invoking that particular activity diagram would initiate multiple
flows.

A final node represents the end point of all activities. Like an initial node, there could be

25
multiple final nodes. Any transition reaching a final node would stop all activities.

Flow

A flow (also termed as edge, or transition) is represented with a directed arrow. This is used
to depict transfer of control from one activity to another, or to other types of components, as
we will see below. A flow is often accompanied with a label, called the guard condition,
indicating the necessary condition for the transition to happen. The syntax to depict it is
[guard condition].

Decision

A decision node, represented with a diamond, is a point where a single flow enters and two
or more flows leave. The control flow can follow only one of the outgoing paths. The
outgoing edges often have guard conditions indicating true-false or if-then-else conditions.
However, they can be omitted in obvious cases. The input edge could also have guard
conditions. Alternately, a note can be attached to the decision node indicating the condition
to be tested.

Merge

This is represented with a diamond shape, with two or more flows entering, and a single
flow leaving out. A merge node represents the point where at least a single control should
reach before further processing could continue.

Fork

Fork is a point where parallel activities begin. For example, when a student has been
registered with a college, he can in parallel apply for student ID card and library card. A
fork is graphically depicted with a black bar, with a single flow entering and multiple flows
leaving out.

Join

A join is depicted with a black bar, with multiple input flows, but a single output flow.
Physically it represents the synchronization of all concurrent activities. Unlike a merge, in
case of a join all of the incoming controls must be completed before any further progress
could be made. For example, a sales order is closed only when the customer has receive the
product, and the sales company has received it's payment.

Note

UML allows attaching a note to different components of a diagram to present some textual
information. The information could simply be a comment or may be some constraint. A
note can be attached to a decision point, for example, to indicate the branching criteria.

Partition

Different components of an activity diagram can be logically grouped into different areas,

26
called partitions or swim lanes. They often correspond to different units of an organization
or different actors. The drawing area can be partitioned into multiple compartments using
vertical (or horizontal) parallel lines. Partitions in an activity diagram are not mandatory.

The following table shows commonly used components with a typical activity diagram.

Component Graphical Notation

Activity

Flow

Decision

Merge

Fork

Join

Note
Table-01: Typical components used in an activity diagram

27
Apart from the above stated components, there are few other components as well
(representing events, sending of signals, nested activity diagrams), which won't be
discussed here. The reader is suggested to go through [x] for further knowledge.

A Simple Example

Figure-04 shows a simple activity diagram with two activities. The figure depicts two
stages of a form submission. At first a form is filled up with relevant and correct
information. Once it is verified that there is no error in the form, it is then submitted. The
two other symbols shown in the figure are the initial node (dark filled circle), and final node
(outer hollow circle with inner filled circle). It may be noted that there could be zero or

more final node(s) in an activity diagram [ix].

Figure-04: A simple activity diagram.

Guidelines for drawing an Activity Diagram

The following general guidelines could be followed to pictorially represent a complex
logic.

 Identify tiny pieces of work being performed by the system

 Identify the next logical activity that should be performed
 Think about all those conditions that should be made, and all those constraints that
should be satisfied, before one can move to the next activity
 Put non-trivial guard conditions on the edges to avoid confusion

28
Sample
Output

Activity Diagram for Issue Book in Library

Post Dram other activity diagrams for your project
Lab
Assign
ment
(If
Any)

29
 Experiment No:7

Title
Working with the Class Diagrams for the chosen project.
Objective It will help students to know the relationships between the class, in the system

Prerequisite Knowledge of UML

Theory Introduction
Classes are the structural units in object oriented system design approach, so it is
essential to know all the relationships that exist between the classes, in a system. All
objects in a system are also interacting to each other by means of passing messages
from one object to another. Sequence diagram shows these interactions with time
ordering of the messages.

In this Experiment, we will learn about the representation of class diagram. We also
learn about different relationships that exist among the classes, in a system.

Structural and Behavioral aspects

Developing a software system in object oriented approach is very much dependent on
understanding the problem. Some aspects and the respective models are used to
describe problems and in context of those aspects the respective models give a clear
idea regarding the problem to a designer. For developer, structural and behavioral
aspects are two key aspects to see through a problem to design a solution for the
same.

Class diagram
It is a graphical representation for describing a system in context of its static
construction.

Elements in class diagram

Class diagram contains the system classes with its data members, operations and
relationships between classes.

Class
A set of objects containing similar data members and member functions is described
by a class. In UML syntax, class is identified by solid outline rectangle with three
compartments which contain

30
 Class name

A class is uniquely identified in a system by its name. A textual string [2]is

taken as class name. It lies in the first compartment in class rectangle.

 Attributes

Property shared by all instances of a class. It lies in the second compartment

in class rectangle.

 Operations

An execution of an action can be performed for any object of a class. It lies in

the last compartment in class rectangle.

Example

To build a structural model for an Educational Organization, ‘Course’ can be

treated as a class which contains attributes ‘courseName’ & ‘courseID’ with
the operations ‘addCourse()’ & ‘removeCourse()’ allowed to be performed for
any object to that class.

Figure-01:

 Generalization/Specialization

It describes how one class is derived from another class. Derived class inherits
the properties of its parent class.

Example

Figure-02:

31
 Geometric_Shapes is the class that describes how many sides a particular
shape has. Triangle, Quadrilateral and Pentagon are the classes that inherit the
property of the Geometric_Shapes class. So the relations among these classes
are generalization. Now Equilateral_Triangle, Isosceles_Triangle and
Scalene_Triangle, all these three classes inherit the properties of Triangle
class as each one of them has three sides. So, these are specialization of
Triangle class.

Relationships
Existing relationships in a system describe legitimate connections between the classes
in that system.

 Association

It is an instance level relationship[i] that allows exchanging messages among

the objects of both ends of association. A simple straight line connecting two
class boxes represent an association. We can give a name to association and
also at the both end we may indicate role names and multiplicity of the
adjacent classes. Association may be uni-directional.

Example

In structure model for a system of an organization an employee (instance of

‘Employee’ class) is always assigned to a particular department (instance of
‘Department’ class) and the association can be shown by a line connecting the
respective classes.

Figure-03:

 Aggregation

It is a special form of association which describes a part-whole[i] relationship

between a pair of classes. It means, in a relationship, when a class holds some
instances of related class, then that relationship can be designed as an
aggregation.

Example

For a supermarket in a city, each branch runs some of the departments they
have. So, the relation among the classes ‘Branch’ and ‘Department’ can be
designed as an aggregation. In UML, it can be shown as in the fig. below

32
 Figure-04:

 Composition

It is a strong from of aggregation which describes that whole is completely

owns its part. Life cycle of the part depends on the whole.

Example

Let consider a shopping mall has several branches in different locations in a

city. The existence of branches completely depends on the shopping mall as if
it is not exist any branch of it will no longer exists in the city. This relation
can be described as composition and can be shown as below

Figure-05:

 Multiplicity

It describes how many numbers of instances of one class is related to the

number of instances of another class in an association.

Notation for different types of multiplicity:

Figure-06:

Example

One vehicle may have two or more wheels

33
Sample
Output

Post Lab
Assignment Dram Class diagrams for the other project
(If Any)

34
 Experiment No:8

Title Working with the Sequence Diagrams for the chosen project.

Objective It will help students to represent the behavioral aspects of a system

Prerequisite Knowledge of UML

Theory Sequence diagram

It represents the behavioral aspects of a system. Sequence diagram shows the
interactions between the objects by means of passing messages from one object to
another with respect to timein a system.

Elements in sequence diagram

Sequence diagram contains the objects of a system and their life-line bar and the
messages passing between them.

Object
Objects appear at the top portion of sequence diagram. Object is shown in a rectangle
box. Name of object precedes a colon ‘:’ and the class name, from which the object is
instantiated. The whole string is underlined and appears in a rectangle box. Also, we
may use only class name or only instance name.

Objects which are created at the time of execution of use case and are involved in
message passing , are appear in diagram, at the point of their creation.

Life-line bar
A down-ward vertical line from object-box is shown as the life-line of the object. A
rectangle bar on life-line indicates that it is active at that point of time.

Messages
Messages are shown as an arrow from the life-line of sender object to the life-line of
receiver object and labeled with the message name. Chronological order of the
messages passing throughout the objects’ life-line show the sequence in which they
occur. There may exist some different types of messages :

 Synchronous messages:Receiver start processing the message after receiving

it and sender needs to wait until it is made.A straight arrow with close and fill
arrow-head from sender life-line bar to receiver end, represent a synchronous
message.

35
  Asynchronous messages: For asynchronous message sender needs not to
wait for the receiver to process the message. A function call that creates thread
can be represented as an asynchronous message in sequence diagram. A
straight arrow with open arrow-head from sender life-line bar to receiver end,
represent an asynchronous message.
 Return message: For a function call when we need to return a value to the
object, from which it was called, then we use return message. But, it is
optional, and we are using it when we are going to model our system in much
detail. A dashed arrow with open arrow-head from sender life-line bar to
receiver end, represent that message.
 Response message: One object can send a message to self. We use this
message when we need to show the interaction between the same object.

Figure-08

Sample
Output

Post Lab Draw Sequence diagrams for the other project

Assignment
(If Any)

36
 Experiment No:9

Title Modeling Data Flow Diagrams (at level 0 & level 1) for the chosen project.

Objecti It will help students to pictorially represent the functionalities of the systems by focusing on
ve the sources and destinations of the data flowing in the system.

Prerequ Knowledge of UML

isite

Theory Introduction
Information Systems (IS) help in managing and updating the vast business-related
information. Before designing such an IS, it is helpful to identify the various stakeholders,
and the information that they would be exchanging with the system. An IS, however, is a
large software comprised of several modules, which, in turn, share the process the available
data. These data are often stored in databases for further references. A Data Flow Diagram
(DFD) is used to pictorially represent the functionalities of the ISs by focusing on the
sources and destinations of the data flowing in the system.

Data Flow Diagram

DFD provides the functional overview of a system. The graphical representation easily
overcomes any gap between ’user and system analyst’ and ‘analyst and system designer’ in
understanding a system. Starting from an overview of the system it explores detailed design
of a system through a hierarchy. DFD shows the external entities from which data flows
into the process and also the other flows of data within a system. It also includes the
transformations of data flow by the process and the data stores to read or write a data.

Graphical notations for Data Flow Diagram

Term Notation Remarks

External
Name of the external entity is written inside the rectangle
entity

Process Name of the process is written inside the circle

A left-right open rectangle is denoted as data store; nam

Data store
written inside the shape

37
Data flow Data flow is represented by a directed arc with its data name

Explanation of Symbols used in DFD

 Process: Processes are represented by circle. The name of the process is written into
the circle. The name of the process is usually given in such a way that represents the
functionality of the process. More detailed functionalities can be shown in the next
Level if it is required. Usually it is better to keep the number of processes less than
7 [i]. If we see that the number of processes becomes more than 7 then we should
combine some the processes to a single one to reduce the number of processes and
further decompose it to the next level.
 External entity: External entities are only appearing in context diagram. External
entities are represented by a rectangle and the name of the external entity is written
into the shape. These send data to be processed and again receive the processed
data.
 Data store: Data stares are represented by a left-right open rectangle. Name of the
data store is written in between two horizontal lines of the open rectangle. Data
stores are used as repositories from which data can be flown in or flown out to or
from a process.
 Data flow: Data flows are shown as a directed edge between two components of a
Data Flow Diagram. Data can flow from external entity to process, data store to
process, in between two processes and vice-versa.

Context diagram and leveling DFD

We start with a broad overview of a system represented in level 0
diagrams. It is known as context diagram of the system. The entire system
is shown as single process and also the interactions of external entities
with the system are represented in context diagram.
Further we split the process in next levels into several numbers of
processes to represent the detailed functionalities performed by the system.
Data stores may appear in higher level DFDs.
Numbering of processes : If process ‘p’ in context diagram is split into 3
processes ‘p1’, ‘p2’and ‘p3’ in next level then these are labeled as 0.1, 0.2
and 0.3 in level 1 respectively. Let the process ‘p3’ is again split into three
processes ‘p31’, ‘p32’ and ‘p33’ in level 2, so, these are labeled as 0.3.1,
0.3.2 and 0.3.3 respectively and so on.
Balancing DFD: The data that flow into the process and the data that flow
out to the process need to be match when the process is split into in the
next level [2]. This is known as balancing a DFD.

38
Sample
Output

Post Draw DFD’s for the other project

Lab
Assg

39
 Experiment No:10

Title Test cases design and program testing for the chosen project.

Objecti The primary objective of this experiment is not to verify that all desired features have been
ve implemented correctly. However, it also includes verification of the software behavior in
case of "bad inputs".
Prerequ Knowledge of software testing
isite

Theory Introduction
Development of new software, like any other product, remains incomplete until it subjected
to exhaustive tests. The primary objective of testing is not to verify that all desired features
have been implemented correctly. However, it also includes verification of the software
behavior in case of "bad inputs".

In this experiment we discuss in brief about different types of testing, and provide
mechanisms to have hands-on experience on unit testing.

Software Testing
Testing software is an important part of the development life cycle of software. It is an
expensive activity. Hence, appropriate testing methods are necessary for ensuring the
reliability of a program. According to the ANSI/IEEE 1059 standard, the definition of
testing is the process of analyzing a software item, to detect the differences between
existing and required conditions i.e. defects/errors/bugs and to evaluate the features of the
software item.

The purpose of testing is to verify and validate software and to find the defects present in
software. The purpose of finding those problems is to get them fixed.

 Verification is the checking or we can say the testing of software for consistency
and conformance by evaluating the results against pre-specified requirements.
 Validation looks at the systems correctness, i.e. the process of checking that what
has been specified is what the user actually wanted.
 Defect is a variance between the expected and actual result. The defect’s ultimate
source may be traced to a fault introduced in the specification, design, or
development (coding) phases.

Standards for Software Test Documentation

IEEE 829-1998 is known as the 829 Standard for Software Test Documentation. It is an
IEEE standard that specifies the form of a set of documents for use in software testing
There are other different standards discussed below.

 IEEE 1008, a standard for unit testing

40
  IEEE 1012, a standard for Software Verification and Validation
 IEEE 1028, a standard for software inspections
 IEEE 1044, a standard for the classification of software anomalies
 IEEE 1044-1, a guide to the classification of software anomalies
 IEEE 830, a guide for developing system requirements specifications
 IEEE 730, a standard for software quality assurance plans
 IEEE 1061, a standard for software quality metrics and methodology
 IEEE 12207, a standard for software life cycle processes and life cycle data
 BS 7925-1, a vocabulary of terms used in software testing
 BS 7925-2, a standard for software component testing

Testing Frameworks
Following are the different testing frameworks:

 jUnit - for Java unit test

 Selenium - is a suite of tools for automating web applications for software testing
purposes, plugin for Firefox
 HP QC - is the HP Web-based test management tool. It familiarizes with the process
of defining releases, specifying requirements, planning tests, executing tests,
tracking defects, alerting on changes, and analyzing results. It also shows how to
customize project
 IBM Rational - Rational software has a solution to support business sector for
designing, implementing and testing software

Need for Software Testing

There are many reasons for why we should test software, such as:

 Software testing identifies the software faults. The removal of faults helps reduce
the number of system failures. Reducing failures improves the reliability and the
quality of the systems.
 Software testing can also improves the other system qualities such as
maintainability, usability, and testability.
 In order to meet the condition that the last few years of the 20th century systems had
to be shown to be free from the ‘millennium bug’.
 In order to meet the different legal requirements.
 In order to meet industry specific standards such as the Aerospace, Missile and
Railway Signaling standards.

Test Cases and Test Suite

A test case describes input descriptions and an expected output descriptions. Input are of
two types: preconditions (circumstances that hold prior to test case execution) and the
actual inputs that are identified by some testing methods. The set of test cases is called a
test suite. We may have a test suite of all possible test cases.

41
Types of Software Testing
Testing is done in every stage of software development life cycle, but the testing done at
each level of software development is different in nature and has different objectives. There
are different types of testing, such as stress testing, volume testing, configuration testing,
compatibility testing, recovery testing, maintenance testing, documentation testing, and
usability testing. Software testing are mainly of following types

1. Unit Testing
2. Integration Testing
3. System Testing

Unit Testing

Unit testing is done at the lowest level. It tests the basic unit of software, that is the smallest
testable piece of software. The individual component or unit of a program are tested in unit
testing. Unit testing are of two types.

 Black box testing: This is also known as functional testing , where the test cases
are designed based on input output values only. There are many types of Black Box
Testing but following are the prominent ones.

- Equivalence class partitioning: In this approach, the domain of input values to a

program is divided into a set of equivalence classes. e.g. Consider a software program that
computes whether an integer number is even or not that is in the range of 0 to 10.
Determine the equivalence class test suite. There are three equivalence classes for this
program. - The set of negative integer - The integers in the range 0 to 10 - The integer
larger than 10

- Boundary value analysis : In this approach, while designing the test cases, the values at
boundaries of different equivalence classes are taken into consideration. e.g. In the above
given example as in equivalence class partitioning, a boundary values based test suite is { 0,
-1, 10, 11 }

 White box testing: It is also known as structural testing. In this testing, test cases
are designed on the basis of examination of the code.This testing is performed based
on the knowledge of how the system is implemented. It includes analyzing data
flow, control flow, information flow, coding practices, exception and error handling
within the system, to test the intended and unintended software behavior. White box
testing can be performed to validate whether code implementation follows intended
design, to validate implemented security functionality, and to uncover exploitable
vulnerabilities.This testing requires access to the source code. Though white box
testing can be performed any time in the life cycle after the code is developed, but it
is a good practice to perform white box testing during the unit testing phase.

Integration Testing

Integration testing is performed when two or more tested units are combined into a larger
structure. The main objective of this testing is to check whether the different modules of a

42
 program interface with each other properly or not. This testing is mainly of two types:

 Top-down approach
 Bottom-up approach

In bottom-up approach, each subsystem is tested separately and then the full system is
tested. But the top-down integration testing starts with the main routine and one or two
subordinate routines in the system. After the top-level ‘skeleton’ has been tested, the
immediately subroutines of the ‘skeleton’ are combined with it and tested.

System Testing

System testing tends to affirm the end-to-end quality of the entire system. System testing is
often based on the functional / requirement specification of the system. Non-functional
quality attributes, such as reliability, security, and maintainability are also checked. There
are three types of system testing

 Alpha testing is done by the developers who develop the software. This testing is
also done by the client or an outsider with the presence of developer or we can say
tester.
 Beta testing is done by very few number of end users before the delivery, where the
change requests are fixed, if the user gives any feedback or reports any type of
defect.
 User Acceptance testing is also another level of the system testing process where
the system is tested for acceptability. This test evaluates the system's compliance
with the client requirements and assess whether it is acceptable for software
delivery

An error correction may introduce new errors. Therefore, after every round of error-fixing,
another testing is carried out, i.e. called regression testing. Regression testing does not
belong to either unit testing, integration testing, or system testing, instead, it is a separate
dimension to these three forms of testing.

Regression Testing

The purpose of regression testing is to ensure that bug fixes and new functionality
introduced in a software do not adversely affect the unmodified parts of the program [2].
Regression testing is an important activity at both testing and maintenance phases. When a
piece of software is modified, it is necessary to ensure that the quality of the software is
preserved. To this end, regression testing is to retest the software using the test cases
selected from the original test suite.

\
Sample LOGIN FORM:
Output

43
 Test

SL.No Test Case Excepted Result Result

Enter valid name and password & Software should display

1 click on login button main window Successful

Software should not

2 Enter invalid display main window successful

Post Design test cases for other system features

Lab
Assign
ment (If
Any)

44
 S.No.

9.
8.
7.
6.
5.
4.
3.
2.
1.

25.
24.
23.
22.
21.
20.
19.
18.
17.
16.
15.
14.
13.
12.
11.
10.
Name
Enroll No.
Date of Experiment :
Continuous Lab assessment sheet

Exp. Exectution (5)

Viva/File(5)

Exp. Exectution (5)

Viva/File(5)

Exp. Exectution (5)

Viva/File(5)

Exp. Exectution (5)

Viva/File(5)

45
Exp. Exectution (5)

Viva/File(5)
 Internal Lab Assessment (End Semester)
Lab Program with Total
S.No Enrollment No. Name file(10) Attendance(10) Quiz(10) Viva(10) Execution(10) (50)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

46
 A. Appendix
SOME GLOSSARIES in UML

 Abstract - An indicator applied to a classifier (e.g., actor, class, use case) or to some features
of a classifier (e.g., a class's operations) showing that the feature is incomplete and is intended
not to be instantiated, but to be specialized by other definitions.
 Abstract class - A class that does not provide a complete declaration, perhaps because it has
no implementation method identified for an operation. By declaring a class as abstract, one
intends to prohibit direct instantiation of the class. An abstract class cannot directly
instantiate objects; it must be inherited from before it can be used.
 Abstract operation - Unlike attributes, class operations can be abstract, meaning that there is
no provided implementation. Generally, a class containing an abstract operation should be
marked as an abstract class. An Operation must have a method supplied in some specialized
Class before it can be used.
 Abstraction is the process of picking out common features and deriving essential
characteristics from objects and procedure entities that distinguish it from other kinds of
entities.
 Classifier - a category of UML elements that have some common features, such as attributes
or methods.
 Client -
 Collaboration - Collaboration is a society of classes, interfaces and other elements that work
together to provide some cooperative behavior that is bigger than the sum of its parts.
 Communication diagram
 Component - A component represents a software module (source code, binary code,
executable, DLL, etc.) with a well-defined interface. The interface of a component is
represented by one or several interface elements that the component provides. Components
are used to show compiler and run-time dependencies, as well as interface and calling
dependencies among software modules. They also show which components implement a
specific class.

47