UML

MODULE 3:
 Unified Modeling language- Introduction,
UML Diagrams – Class diagrams, Sequence
diagrams, Object diagrams, Deployment
diagrams, Use case diagrams, State diagrams,
Activity diagram, Component diagrams –
Case StudyIdentifying Classes- Noun Phrase
Approach, Common class Pattern Approach,
Use-Case Driven Approach, CRC.
 History of the UML

 1975-1988: object-oriented modeling

languages, a new genre of object-oriented
programming languages and increasingly
complex applications
 1989-1994: increasing of object-oriented
methods (from fewer then 10 to more than
50), “method wars”. Booch, Jacobson's
OOSE, Rumbaugh's OMT, Fusion, Shlaer-
Mellor, and Coad-Yourdon methods.
 History of the UML

 1995-2003: Grady Booch (Rational

Software Corporation), Ivar Jacobson
(Objectory), and James Rumbaugh
(General Electric) began to adopt ideas
from each other's methods. UML 0.8 … 1
 2004-…: UML 2.0.
 Modeling with UML
 A model is an abstraction describing system or
a subset of a system
 A view depicts selected aspects of a model
 A notation is a set of graphical or textual rules
for representing views
 Views and models of a single system may
overlap each other
 Principles of object-oriented
modeling of software systems
 Aims of modeling:
 Models help us to visualize a system as it is or as
we want it to be.
 Models permit us to specify the structure or
behavior of a system.
 Models give us a template that guides us in
constructing a system.
 Models document the decisions we have made.
 Principles of object-oriented
modeling of software systems
 Basic principles of modeling:
 The choice of what models to create has a profound
influence on how a problem is attacked and how a solution
is shaped.
 Every model may be expressed at different levels of
precision.
 The best models are connected to reality.
 No single model is sufficient. Every nontrivial system is
best approached through a small set of nearly independent
models.
 What is UML?

 The Unified Modeling Language (UML) is a standard language

for writing software blueprints. The UML may be used to
visualize, specify, construct, and document the artifacts of a
software intensive system.
 The UML is only a language and so is just one part of a
software development method.
 Three major elements of model:
 the UML's basic building blocks,
 the rules that dictate how those building blocks may be put
together,
 some common mechanisms that apply throughout the UML.
 Building Blocks of the UML

Things (entities)
Relationships
Diagrams
 Entites

 Entities are the elements of models.

 All UML entities can be divided into:
 structural entities - nouns UML models, such as class, interface,
cooperation, precedent, the active class, component, unit,
 behavioral entities - verbs UML models, such as interaction, activity,
machines; grouping the essence of the package that is used for grouping
semantically related elements of the model in forming a single whole
modules;
 summary entity - note, which can be added to the model to record
specific information, very much like the sticker.
 Structural entities

 Structural entities are the nouns of UML

models. These are the mostly static parts of a
model, representing elements that are either
conceptual or physical.
 Class
 Interface
 Collaboration
 Use case
 Relationships in UML

 Dependency
 Association
 Generalization
 Realization
Type of relationship UML syntax Semantics
Source – Target
Dependency Source element depends on
the target element and
change last may affect the
first.
Association Description of the set of
relationships between
objects.
Aggregation The target element is a part
of the source element.
Composition Strict (more limited) form of
aggregation/
Type of relationship UML syntax Semantics
Source – Target
Inclusion Source element contains the
target element.
Generalization The source element is a
specialization of a more
generalized the target
element, and can replace
him.
Realization The original item is
guaranteed to perform the
contract, a certain target
element.
 Diagrams in the UML

 A diagram is the graphical presentation of a set

of elements, most often rendered as a connected
graph of vertices (things) and arcs
(relationships).
 The diagram is not a model!
 The things or relationships can be deleted from
the chart, or even with all the diagrams, but still
they continue to exist in the model.
 Diagrams in the UML

 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Statechart diagram
 Activity diagram
 Component diagram
 Deployment diagram
 Class diagrams

 A class diagram shows a set of classes,

interfaces, and collaborations and their
relationships.
 These diagrams are the most common diagram
found in modeling object-oriented systems.
Class diagrams address the static design view of
a system. Class diagrams that include active
classes address the static process view of a
system.
 Object diagram

 An object diagram shows a set of objects and

their relationships. Object diagrams represent
static snapshots of instances of the things found
in class diagrams. These diagrams address the
static design view or static process view of a
system as do class diagrams, but from the
perspective of real or prototypical cases.
 Use case diagram

 A use case diagram shows a set of use cases and

actors (a special kind of class) and their
relationships. Use case diagrams address the
static use case view of a system. These
diagrams are especially important in organizing
and modeling the behaviors of a system.
 Sequence and collaboration
diagrams
 Both sequence diagrams and collaboration diagrams are
kinds of interaction diagrams. An shows an interaction,
consisting of a set of objects and their relationships,
including the messages that may be dispatched among
them. Interaction diagrams address the dynamic view of a
system.
 A sequence diagram is an interaction diagram that
emphasizes the time-ordering of messages; a collaboration
diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive
messages. Sequence diagrams and collaboration diagrams
are isomorphic, meaning that you can take one and
transform it into the other.
 Statechart diagrams

 A statechart diagram shows a state machine,

consisting of states, transitions, events, and
activities. Statechart diagrams address the
dynamic view of a system. They are especially
important in modeling the behavior of an
interface, class, or collaboration and emphasize
the event-ordered behavior of an object, which
is especially useful in modeling reactive
systems.
 Activity diagram

 An activity diagram is a special kind of a

statechart diagram that shows the flow from
activity to activity within a system. Activity
diagrams address the dynamic view of a
system. They are especially important in
modeling the function of a system and
emphasize the flow of control among objects.
 Component diagram

 A component diagram shows the organizations

and dependencies among a set of components.
Component diagrams address the static
implementation view of a system. They are
related to class diagrams in that a component
typically maps to one or more classes,
interfaces, or collaborations.
 Deployment diagram

 A deployment diagram shows the configuration

of run-time processing nodes and the
components that live on them. Deployment
diagrams address the static deployment view of
an architecture. They are related to component
diagrams in that a node typically encloses one
or more components.
UML
 UML STRUCTURE
• building blocks – these are the basic UML modelling
elements, relationships and diagrams
• common mechanisms – common UML ways of achieving
specific goals
• architecture – the UML view of system architecture
 1.1 Things
• structural things – the nouns of a UML model such as class,
interface, collaboration, use case, active class, component,
node;
• behavioral things – the verbs of a UML model such as
interactions, state machines;
• grouping things – the package, which is used to group
semantically related modeling elements into cohesive units;
• annotational things – the note, which may be appended to
the model to capture ad hoc information, very much like a
1.2 Relationships
1.3 Diagrams
 [Link] Mechanisms
• specifications are textual descriptions of the features and
semantics of model elements – the meat of the model;
• adornments are items of information exposed on a modeling
element in a diagram to illustrate a point;
• common divisions:
classifier and instance: classifier – the abstract notion of a
type of thing, e.g. a bank account; instance – a specific
instance of a type of thing, e.g. my bank account;
  interface and implementation: interface – a contract
that specifies the behavior of a thing; implementation –
the specific details of how the thing works;
• extensibility mechanisms:
 constraints allow us to add new rules to modelling
elements;
 stereotypes introduce new modelling elements based
on old ones;
 tagged values allow us to add new properties to model
elements – a tagged value is a keyword with an
associated value.
Architecture
 Use case Modelling
• Use cases are a way of capturing requirements.
actors – roles played by people or things that use the system;
 use cases – things that the actors can do with the system;
 relationships – meaningful relationships between actors and
use cases;
 system boundary – a box drawn around the use cases to
denote the edge or boundary of the system being modeled.
 The system boundary

• The system boundary separates the system from the rest

of the world.

• define what is part of your system (inside the system

boundary) and what is external to your system (outside the

system boundary).

• The system boundary is drawn as a box, labeled with the

name of the system, with the actors drawn outside the

Actors
• Actors are roles adopted by things that interact directly with
the system.
• Actors are external to the system.
• IDENTIFYING ACTORS
• Who or what uses the system?
• What roles do they play in the interaction?
• Who installs the system?
• Who starts and shuts down the system?
• Who maintains the system?
• What other systems interact with this system?
• Who gets and provides information to the system?
Use cases
• A use case describes behaviour that the system
exhibits to benefit one or more actors.
• use cases are always started by an actor;
• use cases are always written from the point of view
of an actor.
Use case Diagrams
Use Case
A use case represents a class of functionality provided
by the system as an event flow.
A use case consists of:
• Unique name
• Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements
 Use Case Example
Event flow:
Name: Purchase ticket
1. Passenger selects
the number of zones to
Participating actor:
be traveled.
Passenger
2. Distributor displays
the amount due.
Entry condition:
3. Passenger inserts
• Passenger standing in
money, of at least the
front of ticket distributor.
amount due.
• Passenger has sufficient
4. Distributor returns
money to purchase
change.
ticket.
5. Distributor issues
ticket.
Exit condition:
The <<extend>> Relationship
• <<extend>>
relationships
represent exceptional
or seldom invoked
cases.
• The exceptional event
flows are factored out
of the main event
flow for clarity.
• Use cases
representing
exceptional flows can
extend more than one
use case.
• The direction of a
The <<include>>
Relationship
• An <<include>> relationship
represents behavior that is
factored out of the use case.
• An <<include>> represents
behavior that is factored out
for reuse, not because it is
an exception.
• The direction of a
<<include>> relationship is
to the using use case (unlike
 UML
Class Diagrams: Basic Concepts
 Objects

 The purpose of class modeling is to describe objects.

 An object is a concept, abstraction or thing that has
meaning for a domain/application.
 Some objects have real world counterparts while
others are conceptual entities.
 The choice of objects depends on judgment and the
nature of problem.
 ِAll objects have identity and are distinguishable.
 Classes

 An object is an instance – occurrence – of a class

 A class describes a group of objects with the same properties
(attributes), behavior (operations), kinds of relationships, and
semantics.

 The objects in a class share a common semantic purpose, above and

beyond the requirement of common attributes and behavior.

 By grouping objects onto classes we abstract a problem.

 UML representation of
classes/objects:
 UML: Unified Modeling Language (OMG Standard):
O.O Visual Modeling language

 Class/object representation
 Values and attributes
 Value : piece of data.
 Attribute: a named property of a class that describes a
value held by each object of the class.

 Attributes may be discovered by looking for adjectives or by

abstracting typical values.

 Don’t confuse values with objects:

• An attribute should describe values, not objects.
• Unlike objects, values lac identity
UML representation
 Object identifiers
 Objects identifiers are implicit.
 Objects belonging to the same and having the same attributes
values may be different individual objects.
 Operations and Methods
 An operation is a function or procedure that may be applied to or by
objects in a class.

 Each operation has a target object as an implicit parameter.

 All objects in a class share the same operations.

 The behavior of the operation depends on the class of its target.

 The same operation may apply to many different classes. Such an

operation is POLYMORPHIC.
 Operations and Methods
 A method is the implementation of an operation for a
class.
 A different piece of code may implement each method.
 An operation may have arguments in addition to its target
object. These arguments may be placeholders for values
and/or for objects.
 When an operation has methods on several classes these
methods must have the same SIGNATURE: number and
types of arguments, type of result value.
UML representation
 Links and Association concepts
 A link is a physical or conceptual connection among objects.
 Most links relate two objects, but some links relate three or
more objects.
 A link is defined as a tuple, that is a list of objects.
 A link is an instance of an association.
 An association is a description of a group of links with
common structure and semantics.
 Association is denoted by a line. Its name is optional if the
model is unambigious.
Examples
 Associations are inherently bi-directional. The association
name is usually read in a particular direction but the binary
association may be traversed in either direction.

 ِ A reference is an attribute in one object that refers to

another object.
 Multiplicity
 It specifies the number of instances of one class that may
relate to a single instance of the associated class.

 UML diagrams explicitly list multiplicity at the end of

association lines.
 Intervals are used to express multiplicity:
 1 (exactly one)
 0..1 (zero or one)
 1..* (one or more)
 0..* (zero or more)
 3..5 (three to five inclusive)
 Association Ends
 Associations have ends. They are called ‘Association Ends’.
 They may have names (which often appear in problem
descriptions).
 Association Ends
 Use of association end names is optional.
 But association end names are useful for traversing associations.
 ِAssociation end names are necessary for for associations between
objects of the same class.
Example of association ends use
 Association: ordering, bag,
sequence
 On a ‘many” association end, sometimes, it is required that
objects have an explicit order.
 In this case the ordering is an inherent part of the association
 Example:
 Association: ordering, bag,
sequence
 Ordinary a binary association has at most one link for a pair of objects
 However we can permit multiple links for a pair of objects by annotating
an association end with {bag} or {sequence}
 A bag is a collection of elements with duplicates allowed.
 A sequence is an ordered collection of elements with duplicates allowed
 Association class
 UML offers the ability to describe links of association with attributes like
any class.
 An association class is an association that is also a class.
 Association class
 Examples:
 Association class
 Example
 Qualified Association
 A qualified association is an association in which an attribute called
Qualifier disambiguates the objects for a ‘many’ association’ end.
 A qualifier selects among the target objects, reducing the effective
multiplicity fro ‘many’ to ‘one’.
 Both below models are acceptable but the qualified model adds
information.
 Qualified Association
 Example:
 Generalization/Inheritance
 Generalization is the relationship between a class (superclass) and one or
more variations of the class (subclasses).
 Generalization organizes classes by their similarities and their
differences, structuring the descriptions of objects.
 A superclass holds common attributes, attributes and associations.
 The subclasses adds specific attributes, operations, and associations.
They inherit the features of their superclass.
 Often Generalization is called a “IS A” relationship
 Simple generalization organizes classes into a hierarchy.
 A subclass may override a superclass feature (attribute default values,
operation) by redefining a feature with the same name.
 Never override the signature of methods.
 Use of generalization
 Used for three purposes:
 Support of polymorphism:
• polymorphism increases the flexibility of software.
• Adding a new subclass and automatically inheriting superclass behavior.
 Structuring the description of objects:
• Forming a taxonomy (classification), organizing objects according to
their similarities. It is much more profound than modeling each class
individually and in isolation of other similar classes.

 Enabling code reuse:

• Reuse is more productive than repeatedly writing code from scratch.
 Aggregation
 Aggregation is a strong form of association in which an
aggregate object is made of constituent parts.
 The aggregate is semantically an extended object that is
treated as a UNIT in many operations, although physically
it is made of several lesser objects.

 Aggregation is a transitive relation:

 if A is a part od B and B is a part of C then A is also a part of C
 Aggregation is an antisymmetric relation:
 If A is a part of B then B is not a part of A.
 Aggregation versus Association
 Aggregation is a special form of association, not an independent concept .
 Aggregation adds semantic connotations:
 If two objects are tightly bound by a part-whole relation it is an aggregation.
 If the two objects are usually considered as independent, even though they
may often be linked, it is an association. ِ
 Discovering aggregation
 Would you use the phrase part of ?
 Do some operations on the whole automatically apply to its parts?
 Do some attributes values propagates from the whole to all or some parts?
 Is there an asymmetry to the association, where one class is subordinate to
the other?
 Aggregation versus Composition
 Composition is a form of aggregation with additional
constraints:

 A constituent part can belong to at most one assembly (whole).

• it has a coincident lifetime with the assembly.
• Deletion of an assembly object triggers automatically a deletion of all
constituent objects via composition.

 Composition implies ownership of the parts by the whole.

• Parts cannot be shared by different wholes.
 Propagation of operations
 Propagation is the automatic application of an operation to a network of
objects when the operation is applied to some starting object.
 Propagation of operations to parts is often a good indicator of
propagation.
 UML Artifacts (Part 2)

1. Collaboration Diagrams
2. State Transition Diagrams
 Collaboration Diagrams

For each system operation

identified in the Use Case Diagrams, and
described in a contract
Design a system of interacting objects to perform the
operation.

The collaboration diagram will indicate the objects

participating in the collaboration, and
The sequence of messages {message(parameters),
sender, receiver} exchanged to achieve the task
involved.
Collaboration Diagrams

Actor System

System SystemOp
Op
:ClassA
+ Operation:xxx
Precondition:. 1:
. message1()

:ClassB

Use Case
Contract
Diagram Collaboration
Diagram
Alternatively (or perhaps primarily)
Sequence Diagrams can be used
instead of Collaboration Diagrams
 Sequence Diagrams

Actor System

:ClassA :ClassB
System
Op
SystemOp
Operation:xxx message1()
+
Precondition:.
.

Use Case Contract

Diagram Collaboration
Diagram
 Collaboration Diagrams

Notation

Student :Student John:Student

class instance named

instance
The Collaboration diagram should consist of illustrations of
the messages sent to objects of the classes identified in the
creates/destroys, reads, changes sections of the contract.
The system operation will be directed to one of the objects
in this group that will act as the controller for executing this
task.
 Collaboration Diagrams

Illustrating links

UML standard syntax for messages

return := message(parameter : parameterType) :

returnType
sysOp() optional

1: tot := total():integer
:POST :Sale

sender receiver
Illustrating Iteration

SystemOp( )

1*: [i:=0..9] str : getName():

String CS335:ClassList
:Grader

sender receiver
Sequence number followed Iteration clause is optional
by a * indicates iteration
 Collaboration Diagrams

Illustrating Iteration
In the example described on the previous slide, we
assumed that the target object contained a sequence
of names (simple strings) as an attribute. More
generally the ClassList may be considered a
collection of StudentRec objects, and messages may
be directed to the collection. The depiction of a
message to a multiobject – a group of objects stored
in a collection – is indicated on the next slide.

1: message( )
:ClassA

Representation of a collection (multiobject)

 Collaboration Diagrams

Given: A vector of StudentRecord

1: inx := find(name: String): integer

v: vector

Version 1 – message to a collection (but vector is NOT a

concept in the problem domain)

1: inx := find(name: String):

integer :StudentRecord

Version 2 – (preferred) Emphasizes the objects in the

collection, not (the solution domain) container.
 Collaboration Diagrams

Conditional Paths – mutually exclusive messages

msg1( )

1a: [test] msg2( ) :ClassB

:ClassA
guard – if true send msg

1b: [not test] msg4( ) 1a.1:

msg3( )

1b.1: msg5( )
:ClassC :ClassD
 Collaboration Diagrams

Creating a new instance during implementation of

the system operation

New
1: create( )
c: Controller m:MenuItem

2: add(m)
:MenuItem

Create a new MenuItem, m, and add it to the

Menu
 Sequence Diagrams

Sequence diagrams offer an alternate way of expressing the exchange

of messages that occur between objects in an object-based system.

The notation for objects and collections is the same as used in

collaboration diagrams. Time ordering is from top to bottom.

:ClassA :ClassB

msg1( )

msg2( )
Each message between
Focus of control is objects is represented with a
msg3( )
illustrated with an message expression on an
activation box arrowed line between the
objects
 Sequence Diagrams

Additional Notation
Object creation -- let the classB object create an
instance of a classC object.
Newly created class
is placed in a column
:ClassA :ClassB
starting at the level
(time) of creation.
msg1( )

msg2( )
create( )
msg3( )
:ClassC
msg4( )

time
 Sequence Diagrams

Conditional
Mutually exclusive
messageconditional
– has guardmessage
to specify the condition

:ClassA :ClassB :ClassC

msg1( )

[flag = true]
msg2( )
[flag = false] msg3( )
 Sequence Diagrams

Iteration for for

Iteration a single message
a sequence of messages

:ClassA :ClassB :ClassC

msg1( )

*[i = 1..N] msg2( )

msg3( )
msg4( )
*[k = 1..M]

msg5( )

Enclose the repeated sequence in a box, and indicate the

multiplicity
 Refining the Class Diagram

Class name

Data attributes
Classes to which
Link attributes messages are
sent
Messages
methods received

Class Description
 State Transition Diagrams

State transition diagrams are a useful tool for

constructing the individual classes. Specifically, they aid
in two important ways in “fleshing out” the structure of
the class:
1. method development -- State transition diagrams provide
the “blueprints” for developing the algorithms that
implement methods in the class

2. attribute identification – Attributes contain the state

information needed for regulating the behaviors of the
instances of the class
When constructing state transition diagrams, take care to
ensure that the post-conditions stipulated in the contracts
are enforced.
 State Transition Diagrams
Notation
Transitions are labeled with the
Some events do not triggering event and the output if any
trigger a change in
state event|output

State 1 State 2

start

States are represented

with an oval and label

State transitions are represented

final state
with a directed arc or line
 State Transition Diagrams

Additional Notation

event|output
State State
[boolean condition]

Guard condition – transition

occurs only if condition is true
 State Transition Diagrams

Example – Nested States in Telephone Call

off hook|dial tone

[valid subscriber]

idle active

talking
on hook playing dial do: hang up
tone
answered
digit
The state labeled
complete|ringing
active has
substates dialing connectin
g

digit
 State Transition Diagrams

Second Example – A Queue of Capacity Two

arrival arrival

Size0 Size1 size2

departure departure
arrival | balk

The queue has three states that indicate its number of

occupants. When the queue is full, new arrivals cannot enter,
and must leave the system.
 Description of Class Queue

class Queue {
private:
State
int capacity, size;
public:
Queue(int cap);
void enqueue(Object obj); State
//precondition: queue not full transitions
//post condition: if (queue not full)
// size = size + 1
// else no change
Object dequeue();
//precondition: queue not empty
//post-condition: size = size-1
}
 Visibility

For an object A to send a message to object B, B must be

visible to A.

In determining the visibility of one object to another, we

must decide during the design whether the link between
objects A and B is:

permanent or transient
exclusive or shared
fixed or variable
 Visibility

Example 1. permanent, exclusive , and fixed

Consider a clock composed of three Counters (hours, mins,

secs)
Clock Counter
*
modulus
3 count

• The Counters have the same lifetime as the Clock –

They are created with the clock and dissolved when the
clock is out of scope.
• The Counters are bound exclusively to the Clock – They
cannot be referenced by any other object in the system
 Visibility

Implementation of the association between Clock and

Counters
class Clock {
private:
Counter hours, mins, secs;
public:
Counter( ) : hours(24), mins(60), secs(60) {};
//other methods
}

C++ header file

 Visibility

Example 2. permanent, shared, fixed

ProductSpe Computer
*
c describes

The ProductSpec exists before an instance of the

product is created. That product (computer) will have a
permanent association with its ProductSpec that it will
share access to with other computers of the same
model.
 Visibility

(Partial) Specification of class Computer

class Computer {
private:
ProductSpec &
ps; public:

Computer (ProductSpec & theMod) : ps(theMod)

{};
//other methods
}
The reference variable ps must be initialized in an initialization
list, and cannot be reassigned during the life of the object.
 Visibility

Attribute visibility -- an association that must be

remembered is implemented as attribute visibility. We
have just seen a couple of examples of attribute
associativity. In C++ attribute associativity is provided
via three forms of the declaration
permanent and exclusive; lifetime of
Counter c; the counter is bounded by the lifetime
of the object itself.

Stack * s; Can be non-permanent, variable, and

shared
Permanent and fixed, but not
ProductSpec & ps; necessarily exclusive; lifetime of the
ProductSpec will exceed that of object
 Visibility

Transient visibility is not remembered, but persists only

during the execution of a single method. It is
implemented in one of two ways.

Parameter visibility – object C is passed from A to B

1: [new sale] create()

3: makeLineItem(spec, qty) :Sale

:POST

2: spec:=
specification(upc) A ProductSpec object is
:ProductCatalog passed to the Sale object for
use by its makeLineItem
method
COMPONENT
DIAGRAM
in UML 2.0
 PLAN OF TALK

 Introduction about components

 Components and component diagrams in uml
2.0
 Case study
 Elements of the component
 Component view: black-box view and white-
box view
 Deployment diagrams
 INTRODUCTION
 UML component diagrams describe software
components and their dependencies to each others
 A component is an autonomous unit within a system
 The components can be used to define software systems of
arbitrary size and complexity
 UML component diagrams enable to model the high-level
software components, and the interfaces to those
components
 Important for component-based development (CBD)
 Component and subsystems can be flexibly REUSED and
REPLACED
 A dependency exists between two elements if changes to
the definition of one element may cause changes to the
other
 Component Diagrams are often referred to as “wiring
diagrams”
 The wiring of components can be represented on diagrams
 INTRODUCTION
An Uml diagram classification:
 Static
 Use case diagram, Class diagram
 Dynamic
 State diagram, Activity diagram, Sequence diagram,
Collaboration diagram
 Implementation
 Component diagram, Deployment diagram

UML components diagrams are

 Implementation diagrams:
describe the different elements required for
implementing a system
 INTRODUCTION
Another classification:
 Behavior diagrams
 A type of diagram that depicts behavior of a system
This includes activity, state machine, and use case
diagrams, interaction diagrams
 Interaction diagrams
 A subset of behavior diagrams which emphasize object
interactions. This includes collaboration, activity,
sequence diagrams
 Structure diagrams
 A type of diagram that depicts the elements of a
specification that are irrespective of time. This
includes class, composite structure, component,
deployment

UML components diagrams are structure

diagrams
 COMPONENT in UML 2.0

 Modular unit with well-defined interfaces

that is replaceable within its environment
 Autonomous unit within a system
 Has one or more provided and required
interfaces
 Its internals are hidden and
inaccessible
 A component is encapsulated
 Its dependencies are designed such
that it can be treated as independently
as possible
 CASE STUDY
 Development of an application collecting students’
opinions about courses
 A student can
 Read
 Insert
 Update
 Make data permanent about the courses in its schedule
 A professor can only see statistic elaboration of the
data
 The student application must be installed in pc client
(sw1, sw2)
 The manager application must be installed in pc
client (in the manager’s office)
 There is one or more servers with DataBase and
components for courses management
 COMPONENT NOTATION
 A component is shown as a rectangle
with
 A keyword <<component>>

 Optionally, in the right hand corner

a component icon can be
displayed
 A component icon is a rectangle with
two smaller rectangles jutting out from
the left-hand side
 This symbol is a visual stereotype

 The component
Components name
can be labelled with a stereotype
there are a number of standard stereotypes
ex: <<entity>>, <<subsystem>>
 Component ELEMENTS
 A component can have
 Interfaces
An interface represents a declaration of a set of
operations and obligations
 Usage dependencies
A usage dependency is relationship which one
element
requires another element for its full implementation
 Ports
Port represents an interaction point between a
component
and its environment
 Connectors
• Connect two components
• Connect the external contract of a component to
the internal structure
 INTERFACE
 A component defines its behaviour in terms of
provided and required interfaces
 An interface
 Is the definition of a collection of one or more
operations
 Provides only the operations but not the
implementation
 Implementation is normally provided by a class/
component
 In complex systems, the physical implementation is
provided by a group of classes rather than a single
class
 INTERFACE

 May be shown using a

rectangle symbol with a
keyword <<interface>>
preceding the name
 For displaying the full
signature, the interface
rectangle can be expanded to
show details
 Can be
 Provided
 Required
 INTERFACE
 A provided interface
 Characterize services that
the component offers to its
environment
 Is modeled using a ball,
labelled with the name,
attached by a solid line to
the component
 A required interface
 Characterize services that the component expects
from its environment
 Is modeled using a socket, labelled with the name,
attached by a solid line to the component
 In UML 1.x were modeled using a dashed arrow
 INTERFACE
 Where two components/classes provide and
require the same interface, these two notations
may be combined

 The ball-and-socket notation hint at that interface in

question serves to mediate interactions between the
two components
 If an interface is shown using the rectangle symbol,
we can use an alternative notation, using
dependency arrows
 INTERFACE
 In a system context where there are multiple
components that require or provide a particular
interface, a notation abstraction can be used that
combines by joining
the interfaces

 A component
 Specifies a CONTRACT of the services that it
provides to its clients and that it requires from
others components in terms of its provided and
required interfaces
 Can be replaced
 The system can be extended
 DEPENDENCIES
 Components can be
connected by usage
dependencies
 Usage Dependency
 A usage dependency is relationship which one
element requires another element for its full
implementation
 Is a dependency in which the client requires
the presence of the supplier
 Is shown as dashed arrow with a <<use>>
keyword
 The arrowhead point from the dependent
component to the one of which it is
dependent
 PORT
 Specifies a distinct interaction point
 Between that component and its environment
 Between that component and its internal parts

 Is shown as a small square symbol

 Ports can be named, and the name
is placed near the square symbol
 Is associated with the interfaces
that specify the nature of the
interactions that may occur over a
port
 PORT
 Ports can support unidirectional
communication or bi-directional
communication

 If there are multiple

interfaces associated
with a port, these
interfaces may be
listed with the interface
icon, separated by a
commas
 PORT

 All interactions of a component with its

environment are achieved through a port
 The internals are fully isolated from the
environment
 This allows such a component to be used in
any context that satisfies the constraints
specified by its ports
 Ports are not defined in UML 1.x
 EXTERNAL VIEW
 A component have an external view and an
internal view

 An external view (or black

box view) shows publicly
visible properties and
operations
 An external view of a component

is by means of interface symbols

sticking out of the component
box
 The interface can be listed in the

compartment of a component box

 INTERNAL VIEW

 An internal, or white
box view of a
component is where
the realizing
classes/components are
nested within the
component shape
 Realization is a relationship between two set
of model elements
 One represents a specification
 The other represent an implementation of
the latter
 INTERNAL VIEW

 The internal class that realize the

behavior of a component may
be displayed in an additional
compartment
 Compartments can also be used to
display parts, connectors or
implementation artifacts
 An artifact is the specification of a
phisycal piece of information
 INTERNAL VIEW
 Components can be built recursively
 ASSEMBLY
 Two kinds of connectors:
 Delegation
 Assembly
 ASSEMBLY CONNECTOR
 A connector between 2 components defines
that one component provides the services that
another component requires
 He must only be defined from a required
interface to a provided interface
 An assembly connector is notated by a “ball-
and-socket” connection
This notation allows
for succint grafical
wiring of
components
 SEMANTICS

 The semantics for an assembly

connector :
 Are that signals travel along an instance of a
connector originating in a required port and
delivered to a provided port
 The interfaces provided and required must be
compatible
 The interface compatibility between provided
and required ports that are connected enables
an existing component in a system to be
replaced
 SEMANTICS
 Multiple connections directed from a single
required interface to provided interfaces indicates
that the instance that will handle the signal will be
determined at execution time
 DELEGATION
 DELEGATION CONNECTOR
 Links the external contract of a component to
the internal realization
 Represents the forwarding of signals
 He must only be defined between used
interfaces or ports of the same kind
 DELEGATION
 The target interface must support a signature
compatible with a subset of operations of the source
interface
 A port may delegate to a set of ports on subordinate
components
 The union of the target interfaces must be signature
compatible with the source interface
 Semantics:
 Is a declaration that behaviour that is available on a
component instance is not realized by that componen
itself, but by another instance that has compatible
capabilities
 Is used to model the hierarchical decomposition
 Message and signal flow will occur between the
CASE STUDY
CASE STUDY
 DEPLOYMENT DIAGRAMS
 There is a strong link between components diagrams
and deployment diagrams

 Deployment diagrams
 Show the physical relationship between
hardware and software in a system
 Hardware elements:
• Computers (clients, servers)
• Embedded processors
• Devices (sensors, peripherals)
 Are used to show the nodes where software
components reside in the run-time system
 DEPLOYMENT DIAGRAMS
 Deployment diagram
 Contains nodes and connections
 A node usually represent a piece of hardware
in the system
 A connection depicts the
communication path
used by the hardware to
communicate
 Usually indicates the
method such as TCP/IP
 DEPLOYMENT DIAGRAMS
 Deployment diagrams
contain artifact
 An artifact
 Is the specification of a
phisycal piece of
information
 Ex: source files, binary
executable files, table
in a database system,
….
 An artifact defined by
the user represents a
concrete element in
the physical world
 DEPLOYMENT DIAGRAMS
 An artifact manifest one or more model
elements
 A <<manifestation>> is the concrete physical
of one or more model elements by an artifact
 This
 A model element often is a component
manifestation is
notated as a dashed
line with an open
arrow-head labeled
with the keyword
<<manifest>>
DEPLOYMENT DIAGRAMS