Goals

1. UML and WSDL for JISC e-Learning ProjectsUML DetailsRichard Hopkins rph@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 • Use case diagram showing our first attempt at two of the functionalities • Further consideration leads to - Return Copy BookBorrower Notify lost Copy

6. <<extend>> Return Overdue Copy 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 <<extend>> – a variation of the indicated base case <<include>> <<include>> Pay fine Defer fine <<extend>> Note – Participant Inheritance BookReturner & CLerk implicitly involved in Return Overdue Copy Pay Fine needs to be specific about participants <<include>> – 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 <<extend>> Return Overdue Copy <<include>> Pay fine Defer fine <<extend>> 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 <<actor>>Book 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_usecasev1p0.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 • 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 Student Staff Journal Article Copy Book

16. Associations • 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 User Item Is part of contains borrows Is copy of Student Staff Journal Article Copy Book borrows Orders print-off

17. Associations • 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 • Don’t duplicate attributes and associations • Copy does not need to show attribute – isCopyOf : Book User Item Is part of contains borrows Is copy of Student Staff Journal Article Copy Book borrows Orders print-off

18. Aggregation and Composition 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” Journal Article Author composition (other) aggregation

19. Multiplicities Number of Copy objects that can be associated with one student object : At least 0; At most 6 • 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 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

20. Navigability • 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? 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

21. Item Journal 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 • 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 0..* Book 1 by 0..* 1..* 0..* contains Author Division 1 by 1..* 0..* Part Chapter

24. A2: Author Name: Guy C112: Chapter Title: Use Cases C111: Chapter Title: Classes B1: Book Title: UML & WSDL A2: Author Name: David A1: Author Name: Richard Object Diagram 0..* Book Class Diagram 1 • 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. by 0..* 1..* 0..* contains Author Division 1 by 1..* 0..* Part Chapter Object Diagram P11: Part Title: UML P12: Part Title: WSDL

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 • 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 theUser: User theCopy: Copy suspended: No Book Borrower theBook: Book

27. Collaboration Diagrams 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 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

28. Collaboration Diagrams • 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 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

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 theUser: User theCopy: Copy Book Borrower 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 theCatalogue:Catalogue registerBook(theBook) createBook(theBook) theBook: Book Librarian theCatalogue:Catalogue theBook: Book Deletion - Lifeline ends Marked by a cross removeBook(theBook) destroy()

32. So Far – Synchronous Messages Synchronous – the sender suspends until receives reply So no need for reply to be explicit Librarian theAccounts:Accounts mailer: MailingLIst loseUser owesMoney loseUser Explicit reply to a synchronous message

33. Asynchronous Librarian theAccounts:Accounts 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 • Conveys a lot of information • E.g. Can’t 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 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 • Note – it’s 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. Wait in queue Record return Record return description finalise Put book back On shelf 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] Start / stop transition

43. Packages • 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 User Item Is part of contains borrows Is copy of Student Staff Journal Article Copy Book borrows Orders print-off User To do with items items Dependency on something in the package Student Staff

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-name::element-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 • Shows Hardware Structure User’s:PC Univ:Server Clerk’s:PC <<LAN>> <<Internet>> B:Browser P:Portal L:Library 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

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