Software Engineering and Project Management Lab Report

Lab experiment 5

Name: Khushi Chadha

Roll no.:R2142220096
Sap_ID:500101728
Program, Semester, Batch: B.Tech CSE( FULL STACK AI)-SEM4-B1
Date of experiment: 10/02/24

School of Computer Science,University of Petroleum and Energy Studies,Dehradun

Aim-
1)Detailed study of data flow diagrams (Level 0,1,2)
2) study of use case diagram(functional requirement)
3)ATM system use case diagram

1)Detailed study of data flow diagrams

A Data Flow Diagram (DFD) is a graphical language used to provide excellent communication with
the users, managers and also other personnel about the data flow in a system.

DFDs can be used to analyse the existing or proposed systems.

The main elements of a DFD are:

the source or the sink (external entities).

Data flow
Processes
Data store (or database)
Output

A source or sink is an entity that provides a lot of data to the system (source) or extracts a lot of data
from the system (sink).

Data flow is shown with an arrow and demonstrates the way the data is moving.
Processes are displayed with a Circle and showcase the work that is being performed.
Data store or database is mentioned with parallel lines and holds the data for the system.
Rules of data flow:

• Data is transferred from an external party to a process.

• Data can be sent from one process to the external agent.
• Processes can employ a database in the backend.
• And data can move back from the processes to the store (database).
• Processes can talk to one another.

Invalid data flow scenarios:

• External to external.
• External entity to store.
• Store to external entity.
• Store to store.

Context diagrams:
It is overview of the system
Levels of DFD diagrams:
DFDs (Data Flow Diagrams) need to have more than one level to correctly represent processes.
The DFD levels by no means constitute an entire diagram in one level; they usually start from level
0 and can go to level 2 and above.

Level 0 in a DFD is the most fundamental level depicting high-level processes. Here, the student
applies to join while the admin handles the admission.

Level 0
Level 1 specifies the processes of Level 0 more. In this example, the admission process is divided
into three parts: carrying out the intake procedure, keeping the information and creating reports.

Level 1

Level 2 further decomposes the processes at Level 1 in smaller sub-processes. Therefore the depart-
ment can be medical, dental, nursing, health or other technical unit in the educational field, etc.
 Level 2

The process called 'Maintain' at Level 1 can also be further subdivided into some steps at Level 2.
Those smaller steps are verifying an applicant’s eligibility, calculating the sum of scores and check-
ing if there are seats available.

Level 0 of DFD deals with the entities and processes whereas levels 1 and 2 consider the sub-
processes and details of the processes.

Types of DFD diagrams

Logical DFD – A Logical DFD which describes how the business works. For this one, processes are
anything that you do in your business. These charts are also populated with external entities such as
data stores as well as the data flow between the processes and entities. Datastores are interpreted as
data storage location de finitions with no information on how it is stored.

Physical DFD – A physical DFD is an implementation schema. This information is the foundation
for building the system. This may be referred to as technical specifications where it contains hard-
ware and software components as well as people that may be involved.

Advantages or Features of the Data Flow Diagram

The following are the advantages of using the data flow diagrams:The following are the advantages
of using the data flow diagrams:
• DFD illustrates the sequence of operation of data within the system.

• For system design, attributes related to physical construction requirements are defined.

• It is necessary for both the system analyst and the customer to understand the business processes
in the process of the requirement analysis stage.

• Simple symbols and syntax used by it, that can be understood by all, even those who have no
technical background, simplify the lives of the customers.

• It also plays as support for the developers because it is depiction of the various processes, entities,
data stores, and data flow of the system.

• It enables not only just the system scope being defined along with the boundaries and relations to
other systems but also the dependencies.

• Therefore, due to that fact that we have many levels of DFD and each level of DFD describes ele-
ments on a low level of details, it assists us not only in understanding the overall system, but also
in the detailed description of processes.

Conclusion
Data flow diagrams are a valuable tool since they give the most complete view of system business
processes, external entities supplying and requesting data, as well as data flows indicating data flow
and data stores. DFD is a key part of the requirements elicitation and analysis (REA) phase of the
software development process which is of benefit to various stakeholders, such as analysts, cus-
tomers and the development team.

2)Use case diagrams

Use case diagrams are simplified representations of relationships between actors, systems and use
cases.

They do not depict the steps of achieving goals or non-functional requirements such as business
rules or service level.

Use case diagrams shall not contain more than 20 use cases. Other UML diagrams can be used to
capture internal parts of a system.
The actors are those who interact with the system, usually in a particular role. They invoke use
cases and expect certain system interaction behaviours.

A use case is an automatic or manual system function or process. Each actor should be linked to at
least one use case. Use cases describe what is expected to happen but they do not tell how to imple-
ment it. They may be expressed in text or graphical form.

Creation of use cases will then allow for the system to be designed from the end-user's point of
view.
Actor and use case communicate through messages, and associations indicate them.
The system boundaries for large systems may contain multiple modules, each of which forms a
boundary for use cases specific to its business function.
Use cases form various relationships: extending, including, and generalisation.
The "extends" relationship demonstrates extra functionality or behaviour of the basic use case.
The "includes" relationship indicates that an instance of the base use case will include the behaviour
in accordance with the definition in the child use case.
Generalisation or inheritance is a parent-child relation where the child use case inherits behaviour
and semantics from the parent use case.

Use case diagrams can concisely illustrate complicated systems having only a few use cases.

Components:

Do’s for modelling use case diagrams:

Structure and organise the diagram from an actor's perspective.
Start with high-level, simple use cases and go towards refinement and detail.
Functionality should take precedence over the implementation.

• Use cases are typically written in plain English, and in the form "noun verb phrase," such
as "Withdraw Funds" or "Print Report."
• Use case diagrams can be used to identify and organise system requirements, facilitate
communication between stakeholders, and visualise system behaviour.
• To create a use case diagram, follow these steps:
• Identify the actors: people or external systems that will interact with the system.
• Identify the use cases: the system functions and processes required to meet the actors'
goals.
• Identify the relationships between the actors and use cases: associations that indicate which
actors are involved in each use case.
• Use cases can have various attributes, such as:
• Name: a brief, descriptive title for the use case.
• Description: a detailed description of the use case's purpose and behaviour.
• Preconditions: the conditions that must be met before the use case can occur.
• Normal Flow: the typical sequence of events that occurs during a use case.
• Alternate Flows: alternative paths that can occur during a use case, triggered by specific
conditions.
• Exception Flows: unexpected circumstances that may occur during a use case, such as error
conditions or system failures.
• Use case diagrams are an essential part of the UML (Unified Modelling Language) family
of diagrams, used to model and visualise software systems.
• Creating use case diagrams can help identify and analyse system requirements, facilitate
communication and collaboration between stakeholders, and ensure that the final system
meets the needs of its users.
• Use case diagrams can be used to model systems of any size, from small, simple applica-
tions to large, complex systems with multiple actors and use cases.
•
In summary, use case diagrams are a valuable tool for modelling and visualising software systems.
They provide a clear, concise overview of the system's functionality and help ensure that the final
product meets the needs of its users. By understanding the fundamental components of use case dia-
grams, including actors, use cases, and relationships, you can effectively model and analyse com-
plex systems.

3)Case study: ATM use case diagram

The given use case diagram is for an Automated Teller Machine (ATM) system. The diagram pro-
vides a description of the behaviour and interaction of the system with the external users/actors. The
key components of this UML use case diagram include many actors, use cases and also relations.

Actors:

1. Customer: The user of the ATM system who does the things such as checking account balances,
depositing the funds, withdrawing cash and transferring funds is the primary user.
2.ATM Technician: The ATM technician was very hard to reach.
3.Bank: An agent that initiates the transaction and also represents the bank's involvement in that
transaction, either made by the customer or the ATM worker.

Use Cases:
1.Check Balances: The customer can get the balances of all their bank accounts with the ATM.
2.Deposit Funds: Customer deposits a lot of money into his bank account via the ATM.
3.Withdraw Cash: The customer can withdraw cash from the bank using the ATM.
4.Transfer Funds: The client can transfer funds between his/hers bank accounts by means of the

ATM.

5.ATM Transaction: An abstract use case that depicts all the Bank ATM transactions and they are
further specialised into Check Balances, Deposit Funds, Withdraw Cash and Transfer Funds.
6.ATM Help: An extension use case which is invoked when the customer search assistance in the
course of a transaction.