Title: UML and WSDL for JISC e-Learning Projects UML Details Richard Hopkins rph@nesc.ac.uk NeSC Training Team Member
1UML and WSDL for JISC e-Learning ProjectsUML
DetailsRichard Hopkins rph_at_nesc.ac.ukNeSC
Training Team Member
2Goals
- 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
3Overview
- 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
4Warning
- 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
5Simple Use Cases
Return Copy
BookBorrower
Notify lost Copy
- Use case diagram showing our first attempt at two
of the functionalities - Further consideration leads to -
6Use 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.
7Use 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
8Use 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
9Use 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
10Use 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
11Documentation - 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
12Documentation - 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
13Documentation - 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)
15Class 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
16Associations
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
17Associations
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
18Aggregation 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
19Multiplicities
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
20Navigability
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?
21Attribute / 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
22OBJECT 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)
23Complex 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
24Object 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.
25COLLABORATION 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)
26Collaboration 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
27Collaboration 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
28Collaboration 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
29SEQUENCE 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)
30Simple 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
31Creation 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()
32So 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
33Asynchronous
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
34STATE 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)
35Basic 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
36Basic 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
37Basic 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
38Statecharts
- 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
39Compound 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
40FURTHER 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
41Activity
- A flow-chart
- Used to develop implementation of object
- Also used for business level modelling
- Just give a business level example
42Business 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
43Packages
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
44Packages
- 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
45Deployment 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
46Deployment/Component Example
UsersPC
UnivServer
ClerksPC
ltltLANgtgt
ltltInternetgtgt
BBrowser
PPortal
LLibrary System
- Shows an example of intended deployment
- Shows component dependencies
Design/Implementation of Portal depends
on- Characteristics of expected user
browers Interface to Library System
47Summary
- 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
48Summary
- 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
49Summary
- 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
50Summary
- Supplementary
- Packaging
- Cut the model up into manageable pieces
- Component Deployment
- Show how the model elements manifest in the real
world
51An 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
52END
53Practical 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
541. 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)
552. 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