Software Engineering – Level II

Object Oriented Modeling using UML

Content of module II

I. UML overview ....................................................................................................................................... 1

1.1. Goals of UML ................................................................................................................................. 2
1.1. Role of UML in OO Design ............................................................................................................. 3
1.2. A Conceptual Model of UML.......................................................................................................... 3
1.3. UML Modeling Types ..................................................................................................................... 4
1.4. UML Diagrams Overview ............................................................................................................... 5
II. Structure Diagrams.............................................................................................................................. 5
2.1. Class Diagram ................................................................................................................................ 5
2.1.1. Association class ........................................................................................................................... 6
2.1.2. Aggregation and composition ........................................................................................................ 7
2.1.3. Qualifiers ..................................................................................................................................... 8
2.1.4. Reflexive association ..................................................................................................................... 8
2.1.5. Component Diagram ..................................................................................................................... 8
2.1.6. Package Diagram ......................................................................................................................... 9
2.1.7. Deployment Diagram .................................................................................................................. 10
III. Behavior diagram ............................................................................................................................. 12
3.4.1. Sequence diagram ................................................................................................................... 18
3.4.2. The Collaboration Diagram ..................................................................................................... 18
Tutorial set I ............................................................................................................................................. 19
Tutorial set II ............................................................................................................................................ 24

I. UML overview

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
 Software Engineering – Level II

Unified Modeling Language (UML) is a standard language for specifying, visualizing,

constructing, and documenting the artifacts of software systems. UML was created by the Object
Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January
1997.

Although UML is generally used to model software systems, it is not limited within this boundary.
It is also used to model non-software systems as well. For example, the process flow in a
manufacturing unit, etc.

Like any other language, UML has its own syntax (symbols and sentence formation rules) and
semantics (meanings of symbols and sentences)

However UML is not a programming language but tools can be used to generate code in
various languages using UML diagrams. UML has a direct relation with object oriented analysis
and design. After some standardization, UML has become an OMG standard.

1.1. Goals of UML

A picture is worth a thousand words, this idiom absolutely fits describing UML. Object
oriented concepts were introduced much earlier than UML. At that point of time, there were
no standard methodologies to organize and consolidate the object-oriented development. It
was then that UML came into picture.

There are a number of goals for developing UML but the most important is to define some general
purpose modeling language, which all modelers can use and it also needs to be made simple to
understand and use.

UML diagrams are not only made for developers but also for business users, common
people, and anybody interested to understand the system. The system can be a software or
nonsoftware system. Thus it must be clear that UML is not a development method rather it
accompanies with processes to make it a successful system. In conclusion, the goal of UML can

IUGET-DOUALA/2020-2021/Level200/OOM-UML 2
 Software Engineering – Level II

be defined as a simple modeling mechanism to model all possible practical systems in today’s
complex environment.

1.1. Role of UML in OO Design

UML is a modeling language used to model software and non-software systems. Although UML
is used for non-software systems, the emphasis is on modeling OO software applications.
Most of the UML diagrams discussed so far are used to model different aspects such as
static, dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects If we look
into class diagram, object diagram, collaboration diagram, interaction diagrams all would basically
be designed based on the objects.

Hence, the relation between OO design and UML is very important to understand. The OO design
is transformed into UML diagrams according to the requirement. Before understanding the
UML in detail, the OO concept should be learned properly. Once the OO analysis and design is
done, the next step is very easy. The input from OO analysis and design is the input to UML
diagrams.

1.2. A Conceptual Model of UML

To understand the conceptual model of UML, first we need to clarify what is a model? what is a
conceptual model? and why a conceptual model is required?

• Model
A model captures aspects important for some application while omitting (or abstracting) the rest.
A model in the context of software development can be graphical, textual, mathematical, or
program code-based. Models are very useful in documenting the design and analysis results.
Models also facilitate the analysis and design procedures themselves. Graphical models are very
popular because they are easy to understand and construct. UML is primarily a graphical
modeling tool. However, it often requires text explanations to accompany the graphical models.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 3
 Software Engineering – Level II

• Conceptual Model
A conceptual model can be defined as a model which is made of concepts and their relationships.
It is the first step before drawing a UML diagram. Conceptual model helps to understand the
entities in the real world and how they interact with each other.

• Importance of Conceptual Model

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

1.3. UML Modeling Types

UML diagrams represent two different views of a system model: Static (or structural) view and
Dynamic (or behavioral) view

• Static (or structural) view: This view emphasizes the static structure of the system using
objects, attributes, operations, and relationships. Ex: Class diagram, Composite Structure
diagram.
• Dynamic (or behavioral) view: 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.

Architectural model represents the overall framework of the system. It contains both structural
and behavioral elements of the system. Architectural model can be defined as the blueprint of the
entire system. Package diagram comes under architectural modeling.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 4
 Software Engineering – Level II

1.4. UML Diagrams Overview

UML 2.2 has 14 types of diagrams divided into multiple categories as shown in the figure below.

II. Structure Diagrams

These diagrams emphasize the things that must be present in the system being modeled. Since
they represent the structure, they are used extensively in documenting the software architecture of
software systems.

2.1. Class Diagram

Describes the structure of a system by showing the system’s classes, their attributes, and the
relationships among the classes.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 5
 Software Engineering – Level II

(occurrence name)

Figure 1: Class diagram example

2.1.1. Association class

An association can have attributes of its own, in which case it is both an association and classe –
an association class. E.g.

* *

Figure 2: Association class

IUGET-DOUALA/2020-2021/Level200/OOM-UML 6
 Software Engineering – Level II

2.1.2. Aggregation and composition

Figure 3: Aggregation and composition

• Aggregation
Aggregation is a special type of association where the involved classes represent a whole-part
relationship. The aggregate takes the responsibility of forwarding messages to the appropriate
parts. Thus, the aggregate takes the responsibility of delegation and leadership. When an instance
of one object contains instances of some other objects, then aggregation (or composition)
relationship exists between the composite object and the component object. Aggregation is
represented by the diamond

• Composition
Composition is a stricter form of aggregation in which the parts are existence-dependent on the
whole. This means that the life of the parts closely ties to the life of the whole. When the whole is
created, the parts are created and when the whole is destroyed, the part s are destroyed. A
typical example of composition is an invoice object with invoice items. As soon as the invoice

IUGET-DOUALA/2020-2021/Level200/OOM-UML 7
 Software Engineering – Level II

object is created, all the invoice items in it are created and as soon as the invoice object is
destroyed, all invoice items in it are also destroyed. The composition relationship is represented
as a filled diamond drawn at the composite-end.

2.1.3. Qualifiers
If an association attribute is unique within a set of related objects, then it is a qualifier. A qualifier
is a value that selects a unique object from the set of related objects across an association.

Sometimes, it transforms undetermined or infinite multiplicity into finite one

Undetermined multiplicity

Representation using index

As qualifier

Figure 4: Qualifier

2.1.4. Reflexive association

Example:

Friend of

* child

Figure 5: Reflexive association

2.1.5. Component Diagram

A component is a part of software program code, which executes an independent task in the
system. It can be a small module or sub-system itself.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 8
 Software Engineering – Level II

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.
Component diagrams are used to visualize the organization and relationships among components
in a system. It describes how a software system is split-up into components and shows the
dependencies among these components. The following diagram is an example of component
diagram.

Order
Entry

« delegate »

Figure 6: Example of component diagram

2.1.6. Package Diagram

This diagram describes how a system is split-up into logical groupings by showing the
dependencies among these groupings.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 9
 Software Engineering – Level II

Figure 7: Package diagram

2.1.7. Deployment Diagram

It describes the hardware used in system implementations and the execution environments and
artifacts deployed on the hardware.

A deployment diagram consists of nodes. Nodes are nothing but physical hardware used to deploy
the application.

Deployment diagrams are useful for system engineers. An efficient deployment diagram is very
important as it controls the following parameters:
• Performance
• Scalability
• Maintainability
• Portability

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
0
 Software Engineering – Level II

Dependency is a relationship
between two entities in
which change in one
element also

Figure 8: Deployment example 1

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
1
 Software Engineering – Level II

Figure 9: Deployment diagram of order management system

III. Behavior diagram

These diagrams emphasize what must happen in the system being modeled. Since they illustrate
the behavior of a system, they are used extensively to describe the functionality of software
systems.

3.1. Activity Diagram

Describes the business and operational step-by-step workflows of components in a system. An
activity diagram shows the overall flow of control. The following diagram is an example of
Activity diagram.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
2
 Software Engineering – Level II

Figure 10: ATM activity diagram

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
3
 Software Engineering – Level II

3.2. State Machine Diagram

Describes the states and state transitions of the system.

Figure 11: Example of state machine diagram

3.3. Use Case 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.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
4
 Software Engineering – Level II

Following (figure 12) is a sample use case diagram representing the order management system.
Hence, if we look into the diagram then we will find three use cases ( Order, SpecialOrder,
and NormalOrder) and one actor which is the customer.
The SpecialOrder and NormalOrder use cases are extended from Order use case. Hence, they
have extended relationship. Another important point is to identify the system boundary, which
is shown in the picture. The actor Customer lies outside the system as it is an external user of the
system.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
5
 Software Engineering – Level II

Figure 12: Use case example 2

Extend Vs include
• Includes
The includes relationship in the older versions of UML (prior to UML 1.1) was known as the uses
relationship. The includes relationship involves one use case including the behavior of
another use case in its sequence of events and actions. The includes relationship occurs
when a chunk of behavior that is similar across a number of use cases. The factoring of
such behavior will help in not repeating the specification and implementation across different
use cases. Thus, the includes relationship explores the issue of reuse by factoring out the
commonality across use cases. It can also be gainfully employed to decompose a large and complex
use cases into more manageable parts. Includes relationship is represented using a predefined
stereotype <<include>>.

• Extends
The main idea behind the extends relationship among the use cases is that it allows you to show
optional system behavior. An optional system behavior is extended only under certain conditions.
This relationship among use cases is also predefined as a stereotype “extends”. The extends

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
6
 Software Engineering – Level II

relationship is similar to generalization. But unlike generalization, the extending use case can add
additional behavior only at an extension point only when certain conditions are satisfied. The
extension points are points within the use case where variation to the mainline (normal) action
sequence may occur. The extends relationship is normally used to capture alternate paths or
scenarios.

Figure 13: Extends & include

Generally, if the behavior of a use case B can be extended by that of A, then A extends B.

3.4. Interaction Diagrams

From the term Interaction, it is clear that the diagram is used to describe some type of interactions
among the different elements in the model. This interaction is a part of dynamic behavior
of the system.

Interactive behavior is represented in UML by two diagrams known as Sequence diagram

and Collaboration diagram. The basic purpose of both the diagrams are similar. Sequence
diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the
structural organization of the objects that send and receive messages.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
7
 Software Engineering – Level II

3.4.1. Sequence diagram

It shows how objects communicate with each other in terms of a sequence of messages. Also
indicates the lifespans of objects relative to those messages.

Figure 14: Example of sequence diagram

3.4.2. The Collaboration Diagram

It shows the object organization as seen in the following diagram. In the collaboration diagram,
the method call sequence is indicated by some numbering technique. The number indicates how
the methods are called one after another. We have taken the same order management system to
describe the collaboration diagram.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
8
 Software Engineering – Level II

Method calls are similar to that of a sequence diagram. However, difference being the
sequence diagram does not describe the object organization, whereas the collaboration
diagram shows the object organization.

Figure 15: Collaboration diagram of order Management system

Tutorial set I

Exercise: 1
You are required to develop an automated Student Registration System (SRS). This system will
enable students to register online for courses each semester.
1. Provide the specification requirement of SRS
2. Describe all use cases. First of all list high-level use cases, before decomposing each.
3. Model the static or data aspect of the system (Class diagram)
4. Define the sequence diagrams for some specific Add users, Login, Edit profil information

Exercise: 2
The purpose of this exercise is to prepare requirements specification for a software system, then
use those requirement to design the system. You are expected to take into account your own
knowledge of the problem domain in completing this work.

IUGET-DOUALA/2020-2021/Level200/OOM-UML 1
9
 Software Engineering – Level II

System description
An n-elevator system is to be installed in a building with m floors. The elevators and the control
mechanism are supplied by the manufacturer. The internal mechanisms of these are assumed
(given).
 The problem concerns the logic to move elevators between floors according to the following
constraints:
• Each elevator has a set of buttons, one for each floor. These illuminate when pressed and
cause the elevator to visit the corresponding floor. The illumination is cancelled when the
corresponding floor is visited by the elevator.
• Each floor has two buttons (except the top and bottom floors), one to request upward travel
and one to request downward travel. These buttons illuminate when pressed. The
illumination is cancelled when an elevator visits the floor and is either moving in the desired
direction or has no outstanding requests.
• When an elevator has no requests to service, it should remain at its final destination with its
doors closed and await further requests. (An alternative would be to specify a floor to which
the elevator should return under these conditions.)
• All requests for elevators from floors must be serviced eventually, with all floors being given
equal priority.
• All requests for floors within an elevator must be serviced eventually, with floors being
serviced sequentially in the direction of travel.
• Each elevator has an emergency button that, when pressed, causes a warning signal to be
sent to the site manager. The elevator is then deemed "out of service." Each elevator has a
mechanism to cancel its "out of service" status.

Instructions
1. Focus primarily on requirements related to controlling the movement of each elevator in
response to passenger inputs and related factors (If you wish, you may include tables or
diagrams).
2. Divide all possible scenarios through use cases
3. Model the dynamic aspect of the system (State diagram) Exercise: 3
A POS (Point-Of-Sale) system is a computer system typically used to manage the sales in retail
stores. It includes hardware components such as a computer, a bar code scanner, a printer and also
software to manage the operation of the store. The most basic function of a POS system is to handle
sales. When a customer arrives at a POS counter with goods to purchase, the cashier will start a
new sale transaction. When the barcode of a good is read by the POS system, it will retrieve the
name and price of this good from the backend catalog system and interact with inventory system
to deduce the stock amount of this good. When the sale transaction is over, the customer can pay
in cash, credit card or even check. After the payment is successful, a receipt will be printed. Note
that for promotion, the store frequently issue gift coupons. The customer can use the coupons for

IUGET-DOUALA/2020-2021/Level200/OOM-UML 2
0
 Software Engineering – Level II

a better price when purchasing goods. Another function of a POS system is to handle returns… A
user must log in to use the POS. The users of a POS system are the employees of the store including
cashiers and the administrator. The administrator can access the system management functions of
the POS system including user management and security configuration that cashiers can’t do.
The context diagram of the system given below:

1. Describe the interfaces of the application (to other systems/devices) using the following
template:

Physical Procedural Data

Credit card system Internet connection URL with web and Format of credit
SSL card data sent, error
descriptions
…. … …. ..

2. Define the user requirements, notably using a table with functional and non-functional
requirements. (Use the template given below)

IUGET-DOUALA/2020-2021/Level200/OOM-UML 2
1
 Software Engineering – Level II

3. Define the user requirements. As an alternative to the technique above described each
requirement with the following form

4. Define scenarios of use with the following template

IUGET-DOUALA/2020-2021/Level200/OOM-UML 2
2
 Software Engineering – Level II

5. Define the use case Diagrams. Given the description of each use case in a table similar to the
following template:

6. Define the sequence diagrams for some specific scenarios

7. Identify the system classes and their relationship.
8. Provide the state chart of POS system

IUGET-DOUALA/2020-2021/Level200/OOM-UML 2
3
 Software Engineering – Level II

Tutorial set II

Exercise: 1
A bank system contains data on customers (identified by name and address) and their accounts.
Each account has a balance and there are 2 type of accounts: one for savings which offers an interest rate,
the other for investments, used to buy stocks. Stocks are bought at a certain quantity for a certain price
(ticker) and the bank applies commission on stock orders. Draw class diagram for that system.

Exercise: 2
You’re creating a digital doll program. What happens to the doll when he receives different stimuli is
determined by the state he’s in, so you decide to model the digital doll with a state diagram.
The behavior of the digital doll program is as follows:
 When the doll is turned on, it starts out happy (happy doll state)
 If the doll is happy and receives punishment, then he becomes sad
 If the doll is sad and receives praise, it becomes happy
 If the doll is sad and receives punishment, it is heart-broken
 When it is turned off, it shuts down

IUGET-DOUALA/2020-2021/Level200/OOM-UML 2
4