Object-Oriented Analysis

& Design with UML

HERY HERYANTO
[email protected],
[email protected]

Overview
UML has become the de facto standard for
modeling object-oriented software. UML has been
adopted by companies throughout the world, and
today more than 50 commercial and academic
modeling tools support software and business
modeling using UML.
UML enables system developers to specify,
visualize, and document models in a manner that
supports scalability, security, and robust
execution. Because UML modeling raises the level
of abstraction throughout the analysis and design
process, it is easier to identify patterns of
behavior and thus define opportunities for

Objectives
1. Teaching the basic concepts and principles of Object
Orientation including Object Oriented Analysis and
Design.
2. Introducing the Syntax, Semantics and Pragmatics of
the Unified Modeling Language.
3. Showing how requirements can be described informally
and how they are modeled using Use Case Diagrams.
4. Teaching how the structural and behavioral aspects of
a system can be analyzed, specified and designed
using Class, Sequence and Activity Diagrams.

UML Modelling

Usecase Diagram

Usecase Diagram cont.

Actor: A role played by a person, system, device, or
even an enterprise, that has a stake in the successful
operation of the system.
Use case: Identifies a key behavior of the system.
Without this behavior, the system will not fulfill the
actor's requirements. Each use case expresses a goal
that the system must achieve and/or a result that it must
produce.
Association: Identifies an interaction between actors
and use cases. Each association becomes a dialog that
should be explained in a use case narrative. Each
narrative in turn provides a set of scenarios that can help
in the development of test cases when evaluating the
analysis, design, and implementation artifacts of the use

Usecase Diagram cont.

Include relationship: Identifies a reusable use case
that is unconditionally incorporated into the execution of
another use case. Responsibility for the decision about
when and why to use the included use case lies with the
calling use case.
Extend redlationship: Identifies a reusable use case
that conditionally interrupts the execution of another use
case to augment its functionality. The responsibility for
deciding when the extending use case should be used
lies with the extending use case.
Generalization: Identifies an inheritance relationship
between actors or between use cases.

Modeling Actors
In UML, the term actor refers to a type of user. Users, in the classic
sense, are people who use the system. But users may also be
other systems, devices, or even businesses that trade information.
In Use Case diagrams, people, systems, devices, and even
enterprises are all referred to as actors. The icons to model them
may vary, but the concept remains the same

Modeling Actors cont.

Any icon may be used to replace these. Picture below offers
some alternatives. A company logo might represent an
enterprise. A cartoon image might represent a device. A
graphic may be used to represent a system. Often, using
alternative icons in a modeling tool is as simple as importing
the graphics to a specific directory.

Include Relationship
To use the include relationship, the use cases must conform to
two constraints:
The calling use case may only depend on the result from the
called use case. It can have no knowledge of the internal structure
of the use case.
The calling use case must always require the execution of the
called use case. The use of the called use case is unconditional.

Extend Relationship
The extend relationship says that one use case might augment
the behavior of another use case. The extension use case provides
a discrete behavior that might need to insert itself into the base
use case. The arrow is drawn from the extension to the executing
use case. Drawing the arrow with the base at the extension use
case indicates that the extension, not the executing use case,
decides whether to impose itself on the executing use case. The
executing use case is unaware of the extension.

Use Case Narrative for SelectPerformance

Element
Use Case Name
Use Case Number
Author
Last Updated
Assumptions
Preconditions
Use Case Initiation
Use Case Dialog

Description
SelectPerformance
12
Jane Analyst and Joe Client
April 1, 2003
The actor has the appropriate authority to use this feature.
None.
This use case starts on demand.
The user should be given a default set of information about
the shows scheduled within the next 20 days. The user
should also be provided with all the events currently
scheduled at the venue.
When the user selects an event, the system should provide
the set of shows scheduled for that event (the event display
should remain unchanged).
When the user selects a show, the system should prompt him
for a confirmation of his selection in order to avoid mistakes.
The user should also be able to request a list of shows for a
date range and get a new list of shows (the event display
should remain unchanged).
The user may cancel out of this use case without making a
selection.
The selected show must be saved so that it can be passed on
to the next step in the workflow. One selected show is the net
output from this use case.

Use Case Narrative

Post conditions

Use Case Scenarios

Summary
Use case diagrams, together with use case narratives and
scenarios, define the goals of a system, or other classifier, such as
an enterprise, subsystem, or component. The purpose of the use
case approach is to focus the development effort on the essential
objectives of the system without getting lost in, or driven by,
particular implementations or practices.
The elements of a Use Case diagram include:
The Use Case diagram is complemented by the use case narrative
and use case scenarios.
Actors define entities outside the system that will use the system in
some way.
Associations indicate which actors will interact with features (use
cases) of the system.
include and extend relationships describe the nature of the
interactions between use cases.
Generalization defines inheritance relationships between use cases
or between actors.

The goal of the Use Case diagram is to define the expectations of

Exercises

Activity Diagram Overview

The Activity diagram is often seen as part of the functional

view of a system because it describes logical processes, or
functions. Each process describes a sequence of tasks and
the decisions that govern when and how they are
performed.
There are at least three places in a model where an Activity
diagram provides valuable insight:
Modeling workflow
Describing use cases
Specifying operations

An Activity diagram for one use case explains how the actor
interacts with the system to accomplish the goal of the use
case, including rules, information exchanged, decisions
made, and work products created.

Activity Diagram
Notation

MODELING ACTIVITIES AND ACTIONS

Activities and actions are the two fundamental units of behavior in
an Activity diagram. An activity is the highest-level unit of
behavior in an Activity diagram. An activity consists of a set of
ActivityNodes and ActivityEdges (connectors).

Activity Diagram
Notation

MODELING INITIAL AND ACTIVITY FINAL NODES

A sequence of actions has a beginning and an end. The Activity
diagram defines two ControlNodes: InitialNode, to designate the
starting point in a sequence, and ActivityFinalNode, to designate
the end of a sequence.

Activity Diagram
Notation

MODELING ACTIVITY EDGES

Modeling control flow requires a means to illustrate the movement
from one action to the next. The Activity diagram provides two
types of ActivityEdge to model flow from one action to the next: a
ControlFlow and an ObjectFlow,

Activity Diagram
Notation

MODELING DECISION AND MERGE POINTS

The ControlNode subclass DecisionNode provides the means to
specify a point at which the logic must choose between a set of
mutually exclusive alternatives. A decision node may have only
one incoming activity edge . It may have two or more outgoing
activity edges.

Activity Diagram
Notation

MODELING DECISION AND MERGE POINTS

The MergeNode provides a point where a flow of control can return
to an existing activity edge to take advantage of the existing flow
of control from that point forward. Picture below adds a merge
node so that once a user makes one of the provided choices, he is
returned to the same initial decision point.

Activity Diagram
Notation

MODELING FORK AND JOIN NODES FOR CONCURRENCY

An Activity diagram may model a process in which parallel
processing is available. In fact, any logic sequence that does not
require a specific sequence may potentially be executed in
parallel. The Activity diagram uses fork and join notation to model
parallel, or concurrent, processes or threads. Note the change
from UML 1.4, which called both the fork and join notation
"synchronization bars.
A ForkNode is represented as a bar with one incoming activity
edge and two or more outgoing activity edges. The incoming edge
is split into multiple outgoing edges that may execute in any
order, including simultaneously. Any data passed along the
incoming edge is duplicated and a copy is passed along each
outgoing activity edge.
A JoinNode is represented as a bar with two or more incoming

Activity Diagram
Notation

MODELING OBJECT NODES AND OBJECT FLOWS

A flow of control includes two types of flows (activity edges):
ControlFlow, discussed earlier in the "Modeling activity edges"
section, and ObjectFlow. An ObjectFlow supports passing data
(tokens) from one action to another. The data is contained within
an ObjectNode.

Activity Diagram
Notation

MODELING ACTION INPUT AND OUTPUT PINS

Actions are behaviors that work with data. Actions create,

transform, and delete data, and in doing so, they may pass
data produced by one action as input to another action.
This process is reminiscent of the classic input-processoutput pattern of functional modeling.
Input and output may be explicitly modeled using InputPins
and OutputPins. Pins are object nodes that contain values.
The pin concept is borrowed from Action Semantics. Each
input pin receives a single value. Input pins correspond to
the parameters passed to an invocation action. As such, the
model assumes that the pins are ordered just as the
parameters are ordered. Also, because of this pairing
relationship, the pins must be of the same data type as the
corresponding parameters.

Summary
The UML 1.4 Activity diagram is the UML version of the
classic flowchart. It may be applied to any process, large or
small. Three common applications of Activity diagrams are
to explain workflow (a series of Use cases), to explain a
single use case, and to explain a method.
The UML 2.0 specification includes the concepts defined in
UML 1.4 but refines the metamodel to separate the
concepts from the state machine metamodel and to refine
and clarify the concepts for an Activity diagram. UML 2.0
has also added new concepts to address limitations that no
longer exist now that the Activity diagram metamodel is
distinct form the State Machine diagram metamodel. The
new concepts include pins, flow final nodes, combining
decision and merge nodes, buffers and data stores,
streaming parameters, and interruptible regions (explain in

Exercises

Class Diagram Overview

The Class diagram stands at the center of the objectmodeling process. It is the primary diagram for capturing all
the rules that govern the definition and use of objects. As
the repository for all the rules it is also the primary source
for forward engineering (turning a model into code), and
the target for reverse engineering (turning code into a
model).

The next picture shows all of the UML diagrams, with the
Class diagram at the center. It illustrates that even though
each of the other diagrams help modelers discover valuable
information about a subject, everything they uncover must
somehow make its way onto the Class diagram.

Class Diagram Modelling a

Class

A class is very much like a dictionary entry. If our theater

application has to manipulate information about events,
then we first need to explain what we mean by the term
event using a class definition. A UML Class definition
describes a type of object.
One class definition describes many objects of the same
type. Each class definition contains at least a unique name.
This name defines the class in the repository so that any
time the same name is referenced it is associated with the
same repository definition. A class can also contain
attributes and operations that describe everything
necessary to create (instantiate) an object of the defined
type.

Class Diagram Modelling

Visibility

Visibility is applied to both attributes and operations in a

class. Since this concept applies equally to attributes and
operations, I'll cover the concept here, and then demonstrate
how to apply it in the descriptions of attributes and
operations that follow.
Visibility refers to the scope of access allowed for a member
of a class. Scope refers to specific regions within the total
system. UML visibility or access levels map to similar visibility
designations in most OO programming languages as follows:
Private scope: Within a class
Package scope: Within the same package
Public scope: Within a system
Protected scope: Within an inheritance tree

Class Diagram Modelling

Multiplicity

Multiplicity, like visibility is a concept used with a number

of UML model elements, most notably with attributes and
associations. Multiplicity specifies the number of values that
may be associated with a model element.
Multiplicity is modeled as a value expression. When
multiplicity is used in a text string like an attribute, the
value expression is enclosed within square brackets ([]).
When multiplicity is used to adorn a diagram notation like
an association, it has no enclosing brackets. Multiplicity can
express a range of values, a specific value, a range without
limit, or a set of discrete values.

Class Diagram Modelling an

Association

Modeling an association begins by identifying the

participating classes. The first examples we'll discuss use a
pair of classes, called a binary association, since this is the
most common type of association. We'll cover associations
that use more than two participating classes, called n-ary
associations, later in the chapter.

Class Diagram Modelling

Aggregation

Aggregation describes a special type of association

designed to help us cope with complexity. In a typical
association the participating classes are peers. Each class
remains independent of the other and neither class is
superior to the other. They simply communicate.
Aggregation, on the other hand, defines a definite
hierarchical relationship. It defines an assembly or
configuration of elements to make a larger more complex
unit. The saying "The whole is greater than the sum of the
parts" is true with aggregation.

Class Diagram Generalization &

Dependency

Generalization is the process of organizing the properties

of a set of objects that share the same purpose. You might
also hear this type of relationship called inheritance. Many
times the terms generalization and inheritance are used
synonymously.

Dependency represents a client-supplier relationship in

which a change to the supplier requires a change to the
client. UML predefines four general types of dependency:
abstraction, binding, permission, and usage. These four
general types are refined into more specific types.

Summary

Regardless of the complexity, class diagram and

each association has to define its own rules to
establish and maintain the integrity of the
relationship. Together, these rules define how the
objects in an application can come into contact
and collaborate with one another.

The simplicity of the Class diagram can be a bit

deceiving. The Class diagram can be used to
model a surprisingly wide variety of systems, such
as airplane navigation, monthly invoicing, real-time
embedded devices such as medical equipment,
and human-machine interface systems used to
automate factories.

Exercises

Sequence Diagram

Tools

References
1. Pender, Tom, UML Bible, John Wiley and Sons,
Indianapolis, 2003
2. Ojo, Adegboyega and Estevez, Elva, ObjectOriented Analysis and Design with UML
Training Course, eMacao Team, Oktober 2005
3. Bigelow, Daniel, Modeling >> UML,
Ostermundigen, Switzerland, 2009 diakses pada
September 2011 di halaman web
http://www.bigelow.ch/Modeling/Modeling.aspx