1 / 63

UML Unified Modeling Language

UML Unified Modeling Language Chapter One Introduction 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

liam
Télécharger la présentation

UML Unified Modeling Language

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

More Related