UML and WSDL for JISC e-Learning Projects UML Details Richard Hopkins [email protected] NeSC Training...

UML and WSDL for JISC e-Learning Projects

UML Details

Richard Hopkins [email protected]

NeSC Training Team Member

JISC UML/WSDL – UML – some details, 9th Nov. 2004 2

Goals

Goals –To understand sufficient details of UML to be able to use it as documentation for

user requirement System (service) definition

To have an appreciation of other parts of UML


Overview

Overview –diagram typesUse Case – more detailClass - more detailCollaboration – newObject – newSequence – more detailState – newAppreciation only- new Activity Packages DeploymentSummaryExercise


Warning

Exactly what is and what is not UML?Difficult questionNo Full implementation to test a questionDifferent Author give conflicting viewsThe Formal Definition is obscure


Simple Use Cases

Use case diagram showing our first attempt at two of the functionalitiesFurther consideration leads to -

BookBorrower

Return Copy

Notify lostCopy


Use Case Relationships

BookReturner

Return Copy

Notify lostCopy

Clerk

Pay fineDefer fine

Pay fine bycredit card

show clerk – sometimes involved, sometimes not system might record which clerk – affects class diag.

<<extend>> – a variation of the indicated base case

<<include>> – allows common sub-structure to be factored out.

Generalisation /Specialisation(same arrow type as in class diag.)– a special case of.

Note – Participant Inheritance

BookReturner & CLerk implicitly involved in Return Overdue Copy

Pay Fine needs to be specific about participants

Return OverdueCopy

<<extend>>

<<include>>

<<include>>

<<extend>>


Use Case RelationshipsSpecialisation vs Extension

Distinction not clear-cut (some say UML should not have both)

For extension base case can document the conditions for the extension case (“extension point”)

One possible decider -

Generalisation is when user unilaterally chooses a variant

Extension is when system detects the condition, or needs to check whether it is OK – testing internal system state

.

Return Copy

Return OverdueCopy

Pay fineDefer fine

Pay fine bycredit card

<<extend>>

<<include>>

<<extend>>


Use Case - Variants

BookReserver

Reserve book personally

Reserve Book electronically

Clerk

<<actor>>BookReserver

Reserve Book

Library

AuthenticateUser

Show system boundaryWith system nameParticularly when A sub-system ofA larger model

The actor can be another system (a class) –In this case a library enquiry and reservation systemWhich is modelled as a separate system

Electronic vs Personal reservation have different requirementsE.g. user authentication is inside vs outside the system


Use Case Diagrams - UsageIdentification of Actors and functionalitiesRequirements feed-back

To communicate to the clients what the providers have understood a being the requirementsDANGER –

generalisations, extensions and inclusions make the diagrams too complex and technical for the clients to

understand properlyTest Case generation

Design Walk-throughs (sequence diagrams) of all Use CasesImplementation tests for all Use Cases

To drive the system design (not a good use!) Producing one module of code for each use case.

Leads to top down, function-oriented system Loses the maintainability and flexibility benefits of object-

oriented designKeep focus on requirements documentation

Include what is import for understanding system functionality


Use Case Documentation

Each use case needs supporting by documentation –

the name and diagram are not enough information

Generally, this would conform to some organisation standard

An exampleSee http://www.imsglbal.org/es/esv1p0/imes_usecasev1p0.html

for full examples using an extension this format


Documentation - Essentials

Title: Return Overdue Book

Brief DescriptionBookReturner hands book (copy) for return to Clerk and the system detects that the book is overdue

Actors:BookReturner: A user of the LibraryClerk: A library employee in the clerical role

Stakeholders (those benefiting from this functionality)

Users: want their return of books recordedClerks: want to be seen to be doing their job properlyAdministrators: Want to be able collect fines; want to ensure records are up-to-date


Documentation - Details

TriggersThe BookReturner spontaneously decides to return the book, or has been prompted by a reminder

Basic Flow of eventsBookReturner hands book to Clerk. Clerk enters book return into system. System informs clerk that is over-due and what the fine is. Clerk negotiates actual or deferred payment with BookBorrower, and enters outcome to the system


Documentation - Details

Pre-conditionsThe period of loan terminated by this book return is greater than that allowed for this type of user and this type of book.

Post-conditionsThe payment of a fine is recorded, or the clerk agrees a deferred payment which is recorded.

Exception HandlingRelated Use Cases:

Defer FinePay Fine by Credit Card


Overview –diagram typesUse Case – more detailsClass - more detailObject – newCollaboration – newSequence – more detailState – new (appreciation only)Activity - new (appreciation only)Packages - new (appreciation only)Deployment - new (appreciation only)

CLASS DIAGRAMS


Class Relationships

Generalisation (= Inheritance) Class relationship –Every instance of Staff is an instance of UserEvery operation of User is an operation of StaffEvery Attribute of User is an attribute of StaffEvery association of User is an association of Staff

This is model, not implementationNot necessarily “code re-use”For a O-O language implementation –

might not be implemented as sub-class(Implementation language might not be O-O)

Its for understanding structure – although probably will drive implementation

User

Student Staff

Item

JournalBookCopy Article


Associations

Associations – knows aboutInstance oriented - A staff instance may order print-off of an articleOften can only be understood by drawing instance example – object diagramClass diagram records the potential actual associations, and defines some characteristicsName is associated with a line-end –

role name - what role the associated object plays for the other object

Usually name at most one end

User

Student Staff

Item


borrows

borrows

Is copy of

Is part of

Orders print-off

contains


Associations

Associations – knows aboutSubsumes entity/relationship diagrams for showing data structuresSubsumes inter-connection diagrams for showing which entities communicate

Conceptual View (user communication) there is an association if there is a relevant real-world association – “a student can borrow a book”

Implementation View (design)A (navigable) association implies a class has an attribute of the associated type, and vice-versaDon’t duplicate attributes and associations

Copy does not need to show attribute – isCopyOf : Book

User

Student Staff

Item


borrows

borrows

Is copy of

Is part of

Orders print-off

contains


Aggregation and Composition

Special AssociationsAggregation – To model a collection of things

Journal has a collection of ArticlesArticle has a collection of Authors

Composition A special case of aggregation – “ownership”Part can only belong to one wholeThe part cannot exist without the whole

Role nameNot given explicitly – implicit in the line end-point – “is part of”

Journal Article Author

composition (other) aggregation


Multiplicities

Constrains the number of instance of one end that can be associated with one instance of the other end (in this association type, at any one time)

Either – single number (usually 0 or 1)Or range X .. Y.

* for Y means no upper limitCan also do set of ranges –

1..5 , 8..20 (hard to find an example!)Composition (“owner”) implies 1Note – “borrows” has become “has on loan” !!!!! –

structure rather than interaction

Student

Staff

BookCopyborrowsIs copy

of

0..1

0..1

0..6

0..12

11..*

Number of Copy objects that can be associated with one student

object : At least 0; At most 6

At least 1,no upper limit

Exactly 1

0 or 1


Navigability

Arrow-head means the association can be followed in the direction shownIn implementation view, navigability requires attributes to hold the link(s)to associated object(s)How to show navigability and aggregation?

BookCopy

borrows Is copy of

BookCopy

borrows Is copy of

One-way from copy to theBook it is a copy of

Two-wayAlso -From a Book to any of its copies


Attribute / Operation 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


OBJECT DIAGRAMS



Complex Class Structures

The intended structure would be elucidated by giving some examples !

Particularly if audience is not familiar with this particular view on the possible structure of book

So illustrate the class diagram by one or more instance diagrams

Part

Book1

Author1..*

Division

0..*

0..*0..*

1

Chapter0..*

1..*

contains

by

by


Object Diagram

Object Diagram does not show full range of possibilitiesThe lines are “links” – instances of associations Can annotate links with navigability and role if usefulSpecial case of collaboration Diag.

Class Diagram

B1: BookTitle: UML & WSDL

P11: PartTitle: UML

P12: PartTitle: WSDL

A1: AuthorName: Richard

A2: AuthorName: David

C111: ChapterTitle: Classes

C112: ChapterTitle: Use Cases

Object Diagram

Part

Book 1

Author1..*

Division

0..*

0..*0..*

1

Chapter0..*

1..*

contains

by

by

A2: AuthorName: Guy


COLLABORATION DIAGRAMS



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



Messages – actual messages passed, Can show operation invoked at destinationUse self-messages to indicate internal condition testingUse structured sequence numbering scheme1.1 – first message produced as a result of receiving message 11.2 - second message produced as a result of receiving message 1

BookBorrower


theBook: Book

suspended: No

1: borrow (theCopy) 1.2: borrow ()

1.1: okToBorrow

1.2.1: borrowed()1.3: borrowStatus



Shows same kind of information as sequence diagramBut with emphasis on object structure, rather than time sequenceBoth are interaction diagramsSequence diagrams also have attribute values, if usefulSame Structured sequence numbering

Generally, Sequence diagrams more useful for understanding system behaviour – shows the time sequence more clearly

Use collaboration diagrams without specific messages, to exemplify system interconnection structure

BookBorrower


theBook: Book

suspended: No

1: borrow (theCopy) 1.2: borrow ()

1.1: okToBorrow

1.2.1: borrowed()1.3: borrowStatus


SEQUENCE DIAGRAMS



Simple Sequence Diagram

Shows all replies ; Uses structured sequence numbering

1 BookBorrower invokes the use case -activates corresponding theUser object

1.1 theUser checks whether this is OK – self message

1.2 theUser tells theCopy object that it is now borrowed – it changes its state

1.2.1. theCopy tells theBook that it has been borrowed –

it reduces its count of available copies

Reply - theUser confirms success to BookBorrower

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 message

The reply

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


So Far – Synchronous Messages

Synchronous – the sender suspends until receives replySo no need for reply to be explicit

LibrariantheAccounts:Accounts

loseUser

owesMoney

mailer: MailingLIst

loseUser

Explicit reply to a synchronous message


Asynchronous

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


STATE DIAGRAMS

Overview –diagram typesUse Case – more detailsClass - more detailObject – newCollaboration – newSequence – more detailState – new

(appreciation only)Activity - new (appreciation only)Packages - new (appreciation only)Deployment - new (appreciation only)


Basic State(chart) DiagramsIn Wings On Shelf In Bindery

On Loan Reserved on Shelf Reserved In Bindery

Based on finite state machine concept Identifying all the different states a discrete-state system can be inIdentify all the possible transitions between states

StatechartFor Copy Class


Basic State(chart) Diagrams

In Wings Catalogue() On Shelf In BinderyRebind()

On Loan

Borrow()Return()

Reserved on Shelf Reserved In BinderyRebind()

Reserved()Reserved()

UML StatechartsGeneric life history of objects of a particular classNamed states; Transition arrowsCan associate a “trigger” with a transition ; e.g. receive particular messageDummy states

Start State Final states



Basic State(chart) Diagrams

Conveys a lot of informationE.g. Can’t remove a copy till its been catalogued – right?; Some problems?

A basic state diag. is easy to readTherefore a good vehicle for requirements clarificationImportant to choose level of abstraction Actual book implementation will have more statesWhether to show trigger


On Loan

Borrow()Return()




Note – it’s a book, not a copy that gets reserved!! – this was just to make a more interesting example


StatechartsFull capabilities give programming language expressivityMost useful are –

Guards – express conditionsCompound states - abstraction

On Shelf

Reserved on Shelf

Reserved()

Guard identify (internal) condition on

transition being possibleTrigger [guard]

[not shortTermCopy]


Compound States - Abstraction


On Loan

Borrow()Return()



On Shelf + In BinderyRebind()

On Loan

Borrow()Return()


Reserved

Give separate statechart for Reserved and On Shelf +And / or show them in-place as compound state


FURTHER DIAG. TYPES

Overview –diagram typesUse Case – more detailsClass - more detailObject – newCollaboration – newSequence – more detailState – newAppreciation only

Activity Package Deployment


Activity

A flow-chartUsed to develop implementation of objectAlso used for business level modellingJust give a business level example


Business Activity Diagram

Find Book on shelf

user

[borrower]

Wait in queue[returner]

Recordreturn

Put book backOn shelf

Recordreturn

[returning]

[borrowing]

librarian

finalise

decision

[guard]transition

description activity

Start / stop

Synchronisation bar –Start/collect concurrent activities“concurrent” = non-sequencedAny order or parallel


Packages

Group any collection of elements and into a named package which can be included in diagrams which depend on the packageAny collection of componentsUsed in any type of diagram

User

Student Staff

Item


borrows

borrows

Is copy of

Is part of

Orders print-off

contains

User

Student Staff

items

To do with items

Dependency on something in the package


Packages

Possible reasons for useJust 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


Deployment and Components

Component (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/Component Example

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 –

Design/Implementation of Portal depends on-Characteristics of expected user browersInterface to Library System


Summary

RequirementsUse Case Diag.

Document requirementsStructured with extension/inclusion/specialisationProvides a handle for the supporting documentation, which is essential – use-case diag. itself can be fairly vacuuous

StructureClass Diag.

Develop structure of objects in systemClasses of objects provide the basis for subsequent diagramsCentral step in firming up the system


SummaryBehaviour – Draws out detail1. Track one example through multiple participants

Show how different participants interact in one case

Sequence Diag.Walk-through of particular use-caseTo show details of behaviour and interactionsImportant clarifications

Collaboration Diag.Same role as sequence diagrams, but - Emphasises Object linking structure Sequence of events less clear Less useful than Sequence DiagramSpecial case is Object diagram (really structure) For providing examples to elucidate complex class

structures


SummaryBehaviour – Draws out detail1. Track one example through multiple participants

Show how different participants interact in one case 2. Tracks one participant through all alternative

interactions –Shows how different cases interact for one participant the orthogonal perspective

Activity DiagramFlow chart Can show concurrency and multiple participantsMost useful is for modelling overall enterprise

State(chart) Diag.States and transitions between themTriggers and guards


Summary

SupplementaryPackaging

Cut the model up into manageable pieces

Component DeploymentShow how the model elements manifest in the real world


An Overall Development Process

Partially articulated requirements

Use Case Diag.

Capture Require-

ments

REQUIREMENTS

Class Diag.

Sequence Diag.Collaboration Diag

ConstructModel ofOverall system

STRUCTURE

Single casemulti-participant interaction

Deployment Diag..

State Diag.Activity Diag.

Single participantmulti-case interaction

BEHAVIOIUR


END


Practical Work

Use of the Poseidon Tool (Community version)

Examples of inputting given diagramPutting in some diagrams you have invented

Requires some UML diagram creation, to do manually beforehand –


1. Class Diagram Exercise

Define a Class Diagram For a Journal series – probably mythicalSuch that the it can support the requirements –

Users being able to do searches on: author, keyword, ….. (anything else you think appropriate)

Staff being able to find out the status – On-the-shelf Being-bound … (anything else you think appropriate)


2. Remote Borrowing ExampleWe add to the Library System the requirement that

a member of staff can electronically submit a request to borrow an item

if successful, the request results in the item being posted to them in the internal University

snail-mail system. the use case(s) for this must include verifying the staff members identity

Do (at least) a sequence diagram for this remote-borrowing caseA use-case diagram that combines

The remote borrowing case The normal case – user physically going to the library

UML and WSDL for JISC e-Learning Projects UML Details Richard Hopkins [email protected] NeSC Training...

Documents

Transcript of UML and WSDL for JISC e-Learning Projects UML Details Richard Hopkins [email protected] NeSC Training...