1. UML Unified Modeling Language

2. Credits Wolfgang Pelz uml-diagrams.org Emanuele Debenedetti

3. History Booch: Booch Method Rumbaugh: OMT (object modeling technique) Jacobson: OOSE (OO software engineering)

5. Another organization

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

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

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

9. Steps to create a class diagram Identify classes using interaction diagrams and place them in the class diagram Get attributes from the conceptual model and the method names from the interaction diagrams Add type information and associations based on attribute visibility Add navigability arrows and dependencies

10. Cautions Start small Perspective should match activity – analysis: conceptual model – software: specification model Don’t go to details too early

11. Classes Classes comprise three slots (the forth is optional) – Name – Attributes (state) – Methods (behavior) Professor name surname create() delete() Professor create() delete() Professor name surname Professor

12. Classes (Visibility and multiplicity) Attribute: visibility name: type [multiplicity] = default {further properties} Method: visibility name (parameter list): returned type {further properties} Visibility: + public, - private, # protected, ~ friendly Parameter: direction name: type = default name: String surname: String age: integer visualize() selectCourse() Professor + name: String # surname: String - age: integer = 33 +visualize() - selectCourse() public protected private

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

14. Roles Define the roles played in associations Useful for – Self-associations – Multiple associations between the same two classes work for PersonCompany employeeeployer 1..*0..1 Person 0..1 husband wife is merried to User Directory owner ack. user container contained 0..* 1

15. Example class Persona { private String nome; private String cognome; private Date dataNascita; private static int numPersone; public Persona marito; public Persona moglie; public boolean siSposa(Persona p) { … } public boolean compieAnni(Date d) { … }

16. Association classes Sometimes the association itself might have properties – They cannot be moved to one of the two parts – UML defines association classes (association + class) CompanyPerson Job description dateHired salary * 1..* employeremployee

17. Aggregations They are specialized associations that stress the containment between the two classes We have a part-of relationship Course Curriculum 1..* 0..*

18. Composites Composites are heavy aggregations – The contents is subordinated to the container – For example, deleting the container means deleting the contents as well Slider Panel Button Window scrollbar body close 2 1 1 1 1 1

19. Inheritance (Generalization) Makes common properties explicit Inheritance is an elegant modeling means, but – It is not mandatory – Maybe we must add properties – Maybe we must refine/modify other properties We can work – Bottom-up (Generalization) – Top-down (Specialization) Person Student Professor

20. Inheritance and abstract classes Abstract classes – Aggregate common properties – They are inherited by all subclasses Inheritance and abstract classes provide an elegant and synthetic modeling means PolygonCircle Shape Triangle Square

21. Interface

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

23. Example

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

27. Object diagram Also called instance diagrams Useful of showing object connections (not interactions) Can be thought of as collaboration/communication diagram without messages

28. Package diagram

29. Model diagram

30. 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 System interaction is the low-level work that ultimately achieves the user goal

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

32. Use case diagram

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

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

35. Interaction diagrams Models that describe how groups of objects interact (collaborate) Class and use case diagrams are useful at capturing the structural nature of a system design in a generalized way Interaction diagrams capture dynamic behavior applicable to timing or sequencing requirements

36. Use case and Interaction diagrams Scenario - a specific instance of a use case, that is, a particular path through system functionality A single use case represents many related yet distinctly different scenarios Typically, an interaction diagram captures the behavior of a single scenario Two forms of interactive diagrams: sequence and collaboration/communication

37. Sequence Boxes at the top are participants (objects) Vertical lines are time lines Horizontal directed lines are messages Unless specifically noted, only sequence (location on the time line) is important, not exact times An activation rectangle in the lifeline indicates a focus of control (activation) during which an object is performing an action, either directly or through another object

38. First example

39. Lifetime of objects Creation: arrow with 'new' written above it – Notice that an object created after the start of the scenario appears lower than the others Deletion: an X at bottom of object's lifeline – Java doesn't explicitly delete objects; they fall out of scope and are garbage-collected

40. More elements Messages are function calls in traditional programming and events in event-driven programming Messages may carry parameters A dashed line indicates a return, used to carry a return message or just indicate the end of a group of sub-actions Self-call: sending messages to one self (message lines direct back to the same life line) Found message: messages not originated from any participants. Synchronous message: messages return only when done, block the flow of execution, no more messages from the same participant until a synchronous message is done Asynchronous message: messages returns immediately, do not block the flow of execution Guards are conditional expressions in square

41. Interaction frames Notations for loops, conditions and other detail algorithms Common operators for Interactive Frames: alt (alternative), opt (optional), par (parallel), loop (loop), region (critical region), neg (negative), ref (reference), sd (sequence diagram)

42. Indicating selection and loops frame: box around part of a sequence diagram to indicate selection or loop – if -> (opt) [condition] – if/else -> (alt) [condition], separated by horiz. dashed line – loop -> (loop) [condition or items to loop over] 42

43. linking sequence diagrams If one sequence diagram is too large or refers to another diagram, indicate it with either: – An unfinished arrow and comment – A "ref" frame that names the other diagram – When would this occur in our system?

44. (De)centralized system control What can we say about the control flow of each of the following systems? – centralized? – distributed? 44

46. Collaboration (UML 1.x) Communication (UML 2.x) An interaction diagram that utilizes message numbering instead of a time line; emphasizes structural organization of objects that send and receive messages

47. Sequence diagram

48. Corresponding collaboration diagram

49. Which to use? Choose sequence diagram when only the sequence of events needs to be shown and collaboration among the objects are priority Choose a collaboration/communication diagram when the objects and their links facilitate understanding the interactions Collaboration diagrams have relatively fixed notation and numbering scheme

50. Links and messages

51. Parameters and return values

52. Iterations and messages to “ this ”

53. Message Sequencing

55. Activity diagrams Useful to specify software or hardware system behavior Based on data flow models – a graphical representation (with a Directed Graph) of how data move around an information system Fill Order Ship Order Send Invoice Accept Payment Close Order Make Payment [order accepted] Invoice Receive Order [order reject]

56. Actions The fundamental unit of executable functionality in an activity The execution of an action represents some transformations or processes in the modeled system

57. Pins Actions can have inputs and outputs, through the pins Hold inputs to actions until the action starts, and hold the outputs of actions before the values move downstream The name of a pin is not restricted: generally recalls the type of objects or data that flow through the pin Output pins Standalone pin notations: the output pin and the input pin have the same name and same type Input pins

58. Activities An activity is the specification of parameterized behaviour as the coordinated sequencing of subordinate units whose individual elements are actions Uses parameters to receive and provide data to the invoker Parameter name Output parameter Activity nodes Activity edges Input parameter An action can invoke an activity to describe its action more finely

59. Activity nodes Action nodes: executable activity nodes; the execution of an action represents some transformations or processes in the modeled system (already seen) Control nodes: coordinate flows in an activity diagram between other nodes Object nodes: indicate an instance of a particular object, may be available at a particular point in the activity (i.e Pins are object nodes)

60. Activity edges Control flow edge - is an edge which starts an activity node after the completion of the previous one by passing a control token Object flow edge - models the flow of values to or from object nodes by passing object or data tokens Weight can determine the minimum number of tokens that must traverse the edge at the same time

61. Decision nodes Route the flow to one of the outgoing edges (tokens are not duplicated) Guards are specified on the outgoing edges or with the stereotype «decisionInput» There is also the predefined guard [else], chosen only if the token is not accepted by all the other edges If all the guards fail, the token remains at the source object node until one of the guards accept it

62. Merge nodes Bring together multiple alternate flows All controls and data arriving at a merge node are immediately passed to the outgoing edge There is no synchronization of flows or joining of tokens

63. Fork nodes Fork nodes split flows into multiple concurrent flows (tokens are duplicated) UML 2.0 activity forks model unrestricted parallelism

64. Join nodes Join nodes synchronize multiple flows Generally, controls or data must be available on every incoming edge in order to be passed to the outgoing edge, but user can specify different conditions under which a join accepts incoming controls and data using a join specification

65. Final nodes Flow final: – destroys the tokens that arrive into it – the activity is terminated when all tokens in the graph are destroyed Final node: – the activity is terminated when the first token arrives

66. Object nodes Hold data temporarily while they wait to move through the graph Specify the type of values they can hold (if no type is specified, they can hold values of any type) Can also specify the state of the held objects There are four kinds of object nodes: Pins (three differents notations) Activity Parameter Nodes Central Buffer Nodes Data Store Nodes

67. Activity edges - transformation It is possible to apply a transformation of tokens as they move across an object flow edge (each order is passed to the transformation behaviour and replaced with the result) In this example, the transformation gets the value of the attribute Customer of the Order object > transformation specification

68. Example 68 Get luggage ready [on car] [on train] «local precondition» Have a license Turn on the car To motorway tollgate Exit to Genova tollgate Go home with the car Go to the station with a friend Buy the ticket Obliterate the ticket Catch the train When the train arrives to Genova Get off the train The train derail Car crash The friend goes home Go home with bus Go to Heaven/Hell ;) Go to Heaven/ Hell ;) Study for 5 minutes [Genova is a long way] [else] Catch the ticket Fill up with fuel [the tank is full] [else] Pay the ticket

69. ActivityPartition Partitions divide the nodes and edges for identifying actions that have some characteristics in common They often correspond to organizational units in a business model Partitions can be hierarchical and multidimensional Additional notation is provided: placing the partition name in parenthesis above the activity name

70. Example

71. SendSignalAction Creates a signal instance from its inputs, and transmits it to the target object (local or remote) A signal is an asynchronous stimulus that triggers a reaction in the receiver in an asynchronous way and without a reply Any reply message is ignored

72. Time triggers and Time events A Time trigger is a trigger that specifies when a time event will be generated Time events occur at the instant when a specified point in time has transpired This time may be relative or absolute – Relative time trigger: is specified with the keyword ‘after’ followed by an expression that evaluates to a time value – Absolute time trigger: is specified as an expression that evaluates to a time value Jan, 1, 2000, Noon after (5 seconds)

73. AcceptEventAction Waits for the occurrence of an event meeting specified conditions Two kinds of AcceptEventAction: – Accept event action – accepts signal events generated by a SendSignalAction – Wait time action – accepts time events Accept event action Wait time action The objects stored in Personnel are only retrieved when the join succeeds (only once a year)

74. InterruptibleActivityRegion Is an activity group (sets of nodes and edges) that supports termination of tokens flowing into it When a token leaves an interruptible region via interrupting edges, all tokens and behaviours in the region are terminated Token transfer is still atomic: a token transition is never partial; it is either complete or it does not happen at all (also for internal stream) Interrupting edge

75. ExpansionRegion Nested region of an activity in which each input is a collection of values The expansion region is executed once for each element (or position) in the input collection On each execution of the region, an output value from the region is inserted into an output collection at the same position as the input elements

76. State machine diagrams

77. A state machine diagram models the behavior of a single object – Specifies the sequence of events that an object goes through during its lifetime in response to events

78. States Initial and Final States

79. Transitions A transition may have a trigger, a guard and an effect – Trigger is the cause of the transition, which could be a signal, an event, a change in some condition, or the passage of time – Guard is a condition which must be true in order for the trigger to cause the transition – Effect is an action which will be invoked directly on the object that owns the state machine as a result of the transition Self-Transitions

80. State actions Effects can be associated with states Possible triggers – Any event – Entry: behavior performed upon entry to the state – Do: ongoing behavior, performed as long as the element is in the state – Exit: behavior performed upon exit from the state It is possible to define any number of actions of each type

81. Compound states

82. Entry and exit points Entry Points help define alternative initial states Exit Points help specify alternative exit points

83. Choice Pseudo-State

84. Junction Pseudo-State

85. Pseudo-state and history Entering a terminate pseudo-state indicates that the lifeline of the state machine has ended A history state is used to remember the previous state of a state machine when it was interrupted

86. Concurrent regions

87. Interaction overview diagrams

88. Composite structure diagrams

89. Component diagrams

91. Deployment diagrams