CS3CO40: Software Engineering Experiment no.

-01

Experiment Title: Identifying the Requirements from Page no.-01 to 07

Problem Statements

Objectives:
• Identify ambiguities, inconsistencies and incompleteness from a requirements
specification
• Identify and state functional requirements
• Identify and state non-functional requirements

Requirements:
Sommerville defines “requirement” as a specification of what should be implemented.
Requirements specify how the target system should behave. It specifies what to do, but not
how to do. Requirements engineering refers to the process of understanding what a customer
expects from the system to be developed, and to document them in a standard and easily
readable and understandable format. This documentation will serve as reference for the
subsequent design, implementation and verification of the system.
It is necessary and important that before we start planning, design and implementation of the
software system for our client, we are clear about it’s requirements. If we don’t have a clear
vision of what is to be developed and what all features are expected, there would be serious
problems, and customer dissatisfaction as well.

Characteristics of Requirements:
Requirements gathered for any new system to be developed should exhibit the following
three properties:
• Unambiguity: There should not be any ambiguity what a system to be developed
should do. For example, consider you are developing a web application for your
client. The client requires that enough number of people should be able to access the
application simultaneously. What’s the “enough number of people”? That could mean
10 to you, but, perhaps, 100 to the client. There’s an ambiguity.
• Consistency: To illustrate this, consider the automation of a nuclear plant. Suppose
one of the clients say that it the radiation level inside the plant exceeds R1, all reactors
should be shut down. However, another person from the client side suggests that the
threshold radiation level should be R2. Thus, there is an inconsistency between the
two end users regarding what they consider as threshold level of radiation.
• Completeness: A particular requirement for a system should specify what the system
should do and also what it should not. For example, consider a software to be
developed for ATM. If a customer enters an amount greater than the maximum
permissible withdrawal amount, the ATM should display an error message, and it
should not dispense any cash.
Categorization of Requirements:
Based on the target audience or subject matter, requirements can be classified into different
types, as stated below:
• User requirements: They are written in natural language so that both customers can
verify their requirements have been correctly identified
• System requirements: They are written involving technical terms and/or
specifications, and are meant for the development or testing teams
Requirements can be classified into two groups based on what they describe:
• Functional requirements (FRs): These describe the functionality of a system – how a
system should react to a particular set of inputs and what should be the corresponding
output.
• Non-functional requirements (NFRs): They are not directly related what
functionalities are expected from the system. However, NFRs could typically define
how the system should behave under certain situations. For example, a NFR could say
that the system should work with 128MB RAM. Under such condition, a NFR could
be more critical than a FR.
Non-functional requirements could be further classified into different types like:
• Product requirements: For example, a specification that the web application should
use only plain HTML, and no frames
• Performance requirements: For example, the system should remain available 24x7
• Organizational requirements: The development process should comply to SEI CMM
level 4

Functional Requirements:
Identifying Functional Requirements
Given a problem statement, the functional requirements could be identified by focusing on
the following points:
• Identify the high level functional requirements simply from the conceptual
understanding of the problem. For example, a Library Management System, apart
from anything else, should be able to issue and return books.
• Identify the cases where an end user gets some meaningful work done by using the
system. For example, in a digital library a user might use the “Search Book”
functionality to obtain information about the books of his interest.
• If we consider the system as a black box, there would be some inputs to it, and some
output in return. This black box defines the functionalities of the system. For example,
to search for a book, user gives title of the book as input and get the book details and
location as the output.

2
• Any high level requirement identified could have different sub-requirements. For
example, “Issue Book” module could behave differently for different class of users, or
for a particular user who has issued the book thrice consecutively.

Preparing Software Requirements Specifications:

Once all possible FRs and non-FRs have been identified, which are complete, consistent, and
non-ambiguous, the Software Requirements Specification (SRS) is to be prepared. IEEE
provides a template , also available here, which could be used for this purpose. The SRS is
prepared by the service provider, and verified by its client. This document serves as a legal
agreement between the client and the service provider. Once the concerned system has been
developed and deployed, and a proposed feature was not found to be present in the system,
the client can point this out from the SRS. Also, if after delivery, the client says a new feature
is3equireed, which was not mentioned in the SRS, the service provider can again point to the
SRS. The scope of the current experiment, however, doesn’t cover writing a SRS.

Exercise

3
4
5
6
Real Life Example
Developing a Mobile Banking App
Problem Statement

"Users are frustrated with our current mobile banking app because it is slow, difficult to navigate, and
lacks essential features like mobile check deposit and budgeting tools."

Steps to Identify Requirements

1. Understand User Frustrations

o Slow Performance: Users want the app to load quickly and respond promptly to
actions.
o Difficult Navigation: Users need an intuitive user interface (UI) that allows them to
find features easily.
2. Identify Essential Features
o Mobile Check Deposit: Users require a feature that allows them to deposit checks
using their phone's camera.
o Budgeting Tools: Users want tools to track spending, set budgets, and receive alerts for
spending limits.
3. Gather User Feedback
o Conduct surveys or focus groups to gather detailed feedback on what users specifically
dislike and what they would like to see improved.
4. Prioritize Requirements
o Rank the requirements based on user feedback and business goals (e.g., speed and
navigation improvements might take precedence over additional features).
5. Define Functional and Non-Functional Requirements
o Functional Requirements:
 The app must allow users to deposit checks.
 The app must include a budgeting feature that tracks expenses.
o Non-Functional Requirements:
 The app must load within 2 seconds.
 The app must have a user-friendly interface that can be navigated in under 3
clicks.

Conclusion

By breaking down the problem statement into specific user needs and priorities, you can create a clear
list of requirements to guide the development process, ultimately leading to a more successful and
user-friendly product.

7
CS3CO40: Software Engineering Experiment no.-02

Experiment Title : Modeling UML Use Case Page no.-08 to 19

Diagrams and Capturing Use Case Scenarios

Use case diagrams:

Use case diagrams belong to the category of behavioural 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 [1] 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 [2], [i] :
• 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 [1] a functionality provided by a system.
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 includes, 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.

8
Subject:
Subject is simply [iii] 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 shown in figure - 01.

Figure - 01: A use case diagram for a book store

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. Association 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
• Use case generalization

9
1. Include Relationship
Include relationships are used to depict common behaviour 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.

Figure - 02: Include relationship between use cases

Notation
Include relationship is depicted by a dashed arrow with a «include» stereotype from the
including use case to the included use case.

2. Extend Relationship
Use case extensions are used used to depict any variation to an existing use case. They are
used to the specify the changes required when any assumption made by the existing use case
becomes false [iv, v].

Example
Let's consider an online bookstore. The system allows an authenticated user to buy selected
book(s). While the order is being placed, the system also allows to specify any special
shipping instructions [vii], for example, call the customer before delivery. This Shipping
Instructions step is optional, and not a part of the main Place Order use case. Figure - 03
depicts such relationship.

10
Figure - 03: Extend relationship between use cases

Notation
Extend relationship is depicted by a dashed arrow with a «extend» stereotype from the
extending use case to the extended use case.

3. Generalization Relationship
Generalization relationship are used to represent the inheritance between use cases. A derived
use case specializes some functionality it has already inherited from the base use case.
Example
To illustrate this, consider a graphical application that allows users to draw polygons. We
could have a use case draw polygon. Now, rectangle is a particular instance of polygon
having four sides at right angles to each other. So, the use case draw rectangle inherits the
properties of the use case draw polygon and overrides it's drawing method. This is an
example of generalization relationship. Similarly, a generalization relationship exists between
draw rectangle and draw square use cases. The relationship has been illustrated in fogur-04.

.
Figure - 04: Generalization relationship among use cases
Notation

11
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
[2]:
• 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 are the functionality they can obtain from the system. Any use case name should
start with a verb like, "Check balance".

Guidelines for drawing Use Case diagrams

Following general guidelines could be kept in mind while trying to draw a use case diagram
[1]:
• 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 behaviour among use cases , if any
Also look at [ix] for further tips.

Exercise 1:
Draw a use case diagram for the following problem
Consider a library, where a member can perform two operations: issue book and return it. A
book is issued to a member only after verifying his credentials. Draw a use case diagram for
the problem.

12
Learning Objectives:
1. Identify the actors and use cases
2. Associate the use cases with the actors by drawing a simple use case diagram
Limitations: While extending a use case, extension points could not be defined through this
interface.

13
UML Case diagram for exercise 1

Exercise 2
Draw a use case diagram for the following problem
Consider your neighbouring travel agent from whom you can purchase flight tickets. To book
a ticket you need to provide details about your journey i.e. on which date and at what time
you would like to travel. You also need to provide your address. The agency has recently been
modernized. So you can pay either by cash or by card. You can also cancel a booked ticket
later if you decide to change your plan. In that case you need to book a new ticket again. Your
agent also allows you to book a hotel along with flight ticket. While canceling a flight ticket
you can also cancel hotel booking. Appropriate refund as per policy is made in case of
cancellation.

14
Learning Objectives:
1. Identify the use cases from a given non-trivial problem statement
2. Identify the primary and secondary actors for a system
3. Use to generalization of use cases and «include» stereotypes to prevent redundancy in
the coding phase
Limitations: While extending a use case, extension points could not be defined through this
interface.

15
16
Self evaluation

17
Real Life Example
Developing a Mobile Banking App
Problem Statement

"Users are frustrated with our current mobile banking app because it is slow, difficult to navigate, and
lacks essential features like mobile check deposit and budgeting tools."

Steps to Create UML Use Case Diagrams

1. Identify Actors
o User: The person using the mobile banking app.
o Bank System: The backend system that processes transactions and manages data.
2. Identify Use Cases
o Login: Users log into the app.
o View Account Balance: Users can view the balance of their accounts.
o Transfer Funds: Users can transfer money between their accounts.
o Deposit Check: Users can deposit checks using the app.
o Create Budget: Users can set up and manage a budget.
o View Transaction History: Users can see their past transactions.
3. Create Use Case Diagram
o Draw a system boundary box labeled "Mobile Banking App."
o Place the actors (User and Bank System) outside the box.
o Inside the box, represent each use case as an oval.
o Connect actors to use cases with lines to indicate interactions. For example:
 The User is connected to Login, View Account Balance, Transfer Funds,
Deposit Check, Create Budget, and View Transaction History.
 The Bank System may interact with use cases like Transfer Funds and
Deposit Check.

Use Case Scenarios

Use Case: Login

 Actors: User
 Preconditions: User has installed the app and has valid credentials.
 Postconditions: User is authenticated and redirected to the home screen.
 Main Flow:
1. User opens the app.
2. User enters username and password.
3. System validates credentials.
4. User is logged in and taken to the dashboard.

Use Case: Deposit Check

 Actors: User, Bank System

 Preconditions: User is logged in and has a check to deposit.
 Postconditions: Check is deposited, and balance is updated.

18
 Main Flow:
1. User selects "Deposit Check" option.
2. User takes a picture of the check using the app.
3. User enters the amount.
4. System submits the deposit request to the Bank System.
5. Bank System processes the deposit.
6. User receives confirmation of deposit.

Use Case: Create Budget

 Actors: User
 Preconditions: User is logged in.
 Postconditions: User's budget is saved.
 Main Flow:
1. User selects "Create Budget."
2. User enters budget category and amount.
3. User sets spending alerts if needed.
4. System saves the budget and displays it to the user.

Conclusion

By creating a UML Use Case Diagram and detailing use case scenarios, you establish a clear
understanding of user interactions and system functionalities. This helps in guiding the development
process and ensuring that the app meets user needs effectively.

19
CS3CO40: Software Engineering Experiment no.-03

Experiment Title : E-R Modeling from the Problem Page no.– 20 to 28

Statements

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

Theory
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:

20
• 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, andFrom
a given problem statement we identify the possible entity sets, their attributes, and

21
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:

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

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.

22
23
Exercise 2

24
Model

25
Self evaluation :

26
Real Life Example
Developing a Mobile Banking App
Problem Statement

"Users are frustrated with our current mobile banking app because it is slow, difficult to navigate, and
lacks essential features like mobile check deposit and budgeting tools."

Steps to Create an E-R Model

1. Identify Key Entities
o User: Represents the individuals using the app.
o Account: Represents the bank accounts linked to users (e.g., checking, savings).
o Transaction: Represents the transactions made by users (e.g., deposits, withdrawals).
o Check: Represents checks that users can deposit via the app.
o Budget: Represents the budgeting information set by users.
2. Define Relationships
o A User can have one or more Accounts. (One-to-Many)
o A User can perform multiple Transactions. (One-to-Many)
o A Transaction is linked to one Account. (Many-to-One)
o A User can deposit multiple Checks. (One-to-Many)
o A User can have one or more Budgets. (One-to-Many)
3. Attributes for Each Entity
o User:
 UserID (Primary Key)
 Name
 Email
 PhoneNumber
o Account:
 AccountID (Primary Key)
 UserID (Foreign Key)
 AccountType (e.g., checking, savings)
 Balance
o Transaction:
 TransactionID (Primary Key)
 AccountID (Foreign Key)
 TransactionDate
 Amount
 TransactionType (e.g., deposit, withdrawal)
o Check:
 CheckID (Primary Key)
 UserID (Foreign Key)
 Amount
 DateDeposited
o Budget:
 BudgetID (Primary Key)
 UserID (Foreign Key)
 BudgetAmount

27
 Category (e.g., groceries, entertainment)
4. Visual Representation
o In an E-R diagram, you would represent each entity as a rectangle, list its attributes
inside, and use lines to connect the entities based on their relationships. For example:
 Draw a line connecting User to Account labeled "has."
 Draw a line from User to Transaction labeled "performs."
 Connect Transaction to Account with "belongs to."
 Connect User to Check and Budget similarly.

Conclusion

This E-R model provides a structured overview of the data requirements for the mobile banking app,
allowing developers to understand how users interact with their accounts, transactions, checks, and
budgeting tools. This foundational design can guide database development and ensure that all
essential features are properly integrated.

28
CS3CO40: Software Engineering Experiment no.-04

Experiment Title :Modeling Data Flow Diagrams Page no.-29 to 33

Objectives
 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
Data store
is written inside the shape

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

Explanation of Symbols used in DFD

29
 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.
See simulation[ii] and case study[iii] of the experiment to understand data flow diagram in more real
context.

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

30
31
Real Life Example
Developing a Mobile Banking App
Problem Statement

"Users are frustrated with our current mobile banking app because it is slow, difficult to navigate, and
lacks essential features like mobile check deposit and budgeting tools."

Steps to Create Data Flow Diagrams

1. Identify External Entities

o User: The person using the app.
o Bank System: The backend system that processes transactions and manages data.
2. Identify Processes
o Authenticate User: Validates user credentials.
o Manage Accounts: Handles viewing balances, transferring funds, etc.
o Process Check Deposit: Manages the deposit of checks.
o Manage Budget: Handles creating and viewing budgets.
o Generate Transaction History: Provides users with their past transactions.
3. Identify Data Stores
o User Data Store: Contains user credentials and profiles.
o Account Data Store: Contains account details and balances.
o Transaction Data Store: Contains records of all transactions.
o Budget Data Store: Contains user budgets and spending limits.

Creating the Data Flow Diagram

1. Diagram Layout
o Place the external entities (User, Bank System) on the left.
o Identify and place processes (circles) in the center.
o Add data stores (open-ended rectangles) on the right.
2. Data Flows
o Draw arrows to indicate the flow of data between entities, processes, and data stores.

Example Data Flow Diagram

 User ➔ Authenticate User ➔ User Data Store (check credentials)

 User ➔ Manage Accounts ➔ Account Data Store (retrieve account info)
 Manage Accounts ➔ Transaction Data Store (fetch transaction history)
 User ➔ Process Check Deposit ➔ Account Data Store (update balance)
 Process Check Deposit ➔ Bank System (send deposit request)
 Bank System ➔ Transaction Data Store (record transaction)
 User ➔ Manage Budget ➔ Budget Data Store (create/view budget)

Example of Data Flow Descriptions

1. User Login Flow

32
o The User enters credentials, which flow into the Authenticate User process. This
process checks the User Data Store for valid credentials and returns a success or
failure message to the User.
2. Check Deposit Flow
o The User submits a check deposit request to the Process Check Deposit process. This
process updates the Account Data Store with the new balance and sends a deposit
request to the Bank System. Once processed, the transaction is recorded in the
Transaction Data Store.
3. Budget Management Flow
o The User creates or views a budget via the Manage Budget process, which interacts
with the Budget Data Store to save or retrieve budget data.

Conclusion

Creating Data Flow Diagrams helps visualize how data moves through the mobile banking app,
clarifying the relationships between users, processes, and data stores. This model aids in
understanding system requirements and guides development and testing efforts.

33
CS3CO40: Software Engineering Experiment no.-05

Experiment Title : Modeling UML Class Diagrams and Page no.-34 to 42

Sequence diagrams
Objectives
After completing this experiment you will be able to:
 Graphically represent a class, and associations among different classes
 Identify the logical sequence of activities undergoing in a system, and represent them
pictorially

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[1].
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
 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

34
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:
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

35
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

Figure-04:
 Composition [i]
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:

36
Figure-06:
Example
One vehicle may have two or more wheels

Figure-07:

Sequence diagram
It represents the behavioral aspects of a system[1]. Sequence diagram shows the interactions between
the objects[1] by means of passing messages from one object to another with respect to time[2] in 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[1]. 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[1].
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[1].
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[1] . There may exist some different types of
messages :

37
 Synchronous messages:Receiver start processing the message after receiving it and sender
needs to wait until it is made[iii]. A straight arrow with close and fill arrow-head from sender
life-line bar to receiver end, represent a synchronous message[iii].
 Asynchronous messages:For asynchronous message sender needs not to wait for the receiver
to process the message[iv]. A function call that creates thread can be represented as an
asynchronous message in sequence diagram[iv]. A straight arrow with open arrow-head from
sender life-line bar to receiver end, represent an asynchronous message[iii].
 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[iv]. We use this message when we
need to show the interaction between the same object.

Figure-08

38
39
Real Life Example
Developing a Mobile Banking App
Problem Statement

"Users are frustrated with our current mobile banking app because it is slow, difficult to navigate, and
lacks essential features like mobile check deposit and budgeting tools."

UML Class Diagram

Identify Classes

1. User
oAttributes: userID, name, email, phoneNumber
oMethods: login(), logout(), viewBalance(), createBudget()
2. Account
o Attributes: accountID, userID, accountType, balance
o Methods: getBalance(), transferFunds()
3. Transaction
o Attributes: transactionID, accountID, transactionDate, amount,
transactionType
o Methods: recordTransaction(), getTransactionHistory()
4. Check
oAttributes: checkID, userID, amount, dateDeposited
oMethods: depositCheck()
5. Budget
o Attributes: budgetID, userID, budgetAmount, category
o Methods: setBudget(), getBudgetDetails()

Class Diagram Representation

Associations:

o A User can have multiple Accounts (1 to many).

o A User can perform multiple Transactions (1 to many).
o A User can have multiple Checks (1 to many).
o A User can create multiple Budgets (1 to many).

Here’s a textual representation of the class diagram structure:

Scss
Copy code
+----------------+ +-----------------+
| User |<>------- | Account |
|----------------| |-----------------|
| - userID | | - accountID |
| - name | | - userID |
| - email | | - accountType |
| - phoneNumber | | - balance |
|----------------| |-----------------|

40
| + login() | | + getBalance() |
| + logout() | | + transferFunds()|
+----------------+ +-----------------+
| |
| |
| |
| |
| |
v v
+----------------+ +-----------------+
| Transaction | | Check |
|----------------| |-----------------|
| - transactionID| | - checkID |
| - accountID | | - userID |
| - transactionDate| | - amount |
| - amount | | - dateDeposited |
| - transactionType| |-----------------|
|----------------| | + depositCheck() |
| + recordTransaction()| +-----------------+
| + getTransactionHistory()|
+----------------+
|
|
|
v
+----------------+
| Budget |
|----------------|
| - budgetID |
| - userID |
| - budgetAmount |
| - category |
|----------------|
| + setBudget() |
| + getBudgetDetails()|
+----------------+
UML Sequence Diagram
Identify the Use Case: Mobile Check Deposit

1. Actors: User, Mobile Banking App, Bank System

2. Sequence of Events:
o User initiates the check deposit.
o Mobile Banking App captures check details.
o Mobile Banking App sends the deposit request to the Bank System.
o Bank System processes the deposit and returns a confirmation.
o Mobile Banking App updates the User's account balance.
o Mobile Banking App notifies the User of the successful deposit.

Sequence Diagram Representation

41
sql
Copy code
User Mobile Banking App Bank System
| | |
|--- initiate deposit ------>| |
| |--- capture check details ------->|
| | |
| |--- send deposit request -------->|
| | |
| |<--- confirmation ----------------|
| | |
|--- update balance -------->| |
| |--- notify user of success ------>|
| | |
Conclusion

Creating UML Class Diagrams and Sequence Diagrams helps clarify the structure and behavior of the
mobile banking app. The Class Diagram outlines the relationships and methods for each class, while
the Sequence Diagram illustrates how different components interact during specific use cases, like
mobile check deposit. Together, these models support the design and development process by
providing clear blueprints of the system.

42