UNIFIED MODELLING LANGUAGE Sushma Vankhede

UNIFIED MODELLING LANGUAGE

Each UML diagram is designed to let developers and customers view a software system from
a different perspective and in varying degrees of abstraction.
Visual language
General purpose modelling language
Need to create blueprint of the system
To precise idea of system in visual representation

A Use Case diagram simplifies the complex system and is very powerful as a picture is worth a
thousand words!
TYPES
UML diagrams commonly created in visual modeling tools include:
1) Use Case Diagram displays the relationship among actors and use cases.1
2) Class Diagram models class structure and contents using design elements such as classes,
packages and objects. It also displays relationships such as containment, inheritance, associations
and others.
3) Interaction Diagrams
• Sequence Diagram displays the time sequence of the objects participating in the interaction.
This consists of the vertical dimension (time) and horizontal dimension (different objects).1
• Collaboration Diagram displays an interaction organized around the objects and their links to
one another. Numbers are used to show the sequence of messages.1
TYPES
4) State Diagram displays the sequences of states that an object of an interaction
goes through during its life in response to received stimuli, together with its responses
and actions.
5) Activity Diagram displays a special state diagram where most of the states are
action states and most of the transitions are triggered by completion of the actions in
the source states. This diagram focuses on flows driven by internal processing.
TYPES
6) Physical Diagrams
• Component Diagram displays the high level packaged structure of the code itself.
Dependencies among components are shown, including source code components, binary code
components, and executable components. Some components exist at compile time, at link time,
at run times well as at more than one time. 1
• Deployment Diagram displays the configuration of run-time processing elements and the
software components, processes, and objects that live on them. Software component instances
represent run-time manifestations of code units.
 USE CASE DIAGRAMS
A use case is a set of scenarios that describing an interaction between a user and a
system.
A use case diagram displays the relationship among actors and use cases. The two
main components of a use case diagram are use cases and actors.

An actor is represents a user or another system that will interact with the system you are modeling.
A use case is an external view of the system that represents some action the user might perform in order to
complete a task.
WHEN TO USE: USE CASES DIAGRAMS
Use cases are used in almost every project.
They are helpful in exposing requirements and planning the project.
During the initial stage of a project most use cases should be defined, but as the
project continues more might become visible.
HOW TO DRAW: USE CASES DIAGRAMS
Use cases are a relatively easy UML diagram to draw, but this is a very simplified
example.
Start by listing a sequence of steps a user might take in order to complete an action. For
example a user placing an order with a sales company might follow these steps.
1. Browse catalog and select items.
2. Call sales representative.
3. Supply shipping information.
4. Supply payment information.
5. Receive conformation number from salesperson.
USE CASES DIAGRAMS
EXAMPLE : ONLINE TRAINING REGISTRATION
Step 1: Draw the System Boundary and name the system
Step 2:
Draw the actors by referring to the
column ‘Allowed actors’ in the ‘List of
System’ section and name them as per
the project standard icon and names
as described in the ‘List of Actors’
section of the document.
The actors ‘New-User’, ‘Registered-
User’, and ‘Employee–Cashier’ are the
primary actors of the system.
The other two support service actors,
i.e. the ‘Bank-Payment-Service’ and
the ‘User-Authentication-Service’ are
the supporting actors.
Step 3:
Draw the use case in the scope of the system by referring to the column ‘Use Case names’ in the ‘List
of System’ section and name the use cases as mentioned in the ‘List of Use Cases‘ section of the
document.
Step 4:
Add the Include and extension use cases for
the in-scope use cases by referring to the
‘List of Use Cases‘ section of the document.
‘Join-a-Course’ includes two Use cases–
‘Course-payment’ and ‘View-Courses’.
Establish the association with a dash-line
starting from the base use case with an
arrow pointing to the included two use
cases.
Depict ‘Register-User’ with its two extension
points with ‘Register-help’ and ‘Location-
Search-help’ and associate it with a dashed
line and an arrow pointing to ‘Register-
User’.
The Note feature can be added as shown in
the diagram to give details.
Step 5:
Establish the link between the actors and
the Use cases. The column ‘Allowed
Actors/Multiplicity number of Actor’ in the
‘List of Use Cases‘ section of the document
gives all the actors to Use case
association.
There can be some actor that is allowed
by the Use case but they do not have any
role in the current system being depicted.
Like the actor ‘Instructor’ that can access
use case ‘View-Courses’ but does not have
a role in the current system being
depicted.
UML Diagram
ACTIVITY DIAGRAM
In UML, the activity diagram is used to demonstrate the flow of control within the
system rather than the implementation. It models the 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 as an object-oriented flowchart. It encompasses activities composed
of a set of actions or operations that are applied to model the behavioral diagram.
COMPONENTS OF AN ACTIVITY DIAGRAM
Activities: The categorization of behavior into one or more actions is termed as an
activity.

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.
COMPONENTS OF AN ACTIVITY DIAGRAM
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.
COMPONENTS OF AN ACTIVITY DIAGRAM
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) edge.
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?
Activity diagrams are used for various purposes and at different stages in the development process.
During the planning stage, you can create an activity diagram to depict workflows and visualize
the sequence of activities in a system.
Meanwhile, at the requirements stage, activity diagrams can be used to present different use
cases for a system.
As for the design phase, an activity diagram can model software elements such as method,
function, and operation.
Other uses of activity diagrams include:
 Modeling business processes
 Illustrating the dynamic aspects of a system
 Defining the logic or rules of a system
 Identifying use cases for a system
 Simplifying complex workflows
HOW TO DRAW AN ACTIVITY DIAGRAM?
An activity diagram is a flowchart of activities, as it represents the workflow among various
activities.
An activity diagram is an enhancement of the flowchart, which encompasses several unique
skills. Since it incorporates swimlane, branching, parallel flows, join nodes, control nodes, and
forks, it supports exception handling.
Exception handling is shown with the help of -

A system must be explored as a whole before drawing an activity diagram to provide a

clearer view of the user.
After gathering all the essential information, an abstract or a prototype is built, which is then
transformed into the actual diagram.
Following are the rules that are to be followed for drawing an activity diagram:
 A meaningful name should be given to each and every activity.
 Identify all of the constraints.
 Acknowledge the activity associations.
EXAMPLE : ORDER PROCESSING
EXAMPLE: ADDING TEXT TO TEXT FILE
SEQUENCE DIAGRAM
Sequence Diagram is an interaction diagram that details how operations are carried
out -- what messages are sent and when.
Sequence diagrams are organized according to time. The time progresses as you go
down the page.
The objects involved in the operation are listed from left to right according to when
they take part in the message sequence.
EXAMPLE: CREATING AN ALBUM
ELEMENT OF SEQUENCE DIAGRAM
Actor
Lifeline
Activation
Call message
Return message
Self message
Create message
Destroy message
Duration message
Note / Comment
ACTOR
•a type of role played by an entity that interacts with the subject
(e.g., by exchanging signals and data)
•external to the subject (i.e., in the sense that an instance of an actor
is not a part of the instance of its corresponding subject).
•represent roles played by human users, external hardware, or other
subjects.
LIFELINE
A lifeline represents an individual participant in the Interaction.
ACTIVATIONS
A thin rectangle on a lifeline) represents the period during which an element is
performing an operation.
The top and the bottom of the of the rectangle are aligned with the initiation and the
completion time respectively
CALL MESSAGE
•A message defines a particular communication between Lifelines of an Interaction.
•Call message is a kind of message that represents an invocation of operation of
target lifeline.
RETURN MESSAGE
•A message defines a particular communication between Lifelines of an Interaction.
•Return message is a kind of message that represents the pass of information back to
the caller of a corresponded former message.
SELF MESSAGE
•A message defines a particular communication between Lifelines of an Interaction.
•Self message is a kind of message that represents the invocation of message of the
same lifeline.
CREATE MESSAGE
A message defines a particular communication between Lifelines of an Interaction.
Create message is a kind of message that represents the instantiation of (target)
lifeline.
DESTROY MESSAGE
A message defines a particular communication between Lifelines of an Interaction.
Destroy message is a kind of message that represents the request of destroying the
lifecycle of target lifeline.
DURATION MESSAGE
A message defines a particular communication between Lifelines of an Interaction.
Duration message shows the distance between two time instants for a message
invocation.
NOTE
A note (comment) gives the ability to attach various remarks to elements. A comment
carries no semantic force, but may contain information that is useful to a modeler.
SEQUENCE FRAGMENTS
Sequence fragments have been
introduced by UML 2.0, which makes
it quite easy for the creation and
maintenance of an accurate sequence
diagram.
It is represented by a box called a
combined fragment, encloses a part
of interaction inside a sequence
diagram.
The type of fragment is shown by a
fragment operator.
TYPES OF SEQUENCE FRAGMENTS
EXAMPLE
CLASS DIAGRAM
The class diagram depicts a static view of an application. It represents the types of
objects residing in the system and the relationships between them.
A class consists of its objects, and also it may inherit from other classes.
A class diagram is used to visualize, describe, document various different aspects of
the system, and also construct executable software code.
It shows the attributes, classes, functions, and relationships to give an overview of the
software system.
Since it is a collection of classes, interfaces, associations, collaborations, and
constraints, it is termed as a structural diagram.
PURPOSE OF CLASS DIAGRAMS
The main purpose of class diagrams is to build a static view of an application. It is
the only diagram that is widely used for construction, and it can be mapped with
object-oriented languages. It is one of the most popular UML diagrams. Following are
the purpose of class diagrams given below:
It analyses and designs a static view of an application.
It describes the major responsibilities of a system.
It is a base for component and deployment diagrams.
It incorporates forward and reverse engineering.
BENEFITS OF CLASS DIAGRAMS
It can represent the object model for complex systems.
It reduces the maintenance time by providing an overview of how an application is
structured before coding.
It provides a general schematic of an application for better understanding.
It represents a detailed chart by highlighting the desired code, which is to be
programmed.
It is helpful for the stakeholders and the developers.
COMPONENTS OF A CLASS DIAGRAM
Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes, operations, and
semantics. Some of the following rules that should be taken into account while representing a
class are given below:
 Capitalize the initial letter of the class name.
 Place the class name in the center of the upper section.
 A class name must be written in bold format.
 The name of the abstract class should be written in italics format.

Middle Section: The middle section constitutes the attributes, which describe the quality of the
class. The attributes have the following characteristics:
 The attributes are written along with its visibility factors, which are public (+), private (-), protected (#), and
package (~).
 The accessibility of an attribute class is illustrated by the visibility factors.
 A meaningful name should be assigned to the attribute, which will explain its usage inside the class.
PERSPECTIVES OF CLASS DIAGRAM
A diagram can be interpreted from various perspectives:
Conceptual: represents the concepts in the domain
Specification: focus is on the interfaces of Abstract Data Type (ADTs) in the software
Implementation: describes how classes will implement their interfaces.
The perspective affects the amount of detail to be supplied and the kinds of
relationships worth presenting.
CLASS VISIBILITY
The +, - and # symbols before an attribute and operation name in a class denote the
visibility of the attribute and operation.
+ denotes public attributes or operations
- denotes private attributes or operations
# denotes protected attributes or operations
COMPONENTS OF A CLASS DIAGRAM
Lower Section: The lower section contain methods or operations. The methods are
represented in the form of a list, where each method is written in a single line. It
demonstrates how a class interacts with data.
RELATIONSHIPS
Dependency: A dependency is a semantic relationship between two or more classes
where a change in one class cause changes in another class. It forms a weaker
relationship.
In the following example, Student_Name is dependent on the Student_Id.
RELATIONSHIPS
Generalization: A generalization is a relationship between a parent class
(superclass) and a child class (subclass). In this, the child class is inherited from the
parent class.
For example, The Current Account, Saving Account, and Credit Account are the
generalized form of Bank Account.
RELATIONSHIPS
Association: It describes a static or physical connection between two or more objects.
It depicts how many objects are there in the relationship.
For example, a department is associated with the college.
MULTIPLICITY:
It defines a specific range of allowable instances of attributes. In case if a range is
not specified, one is considered as a default multiplicity.
For example, multiple patients are admitted to one hospital.
AGGREGATION:
An aggregation is a subset of association, which represents has a relationship. It is
more specific then association. It defines a part-whole or part-of relationship. In this
kind of relationship, the child class can exist independently of its parent class.
The company encompasses a number of employees, and even if one employee
resigns, the company still exists.
COMPOSITION
Composition: The composition is a subset of aggregation. It portrays the
dependency between the parent and its child, which means if one part is deleted,
then the other part also gets discarded. It represents a whole-part relationship.
A contact book consists of multiple contacts, and if you delete the contact book, all
the contacts will be lost.
ABSTRACT CLASSES
In the abstract class, no objects can be a direct entity of the abstract class. The
abstract class can neither be declared nor be instantiated. It is used to find the
functionalities across the classes. The notation of the abstract class is similar to that of
class; the only difference is that the name of the class is written in italics. Since it does
not involve any implementation for a given function, it is best to use the abstract class
with multiple objects.
Let us assume that we have an abstract class named displacement with a method
declared inside it, and that method will be called as a drive (). Now, this abstract
class method can be implemented by any object, for example, car, bike, scooter,
cycle, etc.
HOW TO DRAW A CLASS DIAGRAM?
1. To describe a complete aspect of the system, it is suggested to give a meaningful
name to the class diagram.
2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of
the unwanted property will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the
aspects of a diagram.
6. The diagrams should be redrawn and reworked as many times to make it correct
before producing its final version.
CLASS DIAGRAM EXAMPLE: SALES ORDER SYSTEM
WHY CLASS DIAGRAM?
To describe the static view of a system.
To show the collaboration among every instance in the static view.
To describe the functionalities performed by the system.
To construct the software application using object-oriented languages.
UML 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.
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
Component

Node
PURPOSE OF A COMPONENT DIAGRAM
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?
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:
To divide a single system into multiple components according to the functionality.
To represent the component organization of the system.
HOW TO DRAW A COMPONENT DIAGRAM?
Following are some artifacts that are needed to be identified before drawing a component
diagram:
What files are used inside the system?
What is the application of relevant libraries and artifacts?
What is the relationship between the artifacts?
Following are some points that are needed to be kept in mind after the artifacts are
identified:
Using a meaningful name to ascertain the component for which the diagram is about to be
drawn.
Before producing the required tools, a mental layout is to be made.
To clarify the important points, notes can be incorporated.
EXAMPLE OF A COMPONENT DIAGRAM
A component diagram for an online shopping system is given below:
EXAMPLE OF COMPONENT DIAGRAM
CASE STUDY
In this Case Study Find out System or Any Real Time Application & Present the
following detail about it:
1. System Name
2. System Description
3. Process Model
4. Requirement Gathering
5. Create Use Case Diagram
6. Software Scope & Feasibility Study
7. Risk Analysis and Quality management