UML and WSDL for JISC e-Learning Projects UML Details Richard Hopkins [e-mail] NeSC Training Team Member

1
UML and WSDL for JISC e-Learning ProjectsUML
DetailsRichard Hopkins rph_at_nesc.ac.ukNeSC
Training Team Member
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

3
Overview

• Overview diagram types
• Use Case more detail
• Class - more detail
• Collaboration new
• Object new
• Sequence more detail
• State new
• Appreciation only- new
• Activity
• Packages
• Deployment
• Summary
• Exercise

4
Warning

• Exactly what is and what is not UML?
• Difficult question
• No Full implementation to test a question
• Different Author give conflicting views
• The Formal Definition is obscure

5
Simple Use Cases
Return Copy
BookBorrower
Notify lost Copy

• Use case diagram showing our first attempt at two
  of the functionalities
• Further consideration leads to -

6
Use Case Relationships
show clerk sometimes involved, sometimes
not system might record which clerk affects
class diag.
Return Copy
Clerk
Book Returner
Notify lost Copy
ltltextendgtgt a variation of the indicated base
case
ltltincludegtgt
ltltincludegtgt
Pay fine
Defer fine
ltltextendgtgt
Note Participant Inheritance BookReturner
CLerk implicitly involved in Return Overdue
Copy Pay Fine needs to be specific about
participants
ltltincludegtgt allows common sub-structure to be
factored out.
Pay fine by credit card
Generalisation /Specialisation (same arrow type
as in class diag.) a special case of.
7
Use Case Relationships
Specialisation 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
ltltextendgtgt
Return Overdue Copy
ltltincludegtgt
Pay fine
Defer fine
ltltextendgtgt
Pay fine by credit card
8
Use Case - Variants
Library
Reserve book personally
Book Reserver
Clerk
Show system boundary With system
name Particularly when A sub-system of A larger
model
ltltactorgtgtBook Reserver
Reserve Book electronically
Reserve Book
Authenticate User
The actor can be another system (a class) In
this case a library enquiry and reservation
system Which is modelled as a separate system
Electronic vs Personal reservation have different
requirements E.g. user authentication is inside
vs outside the system
9
Use Case Diagrams - Usage

• Identification of Actors and functionalities
• Requirements feed-back
• To communicate to the clients what the providers
  have understood a being the requirements
• DANGER
• generalisations, extensions and inclusions
• make the diagrams too complex and technical for
  the clients to understand properly
• Test Case generation
• Design Walk-throughs (sequence diagrams) of all
  Use Cases
• Implementation 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 design
• Keep focus on requirements documentation
• Include what is import for understanding system
  functionality

10
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 example
• See http//www.imsglbal.org/es/esv1p0/imes_usecase
  v1p0.html
• for full examples using an extension this format

11
Documentation - Essentials

• Title
• Return Overdue Book
• Brief Description
• BookReturner hands book (copy) for return to
  Clerk and the system detects that the book is
  overdue
• Actors
• BookReturner A user of the Library
• Clerk A library employee in the clerical role
• Stakeholders (those benefiting from this
  functionality)
• Users want their return of books recorded
• Clerks want to be seen to be doing their job
  properly
• Administrators Want to be able collect fines
  want to ensure records are up-to-date

12
Documentation - Details

• Triggers
• The BookReturner spontaneously decides to return
  the book, or has been prompted by a reminder
• Basic Flow of events
• BookReturner 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

13
Documentation - Details

• Pre-conditions
• The period of loan terminated by this book return
  is greater than that allowed for this type of
  user and this type of book.
• Post-conditions
• The payment of a fine is recorded, or the clerk
  agrees a deferred payment which is recorded.
• Exception Handling
• Related Use Cases
• Defer Fine
• Pay Fine by Credit Card

14

CLASS DIAGRAMS

• Overview diagram types
• Use Case more details
• Class - more detail
• Object new
• Collaboration new
• Sequence more detail
• State new (appreciation only)
• Activity - new (appreciation only)
• Packages - new (appreciation only)
• Deployment - new (appreciation only)

15
Class Relationships
User
Item
Student
Staff
Journal
Copy
Article
Book

• Generalisation ( Inheritance)
• Class relationship
• Every instance of Staff is an instance of User
• Every operation of User is an operation of Staff
• Every Attribute of User is an attribute of Staff
• Every association of User is an association of
  Staff
• This is model, not implementation
• Not 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

16
Associations
User
Item
Is part of
contains
borrows
Is copy of
Student
Staff
Journal
Copy
Article
Book
borrows
Orders print-off

• Associations knows about
• Instance oriented - A staff instance may order
  print-off of an article
• Often can only be understood by drawing instance
  example object diagram
• Class diagram records the potential actual
  associations, and defines some characteristics
• Name is associated with a line-end
• role name - what role the associated object
  plays for the other object
• Usually name at most one end

17
Associations
User
Item
Is part of
contains
borrows
Is copy of
Student
Staff
Journal
Copy
Article
Book
borrows
Orders print-off

• Associations knows about
• Subsumes entity/relationship diagrams for showing
  data structures
• Subsumes 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-versa
• Dont duplicate attributes and associations
• Copy does not need to show attribute isCopyOf
  Book

18
Aggregation and Composition
Journal
Article
Author
composition
(other) aggregation

• Special Associations
• Aggregation To model a collection of things
• Journal has a collection of Articles
• Article has a collection of Authors
• Composition
• A special case of aggregation ownership
• Part can only belong to one whole
• The part cannot exist without the whole
• Role name
• Not given explicitly implicit in the line
  end-point is part of

19
Multiplicities
Number of Copy objects that can be associated
with one student object At least 0 At most 6
0..1
Student
0..6
1
1..
Exactly 1
Copy
Book
borrows
Is copy of
0..12
Staff
0..1
0 or 1
At least 1,no upper limit

• 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 limit
• Can also do set of ranges
• 1..5 , 8..20 (hard to find an example!)
• Composition (owner) implies 1
• Note borrows has become has on loan !!!!!
• structure rather than interaction

20
Navigability
Is copy of
Is copy of
borrows
borrows
Copy
Copy
Book
Book
One-way from copy to the Book it is a copy of
Two-way Also - From a Book to any of its copies

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

21
Attribute / Operation Visibility
Book
- Title String
copiesOnShelf() Integer
Visibility public accessed by any client of
the class default for operation protected
typically from same class or sub-class package
typically anything in the same package - private
typically, from the same class - default for
attribute
22
OBJECT DIAGRAMS

• Overview diagram types
• Use Case more details
• Class - more detail
• Object new
• Collaboration new
• Sequence more detail
• State new (appreciation only)
• Activity - new (appreciation only)
• Packages - new (appreciation only)
• Deployment - new (appreciation only)

23
Complex Class Structures
0..
Book
1
by
0..
1..
0..
contains
Author
Division
1
by
1..
0..
Part
Chapter

• 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

24
Object Diagram
0..
Book
Class Diagram
1
by
0..
1..
0..
contains
Author
Division
1
by
1..
0..
Part
Chapter
Object Diagram
P11 Part Title UML
P12 Part Title WSDL

• Object Diagram does not show full range of
  possibilities
• The lines are links instances of associations
  
• Can annotate links with navigability and role if
  useful
• Special case of collaboration Diag.

25
COLLABORATION DIAGRAMS

• Overview diagram types
• Use Case more details
• Class - more detail
• Object new
• Collaboration new
• Sequence more detail
• State new (appreciation only)
• Activity - new (appreciation only)
• Packages - new (appreciation only)
• Deployment - new (appreciation only)

26
Collaboration Diagrams
theUser User
theCopy Copy
suspended No
Book Borrower
theBook Book

• To show an example of message passing interaction
  between objects
• Links - instances of class associations
• Actors/Objects
• Show name and type
• Can show values for objects where useful

27
Collaboration Diagrams
1 borrow (theCopy)
1.2 borrow ()
theUser User
theCopy Copy
suspended No
Book Borrower
1.2.1 borrowed()
1.3 borrowStatus
1.1 okToBorrow
theBook Book

• Messages actual messages passed,
• Can show operation invoked at destination
• Use self-messages to indicate internal condition
  testing
• Use structured sequence numbering scheme
• 1.1 first message produced as a result of
  receiving message 1
• 1.2 - second message produced as a result of
  receiving message 1

28
Collaboration Diagrams
1 borrow (theCopy)
1.2 borrow ()
theUser User
theCopy Copy
suspended No
Book Borrower
1.2.1 borrowed()
1.3 borrowStatus
1.1 okToBorrow
theBook Book

• Shows same kind of information as sequence
  diagram
• But with emphasis on object structure, rather
  than time sequence
• Both are interaction diagrams
• Sequence diagrams also have attribute values, if
  useful
• Same 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

29
SEQUENCE DIAGRAMS

• Overview diagram types
• Use Case more details
• Class - more detail
• Object new
• Collaboration new
• Sequence more detail
• State new (appreciation only)
• Activity - new (appreciation only)
• Packages - new (appreciation only)
• Deployment - new (appreciation only)

30
Simple Sequence Diagram
theBook Book
Book Borrower
theUser User
theCopy Copy
time
1.1 okToBorrow
1 borrow(theCopy)
1.2.1 borrowed()
1.2 borrow()
borrowStatus
Sending a message
Object existence lifeline
Period of activation
The reply
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
31
Creation and deletion
Librarian
Creation- Lifeline starts As a result of message
theCatalogueCatalogue
registerBook(theBook)
createBook(theBook)
theBook Book
Librarian
theCatalogueCatalogue
theBook Book
Deletion - Lifeline ends Marked by a cross
removeBook(theBook)
destroy()
32
So Far Synchronous Messages
Librarian
theAccountsAccounts
mailer MailingLIst
loseUser
owesMoney
loseUser

• Synchronous the sender suspends until receives
  reply
• So no need for reply to be explicit

Explicit reply to a synchronous message
33
Asynchronous
Librarian
theAccountsAccounts
mailer MailingLIst
loseUser
loseUser
owesMoney
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
34
STATE DIAGRAMS

• Overview diagram types
• Use Case more details
• Class - more detail
• Object new
• Collaboration new
• Sequence more detail
• State new
• (appreciation only)
• Activity - new (appreciation only)
• Packages - new (appreciation only)
• Deployment - new (appreciation only)

35
Basic State(chart) Diagrams
Statechart For Copy Class
In 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 in
• Identify all the possible transitions between
  states

36
Basic State(chart) Diagrams
Statechart For Copy Class
Catalogue()
Rebind()
In Wings
On Shelf
In Bindery
Reserved()
Reserved()
Borrow()
Return()
Rebind()
On Loan
Reserved on Shelf
Reserved In Bindery

• UML Statecharts
• Generic life history of objects of a particular
  class
• Named states Transition arrows
• Can associate a trigger with a transition
  e.g. receive particular message
• Dummy states
• Start State
• Final states

37
Basic State(chart) Diagrams
Statechart For Copy Class
Catalogue()
Rebind()
In Wings
On Shelf
In Bindery
Reserved()
Reserved()
Borrow()
Return()
Rebind()
On Loan
Reserved on Shelf
Reserved In Bindery

• Conveys a lot of information
• E.g. Cant remove a copy till its been catalogued
  right? Some problems?
• A basic state diag. is easy to read
• Therefore a good vehicle for requirements
  clarification
• Important to choose level of abstraction
• Actual book implementation will have more states
• Whether to show trigger

• Note its a book, not a copy that gets
  reserved!!
• this was just to make a more interesting example

38
Statecharts

• Full capabilities give programming language
  expressivity
• Most useful are
• Guards express conditions
• Compound states - abstraction

Guard identify (internal) condition on
transition being possible Trigger guard
On Shelf
Reserved()
not shortTermCopy
Reserved on Shelf
39
Compound States - Abstraction
Catalogue()
Rebind()
In Wings
On Shelf
In Bindery
Reserved()
Reserved()
Borrow()
Return()
Rebind()
On Loan
Reserved on Shelf
Reserved In Bindery
Rebind()
On Shelf
In Bindery
Reserved()
Reserved()
Borrow()
Return()
On Loan
Reserved
Give separate statechart for Reserved and On
Shelf And / or show them in-place as compound
state
40
FURTHER DIAG. TYPES

• Overview diagram types
• Use Case more details
• Class - more detail
• Object new
• Collaboration new
• Sequence more detail
• State new
• Appreciation only
• Activity
• Package
• Deployment

41
Activity

• A flow-chart
• Used to develop implementation of object
• Also used for business level modelling
• Just give a business level example

42
Business Activity Diagram
user
librarian
Find Book on shelf
borrower
returner
returning
borrowing
Synchronisation bar Start/collect concurrent
activities concurrent non-sequenced Any order
or parallel
decision
activity
guard
transition
Start / stop
43
Packages
User
Item
Is part of
contains
borrows
Is copy of
Student
Staff
Journal
Copy
Article
Book
borrows
Orders print-off
User
To do with items
items
Dependency on something in the package
Student
Staff

• Group any collection of elements and into a named
  package
• which can be included in diagrams which depend on
  the package
• Any collection of components
• Used in any type of diagram

44
Packages

• Possible reasons for use
• Just to hide irrelevant detail
• To reflect implementation team structure
• Factor the design process
• Create different namespaces
• Names must be unique within package
• Full name is package-nameelement-name
• Control visibility
• and thus reduce dependencies

45
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 links
• Location of components on H/W items

46
Deployment/Component Example
UsersPC
UnivServer
ClerksPC
ltltLANgtgt
ltltInternetgtgt
BBrowser
PPortal
LLibrary System

• Shows Hardware Structure

• Shows an example of intended deployment

• Shows component dependencies

Design/Implementation of Portal depends
on- Characteristics of expected user
browers Interface to Library System
47
Summary

• Requirements
• Use Case Diag.
• Document requirements
• Structured with extension/inclusion/specialisation
  
• Provides a handle for the supporting
  documentation, which is essential
• use-case diag. itself can be fairly vacuuous
• Structure
• Class Diag.
• Develop structure of objects in system
• Classes of objects provide the basis for
  subsequent diagrams
• Central step in firming up the system

48
Summary

• Behaviour Draws out detail
• 1. Track one example through multiple
  participants
• Show how different participants interact in one
  case
• Sequence Diag.
• Walk-through of particular use-case
• To show details of behaviour and interactions
• Important clarifications
• Collaboration Diag.
• Same role as sequence diagrams, but -
• Emphasises Object linking structure
• Sequence of events less clear
• Less useful than Sequence Diagram
• Special case is Object diagram (really structure)
• For providing examples to elucidate complex class
  structures

49
Summary

• Behaviour Draws out detail
• 1. 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

• State(chart) Diag.
• States and transitions between them
• Triggers and guards

• Activity Diagram
• Flow chart
• Can show concurrency and multiple participants
• Most useful is for modelling overall enterprise

50
Summary

• Supplementary
• Packaging
• Cut the model up into manageable pieces
• Component Deployment
• Show how the model elements manifest in the real
  world

51
An Overall Development Process
Partially articulated requirements
Capture Require- ments
REQUIREMENTS
Construct Model of Overall system
Deployment Diag..
STRUCTURE
BEHAVIOIUR
Sequence Diag. Collaboration Diag
State Diag. Activity Diag.
Single case multi-participant interaction
Single participant multi-case interaction
52
END
53
Practical Work

• Use of the Poseidon Tool (Community version)
• Examples of inputting given diagram
• Putting in some diagrams you have invented
• Requires some UML diagram creation,
• to do manually beforehand

54
1. Class Diagram Exercise

• Define a Class Diagram
• For a Journal series probably mythical
• Such 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)

55
2. Remote Borrowing Example

• We 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
  case
• A use-case diagram that combines
• The remote borrowing case
• The normal case user physically going to the
  library