Published on

Published in: Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • This is a brief introduction to the Unified Modeling Language. Before looking into the UML we will recap a few principles and terms of object-orientation. We’ll then look at each of the eight different UML diagrams and show where they are used in the system development life cycle.
  • (Notes same as slide)
  • This is a comparison of traditional analysis and design with object-oriented analysis and design. The essential difference is the focus on the interactions among “things” in the world.
  • (Notes same as slide)
  • (Notes same as slide)
  • There is a difference between services (common methods shared among objects) and methods used by individual objects.
  • Encapsulation and Information Hiding are different ways to say the same thing. The term “Encapsulation” is used by different O-O practitioners differently. This is the common understanding.
  • (Notes same as slide)
  • The eight diagrams are used for different purposes.
  • Use Cases are used for requirements. Most practitioners use them along with scenarios (English textual descriptions) to define user requirements. Jacobson, the originator of use cases, used them to specify not just user requirements, but as a plan at the beginning of each phase of the system development life cycle.
  • The static view has one diagram. The dynamic view has four diagrams.
  • (Notes same as slide)
  • These have counterparts in traditional entity-relationship modeling.
  • Basic association notation.
  • Association notation. In practice use either names or roles (or neither).
  • Association notation. Qualifiers are used only when a strong attribute is observed that sheds light on the business rules. Multiplicity is similar to cardinality in E-R diagrams.
  • Association notation. Association classes are roughly similar to similar structures in E-R notation, but are not used to resolve many-to-many key relationships.
  • Association notation. N-ary associations often arise during the first pass of class modeling.
  • Generalization notation: “Kind-of” relationships.
  • One kind of collection: aggregation (“Part-of relationships). When the parent dies the children survive.
  • A stronger collection: composition. Subclass existence depends upon the superclass existence.
  • The static view has one diagram. The dynamic view has four diagrams.
  • The four dynamic diagrams.
  • Sequence diagrams are popular, especially in the design phase. They show messages between objects and have a temporal dimension.
  • Collaboration diagrams are similar to sequence diagrams. Collaborations can be hard to read because they do not show the time component like sequence diagrams.
  • Statecharts are similar to traditional state-transition diagrams.
  • Statechart example.
  • Activity diagrams are popular among some practitioners. They are also very useful during the transition from requirements gathering into analysis modeling.
  • Activity diagram example using swimlanes to separate responsibilities.
  • Implementation diagrams partition the in-work deliverables into the physical structure showing where different packages will live in terms of the logical architecture. They are roughly similar to code libraries. The small rectangles are embedded packages.
  • Implementation diagrams partition the system into its physical structure. They show where different package units will live in terms of the physical hardware (e.g., client, servers, persistence servers).
  • A package is not a diagram it is a container of diagrams. A large system design has many models, submodels, diagrams, definitions, and other in-work deliverables. Packages help manage the project deliverables.
  • (Notes same as text)
  • The eight diagrams are used for different purposes.
  • The eight diagrams are used for different purposes.
  • The eight diagrams are used for different purposes.
  • The eight diagrams are used for different purposes.
  • UML

    1. 1. Unified Modeling Language Overview 1. Object-orientation: Terms and concepts. 2. Use Cases: Requirements model 3. Class Diagram: The static model 4. Behavioral Modeling: The four dynamic diagrams 5. Implementation: The two physical models 1
    2. 2. Introduction  Object-Oriented (O-O) systems development is a way to develop software by building self- contained modules that can be more easily:  Replaced  Modified  and Reused. 2
    3. 3. Transitioning to Object-Orientation Functional Decomposition vs. Object-Orientation • Focus on verbs • Focus on nouns • Focus on process • Focus on behavior • Describe interactions • Vague partitioning • Describe messages rules • Rules on encapsulation • Analysis and design • Analysis and design separate blend 3
    4. 4. Object-Oriented Terms Object: Anything that  Class: A template that models “things” in the real defines the structure and world. These “things” may capabilities of an object be physical entities such as instance. The class airplanes, or events such definition includes the state as a conference, or data and the behaviors abstractions and logical (methods) for the instances concepts. of that class.  An object is an instance of a class.  Abstract class: A class that can only be used as the base class of some other class. (e.g. Geometric Shape vs. Circle). 4
    5. 5. Object-Oriented Terms (cont.) Attribute: Classes use attributes to store information about themselves (state information). Operation: An action or transformation that a class performs or is performed on a class. Method: Internal implementation of an operation for a specific object. Service: Just a kind of method, but provides access to related functions sharing some common purpose. 5
    6. 6. An Example of a Class Class Name Employee Name DateOfBirth HomePhoneNo Attributes Title (etc.) listDepartmentsWorked() Operations assignToSupervisior() computeVacation() listEmployees() (etc.) 6
    7. 7. Object-Oriented Properties  Inheritance: Parent/Child relationship among classes. A subclass inherits all attributes and behavior of the superclass.  Polymorphism: A request-handling mechanism that selects a method based on the type of the target object.  Encapsulation: The act of grouping both data and methods into a single object .  Information Hiding: Objects hide their internal structure from their surroundings. 7
    8. 8. Object-Oriented Properties (cont.) 8
    9. 9. Eight (or Nine, or Ten) UML DiagramsRequirements 1. Use-case diagramStatic view 2. Class diagram 3. Sequence diagram (an OID) Behavioral view 4. Collaboration diagram (an OID) (dynamic) 5. State Chart diagram 6. Activity diagramImplementation 7. Component diagramview 8. Deployment diagramOrganize Models 9. PackageClass Instances 10. Object diagramModel 9
    10. 10. Use Cases Use cases are graphical scenarios for understanding system requirements.  A textual scenario accompanies each use case. Library System A use case is a specific interaction between users Check out books (actors) and some system functionality. Get The use-case model captures Interlibrary loan the goal of the user and the responsibility of the system to its users. Read books, Newspapers Supplier Member Purchase Supplies 10
    11. 11. Class Diagram  The UML class diagram is the static analysis and design diagram.  Class diagrams show the static structure of the model.  The class diagram is collection of static modeling elements, such as classes and the relationships among the data. 11
    12. 12. Class Diagrams (cont.)  In class notation, either or both the attributes and operation compartments may be suppressed. Boeing 737 Boeing 737 length: meter fuelCapacity: Gal doors: int Boeing 737 length: meter lift ( ) fuelCapacity: Gal roll ( ) doors: int thrust ( ) 12
    13. 13. Object/Class Relationships  Three types of relationships among classes (or among objects, for that matter) are:  Association.  Generalization.  Aggregation (consists of).  Composition (a-part-of). A Stronger Aggregation 13
    14. 14. UML Association Notation  In the UML, a navigable association is represented by an open arrow. BankAccount Person  A bidirectional association does not have an arrow. BankAccount Person 14
    15. 15. UML Binary Association Notation  A binary association is drawn as a solid path connecting two classes or both ends may be connected to the same class. Works For Company Person employer employee Person Note: • Association Name • Association Roles Married To 15
    16. 16. Qualifiers and Multiplicity  A qualifier is an association attribute. Account# is an attribute of Bank, but is important enough to note as the qualifier in the association.  Multiplicity specifies the range of allowable associated classes. Bank accountNo * 0..1 Person . 16
    17. 17. UML Association Class An association class is an association that also has class properties. An association class is shown as a class symbol attached by a dashed line to an association path. Company Person employer employee WorksFor salary 17
    18. 18. UML N-Ary Association An n-ary association is an association among more than two classes. The n-ary association is more difficult to understand. It is better to convert an n-ary association to binary association. Year semester * * * Class Student class student GradeBook grade exam lab 18
    19. 19. Generalization Relationships  Generalization is a form of association.  Sub-classes are specialized versions of their super- classes. Separate target style Vehicle Bus Truck Car Shared target style BoeingAirplane Boeing 737 Boeing 757 Boeing 767 19
    20. 20. Aggregation Relationships Aggregations are a-part-of relationships, where a class consists of several component classes. Aggregation is a special form of association. 1 Team Consists Of * Player class 20
    21. 21. UML Composition  Compositions are aggregations with strong ownership. They use solid diamonds. When the composition dies, all components die too. Car 1 1 1 1graphical composition 4 4, 10 2, 5 1 Wheel Light Door Engine Carnested composition Wheel 4 Light 4,10 Door 2,5 Engine 1 21
    22. 22. Object Diagram  The UML object diagram is the static analysis and design diagram using specific, named objects.  Object diagrams follow the same rules as class diagrams.  The object diagram may be used to model a concrete instance of a use case.  It helps understand the emerging system model.  After it is abstracted into a class diagram, it may be discarded. 22
    23. 23. Four UML Behavior Diagrams• Behavioral (dynamic) models reflect system processes over time. 1. Sequence diagram (an OID*) 2. Collaboration diagram (an OID*) 3. State Chart diagram 4. Activity diagram *Object Interaction Diagram 23
    24. 24. Sequence Diagram A sequence diagram shows an interaction arranged in a time sequence. Telephone Call :Caller :Exchange :Receiver :Talk offHook( ) dialTone( ) dialNumber( ) ringTone( ) offHook( ) onHook( ) breakConnection( ) onHook( ) 24
    25. 25. Collaboration Diagram  A collaboration diagram shows process interactions and messaging. 2: Enter Kind 5: Process Transaction 4: Enter Amount 13: Terminate Account ATM Machine:Definition Bank Client 8: Transaction succeed 1: Request Kind 3: Request Amount 9: Dispense Cash 10: Request Take Cash7: Withdraw Successful 6: Withdraw Checking Account 11: Take Cash 12: Request Continuation Checking Account 14: Print Receipt 25
    26. 26. UML Statechart Diagram  A UML statechart diagram shows the change in states that an object encounters during its life as it responds to outside stimuli and messages.  Statecharts are good for showing complex state behavior of some objects.  Statecharts are often seen in real-time or embedded system modeling. User Interface navigation can employ statecharts. 26
    27. 27. Idle State Idle lift receiver and get dial toneDialing Substates Dialing Start Dial num.isValid( ) entry and start dialog entry and exit / stop dial tone num.append(n) digit(n) 27
    28. 28. UML Activity Diagram An activity diagram is a variation or special case of a state machine. The states are activities representing the performance of operations. The transitions are triggered by the completion of the operations. Activity diagrams are easily confused with traditional flow charts but can show synchronous events. 28
    29. 29. Activity Diagram with Swimlanes Office Clerk Insurance Agent Loan Officer Edit Incoming Paper Check Life Index insurance Draw Up documents Deed Calculate Pay Provision to Mortgage Agent Complete Write Request Insurance Policy 29
    30. 30. Component diagrams • Packages the logical view. Component diagrams show the structure (libraries) of the code itself. Access Update User Interface 30
    31. 31. Deployment Diagram • Packages the implementation view. Deployment diagrams show the structure (hardware) of the run- time system. Node 1: AdminServer Access Update Node 2: John’s PC UI 31
    32. 32. A Package and Its Contents • Used for model management, a package is a grouping of model elements and may contain other packages. GradeNoteBook Year semester * * * Class Student class student GradeBook grade exam lab 32
    33. 33. Notes in UML  A note is a graphic symbol containing textual information that might be anchored.  It also could contain embedded images. employee employer Person Company Static models & Represents revision levels an incorporated released yesterday entity 33
    34. 34. Recap: The UML DiagramsRequirements 1. Use-case diagramStatic view 2. Class diagram 3. Object diagram 4. Sequence diagram (an OID) Behavioral view 5. Collaboration diagram (an OID) (dynamic) 6. State Chart diagram 7. Activity diagramImplementation 8. Component diagramview 9. Deployment diagramOrganizing the 10. PackageModel 34
    35. 35. Recap: The UML DiagramsRequirements 1. Use-case diagramStatic view 2. Class diagram 3. Sequence diagram (an OID) Behavioral view 4. Collaboration diagram (an OID) (dynamic) 5. State Chart diagram 6. Activity diagramImplementation 7. Component diagramview 8. Deployment diagramOrganize Models 9. PackageClass Instances 10. Object diagramModel 35
    36. 36. Diagrams in View Context Structural Implementation View View Class Component Diagrams Diagrams Object User View Diagrams Use Case Diagrams Sequence Diagrams Collaboration Deployment Diagrams Statechart Diagrams Diagrams Activity Diagrams Behaviora Environment l View View 36
    37. 37. A Very Few Resources Books (UML only)  Page-Jones, Meilir (2000). Fundamentals of Object-Oriented Design in UML. Addison-Wesley.  Taylor, David (1992). Object-Oriented Technology; A Managers Guide. Addison-Wesley. Web Sites  IBM / Rational Software. UML resource center. http://www-  The Object Mangement Group. UML resource page. 37
    38. 38. Typical UML Models/Diagrams• Class Diagram - Describes the logical structure of the architecture by showing the types of classes that constitute the system and their interrelationships. A class represents a set of logical objects that share the same attributes and behavior.• Use Case Diagram – Describes the required functionality of the system in terms of goals that provide an observable result of value or service to actors.• Activity Diagram – Describes, in a workflow format, the activities and decisions required by a system to achieve the goal of an associated use case.• Statechart Diagram - Describes the states of a system across the system’s lifecycle (may show the affects of several use cases). It shows the transition from state to state in response to an event.• Sequence Diagram – Describes how the sequences of activities are controlled by the objects’ interactions. In particular, they show the objects participating in the interaction and the time sequence of messages exchanged. The SoSE modeling suite will be used by the System Architecture Team to capture the system requirements and architecture for system development. 38
    39. 39. Class Diagram Format system class boundaryactor system systemclass class interface class relationship SoS Level +A to B +B to C <Class Name B> <Class Name C> +B to A +C to B Actor Name A System Class: An abstract representation of the SoS, System, Subsystem or Configuration Item (e.g., a class of ship, airplane, truck, satellite, HWCI, or CSCI). Actor Class: An abstract role represented by an individual or a group of individuals, organizations, or external systems that interact with the system class. 39
    40. 40. Actor and Use Case Format system actor boundary value or use class service case relationship SoS Level <Use Case Name B> Actor Name A Use Case Name should be a statement of the goal (or service) desired by the actor expressed as an active verb and a quantifiable noun (e.g., start engines and maneuver satellite). 40
    41. 41. Use Case Diagram Example Military SoS Monitor Area <<include>> Assess Reports Regional Commander <<include>> Regional Commander Plan Tasks <<include>> <<include>> Sustain SoS Execute Plan 41
    42. 42. Activity Diagram Format swim lanesclasses : <Actor Name> : <Class Name B> : <Class Name C> start activity Actor Action Activity A actor action Activity B Activity C activity Activity D flow path 42 stop
    43. 43. Activity Diagram Example for Monitor Area Use Case : Regional Commander : Regional Commander : Mobil CommandCenter (MCC) : Mobil Command Center : AWACS : AWACS (MCC) Comm anders Create Sensor Tasking Task Plan Task Sensors Launch AWACS Configure AWACS Sensors Process Sensor Create and Send AWACS Reports Sensor Reports 43
    44. 44. State Chart Diagram Formatstart stop state state transition transition transitionEvent 1 <State Name Event 2 <State Name Event 3 Alpha> Bravo> 44
    45. 45. State Chart Diagram Example Mission Initiated Startup Sensors Tasked Mission Surveillance Completed Target Reported PlanningTarget Report Course of Action Determined Engagement 45
    46. 46. Sequence Diagram Formatclasses : Actor Class : System Level : System Level : System Level Class Alpha Class Bravo Class Charlie Action Interaction A Interaction Bactorinitiates Interaction Caction Interaction D Response actor receives Interactions response 46
    47. 47. Sequence Diagram Example : Regional : Mobil Command : UCAV : AWACS : SatellliteCommander Center (MCC) Operation Plan Evaluate Operation Plan Schedule Satellite Prepare Air Tasking Order Air Tasking Order Air Tasking Order Satellite Data UCAV Data AWACS Reports Evaluate Data and Reports Situation Report 47
    48. 48. Collaboration Diagramsactor Format receives actor initiatesresponse action : Actor : System Level Class Class Bravo 2: Interaction A6: Response 1: Action 4: Interaction C 3: Interaction B 5: Interaction D : System Level Class Alpha : System Level Class Charlie interactions 48
    49. 49. Collaboration Diagram Example 2: Evaluate Operation Plan 4: Prepare Air Tasking Order 1: Operation Plan 10: Evaluate Data and Reports::Regional Commander Regional Commander 11: Situation Report : UCAV : Mobil Command Center (MCC) 5: Air Tasking Order 9: AWACS Reports 8: UCAV Data 3: Schedule Satellite 7: Satellite Data 6: Air Tasking Order : AWACS : Satelllite 49