The Unified Modeling Language (UML)

Transcription

1 The Unified Modeling Language (UML) A Very Distilled Introduction to The Unified Modeling Language (UML). A quick introduction to UML is given. Thereafter, the surface of class and activity diagrams and their use is scratched. An UML tool will be used to show UML in practice. November 19, 2001 Christopher Curry Performance Engineering Lab Department of Computer Science, University of Copenhagen (DIKU). Slide No november 2001

2 Agenda Introduction UML Primer Activity Diagrams Class Diagrams Tools Questions Slide No. 2 Wednesday, 21 November 2001

3 Introduction UML is a language for Visualizing Specifying Constructing Documenting the artifacts of a software-intensive system. Slide No. 3 Wednesday, 21 November 2001

4 The detailed introduction The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML gives you the a standard way to write a system s blueprints, covering conceptual things, such as business processes and system functions, as well as concrete things, such as classes written in a specific programming language, database schemas, and reusable software components. Grady Booch, James Rumbaugh, Ivar Jacobsen (1999) The Unified Modeling Language User Guide, ISBN Slide No. 4 Wednesday, 21 November 2001

5 Visualizing An explicit model facilitates communication. Some structures transcend what can be represented in programming language. UML = 1 picture = 1000 words! Hence, UML replaces the traditional you think it, you code it. Slide No. 5 Wednesday, 21 November 2001

6 Specifying Specifying means building models that are precise and unambiguous. UML addresses the specification of all important analysis, design, and implementation decisions. Slide No. 6 Wednesday, 21 November 2001

7 Constructing UML can be connected to a variety of programming languages (Java, C++, rdb). Forward engineering: generation of code from model into programming language. Reverse engineering: reconstructing model from implementation. Round-trip engineering: going both ways. Keeping both views consistent. Slide No. 7 Wednesday, 21 November 2001

8 Documenting Facilitates documentation about deliverables, such as requirements documents, functional specifications, and test plans. Materials that are critical in controlling, measuring, and communicating about a system during development and after deployment. UML addresses what many developers neglect: documentation (or at least finish of in the last minute quick and dirty). Slide No. 8 Wednesday, 21 November 2001

9 Five reasons to model 1. Provide a sound structure for problem solving. 2. Communicate the desired structure and behavior of the system. 3. Visualize and control the system s architecture. 4. Better understand the system and expose opportunities for simplification and reuse. 5. Manage the risks of mistakes. Slide No. 9 Wednesday, 21 November 2001

10 Manage risks and cost of repair. Development Phase Requirements Design 0.5 Coding 1 Unit test 2 Acceptance test 5 Maintenance 20 Relative Cost of Repair Source: Object-Oriented System Development by Dennis de Champeaux, Douglas Lea, and Penelope Faure (ISBN X) Slide No. 10 Wednesday, 21 November 2001

11 Structural diagrams Class A class diagram shows a set of classes, interfaces, collaborations, and their relationships. Object Object diagrams represent static snapshots of instances of the things found in class diagrams. Component Deployment A component diagrams shows the organization and dependencies among a set of components: classes, interfaces, or collaborations. A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Grady Booch, James Rumbaugh, Ivar Jacobsen (1999): The Unified Modeling Language User Guide, ISBN Slide No. 11 Wednesday, 21 November 2001

12 Behavioural diagrams Use Case Sequence Collaboration Statechart Activity A Use case diagram shows a set of use cases, actors, and their relationship. Use cases diagrams are central to organizing and modeling the behaviour of a system. A Sequence diagram shows a set of objects and the messages sent and received by those objects with emphasis on the time ordering of messages. Sequence diagrams are central to illustrate the dynamic view of a system. As Sequence diagrams, but with emphasis on the structural organization of objects. A Statechart shows a state machine with states, transitions, events, and activities. An Activity diagram shows the flow activities within a system. Slide No. 12 Wednesday, 21 November 2001 Grady Booch, James Rumbaugh, Ivar Jacobsen (1999): The Unified Modeling Language User Guide, ISBN

13 Activity Diagrams In short An activity is defined as a state of doing something. An activity diagram describes the sequencing of activities. An activity diagram supports conditional and parallel behavior. Activity diagrams are useful for modeling workflows (business processes). Slide No. 13 Wednesday, 21 November 2001

14 Activity Diagram Example Jyrki Identify appropriate topic Christopher Audience Identify lecturer Ask lecturer Evaluate proposal <<Accept>> <<Decline>> Announcement Inception Elaboration Construction Transition Slide No. 14 Wednesday, 21 November 2001

15 Activity Diagram Elements (1) Initial state Conditional behavior True Action False Branch for alternate path. A branch has one incoming transition and two or more outgoing transitions. Action state Slide No. 15 Wednesday, 21 November 2001 Final state A merge has two or more incoming transitions and one outgoing transition

16 Activity Diagram Elements (2) Sales Departments Shipping Department Receive Order A fork represents the splitting of a single flow of control into two or more concurrent flows of control. Parallel behavior Bill Customer Send goods Slide No. 16 Wednesday, 21 November 2001 Swimlanes partition groups of activities. For example organizational units. A join represents the synchronization of two or more flows of control into one sequential flow of control.

17 Class Diagrams In short A class diagram describes the Types of objects in a system Static relationships among objects (associations and subtypes) Attributes Operations Constraints that apply to how objects are connected. Slide No. 17 Wednesday, 21 November 2001

18 Three Perspectives on class diagrams Conceptual The concepts in the domain under study. Specification Focus on the interface of the software. Implementation Full blown classes. In practice, the modeler switch perspective at their convenience! Slide No. 18 Wednesday, 21 November 2001

19 Example: Order class Class name Association with multiplicity Private Attributes (-) Order Customer Public Attributes (+) +datereceived +isprepaid +number : char +price : float * 1 -address -name +creditrating() : char Operations +close() : void +dispatch() : void Mandatory Slide No. 19 Wednesday, 21 November 2001

20 Associations Class A Class B Conceptual Associations represents conceptual relationships between classes. Specification Associations represents responsibilities. Implementation Unidirectional association or who has the pointer to the other? Bidirectional association. Slide No. 20 Wednesday, 21 November 2001

21 Attributes and constraints Private attributes. Syntax is a "-" prefix. Public attributes have a "+" as their prefix. Operations. We distinguish between "query" and "modifiers" opertations. -X : float = 0 -Y : float = 0 -Z : float = 0 <<implementationclass>> Point {if Point.X = 0 then Point.X = 1} +getx() : float +gety() : float +getz() : float +new() : void +setpoint( x : float, y : float, z : float ) : void Constraint, in this case very formalized Query operation Modifier operation Slide No. 21 Wednesday, 21 November 2001

22 Class diagrams tips 1. Classes, associations, attributes, generalizations, and constraints the simple notation can bring you far with your modeling. 2. Find the right perspective: Conceptual, specification or implementation. Align the perspective to the stages of your project. 3. Minimize the number of models. Keep it simple! Slide No. 22 Wednesday, 21 November 2001

23 Tools Slide No. 23 Wednesday, 21 November 2001

24 UML Resources Grady Booch, James Rumbaugh, Ivar Jacobsen (1999): The Unified Modeling Language User Guide, ISBN Martin Fowler, Kendall Scott (2001): UML Distilled Second Edition A Brief Guide to the Standard Object Modeling Language., ISBN X Object Management Group ( Slide No. 24 Wednesday, 21 November 2001