Introduction to UML
•
2 j'aime•2,340 vues
An introduction to understanding and using UML for object-oriented design.
Recommandé
Contenu connexe
Tendances
En vedette
Similaire à Introduction to UML
Similaire à Introduction to UML (19)
Dernier
Dernier (20)
Introduction to UML
- 2. Problems have many solutions
- 3. Design is about choosing one http://morguefile.com/archive/?display=66493 http://flickr.com/photos/chidorian/4795357/in/set-384742/
- 4. Why model?
- 6. To communicate Electronic schematic of GEE radar (AMES type 7000) used in second world war by the allies
- 7. To emphasize DaVinci’s Flush Toilet
- 8. The UML is a standard graphical notation for describing object-oriented software systems
- 9. Use UML to visualize, communicate, and emphasize your choices
- 10. 1 Library checkout 1 Membership return start : Date renewal : Date * due : Date LendRecord Lendable 1 returned : Boolean id newArrival : Boolean * LendRecord(lendable, member, date) calcDueDate(member): Date isDue() : Boolean renew(Date) * Book CD 1 * Member DVD Goal: Understand this
- 11. : Library aMember aLendable checkout(lendable, member) canBorrow(lendable) numOut(member) opt calcDueDate(member) { canBorrow == true } dueDate record new aLendRecord And this
- 12. Class Diagram Elements Class Package Class Attributes Operations
- 13. Class Diagram Elements Association multiplicity navigability role
- 14. Class Diagram Elements Complex Associations association class key value
- 15. Class Diagram Elements Dependency depends on
- 16. Class Diagram Elements Generalization superclass subclasses
- 17. Class Diagram Elements Providing and Requiring Interfaces implementor uses interface
- 18. left BinaryTree 1 0..1 0..1 1 add(obj: Obect) remove(obj) root TreeNode Object contains(obj):bool 0..1 right <<interface>> TreeIterator hasNext : bool next : Object PrefixTreeIterator PostfixTreeIterator InfixTreeIterator Example: Binary tree
- 19. 1 Library checkout 1 Membership return start : Date renewal : Date * due : Date LendRecord Lendable 1 returned : Boolean id newArrival : Boolean * LendRecord(lendable, member, date) calcDueDate(member): Date isDue() : Boolean renew(Date) * Book CD 1 * Member DVD Example: Library Classes
- 20. Sequence Diagram Elements Object lifeline object lifeline
- 21. Sequence diagram elements Object activation message activation return bar
- 22. Sequence diagram elements Object creation and deletion object creation object destruction
- 23. Sequence diagram elements Callbacks
- 24. Sequence diagram elements Object calling itself
- 25. Sequence diagram elements Loops operator guard interaction frame
- 26. Sequence diagram elements Conditionals alternative separator
- 27. aPanel child : Component dc : DrawingContext paint(dc) loop paint(dc) drawOperation(args) { forEach child } Example: Panel painting
- 28. : Library aMember aLendable checkout(lendable, member) canBorrow(lendable) numOut(member) opt calcDueDate(member) { canBorrow == true } dueDate record new aLendRecord Example: Library Checkout
- 29. 1: checkout(lendable, member) 1.1: canBorrow(lendable) :Library 1.3: record aMember 1.1.1: numOut(member) 1.2: calcDueDate(member) <<create>> 1.3.1: new aLendable aLendRecord Communication Diagram
- 30. Data View Model SQLServer Oracle Package Diagram
- 31. Actor Actor Actor start Activity fork Activity Activity {condition} Activity Activity {condition} join end Activity Diagram
- 32. <<include>> Common Role Use Case Use Case Role <<include>> Use Case Use Case Role Role Use Case Diagram
- 33. UML in UML
- 34. Resources • UML Distilled by Martin Fowler • http://bdn.borland.com/article/ 0,1410,31863,00.html • http://www.uml.org • http://www.agilemodeling.com
- 35. (cc) 2006 Lou Franco Released under the following creative commons license Attribution-NonCommercial-ShareAlike 2.0 http://creativecommons.org/licenses/by-nc-sa/2.0 Each photograph used has a URL for attribution. Please see the original site for the photo’s license.
Notes de l'éditeur
- UML is used to model OO design, but what is design?
- First there are problems, and problems have many solutions. Each solution has its own trade-offs between benefits and drawbacks.
- Design is choosing the combination of tradeoffs that best solves our problem
- 1. Faster to model than to implement 2. Helps us choose 3. Try different approaches (to compare) 4. Finish the most promising ones
- 1. Communicate to yourself 2. Communicate to implementors 3. Communicate to domain experts
- 1. Models show the important choices 2. Leave out details to emphasize 3. Several different views on same structure
- UNIFIED MODELING LANGUAGE Unifies: Booch, Rumbaugh, Jacobson Language: Can be used to implement a software system -- equivalent to code omg (uml.org) &#x201C;A specification defining a graphical language for visualizing, specifying, constructing, and documenting the artifacts of distributed object systems.&#xA0;&#x201C; Unifies 50+ OO modeling systems
- Main point
- Class name could be just the Name or Package::Name attribute spec is attribute:Type[multiplicity] = default value operation spec is operation : (arg: ArgType, arg2: Arg2Type=default) : Type
- 1. Everything is optional (name could be class name) 2. Multiplicity 3. Bidirectional
- Top is an association class, where each pairing of Library and Member is represented in a Membership class Bottom is a qualified association where Library has a map of id to Lendable. The Multiplicity is per id. Don&#x2019;t show datastructures, unless ...
- call, create, permit (friend), use
- The word generalization emphasizes the role of the base class. Don&#x2019;t think is-a -- think substitutability.
- Top one emphasizes that Clipboard uses an interface and DataObject is just one of those Bottom one emphasizes that DataObject provides an interface and Clipboard is a class that would use it
- Only time to show datastructures is if that&#x2019;s specifically what you&#x2019;re monitoring
- Objects are underlined, either the object name or the class name is optional. If just showing class, keep the colon. The lifeline is the lifetime of the object -- sequence diagrams are read top-down with time passing as we go down.
- messages are shown with arrows, returns are dashed arrows. Line arrow heads are asynch calls (but you will see half arrows used instead -- old convention). During the bar, the class is active (the message is in the stack frame)
- m calls m.1, m.2, etc. m.n calls m.n.1, m.n.2, etc. Order is 1, 1.1, 1.1.1, 1.2, 1.3, 1.3.1
- All classes in each package need to follow this dependency, classes in view can depend on classes in model, but not vice versa.
- each swim lane has an actor (who is doing the activity) diamond is a branch There are also symbols for sending and receiving signals