GREATATER NOIDA INSTITUTE OF TECHNOLOGY GREATATER NOIDA

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

LIST OF EXPERIMENTS

Course: B.Tech Semester: VI Session: 2022-23

Branch: CSE Subject Code & Name: KCS-651, Software Engineering Lab

1. Prepare a SRS document in line with the IEEE recommended standards.

2. Draw the use case diagram and specify the role of each of the actors.
Also state the precondition, post condition and function of each use
case.
3. Draw the activity diagram.
4. Identify the classes. Classify them as weak and strong classes and draw the class
diagram.
5. Draw the sequence diagram for any two scenarios.
6. Draw the collaboration diagram.
7. Draw the state chart diagram.
8. Draw the component diagram.

Dr. Suneet Shukla, Ms. Anupma Surya Dr. Sandeep Saxena

H.O.D (CSE)
(Subject Teachers)
 GREATATER NOIDA INSTITUTE OF TECHNOLOGY GREATATER
NOIDA

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

LAB MANUAL

COURSE : B.Tech (CSE)

SEMESTER : VI

SUBJECT : Software Engineering Lab

SUBJECT CODE : KCS-651

PREPARED BY

Faculty Name: Dr. Suneet Shukla Dr. Sandeep Saxena

Faculty Name: Ms. Anupma Surya H.O.D (CSE)
 Experiment No-1

Objective: Prepare an SRS Document in line with the IEEE recommended Standard for
Library Management Software System.

Introduction of SRS:

SRS stands for Software Requirements Specification, which is a document that fully describes
the expected behaviour of a software system.
Functional requirements are documented in an SRS, as are Non-functional requirements such as
performance goals and descriptions of Quality attributes.

Categories of Customer Requirements:-

1-Functional Requirements (FR) 2-Non-Functional Requirements (NFR)

1-Functional Requirements:-
The functional requirements describe the functionality or services that software should provide.
It is also known as Behavioural Requirements.
The Functional requirement of the software system should clearly describe each function which the
system would support along with the corresponding input and output data set.
NOTE: Each function Fi of the system can be considered as reading certain data Ii and then
transformation of a set of input data to the corresponding set of output data Oi.

Figure 1: View of a System which performs a set of Functions

Examples of a Functional Requirement:-

1)In case of “Library Automation Software”, the” Search book” is a functional requirement and it
involves accepting a book name from the user, running a matching algorithm on the book list and
finally outputting the marched books or error message.

2)In case of “ATM” the “Withdraw-cash” is a functional requirement and it involves accepting (the
type of account, account number and amount that is withdrawn) from the user and then system
checks the balance available in the account and finally provides the required cash, otherwise it
generates an error message.

2-Non-Functional Requirements:-
The non-functional requirements deal the characteristics of a system that cannot be expressed as
functions.
The non-functional requirements are also known as Quality Requirements.
Non –functional requirements address the aspects about Reliability, Response time, Portability,
Usability, Maintainability, throughout, accuracy of results and human - computer interface issues.
Thus, non-functional requirements should be added in software to make it perform efficiently.

Software Requirements Specification (SRS) for Library Management

Software System

Table of Contents
Table of Contents ................................................................................................ iii
1. Introduction ..................................................................................................... 4
1.1 Purpose ............................................................................................................ 4
1.2 Document Conventions ................................................................................... 4
1.3 Intended Audience and Reading Suggestions ................................................. 4
1.4 Product Scope .................................................................................................. 4
1.5 References .........................................................................................................4
2. Overall Description .......................................................................................... 4
2.1 Product Perspective ......................................................................................... 4
2.2 Product Functions ............................................................................................ 5
2.3 User Classes and Characteristics ..................................................................... 5
2.4 Operating Environment ................................................................................... 6
2.5 Design and Implementation Constraints ......................................................... 6
2.6 User Documentation ........................................................................................ 6
2.7 Assumptions and Dependencies ...................................................................... 6
3. External Interface Requirements .................................................................... 7
3.1 User Interfaces ................................................................................................. 7
3.2 Hardware Interfaces ........................................................................................ 8
3.3 Software Interfaces .......................................................................................... 8
3.4 Communications Interfaces ............................................................................. 8
4. System Features ..............................................................................................8
4.1 System Feature 1 ............................................................................................. 8
4.2 System Feature 2 (and so on) ........................................................................ 10
5. Other Nonfunctional Requirements .......................................................... 10
5.1 Performance Requirements ........................................................................... 10
5.2 Safety Requirements…………………………………………………...…...10
5.3 Security Requirements .................................................................................. 11
5.4 Software Quality Attributes .......................................................................... 11

1. Introduction
1.1 Purpose
• To automate the library of college.
• To manage the records of book and user.
• To save the time and reduce the paper work.
• To provide the 24*7 hours service.
• To check the progress of development.

1.2 Document Conventions

• To make this Software Requirement Specification (SRS) document IEEE
standard is used.

1.3 Intended Audience and Reading Suggestions

• Software developer
• Software tester
• Software architecture
• Customer
• User (faculty member, member, library staff)

1.4 Product Scope

• To automate the library of college.
• To manage the records of book and user.
• To save the time and reduce the paper work.
• To provide the 24*7 hours service

2. Overall Description

2.1 Product Perspective

This system is used for Library Manager, Librarian, and Library User. The system
is self-contained. However, it is possible to exchange data with other system
through external interface if required. The Online Library System is a package to
be used by Libraries to improve the efficiency of Librarians, Library employees
and Users. The Online Library System to be developed benefits greatly the
members and the Librarian of institute. The system provides books catalog and
information to members and helps them decide on the books to borrowfrom the
library.

2.2 Product Functions

There are two different users who will be using this product:
a) Librarian who will be acting as the administrator
b) Student of the University who will be accessing the Library online.

The features that are available to the Librarian are:

a) A librarian can issue a book to the student
b) Can view the different categories of books available in theLibrary
c) Can view the List of books available in each category
d) Can take the book returned from students
e) Add books and their information of the books to the database
f) Edit the information of the existing books. 
g) Can check the report of the issued Books.
h) Can access all the accounts of the students. The features available to the Students are:
i) Can view The different categories of books available in theLibrary
j) Can view the List of books available in each category.
k) Can put a request for a new book.
2.3 User Classes and Characteristics

We have 3 levels of users:

• User module: In the user module, user will check the availability of the books.

 Issue book
 Reserve book
 Return book
 Fine details

• Library module:

 Add new book

 Remove books
 Update details of book

• Administration module: The following are the sub module in the administration:

 Register user
 Entry book details
 Book issue.

2.4 Operating Environment

The product will be operating in windows environment. Also it will be compatible

with the IE 6.0. Most of the features will be compatible with the Mozilla Firefox &
Opera 7.0 or higher version. The only requirement to use this online product would
be the internet connection.

2.5 Design and Implementation Constraints

The Product is developed using ASP. The backend database for this SQL server.
The product is accomplished with login facility so that specific function is
available to specific student.
2.6 User Documentation

The product will include user manual. The user manual will include product
overview, complete configuration of the used software (such as SQL server),
technical details, backup procedure and contact information which will include
email address. There will be no online help for the product at this moment. The
product will be compatible with the Internet Explorer 6.0 or higher. The databases
will be created in the Microsoft SQL server 2000.

2.7 Assumptions and Dependencies

The product needs following third party product.

Microsoft SQL server to store the database.
ASP to develop the Product

3. External Interface Requirements

The product needs following third party applications for the development of the
project:
• Android Studio (for development of android based applications)
• Net beans
• Photoshop (for editing layouts, icons, buttons, etc.)

3.1 User Interfaces

The user interface requirements are concerned with the user interface and how
information is presented to the user.
-> Usability
Interfaces are a critical class of components within the DML that will provide the
means by which users interact with the system. As such, all interfaces should
provide easy access to help as well as clearly indicate the current state of the user’s
transaction when the user isn’t idle.
Transaction and error status MUST be displayed within each interface component.

Administrative:
Administrative interfaces will assist Library Staff in building/maintaining
collections and controlling access to them. Because of the complexity of the data
model, Library Staff will need to be able to edit multiple records simultaneously
and create links between them.
Administrative MUST be able to have multiple records open for editing.
Administrator MUST be able to create links (references) between records without
needing to type in record identifiers.

3.2 Hardware Interfaces

• Android version 2.3 ginger bread(minimum, android user’s)
• 2 GB RAM
• 1.2 GHz processor
• Intel i5
• Windows 7/8/8.1/10

3.3 Software Interfaces

• A firewall will be used with the server to prevent unauthorized access to the
system.
3.4 Communications Interface
• The Online Library System will be connected to the World Wide Web.

4. System Features
4.1 Database Storage
4.1.1. Description and Priority
Proposed Database is intended to store, retrieve, update, and manipulate
information related to university which includes:
a) Books availability
b) Staff information
c) Student details
d) My Account
e) Calculation of fines
4.1.2. Stimulus / Response Sequences

1. Responses for Administrator:

The administrator can Login and Logout. When the Administrator Logs into the
Library system. The system will check for validity of login. If the Login and
password are valid, the response to this action is the administrator will be able to
modify, view, add, deleting and all other functions that can be performed on the
database.
4.2. Functional Requirements
This section gives the list of Functional and no functional requirements which are
applicable to the Library Management System.

4.2.1 Interface Requirements

This section describes how the software interfaces with other software products or
users for input or output.

4.2.2.1UserInterfaces
Describes how this product interfaces with the user.
GUI
Describes the graphical user interface if present. This section should include a set
of screen dumps or mock-ups to illustrate user interface features.
1. Description
The user interface must be customizable by the administrator
2. Criticality
This issue is essential to the overall system. All the modules provided with the
software must fit into this graphical user interface and accomplish to the standard
defined.
3. Technical issues
In order to satisfy this requirement, the design should be simple and all the
different interfaces should follow a standard template. There will be the possibility
of changing colors and images.
4. Software
It is used to switch between interfaces with the minimum impact for the users.
5. Risks
To reduce the circumstances under which this requirement might not able to be
satisfied, all the designers must have been developed web sites previously and they
must be aware of html restriction and cross browsers implementations before
starting the designing. In order to reduce the probability of this occurrence the
entire design team will be trained in basic html development and macromedia
fireworks, this tool will be used instead of Photoshop.
6. Dependencies with other requirements
All user interfaces should be able to interact with the user management module and
a part of the interface must be dedicated to the login/logout module.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

•This software is not breakdown suddenly in any disaster like power failure.
The development of the software will be based on the object oriented model.
•The timeline of this software must be in our mind.
•The performance of the functions and every module must be well.
•At every step the output of the one phase is the input of the other phase and it will
be reliable and accurate.
•The risk factor must be taken at initial step for better performance of the software.
•For individual function the performance will be well.
•For login to the software password and user name will be matched to the pass
word and name
•saved in the database and thus only authenticated users are allowed to the login.
•There will be various ways of retrieving data and it takes less time.
•There will be ambiguity in the data and the record
5.2 Safety Requirements
The database may get crashed at any certain time due to virus or operating system
failure. Therefore, it is required to take the database backup.
5.3 Security Requirements
•There will be proper security regarding to the accessing of data.
•The external security can be provided by given the login authentication.
•The data that are stored in the database must be private.
•There is also required a user authentication.
•There is also the facility that the admin can lock his private data that will not be
accessed by anyone.
•The whole software is secure from the outside accessing

5.4 Software Quality Attributes

Our software has many quality attribute that are given below-
Adaptability
This software is adaptable by any organization.
Availability-
The availability of the software is easy and for everyone.
Correctness-
The results of the function are pure and accurate.
Flexibility-
The operation may be flexible and reports can be presented in many ways.
Maintainability-
After the deployment of the project if any error occurs then it can be easily
maintain by the software developer.
Portability-
The software can be deployed at any machine.
Reliability-
The performance of the software is better which will increase the reliability of the
software.
Reusability-
The data and record that are saved in the database can be reused if needed.
Robustness-
If there is any error in any window or module then it does not effect the remaining
part of the software.
Testability-
The software will be tested at every .Alpha Testing Beta Testing Acceptance
Testing
Usability-
To performs any operations and to understand the functioning of software is very
easy.
Productivity-
This software will produce every desired result with accurately.
Timelines-
The time limit is very important. It will save much time and provide fast accessing.
Cost effective-
This software is less in cost and bearable by any organization.

5.5 Business Rules

• A business rule is anything that captures some business policies and practice. A
rule can enforce business policies, make a decision or infer a new data from
existing data.
• This includes the rules and regulations that a user must obey.
• This includes the cost of the project and the discount offered provided.
• The user should avoid illegal rules and protocols; neither admin nor user should
cross the rules and regulations.

Viva Voice Questions:

1. What is SRS?

2. What is the significance of SRS?

3. What are the desired characteristics of good SRS.

4. What is the input and output of analysis phase?

5 How to design the SRS Documents?

 Experiment No-2

Obective: Draw the use case diagram and specify the role of each of the
actors

Use case diagrams

Use case diagrams describe what a system does from the standpoint of an external
observer. The emphasis is on what a system does rather than how.

Use case diagrams are closely connected to scenarios. A scenario is an example of

what happens when someone interacts with the system. Here is a scenario for a
medical clinic.

"A patient calls the clinic to make an appointment for a yearly checkup. The
receptionist finds the nearest empty time slot in the appointment book and
schedules the appointment for that time slot. "

A use case is a summary of scenarios for a single task or goal. An actor is who or
what initiates the events involved in that task. Actors are simply roles that people
or objects play. The picture below is a Make Appointment use case for the
medical clinic. The actor is a Patient. The connection between actor and use case
is a communication association (or communication for short).

Actors are stick figures. Use cases are ovals. Communications are lines that link
actors to use cases.
A use case diagram is a collection of actors, use cases, and their communications.
We've put Make Appointment as part of a diagram with four actors and four use
cases. Notice that a single use case can have multiple actors.

Use case diagrams are helpful in three areas.

 Determining features (requirements). New use cases often generate new

requirements as the system is analyzed and the design takes shape.
 Communicating with clients. Their notational simplicity makes use case
diagrams a good way for developers to communicate with clients.
 Generating test cases. The collection of scenarios for a use case may
suggest a suite of test cases for those scenarios.

Viva Voice Questions:

1. What is Use case?

2. How use case is useful in generating test cases.
3. What all are the actors in use case diagram.
4. Explain the significance of Use Case diagram.
5. Describe the concepts of UML.
 Experiment No-3

Objective: Identify entity sets, their attributes, and various relationships. Represent
the data model through ER diagram.

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.

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 person interacts 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 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

Entity set Name of the set is written inside the rectangle

Attribute Name of the attribute is written inside the ellipse

Entity with
Roll is the primary key; denoted with an underline
attributes

Weak entity set

Relationship set Name of the relationship is written inside the diamond

Related enity
sets

Relationship A person can own zero or more cars but no two

cardinality persons can own the same car

Relationship
with weak entity
set

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

Figure - 01: Steps to implement a RDBMS

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.

Viva Voice Questions:

1. What is an ER Diagram?
2. How do you represent weak entities in ER diagrams?
3. How can cardinality be applied to relationships in ER diagrams?
4. What does it mean to generalize/specialize an object in an ER diagram?
5. What is an identifying relationship?
 Experiment No-4

Objective : Identify the classes. Classify them as weak and strong classes and draw
the class diagram.

Class diagrams

A Class diagram gives an overview of a system by showing its classes and the relationships
among them. Class diagrams are static -- they display what interacts but not what happens when
they do interact.

The class diagram below models a customer order from a retail catalog. The central class is the
Order. Associated with it are the Customer making the purchase and the Payment. A Payment
is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items),
each with its associated Item.
UML class notation is a rectangle divided into three parts: class name, attributes, and operations.
Names of abstract classes, such as Payment, are in italics. Relationships between classes are the
connecting links.

Our class diagram has three kinds of relationships.

 Association -- a relationship between instances of the two classes. There is an association

between two classes if an instance of one class must know about the other in order to
perform its work. In a diagram, an association is a link connecting two classes.
 Aggregation -- an association in which one class belongs to a collection. An aggregation
has a diamond end pointing to the part containing the whole. In our diagram, Order has a
collection of OrderDetails.
 Generalization -- an inheritance link indicating one class is a superclass of the other. A
generalization has a triangle pointing to the super class. Payment is a super class of
Cash, Check, and Credit.
An association has two ends. An end may have a role name to clarify the nature of the
association. For example, an OrderDetail is a line item of each Order.

A navigability arrow on an association shows which direction the association can be traversed or
queried. An OrderDetail can be queried about its Item, but not the other way around. The arrow
also lets you know who "owns" the association's implementation; in this case, OrderDetail has
an Item. Associations with no navigability arrows are bi-directional.
The multiplicity of an association end is the number of possible instances of the class associated
with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In
our example, there can be only one Customer for each Order, but a Customer can have any
number of Orders.

This table gives the most common multiplicities.

Multiplicities Meaning

0..1 zero or one instance. The notation n . . m indicates n tom instances.

0..* or * no limit on the number of instances (including none).

1 exactly one instance

1..* at least one instance

Every class diagram has classes, associations, and multiplicities. Navigability and roles are
optional items placed in a diagram to provide clarity.

Viva Voice Questions:

1. Why class diagram is required in designing phase.

2. What are the different relationships that can exist between classes?
3. What is the importance of multiplicity in class diagram?
4. Difference between strong and weak class.
5. Explain the concept of aggregation and association.
 Experiment No-5
Objective: Draw the activity diagram.

Activity diagrams

An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams
are related. While a state chart diagram focuses attention on an object undergoing a process (or
on a process as an object), an activity diagram focuses on the flow of activities involved in a
single process. The activity diagram shows the how those activities depend on one another.

For our example, we used the following process.

"Withdraw money from a bank account through an ATM."

The three involved classes (people, etc.) of the activity are Customer, ATM, and Bank. The
process begins at the black start circle at the top and ends at the concentric white/black stop
circles at the bottom. The activities are rounded rectangles.

Activity diagrams can be divided into object swimlanes that determine which object is
responsible for which activity. A single transition comes out of each activity, connecting it to
the next activity.

A transition may branch into two or more mutually exclusive transitions. Guard expressions
(inside [ ]) label the transitions coming out of a branch. A branch and its subsequent merge
marking the end of the branch appear in the diagram as hollow diamonds.

A transition may fork into two or more parallel activities. The fork and the subsequent join of
the threads coming out of the fork appear in the diagram as solid bars.

Viva Voice Questions:

 1. what is the Importance of activity diagram in designing.
2. What is transition & swimlanes and their importance in activity
diagram.
3. Why we use fork & join in activity diagram.

Experiment No-6

Objective : Identify the classes. Classify them as weak and strong classes and draw
the class diagram.

Class diagrams

A Class diagram gives an overview of a system by showing its classes and the relationships among
them. Class diagrams are static -- they display what interacts but not what happens when they do interact.

The class diagram below models a customer order from a retail catalog. The central class is the Order.
Associated with it are the Customer making the purchase and the Payment. A Payment is one of three
kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated
Item.
 UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names
of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links.

Our class diagram has three kinds of relationships.

 Association -- a relationship between instances of the two classes. There is an association

between two classes if an instance of one class must know about the other in order to perform its
work. In a diagram, an association is a link connecting two classes.
 Aggregation -- an association in which one class belongs to a collection. An aggregation has a
diamond end pointing to the part containing the whole. In our diagram, Order has a collection of
OrderDetails.
 Generalization -- an inheritance link indicating one class is a superclass of the other. A
generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check,
and Credit.
An association has two ends. An end may have a role name to clarify the nature of the association. For
example, an OrderDetail is a line item of each Order.

A navigability arrow on an association shows which direction the association can be traversed or queried.
An OrderDetail can be queried about its Item, but not the other way around. The arrow also lets you
know who "owns" the association's implementation; in this case, OrderDetail has an Item. Associations
with no navigability arrows are bi-directional.
The multiplicity of an association end is the number of possible instances of the class associated with a
single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our example,
there can be only one Customer for each Order, but a Customer can have any number of Orders.

This table gives the most common multiplicities.

Multiplicities Meaning

0..1 zero or one instance. The notation n . . m indicates n tom instances.

0..* or * no limit on the number of instances (including none).

1 exactly one instance

1..* at least one instance

Every class diagram has classes, associations, and multiplicities. Navigability and roles are optional items placed in
a diagram to provide clarity.

Viva Voice Questions:

1. Why class diagram is required in designing phase.

2. What are the different relationships that can exist between classes?
3. What is the importance of multiplicity in class diagram?
4. Difference between strong and weak class.
5. Explain the concept of aggregation and association.
 Experiment No-7

Objective: Draw the sequence diagram Sequence diagrams

Class and object diagrams are static model views. Interaction diagrams are dynamic. They
describe how objects collaborate.

A sequence diagram is an interaction diagram that details how operations are carried out -- what
messages are sent and when. Sequence diagrams are organized according to time. The time
progresses as you go down the page. The objects involved in the operation are listed from left to
right according to when they take part in the message sequence.

Below is a sequence diagram for making a hotel reservation. The object initiating the sequence
of messages is a Reservation window.
The Reservation window sends a makeReservation() message to a HotelChain. The
HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has
available rooms, then it makes a Reservation and a Confirmation.

Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a
message call. An arrow goes from the sender to the top of the activation bar of the message on
the receiver's lifeline. The activation bar represents the duration of execution of the message.

In our diagram, the Hotel issues a self call to determine if a room is available. If so, then the
Hotel creates a Reservation and a Confirmation. The asterisk on the self call means iteration
(to make sure there is available room for each day of the stay in the hotel). The expression in
square brackets, [ ], is a condition.

The diagram has a clarifying note, which is text inside a dog-eared rectangle. Notes can be put
into any kind of UML diagram.

Viva Voice Questions:

 1. What is the importance of sequence diagram?
2. How messages are passed in sequence diagram between objects.
3. Explain the concept of Message passing.

Experiment No-8

Objective: Identify external entities and functionalities of any system. Identify the flow of data
across the system. Represent the flow with Data Flow Diagrams.

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; name of the data store is written inside
Data store
the shape

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 [2] .
 External entity: External entities are only appear in context diagram[2]. 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 diagram. 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.

Note :
1. External entities only appear in context diagram[2] i.e, only at level 0.
2. Keep number of processes at each level less than 7[i].
3. Data flow is not possible in between two external entities and in between two data
stores[i].
4. Data cannot flow from an External entity to a data store and vice-versa[i].

Viva Voice Questions:

1. Why do we need to use a data flow system?

2. What are the main components of data flow architecture?
3. What is DFD level 0?