unified modeling language. omg uml evolution from [kobryn 01a]

Unified Modeling LanguageUnified Modeling Language

OMG UML Evolution

1997(adopted by OM G)

1998

1999

Q1 2001

2001 Q4(planned)

Editorial revisionwithout significanttechnical changes.

2002(planned)

<<docum ent>>UM L 1.1





Infrastructure



Superstructure

<<docum ent>>UM L 2.0 OCL

com position(whole-part)relationship

dependencyrelationship

From [Kobryn 01a].

OMG UML Contributors

AonixComputer AssociatesConcept FiveData AccessEDSEnea DataHewlett-Packard IBMI-LogixInLine SoftwareIntellicorpKabira TechnologiesKlasse ObjectenLockheed Martin

MicrosoftObjecTimeOraclePtech OAO Technology SolutionsRational SoftwareReichSAPSofteamSterling SoftwareSunTaskonTelelogicUnisys…

What UML is and is not.

UML is …

A set of standardised diagramatic notations for representingdifferent aspects of a system. Containing static structuralviews, 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 lifecycle – Rapid Application Development (RAD), prototyping, incremental development, waterfall or spiral - they wished and provide their own project management and QA framework.

Overview of diagramsUML diagram provide a variety of different perspectives on a system.These can be divided into static, structural diagrams, interactiondiagrams 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.

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.

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.

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

Overview of the OOD processAnalysis 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 toImplementation 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.

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.

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 GUI’s.

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

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

Case I: Highway toll systemToll 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 driver’saccount.

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 thetransponder 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 thepayment details are transmitted to the central system to update the driver’s account.

If a car is detected which does not respond due to faulty or absent transponder or card, the camera is activatedto take a picture of the car registration. This is done with a digital camera and the resulting image processedto extract the number which is sent along with time and date to regional centre. If the account becomesoverdrawn, 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.

Case II: Diagram EditorThis is a specialised style of diagram editor for drawing system models as a block diagram. A diagram consistsof a number of separate sub-diagrams, each of which consists of a number of boxes of different types connectedby 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 andcannot 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 ofmouse 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.

START END

PROCESS IF_THEN

Use-case diagramsThese depict the Actors in the system and the required functionality.

Actors

External entities People interested in system Other systems interfacing with the systemMay 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.

Identify the actors & main functions in the motorway toll system

Use-case for motorway toll system

Createtransaction

motorist Traffic advice centre

Centralregistry Regional

centre

Recordillegal use

Record trafficevent

Charge card

Underpaidtransaction

<<ex

tend

s>>

<<

exte

nds>

>

Use-case for library system

Returnbook

Staffborrower

studentborrower

Checkmember status

Reservebook

Browsecatalogue

Borrowbook

browser

Counterstaff

manager

Registermember

Usagereport

Updatecatalogue

Return late book

<<uses>>

<<uses>>

<<extends>>

Use Case Modeling: Core Elements

Construct Description Syntax

use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the physical system and the actors who interact with the physical system.

UseCaseNam e

ActorNam e

Construct Description Syntax

association The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.

generalization A taxonomic relationship between a more general use case and a more specific use case.

extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.

include An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.

<<extend>>

<<include>>

Use Case Modeling: Core Relationships

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.

Now list the candidate classes in the motorway toll system

Candidate classes for the motorway toll systemSystemtollmotorwaymotoristtoll boothpaymentstrategic pointtoll gantryradar receivertransmittercameracartransponderradar beamsignaldrivervehiclecurrent balancebalanceaccount

Transactionregional centretollcentral systemmagnetic cardpayment machinepost office countrycustomerbalancevalid cardcredit balancepictureregistration platecomputer registration numberimagelocationtimeoffence cardnegative a/c balance

Feeunderpaid transactwarning signaltraffic eventgantrydirectioninformationtraffic densityroutetrouble spothold updisplayroad networkfeaturetraffic advice serviceclosed circuit TVtraffic channelusage statisticstraffic flowssegmentshour of the daynew road maintenance operation

Deriving principle classes - refinementThe list of candidate classes will be excessively long and contain many inappropriate items. These should be filtered out by applying the followingcriteria :-

Classes outside scope of system

Redundant classes - synonyms

Vague classes

Implementation classes

Attributes of other classes

Verbs or events

Representing entities over which thesystem will have no control. Different names referring to the sameconcept.Non-specific concepts too imprecise todefine exactly.Parts of the final computer systemrather than the user domain.Simple data values not warrantingtreatment as an object - keep a note.Possibly methods in other classes

Apply these criteria to the candidates in the motorway system

Classes outside the scope of the systemSystemtollmotorwaymotoristtoll boothpaymentstrategic pointtoll gantryradar receivertransmittercameracartransponderradar beamsignaldrivervehiclecurrent balancebalanceaccount

Transactionregional centretollcentral systemmagnetic cardpayment machinepost office countrycustomerbalancevalid cardcredit balancepictureregistration platecomputer registration numberimagelocationtimeoffence cardnegative a/c balance

Feeunderpaid transactwarning signaltraffic eventgantrydirectioninformationtraffic densityroutetrouble spothold updisplayroad networkfeaturetraffic advice serviceclosed circuit TVtraffic channelusage statisticstraffic flowssegmentshour of the daynew road maintenance operation

Redundant classes - synonymsSystemtoll

motorist & customertoll boothpaymentstrategic pointtoll gantryradar receivertransmittercameracar & vehicle & motorist

radar beamsignaldriver & motoristvehiclecurrent balancebalance & current balaccount & motorist

Transaction & underpaidregional centretollcentral systemmagnetic card & cardpayment machine

customerbalancevalid cardcredit balancepictureregistration platecomputer registration number & plateimagelocationtimeoffence card & valid cardnegative a/c balance

Feeunderpaid transactwarning signaltraffic eventgantry & toll gantrydirectioninformationtraffic density

trouble spothold updisplay

feature

closed circuit TV

usage statisticstraffic flows

hour of the day

Vague classesSystemtoll

motoristtoll boothpaymentstrategic point

radar receivertransmittercamera

radar beamsignal

Transaction regional centre

central systemmagnetic cardpayment machine

credit balancepicture

computer registration number imagelocationtimeoffence

Fee

warning signaltraffic eventgantry directioninformationtraffic density

trouble spothold updisplay

feature

closed circuit TV


hour of the day

Implementation classesSystemtoll

motoristtoll boothpayment


signal


central systemmagnetic cardpayment machine

credit balance

computer registration number

locationtime

Fee

warning signaltraffic eventgantry direction

traffic density

display

closed circuit TV


hour of the day

Attributes of other classes

toll

motorist

payment


signal


central system

payment machine

credit balance

registration number

locationtime

Fee

warning signaltraffic eventgantry direction

traffic density


hour of the day

Verbs or events

motorist

payment


signal


central system

payment machine

warning signaltraffic eventgantry

Final class list

motorist



central system

payment machine

gantry

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 registrationstransaction vehicle passage through toll - time,direction fee, account IDregional centre collect and analyse traffic flows

central system update accounts

payment machine recharging card with credit - link to centralsystem.

Gantry assembly of components.

Relationships between classesThe 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

student

is enrolled on

race horse*

car wheel4

vehicle car

Relationships between classesOther forms of notation frequently used are :-

Role names on associations -

Interface inheritance (implements) :-

Uses relationship:-

Generic instantiation :

employee

works for

boss

worker*

0,1

<<interface>>Controls

simulator

Flight modelmaths

controls

collection

type

Book list

<<bind>> book

Class attributes and methods

During analysis, the conceptual class model is developed, with the helpof other diagrams, through the following stages :-

Simple class names with relationships

Introduction of class attributes

Introduction of methods

During design, attribute and method detail willbe extended to include visibility indication,data types, parameter and parameter typesand return types from methods.

Book

Draw a class diagram for motorway toll system

Book

authortitle

Book

authortitle

lendreturnreserve

Conceptual model - motorway toll system

Regional CentreCentral System

Toll gantry

TransactionTraffic lane

Camrea Radio transceiverRadar

*

*

6

*

updated by

records

Gets trafficevents from

Conceptual model - diagram editor

Diagram

Box

StartBox TerminalBox Line

ProcessBox

BranchBox

Line

Segment

Model

*

*

*

*

output input

outputs

*

Implementation model

The initial conceptual models created during analysis avoid implementationaldetail and do not consider the implementation of relationships.

In moving to an implementation model during design, a number of changestake 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.

The design process

The conceptual models describe the system in user oriented terms andfocus 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.

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

Visibility and data types

Link classes

race horse*

race horsename

race horsename

jockey

ridden by/Rides in

sponsor

club

or

Book

-author : String-title : String

+Book(String auth, titl)+lend(Member m)+return()+reserve(Member m)

book member

reservation

* *

Use-case for diagram editor

Move box

User

Delete box

Add line

Add box

Delete line

Edit box

Instance diagram - diagram editor

Customer :diagram

Arrive:StartBox Checkout: ProcessBox Leave: TerminalBox

ReleaseTill:ProcessBox

Shop:model

L1: line

L3: line

L2: line L4: lineGetTill:ProcessBox


Object interaction diagrams

Sequence diagrams

Collaboration diagrams

Object interaction & message passing

The process of fleshing out the class diagram by adding methods can bedone 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 interactingwith 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 dealingwith instances and not classes.

Event sequence diagrams


Event sequence diagram - diagram editor

Customer :diagram

Checkout: process

ReleaseTill:process

Shop:model

L3: line

Scenario - Add line

User

create

add line

add line(a,b)

a.addOutput(a,b)

L.create(a,b)

okok

b.addInput()

ok

okok

Event sequence diagrams

These, like Collaboration diagrams, show the interaction between objects,with time increasing downwards.

Message types synchronousreturnasynchronous

Instance creation & destruction

Conditional choice

Iteration

[ condition 1]

[ condition 2]

n times

Create an event sequence diagram for move box

Event sequence diagram - diagram editor

Customer :diagram aBox Outputs : Lines

Shop:model

Inputs : Lines

Scenario - Move box

User

moveBox

moveBox(aBox)

Move()

ok

okok

for allinputs

reDraw()

for allinputs

reDraw()

ok

ok


These show the way in which objects collaborate with each otherto 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 callsThose created as local variables in methods

Avoid objects passed back from method calls to other objects

Minimizes coupling between objects - necessary for ease ofreuse.

Collaboration diagram - diagram editor

Customer :diagram

Arrive:start

GetTill:Process

Checkout: process Leave: Terminal

ReleaseTill:process

Shop:model

L1: line

L3: line

L2: line L4: line

Scenario - Add line

1.1. Add output

1.1.2. Create line(checkout)

1.2. Add input(L3)

1. Add line(a,b)

Ex. Admin. manages users through Web


Modeling Object Behaviour

Statecharts

Activity diagrams

Modelling Object Behaviour

Having represented the interaction between objects through collaborationand 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 developmentfrom 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.

Harrel Statecharts

These diagrams depict the way in which objects evolve during their lifein 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.

Example Statecharts

The following simple statechart depicts the life of a push/push light switch :-

OFF ON

push/turn-on

push/turn-offFolding of states The state of an object can be characterised entirely it’s 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 :-

0 1 2pulse/ pulse/ pulse/

or, when folded with count attribute

countingpulse/count++

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 byproviding :-

A heirarchy of levels of representation.

Representation of parallel sub-diagrams for concurrency.

Extra features such as entry, exit and do action specifications.

Statechart for a simple ATM

The following represents a very simple ATM machine and illustratessome of these features :-

IDLE

AWAIT PIN

VERIFYINGPIN

AWAITCHOICE

AWAITTAKE CARD

insert card/prompt for pin

complete

[timeout]/eat card

take card/complete

eject card/

[not valid]/re-prompt

[valid]/prompt for choice

Enter choice/dispense & eject

[not valid 4th time]/ timeout 4th digit/

validate

cancel trans/eject card

digit/ display


This becomes the following at a higher level of abstraction:-

IDLE

OBTAINPIN & CHOICE

AWAITTAKE CARD


complete

[timeout]/eat card

take card/complete

eject card/

cancel trans/eject card


Or at an even higher level of abstraction :-

PROCESSTRANSACTION

IDLE


complete

[timeout]/eat card

Statechart for diagram editor

BOXSELECTED

LINEDRAWING

FILLINGDIALOG MOVING

NO BOXSELECTED

mm[not in box]/

rbd/cancel line & cross hair

mm[still in box]/

mm[ in box]/select box

mm[not in box]/de-select box

lbd [in right]/select next line

lbd[not in box]/create segment mm/draw line segment

mm/ redraw box outline

delete/remove box & lines

confirm/redraw box lbd [left]/

display dialogue

rbu/redraw box & lines cross hair

rbd[left]/ hand cursor

rbd[right]/ circle cursor

lbd[in box]/ insert line &cross hair

Representation of concurrency

This snippet of a domestic security system illustrates the use of concurrentsub diagrams with synchronising events :-

DISABLED

ARMINGdo: beep

GRACE PERIODentry: count=0

ARMEDset/arm

trigger/activate

[count>lim]/set

pulse/count++

enable

cancel

Activity diagrams Activity diagrams are a cross between Petri-Nets and Process or WorkflowDiagrams 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.

Example activity diagram The following represents a simple bespoke production system :-Customer Design dept. Commercial dept. Manufacturing

SPECIFYCUST REQ.S

ALLOCATEDESIGNER

DESIGNPRODUCT

CREATEORDER

COMPUTEPRICE

OBTAINBO ITEMS BUILD

PRODUCT

ALLOCATEBUILDER

ASSEMBLEPRODUCT

[not ok]

[ok]

Example activity diagram The following represents a simple bespoke production system :-Customer Design dept. Commercial dept. Manufacturing

SPECIFYCUST REQ.S

ALLOCATEDESIGNER

DESIGNPRODUCT

CREATEORDER

COMPUTEPRICE

OBTAINBO ITEMS BUILD

PRODUCT

ALLOCATEBUILDER

ASSEMBLEPRODUCT

CUSTREQ

ORDER

PRODUCT

DESIGNERFREE

DESIGNERALLOC

PRODUCTCOMPLETE

PRODUCT

DESIGNERFREE

[not ok]

[ok]

Cas

e S

tudy

partition

Submission Team Task Force Revision Task Force

Issue RFP

Evaluate initialsubmissions

Submitspecification

draft

Collaborate withcompetitivesubmitters

Developtechnology

specification

action state

RFP[issued]

[optional]

control flow

Finalizespecification

Specification[initial

proposal]

input value

Begin

object flow

initial state

join of control

conditionalfork

fork of control

Specification[final

proposal]

Ad

ap

ted

fro

mK

ob

ryn

, “U

ML

20

01

”C

om

mu

nic

atio

ns

of

the

AC

MO

cto

be

r 1

99

9

Cas

e S

tudy

Ad

ap

ted

fro

mK

ob

ryn

, “U

ML

20

01

”C

om

mu

nic

atio

ns

of

the

AC

MO

cto

be

r 1

99

9

Evaluate initialsubmissions

Evaluate finalsubmissions

Vote torecommend

Enhancespecification

Implementspecification

Revisespecification

Finalizespecification

Specification[final

proposal]

Specification[adopted]

Recommendrevision

Specification[revised]

[NO][YES]

[else] [Enhanced]

decision

final state

guard

Collaborate withcompetitivesubmitters


Implementation diagrams

Component diagrams

Packages and sub-systems

Deployment diagrams

Implementation issues

We have already seen how the class diagram produced during analysismay change significantly during design as we move from a conceptualmodel 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 ?

Component diagramsA component is a reusable, pluggable entity which usually consists of aset of tightly coupled objects working together for a very specificpurpose.

The component is a black box (façade pattern) and present a well definedinterface to clients. A component diagram shows component types and isequivalent to a class diagram.

black box collectionof classes

pluggable interface



<<compile>>

<<compile>>

UML has a number of predefinedstereotypes for components :-link, compile, file, library, table, document, executable

Package & Sub-system diagrams

Packages are groups of model entities - which may be individual classes and/or components. They are usually logical groupings of componentssuch as graphics packages or interface components or maths packagesetc.

Sub-systems are similar, but usually represent a functional subset of thesystem being built.

These groupings are used :-

to clarify designs

to partition work

guidance system

Deployment diagramsDeployment diagrams show the way software is distributed across theavailable hardware and the basic hardware architecture in terms ofprocessors and communication links.

GantryGantry

GantryGantry

Gantry

Transaction

Driver

<<WAN>>

*<<WAN>>

*

regional computer

gantry computer

central computer

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

An Overall Development ProcessPartially articulated requirements

Capture Requirements

Use Case Diag. Requirements

ConstructModel 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

UML-Driven Software Engineering Process

Inception Elaboration Construction Transition

Iteration 1 Iteration 2 Iteration 3

Iteration PlanningReqs Capture

Analysis & DesignImplementation

Test Prepare Release

“Mini-Waterfall” Process

Each iteration is defined in terms of the scenarios it implements

Selected scenarios

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

Release descriptionUpdated risk assessmentControlled libraries


Other topics

Mixin inheritance

Multiple inheritance

Meta-classes

Mixin inheritance

One of the problems with multiple inheritance is the ambiguity thatarises when there is a common base class :-

Here, it’s unclear what attributes andmethods class D inherits.

Mixin inheritance uses abstract propertyclasses which can be ‘mixed-in’ with aclass without leading to these problems.

This is similar to the use of interfaces in Javato provide capabilities.

AattribAmethodA

BattribBmethodB

CattribCmethodA

DattribDmethodD

Multiple inheritance

Multiple inheritance clearly presents problems as the previous slideindicated. Many OO languages avoid the problems by only implementingsingle inheritance (Smalltalk, Java, Delphi etc.)

In such languages, multiple inheritance can be simulated by acombination of aggregation and delegation :-

A B

C

A B

C

Multiple inheritance Aggregation & delegation

Meta-classes

Meta means data about data. Hence, a class (which is information aboutinstances) is a meta-instance.

However, a class is an object in its own right, hence the meta-class providesinformation about the class.

In Java the class and meta-class data are mixed together - we should really have :-

vol:BookH.G.WellsTime Machine

public class Book { private String author private String title public void lend() public void return()

}

Meta-class Book private static int numberVols; public Book(String auth, String titl){ numberVols++; etc. } public static int getNumber(){ return numberVols; }}

describes describes

Meta-classes

Java does provide a form of meta-class in the Class class. This describesthe structure of a class in terms of its components - Attributes, Methodsand Parameters.

Provides a powerful tool for introspection and aids the development ofpluggable components such as Java Beans.

The Java Class meta-class has the following structure :-

Class

Parameter

Attribute Method Exception Event

* * **

*

References

• Dr. Peter Martin http://www.cems.uwe.ac.uk/~pcsmarti/uqc816sm/uqc816sm.htm

unified modeling language. omg uml evolution from [kobryn 01a]

Documents