Faculty of Computing and Information Technology in Rabigh

COIT 415
Object-Oriented Analysis and
Design
Chapter II – Introduction to UML
 UML Basics
 UML Modeling and Diagrams

1
 UML Basics
What Is Modelling ?
Modelling involves:
representation or simplification of reality
providing a blueprint of a system

Why Model ?
better understand the system we are developing
describe the structure or behavior of the system
experiment by exploring multiple solutions
furnish abstraction for managing complexity
document the design decisions
visualize the system “as-is” and ”to-be”
provide a template for constructing a system
2
 What is UML ?
UML = Unified Modeling Language
A language for visualizing, specifying, constructing
and documenting artifacts of software-intensive
systems.
Examples of artifacts: requirements, architecture,
design, source code, test cases, prototypes, etc.
UML is suitable for modeling various kinds of systems:
enterprise information systems,
distributed web-based,
real-time embedded system, etc.
3
 UML – Specification Language
 Provides views for development and deployment.
 UML is recommended for use with the processes that are:
 use-case driven: the use cases are used as an artifact for establishing the desired
behavior, for verifying and validating the system’s architecture, for testing, and for
communicating among the stakeholders of the project.

 architecture-centric: means that a system’s architecture is used as a primary

artifact for conceptualizing, constructing, managing, and evolving the system under
development.

 Iterative: involves managing a stream of executable releases.

 Incremental: involves the continuous integration of the system’s architecture to

produce these releases.

4
 Why is UML powerful ?
All the elements and diagrams in UML are based on
object-oriented paradigms.
UML was developed having RUP (Rational Unified
Process) model in mind. This model is :
 Iterative and incremental
 Architecture centric
 Use case driven
UML can be used to model a broad range of systems
(information systems, technical systems, distributed
systems, business systems and real-time systems).
UML can also be used in the different phases of software
development, from requirements specification to test of a
finished system. 5
 History of UML
Started as a unification of the Booch and Rumbaugh
methods - Unified Method v. 0.8 (1995)
Jacobson contributes to produce UML 0.9, 1996
UML Partners work with three Amigos* to propose UML
as a standard modeling language to OMG in 1996.
UML partners tender their proposal (UML 1.0) to OMG
in 1997, and 9 months later submit final UML 1.1.
Minor revision is UML 1.4 adopted in May 2001, and the
most recent revision is UML 1.5, March 2003.
UML 2.0 released by the end 2004.
UML 2.2 released by 2008.

* Three Amigos: Grady Booch, Ivar Jacobson and James Rumbaugh

6
 History of UML

Apr 10, 2024 7

 History of UML
Although UML 2.1 was never released as a formal
specification, versions 2.1.1 and 2.1.2 appeared in 2007,
followed by UML 2.2 in February 2009.
UML 2.3 was formally released in May 2010.
 UML 2.4.1 was formally released in August 2011.
 UML 2.5 was released in October 2012 as an "In progress"
version and was officially released in June 2015.
 Formal version 2.5.1 was adopted in December 2017

8
UML Modelling and Diagrams
UML Modeling UML Diagrams
A. Requirements 1. Use Case
B. Architecture 2. Class
C. Design 3. Object
D. Implementation 4. Sequence
E. Deployment 5. State
6. Component
7. Collaboration
8. Activity
9. Deployment

9
 UML Building Blocks
Three basic building blocks:
1. Elements: main “citizens” of the model
2. Relationships: relationships that tie elements together
3. Diagrams: mechanisms to group interesting collections
of elements and relationships

They will be used to represent complex

structures.

10
 Elements
Four basic types of elements:
1. Structural
2. Behavioral
3. Grouping
4. Notation

They will be used to specify well-formed

models.

11
 Structural Elements
Static part of the model to represent conceptual elements
“nouns” of the model
Seven kinds of structural elements:
1. Class
2. Interface
3. Collaboration
4. Use Case
5. active class
6. Component
7. Node

12
 Element 1: Class
Description of a set of objects that share the same
attributes, operations, relationships and semantics
Implements one or more interfaces
Graphically rendered as a rectangle usually including a
name, attributes and operations

Student
Student_Id
Name
GPA
Input_Data()
Calc_GPA()

13
Class diagram - Example

14
 Element 2: Interface
Collection of operations that specifies a service of a
class
Describes the externally visible behavior, partial or
complete, of a class
Defines a set of operation signatures but not their
implementations
Rendered as a circle with a name

PaymentTransaction IdentityManagement

15
 Element 3: Collaboration
Defines an interaction between elements
Several elements cooperating to deliver a behavior,
rather than individual behavior
Includes structural and behavioral dimensions
Represented as a named ellipse drawn with a dashed
line

16
 Element 4: Use Case
Description of a sequence of actions that a system
performs to deliver an observable result to a particular
actor
Used to structure the behavioral elements in a model
Realized by collaboration
Graphically rendered as an ellipse drawn with a solid
line

Send the list of

required items

17
Use Case diagram - Example

18
 Element 5: Active Class
A class whose objects own one or more processes or
threads and therefore can initiate an action
A class whose objects have concurrent behavior with other
objects
It also can be used to represent processes and threads
An active class initiate and control the flow of activity, while a
passive class stores data and serves other classes.
Graphically, an active class is
 rendered just like a class
 drawn with a thick line

For example, a class that intercepts incoming calls and

messages that can come at any time, should be active.
19
 Element 6: Component
Physical, replaceable part of a system that conforms to
and provides the realization of a set of interfaces.
Represents deployment components such as Java
Beans components
Represents a physical packaging of logical elements
such as classes, interfaces and collaborations
It can also be used to represent applications, files,
libraries, pages and tables

20
 Element 7: Node
A physical element, exists at run time
Represents a computational resource with
memory and processing capacity
A set of components may reside in a node
Components may also migrate from one node to
another
Graphically modeled as a cube

21
 Behavioural Elements
Represent behavior over time and space
“verbs” of the model
Two kinds of behavioral elements:
Interaction
State machine

22
 Element 8: Interaction
A set of messages exchanged among a set of objects
within a particular context to accomplish a specific
goal
Specifies the behavior of a set of objects
Involves a number of other elements:
Messages
action sequences (behavior invoked by a message)
links (connection between objects)
Graphically rendered as an arrow
saveapplication()

23
Interaction diagram - Example

24
 Element 9: State Machine
a sequence of states of an object or interaction goes through
during its lifetime, and its response to external events
may specify the behavior of an individual class or a
collaboration of classes
includes a number of elements: states, transition, events and
activities
presented as a rounded rectangle with a name and sub-states

Interactions and state machines are associated with

structural elements such as classes, collaborations and
objects.
25
State Machine diagram -Example

26
 Element 10: Package
Grouping element of UML:
Organizes diagrams
Primary kind of grouping and decomposition
Conceptual, only available at development time
Graphically represented as a tabbed folder

27
 Element 11: Note
Annotation element:
comments added to models for better explanation or
illumination on specific elements
used primarily for annotation e.g. rendering
constraints and comments attached to elements or
collections of elements
presented as a rectangle with a dog-eared corner
may include both textual and graphical comments

28
 Relationships
Four basic types of relationships:
Dependency
Associations
Generalization
Realization

Meanings are consistent with the basic Object

Oriented relationship types described earlier.

29
 Relationship 1: Dependency
A semantic relationship between two elements in which a
change to one element (independent element) may
affect the meaning of another (dependent element).
Non-structural, “using” relationship
Given as a directed dashed line possibly with a label:

Dependent element Independent element

Client Supplier
Class

Dependency relationship
30
 Relationship 2: Association
a structural relationship describing a set of links
links are connections between objects
Aggregation is a special type of association depicting the
whole-part relationship
Composition is stricter form of aggregation, in which
lifespan of individual objects depend on the on lifespan of
the aggregate object

association is presented as a solid line, possibly directed,

labeled and with adornments (multiplicity and role
names)

31
 Relationship 2: Association
Association Role Name
ROLES
Works for
Person Company

Employee Employer

aggregation

composition

32
 Relationship 3: Generalization
a relationship in which objects of a specialized element
(child) are substitutable for objects of a generalized
element (parent)
child elements share the structure/behavior of the
parent
rendered graphically as a solid line with hollow
arrowhead pointing to the parent

33
 Relationship 4: Realization
 a semantic relationship between elements, wherein one element
specifies a` contract and another guarantees to carry out this contract.
 denotes the implementation of the functionality defined in one class
by another class
 relevant in two basic scenarios:
a) interfaces versus realizing classes/components
b) uses cases versus realizing collaborations
 graphically depicted as a dashed arrow with hollow head, a cross
between dependency and generalization
Contract

Implementation
34
 Relationship 4: Realization
The source object implements or realizes the
destination Tube
<<interface>>
Shape
Pyramid
Draw
Move
Scale
Rotate Cube

Realization relationship