MAHARAJA SURAJMAL

INSTITUTE OF TECHNOLOGY

SE PRACTICAL FILE
(SOFTWARE ENGINEERING LAB)
(ETCS-353)

Submitted By: Inika Kanojia

Submitted To: Dr. Anupama Kaushik
Enrollment No: 03115003120
Branch: IT-1 (B Batch)
 INDEX

AIM DATE PAGE REMARKS

[Link].

INIKA IT-1 03115003120

 AIM DATE PAGE REMARKS
[Link].

INIKA IT-1 03115003120

 Practical - 1
Aim: Introduction to UML.

Theory:

Unified Modeling Language (UML)

The Unified Modeling Language (UML) is a general-purpose,

developmental modeling language in the field of software engineering
that is intended to provide a standard way to visualize the design of a
system.
The main aim of UML is to define a standard way to visualize the
way a system has been designed. It is quite similar to blueprints used
in other fields of engineering.

Why use UML?

The 1990s was the era of the development of object-oriented
languages such as C++. These object-oriented languages were used to
create complex but compelling systems.
As the systems developed were complicated to understand, it led to the
design and analysis problems which were faced a er the deployment of
the system. It was difficult to explain the system to others.
As soon as the UML was introduced, many game-changing
experiments and approaches were made for simplifying such difficult
tasks of analyzing the system.
UML has unlimited applications even outside the so ware industry. It
can be used to visualize the workflow of a factory.

INIKA IT-1 03115003120

Complete History of UML

UML is an object-oriented unified modelling language. It was invented

by brilliant so ware engineers Grady Booch, Ivar Jacobson, and James
Rumbaugh of Ronal so ware in 1994 and 1995. It was under
development in 1996.
Each of the UML inventors, viz, Grady Booch, Ivar Jacobson, and James
Rumbaugh had a fantastic idea for designing a language which will
reduce the complexity.
 Booch’s method was very flexible to work with during the
design and construction of objects.
 Jacobson’s method provided a great way to work around use
cases. It also has a powerful approach to high-level design.
 Rumbaugh’s method was very useful while handling sensitive systems.

UML was recognized as a standard by the Object Management Group

(OMG) in 1997. Object Management Group has been responsible for
managing UML since it was adopted as a standard.
In 2005, the International Organization for Standardize on approved
UML as an ISO standard. It is used in various industries for creating
object-oriented models.
The latest UML version is 2.5.1 which was released in December 2017.

Characteristics of UML
 It is a generalized modelling language.
 It is different from so ware programming
languages such as Python, C, C++, etc.
 It is a pictorial language which can be used to generate
powerfull modelling elements.
 It is related to object-oriented designs and analysis.
 It has unlimited applications even outside the so ware
industry. It can be used to visualize the workflow of a factory.

INIKA IT-1 03115003120

What is UML Diagram?
UML Diagrams are the output of the Unified Modeling Language. It is a
pictorial representation of classes, objects, and relationships between
them. UML diagram is a model that describes a part of a system. It is
used to define the functionality or design of a system. A diagram
must be clear and concise so that the viewer will readily understand it.

UML Diagram Types

There are two main categories of UML Diagram

Figure 1.1: Types of UML Diagrams

INIKA IT-1 03115003120

Structural Diagrams- Capture static aspects or structure of a system.
It includes:

 Class Diagram – It is the building block of all object-oriented so

ware systems. We use class diagrams to depict the static structure
of a system.

 Composite Structure Diagram – We use composite structure

diagrams to represent the internal structure of a class and its
interaction points with other parts of the system.

 Object Diagram – An Object Diagram can be referred to as a

screenshot of the instances in a system and the relationship that
exists between them. We can study the behaviour of the system at
a particular instant.

 Component Diagram – Component diagrams are used to

represent how the physical components in a system have been
organized. We use them for modelling implement on details.

 Deployment Diagram – Deployment Diagrams are used to

represent system hardware and its so ware. It tells us what
hardware components exist and what so ware components run on
them.

 Package Diagram – We use Package Diagrams to depict how

packages and their elements have been organized. A package
diagram simply shows us the dependencies between different
packages and the internal composition of packages. Packages
help us to organize UML diagrams into meaningful groups and
make the diagram easy to understand. They are primarily used to
organize classes and use case diagrams.
INIKA IT-1 03115003120
Behavior Diagrams – Capture dynamic aspects or behavior of the
system.
It includes:
 State Machine Diagrams – State machine diagrams, now known
as state machine diagrams and state diagrams describe the
dynamic behavior of a system in response to external stimuli.
State diagrams are especially useful in modelling objects whose
states are triggered by specific events

 Activity Diagram – We use Activity Diagrams to illustrate

the flow of control in a system. We basically depict workflows
visually using an activity diagram. An activity diagram focuses on
the condition of flow and the sequence in which it happens.

 Use Case Diagrams – They are widely used to illustrate the

functional requirements of the system and its interaction with
external actors. A use case is basically a diagram representing
different scenarios where the system can be used. A use case
diagram gives us a high- level view of what the system or a part
of the system does without going into implementation details.

 Sequence Diagram – A sequence diagram simply depicts the

interaction between objects in sequence order i.e., the order in
which these interactions take place.

 Communication Diagram – A communication on diagram

focuses primarily on objects and their relationships.

 Timing Diagram – Timing diagram is a type of behavioural or

interaction UML diagram that focuses on processes that take place
during a specific period of me.

 Interaction Overview Diagram – An Interaction Overview

Diagram models a sequence of actions and helps us simplify
complex interactions o into simpler occurrences. It is a mixture of
activity and sequence diagrams.

INIKA IT-1 03115003120

Unified Modeling Language (UML) Software design tools
There are numerous tools, both commercial and open-source, which
are available for designing UML diagrams.

Rational Rose

 Rational Rose is an object-oriented Unified Modeling Language

(UML) so ware design tool intended for visual modelling and
component construction of enterprise-level so ware applications.
In much the same way a theatrical director blocks out a play, a
so ware designer uses Rational Rose to visually create (model) the
framework for an application by blocking out classes with actors ,
use case elements ( ovals), objects ( rectangles) and
messages/relationships ( arrows) in a sequence diagram using
drag-and-drop symbols. Rational Rose documents the diagram as
it is being constructed and then generates code in the designer's
choice of C++, Visual Basic, Java, Oracle8, Data Definition
Language.

 Two popular features of Rational Rose are its ability to provide

iterative development and round-trip engineering. Rational Rose
allows designers to take advantage of iterative development (some
called evolutionary development) because the new application
can be created in stages with the output of one iteration becoming
the input of the next. (This is in contrast to waterfall development
where the whole project is completed from start to finish
before a user gets to try it out.)

 Then, as the developer begins to understand how the components

interact and makes modifications in the design, Rational Rose can
perform what is called "round-trip engineering" by going back and
upgrading the rest of the model to ensure the code remains
consistent.

INIKA IT-1 03115003120

Star UML

StarUML is an open-source so ware modelling tool that supports the

UML (Unified Modeling Language) framework for system and so
ware modelling. It is based on UML version 1.4 , provides eleven
different types of diagrams and accepts UML 2.0 nota on. It ac vely
supports the MDA (Model Driven Architecture) approach by suppor ng
the UML profile concept and allowing it to generate code for mul ple
languages.
StarUML makes a clear conceptual dis nc on between models, views and
diagrams. A Model is an element that contains informa on for a so
ware model. A View is a visual expression of the informa on contained
in a model, and a Diagram is a collec on of view elements that
represent the user's specific design thoughts.
StarUML supports the following diagram types:
 Use Case Diagram
 Class Diagram
 Sequence Diagram
 Collaboration Diagram
 State Machine Diagram
 Activity Diagram
 Component Diagram
 Deployment Diagram
 Composite Structure Diagram

Visual Paradigm

 Visual Paradigm is a complete UML modelling application. It

comes in two versions: a desktop version that is a UML
modeler and an internet version that is a diagramming tool.
 Visual Paradigm has a large number of modelling capabilities
that make crea ng UML diagrams simple. It combines basic tools
with on-the-fly UML syntax checking. It also works with all
UML 2.x

INIKA IT-1 03115003120

 diagram types. Its sequence diagram editor is one of the most
user-friendly editors available.

 Visual Paradigm provides inline edi ng for class members, as

well as an integrated sequence diagram editor that is both
interactive and simple to use.

 Visual Paradigm also has a plug-in interface that allows you

to construct your own features and shapes based on your
requirements.

In this lab, we are using StarUML.

StarUML installa on steps:

 Open the link: h p://[Link]/download
 According to your PC specifications. Download any version of
the application. Here we are going to choose the windows op on.

 Once the application is downloaded, install it with all the

default options.

 After installation launch the Staruml application in your PC

and start creating UML diagrams.

INIKA IT-1 03115003120

 Practical - 2

Aim: Write down the problem statement for Automated Teller

Machine and design the system using UML diagrams.

Software Used: Star UML.

(A) Problem Statement: ATM is a system by which a user can

withdraw any amount not exceeding his account’s current balance
without visiting bank. Software is to be designed that will control the
ATM that will have an ATM card reader to read the card, an output
screen for interaction with customers, a cash dispenser, and a printer to
print mini statements. With the help of ATMs, we can achieve this
without the hassle of visiting the bank. ATM is completely automated
and it can be placed in shopping malls, airports, railway stations etc.
Also, technicians would also have access to the software for maintenance
and repair the software, which could help them to troubleshoot the bugs
and update the firmware of the ATM system.
The user has a card issued by the bank in which he holds the
account. The user has to enter the card into the ATM machine and
enter his four- digit pin to log in. If the pin entered by the user is
invalid, an error will be displayed. After entering the correct pin, the
user has to select from various functionalities offered by ATM. These
functionalities are:

Withdraw money by entering the required amount if a sufficient

amount exists.
 Check the account balance and get a mini statement from ATM.
 Deposit money in the account.
 Transfer Funds.
 Change PIN.
 Print Passbook

INIKA IT-1 03115003120

INIKA IT-1 03115003120
(B) Use Case Diagram:

A use case diagram is used to represent the dynamic behaviour of a

system. It encapsulates the system's functionality by incorporating use
cases, actors, and their relationships. It models the tasks, services, and
functions required by a system/subsystem of an application. It
depicts the high-level functionality of a system and also tells how
the user handles a system.
When we are planning to draw a use case diagram, we should have the
following items identified:
 Functionalities to be represented as use case
 Actors
 Relationships among the use cases and actors.

Figure 2.1: Use Case Diagram for ATM Management System

INIKA IT-1 03115003120

Actors:
Any Bank Customer (Has an existing account)
Banking System (Any bank’s ATM and its infrastructure)

Pre-conditions:
The ATM is operational.

The bank customer has a card to insert into the ATM.

Post-conditions:
The bank customer has received their cash or transferred successfully
( and optionally a receipt).
The bank has debited the customer’s bank account and recorded the
details of the transaction.

INIKA IT-1 03115003120

 (C)Sequence Diagram
Sequence Diagrams are interaction diagrams that detail how
operations are carried out. They capture the interaction between
objects in the context of a collaboration.
The sequence diagram represents the flow of messages in the
system and is also termed an event diagram. It helps in
envisioning several dynamic scenarios. It portrays the
communication between any two lifelines as a me-ordered
sequence of events, such that these lifelines took part in the
run me. In UML, the lifeline is represented by a vertical bar,
whereas the message flow is represented by a vertical line that
extends across the bottom of the page.

 Lifeline-An individual participant in the sequence diagram is

represented by a lifeline. It is positioned at the top of the diagram.
 Actor- A role played by an entity that interacts with the subject
is called an actor. It is out of the scope of the system. It
represents the role, which involves human users and external
hardware or subjects.
 Message- The messages depict the interaction between the
objects and are represented by arrows. They are in sequential order
on the lifeline. They are divided into the following categories:
 Synchronous Messages – A synchronous message waits for a
reply before the interaction can move forward. The sender waits
un l the receiver has completed the processing of the message. We
use a solid arrowhead to represent a synchronous message.
 Asynchronous Messages – An asynchronous message does not
wait for a reply from the receiver. The interaction moves
forward irrespective of whether the receiver processing the
previous message or not. We use a lined arrowhead to represent
an asynchronous message.

INIKA IT-1 03115003120

  Self-Message – Certain scenarios might arise where the object
needs to send a message to itself. Such messages are called
Self Messages and are represented with a U-shaped arrow.

Purpose of Sequence Diagram:

 Model high-level interaction between ac ve objects in a system

 Model the interaction between object instances within a
collaboration that realizes a use case
 Model the interaction between objects within a collaboration that
realizes an opera on
 Either model generic interactions (showing all possible paths
through the interaction) or specific instances of an interaction
( showing just one path through the interaction)

Withdrawal of cash

Fig2.2 sequence diagram for withdrawal of cash

INIKA IT-1 03115003120

Invalid PIN

Fig2.3 sequence diagram for invalid Pin in ATM system (error)

Invalid Withdrawal

Fig 2.4 sequence diagram for Invalid Withdrawal in ATM system (error)

INIKA IT-1 03115003120

(D)Class Diagram:
A class diagram is a static diagram. It represents a static view of an
application. Class diagrams are used to create executable code for
software applications as well as for visualizing, describing, and
documenting various system components.

Class diagrams outline a class's characteristics, methods, and restrictions

on the system. Because they are the only UML diagrams that can be
directly mapped to object-oriented languages, class diagrams are
frequently used to model object-oriented systems.

A class diagram displays a number of classes, interfaces, associations,

collaborations, and constraints. It is also referred to as a structural
diagram.

The following points should be remembered while drawing a class diagram

 The name of the class diagram should be meaningful to describe
the aspect of the system.
 Each element and its relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be
clearly identified
 For each class, the minimum number of properties should be
specified, as unnecessary properties will complicate the diagram.

Purpose of Class Diagrams

Class diagrams is used to model an application's static view. The only
diagrams that can be directly mapped to object-oriented languages are
class diagrams, which are frequently used when building software.
Class diagrams are somewhat different from other UML diagrams like
activity diagrams and sequence diagrams in that they can show more
than just the application's sequence of events. It is the UML diagram that
programmers use the most.
The purpose of the class diagram can be summarized as –
Analysis and design of the static view of an application.
 Describe the responsibilities of a system

INIKA IT-1 03115003120

Relationships in Class Diagrams:

In UML, a relationship is a connection between model elements. A UML

relationship is a type of model element that adds semantics to a model by
defining the structure and behavior between model elements.

UML relationships are grouped into the following categories:

You can set properties and use keywords to create variations of these
relationships.

Relationships in class diagrams show the interaction between classes and

classifiers. Such relationships indicate the classifiers that are associated
with each other, those that are generalizations and realizations, and those
that have dependencies on other classes and classifiers.

The following topics describe the relationships that you can use in class
diagrams:

Abstraction relationships:
An abstraction relationship is a dependency between model elements that
represent the same concept at different levels of abstraction or from
different viewpoints. You can add abstraction relationships to a model in
several diagrams, including use-case, class, and component diagrams.

Aggregation relationships:
In UML models, an aggregation relationship shows a classified as a part
of or subordinate to another classifier.

INIKA IT-1 03115003120

Association relationships:
In UML models, an association is a relationship between two classifiers,
such as classes or use cases that describes the reasons for the relationship
and the rules that govern the relationship.

Association classes:
In UML diagrams, an association class is a class that is part of an
association relationship between two other classes
.
Binding relationships:
In UML models, a binding relationship is a relationship that assigns
values to template parameters and generates a new model element from
the template.

Composition association relationships:

A composition association relationship represents a whole–part
relationship and is a form of aggregation. A composition association
relationship specifies that the lifetime of the part classifier is dependent
on the lifetime of the whole classifier.

Dependency relationships:
In UML, a dependency relationship is a relationship in which one
element, the client, uses or depends on another element, the supplier.
You can use dependency relationships in class diagrams, component
diagrams, deployment diagrams, and use-case diagrams to indicate that a
change to the supplier might require a change to the client.

Directed association relationships:

In UML models, directed association relationships are associations that
are navigable in only one direction

Element import relationships:

In UML diagrams, an element import relationship identifies a model
element in another package, and allows the element in the other package
to be referenced by using its name without a qualifier.

Generalization relationships:
In UML modelling, a generalization relationship is a relationship in
which one model element (the child) is based on another model element
(the parent). Generalization relationships are used in class, component,
deployment, and

INIKA IT-1 03115003120

use-case diagrams to indicate that the child receives all of the
attributes, operations, and relationships that are defined in the
parent.

Interface realization relationships:

In UML diagrams, an interface realization relationship is a
specialized type of implementation relationship between a
classifier and a provided interface. The interface realization
relationship specifies that the realizing classifier must conform to
the contract that the provided interface specifies.

Instantiation relationships:
In UML diagrams, an instantiation relationship is a type of usage
dependency between classifiers that indicates that the operations
in one classifier create instances of the other classifier.

Package import relationship:

In UML diagrams, a package import relationship allows other
namespaces to use unqualified names to refer to package
members.

Realization relationships:
In UML modelling, a realization relationship is a relationship
between two model elements, in which one model element (the
client) realizes the behaviour that the other model element (the
supplier) specifies. Several clients can realize the behavior of a
single supplier. You can use realization relationships in class
diagrams and component diagrams.

Usage relationships:
In UML modelling, a usage relationship is a type of dependency
relationship in which one model element (the client) requires
another model element (the supplier) for full implementation or
operation.

INIKA IT-1 03115003120

 Fig 3.1 Class Diagram for ATM Management System

Class Diagram for ATM Management System simply describes

structure of ATM Management System class, attributes, methods or
operations, relationship among objects.
Classes of ATM Management System:
 card reader
 ATM
 User’s account
 User
 Bank
Their roles are in the middle part and called their attributes. The function
of each class is in its’ methods.
Attributes of ATM Management System:
Card reader
 insert card
 enter pin
 enter amount
 withdraw cash
User’s Account
 Verify account
 Deposit money
 Change pin

INIKA IT-1 03115003120

Bank
 Check pin
 Check balance
 Update balance

INIKA IT-1 03115003120

 (E)Activity Diagram:
In UML, the activity diagram is used to demonstrate the flow of control
within the system rather than the implementation. It models concurrent
and sequential activities.
The activity diagram helps in envisioning the workflow from one activity
to another. It put emphasis on the condition of flow and the order in
which it occurs. The flow can be sequential, branched, or concurrent, and
to deal with such kinds of flows, the activity diagram has come up with a
fork, join, etc.
It is also termed an object-oriented flowchart. It encompasses activities
composed of a set of actions or operations that are applied to model the
behavioral diagram.

Activities
The categorization of behavior into one or more actions is termed as an
activity. In other words, it can be said that an activity is a network of
nodes that are connected by edges. The edges depict the flow of
execution. It may contain action nodes, control nodes, or object nodes.
The control flow of activity is represented by control nodes and object
nodes that illustrate the objects used within an activity. The activities are
initiated at the initial node and are terminated at the final node.

Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or
one row. It can be either vertical or horizontal. It used to add modularity
to the activity diagram. It is not necessary to incorporate swimlane in the
activity diagram. But it is used to add more transparency to the activity
diagram.

INIKA IT-1 03115003120

Forks
Forks and join nodes generate the concurrent flow inside the activity. A
fork node consists of one inward edge and several outward edges. It is
the same as that of various decision parameters. Whenever a data is
received at an inward edge, it gets copied and split crossways various
outward edges. It split a single inward flow into multiple parallel flows.

Join Nodes
Join nodes are the opposite of fork nodes. A Logical AND operation is
performed on all of the inward edges as it synchronizes the flow of input
across one single output (outward)

Pins
It is a small rectangle, which is attached to the action rectangle. It clears
out all the messy and complicated thing to manage the execution flow of
activities. It is an object node that precisely represents one input to or
output from the action.

INIKA IT-1 03115003120

Notation of an Activity diagram:
Activity diagram constitutes following notations:
 Initial State: It depicts the initial stage or beginning of the set of
actions.
 Final State: It is the stage where all the control flows and object
flows end.
 Decision Box: It makes sure that the control flow or object
flow will follow only one path.
 Action Box: It represents the set of actions that are to be
performed.

Why use Activity Diagram?

An event is created as an activity diagram encompassing a group of
nodes associated with edges. They can be attached to any modelling
element to model the behaviour of activities. It can model use cases,
classes, interfaces, components, and collaborations.
It mainly models processes and workflows. It envisions the dynamic
behaviour of the system as well as constructs a runnable system that
incorporates forward and reverses engineering. It does not include the
message part, which means message flow is not represented in an
INIKA IT-1 03115003120
activity [Link] is the same as flowchart but not precisely a
flowchart itself. It is used to depict the flow between several
activities.

Fig 4.1 Activity Diagram for ATM Management System

INIKA IT-1 03115003120

(F)Communication/Collaboration Diagram
In UML, a communication diagram shows the interactions between the
objects or roles associated with lifelines and the messages that pass
between lifelines. In earlier versions of UML, this diagram was called a
collaboration diagram and had a different notation.

Communication diagrams are a type of interaction diagram that you can

use to explore the dynamic behavior of a system or software application.
They provide an alternate view of the same information as sequence
diagrams. In sequence diagrams, the focus is the ordering of the
messages over time; in communication diagrams the focus is the
structure of the messages that pass between the objects in the interaction.
These diagrams illustrate the flow of messages between objects and the
implied relationships between classes.

You can use communication diagrams to explore how objects in a system

or application work together. Communication diagrams can identify the
following aspects of an interaction or task:

● Objects that participate in the interaction

● Interfaces that the participating classes require
● Structural changes that an interaction requires
● Data that is passed between the objects in an interaction

Communication diagrams look similar to object diagrams, in which a

lifeline represents the objects in the interaction and arrows represent the
messages that are passed between the lifelines. Arrowheads indicate the
direction of the messages, forward or reverse, and sequence numbers
indicate the order in which the messages are passed.
The following topics describe the elements in communication diagrams:

Lifelines in UML Diagrams:

In UML diagrams, such as sequence or communication diagrams,
lifelines represent the objects that participate in an interaction. For
example, in a banking scenario, lifelines can represent objects such as a
bank system or customer. Each instance in an interaction is represented
by a lifeline.

INIKA IT-1 03115003120

Message pathways in communication diagrams:
A message pathway is a connector between the roles or objects
represented by lifelines in the diagram. The pathway identifies the
objects that can pass messages in the interaction.

Messages in UML Diagrams:

A message is an element in a Unified Modeling Language (UML)
diagram that defines a specific kind of communication between
instances in an interaction. A message conveys information from one
instance, which is represented by a lifeline, to another instance in an
interaction.

Fig 5.1 Communication Diagram for ATM management system

INIKA IT-1 03115003120

 (G)Component Diagram
A component diagram is used to break down a large object-oriented
system into the smaller components, so as to make them more
manageable. It models the physical view of a system such as
executables, files, libraries, etc. that resides within the node.
It visualizes the relationships as well as the organization between the
components present in the system. It helps in forming an executable
system. A component is a single unit of the system, which is replaceable
and executable. The implementation details of a component are hidden,
and it necessitates an interface to execute a function. It is like a black
box whose behavior is explained by the provided and required interfaces.

Notation of a Component Diagram

a) A component

b) A node

INIKA IT-1 03115003120

Purpose of a Component Diagram
Since it is a special kind of a UML diagram, it holds distinct purposes. It
describes all the individual components that are used to make the
functionalities, but not the functionalities of the system. It visualizes the
physical components inside the system. The components can be a library,
packages, files, etc.
The component diagram also describes the static view of a system, which
includes the organization of components at a particular instant. The
collection of component diagrams represents a whole system.
The main purpose of the component diagram are enlisted below:

 It envisions each component of a system.

 It constructs the executable by incorporating forward and
reverse engineering.
 It depicts the relationships and organization of components.

Why use Component Diagram?

The component diagrams have remarkable importance. It is used to
depict the functionality and behavior of all the components present in the
system, unlike other diagrams that are used to represent the architecture
of the system, working of a system, or simply the system itself.
In UML, the component diagram portrays the behavior and organization
of components at any instant of time. The system cannot be visualized by
any individual component, but it can be by the collection of components.
Following are some reasons for the requirement of the component diagram:

 It portrays the components of a system at the runtime.

 It is helpful in testing a system.
 It envisions the links between several connections.

When to use a Component Diagram?

It represents various physical components of a system at runtime. It is
helpful in visualizing the structure and the organization of a system. It
describes how individual components can together form a single system.
Following are some reasons, which tells when to use component
diagram:

INIKA IT-1 03115003120

To divide a single system into multiple components according to the
functionality.
To represent the component organization of the system.

Where to use Component Diagrams?

The component diagram is a special purpose diagram, which is
used to visualize the static implementation view of a system. It
represents the physical components of a system, or we can say it
portrays the organization of the components inside a system. The
components, such as libraries, files, executables, etc. are first
needed to be organized before the implementation.

The component diagram can be used for the followings:

 To model the components of the system.

 To model the schemas of a database.
 To model the applications of an application.
 To model the system's source code.

Fig 6.1 Component Diagram for ATM Management System

INIKA IT-1 03115003120

D) Data Flow Diagram
A Data Flow Diagram (DFD) is a traditional visual representation
of the information flows within a system. A neat and clear DFD
can depict the right amount of the system requirement graphically.
It can be manual, automated, or a combination of both.
It shows how data enters and leaves the system, what changes the
information, and where data is stored.
The objective of a DFD is to show the scope and boundaries of a
system as a whole. It may be used as a communication tool
between a system analyst and any person who plays a part in the
order that acts as a starting point for redesigning a system. The
DFD is also called a data flow graph or bubble chart.

 All names should be unique. This makes it easier to refer to

elements in the DFD.
 Remember that DFD is not a flow chart. Arrows is a flow
chart that represents the order of events; arrows in DFD
represents flowing data. A DFD does not involve any order
of events.
 Suppress logical decisions. If we ever have the urge to draw
a diamond- shaped box in a DFD, suppress that urge! A
diamond-shaped box is used in flow charts to represents
decision points with multiple exists paths of which the only
one is taken. This implies an ordering of events, which
makes no sense in a DFD.
 Do not become bogged down with details. Defer error
conditions and error handling until the end of the analysis.
Standard symbols for DFDs are derived from the electric circuit
diagram analysis and are shown in fig:

INIKA IT-1 03115003120

INIKA IT-1 03115003120
Circle: A circle (bubble) shows a process that transforms data
inputs into data outputs.
Data Flow: A curved line shows the flow of data into or out of a
process or data store.
Data Store: A set of parallel lines shows a place for the collection
of data items. A data store indicates that the data is stored which
can be used at a later stage or by the other processes in a different
order. The data store can have an element or group of elements.
Source or Sink: A source or Sink is an external entity and acts as
a source of system inputs or sink of system outputs.

Levels in Data Flow Diagrams (DFD):

The DFD may be used to perform a system or software at any
level of abstraction. In fact, DFDs may be partitioned into levels
that represent increasing information flow and functional detail.
Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see
primarily three levels in the data flow diagram, which are: 0-level
DFD, 1-level DFD, and 2-level DFD.

0-level DFDM:
It is also known as the fundamental system model, or context
diagram represents the entire software requirement as a single
bubble with input and output data denoted by incoming and
outgoing arrows. Then the system is decomposed and described as
a DFD with multiple bubbles. Parts of the system represented by
each of these bubbles are then decomposed and documented as
more and more detailed DFDs. This process may be repeated at as
many levels as necessary until the program at hand is well
understood. It is essential to preserve the number of inputs and
outputs between levels, this concept is called leveling by
DeMarco. Thus, if bubble "A" has two inputs x 1 and x2 , and one
output y, then the expanded DFD, that represents "A" should have
exactly two external inputs and one external output. The Level-0
DFD, also called the context diagram of the result management
system is shown in fig. As the bubbles are decomposed into less
and less abstract bubbles, the corresponding data flow may also be
needed to be decomposed.

1-level DFD:
In 1-level DFD, a context diagram is decomposed into multiple
bubbles/processes. In this level, we highlight the main objectives
INIKA IT-1 03115003120
of the system and break down the high-level process of 0-level
DFD into subprocesses.

INIKA IT-1 03115003120

2-Level DFD:
2-level DFD goes one process deeper into parts of 1-level DFD. It can
be used to project or record the specific/necessary detail about the
system's functioning.

Fig 7.1 Data Flow Diagram for ATM Management System

INIKA IT-1 03115003120

I) Deployment Diagram:
The deployment diagram visualizes the physical hardware on
which the software will be deployed. It portrays the static
deployment view of a system. It involves the nodes and their
relationships.
It ascertains how software is deployed on the hardware. It maps
the software architecture created in design to the physical system
architecture, where the software will be executed as a node. Since
it involves many nodes, the relationship is shown by utilizing
communication paths.

Purpose of Deployment Diagram:

The main purpose of the deployment diagram is to represent how
software is installed on the hardware component. It depicts in
what manner software interacts with hardware to perform its
execution.
Both the deployment diagram and the component diagram are
closely interrelated to each other as they focus on software and
hardware components. The component diagram represents the
components of a system, whereas the deployment diagram
describes how they are actually deployed on the hardware.
The deployment diagram does not focus on the logical
components of the system, but it put its attention on the hardware
topology.
Following are the purposes of the deployment diagram enlisted below:
1. To envision the hardware topology of the system.
2. To represent the hardware components on which
the software components are installed.
3. To describe the processing of nodes at the runtime.

Symbol and notation of Deployment diagram:

The deployment diagram consist of the following notations:
 A component
 An artifact
 An interface
 A node

INIKA IT-1 03115003120

How to draw a Deployment Diagram?
The deployment diagram portrays the deployment view of the
system. It helps in visualizing the topological view of a system. It
incorporates nodes, which are physical hardware. The nodes are
used to execute the artifacts. The instances of artifacts can be
deployed on the instances of nodes.
Since it plays a critical role during the administrative process, it
involves the following parameters:
 High performance
 Scalability
 Maintainability
 Portability
 Easily understandable
One of the essential elements of the deployment diagram is the
nodes and artifacts. So it is necessary to identify all of the nodes
and the relationship between them. It becomes easier to develop a
deployment diagram if all of the nodes, artifacts, and their
relationship is already known.

INIKA IT-1 03115003120

Fig 8.1 Deployment Diagram for ATM Management System

INIKA IT-1 03115003120