Oose 2

Activity # 3: Modeling with UML
Overview of UML
Building Blocks of the UML
 Things in the UML
 Relationships in the UML
 Diagrams in the UML
Learning Outcomes
• At the end of this activity, you will be able to define and

understand:
– Modeling and its benefits
– Different types of models
– Basics of unified modeling Language and its modeling
diagrams
Compiled By: Modeling with UML 2

Overview of the UML
• UML is a standard language for specifying, visualizing,

constructing, and documenting the artifacts of software
systems.
• UML was created by Object Management Group and UML
1.0 specification draft was proposed to the OMG in January
1997.
• The Unified Modeling Language (UML) is a general-
purpose, developmental, modeling language in the field of
software engineering, that is intended to provide a standard
way to visualize the design of a system

• UML is a language that we use to model a reality. UML is a
language for
– Visualizing
– Specifying
– Constructing
– Documenting the artifacts of a software system.

• UML as a Language for Visualizing - The vision for the system
being developed can be easily communicated through UML
and thus the software team has a unified vision of a system
that is only described in specification and requirement
documents.
– A picture is worth a thousand words; a graphical
notation articulates and unambiguously communicates
the overall view of the system (problem domain).
• UML as a Language for Specifying - the structure or behavior
of a system can be described with UML.
– i.e , UML provides the means to model precisely, unambiguously
and completely.

• UML as a Language for Constructing - UML’s models can be
directly connected or converted to a variety of programming
languages like C++, Java, or Visual Basic with no ambiguity. This
facilitates forward engineering.
– Models built with UML have a “design” dimension to it; these are
language independent and can be implemented in any programming
language.
• UML as a Language for Documenting - UML provides a language
for expressing requirements, tests, activities of project planning
and release management. Some of the artifacts that may need to
be documented are: Requirements, Architecture, Design, Source
Code, Project Plan, Tests, Prototypes, and Releases.
– Every software project involves a lot of documentation

Why do we model software?
• A model is a simplification of reality.

• Software is getting increasingly more complex
– Windows XP > 40 mio lines of code
– A single programmer cannot manage this amount of
code in its entirety.
• Code is not easily understandable by developers who did
not write it
• We need simpler representations for complex systems
– Modeling is a mean for dealing with complexity
• We build models so that we can better understand
the system we are developing
• Benefits:
– 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.
– Provide structure for problem solving
– Experiment to explore multiple solutions
– Furnish abstractions to manage complexity
– Reduce time-to-market for business problem solutions
– Decrease development costs
– Manage the risk of mistakes

Why is UML important?
• From the point of view of the construction trade.
Architects design buildings. Builders use the designs to
create buildings. The more complicated the building, the
more critical the communication between architect and
builder. Blueprints are the standard graphical language that
both architects and builders must learn as part of their
trade.
• Writing software is not unlike constructing a building.
The more complicated the underlying system, the more
critical the communication among everyone involved in
creating and deploying the software.

• In the past decade, the UML has emerged as the software blueprint
language for analysts, designers, and programmers alike. It is now part of
the software trade.
• The UML gives everyone from business analyst to designer to programmer
a common vocabulary to talk about software design.
• The UML is applicable to object-oriented problem solving. Anyone
interested in learning UML must be familiar with the underlying tenet of
object-oriented problem solving -- it all begins with the construction of a model.
• A model is an abstraction of the underlying problem. The domain is the actual
world from which the problem comes.
• Models consist of objects that interact by sending each other messages.
Think of an object as "alive." Objects have things they know (attributes) and
things they can do (behaviors or operations).
• The values of an object's attributes determine its state. Classes are the
"blueprints" for objects. A class wraps attributes (data) and behaviors
(methods or functions) into a single distinct entity. Objects are instances of
classes.

Where can the UML be used?
• It has been used effectively for software intensive
domains such as –
1) Enterprise information systems
2) Banking and financial services
3) Telecommunications
4) Transportation
5) Defense / aerospace
6) Medical electronics
7) Distributed web-based services

UML Modeling
• However, most of the software projects developed around the
globe do not follow any specific modeling technique to avoid
the perceived risk and complexity in Object Oriented modeling
of large systems.
• The semantics defined in the language are based on the
software systems; they do not have complete support for
systems of other domains
• Moreover, the UML is still incomplete in its support for
components. While modeling software is useful, it will not solve
all design issues.
• Smart people and a good methodology are a must. But if used
correctly, UML and the modeling process can help improve
quality, completeness, and scalability and reduce production time in
many software projects.
• UML (Unified Modeling Language)
– An emerging standard for modeling object-oriented
software.
– Resulted from the convergence of notations from
three leading object-oriented methods:
• OMT (James Rumbaugh)
• OOSE (Ivar Jacobson)
• OOD (Grady Booch)
– The Unified Modeling Language (UML) is one of the most
exciting and useful tools in the world of system
development.

• Modeling consists of building an abstraction of reality.
• Abstractions are simplifications because:
– They ignore irrelevant details and
– They only represent the relevant details.
• What is relevant or irrelevant depends on the purpose
of the model.

Conceptual Model of UML
• To understand conceptual model of UML first we need
to clarify What is a conceptual model? and Why a
conceptual model is at all required?
– A conceptual model can be defined as a model which is
made of concepts and their relationships.
– A conceptual model is the first step before drawing a
UML diagram. It helps to understand the entities in the real
world and how they interact with each other.
• The building blocks of UML can be defined as:
– Things
– Relationships
– Diagrams

Building Blocks of the UML
• The vocabulary of the UML encompasses three kinds of
building blocks:
1) Things
2) Relationships
3) Diagrams
• Things are the abstractions that are first-class citizens in a

model
• Relationships tie these things together
• Diagrams group interesting collections of things.

Things in the UML
• There are four kinds of things in the UML:

a) Structural things (static parts)
b) Behavioral things (dynamic parts)
c) Grouping things (Organizational parts of a model)
d) Annotational things (Explanatory parts of a model)

a) Structural Things
• Structural things are the nouns of the UML models. These are
mostly static parts of the model, representing conceptual or
physical elements.
• Structural things are called classifiers.
• Structural thing include classes, interfaces, collaborations, use
cases, components, and nodes.
• A class
– is a description of a set of objects that share the same
attributes, operations, relationships, and semantics.
– A class implements one or more interfaces. Graphically, a
class is rendered as a rectangle, usually including its name,
attributes, and operations

Class represents set of objects having similar responsibilities.

• Interface
– Interface defines a set of operations which specify the
responsibility of a class. Or
– is a collection of operations that specify a service of a class
or component.

• Collaboration:
– Collaboration defines interaction between elements.
– A given class or object might participate in several
collaborations
• A use case
– It’s a description of sequences of actions that a system
performs that yield observable results of value to a
particular actor.
– A use case is used to structure the behavioral things in a
model.

• Component
– Component describes physical part of a system.
– is a modular part of the system design that hides its
implementation behind a set of external interfaces.

• Node
– A node can be defined as a physical element that exists at
run time and represents a computational resource, generally
having at least some memory and, often, processing
capability.
– Examples: a server, network etc
– Graphically, a node is rendered as a cube, usually including
only its name as shown in the following figure

b) Behavioral Things
• Behavioral things are the dynamic parts of UML models.

• These are the verbs of a model , representing behavior over
time and space.
• There are three primary kinds of behavioral things:
– an interaction
– a state machine
– an activity
• An interaction is used to represent communication among the
components of a system.
• Interaction is basically message exchange between two UML
components.

• An interaction is a behavior that comprises a set of
messages exchanged among a set of objects or roles
within a particular context to accomplish a specific
purpose.
• Graphically, a message is rendered as a directed line,
including the name of its operation as shown below

• State machine describes the different states of a component in
its life cycle.
• The behavior of an individual class or a collaboration of classes
may be specified with a state machine.
• Graphically, a state is rendered as a rounded rectangle, usually
including its name and its substates
• A State machine is used to describe different states of a system

component.
• The state can be active, idle or any other depending upon the
situation.

• An activity is a behavior that specifies the sequence of
steps a computational process performs.
• In an interaction, the focus is on the set of objects that
interact.
• In a state machine, the focus is on the life cycle of one
object at a time.
• In an activity, the focus is on the flows among steps
without regard to which object performs each step.

c) Grouping Things
• Organizing the UML models are one of the most important

aspects of the design.
• Grouping things are the organizational parts of UML models.
• In UML there is only one element available for grouping and
that is package.
• Package
– A package is a general purpose mechanism for
organizing elements into groups. Structural things,
behavioral things, and even other grouping things may be
placed in a package.
– The packages are used to wrap the components of a system.

• Graphically a package is rendered as a tabbed folder,
usually including only its name and sometimes, its
contents.

d) Annotational things
• Annotational things are the explanatory parts of UML models.
• These are the comments you may apply to describe, illuminate,
and remark about any element in a model.
• There is one primary kind of annotational thing called a note.
• A note is simply a symbol for rendering constraints and
comments attached to an element or a collection of
elements
• Graphically, a note is rendered as a rectangle with a dog-eared
corner, together with a textual or graphical comment. It may be
anchored to an element with a dashed line.
The schedule can
MaintainSchedule be update

Relationships in the UML
• Objects do not exist in isolation, they exist in relationship to other
objects
• There are four kinds of relationships in the UML:
i. Dependency
ii. Associations
• Association
• Aggregation (special type of association)
• Composition(special type aggregation)
iii. Generalization
iv. Realization
• These relationships are the basic relational building blocks of the
UML.
• You use them to write well-formed models.

• Dependency relationship
– Dependency is an important aspect in UML elements. It
describes the dependent elements and the direction of
dependency.
– Dependency is a semantic relationship where a change in
one thing (the independent thing) causes a change in the
semantics of the other thing (the dependent thing).
Client class depends on the Supplier class.

– The notation used for dependency is a dashed line with an
arrowhead.
– The arrow head represents the independent element and
the other end the dependent element.
– Weakest class association. If something changes in

meeting then this would affect schedule but the reverse is
not true

Associations relation ships
• Association
– An association is a structural relationship that specifies
how objects (instances of classes) are connected to
other objects.
• describes how the elements in an UML diagrams are
associated.
– In simple word it describes how many elements are
taking part in an interaction.
– Association is represented by a line with (without)
arrows on both sides.

We can also indicate the behavior of an object in an
association (i.e., the role of an object) using role names.

• For example, as shown below, a Course Offering object
may have either zero or one Professor object related to it,
and conversely a Professor object may have zero or more
Course Offering objects related to it.

• Aggregation
– Aggregation indicates a relationship between a whole and its
parts
– Aggregation is a special kind of association, representing a
structural relationship between a whole and its parts.
– Has-a relationship
– The part can exist separately from the whole

• Composition
– Strong form of aggregation where the part can not exist
separately from the whole
– That means the construction and destruction of the part
depend on the whole
– A department is part of a company. The construction and

destruction of a department depends on the company
Generalization
• Generalization describes the inheritance relationship of the

object oriented world. It is parent and child relationship.
• A generalization is a specialization/generalization relationship in
which the specialized element (the child) builds on the
specification of the generalized element (the parent).
• Is -a kind-of relationship
• Relationship between a general thing and a more specific kind
of that thing (i.e super class and subclass)
• A child inherits + reuses the non private parent classes
attributes and operations.
• The child can have additional attributes and operation of its
own

Realization
• Realization can be defined as a relationship in which two
elements are connected.
• One element describes some responsibility which is not
implemented and the other one implements them.
• You'll encounter realization relationships in two places:
– between interfaces and the classes or components that
realize them,
– and between use cases and the collaborations that realize
them.
• Graphically, a realization relationship is rendered as a cross
between a generalization and a dependency relationship

Multiplicity
• Multiplicity is a definition of cardinality - i.e. number of
elements - of some collection of elements by providing an
inclusive interval of non-negative integers to specify the
allowable number of instances of described element.
Multiplicity interval has some lower bound and (possibly
infinite) upper bound
• Multiplicity allows us to specify how many objects are
participating in relationships
• It is the number of instances of one class that relate to one
instance of another class. For each association, there are two
multiplicity decisions to make, one for each end of the
association.
– How many objects are associated

As shown above, House has exactly one kitchen, one bath and one
bedroom
 kitchen, bath and bedroom exist only if the house exist(composition)
 All kitchen, bath and bedroom are rooms(inheritance)

UML Diagrams
• Use case Diagrams
– Describe the functional behavior of the system as seen by the
user.
• Class diagrams
– Describe the static structure of the system: Objects, Attributes,
Associations
• Sequence diagrams
– Describe the dynamic behavior between actors and the system
and between objects of the system
• Statechart diagrams
– Describe the dynamic behavior of an individual object
(essentially a finite state automaton)
• Activity Diagrams
– Model the dynamic behavior of a system, in particular the
workflow (essentially a flowchart)

UML : Use case diagrams

UML: Use case diagrams
Package Use case
Watch
Actor
ReadTime
SetTime
WatchUser WatchRepairPerson
ChangeBattery
Use case diagrams represent the functionality of the system

from user’s point of view
UML: Class diagrams
Class diagrams represent the structure of the system
Association
Class
Multiplicity Watch
1 1 1 1
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load now
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
referesh()
Attribute
Operations

UML: Sequence diagram
Actor Object
:Watch :LCDDisplay :Time

:WatchUser
pressButton1() blinkHours()
pressButton1() blinkMinutes()
Message pressButton2() incrementMinutes()

refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()
Activation
Lifeline
Sequence diagrams represent the behavior as interactions

UML provide other notations
Implementation diagrams
– Component diagrams
– Deployment diagrams

Use Case Diagrams
• Used during requirements
elicitation to represent external
behavior
• Actors represent roles, that is, a
Passenger
type of user of the system
• Use cases represent a sequence
of interaction for a type of
functionality
PurchaseTicket • The use case model is the set of
all use cases. It is a complete
description of the functionality of
the system and its environment

Actors
• An actor models an external entity which
communicates with the system:
– User
– External system
– Physical environment
• An actor has a unique name and an optional
Passenger
description.
• Examples:
– Passenger: A person in the train
– GPS satellite: Provides the system with GPS
coordinates

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
PurchaseTicket • Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements

Use Case Diagram: Example
Name: Purchase ticket Event flow:
1. Passenger selects the number of
Participating actor: Passenger zones to be traveled.
2. Distributor displays the amount
Entry condition: due.
• Passenger standing in front of 3. Passenger inserts money, of at
ticket distributor. least the amount due.
• Passenger has sufficient money to 4. Distributor returns change.
purchase ticket. 5. Distributor issues ticket.
Exit condition:
• Passenger has ticket.
Anything missing ?
Exceptional cases!
The <<extends>> Relationship
• <<extends>> relationships represent
exceptional or seldom invoked cases.
• The exceptional event flows are factored
Passenger
out of the main event flow for clarity.
• Use cases representing exceptional
flows can extend more than one use
case.
PurchaseTicket
• The direction of a <<extends>>
<<extends>>
relationship is to the extended use case
<<extends>>
<<extends>>
OutOfOrder <<extends>> TimeOut
Cancel NoChange
The <<includes>> Relationship
• <<includes>> relationship
represents behavior that is
Passenger factored out of the use case.
• <<includes>> behavior is factored
out for reuse, not because it is an
PurchaseMultiCard exception.
PurchaseSingleTicket • The direction of a <<includes>>
<<includes>> relationship is to the using use
<<includes>> case (unlike <<extends>>
relationships).
CollectMoney
<<extends>> <<extends>>
NoChange Cancel
Class Diagrams
TarifSchedule
Trip
Enumeration getZones() zone:Zone
* *
Price getPrice(Zone) Price: Price
• Class diagrams represent the structure of the system.

• Used
– during requirements analysis to model problem domain
concepts
– during system design to model subsystems and interfaces
– during object design to model classes.

Oose 2

Uploaded by

Copyright:

Available Formats

Oose 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oose 2

Uploaded by

Copyright:

Available Formats

Activity # 3: Modeling with UML

• At the end of this activity, you will be able to define and

Compiled By: Modeling with UML 2

• UML is a standard language for specifying, visualizing,

Compiled By: Modeling with UML 3

Compiled By: Modeling with UML 4

Compiled By: Modeling with UML 5

Compiled By: Modeling with UML 6

• A model is a simplification of reality.

Compiled By: Modeling with UML 8

Compiled By: Modeling with UML 9

Compiled By: Modeling with UML 10

Compiled By: Modeling with UML 11

Compiled By: Modeling with UML 13

Compiled By: Modeling with UML 14

Compiled By: Modeling with UML 15

• Things are the abstractions that are first-class citizens in a

Compiled By: Modeling with UML 16

• There are four kinds of things in the UML:

Compiled By: Modeling with UML 18

Compiled By: Modeling with UML 19

Compiled By: Modeling with UML 20

Compiled By: Modeling with UML 21

Compiled By: Modeling with UML 22

Compiled By: Modeling with UML 23

Compiled By: Modeling with UML 24

• Behavioral things are the dynamic parts of UML models.

Compiled By: Modeling with UML 25

Compiled By: Modeling with UML 26

• A State machine is used to describe different states of a system

Compiled By: Modeling with UML 27

Compiled By: Modeling with UML 28

• Organizing the UML models are one of the most important

Compiled By: Modeling with UML 29

Compiled By: Modeling with UML 30

Compiled By: Modeling with UML 31

Compiled By: Modeling with UML 32

Client class depends on the Supplier class.

– Weakest class association. If something changes in

Compiled By: Modeling with UML 34

Compiled By: Modeling with UML 35

Compiled By: Modeling with UML 36

Compiled By: Modeling with UML 37

Compiled By: Modeling with UML 38

– A department is part of a company. The construction and

• Generalization describes the inheritance relationship of the

Compiled By: Modeling with UML 40

Compiled By: Modeling with UML 42

Compiled By: Modeling with UML 43

Compiled By: Modeling with UML 45

Compiled By: Modeling with UML 46

Compiled By: Modeling with UML 47

Use case diagrams represent the functionality of the system

Compiled By: Modeling with UML 49

:Watch :LCDDisplay :Time

Message pressButton2() incrementMinutes()

Sequence diagrams represent the behavior as interactions

Compiled By: Modeling with UML 51