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

2. 2 © Wolfgang Pelz 2000-04UML Chapter One Introduction

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

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

5. 5 © Wolfgang Pelz 2000-04UML 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

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

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

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

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

10. 10 © Wolfgang Pelz 2000-04UML 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

11. 11 © Wolfgang Pelz 2000-04UML 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

12. 12 © Wolfgang Pelz 2000-04UML 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

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

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

15. 15 © Wolfgang Pelz 2000-04UML Another Organization

16. 16 © Wolfgang Pelz 2000-04UML 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

17. 17 © Wolfgang Pelz 2000-04UML 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

18. 18 © Wolfgang Pelz 2000-04UML 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:

19. 19 © Wolfgang Pelz 2000-04UML

20. 20 © Wolfgang Pelz 2000-04UML 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

21. 21 © Wolfgang Pelz 2000-04UML 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

22. 22 © Wolfgang Pelz 2000-04UML 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

23. 23 © Wolfgang Pelz 2000-04UML Chapter Three Class Diagram

24. 24 © Wolfgang Pelz 2000-04UML 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

25. 25 © Wolfgang Pelz 2000-04UML 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?

26. 26 © Wolfgang Pelz 2000-04UML 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

27. 27 © Wolfgang Pelz 2000-04UML 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

28. 28 © Wolfgang Pelz 2000-04UML 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

29. 29 © Wolfgang Pelz 2000-04UML 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

30. 30 © Wolfgang Pelz 2000-04UML Notation

31. 31 © Wolfgang Pelz 2000-04UML More Notation

32. 32 © Wolfgang Pelz 2000-04UML Aggregation/Composition

33. 33 © Wolfgang Pelz 2000-04UML Example

34. 34 © Wolfgang Pelz 2000-04UML 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

35. 35 © Wolfgang Pelz 2000-04UML Another Example

36. 36 © Wolfgang Pelz 2000-04UML 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

37. 37 © Wolfgang Pelz 2000-04UML 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

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

39. 39 © Wolfgang Pelz 2000-04UML 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)

40. 40 © Wolfgang Pelz 2000-04UML 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

41. 41 © Wolfgang Pelz 2000-04UML Another Example

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

43. 43 © Wolfgang Pelz 2000-04UML 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

44. 44 © Wolfgang Pelz 2000-04UML Example revisited

45. 45 © Wolfgang Pelz 2000-04UML Example with Dependency

46. 46 © Wolfgang Pelz 2000-04UML 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 > to prefix the class name.

47. 47 © Wolfgang Pelz 2000-04UML 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.

48. 48 © Wolfgang Pelz 2000-04UML Examples Figures in UML Distilled.

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

50. 50 © Wolfgang Pelz 2000-04UML 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):

51. 51 © Wolfgang Pelz 2000-04UML

52. 52 © Wolfgang Pelz 2000-04UML Object Diagrams (try this example) class Pet { // define a class protected: string name; // protected members can be accessed by child classes public: Pet() {name = "";} // default constructor Pet(string nm){name = nm;} // constructor string getName() {return name;} // to be inherited by child classes //virtual method, to be overridden virtual string speak() const { return “’I can't speak.’”; } };... int main() { vector pets; pets.push_back(new Dog("Midnight")); pets.push_back(new Cat("Ginger")); pets.push_back(new Pet("Dummy")); }

53. 53 © Wolfgang Pelz 2000-04UML Chapter 9 Use Case Diagram

54. 54 © Wolfgang Pelz 2000-04UML Use Case Diagram For capturing the functional requirements of a system. Typical interaction between user and system –captures some user-visible function –achieves a discrete goal for the user note the distinction between the user goal and system interaction in which system interaction is the low-level work that ultimately achieves the user goal

55. 55 © Wolfgang Pelz 2000-04UML Notation

56. 56 © Wolfgang Pelz 2000-04UML An Example (UML 1.3)

57. 57 © Wolfgang Pelz 2000-04UML Another Example (UML 1.1)

58. 58 © Wolfgang Pelz 2000-04UML Common Uses to model the context of a system –system, actors, and their interactions with it to model the requirements of a system –what system should do –independent of how it is done –point of view outside of system

59. 59 © Wolfgang Pelz 2000-04UML Caution it is easy to get too low-level A use case is a relatively large end-to-end process description that typically includes many steps or transactions; it is not normally an individual step or activity in a process. –Larman [1998] Applying UML and Patterns

60. 60 © Wolfgang Pelz 2000-04UML Steps capture normal case first for every step, ask: “What can go wrong” “How might this work differently” each variation is plotted as an extension common behavior can be encapsulated in another use case to be used by other cases

61. 61 © Wolfgang Pelz 2000-04UML Steps (cont.) after creating the diagram, write a generic scenario (called a use case description) which is a series of sentences describing each step in the interaction Each step in a use case is an element of the interaction between an actor and the system. use case description can be used to generate specific scenarios and interaction diagrams

62. 62 © Wolfgang Pelz 2000-04UML Scenario a thread through a use case a sequence of steps describing an interaction between a user and a system. A use case is a set of scenarios tied together by a common user goal.

63. 63 © Wolfgang Pelz 2000-04UML Exercise Produce a use case diagram for an ATM