1 / 35

Other Aspects of UML

Other Aspects of UML. Richard Hopkins rph@nesc.ac.uk UML for Use Cases NeSC, Edinburgh, Jan 5/6 2006. OUTLINE. Goals To give an appreciation of full power of UML Content (increasingly more technical) New Diagrams / Concepts Component Deployment State Diagrams Collaboration Diagrams

rollo
Télécharger la présentation

Other Aspects of UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related