The Unified Modelling Language UML

1
1
The Unified Modelling Language (UML)
Introduction
Introduction to illustrative case
studies Origins of the UML What the UML is and
is not Overview of notations Development
process and life cycle
2
The Unified Modelling Language
2
Illustrative case studies
To demonstrate and practice the methods used in
OOD, the following two very different case
studies will be used throughout the
course. Motorway toll system This is a large,
distributed, real-time system which is concerned
with the automatic collection of tolls
on motorways. Diagram editor In contrast,
this forms part of a CASE tool GUI and
is concerned with the drawing of diagrams with
specific properties.
3
The Unified Modelling Language
3
Motorway toll system
Toll gantries will be sited at strategic points
along the motorways. These are equipped with
radar sensors, radio transceivers and cameras.
Every car will be equipped with a radar
transponder as used in aircraft and when sensing
the radr beam will emit a signal which identifies
the driver and the current balance on his
account. This is achieved by providing drivers
with magnetic cards which are inserted into the
transponder and provides a unique identity for
the owner of the card. The card also contains a
record of the current credit on the drivers
account. As the car passes the gantry, a
broadcast signal informs the in-car system of the
fee payable and the transponder deducts that
amount from the current balance. The transaction
is also relayed back to the regional centre where
information on toll charges is passed to a
central system which maintains drivers
accounts. The transponder is preset to
identify the type of vehicle so that different
toll charges can be made for different types of
vehicle. Magnetic cards can be checked and
topped up at payment machines sited in post
offices. From here the payment details are
transmitted to the central system to update the
drivers account. If a car is detected which does
not respond due to faulty or absent transponder
or card, the camera is activated to take a
picture of the car registration. This is done
with a digital camera and the resulting image
processed to extract the number which is sent
along with time and date to regional centre. If
the account becomes overdrawn, no picture is
taken. The traffic events which record location
and direction of travel are used at the regional
centre to monitor traffic densities and identify
trouble spots. A constantly updated display of
the road network is provided for traffic
advisory radio service to supplement their
closed-circuit television monitoring. Also, usage
statistics on traffic flows are recorded every
hour to assist planning of maintenance and new
roads.
4
The Unified Modelling Language
4
Diagram Editor
This is a specialised style of diagram editor for
drawing system models as a block diagram. A
diagram consists of a number of separate
sub-diagrams, each of which consists of a number
of boxes of different types connected by directed
lines. Boxes have a number of lines leading to
them (inputs) and coming from them (outputs).
Lines consist of one or more straight line
segments with an arrow indicating the direction
of flow through the model. Boxes are of one of
the following types - Start boxes (one
per sub-diagram) - no inputs and only one ouput
line. Normal process boxes - up to ten
inputs and one output. Branch boxes
representing decision points with up to ten
inputs and up to ten outputs. Terminal
boxes with up to ten inputs and no
outputs. Boxes are divided into two
compartments, a left side and a right side.
During development, boxes can exist within the
diagram unconnected or partially connected. Lines
however must always connect tow boxes and cannot
exist on their own. In normal edit mode, as the
cursor passes over a box it changes colour to
show that it is selected. The effect of mouse
button clicks when the cursor is over a box are
as follows (lbd left button down event etc)
Cursor in left of box lbd - bring up a dialog
box allowing contents of box to be altered or
box to be deleted -
in latter case all lines to or from boxes
are also deleted. Cursor in left of box
rbd - box is dragged to a new position, when rbu,
fixed in new position and lines redrawn.
Cursor in of bax lbd - start drawing a line
from right side of box and other end follows
cursor. During line
drawing, left button down events produce
anchor points for line segments unless over a
different box,
when line drawing is completed and the new line
replaces any previous one
editor returns to edit mode.
While drawing line, rbd causes line drawing to be
cancelled. Cursor in right of box rbd -
only with branch box, a new ouput is selected
from the ten available. When no box selected
lbd, dialog box pops up to allow the creation of
a new box.
5
The Unified Modelling Language
5
The origins of UML
UML resulted from the merging of three very
popular OOD methods - Objectory by Jacobsen,
Boochs OOD and OMT by Rumbaugh. These authors
worked together on the development of UML - now
referred to as the three amigos.
Jacobsons Use-Case approach
This focused on the external actors interacting
with the system and their functional
requirements. Has a strong functional basis and
has some similarity to the context diagrams of
SASD. A CASE tool called Objectory is available.
Boochs OOD
Boochs method developed originally in 1989 and
later extended in 1991 was targeted initially at
Ada development but later broadened to apply to
OO languages. Diagrams rather complex and CASE
tool support essential. The emphasis here was on
design and implementation.
Rumbaughs OMT
Object modeling technique supported initially by
a case tool OMTool and later by others. Very
straightforward approach with an excellent text
book. Widely adopted in academia and industry
alike. Focus very much on analysis rather than
design and implementation.
6
The Unified Modelling Language
6
What UML is and is not.
UML is A set of standardised diagramatic
notations for representing different aspects of
a system. Containing static structural views,
dynamic behavioural views and functional
views. UML is not A design method or
process, neither is it a methodology. There is
no provision for project management,
specification of deliverables or life cycle or
provision for estimation. This was intended to
allow users to apply whatever process and
life cycle - RAD, prototyping, incremental
development, waterfall or spiral - they wished
and provide their own project management and
QA framework.
7
The Unified Modelling Language
7
Overview of diagrams.
UML diagram provide a variety of different
perspectives on a system. These can be divided
into static, structural diagrams,
interaction diagrams and dynamic behaviour
description as follows - Static, structure
diagrams Class and instance diagrams
These depict the components (classes or
instances) within the system, their
attributes and methods and their relationships
with each other. The class diagram in
particular is the most important single diagram
in the design. Component and
subsystem diagrams These show the way
classes are grouped to form large assemblies -
reusable components, sub-systems or
packages of classes. Deployment diagrams
These show how the software components
are deployed across a set of hardware
components.
8
The Unified Modelling Language
8
Overview of diagrams.
Interaction diagrams Use-case diagrams
These show the interface between the
system and the outside world and
identify the actors in the system and their
required functionality. Sequence diagrams
These show the functionality of the
system is achieved by message passing
between objects. Each sequence diagram shows the
implementation of one scenario.
Collaboration diagrams Based on the
instance diagram, this shows how specific
scenarios are implemented by message
sequence. Similar to sequence diagrams.
Activity diagrams Similar to
petri-nets, these provide a view of the way the
ways objects interact and undergo
mutual changes of state in so doing.
9
The Unified Modelling Language
9
Overview of diagrams.
Dynamic behaviour of the system Activity
diagrams Similar to petri-nets, these
provide a view of the way objects interact
and undergo mutual changes of state in so
doing. The emphasis here is on system
functionality as perceived by users and different
areas of responsibility can be
demarcated. Statecharts Harel
statecharts are a development from finite state
notation and show the dynamic behaviour
of objects. i.e. the way in which an object
evolves through time in reponse to
external events.
10
The Unified Modelling Language
10
The development process
As has already been stated, the UML does not
specify a process to be followed. A number of
possible processes could be adopted depending on
the experience of the personnel and the nature of
the project. Additionally, a number of
different life-cycles could be adopted
- Water-fall approach This never really
worked in the days of structured analysis and
design and there is every reason to believe
that it would be less successful with the
iterative nature of OOD. Prototyping and RAD
OO is highly suited to this approach and aids
it by the provision of reusable, pluggable
components. Incremental development and
iterative development Again both highly
suitable for OO, bringing rapid benefits with low
risk.
11
The Unified Modelling Language
11
Overview of the OOD process
Analysis of current system (if any) new
requirements leading to - Conceptual model. Most
diagram types are involved, but principally -
Create a use-case diagram - identify actors

- identify major functional requirements
Initial Class diagram - discover
principle classes
- represent important
relationships Event sequence diagrams
-examine possible object interactions
-
determine class protocols Design involves
consideration of non-functional requirements and
leads to Implementation model. Involves - adding
more detail, new classes.
- combining or
splitting classes,
- adding or removing
relationships,
- defining the
implementation of
relationships.
-
introducing generalisations, interface

implementation classes. Introduce Component,
sub-system and deployment models.
12
The Unified Modelling Language
12
Categories of model
The development process moves from analysis,
through design to implementation and review in a
cyclewhose length and number of characterises
the life cycle to be used - e.g. waterfall,
cyclic, prototyping, RAD, incremental
etc. During this process a number of different
categories of model can be identified -
Conceptual model - describing the essence of the
system in a low level
of detail. The nature of the
system. Specification model - describing
what the client requires in detail, and
forming a
blueprint for design. Implementation -
describing how the clients requirements are to be
met and
forming a blueprint for implementation.

13
The Unified Modelling Language
13
Categories of object
In identifying objects from which classes can be
derived in the design, three different levels of
object can be recognised - Domain objects
- these represent artefacts or concepts in the
application
domain. Interface objects - these are
systems related components which
provide an interface between
the system and
its actors, such as GUIs.
Implementation objects - these are low level
software components
needed to implement the
design, such as
various forms of data structure
etc. During early stages of design, only domain
objects should be considered. Later, in producing
a specification model, interface objects can be
included and finally, during implementation,
implementation objects are added.

14
14
The Unified Modelling Language (UML)
Use-case and class diagrams
Use-case diagrams Discovering objects Class
diagrams - conceptual models Class diagrams -
implementation models Instance diagrams
15
The Unified Modelling Language
15
Use-case diagrams
These depict the Actors in the system and the
required functionality. Actors External
entities People interested in system
Other systems interfacing with the
system May or may not be represented by a
software component. Represented by stick people
or other graphic. Functions Primary
functionality of system seen from a users
perspective. Linked to the actors involved
with/interested in the function. Represented by
ovals.
16
The Unified Modelling Language
16
Use-case for motorway toll system
Underpaid transaction
Record illegal use
ltltextendsgtgt
ltltextendsgtgt
Create transaction
Record traffic event
Charge card
17
The Unified Modelling Language
17
Use-case for library system
Check member status
ltltusesgtgt
Borrow book
Register member
ltltusesgtgt
Reserve book
Usage report
Return book
Update catalogue
Browse catalogue
ltltextendsgtgt
18
The Unified Modelling Language
18
Discovering Objects
Probably the most difficult part of OOD. No
right answers - only better or poorer
ones. Look for candidate objects as nouns in the
system descriptions. Be very wary of inferred
nouns. Need to read between the lines. Objects
have state and suffer or perform
actions. Actions on objects bring about changes
of state of the object. Objects will represent
key concepts in the application domain. From
identification of objects we can infer candidate
classes.
19
The Unified Modelling Language
19
Candidate classes for the motorway toll system
System toll motorway motorist toll
booth payment strategic point toll gantry radar
receiver transmitter camera car transponder radar
beam signal driver vehicle current
balance balance account
Transaction regional centre toll central
system magnetic card payment machine post office
country customer balance valid card credit
balance picture registration plate computer
registration number image location time offence
card negative a/c balance
Fee underpaid transact warning signal traffic
event gantry direction information traffic
density route trouble spot hold up display road
network feature traffic advice service closed
circuit TV traffic channel usage
statistics traffic flows segments hour of the
day new road maintenance operation
20
The Unified Modelling Language
20
Deriving principle classes - refinement
The list of candidate classes will be excessively
long and contain many inappropriate items. These
should be filtered out by applying the
following criteria - Classes outside
scope of system Redundant classes -
synonyms Vague classes
Implementation classes Attributes of
other classes Verbs or events
Representing entities over which the system will
have no control. Different names referring to
the same concept. Non-specific concepts too
imprecise to define exactly. Parts of the final
computer system rather than the user
domain. Simple data values not warranting treatmen
t as an object - keep a note. Possibly methods in
other classes
21
The Unified Modelling Language
21
Classes outside the scope of the system
System toll motorway motorist toll
booth payment strategic point toll gantry radar
receiver transmitter camera car transponder radar
beam signal driver vehicle current
balance balance account
Transaction regional centre toll central
system magnetic card payment machine post office
country customer balance valid card credit
balance picture registration plate computer
registration number image location time offence
card negative a/c balance
Fee underpaid transact warning signal traffic
event gantry direction information traffic
density route trouble spot hold up display road
network feature traffic advice service closed
circuit TV traffic channel usage
statistics traffic flows segments hour of the
day new road maintenance operation
22
The Unified Modelling Language
22
Redundant classes - synonyms
System toll motorist customer toll
booth payment strategic point toll gantry radar
receiver transmitter camera car vehicle
motorist radar beam signal driver
motorist vehicle current balance balance
current bal account motorist
Transaction underpaid regional
centre toll central system magnetic card
card payment machine customer balance valid
card credit balance picture registration
plate computer registration number
plate image location time offence card valid
card negative a/c balance
Fee underpaid transact warning signal traffic
event gantry toll gantry direction information t
raffic density trouble spot hold
up display feature closed circuit TV usage
statistics traffic flows hour of the day
23
The Unified Modelling Language
23
Vague classes
System toll motorist toll booth payment strategic
point radar receiver transmitter camera radar
beam signal
Transaction regional centre central
system magnetic card payment machine credit
balance picture computer registration number
image location time offence
Fee warning signal traffic event gantry
direction information traffic density trouble
spot hold up display feature closed circuit
TV l usage statistics traffic flows hour of the
day
24
The Unified Modelling Language
24
Implementation classes
System toll motorist toll booth payment radar
receiver transmitter camera signal
Transaction regional centre central
system magnetic card payment machine credit
balance computer registration number
location time
Fee warning signal traffic event gantry
direction traffic density display closed
circuit TV l usage statistics traffic flows hour
of the day
25
The Unified Modelling Language
25
Attributes of other classes
toll motorist payment radar
receiver transmitter camera signal
Transaction regional centre central
system payment machine credit balance
registration number location time
Fee warning signal traffic event gantry
direction traffic density usage
statistics traffic flows hour of the day
26
The Unified Modelling Language
26
Verbs or events
motorist payment radar receiver transmitter
camera signal
Transaction regional centre central
system payment machine
warning signal traffic event gantry

27
The Unified Modelling Language
27
Final class list
motorist radar receiver transmitter camera

Transaction regional centre central
system payment machine
gantry
28
The Unified Modelling Language
28
Final class list - Motorway toll system
Motorist account holder radar transceiver sub
system detecting communicating with
transponder camera digital camera for
recording and relaying registrations transacti
on vehicle passage through toll -
time,direction fee, account ID regional
centre collect and analyse traffic
flows central system update accounts payment
machine recharging card with credit - link to
central system. Gantry assembly of
components.
29
The Unified Modelling Language
29
Relationships between classes
The UML recognizes four principle relationships
between classes as follows - Simple
association - usually annotated and interpreted
left to
right/top to bottom.
If meaning implies right to left
etc use
small arrows to indicate. Aggregation -
a part of relationship Composition - a
stronger - permanent ownership form
of aggregation.
Generalisation/specialisation - is a or is
like as
relationship. Composition and generalisation not
usually annotated and always 1 to 1. Others can
be 1 to 1 ( unmarked), 1 to many or many to
many. Multiplicity is shown as zero or more,
1.. one or more specifically e.g. 2..5 or 6
or 4,8,12
course
is enrolled on
student

race
horse
4
car
wheel
vehicle
car
30
The Unified Modelling Language
30
Relationships between classes
Other forms of notation frequently used are
- Role names on associations - Interface
inheritance (implements) - Uses
relationship- Generic instantiation
31
The Unified Modelling Language
31
Class attributes and methods
During analysis, the conceptual class model is
developed, with the help of other diagrams,
through the following stages - Simple class
names with relationships Introduction of class
attributes Introduction of methods During
design, attribute and method detail will be
extended to include visibility indication, data
types, parameter and parameter types and return
types from methods.
Book
32
The Unified Modelling Language
32
Conceptual model - motorway toll system

Central System
Regional Centre
updated by
Gets traffic events from

Toll gantry
6
records
Traffic lane
Transaction

Radar
Camrea
Radio transceiver
33
The Unified Modelling Language
33
Conceptual model - diagram editor


input
output


outputs

34
The Unified Modelling Language
34
Implementation model
The initial conceptual models created during
analysis avoid implementational detail and do not
consider the implementation of relationships. In
moving to an implementation model during design,
a number of changes take place - New
super-classes may be introduced and larger
classes split or smaller ones
combined. Link classes may be introduced/removed.
The direction multiplicity of aggregation,
composition and association relations is
revised. Derived relations and attributes and
qualified relations are introduced.
Packaging of classes, creation of subsystems
and reusable components considered. Deployment
of components to hardware decided.
35
The Unified Modelling Language
35
The design process
The conceptual models describe the system in
user oriented terms and focus on objects in the
user domain only. During design, two more levels
of components are introduced into the
models. User interface components (often GUI
components) Implementation components
(typically collection components) Other
considerations include - Use of design pattern
and frameworks. Persistence requirements. Non-
functional constraints such as performance,
useability, maintainability, security and
reliability.
36
The Unified Modelling Language
36
Implementation model - additional notations
The detail on class diagrams is increased to show
- Direction of navigation Use of qualified
association Derived attributes
associations Either-or membership Visibili
ty and data types Link classes
race
horse
name
ridden by
/Rides in
sponsor
jockey
or
club
Book -author String -title
String Book(String auth, titl) lend(Member
m) return() reserve(Member m)


book
member
reservation
37
The Unified Modelling Language
37
Use-case for diagram editor
Add box
Delete box
Move box
Delete line
Edit box
Add line
38
The Unified Modelling Language
38
Instance diagram - diagram editor

L3 line


L1 line
L2 line

L4 line
39
39
The Unified Modelling Language (UML)
Object interaction diagrams
Object interaction and message passing Collaborat
ion diagrams Sequence diagrams
40
The Unified Modelling Language
40
Object interaction message passing
The process of fleshing out the class diagram by
adding methods can be done partly by invention,
but principally through the examination of
scenarios which are instances of use
cases. The essence of object-oriented systems is
a collection of objects interacting with each
other to achieve a common goal. In this case the
goal is the user functionality and the
interactions are messages or methods defined in
objects classes. Two diagram types provide views
of this aspect of the system - both dealing with
instances and not classes. Collaboration
diagrams Event sequence diagrams
41
The Unified Modelling Language
41
Collaboration diagram - diagram editor
Scenario - Add line
1. Add line(a,b)

L3 line


L1 line
L2 line

L4 line
42
The Unified Modelling Language
42
Collaboration diagram - diagram editor
Scenario - Add line
1. Add line(a,b)
1.1. Add output

L3 line


L1 line
L2 line

L4 line
43
The Unified Modelling Language
43
Collaboration diagram - diagram editor
Scenario - Add line
1. Add line(a,b)
1.1. Add output
1.1.2. Create line(checkout)

L3 line


L1 line
L2 line

L4 line
44
The Unified Modelling Language
44
Collaboration diagram - diagram editor
Scenario - Add line
1. Add line(a,b)
1.1. Add output
1.1.2. Create line(checkout)

L3 line
1.2. Add input(L3)


L1 line
L2 line

L4 line
45
The Unified Modelling Language
45
Collaboration diagrams
These show the way in which objects collaborate
with each other to achieve a specific functional
requirement. Based on an instance
diagram Show interaction in form of message
passing Use dewy-decimal numbering to show
ordering and logical grouping of
messages. Law of Demeter - Objects should only
communicate with - Those directly
connected. Those passed as parameters in
method calls Those created as local variables
in methods Not objects passed back from method
calls to other objects
Minimizes coupling between objects - necessary
for ease of reuse.
46
The Unified Modelling Language
46
Event sequence diagram - diagram editor
Scenario - Add line
add line
add line(a,b)
a.addOutput(a,b)
L.create(a,b)
create
ok
ok
b.addInput()
ok
ok
ok
47
The Unified Modelling Language
47
Event sequence diagrams
These, like Collaboration diagrams, show the
interaction between objects, with time increasing
downwards. Message types synchronous return
asynchronous Instance creation
destruction Conditional choice Iteration
48
The Unified Modelling Language
48
Event sequence diagram - diagram editor
Scenario - Move box
moveBox
moveBox(aBox)
Move()
ok
for all inputs
reDraw()
ok
ok
ok
49
49
The Unified Modelling Language (UML)
Activity diagrams statecharts
Modelling object behaviour Activity
diagrams Statecharts
50
The Unified Modelling Language
50
Modelling Object Behaviour
Having represented the interaction between
objects through collaboration and event sequence
diagrams, we need a way of depicting the dynamic
behaviour on individual objects. This needs to
show - How objects change state and
evolve through their lifetime. What
events bring about such changes of state, and
What actions accompany such changes. This
is depicted primarily by Harrel statecharts which
are a development from traditional state
transition diagrams. At the functional level, a
more user oriented view of the processing
that takes place is provided by Activity
diagrams. These are a cross between Petri-Net
diagrams and the more traditional control flow or
workflow diagrams.
51
The Unified Modelling Language
51
Harrel Statecharts
These diagrams depict the way in which objects
evolve during their life in the system. The
essential elements are - States -
representing a stable condition of the object
which persists for a
significant time (although transient states are
sometimes depicted), at a
given level of detail. Not described by verbs.
Transitions - depicting possible paths
from one state to another. Events -
these may be external events originating from
actors, or internal
events - actions performed by other objects in
the system.
Actions - processing carried out as part of a
transition in state - seen
as internal events by other objects.
Conditions - conditions governing the occurrence
of a transition.
52
The Unified Modelling Language
52
Example Statecharts
The following simple statechart depicts the life
of a push/push light switch -
push/turn-on
OFF
ON
push/turn-off
Folding of states The state of an object can be
characterised entirely its location in the
diagram, but frequently this leads to an
explosion of states. These can be folded on each
other by introducing attributes, e.g. the two
ways of representing a counter -
pulse/
pulse/
pulse/
0
1
2
or, when folded with count attribute
pulse/count
counting
53
The Unified Modelling Language
53
Harrel Statechart Features
The principal problems with traditional state
transition diagrams are - They
represent a single sequence of transitions - i.e.
cannot represent concurrency.
They are all at one level and tend to have many
states transitions. These are addressed with
more or less success in Harrel statecharts
by providing - A heirarchy of levels
of representation. Representation of
parallel sub-diagrams for concurrency.
Extra features such as entry, exit and do action
specifications.
54
The Unified Modelling Language
54
Statechart for a simple ATM
The following represents a very simple ATM
machine and illustrates some of these features -
insert card/ prompt for pin
digit/ display
AWAIT PIN
not valid/ re-prompt
not valid 4th time/ timeout
4th digit/ validate
timeout/ eat card
IDLE
VERIFYING PIN
Enter choice/ dispense eject
AWAIT CHOICE
valid/ prompt for choice
complete
eject card/
take card/ complete
AWAIT TAKE CARD
cancel trans/ eject card
55
The Unified Modelling Language
55
Statechart for a simple ATM
This becomes the following at a higher level of
abstraction-
insert card/ prompt for pin
OBTAIN PIN CHOICE
timeout/ eat card
IDLE
eject card/
take card/ complete
AWAIT TAKE CARD
cancel trans/ eject card
complete
56
The Unified Modelling Language
56
Statechart for a simple ATM
Or at an even higher level of abstraction -
insert card/ prompt for pin
PROCESS TRANSACTION
timeout/ eat card
IDLE
complete
57
The Unified Modelling Language
57
Statechart for diagram editor
mmnot in box/
NO BOX SELECTED
rbd/cancel line cross hair
delete/remove box lines
mm in box/ select box
mmnot in box/ de-select box
lbd in right/ select next line
mmstill in box/
BOX SELECTED
rbu/redraw box lines cross hair
confirm/ redraw box
lbd left/ display dialogue
rbdleft/ hand cursor
FILLING DIALOG
MOVING
rbdright/ circle cursor
lbdin box/ insert line cross hair
mm/ redraw box outline
LINE DRAWING
lbdnot in box/ create segment
mm/draw line segment
58
The Unified Modelling Language
58
Representation of concurrency
This snippet of a domestic security system
illustrates the use of concurrent sub diagrams
with synchronising events -
ARMING do beep
ARMED
set/arm
DISABLED
trigger/ activate
enable
countgtlim/ set
cancel
GRACE PERIOD entry count0
pulse/count
59
The Unified Modelling Language
59
Activity diagrams
Activity diagrams are a cross between Petri-Nets
and Process or Workflow Diagrams and provide a
very user oriented view of system operation. The
main components of such diagrams are -
Process specifications identify individual
steps in processing Workflow
paths define the flow of control or work flow
Swimlanes identify departmental
boundaries or areas of responsibility.
Transitions represent synchronisation
points Decision points if/then/else
branches in work flow Signal and
accept flags provide synchronisation points
between different work flow paths As with
statecharts, these diagrams can bearranged in a
heirarchy.
60
The Unified Modelling Language
60
Example activity diagram
The following represents a simple bespoke
production system - Customer Design
dept. Commercial dept.
Manufacturing
SPECIFY CUST REQ.S
ALLOCATE DESIGNER
ALLOCATE BUILDER
DESIGN PRODUCT
COMPUTE PRICE
not ok
ok
CREATE ORDER
OBTAIN BO ITEMS
BUILD PRODUCT
ASSEMBLE PRODUCT
61
The Unified Modelling Language
61
Example activity diagram
The following represents a simple bespoke
production system - Customer Design
dept. Commercial dept.
Manufacturing
DESIGNER FREE
SPECIFY CUST REQ.S
ALLOCATE DESIGNER
ALLOCATE BUILDER
DESIGNER ALLOC
CUST REQ
DESIGN PRODUCT
COMPUTE PRICE
not ok
ok
CREATE ORDER
PRODUCT
OBTAIN BO ITEMS
ORDER
DESIGNER FREE
BUILD PRODUCT
PRODUCT
PRODUCT COMPLETE
ASSEMBLE PRODUCT
62
The Unified Modelling Language
62
Example activity diagram
The following represents a simple bespoke
production system - Customer Design
dept. Commercial dept.
Manufacturing
DESIGNER FREE
SPECIFY CUST REQ.S
ALLOCATE DESIGNER
ALLOCATE BUILDER
DESIGNER ALLOC
CUST REQ
DESIGN PRODUCT
COMPUTE PRICE
not ok
ok
CREATE ORDER
PRODUCT
OBTAIN BO ITEMS
ORDER
DESIGNER FREE
BUILD PRODUCT
PRODUCT
PRODUCT COMPLETE
ASSEMBLE PRODUCT
63
63
The Unified Modelling Language (UML)
Implementation diagrams
Implementation issues Component
diagrams Packages and sub-systems Deployment
diagrams
64
The Unified Modelling Language
64
Implementation issues
We have already seen how the class diagram
produced duroing analysis may change
significantly during design as we move from a
conceptual model to an implementation model of
the system. In addition, the following
considerations come to bear and must be
documented - Can reusable components be
created from the defined classes ? How should
classes be separated into packages and
sub-systems ? How should components be deployed
onto the hardware ? What level of concurrency
should there be on individual processors ? How
many processors should there be ? What form
should communication links between processors
take ?
65
The Unified Modelling Language
65
Component diagrams
A component is a reusable, pluggable entity which
usually consists of a set of tightly coupled
objects working together for a very
specific purpose. The component is a black box
(façade pattern) and present a well
defined interface to clients. A component diagram
shows component types and is equivalent to a
class diagram.
ltltcompilegtgt
pluggable interface
ltltcompilegtgt
UML has a number of predefined stereotypes for
components - link, compile, file, library,
table, document, executable
66
The Unified Modelling Language
66
Package Sub-system diagrams
Packages are groups of model entities - which may
be individual classes and/or components. They
are usually logical groupings of components such
as graphics packages or interface components or
maths packages etc. Sub-systems are similar, but
usually represent a functional subset of
the system being built. These groupings are used
- to clarify designs to partition work
guidance system
67
The Unified Modelling Language
67
Deployment diagrams
Deployment diagrams show the way software is
distributed across the available hardware and the
basic hardware architecture in terms
of processors and communication links.
regional computer
ltltWANgtgt
gantry computer


ltltWANgtgt
central computer
68
68
The Unified Modelling Language (UML)
Other topics
Mixin inheritance Multiple inheritance Meta-clas
ses
69
The Unified Modelling Language
69
Mixin inheritance
One of the problems with multiple inheritance is
the ambiguity that arises when there is a common
base class - Here, its unclear what
attributes and methods class D inherits. Mixin
inheritance uses abstract property classes which
can be mixed-in with a class without leading to
these problems. This is similar to the use of
interfaces in Java to provide capabilities.
70
The Unified Modelling Language
70
Multiple inheritance
Multiple inheritance clearly presents problems as
the previous slide indicated. Many OO languages
avoid the problems by only implementing single
inheritance (Smalltalk, Java, Delphi etc.) In
such languages, multiple inheritance can be
simulated by a combination of aggregation and
delegation -
Multiple inheritance Aggregation
delegation
A
B
C
71
The Unified Modelling Language
71
Meta-classes
Meta means data about data. Hence, a class (which
is information about instances) is a
meta-instance. However, a class is an object in
its own right, hence the meta-class
provides information about the class. In Java
the class and meta-class data are mixed together
- we should really have -
describes
describes
72
The Unified Modelling Language
72
Meta-classes
Java does provide a form of meta-class in the
Class class. This describes the structure of a
class in terms of its components - Attributes,
Methods and Parameters. Provides a powerful
tool for introspection and aids the development
of pluggable components such as Java Beans. The
Java Class meta-class has the following structure
-
Class




Attribute
Method
Exception
Event

Parameter