DESIGN TOOLS AND TECHNIQUES

LECTURE 6

(YEAR 3 SEMESTER 1)

UNIVERSITY OF MINES AND TECHNOLOGY, TARKWA UMaT

 LECTURE OBJECTIVES

Describing ELH notation.

Constructing an ELH from a given example.
Explaining the use of state indicators in
ELH.
Identifying the various components of
UML.
Appreciate the usefulness of UML
especially in object-oriented designs
 MODELING LANGUAGE
A modeling language is any artificial language that makes
use of a consistent set of rules that are used to express
information or knowledge or systems in a structure.
A modeling language can be graphical or textual. Some
are used mainly to describe a designs structural
organization, others to represent software behavior.
They are categorized for describing the structural (static)
view and the behavioral (dynamic) view.

Structural Description (Static View)

Mostly (but not always) graphical, describe and represent
the structural aspects of a software design - that is, they
describe the major components and how they are
interconnected (static view):
 STRUCTURAL DESCRIPTIONS (STATIC VIEW)

Architecture description languages (ADLs): textual, often

formal, languages used to describe software architecture in
terms of components and connectors.
Class and object diagrams: Represent a set of classes (and
objects) and their interrelationships.
Component diagrams: Represent a set of components
(physical and replaceable part[s] of a system that
[conform] to and [provide] the realization of a set of
interfaces) and their interrelationships.
Class responsibility collaborator cards (CRCs): Denote
the names of components (class), their responsibilities, and
their collaborating components names.
Deployment diagrams: Represent a set of (physical) nodes
and their interrelationships, and, thus, to model the
 STRUCTURAL DESCRIPTIONS (STATIC VIEW)

Entity-relationship diagrams (ERDs): Represent

conceptual models of data stored in information
systems.
Interface description languages (IDLs):
programming-like languages used to define the
interfaces (names and types of exported
operations) of software components.
Jackson structure diagrams: used to describe
the data structures in terms of sequence,
selection, and iteration.
Structure charts: used to describe the calling
structure of programs (which module calls, and is
 JACKSON STRUCTURE DIAGRAMS (JSD)
Jackson structure diagrams: used to describe data
structures in terms of sequence, selection, and iteration.
Three basic principles of operation of JSD are that:
Development starts with describing and modeling the real
world, rather than specifying or structuring the function
performed by the system. A JSD system performs the
simulation of the real world before any direct attention is
paid to function or purpose of the system.
An adequate model of a time-ordered world must itself
be time-ordered. Main aim is to map progress in the real
world on progress in the system that models it.
The way of implementing the system is based on
transformation of specification into efficient set of
processes. These processes should be designed in such a
 ENTITY LIFE HISTORIES (ELHS)
Entity life histories are diagrammatic methods used to describe
what happens to an entity over time. They describe the events
that can happen to an entity from creation to deletion. For
example, if you had an entity PUPIL in which you stored all the
details of pupils at a school, the kinds of the things that could
happen to the table of records include:
a record could be added. (when a pupil joins the school)
a record could be deleted. (when a pupil leaves the school)
a record could be amended (when a pupil changes address, for
example).
Jackson structures provide three basic constructs: sequence,
selection and iteration (plus the quit / admit).
EVENTS - An event is something that happens in the
real/outside world to cause a change of state to an
entity/database. The 'trigger' that causes the event to occur
may be as a result of three things namely, externally generated,
 ENTITY LIFE HISTORIES
(ELHS)
EFFECTS - Particular set of changes caused within an entity by
an event is called an effect. The change within a single entity,
i.e. creation, update or delete caused by an event is called an
effect. An event creates, modifies, or deletes an occurrence of
one or more entity types. These effects can be in
straightforward sequence, or they may involve iteration,
selection and parallelism.

NOTATION - The drawing of ELHs takes place when the

requirements specification is almost complete and when all
entities of the system have been identified and most of the
events which affect these entities are clearly established. ELH
notation is based on the main structured principle that states
that any programming activity can be described using only the
three basic constructs of sequence, selection and iteration. An
ELH consists of a set of connected boxes. A single box
 ENTITY LIFE HISTORIES (ELHS)
SEQUENCE - Activities are undertaken in strict sequence,
from left to right (for example, an account must be
opened before any other event that will affect it can
occur, and account closure must occur before account
deletion). The thing that is expected to happen first is
positioned to the left, and at the same height, as the thing
that is expected to follow.
For example, if a team of analysts has decided that three
events, A, B, and C, are to affect an entity in that order,
then these events are shown on the ELH as follows:
 ENTITY LIFE HISTORIES (ELHS)
SELECTION - Often, a choice exists between alternatives
that can affect an entity. This choice is shown on separate
branches of the structure. Note that one, and only one,
of two or more possible events will occur at a particular
time in a sequence. To represent a choice between a
number of alternative events, mark the events with a
small "o" (for option) on the upper right hand corner.
 ENTITY LIFE HISTORIES (ELHS)
ITERATION - Events that occur many times for each
particular occurrence of an entity are represented on the
diagram with boxes containing asterisk. If an event is
repeated, place a small asterisk (*) in its upper right hand
corner. All events under a single node must be of the
same type. In other words, don't mix and match iteration,
selection, and sequence event notations.
 ENTITY LIFE HISTORIES (ELHS)
Parallel Structures - Sometimes an event occurs that
does not change the status, as far as the system being
considered is concerned, of an occurrence. To illustrate an
event that has no major effect on the system, such as a
change of an address for an employee, use a parallel bar
to note this exception to the system's normal life. The ELH
notation accommodates these situations by introducing a
parallel structure, depicted on the diagram with a parallel
bar, placing the exception to the right.
 ENTITY LIFE HISTORIES (ELHS)
Quit and Resume - Sometimes extraordinary events occur and
disrupt the expected life pattern of an entity. Attempts to anticipate
those events on an ELH may lead to a complicated diagram that
obscures the normal entity life. Quits and Resumes are used on the
diagram to leap from one event to another. Quits and Resumes can
only be used to jump from one side of a selection to another or from
an iteration into the main structure or towards an off-the structure
random event. To represent an unusual event (i.e. an employee
taking family medical leave), you can use pairs of "quit and resume"
events. Each event marked with a "Q", can be replaced by an event
marked with an "R."
 EVENT MODELING: ENTITY LIFE
HISTORIES
An ELH is a diagrammatic representation of the life of a single
entity, from its creation to its deletion. The life is expressed as
the permitted sequence of events that can cause the entity to
change. An event is therefore thought of as whatever brings a
process into action to change entities, so although it is a
process that changes the entity, it is the event that is the cause
of the change.

Creation of Entity Life Histories

The necessary pre-requisites for the development of life histories are
knowledge of the following three ELH components:
The system entities and their attributes.
The events which affect one or more of the system entities during
their lifetime in the system.
A basic notation for describing graphically the chronological
sequence in which the events and event sub structures may occur.
 STRUCTURE OF ENTITY LIFE HISTORIES
The general structure of an ELH as shown in figure 6.1 shows that
there exist three fundamental event types:
Birth Events Death Events Middle Life (or update) Events
The corresponding effects of these are that they cause an occurrence
of the entity to be:
Created by the system. Deleted by the system.
Modified in terms of changes to its attribute values.
 THE 'LEVELS' IN AN ELH
An ELH structure can extend to several levels of detail where
each level is represented by a horizontal bar, immediately
above which will be a group heading and below it the 'details
which collectively describe the construct of the heading.
Life history structures should be minimal structures in terms of
levels necessary to describe an entity's lifetime as a collection
of system events. A fundamental requirement that directly
affects the number of levels shown in particular situations is
that since all the boxes below a horizontal line describe the
construct of the box above it, the mixing of constructs in boxes
below a horizontal line would result in a contradictory
description.
In practice this means that all boxes hanging below a
horizontal line must have the same construct (sequence of
event types, iterations or a selection). Whenever this
requirement cannot be met, new levels and group headings
 WORKED EXAMPLE
Imagine that Danso Ntow has decided, he wants to open a
bank account at D&G Bank. When Danso Ntow has persuaded
Mr. Bobby, the manager, that he would be suitable as a
customer, Mr. Bobby turns to his computer terminal and
records Ntow's new bank account code in the system. The ER
diagram of the bank computer system contains an entity called
Bank Account. The event occurrence that creates the Danso
Ntow occurrence of the entity Bank Account is the opening of
the account by Mr. Bobby.
This event occurrence and the ones that follow it are:
Account opened for Danso Ntow
Cash Deposit GHS2000
Cheque Cashed for GHS20
Direct Deposit GHS1000
Cheque Cashed for GHS20
 WORKED EXAMPLE

This ELH shows that the first event to affect the entity Bank Account will
be Account Opened for all occurrences. Next, the account has a life
which is a series of transactions. Each Transaction is one of: a Pay
Deposit, a Direct Deposit, or a Cheque Cashed. After an undefined
number of Transactions have taken place, the Account will be closed and
finally deleted.
 STATE INDICATORS
A state indicator can be thought of as a data
item/a unit of data stored (example, "M000675"
and "M000676" are data items in the "Account
Number field) within an entity that is updated
every time an event affects it. This means that the
value of the state indicator will show where in its
ELH an entity is at any one time. The values given
to the state indicator have no significance
provided that each effect assigns a unique value
to it. The convention is to start with a value of 1
and increment it by one each time an event
affects an entity. The first thing to do is to assign
a value to each of the effect boxes on the ELH as
STATE INDICATORS
 BEHAVIORAL DESCRIPTIONS (DYNAMIC VIEW)

The following notations and languages are used to describe

the dynamic behavior of software and components.
Unified Modeling Language (UML) is a general modeling
language used to describe software both structurally and
behaviorally. There are several classifications of UML. Some of
these are:
Activity diagrams: Used to show the control flow from activity
(ongoing non atomic execution within a state machine) to activity.
Sequence diagrams: Used to show the interactions among a group
of objects, with emphasis on the time-ordering of messages.
State transition and state-chart diagrams: Used to show the
control flow from state to state in a state machine.
Collaboration diagrams: Used to show the interactions that occur
among a group of objects, where the emphasis is on the objects,
their links, and the messages they exchange on these links.
Data flow diagrams (DFDs): Used to show data flow among a
BEHAVIORAL DESCRIPTIONS (DYNAMIC VIEW)

Decision tables and diagrams: Used to

provide a systematic way of stating
complex combinations of conditions and
actions which are helpful to developers as
well as testers.
Flowcharts and structured flowcharts:
Used to represent the flow of control and
the associated actions to be performed.
Pseudocode and program design
languages (PDLs): structured-
programming-like languages used to
 UNIFIED MODELING LANGUAGE
Released in 1997 by Object Management Group (OMG),
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.
When a standardized notation is used/followed, there is little
room for misinterpretation and ambiguity. Therefore,
standardization provides for efficient communication (a.k.a. a
picture is worth a thousand words) and leads to fewer errors
caused by misunderstanding.
 UML 4+1 VIEW

UML Concepts make use of 4+1 view

o Use Case view - Understandability
o Logical View - Functionality
o Process View Performance, Scalable, Throughput
o Implementation View - Software Management
o Deployment View - System topology, Delivery,
Installation
 UML ADVANTAGES
The UML can be used to model just about any type of
application, running on any type and combination of
hardware, operating system, programming language, and
network, in UML.
UML can be used for modeling middleware and this is
effective for modeling large, complex software systems
Constructed models are easy to understand, even for
non-programmers
Bridges the communication gap between different entities
of system development(i.e . System Analyst, Developer,
Client etc)
Wide Industry Acceptance in comparison to previous
Modeling Language
It can specify systems in an implementation-independent
 USE-CASE DIAGRAM
A use case illustrates a unit of functionality provided by a system.
It is the graphical depiction of the interactions among the
elements of a system. It helps development teams visualize the
functional requirements of a system, including the relationship of
"actors" (human beings who will interact with the system) to
essential processes, as well as the relationships among different
use cases. To show a use case on a use-case diagram, you draw an
oval in the middle of the diagram and put the name of the use
case in the center of, or below, the oval. To draw an actor
(indicating a system user) on a use-case diagram, you draw a stick
person to the left or right of your diagram.
System boundary - It indicates the scope of your system.
Anything within the box represents functionality that is in scope
and anything outside the box is not.
Use case - A use case describes a sequence of actions that
provide something of measurable value to an actor and is drawn
as a horizontal ellipse
Actor - An actor is a person, organization, or external system that
 RELATIONSHIPS IN USE CASE DIAGRAM

Association: communication between an actor and a use case;

Represented by a solid line.
Generalization: relationship between one general use case and
a special use case (used for defining special alternatives);
Represented by a line with a triangular arrow head toward the
parent use case.
Include: a dotted line labeled <<include>> beginning at base
use case and ending with an arrow pointing to the include use
case. The include relationship occurs when a chunk of behavior
is similar across more than one use case. Use include instead
of copying the description of that behavior. <<Include>>
Extend: a dotted line labeled <<extend>> with an arrow
toward the base case. The extending use case may add
behavior to the base use case. The base class declares
extension points. <<Extend>>
SAMPLE USE CASE DIAGRAM
 CLASS DIAGRAM

The class diagram describes the structure of a system and

how the different entities (people, classes, and data) relate
to each other; in other words, it shows the static
structures of the system. A class diagram can be used to
display logical classes, which are typically the kind of
things the business people in an organization talk about
rock bands, CDs, radio play; or loans, home mortgages,
car loans, and interest rates.
A class is depicted on the class diagram as a rectangle
with three horizontal sections. The upper section shows
the class's name; the middle section contains the class's
attributes; and the lower section contains the class's
operations (or "methods"). Class diagrams show the
classes of the system, their interrelationships (including
inheritance, aggregation, and association), and the
CLASS DIAGRAM
 RELATIONSHIPS BETWEEN CLASS
DIAGRAM
Association A relationship between instances of the
two classes. It indicates that objects of one class have a
relationship with objects of another class, There is an
association between two classes if an instance of one
class must know about the other in order to perform its
work. In a diagram, an association is a link connecting two
classes.

Associations can be further classified as

 RELATIONSHIPS BETWEEN CLASS
DIAGRAM
Composition Expresses the dependency relationship
among instances of related classes. Its key purpose of
emphasizing the dependence of the contained class to
the life cycle of the container class. That is, the contained
class will be obliterated when the container class is
destroyed.

Aggregation - expresses a relationship among instances of

related classes. In aggregation, the contained classes are not
strongly dependent on the life cycle of the container. In the
same example, books will remain so even when the library is
dissolved. To render aggregation in a diagram, draw a line from
the parent class to the child class with a diamond shape near
 RELATIONSHIPS BETWEEN CLASS
DIAGRAM

GENERALIZATION refers to a
type of relationship wherein one
associated class is a child of
another by virtue of assuming the
same functionalities of the parent
class. To depict this in a UML
diagram, a solid line from the
child class to the parent class is
drawn using an unfilled
arrowhead.
 SEQUENCE DIAGRAM

Sequence diagrams is a form of interaction diagram which

shows objects as lifelines with their interactions over time
represented as messages drawn as arrows from the source
lifeline to the target lifeline. They show which objects
communicate with which other objects in a time sequence. It
depicts the objects and classes involved in the scenario and the
sequence of message exchanges between them. A sequence
diagram has two dimensions: The vertical dimension shows the
sequence of messages/calls in the time order that they occur;
the horizontal dimension shows the object instances to which
the messages are sent.

Sequence diagram is
o An interaction diagram that details how operations are
carried out.
o What messages are sent and when.
 SEQUENCE DIAGRAM

A sequence diagram is very simple to draw. Across the

top of your diagram, identify the class instances (objects)
by putting each class instance inside a box. In the box, put
the class instance name and class name separated by a
space/colon/space " : " (e.g., myReportGenerator :
ReportGenerator). If a class instance sends a message to
another class instance, draw a line with an open
arrowhead pointing to the receiving class instance; place
the name of the message/method above the line.

Optionally, for important messages, you can draw a

dotted line with an arrowhead pointing back to the
originating class instance; label the return value above the
dotted line. Personally, I always like to include the return
value lines because I find the extra details make it easier
SEQUENCE DIAGRAM
 STATE DIAGRAMS
State diagrams are used to describe the behavior of a
system. They describe all of the possible states of an
object as events occur. A state diagram begins with an
initial object state (when the object is created). The states
activity section depicts what activities the object will be
doing in this state.
State Diagrams show the sequences of states an object
goes through during its life cycle in response to stimuli,
together with its responses and actions; an abstraction of
all possible behaviors
 COLLABORATION DIAGRAMS
UML Collaboration diagrams (interaction diagrams) illustrate the
relationship and interaction between software objects (Classes
and associations). These interactions are modeled as exchanges
of messages between classes and objects (instances) through
their associations. The purposes of interaction diagrams are to
visualize the interactive behaviour of the system. A diagram is
created for each system operation that relates to the current
development cycle (iteration). When creating collaboration
diagrams, patterns are used to justify relationships. There are
two main types of patterns used for assigning responsibilities,
these include evaluative and driving patterns.
Collaboration diagrams contain the following elements.
Class roles, Represent roles that objects may play within the
interaction.
Association roles, Represent roles that links may play within the
interaction.
COLLABORATION DIAGRAMS
 DEPLOYMENT DIAGRAMS

Deployment diagrams are used to visualize the topology

of the physical components of a system where the
software components are deployed. They are used to
describe the static deployment view of a system.
Deployment diagrams consist of nodes and their
relationships.
Deployment diagrams describe the configuration of
processing resource elements and the mapping of
software implementation components onto them. These
diagrams contain components and nodes, which
represent processing or computational resources,
including computers, printers, etc.
The purpose of deployment diagrams can be described as:
Visualize hardware topology of a system.
Describe the hardware components used to deploy software
 DEPLOYMENT DIAGRAMS

Deployment diagrams are mainly used by system engineers.

These diagrams are used to describe the physical components
(hardware), their distribution and association. To clarify it in
details we can visualize deployment diagrams as the hardware
components/nodes on which software components reside.
THANK YOU FOR YOUR
ATTENTION AND
SUPPORT
I WISH YOU THE VERY BEST IN THE EXAMS