No Name Of Practical

1 Study and implementation of class diagrams.

2 Study and implementation of Use Case Diagrams.
3 Study and implementations of Entity Relationship Diagrams.
4 Study and implementations of Sequence Diagrams.
5 Study and implementations of State Transition Diagrams
6 Study and implementations of Data Flow Diagrams
7 Study and implementations of Collaboration Diagrams
8 Study and implementations of Activity Diagrams.
 CERTIFICATE
Class: SY. BSc-IT Year: 2021 .
This is to certify that work entered in this journal is the work of
Shri / Kumari OM MARUTI GAIKWAD .
Of: SY. BSc-IT Division: A Roll No: A4601 .
Uni. Exam No. A4601 has satisfactorily completed therequired number of
practical and worked for the 1 term / 2 term / both the term of the year
st nd
2019-2020
in the college laboratory as laid down by the university.

______________
Head of the External internal Examiner
Department Examiner Subject teacher

Date:04/03/2021 Department of Bachelor of Science in IT

Practical No:-01
Aim: Study and implementation of class diagrams.
Theory: Class diagram is a static diagram. It represents the static view of an application.
Class diagram is not only used for visualizing, describing, and documenting different aspects
of a system but also for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modelling of object-
oriented systems because they are the only UML diagrams, which can be mapped directly
with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.

Purpose of Class Diagrams:-

The purpose of class diagram is to model the static view of an application. Class diagrams
are the only diagrams which can be directly mapped with objectoriented languages and thus
widely used at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the application, however class diagram is a bit different. It is the most popular UML
diagram in the coder community. The purpose of the class diagram can be summarized as −
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.

Attributes
+ Stands for public attributes # Stands
for protected attributes - Stands for
private attributes
Operations
+ Stands for public operations # Stands
for protected operations

- Stands for private operations

Diagram:

PRACTICAL NO:-2
Aim: Study and implementation of Use Case Diagrams.
Theory: To model a system, the most important aspect is to capture the dynamic behaviour.
Dynamic behaviour means the behaviour of the system when it is running/operating.
Only static behaviour is not sufficient to model a system rather dynamic behaviour is more
important than static behaviour. In UML, there are five diagrams available to model the
dynamic nature and use case diagram is one of them. Now as we have to discuss that the use
case diagram is dynamic in nature, there should be some internal or external factors for
making the interaction.
These internal and external agents are known as actors. Use case diagrams consists of actors,
use cases and their relationships. The diagram is used to model the system/subsystem of an
application. A single use case diagram captures a particular functionality of a system.
Hence to model the entire system, a number of use case diagrams are used.

Purpose of Use Case Diagrams

The purpose of use case diagram is to capture the dynamic aspect of a system. However, this
definition is too generic to describe the purpose, as other four diagrams (activity, sequence,
collaboration, and State chart) also have the same purpose. We will look into some specific
purpose, which will distinguish it from other four diagrams.
Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. Hence, when a
system is analysed to gather its functionalities, use cases are prepared and actors are
identified.
When the initial task is complete, use case diagrams are modelled to present the outside
view.
In brief, the purposes of use case diagrams can be said to be as follows − • Used to
gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the system.
• Show the interaction among the requirements are actors.

Uses of Use Case Diagram:

As we have already discussed there are five diagrams in UML to model the dynamic view of
a system. Now each and every model has some specific purpose to use. Actually these
specific purposes are different angles of a running system.
To understand the dynamics of a system, we need to use different types of diagrams. Use
case diagram is one of them and its specific purpose is to gather system requirements and
actors.
Use case diagrams can be used for −
• Requirement analysis and high level design.
• Model the context of a system.
• Reverse engineering.
• Forward engineering.

Diagram:
 Practical No:-03

Aim: Study and implementations of Entity Relationship Diagrams.

Theory: ER-modelling is a data modelling method used in software engineering to produce a

conceptual data model of an information system. Diagrams created using this ER-modelling
method are called EntityRelationship Diagrams or ER diagrams or ERDs.

Purpose of ERD o The database analyst gains a better understanding of the data to be
contained in the database through the step of constructing the ERD.
o The ERD serves as a documentation tool. o Finally, the ERD is used to connect the
logical structure of the database to users. In particular, the ERD effectively communicates
the logic of the database to users.

Components of an ER Diagrams
1. Entity

An entity can be a real-world object, either animate or inanimate, that can be merely
identifiable. An entity is denoted as a rectangle in an ER diagram. For example, in a school
database, students, teachers, classes, and courses offered can be treated as entities. All these
entities have some attributes or properties that give them their identity.

Entity Set

An entity set is a collection of related types of entities. An entity set may include entities
with attribute sharing similar values. For example, a Student set may contain all the students
of a school; likewise, a Teacher set may include all the teachers of a school from all faculties.
Entity set need not be disjoint.

2. Attributes

Entities are denoted utilizing their properties, known as attributes. All attributes have values.
For example, a student entity may have name, class, and age as attributes.

There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.

There are four types of Attributes:

 1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute
3. Relationships

The association among entities is known as relationship. Relationships are represented by the
diamond-shaped box. For example, an employee works at a department, a student enrols in a
course. Here, Works at and Enrols are called relationships.

Relationship set

A set of relationships of a similar type is known as a relationship set. Like entities, a

relationship too can have attributes. These attributes are called descriptive attributes.

Degree of a relationship set

The number of participating entities in a relationship describes the degree of the relationship.
The three most common relationships in E-R models are:

1. Unary (degree1)
2. Binary (degree2) 3. Ternary (degree3) Diagram:
 Practical No:-04

Aim: Study and implementations of Sequence Diagrams.

Theory:
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place. We can also use the terms event diagrams or
event scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what
order the objects in a system function. These diagrams are widely used by businessmen and
software developers to document and understand requirements for new and existing systems.

Sequence Diagram Notations –

Actors – An actor in a UML diagram represents a type of role where it interacts with the
system and its objects. It is important to note here that an actor is always outside the scope of
the system we aim to model using the UML diagram.
Lifelines – A lifeline is a named element which depicts an individual participant in a
sequence diagram. So basically each instance in a sequence diagram is represented by a
lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in UML
for naming a lifeline follows the following format – Instance Name : Class Name

Messages – Communication between objects is depicted using messages.

The messages appear in a sequential order on the lifeline. We represent messages using
arrows. Lifelines and messages form the core of a sequence diagram. Messages can be
broadly classified into the following categories :

• Synchronous messages – A synchronous message waits for a reply before the

interaction can move forward. The sender waits until the receiver has completed the
processing of the message. The caller continues only when it knows that the receiver
has processed the previous message i.e. it receives a reply message. A large number of
calls in object oriented programming are synchronous. We use a solid arrow head 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 the receiver processing the
previous message or not. We use a lined arrow head to represent an asynchronous
message.
• Create message – We use a Create message to instantiate a new object in the
sequence diagram. There are situations when a particular message call requires the
creation of an object. It is represented with a dotted arrow and create word labelled on
it to specify that it is the create Message symbol. For example – The creation of a new
order on a e-commerce website would require a new object of Order class to be
created.

• Delete Message – We use a Delete Message to delete an object. When an object is

deallocated memory or is destroyed within the system we use the Delete Message
symbol. It destroys the occurrence of the object in the system.It is represented by an
arrow terminating with a x. For example – In the scenario below when the order is
received by the user, the object of order class can be destroyed.

• 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.
 • Reply Message – Reply messages are used to show the message being sent from the
receiver to the sender. We represent a return/reply message using an open arrowhead
with a dotted line. The interaction moves forward only when a reply message is sent
by the receiver.

• Found Message – A Found message is used to represent a scenario where an

unknown source sends the message. It is represented using
an arrow directed towards a lifeline from an end point. For example: Consider the
scenario of a hardware failure.

• Lost Message – A Lost message is used to represent a scenario where the recipient is
not known to the system. It is represented using an arrow directed towards an end
point from a lifeline. For example: Consider a scenario where a warning is generated.

Guards – To model conditions we use guards in UML. They are used when we need to
restrict the flow of messages on the pretext of a condition being met. Guards play an
important role in letting software developers know the constraints attached to a system or a
particular process.
For example: In order to be able to withdraw cash, having a balance greater than zero is a
condition that must be met as shown below.
Diagram:
 Practical No:-05
Aim: Study and implementations of State Transition Diagrams.
Theory: The name of the diagram itself clarifies the purpose of the diagram and other
details. It describes different states of a component in a system. The states are specific to a
component/object of a system.
A Statechart diagram describes a state machine. State machine can be defined as a machine
which defines different states of an object and these states are controlled by external or
internal events.
Activity diagram explained in the next chapter, is a special kind of a Statechart diagram. As
Statechart diagram defines the states, it is used to model the lifetime of an object.

Terminologies of State Transition Diagram

State
In the state transition diagram, An object always remains in some state. Further, the state of
the object may change after an event occur.
Event
Any activity that may trigger a state transition or can change the state.
Guard
In the state transition diagram, a guard is a Boolean expression. Suppose if the guard is true,
then it enables an event to trigger a transition.
Transition
The change of state within an object is represented with a transition. It is possible that an
object changes its state when the transition occurs.
Action
One or more actions are taken by an object when the object changes a state.

Purpose of Statechart Diagrams

Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a
system. They define different states of an object during its lifetime and these states are
changed by events. Statechart diagrams are useful to model the reactive systems. Reactive
systems can be defined as a system that responds to external or internal events.
Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is
triggered. The most important purpose of Statechart diagram is to model lifetime of an
object from creation to termination.
Statechart diagrams are also used for forward and reverse engineering of a system. However,
the main purpose is to model the reactive system.
Following are the main purposes of using Statechart diagrams − • To
model the dynamic aspect of a system.
• To model the life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model the states of an object.

Diagram:
 Practical No:06

Aim: Study and implementations of Data Flow Diagrams.

Theory: Data flow diagram is graphical representation of flow of data in an information
system. It is capable of depicting incoming data flow, outgoing data flow and stored data.
The DFD does not mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD
does not contain any control or branch elements. Types of DFD
Data Flow Diagrams are either Logical or Physical.

• Logical DFD - This type of DFD concentrates on the system process, and flow of data
in the system. For example in a Banking software system, how data is moved between
different entities.
• Physical DFD - This type of DFD shows how the data flow is actually implemented in
the system. It is more specific and close to the implementation.

DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of
components -

• Entities - Entities are source and destination of information data.

Entities are represented by a rectangles with their respective names.
• Process - Activities and action taken on the data are represented by Circle or Round-
edged rectangles.
• Data Storage - There are two variants of data storage - it can either be represented as
a rectangle with absence of both smaller sides or as an opensided rectangle with only
one side missing.
• Data Flow - Movement of data is shown by pointed arrows. Data movement is shown
from the base of arrow as its source towards head of the arrow as destination.
Levels of DFD

• Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the
entire information system as one diagram concealing all the underlying details. Level
0 DFDs are also known as context level DFDs.

• Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1
DFD depicts basic modules in the system and flow of data among various modules.
Level 1 DFD also mentions basic processes and sources of information.

• Level 2 - At this level, DFD shows how data flows inside the modules mentioned in
Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with
deeper level of understanding unless the desired level of specification is achieved.

Diagram:
 Practical No:-07

Aim: Study and implementations of Collaboration Diagrams.

Theory: A collaboration diagram, also known as a communication diagram, is an illustration
of the relationships and interactions among software objects in the Unified Modeling
Language (UML). These diagrams can be used to portray the dynamic behavior of a
particular use case and define the role of each object.

Collaboration diagrams are created by first identifying the structural elements required to
carry out the functionality of an interaction. A model is then built using the relationships
between those elements. Several vendors offer software for creating and editing
collaboration diagrams.

Notations of a collaboration diagram

A collaboration diagram resembles a flowchart that portrays the roles, functionality and
behaviour of individual objects as well as the overall operation of the system in real time.
The four major components of a collaboration diagram are:
 1. Objects- Objects are shown as rectangles with naming labels inside. The naming
label follows the convention of object name: class name. If an object has a
property or state that specifically influences the
collaboration, this should also be noted.
Object_name : class_name You can use objects in collaboration diagrams in the
following ways:

• Each object in the collaboration is named and has its class specified

• Not all classes need to appear

• There may be more than one object of a class

• An object’s class can be unspecified. Normally you create a collaboration
diagram with objects first and specify their classes later.
• The objects can be unnamed, but you should name them if you want to
discriminate different objects of the same class.

2. Actors- Actors are instances that invoke the interaction in the diagram. Each actor
has a name and a role, with one actor initiating the entire use case.

3. Links- Links connect objects with actors and are depicted using a solid line
between two elements. Each link is an instance where messages can be sent.
Links are defined as follows:

• A link is a relationship among objects across which messages can be sent. In

collaboration diagrams, a link is shown as a solid line between two objects.

• An object interacts with, or navigates to, other objects through its links to these
objects.

• A link can be an instance of an association, or it can be anonymous, meaning that

its association is unspecified.

• Message flows are attached to links, see Messages.

4. messages- Messages between objects are shown as a labeled arrow placed near a
link. These messages are communications between objects that convey information
about the activity and can include the sequence number.
Diagram:
Practical No:-08
Aim: Study and implementations of Activity Diagrams.
Theory: Activity diagram is another important diagram in UML to describe the dynamic
aspects of the system.
Activity diagram is basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential,
branched, or concurrent. Activity diagrams deal with all type of flow control by using
different elements such as fork, join, etc

Purpose of Activity Diagrams

The basic purposes of activity diagrams is similar to other four diagrams. It captures the
dynamic behaviour of the system. Other four diagrams are used to show the message flow
from one object to another but activity diagram is used to show message flow from one
activity to another.
Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing the dynamic nature of a system, but they are also used to construct the
executable system by using forward and reverse engineering techniques. The only missing
thing in the activity diagram is the message part.
It does not show any message flow from one activity to another. Activity diagram is
sometimes considered as the flowchart. Although the diagrams look like a flowchart, they
are not. It shows different flows such as parallel, branched, concurrent, and single.
The purpose of an activity diagram can be described as − • Draw the
activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.
Before drawing an activity diagram, we should identify the following elements −
• Activities
• Association
• Conditions
• Constraints

Following diagram is drawn with the four main activities

− • Send order by the customer
• Receipt of the order
 • Confirm the order
• Dispatch the order
After receiving the order request, condition checks are performed to check if it is normal or
special order. After the type of order is identified, dispatch activity is performed and that is
marked as the termination of the process.
Activity diagram can be used for −
• Modeling work flow by using activities.
• Modeling business requirements.
• High level understanding of the system's functionalities.
• Investigating business requirements at a later stage.

Diagram: