CSCI 3428: Software Engineering Tami Meredith UML Unified Modeling Language UML Is a diagrammatic framework for modeling systems Has both syntax and semantics Has formal specifications Can be executed (MDA; Model Driven Architecture) Is NOT a process it is to support S.E., not replace existing practices Can be used in multiple ways, including informally, and is easily extended Is generally associated with OOP References 1.deling_Language 2. Dan Pilone & Neil Pitman (2005).UML 2.0 in a nutshell: A desktop quick reference, O'Reilly Media Inc.: Sebastopol, CA, USA. History Based on 3 distinct OOP modeling methods 1. Booch Method of Grady Booch 2. Object Modeling Technique of James Rumbaugh 3. Objectory by Ivar Jacobson UML 1.0 was released in 1994 UML 1.1 Released in 1997 by Object Management Group UML 2.0 was released in 2005 Currently using released in August 2011 UML 2.5 was released on October 2012 and is "in process" Uses Capturing and communicating business processes (Domain modeling) Capturing details about a system for requirements or analysis Designing software Documenting existing systems, software, processes, or organizations UML can be used anywhere in S.E. for diagrammatically describing and communicating Rules of Thumb 1. Nearly everything in UML is optional 2. UML models are rarely complete 3. UML is designed to be open to interpretation (different organisations use it differently) 4. UML is intended to be extended UML is a framework, a set of guidelines, a tool for communicating and explaining things While it can be formal, it doesn't have to be Power of Practicality Unless being used formally (e.g., Rhapsody, MDA), UML is designed to improve communication It should describe constraints, not impose them Do not let UML limit your thinking, perspectives, analyses, or designs Use it as you need, when you need, how you need Components UML Infrastructure low-level, core, bottom-most concepts used by the UML creators to provide the foundation for UML UML Superstructure 600 pages describing the elements of UML OCL Object constraint language for writing constraints and expressions in a specific model Data Interchange Specification an XML schema for sharing UML models between tools UML Diagrams Structural Diagrams Perform static modeling Describe the structure of the system, its design, components, parts, pieces Includes attributes and relationships Most of these diagrams can be subsumed as variants of ER diagrams Not designed to capture behaviour, activities, and dynamic concerns More of value in the design phases UML Structural Diagrams 1. Class Diagrams: The OO class organisation 2. Component Diagrams: Describes how the system is split up into components and shows dependencies between components 3. Composite Structure Diagrams: Describes the internal structure of a class 4. Deployment Diagrams: Describes the hardware and execution environments 5. Package Diagrams: shows how the system is split into logical groupings 6. Object Diagrams: Show a snapshot of the executing (partial) system at a moment in time 7. Profile Diagram (new): Used at Meta-model level (not covered) 1. Class Diagrams Decomposes a system into Objects (classes) representing entities Most commonly used diagram Classes have attributes, of which some provide functionality and are called operations Special relationships exist: Aggregation: "has a," also decomposition Generalisation: "is a," also specialisation Generally limited to OOP paradigms Basic Class Notation Class name Data Methods Visibility Class members (data and methods) are preceded with symbols to indicate visibility " + " Public " - " Private " # " Protected " ~ " Package " / " Derived (can be combined with one of the others) Derived data is not stored it is calculated e.g., age = date birthdate), or obtained in some other way (e.g., from an external sensor) Relationships Subtypes point to their parents with a hollow arrow (inheritance) Components point to their containing (holder) with a diamond arrow Hollow: Aggregation, part can exist alone Solid: Containment, part cannot exist without holder Other notations exist for other relationships Class Diagram Example #1 Class Diagram Example #2 Notation Summary 2. Component Diagrams 3.Composite Structure Diagrams 4. Deployment Diagrams Deployment Diagram Example 5.Package Diagrams 6. Object Diagrams (Snapshot) UML Behavioural Diagrams Captures interactions among components and users Explores execution, timing, sequencing, control flow, and other dynamic behaviour Focus on functionality instead of structure More of value in requirements analysis and specification phases Can be used in the development of test plans UML Behavioural Diagrams 8. Use Case Diagrams: Usage scenarios 9. Activity Diagrams: Flowcharts, step-by-step workflows 10. State Machine Diagrams: For systems where behaviour can be shown using state models 11. Interaction Overview Diagrams: Help show how other diagrams are related 12. Communication Diagrams: Interaction in terms of message sequences 13. Sequence Diagrams: Message passing and sequences 14. Timing Diagrams: For RT systems where explicit timing constraints exist 8. Use Cases Represent the system in terms of how it can be used Frequently represented as a set of usage scenarios Good for capturing data flow Customers tend to like these Use Case Notation (UML) Use Case Example #1 Use Case Example #2 9. Activity Diagrams Control flow diagrams Based on structured programming of the 1970s Flowcharts (basis for most process diagrams) Can have: hierarchical components, abstractions, decompositions into "swim lanes" (sequences) Activity Diagram Example #1 Activity Diagram Example #2 Use Case Notation (alternative) 10. State Machine Diagrams State Machine Example #1 State Machine Example #2 11. Interaction Overview Diagram 12. Communication Diagrams Communication Diagram Example 13. Sequence Diagrams Sequence Diagram Example #1 Sequence Diagram Example #2 14. Timing Diagrams Effective Diagramming Know your purpose Modeling (complete, precise, detailed) vs. Communication (partial, concise, clear, focused) Let your diagram speak when you can't its a form of documentation that may be used without you to explain it Limit the number of abstractions in each diagram to 1 Don't feel limited by UML if not using MDA then do whatever is needed to get the ideas across Abuse the Notation You can merge the ideas if you want Mix'n match parts'n pieces