1. UML 2-OMG certification course (OCUP Fundamental-3) Instructor: M.C. Ricardo Quintero

4. The metamodel for dependencies

12. Types of dependency relationship Keyword for permission relationship The dependent element is permitted to use private of this independent element <<permit>> Stereotype to usage relationship The dependent element creates instances of the independent element. Is defined between classifiers. <<instantiate>> Stereotype to abstraction relationship The dependent element is derived from the independent element <<derive>> Stereotype to usage relationship The dependent element creates instances of the independent element. Is delined between classifiers <<Create>> Stereotype to usage relationship Is defined and specified from one operation to another operation, so that the source operation calls the target operation. The source can also be a class (the class contains an operation that calls the target operation) <<call>> Description Keyword/Stereotype

13. Types of dependency relationship Keyword fo usage relationship The dependent element uses the independent element for its implementation <<use>> Stereotype to abstraction relationship The dependent element leads to the independent to trace semantic dependencies (e.g. From a use case to a class) <<trace>> Steretotype to abstracton relationship The dependent element resides on a more concrete semantic level than the independent element <<refine>> Description Keyword/Stereotype

16. The metamodel for interfaces

21. Supplied Interface (arrow notation & plug notation) Opel Astra implements the interface Car. Opel Astra provides the Car interface Provider Provider <<interface>> Interface-A Interface-A

22. Required Interface (arrow notation & plug notation) For a required interface, the requiring element has a usage relationship with the interface User <<interface>> Interface-A RacingDriver Car User Interface-A <<use>>

23. Example extending and implementing interfaces RacingDriver Car Manager LuxuryCar

28. Packages for dynamic modeling in the metamodel Behavioral descriptions

32. The metamodel for basic behavior

37. The notational model for executing behavior Request SendRequest CallRequest InvocationOccurrence CallInvocationOccurrence SendInvocationOccurrence SignalOccurrence ReceiveOccurrence CallOccurrence +sendEvent +message +message +receiveEvent 1 1..* 1 1

39. Event hierarchy Event TriggerEvent CallBehavior Event SpontaneousEvent ChangeEvent TimeEvent Receiving Event Exceptions are a special form of signals. Only active objects can receive signals. Signals always represent an asynchronous call behavior. The receiver of a signal is responsible for selecting the behavior to be executed.

50. Example of an activity Produced Bottles [empty] New Six-Pack Fill Bottles Label Bottles Bundle Pack Bottles [labeled] Bottles [empty] Bottles [filled] Bottles [filled] [knockOff] [continue] <<precondition>> Boolean expression <<postcondition>>Boolean expression Six-Pack Production Produced Bottles:Bootles New Six-Pack:Six-Pack Six-Pack Actions Pins (input or output parameters of actions) keywords Activity input parameter Activity output parameter Declaration of activity parameters Decision node

51. Types of activity node ActivityNode ExecutableNode ControlNode ActivityParameterNOde CallBehaviorAction Action Pin ObjectNode

54. The metamodel for activity edges

56. Notation for connectors A ... A

57. Nodes ActivityNode ExecutableNode ControlNode ActivityParameterNode CallBehaviorAction Action Pin ObjectNode Actions Object nodes Control nodes

63. The metamodel for activity edges ValueSpecification 1 +guard {subsets ownedElement} {default value is true}

65. Control flow- “and” semantics A C B A B C Implicit splitting Once action A terminates, a control token is made available at both outgoing edges. After action A , actions B and C start concurrently Implicit synchronization Action C doesn’t start until tokens are available at both incoming edges. Actions A and B have to terminate first

66. Object Flow-”and” semantics A C B A B C Except by the fact that the actions have input and output pins, the same rules from control flow apply

67. Object Flow-”or” semantics A C B A B C A has only one output pin , wich means that the action supplies one object token . Outgoing are two edges . Which one of these edges the object token will select is not defined The model behavior cannot anticipated Actions A and B each supply an object token. But action C has only one input pin . Action C would be called twice .

70. Notation & Semantics Initial Node When calling an activity, a control token is placed on each initial node . If an activity has several initial nodes, there will be several concurrent flows after an activity has been called. It is not mandatory for an activity to have an initial node It has at least one incoming edge, but no outgoing edge . The entire activity terminates as soon as a token reaches a final node, regardlees of how many other tokens are still within the activity. It is not mandatory for an activity to have a final node Final Node

74. The metamodel for control nodes

79. Notation for activity parameters Make vechicle ready for rental Vehicle: Car Protocol: HandOverProtocol Vehicle Protocol Take down car condition ... Take down car condition Input Parameter Output Parameter Parameter declaration

81. The metamodel for pins

82. Various notations for pins Action Action Object [state] Object [state] Action Action Object type [state] Action Action An object flow without details

83. Various object types Activity Section from an activity Identify Customer Display Data Customer Person class Person/Customer Customer Person Object types and object states of output pins and their partners input pins don’t have to be identical , but it should be easy to derive the object type at the input pin from the incoming object types

84. Labeling object nodes Action Object Type [state] Book vehicle Booking Action Object Name: Type [state] Identify Customer Booker:Customer

85. Input pins and output pins without edges Action Input pin Output pin An output pin without continuing edges expresses that the pertaining action has an output parameter which, however, doesn’t play a role in the activity’s further flow

86. A special form of input pin: the value pin Create invoice Tarif.SALESTAX The notation adds a value specification, describing a value in the model, next to the pin. Value pins are used, for example, to model constants in activities