Other Aspects of UML

1. Other Aspects of UML Richard Hopkins rph@nesc.ac.uk UML for Use Cases NeSC, Edinburgh, Jan 5/6 2006

2. OUTLINE • Goals • To give an appreciation of full power of UML • Content • (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

3. Deployment of 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

4. Deployment • 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 –

5. STATE DIAGRAMS • Goals • To give an appreciation of full power of UML • Content • (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

6. 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 • Generic life-history of a type of entity

7. State (chart) Diagrams Statechart For Copy Class In Wings On Shelf In Bindery On Loan Reserved on Shelf Reserved In Bindery • Has full power of a programming language • trigger on an arc – e,g receipt of a message • guard on an arc – condition on moving to that state • actions on an arc – actions done in moving to next state • entry / exit actions – actions done whenever enter/leave a state • Compound states

8. COLLABORATION DIAGRAMS • Goals • To give an appreciation of full power of UML • Content • (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

9. Basic 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

10. With Messages • Messages – actual messages passed, • Show operation invoked at destination • Use 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 testing • Different perspective on a sequence diagram 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

11. CUSTOMISATION • Goals • To give an appreciation of full power of UML • Content • (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

12. Stereotypes • Adding extra classification to model elements • Either Pre-defined • Or Model-specific • Already seen some stereotypes Return Overdue Copy Use Case Diag. Pre-defined <<extend>> <<include>> Defer fine Pay fine Deployment Diag. Model-specific <<Internet>> <<LAN>> Univ:Server Clerk’s:PC User’s:PC • <<stereotype name>> - written “near” the element • Can use for any element – icon, line, operation, … • Can define a new icon for a particular stereotype – • Developing specialised language

13. Properties Book • 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 Title : String {author = Richard, reviewer = David} {isQuery = true} copiesOnShelf() : Integer {isQuery} getISBN() : ISBN

14. Pre-defined Properties • documentation= • Applies to everything • location = • Applies to most things; • Value is typically a deployment diagram node or component • persistence = • Applies to: class, association, attribute • Whether value survives system re-start • Value usually – Persistent / Transient • semantics = • Applies to class and operation

15. PACKAGES • Goals • To give an appreciation of full power of UML • Content • (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

16. Packages • Group collection of elements into a named package • which can be included in diagrams which depend on the package • NOT JUST CLASSES - • Any collection of elements ; Used in any type of diagram loaned to User Item is part of contains Is copy of Student Staff Journal Article Copy Book loaned to wants print-off of User To do with items items Dependency on something in the package Student Staff

17. 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

18. SEQUENCE DIAGRAMS • Goals • To give an appreciation of full power of UML • Content • (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

19. Sequence Diagrams 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 Replies – all shown 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 – the only “significant reply”

20. 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()

21. Synchronous Messages Synchronous – the sender suspends until receives reply Librarian theAccounts:Accounts mailer: MailingLIst loseUser owesMoney loseUser X Explicit reply to a synchronous message Because synchronous, can omit the reply Omit this one because no useful information

22. Asynchronous Messages 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

23. Conditionals • Have different objects for cataloguing books and journal • Journals and softback books are registered • Hardback books are catalogued Librarian BC :BookCatalogue JC :JournalCatalogue register(it) [Journal] catalogue(it) [hardBack] register(it) [softBack]

24. CLASS DIAGRAMS • Goals • To give an appreciation of full power of UML • Content • (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

25. Class Diagrams - Operations Book • An operation – • something that instances of this class can do, which can be externally invoked • A unit of functionality which is externally exposed • Corresponds to a Java Method • Type 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 Copy Title : String of ShelfMark : smT CopiesOnShelf() : Integer Borrow():Status Borrowed() : Status ReMark(m:smT): Copies(…) : Status

26. Item Journal Class - 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

27. Class - Interfaces • Interface - same concepts as in Java • A 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 Is part of contains Article printOffColour() printOffB&W … Journal <<interface>> Copyable Book printOffColour() printOffB&W() Pamphlet printOffColour() printOffB&W() … Redundant – don’t need both

28. Association Classes • To model there being some information and/or operations for an association between two classes • Could be done using an ordinary class takes Student Module 0..* 6 IsTaking Mark : int takes Student Module Student Module 0..* 6 0..* 6 1 1 1 1 Or - 0..* 0..* 6 6 Mark Mark Mark : int Mark : int • Less clear • Would have to implement it in one of these ways

29. Parameterised Classes • For generic, customisable type definitons T List of objects All of type T IndexedList T – type as parameter add(t : T, pos: int) get(pos : int) : T 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 <<bind>>(Book) <<bind>>(Citation) List of Citations List of Books References BookLIst Equivalent to - References BookLIst add(t : Citation, pos: int) get(pos : int) : Citation add(t : Book, pos: int) get(pos : int) : Book But this duplicates interface definition and understanding - Less clear structure ?

30. {xor} Constraints • A constraint is a condition that must be satisfied by any correct implementation. • These are class invariants • Can put constraints on other diagram types • Can be done in natural language or formally in – • Object constraint language (OCL) • Greater precision • Harder to understand Book Journal 1 1 Pre-defined constraint type – can’t be both a copy of a book and a copy of journal 1..* 1..* Copy {braille implies aisle = 6} largePrint: bool braille : bool aisle : int shelf : int Define constraints within an element or between elements

31. Object Constraint Language Manager Worker must contact his/her manger via PA, If there is one • Syntax – approximate, see http://www.omg.org/technology/documents/formal/uml.htm • Chapt 6 • Other contexts – • Class Diag. – Operation pre and post conditions • State diag., activity diag., sequence diag. - Guards hasPA : Bool phone:PhoneNo 1 {IF self . lineM . hasPA = True THEN self . lineMphone = self . lineM . myPA . Phone ELSE self . lineMphone = self . lineM . phone} myPA 0..1 Worker Administrator phone : PhoneNo lineM : Manager lineMphone : PhoneNo

32. CLASS DIAGRAMS • Goals • To give an appreciation of full power of UML • Content • (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

33. SUMMARY OF UML • Requirements – Use Case Diag. • Structure – Class, Object, Deployment, Packaging • 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 • Collaboration Diag. – • Same role as sequence diagrams, butEmphasises Object linking structure • 2. Tracks one participant through all alternative interactions • Shows how different cases interact for one participant • State(chart) Diag. • States and transitions between them • Activity Diagram – • Flow chart

34. End - references • http://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

35. Questions?