Unified Modeling Language

1
Unified Modeling Language
2
OMG UML Evolution
From Kobryn 01a.
3
OMG UML Contributors
AonixComputer Associates Concept Five Data
Access EDS Enea Data Hewlett-Packard
IBM I-LogixInLine Software Intellicorp Kabira
TechnologiesKlasse Objecten Lockheed Martin
Microsoft ObjecTimeOraclePtech OAO Technology
SolutionsRational SoftwareReich SAP Softeam Ster
ling Software Sun Taskon TelelogicUnisys
4
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 Rapid Application Development (RAD),
prototyping, incremental development, waterfall
or spiral - they wished and provide their own
project management and QA framework.
5
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.
6
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.
7
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.
8
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.
9
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.
10
Categories of model
The development process moves from analysis,
through design to implementation and review in a
cycle whose 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.

11
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.

12
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
13
Case I Highway 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 radar beam will emit a signal which
identifies the driver and the current balance on
the drivers 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
center 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.
14
(No Transcript)
15
Case II 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 right of box 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 output is selected
from the ten available. When no box selected
lbd, dialog box pops up to allow the creation of
a new box.
16
(No Transcript)
17
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.
18
Use-case for motorway toll system
Underpaid transaction
Record illegal use
ltltextendsgtgt
ltltextendsgtgt
Create transaction
Record traffic event
Charge card
19
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
20
Use Case Modeling Core Elements
21
Use Case Modeling Core Relationships
22
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.
23
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
24
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
25
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
26
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
27
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 usage statistics traffic flows hour of the
day
28
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 usage statistics traffic flows hour
of the day
29
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
30
Verbs or events
motorist payment radar receiver transmitter
camera signal
Transaction regional centre central
system payment machine
warning signal traffic event gantry

31
Final class list
motorist radar receiver transmitter camera

Transaction regional centre central
system payment machine
gantry
32
Final class list / Glossary - 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.
33
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
34
Relationships between classes
Other forms of notation frequently used are
- Role names on associations - Interface
inheritance (implements) - Uses
relationship- Generic instantiation
35
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
36
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
37
Conceptual model - diagram editor


input
output


outputs

38
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.
39
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,
usability, maintainability, security and
reliability.
40
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
41
Use-case for diagram editor
Add box
Delete box
Move box
Delete line
Edit box
Add line
42
Instance diagram - diagram editor


L1 line
L2 line

L4 line
43
The Unified Modelling Language (UML)
Object interaction diagrams
Sequence diagrams Collaboration diagrams
44
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. Event sequence
diagrams Collaboration diagrams
45
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
46
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
47
Event sequence diagram - diagram editor
Scenario - Move box
moveBox
moveBox(aBox)
Move()
ok
for all inputs
reDraw()
ok
ok
ok
48
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 Dewey-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 Avoid objects passed back from
method calls to other objects
Minimizes coupling between objects -
necessary for ease of reuse.
49
Collaboration diagram - diagram editor
Scenario - Add line
1. Add line(a,b)

L3 line


L1 line
L2 line

L4 line
50
Ex. Admin. manages users through Web
51
The Unified Modelling Language (UML)
Modeling Object Behaviour
Statecharts Activity diagrams
52
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 system
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.
53
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.
54
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
55
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.
56
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
57
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
58
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
59
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
60
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
61
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 be arranged in a
hierarchy.
62
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
63
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
64
Case Study
Adapted from Kobryn, UML 2001 Communications of
the ACM October 1999
65
Case Study
Adapted from Kobryn, UML 2001 Communications of
the ACM October 1999
66
The Unified Modelling Language (UML)
Implementation diagrams
Component diagrams Packages and
sub-systems Deployment diagrams
67
Implementation issues
We have already seen how the class diagram
produced during 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 ?
68
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
69
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
70
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
71
How do they all fit together?

• Functionality
• use case diagrams
• Decomposition
• class diagrams (class structure)
• package diagrams, deployment diagrams
  (architecture)
• Behavior
• state diagrams, activity diagrams
• Communication
• sequence diagrams, collaboration diagrams

72
An Overall Development Process
Partially articulated requirements
Capture Requirements
Use Case Diag.
Requirements
Construct Model of Overall system
Class Diag.
Structure
Sequence Diag.
Behaviour

• These diagram types, and the process can be used
  both for
• Designing a new system
• Understanding an existing system

73
UML-Driven Software Engineering Process
Inception
Elaboration
Construction
Transition
Iteration 1
Iteration 2
Iteration 3
Each iteration is defined in terms of the
scenarios it implements
Mini-Waterfall Process

• Results of previous iterations
• Up-to-date risk assessment
• Controlled libraries of models, code, and tests

Selected scenarios
Iteration Planning
Reqs Capture
Analysis Design
Implementation
Test
Release description Updated risk
assessment Controlled libraries
Prepare Release
74
The Unified Modelling Language (UML)
Other topics
Mixin inheritance Multiple inheritance Meta-clas
ses
75
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.
76
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
77
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
78
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
79
References

• Dr. Peter Martin http//www.cems.uwe.ac.uk/pcsmar
  ti/uqc816sm/uqc816sm.htm