Other Aspects of UML

Other Aspects of UML

Richard [email protected]

UML for Use CasesNeSC, Edinburgh, Jan 5/6 2006

mailto:[email protected]

UML for Use Cases, Jan 5/6 2006 Other Aspects of UML 2

OUTLINEGoals

To give an appreciation of full power of UMLContent

(increasingly more technical)New Diagrams / Concepts

Component Deployment State Diagrams Collaboration Diagrams Customisation – stereotypes and properties Packages

Further Features of previous diagrams Sequence Diagrams Class Diagrams

References and Summary


Deployment of ComponentsComponent (here) –

“a distributable piece of an implementation of a system, including S/W code , but also including business documents etc. in a human system”A WSDL definition could usefully viewed as a component

Deployment Diagram shows –Hardware items and physical communication linksLocation of components on H/W items


Deployment

Shows Hardware Structure

<<Internet>> <<LAN>>User’s:PC

B:Browser P:Portal L:LibrarySystem

Univ:Server Clerk’s:PC

Shows an example of intended deployment

Shows component dependencies –


STATE DIAGRAMSGoals







State (chart) Diagrams

Based on finite state machine concept Identifying all the different states a discrete-state system can be inIdentify all the possible transitions between statesGeneric life-history of a type of entity

In Wings On Shelf In Bindery

On Loan Reserved on Shelf Reserved In Bindery

StatechartFor Copy Class


State (chart) Diagrams

Has full power of a programming languagetrigger on an arc – e,g receipt of a messageguard on an arc – condition on moving to that stateactions on an arc – actions done in moving to next stateentry / exit actions – actions done whenever enter/leave a stateCompound states

In Wings On Shelf In Bindery

On Loan Reserved on Shelf Reserved In Bindery

StatechartFor Copy Class


COLLABORATION DIAGRAMSGoals







Basic Collaboration Diagrams

To show an example of message passing interaction between objectsLinks - instances of class associations

Actors/Objects – Show name and typeCan show values for objects where useful

BookBorrower

theUser: User theCopy: Copy

theBook: Book

suspended: No


With Messages

BookBorrower

theUser: User theCopy: Copy

theBook: Book

suspended: No

1: borrow (theCopy) 1.2: borrow ()

1.1: okToBorrow

1.2.1: borrowed()1.3: borrowStatus

Messages – actual messages passed, Show operation invoked at destinationUse structured sequence numbering scheme

1.2 – second message produced as a result of receiving message 1

1.2.1 - first message produced as a result of receiving message 1.2

Use self-messages to indicate internal condition testingDifferent perspective on a sequence diagram


CUSTOMISATIONGoals







StereotypesAdding extra classification to model elements

Either Pre-definedOr Model-specific

Already seen some stereotypes

<<Internet>> <<LAN>>Univ:Server Clerk’s:PCUser’s:PC

Deployment Diag.Model-specific

Return OverdueCopy

Pay fine Defer fine<<include>> <<extend>> Use Case Diag.Pre-defined

<<stereotype name>> - written “near” the elementCan use for any element – icon, line, operation, …Can define a new icon for a particular stereotype –

Developing specialised language


Properties

A model element can have a value for a property – {isQuery = true}Boolean property values can be written {X} rather than {X = true}

A way of recording design information

BookTitle : String

copiesOnShelf() : Integer

getISBN() : ISBN

{isQuery = true}

{isQuery}

{author = Richard,reviewer = David}


Pre-defined Propertiesdocumentation=

Applies to everythinglocation =

Applies to most things; Value is typically a deployment diagram node or component

persistence =Applies to: class, association, attributeWhether value survives system re-startValue usually – Persistent / Transient

semantics =Applies to class and operation


PACKAGESGoals







Packages

Group collection of elements into a named package which can be included in diagrams which depend on the packageNOT JUST CLASSES -Any collection of elements ; Used in any type of diagram

User

Student Staff

items

To do with items

Dependency on something in the package

User

Student Staff

Item

JournalBookCopy Articleloaned to

Is copy of

is part of

wants print-off of

containsloaned to


PackagesPossible reasons for use

Just to hide irrelevant detailTo reflect implementation team structureFactor the design processCreate different namespaces

Names must be unique within package Full name is package-name::element-name

Control visibility – and thus reduce dependencies


SEQUENCE DIAGRAMSGoals







Sequence Diagrams

Uses structured sequence numbering1 BookBorrower invokes the use case -activates corresponding theUser object1.1 theUser checks whether this is OK – self message1.2 theUser tells theCopy object that it is now borrowed – it changes its state1.2.1. theCopy tells theBook that it has been borrowed – it reduces its count of available copiesReply - theUser confirms success to BookBorrower – the only “significant reply”

BookBorrower

theUser: User theCopy: Copy theBook: Book

time

Object existence lifeline Period of activation

1: borrow(theCopy)

1.2.1: borrowed()1.2: borrow()

borrowStatus

Sending a messageReplies – all shown

1.1: okToBorrow


Creation and DeletionLibrarian

theCatalogue:Catalogue

theBook: Book

registerBook(theBook)

createBook(theBook)

theCatalogue:Catalogue theBook: Book

removeBook(theBook)

destroy()

Librarian

Creation- Lifeline startsAs a result of message

Deletion -Lifeline endsMarked by a cross


Synchronous Messages

Synchronous – the sender suspends until receives reply

LibrariantheAccounts:Accounts

loseUser

owesMoney

mailer: MailingLIst

loseUser

Explicit reply to a synchronous messageBecause synchronous, can omit the replyOmit this one because no useful information

X


Asynchronous Messages

Asynchronous – the sender retains control and can send and receive further messages

other versions of arrow heads are also used

Unspecified (simple) – could be synchronous or asynchronous

LibrariantheAccounts:Accounts

loseUser

owesMoney

mailer: MailingLIst

loseUser


Conditionals

Have different objects for cataloguing books and journalJournals and softback books are registeredHardback books are catalogued

LibrarianBC :BookCatalogue

register(it) [Journal]

JC :JournalCatalogue

catalogue(it) [hardBack]

register(it) [softBack]


CLASS DIAGRAMSGoals







Class Diagrams - OperationsBook

Title : String

CopiesOnShelf() : Integer

Copyof ShelfMark : smT

Borrow():Status

ReMark(m:smT):

An operation – something that instances of this class can do, which can be externally invokedA unit of functionality which is externally exposedCorresponds to a Java MethodType for each parameter and the result (“void” if no result)Direction for each parameter – in, out, inout

UML terminology is message-passing -An object’s operation is invoked by another object sending it a message

Borrowed() : Status

Copies(…) : Status


Class - Visibility

Book- Title : String

+ copiesOnShelf() : Integer

Item

Journal

Visibility+ public accessed by any client of the class –

default for operation# protected typically from same class or sub-class~ packagetypically anything in the same package- private typically, from the same class -

default for attribute


Class - InterfacesInterface - same concepts as in JavaA collection of operations which must be supported by any class claiming to support the interface (“match” the interface; “realise” the interface)“supports” is shown as specialisation with dashed arrow An interface is like a class but has no instances – no attributes, no associations

Item

JournalBook

Article

Is part of

contains

<<interface>>CopyableprintOffColour()printOffB&W()

printOffColour()printOffB&W…

Redundant – don’t need both

PamphletprintOffColour()printOffB&W()…


Association Classes

To model there being some information and/or operations for an association between two classesCould be done using an ordinary class

Student Moduletakes

60..*

IsTaking

Mark : int

Student Moduletakes

60..*

Mark

Mark : int

0..*6

1 1Student Module

60..*

Mark

Mark : int

0..*6

1 1Or -

• Less clear• Would have to implement it in one of these ways


Parameterised Classes

BookLIst

IndexedList

add(t : T, pos: int)get(pos : int) : T

T

<<bind>>(Book)

References

<<bind>>(Citation)

T – type as parameter List of objects All of type T

List of Books

List of Citations

References

add(t : Citation, pos: int)get(pos : int) : Citation

BookLIst

add(t : Book, pos: int)get(pos : int) : Book

Equivalent to -

But this duplicates interface definition and understanding - Less clear structure ?

Implementation language might not have parameterised types –Still may be better to• Use parameterised types in the data structure model• Use equivalent explicit types in implementation

For generic, customisable type definitons


Constraints

A constraint is a condition that must be satisfied by any correct implementation.These are class invariantsCan put constraints on other diagram typesCan be done in natural language or formally in – Object constraint language (OCL)

Greater precisionHarder to understand

Journal Book

Copy

largePrint: boolbraille : boolaisle : intshelf : int

1..*

1 1

1..*

{braille implies aisle = 6}

Pre-defined constraint type – can’t be both a copy of a book and a copy of journal

{xor}

Define constraints within an element or between elements


Object Constraint Language

Syntax – approximate, see http://www.omg.org/technology/documents/formal/uml.htm

Chapt 6Other contexts –

Class Diag. – Operation pre and post conditionsState diag., activity diag., sequence diag. - Guards

Manager

hasPA : Boolphone:PhoneNo

Worker

lineM : ManagerlineMphone : PhoneNo

Administrator

phone : PhoneNo

{IF self . lineM . hasPA = True

THEN self . lineMphone =

self . lineM . myPA . Phone

ELSE self . lineMphone =

self . lineM . phone}

myPA0..1

1

Worker must contacthis/her manger via PA,If there is one

http://www.omg.org/technology/documents/formal/uml.htm


CLASS DIAGRAMSGoals







SUMMARY OF UMLRequirements – Use Case Diag.Structure – Class, Object, Deployment, PackagingBehaviour – Draws out detail1. Track one example through multiple participants

Show how different participants interact in one caseSequence Diag – Walk-through of particular use-caseCollaboration Diag. – Same role as sequence diagrams, butEmphasises

Object linking structure2. Tracks one participant through all alternative interactions

Shows how different cases interact for one participant State(chart) Diag. States and transitions between themActivity Diagram – Flow chart


End - referenceshttp://www.omg.org/technology/documents/formal/uml.htm

UML Pocket Reference, O’Reilly,ISBN: 0-596-00497-4

UML in a Nutshell

Using UML – Software Engineering with Objects and Components, Perdita Stevens with Rob Pooley

ISBN: 0-201-64860-1




Questions?

Documents

Other Aspects of UML