Hawassa University Bensa Daye

Campus
DEPARTMENT OF COMPUTER
SCIENCE

Software Engineering (Course Code InSy3033)

Chapter Two
Unified Modeling Language
(UML)
1
 Topics Covered

Where Can the UML Be Used

Building Blocks of the UML.

Relationships in the UML

Diagrams in the UML.

Use Case Diagrams

Class Diagrams

Sequence diagrams

State chart diagrams

Activity diagrams

Component diagram

Deployment diagram

2
 Chapter Two

2. Unified Modelling Language(UML)

2.1. Where Can the UML Be Used
 UML, as the name implies, is a modelling language. It may be used to visualize,
specify, construct, and document the artifacts of a software system.
 It provides a set of notations (e.g. rectangles, lines, ellipses, etc.) to create a visual
model of the system.
 Like any other language, UML has its own syntax (symbols and sentence formation
rules) and semantics (meanings of symbols and sentences).

3
 ….cont’d

 Also, we should clearly understand that UML is not a system design or

development methodology, but can be used to document object-oriented

and analysis results obtained using some methodology.

 UML can be used to construct nine different types of diagrams to capture

five different views of a system.

 UML diagrams provide different perspectives of the software system to

be developed and facilitate a comprehensive understanding of the system.

4
….cont’d
The UML diagrams can capture the following five views of a system:
 User’s view
 Structural view
 Behavioural view
 Implementation view
 Environmental view

Figure 2.1 UML diagrams views of a system

5
 2.2 UML-Building Blocks

 UML is composed of three main building blocks, i.e., things, relationships, and
diagrams.
 Building blocks generate one complete UML model diagram by rotating around
several different blocks.
 It plays an essential role in developing UML diagrams.

The basic UML building blocks are enlisted below:

1. Things
2. Relationships
3. Diagrams

6
 2.3 Relationships in the UML

 Relationships depict a connection between several things, such as structural,

behavioural, or grouping things in the unified modelling language.

 Since it is termed as a link, it demonstrates how things are interrelated to each other at

the time of system execution.

 It constitutes four types of relationships, i.e., dependency, association, generalization,

and realization.

7
….cont’d

1. Dependency
 Whenever there is a change in either the structure or the behaviour of the class that affects the other class,

such a relationship is termed as a dependency.

 Or, simply, we can say a class contained in other class is known as dependency.

2. Association
 Association is a structural relationship that represents how two entities are linked or connected to each other

within a system.
 It can form several types of associations, such as one-to-one, one-to-many, many-to-one, and many-to-

many. 8
 2.1 Aggregation

 An aggregation is a special form of association. It portrays a part-of relationship.

 It forms a binary relationship, which means it cannot include more than two

classes. It is also known as Has-a relationship.

 It specifies the direction of an object contained in another object. In aggregation, a

child can exist independent of the parent.

2.2 Composition
 In a composition relationship, the child depends on the parent. It forms a two-way

relationship. It is a special case of aggregation. It is known as Part-of relationship.

9
 3 Generalization

 The generalization relationship implements the object-oriented concept called

inheritance or is-a relationship.

 It exists between two objects (things or entities), such that one entity is a parent

(superclass or base class), and the other one is a child (subclass or derived class).
 These are represented in terms of inheritance. Any child can access, update, or

inherit the functionality, structure, and behaviour of the parent.

10
….cont’d
4. Realization
 It is a kind of relationship in which one thing specifies the behaviour

or a responsibility to be carried out, and the other thing carries out that

behaviour.
 It can be represented on a class diagram or component diagrams.
 The realization relationship is constituted between interfaces, classes,

packages, and components to link a client element to the supplier

element.
11
 2.4. Diagrams in the UML.

2.4.1. Use Case Diagrams

 The use case model for any system consists of a set of use case.
 The purpose of a use case is to define a piece of coherent behaviour without
revealing the internal structure of the system.
 A use case typically involves a sequence of interactions between the user and the
system.
 Even for the same use case, there can be several different sequences of
interactions.

12
….cont’d

 Use case:- A set of scenarios that describe an interaction between a user and a
system, including alternatives and is drawn as a horizontal ellipse.
 A use case consists of one main line sequence and several alternate sequences.
 The main line sequence represents the interactions between a user and the
system that normally take place.
 The mainline sequence is the most frequently occurring sequence of
interaction.
 In contrast to all other types of UML diagrams, the use case model represents a
functional or process model of a system.
13
Use case diagram for library information system

3/2/2018

Figure 2.2 Use case diagram 14

Usecase Diagram(Elements of a Use Case Diagram)

15
 Elements of a Use Case Diagram(what is Actor?)

 Actor:- any entity that interacts with the system (e.g., a user,
another system, the system’s physical environment). Actors
are drawn as stick figures.
 Actor is a person or another system that interacts with and
derives value from the system.
 An actor is not a specific user, but a role that a user can play
while interacting with the system.
 Actors are external to the system and initiate a use case.
 An actor is a role played by a user with respect to the system
use.
 An actor can participate in one or more use cases. 16
 ….cont’d

 Sometimes an actor plays a specialized role of a more general

type of actor.
 For example, there may be times when a new customer
interacts with the system in a way that is somewhat different
from a returning customer.
 In this case, a specialized actor (i.e., new customer) can be
placed on the model, shown by a line with a hollow triangle at
the end of the more general superclass of actor (i.e., customer).
 The specialized actor will inherit the behavior of the superclass
and extend it in some way.
17
 ….cont’d

 use case is a major process that the system will perform that benefits
an actor(s) in some way.
 In figure, the system has three primary use cases: make offer,
accept/reject offer and record sales contract.
 Associations:- Associations between actors and use cases are
indicated in use case diagrams by solid lines.
 System boundary:- rectangle diagram representing the boundary
between the actors and the system.
 You can draw a rectangle around the use cases, called the system
boundary box, to indicate the scope of your system.
 Anything within the box represents functionality that is in scope and
anything outside the box is not. 18
 ….cont’d
 There are times when one use case will either use the functionality or extend the
functionality of another use case on the diagram, and these are shown by <<includes>> or
<<extends>> relationships.
 The includes relationship implies one use case includes the behaviour of another use case
in its sequence of events and actions.
 Decompose a large and complex use case into more manageable parts.
 The includes relationship is represented using a predefined stereotype <<include>>.
 In the includes relationship, a base use case includes the behaviour of the common use
case.

19
 ….cont’d

 The main idea behind the extends relationship among use cases is that it
allows you show optional system behaviour.
 An optional system behaviour is executed only if certain conditions hold.
 The extending use case can add additional behaviour only at an extension
point only when certain conditions are satisfied.
<<extends>>

Base use Common use

case case

20
 Why Develop the Use Case Diagram?

 One possible use of identifying the different types of users (actors) is in

implementing a security mechanism through a login system.
 Another important use is in designing the user interface in the
implementation of the use case for each category of users.
 Another possible use is in preparing the documentation (e.g. users’ manual)
targeted at each category of user.
 Further, actors help in identifying the use cases and understanding the exact
functioning of the system.

21
 Text Description

 Each ellipse in a use case diagram, by itself conveys very little information, other
than giving a hazy idea about the use case.
 Therefore, every use case diagram should be accompanied by a text description.
 The following are some of the information which may be included in a use case
text description in addition to the mainline sequence, and the alternate scenarios.

Actors
 Pre-condition: The preconditions would describe the state of the system before
the use case execution starts.

22
 ….cont’d

 Post-condition: This captures the state of the system after the use case has
successfully completed.
 Non-functional requirements : This could contain the important constraints
for the design and implementation, such as platform and environment
conditions, qualitative statements, response time requirements, etc.
 Exceptions, error situations: This contains only the domain-related errors
such as lack of user’s access rights, invalid entry in the input fields, etc.

23
 ….cont’d
Name Login

Actors Admin, librarian and user.

Description Each of the above actors has their own privileges to access the database.

Pre condition They must first be create account(register) on data base.

Basic flow of event 1. the above actors can press login link according to their level of privilege.
2. then the user should fill the necessary information on the form and press login.
3. the system checks whether the user is found with that login detail on database or not.
4. the system prompts message(success or error) for the user.

Alternative flow of 3.1 if user information not found in database recommend user to register.
events
3.2 if the information is present navigate to next page.
4.1 if the message is error enter detail correctly again.
3/2/2018

Post condition Access the page what he/she wants. 24

 2.4.2 CLASS DIAGRAMS

 A class diagram describes the static structure of a system. It shows how a

system is structured rather than how it behaves.
 The static structure of a system comprises a number of class diagrams and
their dependencies.
 The main constituents of a class diagram are classes and their relationships
—generalisation, aggregation, association, and various kinds of
dependencies.

25
 Classes

 The classes represent entities with common features, i.e., attributes and
operations.
 Classes are represented as solid outline rectangles with compartments. Classes
have a mandatory name compartment where the name is written centered in
boldface.
 The class name is usually written using mixed case convention and begins with
an uppercase (e.g. LibraryMember).
 Object names on the other hand, are written using a mixed case convention, but
starts with a small case letter (e.g., studentMember).
 Class names are usually chosen to be singular nouns. 26
 ….cont’d

♥ Classes have optional attributes and operations compartments. Its attributes

and operations are suppressed on all but one diagram.

3/2/2018

27
 Attributes
 An attribute is a named property of a class. It represents the kind of data that an object might
contain.
 Attributes are listed with their names, and may optionally contain specification of their type (that
is, their class, e.g., Int, Book, Employee, etc.), an initial value, and constraints.
 Attribute names are written left-justified using plain type letters, and the names should begin with a
lower case letter.
 Attribute names may be followed by square brackets containing a multiplicity expression, e.g.
sensorStatus[10].
 The multiplicity expression indicates the number of attributes per instance of the class. An
attribute without square brackets must hold exactly one value.
 The type of an attribute is written by following the attribute name with a colon and the type name,
28
 Operation

 The operation names are typically left justified, in plain type, and always begin with
a lower case letter.
 The parameters of a function may have a kind specified. The kind may be “in”
indicating that the parameter is passed into the operation; or “out” indicating that the
parameter is only returned from the operation; or “inout” indicating that the
parameter is used for passing data into the operation and getting result from the
operation.
 The default is “in”. An operation may have a return type consisting of a single return
type expression, e.g., issueBook(in bookName):Boolean.
29
 Association

 Association between two classes is represented by drawing a straight line between the
concerned classes.
 The name of the association is written along side the association line.
 An arrowhead may be placed on the association line to indicate the reading direction of
the association.
 On each side of the association relation, the multiplicity is noted as an individual number
or as a value range.
 The multiplicity indicates how many instances of one class are associated with the other.
 Value ranges of multiplicity are noted by specifying the minimum and maximum value,
separated by two dots, e.g. 1..5. 30
 ….cont’d

 An asterisk is used as a wild card and means many (zero or more). The
association of the Figure should be read as “Many books may be borrowed
by a LibraryMember”.
 Usually, associations (and links) appear as verbs in the problem statement.

31
 2.4.3 Sequence diagram
 A sequence diagram shows interaction among objects as a two dimensional chart.
 The chart is read from top to bottom. The objects participating in the interaction are
shown at the top of the chart as boxes attached to a vertical dashed line.
 Inside the box the name of the object is written with a colon separating it from the
name of the class and both the name of the object and the class are underlined.
 This signifies that we are referring any arbitrary instance of the class.
 For example, in Figure : ATM machine during withdrawing money.

32
 ….cont’d
The sequence diagram for ATM machine during withdrawing money looks look the
following.

Figure 2.3 sequence diagram for ATM machine withdrawing money 33

 ….cont’d

 The vertical dashed line is called the object’s lifeline. Any point on the lifeline
implies that the object exists at that point.
 Absence of lifeline after some point indicates that the object ceases to exist after
that point in time, particular point of time.
 Normally, at the point if an object is destroyed, the lifeline of the object is
crossed at that point and the lifeline for the object is not drawn beyond that
point.

34
 ….cont’d

 A rectangle called the activation symbol is drawn on the lifeline of an object to

indicate the points of time at which the object is active.
 Thus an activation symbol indicates that an object is active as long as the symbol
(rectangle) exists on the lifeline.
 Each message is indicated as an arrow between the lifelines of two objects.
 The messages are shown in chronological order from the top to the bottom.
 That is, reading the diagram from the top to the bottom would show the sequence
in which the messages occur.
35
 2.4.4 STATE CHART DIAGRAM

 A state chart diagram is normally used to model how the state of an object
changes in its lifetime.
 State chart diagrams are good at describing how the behaviour of an object
changes across several use case executions.
 A state chart is a hierarchical model of a system and introduces the concept of a
composite state (also called nested state).
 Actions are associated with transitions and are considered to be processes that
occur quickly and are not interruptible.

36
 ….cont’d

 Activities are associated with states and can take longer. An activity can be
interrupted by an event.
The basic elements of the state chart diagram are as follows:
 Initial state- This is represented as a filled circle.
 Final state- This is represented by a filled circle inside a larger circle.
 State- These are represented by rectangles with rounded corners.
 Transition- A transition is shown as an arrow between two states.

37
 ….cont’d
 State chart 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 State chart 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.

38
….cont’d

Figure 2.4 State chart diagram of an order management system. 39

 2.4.5 ACTIVITY DIAGRAM

 The activity diagram focuses on representing various activities or chunks of

processing and their sequence of activation.
 The activities in general may not correspond to the methods of classes.
 UML activity diagrams are the object-oriented equivalent of flow charts and data-
flow diagrams from structured development
 Activity diagram describes a system in terms of activities.
 Activities are states that represent the execution of a set of operations.
 Activity diagrams are state chart diagrams whose states are action states.

40
 ….cont’d

Pre-condition------------->
Actor --------------------------------->
System step------------------->

Alternative flow---------------------> <---------------- Basic flow

Post condition---------------------->

Figure 2.5 Activity diagram 41

 2.4.6 Component diagram

 A component represents a piece of software that can be independently purchased,

upgraded, and integrated into an existing software.
 A component diagram can be used to represent the physical structure of an
implementation in terms of the various components of the system.
 Component diagrams are used to visualize the organization and relationships
among components in a system.

A component diagram is typically used to achieve the following purposes:

 Organise source code to be able to construct executable releases.
 Specify dependencies among different components.
42
 2.4.7 Deployment diagram

 Deployment diagrams are used to visualize the topology of the physical

components of a system where the software components are deployed.
 That is, it captures the environment in which the software solution is
implemented.
 In other words, a deployment diagram shows how a software system will be
physically deployed in the hardware environment.
 That is, which component will execute on which hardware component and how
they will they communicate with each other.

43
 ….cont’d
 Deployment diagrams are used to describe the static deployment view of a system.
 Deployment diagrams consist of nodes and their relationships.
The purpose of deployment diagrams can be described as:
 Visualize hardware topology of a system.
 Describe the hardware components used to deploy software components.
 Describe runtime processing nodes.

44
 ….cont’d

Example according to the next system we use computer as hardware, web server
(Apache) as software and MySQL connector as connectors.

Figure 2.6 Deployment diagram of Bus Transport Agency 45

THANK YOU!

46