150 likes | 220 Views
Explore the graphical method to develop models using UML, an industry standard. Learn about various diagrams to represent different aspects - static diagrams like Classes, Use Case, Deployment, dynamic diagrams like Sequence, State Machine. Walk through a running example of the Observer Pattern with abstract and concrete classes illustrated in Class diagrams. Understand concepts like Association, Inheritance, Composition, Aggregation, and Dependency in modeling. Discover how UML tools support readability by showing the same classes in different diagrams. Dive into Sequence diagrams to model dynamic behavior, detailing method call sequences and object interactions. Gain insights into state machines for capturing general dynamic behavior of classes with trigger-actions and transitions.
E N D
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)
Class diagrams Association A class is represented by a box AObserver ASubject Class name 1 * observers: collection(AObserver) Attributes observers attach(AObserver) Methods detach(Aobserver) notify() $update() forall obs in observers obs.update()
ASubject AObserver observers attach(AObserver) detach(Aobserver) notify() $update() Inheritance versus 1 * CSubject CObserver subject state: State state:State Mutual dependency! getState(): State setState(State) update()
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 CSubject Association Reference to an object owned by yet another object State getState(): State setState(State) Dependency component depends on component to which arrow points
Stereotype <<interface>> Player methods Package Interface inheritance (realization) RealPlayer methods Do not include too many classes in one diagram (readability) – tools support that the same classes appear in different diagrams
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
(Outside) Actor :CObserver :CSubject attach(this) setState(state) update() notify() getState() state Notice that contol “jumps”: actor can be considered as a separate thread
Object creation Call: object becomes active Return: object becomes inactive destroy()
System name UC1 generalization UC1’ actor UC2 Extend/include UC3 Use Case
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
CObserver states …/subject.detach(this) /subject.attach(this) (Initial transition) detached attached free update()/ attach(this)/ updating waiting /state=subject.getState() updated usually some operations on state
setState(state) CSubject states updated consistent /notify();n=0 n=|observers|/ /observers =Ø notifying attach(obs)/observers +=obs waiting getState()/n+=1 |observers| !=0/observers(n).update() updateObserver detach(obs)/observers -=obs