SAMARA UNIVERSITY

College of Engineering &Technology

Department of Computer Science
Regular Program
Object Oriented Software Engineering
Chapter Two
Unified Modeling Language (UML)
 Outline
• An overview of Modeling
• An overview of UML
• Context Model
• Diagrams in the UML
 Use Case
 Class
 Sequence
 State
 Activity
 Component,
 Deployment diagrams
02/09/2021 O-O Software Engineering 2
 An overview of Modeling (1)
• Model is an abstract representation of a system constructed, to understand
the system prior to building or modifying it.
• Models can represent the static or dynamic situation
 Static Model: Can be viewed as a snapshot of a system’s parameter at
rest or at a specific point in time
- It assumes stability and an absence of change in data over time
- Example :UML class diagram
 Dynamic Model: Viewed as a collection of procedures or behaviors
that taken together , reflects the behavior of the system over the time.
- It shows how the business objects interact to perform task.
- Example: UML activity diagram and interaction diagram
02/09/2021 O-O Software Engineering 3
 An overview of Modeling (2)
• A system can be described first by developing its static model ,
which is the structure of its object and their relationship frozen in
time. Then, we can examine changes to the objects and their
relationship over time(the dynamic model).
• Good modeling is essential for communication among project team.
• A modeling language must include:-
- model element: fundamental modeling concepts & semantics
- Notation: visual rendering of modeling elements
- Guidelines: expression of usage within the trade

02/09/2021 O-O Software Engineering 4

 An overview of UML (1)

 UML is a general purpose notation that issued to

 visualize,
 specify,
 construct, and
 document the artifacts of a 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.
 UML is a graphical language with a set of rules and semantics

02/09/2021 O-O Software Engineering 5

 An overview of UML (2)

02/09/2021 O-O Software Engineering 6

 An overview of UML (3)

 UML diagrams are not only made for developers but also for
business users, common people, and anybody interested to
understand the system.
 Why we use UML?
 Use graphical notation: more clearly than natural language
(imprecise) and code (too detailed).
 Simplifies the complex process of software design
 Help acquire an overall view of a system.
 UML is not dependent on any one language or technology.
 UML moves us from fragmentation to standardization.
02/09/2021 O-O Software Engineering 7
 Context Models
• Context models show the relationships of the system to other systems,
and are used to establish the system boundaries.
• Done at an early stage in the specification of a system
• The advantage of relying on other systems that you avoid duplicating
data.
• The major disadvantage, however, is that using other systems may make
it slower to access information.
• For example, say you are developing the specification for the patient
information system for mental healthcare(MHC-PMS); the system may
retrieve Patient Record and previous Prescription from other system

02/09/2021 O-O Software Engineering 8

 The context of the MHC-PMS

02/09/2021 O-O Software Engineering 9

 Diagrams in the UML (1)
• Every complex system is best approached through a small
set of independent views of a model.
• no single view is sufficient.
• Every model may be expressed at different levels of
fidelity.
• The best models are connected to reality.

02/09/2021 O-O Software Engineering 10

Diagrams in the UML (2)
• The UML define the following nine (9) diagrams:
1. Use case diagram (functional model)
2. Class diagram (Static model)
3. Sequence diagram, collaboration diagram, state chart
and activity diagram( behavioral/dynamic models)
4. Component diagram and deployment diagram
( Implementation models)

02/09/2021 O-O Software Engineering 11

Use case diagram
• A use-case diagram is a set of use cases
• Used for describing a set of user scenarios
• Mainly used for capturing user requirements
• Work like a contract between end user and software developers
 Use Case Diagram (core components)
 Actors: A role that a user plays with respect to a system, including
human and other systems. e.g. inanimate physical objects (e.g. robot)
 Use case: A set of scenarios that describing an interaction between a
user and a system, including alternatives.

02/09/2021 O-O Software Engineering 12

 Use Case Diagram (core components) con’t..
• System boundary: rectangle diagram representing the
boundary between the actors and the system.
• Association: communication between an actor and a use case;
Represented by a solid line.
• Generalization: relationship between one general use case and
a special use case (used for defining special alternatives)

02/09/2021 O-O Software Engineering 13

 Use Case Diagram (core components) con’t..
• Include: a dotted line labeled <<include>> beginning at base use case
and ending with an arrows pointing to the include use case. The include
relationship occurs when a chunk of behavior is similar across more
than one use case. Use “include” in stead of copying the description of
that behavior.

• Extend: a dotted line labeled <<extend>> with an arrow toward the

base case. The extending use case may add behavior to the base use
case. The base class declares “extension points”.

02/09/2021 O-O Software Engineering 14

 Developing Use Cases
•  Understand what the system must do – capture the goals
•  Understand how the user must interact to achieve the goals –
capture user interactions
• Identify sequences of user interactions
• Start with goals and refine into interactions
• Show common behaviors with includes
• Describe extensions and exceptions with extends

02/09/2021 O-O Software Engineering 15

 Use Case Diagrams
Boundary Use Case
Actor
Library System

Borrow
Employee
Client

Order Title

Fine Remittance

Supervisor

• A generalized description of how a system will be used.  remittance

• Provides an overview of the intended functionality of the system
02/09/2021 O-O Software Engineering 16
 Use Case Diagrams(cont.)

02/09/2021 O-O Software Engineering 17

 Use Case Diagrams(cont.)
•Pay Bill is a parent use case and Bill Insurance is the child use case.
(generalization)

•Both Make Appointment and Request Medication include Check

Patient Record as a subtask.(include)

•The extension point is written inside the base case

Pay bill; the extending class Defer payment adds the behavior of this
extension point. (extend)

02/09/2021 O-O Software Engineering 18

 Class diagram
• Used for describing structure and behavior in the use
cases
• Provide a conceptual model of the system in terms of
entities and their relationships
• Used for requirement capture, end-user interaction
• Detailed class diagrams are used for developers

02/09/2021 O-O Software Engineering 19

 Class representation
• Each class is represented by a rectangle subdivided into three
compartments
• Name
• Attributes
• 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.

02/09/2021 O-O Software Engineering 20

 An example of Class

Name
Account_Name
- Customer_ Name
Attributes
- Balance
+addFunds( ) Operations
+withDraw( )
+transfer( )

02/09/2021 O-O Software Engineering 21

 OO Relationships
• There are two kinds of Relationships
• Generalization (parent-child relationship)
• Association (student enrolls in course)
• Associations can be further classified as
• Aggregation
• Composition

02/09/2021 O-O Software Engineering 22

 OO Relationships: Generalization
Supertype Example: Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2
or: Customer
- Generalization expresses a
parent/child relationship among related
classes.
- Used for abstracting details in several Regular Loyalty
layers Customer Customer
02/09/2021 O-O Software Engineering 23
 OO Relationships: Association
• Represent relationship between instances of classes
• Student enrolls in a course
• Courses have students
• Courses have exams
• Association has two ends
• Role names (e.g. enrolls)
• Multiplicity (e.g. One course can have many students)
• Navigability (unidirectional, bidirectional)

02/09/2021 O-O Software Engineering 24

Association: Multiplicity and Roles
student
1 *
University Person

0..1 *
employer teacher

Multiplicity Role
Symbol Meaning
1 One and only one Role
0..1 Zero or one
“A given university groups many people;
M..N From M to N (natural language)
* From zero to any positive integer
some act as students, others as teachers.
0..* From zero to any positive integer
A given student belongs to a single
1..* From one to any positive integer
university; a given teacher may or may not
be working for the university at a particular
time.”
02/09/2021 O-O Software Engineering 25
Class diagram

02/09/2021 O-O Software Engineering 26

 Association: Model to Implementation
* 4
Student Course
has enrolls

Class Student {
Course enrolls[4];
}

Class Course {
Student have[];
}
02/09/2021 O-O Software Engineering 27
 OO Relationships: Composition
Composition: expresses a relationship among instances
Whole Class of related classes. It is a specific kind of Whole-Part
Class W relationship.

It expresses a relationship where an instance of the

Whole-class has the responsibility to create and initialize
instances of each Part-class.

Class P1 Class P2 It may also be used to express a relationship where instances

of the Part-classes have privileged access or visibility to
certain attributes and/or behaviors defined by the
Part Classes Whole-class.

Composition should also be used to express relationship where

Example instances of the Whole-class have exclusive access to and
control of instances of the Part-classes.
Automobile
Composition should be used to express a relationship where
the behavior of Part instances is undefined without being
related to an instance of the Whole. And, conversely, the
behavior of the Whole is ill-defined or incomplete if one or
more of the Part instances are undefined.
Engine Transmission

02/09/2021 O-O Software Engineering 28

 Aggregation vs. Composition
• Composition is really a strong form of aggregation
• components have only one owner
• components cannot exist independent of their owner
• components live or die with their owner
e.g. Each car has an engine that can not be shared with other cars.
• Aggregations may form "part of" the aggregate, but may not be essential
to it. They may also exist independent of the aggregate.
e.g. Apples may exist independent of the bag.

02/09/2021 O-O Software Engineering 29

 Sequence Diagram(1)

• Sequence diagrams –  Models interaction of objects arranged

in time sequence.
• X-axis is objects –  Object that initiates interaction is left
most –  Object to the right are increasingly more subordinate
•  Y-axis is time –  Messages sent and received are ordered by
time
•   Object life lines represent the existence over a period of time
• Activation (double line) is the execution of the procedure.

02/09/2021 O-O Software Engineering 30

 Sequence Diagram (2)

02/09/2021 O-O Software Engineering 31

 Sequence Diagram (3)
• Initiator is leftmost object (boundary object)
•  Next is typically a control object
• Then comes entity objects

02/09/2021 O-O Software Engineering 32

 State Diagram

• Finite state machines (i.e., automata, Mealy/

Moore, state transition)
• Shows the sequence of states that an object goes
through during it’s life in response to outside
stimuli and messages.
• The state is the set of values that describes an
object at a specific point in time

02/09/2021 O-O Software Engineering 33

 State Diagram
• The state diagram has five basic elements:
The initial starting point, which is drawn using a solid circle;
A transition between states, which is drawn using a line with an
open arrowhead
A state, which is drawn using a rectangle with rounded corners
A decision point, which is drawn as an open circle
 One or more termination points, which are drawn using a circle
with a solid circle inside it.

02/09/2021 O-O Software Engineering 34

State diagram for money withdrawal from ATM

02/09/2021 O-O Software Engineering 35

 Activity Diagram (1)
• Activity diagrams represent the dynamics of the system.
• They are flow charts that are used to show the workflow of a
system.
• They show that:-
• The flow of control from activity to activity in the system
• What activities can be done in parallel.
• Alternate paths through the flow.
• They can show the flow across use cases or within a use
case; i.e show the internal state of an object

02/09/2021 O-O Software Engineering 36

 Activity Diagram (2)
• Core symbol is an activity. Round box.
• An activity is some task which needs to be done.
• Each activity can be followed by another activity
(sequencing).

02/09/2021 O-O Software Engineering 37

 Decision Activities
• Diamond.
• Each trigger coming from it has a guard.
• Synchronisation bar. or
• All triggers from this attach to activities that can occur in
parallel, with no specific sequence, or concurrently.
• The next synchronisation bar closes the concurrency.
• Iteration is represented by a * on the trigger.

02/09/2021 O-O Software Engineering 38

02/09/2021 O-O Software Engineering 39
 Component Diagram (1)
• Component diagram shows the structure of the code where as
deployment diagram shows the structure of the runtime system
• A component diagram contains components, interfaces and
relationships.
• The component diagram's main icon is a rectangle that has two
rectangles overlaid on
its left side.
• You put the name of the component inside the icon.
• The name is string.
• If the component is a member of a package, you can prefix the
component's name with the name of the package.
02/09/2021 O-O Software Engineering 40
 Component Diagram (2)

• A component and the interfaces are represented in two ways.

• One way is to show the interface as a rectangle that contains interface-related
information. It's connected to the component by the dotted line and empty triangle
that visualizes realization.
• Other way to represent interface is as a small circle connected to the component by
a solid line, which represents a realization relationship.

02/09/2021 O-O Software Engineering 41

Component Diagram (3)

02/09/2021 O-O Software Engineering 42

Component Diagram (4)
• Suppose that we need to build up software for playing music from a
CD-ROM Drive.
• A visual programming language might be used (VisualBasic or Delphi
for example)
• The programming language provides the interface for multimedia
control as shown below

02/09/2021 O-O Software Engineering 43

Component Diagram (5)
• All the components shown on the previous diagram belongs to one global
component Button, but actions they perform are different. We must obtain these
actions by programming them.

02/09/2021 O-O Software Engineering 44

 Deployment diagrams (1)
• The UML deployment diagram shows the configuration of run time
processing elements and the software components, process and
object that live in them.
• The UML deployment diagram provides a picture of how the physical
system will look when it's all put together.
• A system consists of nodes (represented by a cube) with line
connecting them, called connections.
• There are two types of nodes: a processor (can execute a component)
and a device (interface with the real world).
• Deployment diagrams are useful for modeling networks.

02/09/2021 O-O Software Engineering 45

 Deployment diagrams (2)

• The diagram shown below shows that a deployment diagram for a home computer
system. Computer consists of these hardware elements: CPU, monitor, printer, mouse,
keyboard. And installed software components: Windows98, Office98,
InternetExplorer4, FrontPage, DOS, NortonCommander, TurboPascal.
• In most cases the deployment diagram is used in conjunction with component diagram.

02/09/2021 O-O Software Engineering 46

 Deployment diagrams (2)

•.

02/09/2021 O-O Software Engineering 47

 Thank
Thank You
You ...
...

02/09/2021 O-O Software Engineering 48