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
<<docum ent>>UM L 1.2
<<docum ent>>UM L 1.3
<<docum ent>>UM L 1.4
<<docum ent>>UM L 2.0
Infrastructure
<<docum ent>>UM L 2.0
<<docum ent>>UM L 2.0
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
usage statisticstraffic flows
hour of the day
Implementation classesSystemtoll
motoristtoll boothpayment
radar receivertransmittercamera
signal
Transaction regional centre
central systemmagnetic cardpayment machine
credit balance
computer registration number
locationtime
Fee
warning signaltraffic eventgantry direction
traffic density
display
closed circuit TV
usage statisticstraffic flows
hour of the day
Attributes of other classes
toll
motorist
payment
radar receivertransmittercamera
signal
Transaction regional centre
central system
payment machine
credit balance
registration number
locationtime
Fee
warning signaltraffic eventgantry direction
traffic density
usage statisticstraffic flows
hour of the day
Verbs or events
motorist
payment
radar receivertransmittercamera
signal
Transaction regional centre
central system
payment machine
warning signaltraffic eventgantry
Final class list
motorist
radar receivertransmittercamera
Transaction regional centre
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
The Unified Modelling Language (UML)
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
Collaboration 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
Collaboration diagrams
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
The Unified Modelling Language (UML)
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
Statechart for a simple ATM
This becomes the following at a higher level of abstraction:-
IDLE
OBTAINPIN & CHOICE
AWAITTAKE CARD
insert card/prompt for pin
complete
[timeout]/eat card
take card/complete
eject card/
cancel trans/eject card
Statechart for a simple ATM
Or at an even higher level of abstraction :-
PROCESSTRANSACTION
IDLE
insert card/prompt for pin
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
The Unified Modelling Language (UML)
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
black box collectionof classes
black box collectionof classes
<<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
The Unified Modelling Language (UML)
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