UML Unified Modeling Language - PowerPoint PPT Presentation

liam
uml unified modeling language l.
Skip this Video
Loading SlideShow in 5 Seconds..
UML Unified Modeling Language PowerPoint Presentation
Download Presentation
UML Unified Modeling Language

play fullscreen
1 / 63
Download Presentation
UML Unified Modeling Language
370 Views
Download Presentation

UML Unified Modeling Language

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. UML Unified Modeling Language © Wolfgang Pelz 2000-04

  2. Chapter OneIntroduction © Wolfgang Pelz 2000-04

  3. District Module Semi-Auto Fill Delivery Status Order Requested Order Initiated Order Approved Order Filled Application Server Central-Office Module Database Server Sign-Shop Module Figure 4 Data Flow of Sign Orders © Wolfgang Pelz 2000-04

  4. Engineering and Blueprints • standard notation • communication tool © Wolfgang Pelz 2000-04

  5. History • CASE Tools: Automation of Software Development • People-to-People • People-to-Computer • Rational Software (An IBM Company) • Rational Rose / MS Visio: Converting UML-Diagrams-to-Programs • OMG: Object Management Group © Wolfgang Pelz 2000-04

  6. History • Booch: Booch Method • Rumbaugh: OMT (object modeling tech.) • Jacobson: OOSE (OO software engrg.) • Three amigos: UML © Wolfgang Pelz 2000-04

  7. History • UML: an open standard controlled by OMG • UML 1.0 (1997) • UML 2.0 (2004) © Wolfgang Pelz 2000-04

  8. Meta-Model • a diagram that defines the notation to be used in the modeling language © Wolfgang Pelz 2000-04

  9. class object component package deployment use case interaction communication sequence collaboration timing activity state/statechart UML supported diagrams © Wolfgang Pelz 2000-04

  10. Brief Overview • class - set of classes, interfaces, collaboration, relationships • object - set of objects and their relationships • use case - description of functionality provided by system along with actors and their connection to the use case © Wolfgang Pelz 2000-04

  11. Overview (cont.) • interaction - set of objects and their relationships including messages • state/statechart - a state machine showing states, transitions, events, and activities • activity - statechart sequential flow of activities • component - physical structure of code in terms of code components © Wolfgang Pelz 2000-04

  12. Overview (cont.) • deployment - physical architecture of hardware and software in the system • package - shows packages of classes and dependencies among them • grouping mechanism • form of class diagram • also called subsystem © Wolfgang Pelz 2000-04

  13. domain expert use case activity interaction system designer class component deployment state package Organization of Diagrams © Wolfgang Pelz 2000-04

  14. static class component package deployment dynamic use case interaction state activity Another Organization © Wolfgang Pelz 2000-04

  15. Another Organization © Wolfgang Pelz 2000-04

  16. Model Terminology • user model view - problem and solution from the perspective of the users • structural model view - static or structural aspects of a problem and solution • behavioral model view - dynamic or behavioral aspects; interactions or collaborations among problem and solution elements © Wolfgang Pelz 2000-04

  17. Model Terminology • implementation model view - structural and behavioral aspects of the solution’s realization • environment model view - structural and behavioral aspects of the domain in which a solution must be realized © Wolfgang Pelz 2000-04

  18. Language versus Method • A (software engineering) method is composed of a language and a process. • UML is a language, not a method, since it has no notion of process • process can be: © Wolfgang Pelz 2000-04

  19. © Wolfgang Pelz 2000-04

  20. Terminology • inception - a few days’ work to decide if a few months of elaboration is worth it • elaboration - risk assessment, about 1/5 of project time; includes planning based on use cases; generates a commitment schedule • construction - composed of iterations that include refactoring, frameworks & patterns • transition - beta testing, optimizing, training © Wolfgang Pelz 2000-04

  21. Refactoring the process of changing the internal structure of a program or system to make it easier to understand or change while maintaining its functionality © Wolfgang Pelz 2000-04

  22. Frameworks & Patterns • frameworks are reusable designs of all or part of a software system described by a set of abstract classes and the way instances of those classes collaborate • patterns are common designs that have repeating themes © Wolfgang Pelz 2000-04

  23. Chapter ThreeClass Diagram © Wolfgang Pelz 2000-04

  24. Class Diagram • static view of a system in terms of classes and relationships among the classes • associations • subtypes • typically done in parallel with interaction diagrams • a more graphical alternative to CRC cards © Wolfgang Pelz 2000-04

  25. Important Questions(Finding classes) • Is there information to be stored/analyzed? • Do external systems exist? • Are there patterns, class libraries, components, etc? • Must the system handle devices? • Are there organizational parts (business model)? • Do actors have roles to play in the system? © Wolfgang Pelz 2000-04

  26. Common Uses • Objective: provide a view of services the system should provide to its end user • model the vocabulary of a system • model simple collaborations • model a logical database schema © Wolfgang Pelz 2000-04

  27. Terminology • association: a description of a related set of links between objects of two classes • subtype: “is a” or “is a kind of” • generalization: relationship between a more general and a more specific element - see subtype © Wolfgang Pelz 2000-04

  28. Terminology (cont.) • dependency: relationship where a change in the independent element affects the dependent element • refinement: relationship between two descriptions of the same thing, but at different levels of abstraction © Wolfgang Pelz 2000-04

  29. Terminology (cont.) • Aggregation: association specifying a whole-part relationship between the aggregate (whole) and a component (part). An aggregation may not have any components and a component may not belong to any aggregation. • composition: special form of aggregation (a component must belong to a composition and only to one composition) • strong ownership • coincident lifetime of parts and whole © Wolfgang Pelz 2000-04

  30. Notation © Wolfgang Pelz 2000-04

  31. More Notation © Wolfgang Pelz 2000-04

  32. Aggregation/Composition © Wolfgang Pelz 2000-04

  33. Example © Wolfgang Pelz 2000-04

  34. Levels of Abstraction • conceptual model: class name • associations are conceptual relationships • specification model: above + behavior • associations and responsibilities • implementation model: above + state • probably too low-level for design stage © Wolfgang Pelz 2000-04

  35. Another Example © Wolfgang Pelz 2000-04

  36. Associations • Describe relations between classes • associations have roles (given at the end of the association) which have multiplicities • associations have navigability • A sends a message to B • A creates an instance of B • A needs to maintain a connection with B • navigability is identified from collaboration diagrams © Wolfgang Pelz 2000-04

  37. Associations (cont.) • navigability in one direction is termed uni-directional association and has an arrow • two-way navigability is bi-directional association and has no arrow • an association with no arrow could also mean that the direction is unknown • bidirectional requires inverse relationship f ( f -1(y)) = y f -1( f (x)) = x © Wolfgang Pelz 2000-04

  38. Operation Signatures visibilityname(parameters) : return type optional optional + public # protected - private • Example: + getData (pos : Position) : Data © Wolfgang Pelz 2000-04

  39. Operations & Methods • Operation • something invoked on an object which in turn is implemented by a method • Method (in coding not design method) • body of the procedure • polymorphism forces a distinction between the two (all siblings have the same operation but different methods) © Wolfgang Pelz 2000-04

  40. Steps to create a Class Diagram • Identify classes using the interaction diagram and place them in the class diagram • get attributes from the conceptual model and the method names from the interaction diagram • add type information and associations based on attribute visibility • add navigability arrows and dependencies © Wolfgang Pelz 2000-04

  41. Another Example © Wolfgang Pelz 2000-04

  42. Cautions • start small • perspective should match activity • analysis: conceptual model • software: specification model • don’t go to details too early © Wolfgang Pelz 2000-04

  43. Dependency Relationship • One element (of any kind, including classes, use cases, etc.) has knowledge of another element • if one element changes, the other might have to change as well • differs from plain attribute visibility which uses regular association line and a navigability arrow © Wolfgang Pelz 2000-04

  44. Example revisited © Wolfgang Pelz 2000-04

  45. Example with Dependency © Wolfgang Pelz 2000-04

  46. Interface • Interface is a class of abstract/pure virtual functions. • All functions in the interface are public. • Interface cannot be used to instantiate objects. • There is no data members in an interface class. • UML: use <<interface>> to prefix the class name. © Wolfgang Pelz 2000-04

  47. Abstract Class • An abstract class has one or more abstract/pure virtual functions. • An abstract class cannot be used to instantiate objects. • An abstract class can contain data members. • UML: use Abstract to prefix the class name. © Wolfgang Pelz 2000-04

  48. ExamplesFigures in UML Distilled. © Wolfgang Pelz 2000-04

  49. Chapter 6 Object Diagrams © Wolfgang Pelz 2000-04

  50. Object Diagrams • A snapshot of the objects in a system at a point in time. • Also called instance diagrams. • Useful of showing object connections (not interactions) • Can be thought of as collaboration/communication diagram without messages. • Naming convention (did not change as sequence diagram did): © Wolfgang Pelz 2000-04