CUIT 214 / CUIEE 201:
SOFTWARE ENGINEERING
OBJECT ORIENTED ANALYSIS AND DESIGN 2
MS CHIMHENO
rchimheno@cut.ac.zw
Office: E12
STRUCTURAL MODELS
Structural models of software display the organization of
a system in terms of the components that make up that
system and their relationships.
They may be static models, which show the structure of
the system design or dynamic models, which show the
organization of the system when it is executing.
Class diagrams can be used to model the static structure
of the object classes in a software system.
INTERACTION MODELS
All systems involve interaction of some kind.
This can be user interaction, which involves user inputs
and outputs, interaction between the system being
developed and other systems or interaction between the
components of the system
INTERACTION MODELS
Modeling user interaction is important as it helps to
identify user requirements.
Modeling system interaction highlights the
communication problems that may arise.
Modeling component interaction helps us understand if a
proposed system structure is likely to deliver the required
system performance and dependability.
TWO APPROACHES CAN BE USED
Use case modeling, which is mostly used to model
interactions between a system and external actors (users or
other systems).
Sequence diagrams, which are used to model interactions
between system components, although external agents may
also be included.
Use case models and sequence diagrams present
interaction at different levels and so may be used together.
MODELING DYNAMIC ASPECTS OF SYSTEMS
Interaction diagrams: set of objects and their relationships
including messages that may be dispatched among them
Sequence diagrams: time ordering of messages
Collaboration diagrams: structural organization of objects that
send and receive messages
Activity diagram: flow chart showing flow of control from
activity to activity
Statechart diagram: models a state machine
SEQUENCE DIAGRAMS
SEQUENCE DIAGRAMS
Sequence models show the sequence of object interactions
that take place
Objects are arranged horizontally across the top;
Time is represented vertically so models are read top to bottom;
Interactions are represented by labelled arrows, Different styles
of arrow represent different types of interaction;
A thin rectangle in an object lifeline represents the time when
the object is the controlling object in the system.
INTERACTION SHOWN ON A SEQUENCE DIAGRAM
INTERACTION SHOWN ON A SEQUENCE DIAGRAM
The vertical dimension of a sequence diagram represents time
The horizontal dimension represents the different objects or
roles that participate in the interactive sequence.
An object’s lifeline is shown as a narrow vertical bar.
Time is assumed to pass as we move from top to bottom of the
diagram.
Messages between objects are shown as solid line arrows, and
their returns are shown as dashed line arrows.
MESSAGES FROM AN OBJECT TO ITSELF
An object may, and frequently does, send a message to itself
On a sequence diagram, you show a message arrow from the
object’s lifeline back to itself.
You might choose to omit messages from an object to itself,
counting such things as internal computation within the object.
STATE DIAGRAM
STATE DIAGRAMS
State diagrams are used to show how objects respond to different
service requests and the state transitions triggered by these
requests.
State diagrams are useful high-level models of a system or an
object’s run-time behavior.
You don’t usually need a state diagram for all of the objects in the
system.
Many of the objects in a system are relatively simple and a state
model adds unnecessary detail to the design.
WHEN TO USE STATE DIAGRAMS
When you want to describe the behavior of one object for all (or
at least many) scenarios that affect that object
Not good at showing the interaction between objects. Use
interaction diagrams or activity diagrams
Do not use them for all classes
 Some methods prescribe this
 Very time consuming and questionable benefit
STATE DIAGRAMS
Let us start with a very simple example
in which an object receives a message and what it does depends on the
values of its attributes and links.
In our library system an object of class Copy may have a Boolean
attribute onShelf
which is intended to record whether the object describes a copy of a book
which is currently in the library,
or one which is currently on loan.
The interface of a class Copy specifies that the object should be willing
to accept the message borrow().
STATE DIAGRAM OF CLASS COPY
The value of the copy’s attribute onShelf is important for
understanding the behaviour of the object,
We can name two significantly different states of a Copy object
 “on the shelf” and “on loan”
We can record the messages that cause it to move between the
states as the events that cause transition between states.
STATE, TRANSITIONS, EVENTS
The most important elements of a state diagram, namely:
States: Shown as boxes with rounded corners
Transitions between states: Shown as arrows
Events that cause transitions between states: Shown by writing the
message on the transition arrow
Start marker: Shown as a black blob with an (unlabeled) arrow into the
initial state of the diagram
Stop marker: Shown by a black blob with a ring round it and means that
the object has reached the end of its life.
ACTIVITY DIAGRAM
Activity diagrams describe how activities are coordinated.
 For example, an activity diagram may be used to show how an operation
could be implemented
An activity diagram is particularly useful
 when you know that an operation has to achieve a number of different
things, and
 you want to model what the essential dependencies between them are,
before you decide in what order to do them
ACTIVITY DIAGRAM
Activity diagrams are state diagrams extended for convenience
with some extra notation
Elements of activity diagrams
 Activity
 Transition
 Synchronization bar
 Decision diamond
 Start and stop markers
BUSINESS LEVEL ACTIVITY DIAGRAM OF THE LIBRARY
EXAMPLE
UML NOTATION
Library item
Catalogue n umber
Acquisition date
Cost
Type
Status
Number of copies
EXAMPLE (CONT..)
Acquire ()
Catalogue ()
Dispose ()
Issue ()
Return ()
Published item
Recorded item
Title
Medium
Title
Publisher
Book
Author
Edition
Publication date
ISBN
Magazine
Year
Issue
Film
Dir ector
Date of release
Distributor
Computer
program
Version
Platfo rm
MULTIPLE INHERITANCE
Rather than inheriting the attributes and services from a single
parent class, a system which supports multiple inheritance
allows object classes to inherit from several super-classes.
This can lead to semantic conflicts where attributes/services
with the same name in different super-classes have different
semantics.
Multiple inheritance makes class hierarchy reorganisation
more complex.
MULTIPLE INHERITANCE
Book
Voice recording
Author
Edition
Publication date
I SBN
Speak er
Dur ation
Recording date
Talking book
# Tapes
BEHAVIOURAL MODELS
Behavioural models are used to describe the overall behaviour of a
system
They are models of the dynamic behavior of the system as it is
executing.
They show what happens or what is supposed to happen when a
system responds to a stimulus from its environment.
These stimuli are of two types:
Data Some data arrives that has to be processed by the system.
Events Some event happens that triggers system processing.
Events may have associated data but this is not always the case
.
SEMANTIC DATA MODELS
Used to describe the logical structure of data processed
by the system
Entity-relation-attribute model sets out the entities in the
system, the relationships between these entities and the
entity attributes
Widely used in database design. Can readily be
implemented using relational databases
No specific notation provided in the UML but objects and
associations can be used
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY
SUMMARY