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
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>>
37. The notational model for executing behavior Request SendRequest CallRequest InvocationOccurrence CallInvocationOccurrence SendInvocationOccurrence SignalOccurrence ReceiveOccurrence CallOccurrence +sendEvent +message +message +receiveEvent 1 1..* 1 1
38.
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.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
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
63. The metamodel for activity edges ValueSpecification 1 +guard {subsets ownedElement} {default value is true}
64.
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 .
68.
69.
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
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
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
![Dependencies ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)