Practical No – 1

Aim: Study and implementation of class diagrams.

Defination of Class Diagram:

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.

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 object-
oriented languages and thus widely used at the time of construction.

Attributes:
An attribute is named property of a class which describes the object being
modeled. In the class diagram, this component is placed just below the name-
compartment.

Attributes characteristics:
• The attributes are generally written along with the visibility factor.
• Public, private, protected and package are the four visibilities which are
denoted by +, -, #, or ~ signs respectively.
• Visibility describes the accessibility of an attribute of a class.
• Attributes must have a meaningful name that describes the use of it in a
class.
Relationships
There are mainly three kinds of relationships in UML:

1. Dependencies
2. Generalizations
3. Associations

1. Dependency:
A dependency means the relation between two or more classes in which a
change in one may force changes in the other. However, it will always create a
weaker relationship. Dependency indicates that one class depends on another.
2. Generalizations:
A generalization helps to connect a subclass to its superclass. A sub-class is
inherited from its superclass. Generalization relationship can't be used to model
interface implementation. Class diagram allows inheriting from multiple
superclasses.
3. Associations:
This kind of relationship represents static relationships between classes A and
B. For example; an employee works for an organization.
Multiplicity:
A multiplicity is a factor associated with an attribute. It specifies how many
instances of attributes are created when a class is initialized. If a multiplicity is
not specified, by default one is considered as a default multiplicity.
Aggregation:
Aggregation is a special type of association that models a whole- part
relationship between aggregate and its parts.
Composition:
The composition is a special type of aggregation which denotes strong
ownership between two classes when one class is a part of another class.
 Practical No – 2
Aim: Study and implementation of Use Case Diagrams.

Defination of Use Case Diagram:

Use cases are used to represent high-level functionalities and how the user will
handle the system. A use case represents a distinct functionality of a system, a
component, a package, or a class. It is denoted by an oval shape with the name
of a use case written inside the oval shape.
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. Use case diagrams are used to gather the requirements of a system
including internal and external influences. These requirements are mostly
design requirements.
Attributes:
1. Use Case
2. Actor

1. Use Case:

Use cases are used to represent high-level functionalities and how the
user will handle the system. A use case represents a distinct functionality
of a system, a component, a package, or a class. It is denoted by an oval
shape with the name of a use case written inside the oval shape.

2. Actor:
It is used inside use case diagrams. The actor is an entity that interacts
with the system. A user is the best example of an actor. An actor is an entity that
initiates the use case from outside the scope of a use case. It can be any element
that can trigger an interaction with the use case. One actor can be associated
with multiple use cases in the system.
 Practical No – 3
Aim: Study and implementation of Entity Relationship Diagrams.
Defination of Entity Relationship Diagram:
ER-modeling is a data modeling method used in software engineering to
produce a conceptual data model of an information system. Diagrams created
using this ER-modeling method are called Entity-Relationship Diagrams or ER
diagrams or ERDs.
Purpose of Entity Relationship Diagram:
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.
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
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 are four types of Attributes:

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

Key attribute:

Key is an attribute or collection of attributes that uniquely identifies an entity

among the entity set.

There are mainly three types of keys:

Super key:

A set of attributes that collectively identifies an entity in the entity set.

Candidate key:

A minimal super key is known as a candidate key. An entity set may have
more than one candidate key.

Primary key:

A primary key is one of the candidate keys chosen by the database

designer to uniquely identify the entity set.

Composite attribute:

An attribute that is a combination of other attributes is called a composite

attribute.
Single-valued attribute:
Single-valued attribute contain a single value.

Multi-valued Attribute:
If an attribute can have more than one value, it is known as a multi-valued
attribute. Multi-valued attributes are depicted by the double ellipse.
Derived attribute: Derived attributes are the attribute that does not exist in the
physical database, but their values are derived from other attributes present in
the database. For example, age can be derived from date_of_birth. In the ER
diagram, Derived attributes are depicted by the dashed ellipse.
Relationships:
The association among entities is known as relationship. Relationships are
represented by the diamond-shaped box.
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.
Cardinality:
Cardinality describes the number of entities in one entity set, which can be
associated with the number of entities of other sets via relationship set.
Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most
one entity of entity set B and vice versa.
2. One to many: When a single instance of an entity is associated with
more than one instances of another entity then it is called one to many
relationships.
3. Many to One: More than one entity from entity set A can be associated
with at most one entity of entity set B, however an entity from entity set
B can be associated with more than one entity from entity set A.
4. Many to Many: One entity from A can be associated with more than one
entity from B and vice-versa.
 Practical No – 4
Aim: Study and implementation of Sequence Diagrams.
Defination of Sequence Diagram:
A sequence diagram is a type of interaction diagram because it describes how
and in what order a group of objects works together. These diagrams are used
by software developers and business professionals to understand requirements
for a new system or to document an existing process. Sequence diagrams are
sometimes known as event diagrams or event scenarios.
Benefits of sequence diagrams
Sequence diagrams can be useful references for businesses and other
organizations. Try drawing a sequence diagram to:
• Represent the details of a UML use case.
• Model the logic of a sophisticated procedure, function, or operation.
• See how objects and components interact with each other to complete a
process.
• Plan and understand the detailed functionality of an existing or future
scenario.
Use cases for sequence diagrams
The following scenarios are ideal for using a sequence diagram:
Usage scenario: A usage scenario is a diagram of how your system could
potentially be used.
Method logic: Just as you might use a UML sequence diagram to explore the
logic of a use case, you can use it to explore the logic of any function,
procedure, or complex process.
Service logic: If you consider a service to be a high-level method used by
different clients, a sequence diagram is an ideal way to map that out.
Sym
Name Description
bol

Represents a class or object in UML. The object symbol

Object symbol demonstrates how an object will behave in the context of the
system. Class attributes should not be listed in this shape.

Represents the time needed for an object to complete a task. The

Activation box
longer the task will take, the longer the activation box becomes.

Actor symbol Shows entities that interact with or are external to the system.

Used in UML 2.0 notation to contain interactive elements of the

Package
diagram. Also known as a frame, this rectangular shape has a
symbol
small inner rectangle for labeling the diagram.

Represents the passage of time as it extends downward. This

Lifeline dashed vertical line shows the sequential events that occur to an
symbol object during the charted process. Lifelines may begin with a
labeled rectangle shape or an actor symbol.

Option loop Used to model if/then scenarios, i.e., a circumstance that will
symbol only occur under certain conditions.

Symbolizes a choice (that is usually mutually exclusive) between

Alternative
two or more message sequences. To represent alternatives, use
symbol
the labeled rectangle shape with a dashed line inside.
Common message symbols

Use the following arrows and message symbols to show how information is
transmitted between objects. These symbols may reflect the start and execution
of an operation or the sending and reception of a signal.

Symbol Name Description

Represented by a solid line with a solid arrowhead. This

Synchronous symbol is used when a sender must wait for a response to
message symbol a message before it continues. The diagram should show
both the call and the reply.

Represented by a solid line with a lined arrowhead.

Asynchronous Asynchronous messages don't require a response before
message symbol the sender continues. Only the call should be included in
the diagram.

Asynchronous
return message Represented by a dashed line with a lined arrowhead.
symbol

Asynchronous
Represented by a dashed line with a lined arrowhead.
create message
This message creates a new object.
symbol

Reply message Represented by a dashed line with a lined arrowhead,

symbol these messages are replies to calls.

Delete message Represented by a solid line with a solid arrowhead,

symbol followed by an X. This message destroys an object.
 Practical No – 5
Aim: Study and implementation of State Transition Diagrams.
Defination of State Transition Diagrams:
State Diagram are used to capture the behavior of a software system. UML State
machine diagrams can be used to model the behavior of a class, a subsystem, a
package, or even an entire system. It is also called a Statechart or State
Transition diagram.
1. Behavioral state machine:
The behavioral state machine diagram records the behavior of an object
within the system. It depicts an implementation of a particular entity. It
models the behavior of the system.
2. Protocol state machine:
It captures the behavior of the protocol. The protocol state machine
depicts the change in the state of the protocol and parallel changes within
the system. But it does not portray the implementation of a particular
component.
Why State Transition Diagram?
Since it records the dynamic view of a system, it portrays the behavior of a
software application. During a lifespan, an object underwent several states, such
that the lifespan exist until the program is executing. Each state depicts some
useful information about the object.
It blueprints an interactive system that response back to either the internal
events or the external ones. The execution flow from one state to another is
represented by a state machine diagram. It visualizes an object state from its
creation to its termination.
The main purpose is to depict each state of an individual object. It represents an
interactive system and the entities inside the system. It records the dynamic
behavior of the system.
 Initial State

State1
State-Box

Decision-Box

Final State

a. Initial state:
It defines the initial state (beginning) of a system, and it is represented by a
black filled circle.
b. Final state:
It represents the final state (end) of a system. It is denoted by a filled circle
present within a circle.
c. Decision box:
It is of diamond shape that represents the decisions to be made on the basis of
an evaluated guard.
d. State box:
It depicts the conditions or circumstances of a particular object of a class at a
specific point of time. A rectangle with round corners is used to represent the
state box.
 Practical No – 6
Aim: Study and implementation of Data Flow Diagrams.
Defination Data Flow Diagram (DFD):
A Data Flow Diagram (DFD) is a traditional way to visualize the information
flows within a system. It uses defined symbols like rectangles, circles and
arrows, plus short text labels, to show data inputs, outputs, storage points and
the routes between each destination.
Why Data Flow Diagram:
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 as a data flow graph or bubble
chart.
Symbols used in DFD:
1. External entity: an outside system that sends or receives data,
communicating with the system being diagrammed. They are the sources
and destinations of information entering or leaving the system. They
might be an outside organization or person, a computer system or a
business system. They are also known as terminators, sources and sinks
or actors. They are typically drawn on the edges of the diagram.
2. Process: any process that changes the data, producing an output. It might
perform computations, or sort data based on logic, or direct the data flow
based on business rules. A short label is used to describe the process,
such as “Submit payment.”
3. Data store: files or repositories that hold information for later use, such
as a database table or a membership form. Each data store receives a
simple label, such as “Orders.”
4. Data flow: the route that data takes between the external entities,
processes and data stores. It portrays the interface between the other
components and is shown with arrows, typically labeled with a short data
name, like “Billing details.”
5. Circle: A circle (bubble) shows a process that transforms data inputs into
data outputs.
6. Source or Sink: Source or Sink is an external entity and acts as a source
of system inputs or sink of system outputs.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to elements in
the DFD.
2. 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.
3. 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.
4. Do not become bogged down with details. Defer error conditions and
error handling until the end of the analysis.
 Practical No – 7
Aim: Study and implementation of Collaboration Diagrams.
Defination of Collaboration Diagrams:
The collaboration diagram is used to show the relationship between the objects
in a system. Both the sequence and the collaboration diagrams represent the
same information but differently. Instead of showing the flow of messages, it
depicts the architecture of the object residing in the system as it is based on
object-oriented programming. An object consists of several features. Multiple
objects present in the system are connected to each other. The collaboration
diagram, which is also known as a communication diagram, is used to portray
the object's architecture in the system.
Purpose of Collaboration Diagram:
The collaborations are used when it is essential to depict the relationship
between the object. Both the sequence and collaboration diagrams represent the
same information, but the way of portraying it quite different. The collaboration
diagrams are best suited for analyzing use cases.
Following are the components of a component diagram that are enlisted
below:
1. Objects: The representation of an object is done by an object symbol
with its name and class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then
its class is specified.
o To differentiate one object from another object, it is necessary to
name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it
invokes the interaction. Each actor has its respective role and name. In
this, one actor initiates the use case.
3. Links: The link is an instance of association, which associates the objects
and actors. It portrays a relationship between the objects through which
 the messages are sent. It is represented by a solid line. The link helps an
object to connect with or navigate to another object, such that the
message flows are attached to links.
4. Messages: It is a communication between objects which carries
information and includes a sequence number, so that the activity may take
place. It is represented by a labeled arrow, which is placed near a link.
The messages are sent from the sender to the receiver, and the direction
must be navigable in that particular direction. The receiver must
understand the message.
 Practical No – 8
Aim: Study and implementation of Activity Diagrams.
Defination of Activity Diagram:
Activity Diagrams 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 basic purpose of activity diagrams is to capture the dynamic
behavior of the system.. It is also called object-oriented flowchart.
Use Activity Diagrams?
Activity diagram in UML allows you to create an event as an activity which
contains a collection of nodes joined by edges. An activity can be attached to
any modeling element to model its behavior.
Symbols for Activity Diagram:

• Initial states: The starting stage before an activity takes place is depicted
as the initial state
• Final states: The state which the system reaches when a specific process
ends is known as a Final State
• State or an activity box:
• Decision box: It is a diamond shape box which represents a decision with
alternate paths. It represents the flow of control.
 Practical No – 9
Aim: Study and implementation of Component Diagrams.
Defination of Component Diagram:
Component diagrams are different in terms of nature and behavior. Component
diagrams are used to model the physical aspects of a system. Now the question
is, what are these physical aspects? Physical aspects are the elements such as
executables, libraries, files, documents, etc. which reside in a node.
Purpose of Component Diagrams:
Component diagram is a special kind of diagram in UML. The purpose is also
different from all other diagrams discussed so far. It does not describe the
functionality of the system but it describes the components used to make those
functionalities.
The purpose of the component diagram can be summarized as:
• Visualize the components of a system.
• Construct executables by using forward and reverse engineering.
• Describe the organization and relationships of the components.
Use of Component Diagrams?
We have already described that component diagrams are used to visualize the
static implementation view of a system. Component diagrams are special type
of UML diagrams used for different purposes.
These diagrams show the physical components of a system. To clarify it, we can
say that component diagrams describe the organization of the components in a
system.
Organization can be further described as the location of the components.
Component diagram Notations:
1. A component

2. A node
A component in UML is represented as follows,

Port
A port is an interaction point between a classifier and an external environment.
It groups semantically cohesive set of provided and required interfaces. A port
can be used in UML without specifying the name of the port. A port may have
visibility.