1212 UML Grafical method to develop models Industry standard Different diagrams for different aspects Static diagrams: – Classes – Use case – Deployment Dynamic diagrams – Sequence – State machine Running example: Observer Pattern (A = abstract, C = concrete)

1212 Class diagrams A class is represented by a box ASubject Class name Attributes attach(AObserver) Methods detach(Aobserver) notify() AObserver $update() Association 1* observers observers: collection(AObserver ) forall obs in observers obs.update()

1212 ASubject attach(AObserver) detach(Aobserver) notify() AObserver $update() observers CObserver CSubject state: State getState(): State setState(State) update() 1 * subject Inheritance Mutual dependency! versus state:State

1212 CSubject getState(): State setState(State) State Composition Static ownership relation Owner creates object(s) at its own creation Object(s) disappears when owner disappears Aggregation Dynamic ownership relation Owner creates/destroys object(s) at any time Association Reference to an object owned by yet another object Dependency component depends on component to which arrow points

1212 Package > Player methods Interface inheritance (realization) Stereotype Do not include too many classes in one diagram (readability) – tools support that the same classes appear in different diagrams RealPlayer methods

1212 Sequence diagrams Model dynamic behavior Used to describe some sequence of method calls for important sequences (typical or complicated) More general dynamic behavior is captured by state diagrams Control of a single thread jumps from object to object when calls/returns are made

1212 (Outside) Actor :CSubject :CObserver attach(this) setState(state) notify() getState() state Notice that contol “jumps”: actor can be considered as a separate thread update()

1212 Object creation Call: object becomes active Return: object becomes inactive destroy()

1212 actor Use Case System name UC1 UC1’ generalization UC2 UC3 Extend/include

1212 State machines General dynamic behavior of classes In contrast to use cases that are for a typical scenario only, state machines describe behavior for all uses State machines can send messages to other state machines and cause a transition there With a state transition, there can be a trigger and an action If there is no trigger, the transition is always made

1212 CObserver states waiting attach(this)/ updating update()/ /state=subject.getState() updated usually some operations on state free (Initial transition) attached /subject.attach(this) …/subject.detach(this) detached

1212 waiting /observers =Ø consistent attach(obs)/observers +=obs detach(obs)/observers -=obs updated setState(state) notifying updateObserver /notify();n=0 |observers| !=0/observers(n).update() getState()/n+=1 n=|observers|/ CSubject states