AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Chapter Three
Over View of Unified Modelling Language
What is UML?
It’s an industry standard graphical language for visualizing, specifying, constructing, and
documenting the artifacts of a software intensive system.” [Booch]. It offers a standard way to
write a system’s blueprints, including conceptual things such as business processes and system
functions as well as concrete things such as programming language statements, database schemas,
and reusable software components.
UML includes a set of graphic notation techniques to create visual models of object-oriented
software systems. UML combines techniques from data modeling, business modeling, object
modeling, and component modeling and can be used throughout the software development lifecycle and across different implementation technologies.

UML is a generic broad language enabling the key aspects of software development to
capture on paper.

General-purpose modeling language

It’s a notation not a methodology.

UML is used to model systems build through Unified Approach.
It’s a language for modeling software systems. This language is used for specifying, visualizing,
constructing and documenting software systems throughout the development. (Mostly object
oriented development). UML is used to model systems build through Unified Approach. Unified
Approach combines the methodologies of Booch, Rumbaugh and Jacobson.
Unified Modeling Language (UML) is a well-accepted language for OOAD. The basic building
blocks of UML used for OOAD are things, relationships, and diagrams. Basically, the Unified
Modeling Language focuses on the concepts of Booch, OMT, and Object Oriented Software
Engineering (OOSE). The result of these concepts is a single, common, and widely usable
modeling language for users of these and other methods. The Unified Modeling Language also
promotes the concept of what can be done with existing methods. Many modern applications are
being developed based on object oriented principles such as classes, methods, and inheritance. To
fulfill the needs of such developments, CASE tools offer many benefits for developers building
large-scale systems. CASE tools enable us to abstract away from the mess of source code, to a
1
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
level where design and propose become more clear and easier to understand and modify. For
making and representing these features of the systems to be developed, some tools are used.
Benefits of UML

Use graphical notation to communicate more clearly than natural language (imprecise) and
code (too detailed).

Quick understanding

Help acquire an overall view of a system.

Lessens chances of conflicts.

UML is not dependent on any one language or technology.

Necessary to manage complexity.

UML moves us from fragmentation to standardization.
Model: An abstraction describing a problem domain and/or a solution to a problem domain.
Traditionally models are thought of as diagrams plus their corresponding documentation,
although non-diagrams, such as interview results and collections of CRC cards, are also
considered to be models. There is a difference between a UML model and the set of diagrams of
a system. A diagram is a partial graphic representation of a system’s model. The model also
contains documentation that drives the model elements and diagrams (such as written use cases).
Modeling: Technique of creating models. It is also a good medium of communication between
developers at various levels.
Advantages:

Clarity – Visual representations are mode clear and informative than listed or written
documents. Missed out details can be easily found out.

Familiarity – Similar modeling language and techniques is followed by developers
working in same domain.

Maintenance – Changes can be made easily in visual systems and changes can be
confirmed easily.

Simplification – More complex structures can be represented in an abstract manner to
deliver the conceptual idea
UML diagrams represent three different views of a system model:
functional model: represented in UML with use case diagrams, describes the functionality of the
system from the user’s point of view.
2
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Object (Static or structural) model: This view emphasizes the static structure of the system
using objects, attributes, operations, and
relationships. Ex: Class diagram, Composite Structure diagram.
Dynamic (or behavioral) model: This view emphasizes the dynamic behavior of the system by
showing collaborations among objects and changes to the internal states of objects. Ex: Sequence
diagram, Activity diagram, State Machine diagram.
Use Case Diagram
Describes the functionality provided by a system in terms of actors, their goals represented as use
cases, and any dependencies among those use cases. A use case is the description of set of
interaction between as actor and system.

It is used during requirements elicitation and analysis.

focus on the behavior of the system from an external point of view(actor).

Used for describing a set of user scenarios

Illustrates functionality provided by the system

Mainly used for capturing user requirements

Work like a contract between end user and software developers
The primary goals of Use Case diagrams include:

Providing a high-level view of what the system does.

Identifying the users ("actors") of the system.

Determining areas needing human-computer interfaces.
Components of use case diagram

Actor: - any entity that interacts with the system (e.g., a user, another system, the system’s
physical environment).

Use case: - A set of scenarios that describing an interaction between a user and a system,
including alternatives

System boundary: - rectangle diagram representing the boundary between the actors and the
system.
Types of relationships in use case diagram

Association: - communication between an actor and a use case. Represented by a solid line.
_________________
3
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE

Generalization: - relationship between one general use case and a special use case.
Represented by a line with a triangular arrow head toward the parent use case.

Include: - occurs when a chunk of behavior is similar across more than one use case. Two
use case are related by an include relationship if one of them include the second one in its
flow of event. Include relationships are showed by a dashed open arrow originating from the
including usecase include relationships are labeled with the string <<include>>.
o Use “include” instead of copying the description of that behavior.
o The direction of a <<includes>> relationship is to the using use case

Extend: - The extending use case may add behavior to the base use case.
extend
relationships are showed by a dashed open arrow to the extended. extend relationships are
labeled with the string <<extend>>.
Reuse in Use Case Models: <<extend>>, <<include>>, and Inheritance
An extend association is a generalization relationship where an extending use case continues the
behavior of a base use case. The extending use case accomplishes this by conceptually inserting
additional action sequences into the base use case sequence. This allows an extending use case to
continue the activity sequence of a base use case when the appropriate extension point is reached
in the base use case and the extension condition is fulfilled. When the extending use case activity
sequence is completed, the base use case continues. the notation for doing so being simply a normal
use case association with the stereotype of <<extend>>. Stereotypes are a mechanism for defining
common and consistent extensions to the UML notation. An extending use case is, effectively, an
alternate course of the base use case.
A second way to indicate potential reuse within use case models is to include associations. An
include association is a generalization relationship denoting the inclusion of the behavior described
by another use case. The best way to think of an include association is that it is the invocation of a
4
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
use case by another one. the notation for doing so being simply a normal use case association with
the stereotype of <<include>>. You use associations whenever one use case needs the behavior
of another. Introducing a new use case that encapsulates similar logic that occurs in several use
cases is quite common
Use cases can inherit from other use cases, offering a third opportunity to indicate potential reuse
Inheritance between use cases is not as common as the use of either extend or include associations,
but it is still possible. The inheriting use case would completely replace one or more of the courses
of action of the inherited use case
The inheriting use case is much simpler than the use case from which it inherits. It should have a
name, description, and identifier, and it should indicate from which use case it inherits. This
includes any section that is replaced, particularly the preconditions and post conditions as well as
any courses of action. If something is not replaced, then leave that section blank, assuming it is
inherited from the parent use case (you might want to put text, such as "see parent use case," in the
section).
The standard UML notation for inheritance, the open-headed arrow, is used and the advice
presented about the appropriate use of inheritance still applies: it should make sense to say the
inheriting actor is or is like the inherited actor.
Use case Description
Each Use Case contains a full set of textual details about the interactions and scenarios contained
within it.

Use case no: no of the use case

Usecase name: Name of the usecase

Short Description: A Brief Description of the Use Case

Participating Actors: actors participate in the use case

Pre-Conditions: A description of the conditions that must be satisfied before the use case
is invoked

Post-Conditions: A description of what has happened at the end of the use case

Main Flow: A list of the system interactions that take place under the most common
scenario. For example, for withdraw money, this would be entering card, enter pin, etc...

Alternate Flow(s): A description of possible alternative interactions.
5
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE

Exception Flow(s): A description of possible scenarios where unexpected or unpredicted
events have taken place
6
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Criminal management System
approve
update account
give certificate
<extend>
create account
<etend>
<etend>
delet account
manage account
<include>
<include>
<include>
<include>
<include>
<include>
logout
<incude>
<include>
login
register prisoner
<include>
<exted
>
Generate Report
<include>
<include>
Prson
Administrator
update data
<include>
register traninig
<include>
generate id
Training
center
<include>
<include>
<include>
<include>
Register visitor
System
administra
tor
Identify pricharge
Give parole
Security
manager
update visitor
Release
manager
View
Give clearance
Register release
Use case description for login
Usecase no
1
Usecasae name
Login
Actor
All
Priority
High
7
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Pre- condition
the user should have an account in the system
Description
Actors log in to the system in order to have privilege for preforming
task
different
Main flow
Actor action
system response
1. User open web page
3. Login form displayed
2. Select login link
6. Valid data entry
4
7. Users home page displayed
enter user name and
Password
5
Alternative flow
Post-condition
click login button
if the user name and pass word don’t match go to step 4
The user logged the system and provided with privileges for actions
according to there role
Class Diagram
Describe the system in terms of objects, classes, attributes, operations, and their associations.
We use class diagrams to describe the structure of the system.
It is used

During requirements analysis to model application domain concepts

During system design to model subsystems

During object design to specify the detailed behavior and attributes of classes.

Detailed class diagrams are used for developers.
A class is a description of a set of objects that share the same attributes, operations, relationships,
and semantics.
Class Representation
Each class is represented by a rectangle subdivided into three compartments

Name

Attributes
8
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE

Operations
Modifiers are used to indicate visibility of attributes and operations.

‘+’ is used to denote Public visibility (everyone)

‘#’ is used to denote Protected visibility (friends and derived)

‘-’ is used to denote Private visibility (no one)
By default, attributes are hidden and operations are visible.
Class
Attribute
The name of the class is the only required tag in the graphical
representation of a class. It always appears in the top-most compartment.
Operation
An attribute is a named property of a class that describes the object being
modeled. In the class diagram, attributes appear in the second compartment
just below the name-compartment.
Person
Operations describe the class behavior and appear in the third compartment.
- name : String
-birthdate : Date
-ssn
: Id
+eat()
+sleep()
+work()
+play()
Relationships

A link represents a connection between two objects.

Associations are relationships between classes and represent groups of links.

Roles: a string each end of an association which clarify the purpose of the association.

Multiplicity: a set of integers indicating the number of links that can legitimately originate
from an instance of the class connected to the association end.

Aggregation: Aggregation are used to represent a wide range of connections among a set of
objects.

Generalization It is the relationship between a general class and one or more specialized
classes. It is used to describe all the attributes and operations that are common to a set of
classes.
9
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Sequence diagram
An "interaction diagram" that models a single scenario executing in the system models the
collaboration of objects based on a time sequence. Is the second most used UML diagram (behind
class diagram). Useful to identify or find missing objects Time consuming to build, but worth the
investment.
Parts of a sequence diagram

Participant: object or entity that act on the diagram

Message: communication between participant object

Actors are shown as the leftmost column.

Lifeline: Identify the existence of the object over time

Activations: Indicate when an object is performing an action

Each column in the diagram represents an object that participates in the interaction.

The vertical axis represents time from top to bottom.
10
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Object 1
Object 2
Actors
Objects
Message
Lifelines
Activation
Sequence Diagram (make a phone call)
Sequence diagram for login
11
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Main
page
Controller
Login
Actors
Sequence diagram for ATM
Activity diagram
12
Database
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Activity diagram describes a system in terms of activities. Where Activities are states that represent
the execution of a set of operations.
Activity diagrams are similar to flowchart diagrams in that they can be used to represent control
flow and data flow.
Activity diagrams are state chart diagrams whose states are action states.
An activity diagram is essentially a flowchart, showing the flow of control from activity to activity.
Use activity diagrams to specify, construct, and document the dynamics of a society of objects, or
to model the flow of control of an operation. Whereas interaction diagrams emphasize the flow of
control from object to object, activity diagrams emphasize the flow of control from activity to
activity.
Activity diagrams are used for

documenting existing process

analyzing new Process Concepts

finding reengineering opportunities.
UML representation for activity diagram
•
Initial State: The filled circle (solid circle) is the starting point of the diagram.
•
Final state: Marks the end of the modeled work flow shown as solid circle enclosed in an
open circle)
•
Action state: The rounded rectangles represent activities/action that occur. An activity
may be physical, such as Inspect Forms, or electronic, such as Display Create Student
Screen. Shown as rectangle with its left and right sides replaced by arcs curving outwards
•
Action order: when the action state is completed processing move to another action state
shown as arrow with a stick arrowhead
•
Fork: A black bar with one flow going into it and several leaving it. This denotes the
beginning of parallel activity.
•
Join: A black bar with several flows entering it and one leaving it. This denotes the end of
parallel processing.
•
Condition: Text such as [Incorrect Form] on a flow, defining a guard that must evaluate
to true in order to traverse the node.
13
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
•
Decision: A diamond with one flow entering and several leaving. The flows leaving
include conditions although some modelers will not indicate the conditions if it is obvious.
•
Merge: A diamond with several flows entering and one leaving. The implication is that all
incoming flows must reach this point until processing continues.
Initial State
Fork
Action State
Decision
Action Order
Condition
Join
Merge
Final state
14
AN OVER VIEW OF UNIFIED MODELLING LANGUAGE
Activity Diagram for login
15