Ch 2.1

Chapter Two
Unified Modelling Language

Introduction
 Unified approach:
 Helps to understood OO concept and system development
 UML is set of notation and conventions used to describe and model
an application.
 Notations enable us to articulate complex ideas briefly and
precisely.
 For a notation to enable accurate communication, it must
come with a well-deﬁned semantics, it must be well suited for
representing a given aspect of a system, and it must be well
understood among project participants.

Overview of UML
 UML is a notation that resulted from the uniﬁcation of OMT
(Object Modeling Technique, [Rumbaugh et al., 1991]), Booch
[Booch, 1994], and OOSE (Object-Oriented Software
Engineering, [Jacobson et al., 1992]) (e.g. use cases).
 OMT separates modelling into three different parts
 An object model, presented by object model and data dictionary
 A dynamic model, presented by the state diagrams and event flow
diagram
 A functional model, presented by data flow and constraint

Overview…
 BOOCH Methodology
 Widely used object-oriented methodology that helps you
design the system using object paradigm.
 It covers
 Analysis and design phases of an object-oriented system
 It consists the following diagram
 Class diagram
 Object diagram
 State transition diagram
 Etc.

UML…
 Is a language for specifying, constructing, visualising and
documenting the software system and its components.
 Is graphical language with sets of rules and semantics.
 The rules and semantics of a model are expressed in
English, in a form known as object constraint language(
OCL).
 OCL is a specification language that uses simple logic for
specifying the property of the system.
 However, UML is not programming language.

UML…
 The primarily goals in the design of UML were:
 Provide users are ready to use, expensive visual modelling language
so they can develop and exchange meaningful models.
 Provide extensibility and specialization mechanism to extend the core
concepts.
 Be independent of particular programing languages and development
process.
 Provide a formal basis for understanding the modelling language
 Encourage the growth of the oo tools market
 Support higher-level development concepts
 Integrate best practices and methodologies.

Building Blocks of UML
 As UML describes the real-time systems, it is very
important to make a conceptual model and then
proceed gradually.
 The conceptual model of UML can be mastered by
learning the following three major elements:
 UML building blocks
 Rules to connect the building blocks
 Common mechanisms of UML

Cont…
 The building blocks of UML
can be defined as −
 Things
 Relationships
 Diagrams
 Things are the most
important building blocks of
UML. Things can be:
 Structural
 Behavioural/dynamic
 Grouping
 Annotation

Structural things
 Structural things define the static part of the model.
 They represent the physical and conceptual elements.
Following are the brief descriptions of the structural things.
 Class: represent a set of objects having similar responsibilities
 Interface: Interface defines a set of operations, which specify the
responsibility of a class.
 Use case: Use case represents a set of actions performed by a
system for a specific goal.
 Component: physical part of the system

Behavioural things
 Represents dynamic part of the UML models. The following
can be consider as behavioural things:
 Interaction-message exchange among different elements to
accomplish a specific task.
 Sequence diagram
 Activity diagram
 State machine: State machine is useful when the state of an object
in its life cycle is important.
 It defines the sequence of states an object goes through in response to events.
Events are external factors responsible for state change

Grouping things
 can be defined as a mechanism to group elements of
a UML model together. There is only one grouping
thing available:
 Package − Package is the only one grouping thing
available for gathering structural and behavioral things.

Annotation Things
 Annotational things can be defined as a mechanism
to capture remarks, descriptions, and comments of
UML model elements.
 Note - It is the only one Annotational thing available. A
note is used to render comments, constraints, etc. of
an UML element.


Relationship
 Relationship is another most important building block
of UML. It shows how the elements are associated
with each other and this association describes the
functionality of an application.
 There are four kinds of relationships available.
 Dependency is a relationship between two things in which
change in one element also affects the other.

Relationship
 Association: is basically a set of links that connects
the elements of a UML model. It also describes how
many objects are taking part in that relationship.
 Generalization: can be defined as a relationship
which connects a specialized element with a
generalized element. It basically describes the
inheritance relationship in the world of objects.

Relationship
 Realization: can be defined as a relationship in which
two elements are connected. One element describes
some responsibility, which is not implemented and the
other one implements them. This relationship exists in
case of interfaces.


UML Diagrams
 UML diagrams are the ultimate output of the entire
discussion. All the elements, relationships are used to
make a complete UML diagram and the diagram
represents a system.
 The visual effect of the UML diagram is the most
important part of the entire process. All the other
elements are used to make it complete.

UML Diagrams
 Use Case Diagrams
 Object diagram
 Class Diagrams
 Sequence diagrams
 Collaboration diagram
 State chart diagrams
 Activity diagrams
 Component diagram
 Deployment diagram

Use case diagram
 It was introduced by Ivar Jacobson in OOSE.
 Use case helps to represent actions done by the end users.
 Use case helps to show or visualize user requirement
 A use case describes how a user uses a system to accomplish a particular goal.
 The functionality of a system is described in number of different use cases, each
of which represents a specific flow of events in the system.
 Use case corresponds to a sequence of transaction, in which each transaction is invoked from
outside the system (actors) and engages internal objects to interact with one another and with the
system’s surrounding.
 A Use Case represents an interaction between an actor (human or machine) and the
system in performing meaningful work. Example of meaningful work is login to system,
register with system and create order.

Essential Use Case Modeling
• To model behavioral requirements
• It is one of the two basic flavors
– Essential Use Case – Business/Abstract Use Case
– System Use Case – Concrete /Detailed Use Case
• Intended to capture the essence of problems through
technology free, idealized and abstract descriptions
• Flexible
• A picture says 1,000 words

Use case characteristics
 Organizes functional requirements
 Models the goals of system/actor (user) interactions
 Describes one main flow of events (main scenarios)
and possibly other exceptional flows (alternatives),
also called paths or user scenarios

Use case diagram…
• In general it is Collection of use cases, actors, their
associations, a system boundary box (Optional), and
packages (Optional)
• Horizontal Ellipse – Use Cases
• Stick Figures – Actors – role players
• Line – Association and Relationship
• Arrow – Initial invocation (optional)
• Rectangle around use case – Scope of the system
• File Folders – Packages (organized model elements into
groups)

 E.g.
 a use-case diagram shows the relationship among
actors and use cases within a system.

Relationship in use case diagram
 Communication
 Are the paths btn the user and the use cases
 Use/include(<<include>>, ----):
 This is represented by dashed line from the one use case
to other use case.
Manage
account
Login
<<include>> valid
<<include>>

Relationship….
 Extend (<<extend>>, <-----)
 It can be considered as sub-class
 An extending use case is, effectively, an alternate course of the base use case. The
<<extend>> use case accomplishes this by conceptually inserting additional action
sequences into the base use-case sequence.
View
report
Print
report
<< extend>>
Generate
report
<<include>>

Abstract and generalized Use Case
 The general use case is abstract. It can not be
instantiated, as it contains incomplete information. The
title of an abstract use case is shown in italics.

use case description
 There is also
 Defines the outside(actor) and inside (use case)
defines what happens in the system when the use
case is performed.
 Use case model defines the outside and inside
behaviour of the system
 It represents specific flow of events in the system

Documenting use case
• Sections
– Name – name of the use case
– //Description – summary of a use case
– Actors (optional) – associated with the use case
– purpose of the use case
– //Status (optional) – work in progress etc…
– Precondition – conditions that must be met
– Post condition – effect of a use case action
– //Extension Points (optional) – covered later
– Included Use Cases (optional) – covered later
– Basic Course of Action – logic followed
– Alternate Course of Action – Infrequently used path
– Change History (optional) – when, who, why modified use cases

Sample Documentation (Login)
Use Case Name Login
Actor(s) USER
Purpose Allow user to access the system
Pre-condition The user not already logged in to the system and have a username and password
Flow of event 1. The user sends the request to the server using a web browser
2. The system displays the login page.
3. The user enters the user name and password and press submit button.
4. The system verifies the account [Alternate 4]
5. The user access the system
6. Use case end
Post condition User access to the system
Alternate 4 The user account not found in the system,
4.1. System display “Incorrect user name or password ” message
4.2. Go to 2.

Benefits of Use Case Diagram
 Use cases is a powerful technique for the elicitation and documentation of black-box
functional requirements.
 Because, use cases are easy to understand and provide an excellent way for
communicating with customers and users as they are written in natural language.
 Use cases can help manage the complexity of large projects by partitioning the problem
into major user features (i.e., use cases) and by specifying applications from the users'
perspective.
 A use case scenario, often represented by a sequence diagram, involves the
collaboration of multiple objects and classes, use cases help identify the messages
(operations and the information or data required - parameters) that glue the objects and
classes together.

Cont….
 Use cases provide a good basis to link between the
verification of the higher-level models (i.e. interaction between
actors and a set of collaborative objects), and subsequently,
for the validation of the functional requirements (i.e. blueprint
of white-box test).
 Use case driven approach provides an traceable links for
project tracking in which the key development activities such
as the use cases implemented, tested, and delivered fulfilling
the goals and objectives from the user point of views.

How to Draw a Use Case Diagram
 A Use Case model can be developed by following the steps below.
 Identify the Actors (role of users) of the system.
 For each category of users, identify all roles played by the users relevant to the
system.
 Identify what are the users required the system to be performed to achieve these
goals.
 Create use cases for every goal.
 Structure the use cases.
 Prioritize, review, estimate and validate the users.

Class Diagram
 Class diagram show the static structure of the model.
 A class diagram is a collection static modelling elements, such as
classes and their relationships, connected a graph to each other and to
their contents.
 Class diagram describes the attributes and operations of a class and
also the constraints imposed on the system.
 It refers to object modelling, is the main static analysis diagram.
 Object modelling is the process by which the logical objects in the real
world or represented by the actual objects in the program.
 The visual representation, their relationship to other classes, and their
structure is for ease of understanding.

Cont…
 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 is also considered as the foundation for
component and deployment diagrams.
 UML diagrams are not directly mapped with any
object-oriented programming languages but the class
diagram is an exception.

Cont…
 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.

Class Diagram elements…
 Class Notation: Static structure,
 Class is drawn as a rectangle with three components separated by
horizontal lines.
 The top name section holds the class name,
 The middle section holds general property of the class, e.g. attributes
 And the bottom section holds a list of operations.

Class Diagram…
 Class Interface Notation:
 Is used to describe the externally visible behaviour of a class.
 For example, an operation with public visibility.
 The UML notation for an interface is a small circle with the name of the
interface connected to the class.
 A class that requires the operations in the interface may be attached to the
circle by a dashed arrow.
 The dependant class is not required to actually use all of the operation. For
example, a person object may interact with bankAccount object to get the
balance.

Class Diagram
 Association(binary):
 Is drown as a solid pat connecting two class or both ends may be
connected to same class. It may have association name.
 The association may have an optional blank triangle in it, the point of
the triangle indicating the direction in which to read the name.

Class Diagram
 Qualifier:
 It is an association attribute. For example, a person object may be associated to bank
object. An attribute of this association is the account#. The account number is qualifier
of this association.
 Multiplicity:
 It specifies the range of allowable associated classes.
 It is given roles within associations, parts within compositions, repetitions, and other purposes.
 There are two bounds, lower and upper bounds.
 Both are integer values, specifying the range of integer including the upper and lower bounds.

Class Diagram
 The star character (*) may be used for upper bound,
denoting un limited upper bound. E.g
 0…1
 0..*
 1..3, 7..10, 19..*
 Association class:
 It is an association that also has class properties. It is sown
as class symbol attached by a dashed line to an
association path. The name of the association can be
shown on the path or the class symbol.

Association class…
 e.g.
 Aggregation and composition (a part of):
 Aggregation is a form of association.
 A hollow diamond is attached to the end of the path to indicate the
aggregation. The diamond hollow may not be attached to both ends of line.

Aggregation and composition….
 Composition also known as a the a-part-of , is a form of
aggregation with strong ownership to represent the component of a
complex object.
 It is also referred as a part-whole relationship. The UML notation for
composition is a solid diamond at the end of the path.


Class Diagram
 Generalization:
 Is the relationship btn more general class and more specific class.
 Generalization is displayed as a directed line with a closed, hollow
arrowhead at the superclass end. Generalization natation

Con…
Person
+FullName:String
+ID:Sting
+Age:int
+gender:char
+Register():void
+update():void
Student
-StudID:String
-Year:string
-status:String
+write():String
+read():String
Account
-Username:String
-Password:String
+create():void
+update():void
+inactive():void
+deactive():void
Instructor
-InstID:String
-Rank:strng
-Salary:String
+Write():void
+read():void
Address
+Country:String
+nationality:string
+city:Striing
+street:String
+write():void
+read():void
+update():void
Admin
-AdminID:String
-Position :string
-Proffesion:String
+Register():string
+read():string
have
create
1
1…*
1 11..*1..*

Object Diagram
 A static object diagram is an instance of a class
diagram. It shows a snapshot of the detailed state of
the system at a point in time. Notation is similar as
class notation.
 Class diagram contain objects and no classes in
object diagram
 Object diagrams are derived from class diagrams so
object diagrams are dependent upon class diagrams.

Cont…
 Object diagrams represent an instance of a class
diagram. The basic concepts are similar for class
diagrams and object diagrams. Object diagrams also
represent the static view of a system but this static
view is a snapshot of the system at a particular
moment.
 Object diagrams are used to render a set of objects
and their relationships as an instance.

Purpose…
 The purposes of object diagrams are similar to class
diagrams.
 The difference is that a class diagram represents an
abstract model consisting of classes and their
relationships. However, an object diagram represents
an instance at a particular moment, which is concrete
in nature.

Cont…
 It means, object diagram is closer to the actual system
behaviour. The purpose is to capture the static view of a
system at a particular moment.
 The purpose of the object diagram can be summarized as:
 Forward and reverse engineering.
 Object relationships of a system
 Static view of an interaction.
 Understand object behaviour and their relationship from practical
perspective

Interaction Diagram
 Are diagrams that describe how group objects collaborate to
get the job done.
 It capture the behaviour of a single use case, showing the
pattern of interaction among objects.
 It also shows messages between objects.
 Two type of:
 Sequence diagram
 Collaboration diagram

Sequence Diagram
 Are an easy and intuitive way of describing the behaviour of a system by
viewing the interaction between the system and the environment.
 It shows an interaction arranged in time sequence.
 It shows the objects in the interaction by their life-line and messages they
exchange, arranged in a time sequence.
 It has two dimension
 Vertical dimension, represent time and,
 Horizontal dimension, represents different objects.
 The vertical lifeline represents the object’s existence during the interaction

Sequence diagram…for login
 An object is shown as box at the top of dashed vertical line. The sequence diagram doesn’t show
the relationship the association among objects.

Sample example for create account
 Here is the link

Collaboration Diagram
 Is another type of integration diagram
 It represent collaboration, which is set of objects related in a
particular context, and interaction, which messages
exchanged among the object within the collaboration to
achieve a desired outcome.
 In collaboration diagram, objects are shown as figures.
 In collaboration, the sequence is indicated by numbering the
message.

State chart Diagram
 It shows sequence of states that an object goes through
during its life in response to outside stimuli and messages.
 The state is set of values that describes an object at a specific
point in time and is represented by state symbols and
transitions are represented by arrows connecting the state
symbol
 Its purpose is to understand the algorithm involving in method.
 A state is represented as a rounded box, which may contain
one or more compartments.

State chart..
 E.g2.
A UML state chart diagram for SetTime use case of the SimpleWatch

…Statechart Diagram
 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.
 Before drawing a Statechart diagram we should clarify the following
points:
 Identify the important objects to be analysed.
 Identify the states.
 Identify the events.

Activity Diagram
 It is a variation or special case of a state machine, in which the states
are activities representing the performance of operations and the
transitions are triggered by the completion of the operations.
 Unlike state diagram that focus on the events occurring to a single
object as it responds to messages, an activity diagram can be used to
model the entire business process.
 The purpose of activity diagram is a view of flows and what is going
on in side a use case or among several classes.
 An activity is represented as round box, containing the name
of the operation. It also indicates the execution of operation.

Activity Diagram for Manage Account
clickManegeAccoLinck
inActiveAccount
acountPageDisplay
[Create]
createFormDisplayed
FillValue
[InvalidData]
CreatedAcount
AKN
[inActive]
[End]
[End]
deleteAccount
[Delete]
[Yes]
[No]
Addministrator
[validDta]

…Activity Diagram
 Activity diagram can be used for :
 Modelling work flow by using activities.
 Modelling business requirements.
 High level understanding of the system's functionalities.
 Investigating business requirements at a later stage.

Component Diagram
 Component diagrams model the physical components
such as source code, executable program, user
interface in design.
 Another way of looking at components is the concept
of packages. A package is used to show how you can
group together classes, which in essence are smaller
scale components.
 A component diagram is a graph of the design’s
components connected by dependency relationship.

…Component Diagram
 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.

Deployment Diagram
 It shows the configuration of run-time processing elements and the software
components, process and objects that live in them.
 Software component instances represent run-time manifestations of code units.
Component diagram are used in conjunction with deployment diagrams to show
physical modules of code are distributed on various hardware platforms.
 A deployment diagram is a graph of nodes connected by communication
association.
 Nodes may contain component instances, which means that the component lives
or runs at that node. Components are connected to other components by dashed-
arrow dependencies, usually through interfaces which indicate one component
uses the services of another.

Reference
 https://www.tutorialspoint.com/uml/index.htm
 https://tallyfy.com/uml-diagram/#class-diagram

Ch 2.1

More Related Content

What's hot (20)

Similar to Ch 2.1 (20)

Recently uploaded (20)

Ch 2.1