Unified Modeling Language

Transcription

1 Unified Modeling Language Software technology Szoftvertechnológia Dr. Balázs Simon BME, IIT

2 Outline UML Diagrams: Sequence Diagram Communication Diagram Interaction Overview Diagram Dr. Balázs Simon, BME, IIT 2

3 Where are we now? Requirements Design Implementation Testing Delivery Maintenance Use Case Diagram High level description of functional requirements: Use cases are basic interaction sequences between the system and its users Activity Diagram Use case interaction sequences as workflows Component Diagram High level overview of the system architecture: Components and how they are connected to each other Where to deploy components Deployment Diagram Dr. Balázs Simon, BME, IIT 3

4 Where are we now? Requirements Design Implementation Testing Delivery Maintenance Class Diagram Package Diagram Object Diagram Structure of a component/system using object-oriented modeling Packages and dependencies between them Shows a snapshot of the detailed state of a system at a point in time Next: How to design the inside of a component? (Behavior) Dr. Balázs Simon, BME, IIT 4

5 Where are we now? Structural UML diagrams: Next: How to design the inside of a component? (Behavior) Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 5

6 Sequence Diagram Dr. Balázs Simon, BME, IIT 6

7 Sequence Diagram Requirements Design Implementation Testing Delivery Maintenance Sequence Diagrams are graphical representations of interactions Sequence Diagrams show the dynamic behavior of the system interactions focus on the passing of information between participants Sequence Diagrams can be used to describe use case scenarios, logic of methods, message flows of a protocol Sequence Diagrams show possible traces of message exchanges arranged in time sequence traces are simple runtime scenarios valid and invalid traces can also be described traces that are not included are not described by the interactions at all, and we cannot know whether they are valid or invalid Dr. Balázs Simon, BME, IIT 7

8 Pacman: Class Diagram excerpt Thing +CollideWith(t: Thing) +HitBy(p: Pacman) +HitBy(m: Monster) +Move(d: Direction) -things -field 0..* d:direction Field -neighbors Accept(t: Thing) +Remove(t: Thing) +GetNeighbor(d: Direction): Field Pacman +CollideWith(t: Thing) +HitBy(m: Monster) +Die() Monster +CollideWith(t: Thing) +HitBy(p: Pacman) <<enumeration>> Direction +Up +Down +Left +Right Dr. Balázs Simon, BME, IIT 8

9 Pacman: Object Diagram for a possible initial state m : Monster p : Pacman f1 : Field f2 : Field Dr. Balázs Simon, BME, IIT 9

10 Sequence Diagram example: Monster kills Pacman sd Monster kills Pacman m : Monster f1 : Field f2 : Field p : Pacman Move(d) GetNeighbor(d) f2 Time Remove(m) Accept(m) CollideWith(m) HitBy(p) Die() 10

11 Sequence Diagram example: Monster kills Pacman sd Monster kills Pacman m : Monster f1 : Field f2 : Field p : Pacman Move(d) GetNeighbor(d) f2 Remove(m) Accept(m) CollideWith(m) HitBy(p) Die() 11

12 Sequence Diagram example: Monster kills Pacman sd Monster kills Pacman Interaction name Interaction m : Monster f1 : Field f2 : Field p : Pacman Lifeline Gate Move(d) GetNeighbor(d) f2 Name Type Lifeline Remove(m) Frame (fragment) Accept(m) CollideWith(m) HitBy(p) Die() Gate 12

13 Sequence Diagram example: Monster kills Pacman sd Monster kills Pacman m : Monster f1 : Field f2 : Field p : Pacman Move(d) GetNeighbor(d) Message f2 Message Execution specification Remove(m) Accept(m) CollideWith(m) Parameter HitBy(p) Die() Overlapping execution specification 13

14 Sequence Diagram example: Monster kills Pacman m : Monster f1 : Field f2 : Field p : Pacman Mapping to C++: Move(d) class Monster : public Thing { private: Field* field; //should be in Thing public: void Move(Direction d) { Field* next = field->getneighbor(d); field->remove(this); next->accept(this); void HitBy(Pacman* p) { p->die(); //... GetNeighbor(d) f2 Remove(m) Accept(m) HitBy(p) Die() CollideWith(m) 14

15 Sequence Diagram example: Monster kills Pacman m : Monster f1 : Field f2 : Field p : Pacman Move(d) Mapping to Java: GetNeighbor(d) public class Monster extends Thing { private Field field; //should be in Thing public void Move(Direction d) { Field next = field.getneighbor(d); field.remove(this); next.accept(this); public void HitBy(Pacman p) { p.die(); //... f2 Remove(m) Accept(m) HitBy(p) Die() CollideWith(m) 15

16 Sequence Diagram example: Monster kills Pacman m : Monster f1 : Field f2 : Field p : Pacman Move(d) Mapping to C#: GetNeighbor(d) public class Monster : Thing { private Field field; //should be in Thing public void Move(Direction d) { Field next = field.getneighbor(d); field.remove(this); next.accept(this); public void HitBy(Pacman p) { p.die(); //... f2 Remove(m) Accept(m) HitBy(p) Die() CollideWith(m) 16

17 Lifeline Describes the time-line for a process, where time increases down the page The head of the lifeline is not an instance specification (object)! an instance specification (object) is a snapshot of the dynamic instance it is modeling the sequence diagram is not a snapshot, it is dynamic, it shows a process hence: no underline in the head of the lifeline even an interface or an abstract class can appear as a type in the head on the lifeline but, of course, abstract methods and methods of an interface can only be called, they cannot call other methods, since they have no implementation p : Pacman Name Name Anonymous lifeline Type Lifeline The name and the type is optional, but at least one of them has to be specified Dr. Balázs Simon, BME, IIT 17 p : Pacman Type Lifeline Lifeline

18 Sequence Diagram: synchronous message Synchronous message: synchronous method call the operation name and the values passed as parameters are written above the arrow starts an execution specification the caller waits for the execution of the method to complete and, hence, for all the other methods called by this method Reply message: drawn from the end of the execution specification of a synchronous message the return value is written above the arrow Execution specification: body of the method call, while it is active corresponds to stack frames in programming languages main : Calculator Add(3,4) Synchronous message 7 Execution specification Reply message Dr. Balázs Simon, BME, IIT 18

19 Sequence Diagram: asynchronous message Asynchronous message (signal): asynchronous method call the caller does not wait for the execution of the method to complete it calls into or starts another thread/process the operation name and the values passed as parameters are written above the arrow starts an execution specification which does not need to be nested within the range of the caller s execution specification an asynchronous message has no reply message another asynchronous message can be used as callback main : Thread start() Asynchronous message Dr. Balázs Simon, BME, IIT 19

20 Sequence Diagram: create and destroy Create message: creates a new lifeline : Pacman Create message <<create>> b : Bomb f : Field Accept(b) Destruction: ends a lifeline timer b : Bomb tick() explode() Destruction Dr. Balázs Simon, BME, IIT 20

21 Sequence Diagram: Alternatives Choice of behavior: alt if-else branches Mapping to C++: class Hello { public: void Greet(Person* p, int hour) { if (hour < 12) p->goodmorning(); Combined fragment Guard else if (hour < 18) p->goodafternoon(); else p->goodevening(); Operand main Greet(p, hour) alt [hour<12] [hour<18] : Hello GoodMorning() GoodAfternoon() p : Person Mapping to Java/C#: public class Hello { public void Greet(Person p, int hour) { if (hour < 12) p.goodmorning(); else if (hour < 18) p.goodafternoon(); else p.goodevening(); [else] GoodEvening() 21

22 Sequence Diagram: Option Optional behavior: opt if without else timer tick() b : Bomb Combined fragment Mapping to C++: class Bomb { private: int timer; public: void Tick() { --timer; if (timer == 0) { this.explode(); void Explode() { /*...*/ Guard Operand Mapping to Java/C#: opt [timer==0] public class Bomb { private int timer; public void Tick() { --timer; if (timer == 0) { this.explode(); public void Explode() { /*...*/ explode() 22

23 Sequence Diagram: Loop Repeated behavior: loop main start() b : Bomb Combined fragment Mapping to C++: class Bomb { private: int timer; public: void Start() { while(timer > 0) { this.tick(); this.explode(); void Tick() { --timer; void Explode() { /*...*/ Guard Operand Mapping to Java/C#: loop [timer > 0] tick() public class Bomb { private int timer; public void Start() { while(timer > 0) { this.tick(); this.explode(); public void Tick() { --timer; public void Explode() { /*...*/ explode() 23

24 Sequence Diagram: combined fragments Abbrev Kind Meaning alt Alternatives Represents a choice of behavior. At most one of the operands will be chosen. opt Option Represents a choice of behavior where either the (sole) operand happens or nothing happens. break Break Represents a breaking scenario in the sense that the operand is a scenario that is performed instead of the remainder of the enclosing fragment. par Parallel Represents a parallel merge between the behaviors of the operands. seq Weak sequencing Represents a weak sequencing between the behaviors of the operands. strict Strict sequencing Represents a strict sequencing between the behaviors of the operands. Dr. Balázs Simon, BME, IIT 24

25 Sequence Diagram: combined fragments Abbrev Kind Meaning neg Negative Represents traces that are defined to be invalid. All fragments that are different from Negative are considered positive meaning that they describe traces that are valid and should be possible. critical Critical region The region is treated atomically by the enclosing fragment when determining the set of valid traces. ignore Ignore Ignore designates that there are some message types that are not shown within this combined fragment. consider Consider Consider designates which messages should be considered within this combined fragment. This is equivalent to defining every other message to be ignored. assert Assertion Represents an assertion. The sequences of the operand of the assertion are the only valid continuations. All other continuations result in an invalid trace. loop Loop Represents a loop. The loop operand will be repeated a number of times. Dr. Balázs Simon, BME, IIT 25

26 Sequence Diagram: Interaction use Sequence Diagrams can reference other Sequence Diagrams with Interaction use Advantages: modularity: large diagrams can be split into multiple smaller diagrams reuse: common behavior in multiple diagrams can be drawn once and referenced multiple times readability: high level diagrams can be refined with lower level diagrams Dr. Balázs Simon, BME, IIT 26

27 Sequence Diagram: Thing moves sd Thing moves t : Thing f1 : Field f2 : Field Move(d) GetNeighbor(d) f2 Remove(t) Accept(t) Dr. Balázs Simon, BME, IIT 27

28 Sequence Diagram: Interaction use sd Game loop timer t : Thing Start() loop [not end of game] loop Interaction use [for all t:thing] (references the diagram on the previous slide) ref Thing moves Dr. Balázs Simon, BME, IIT 28

29 Rules to have consistent and manageable diagrams Display one key behavior per diagram Different objects of the same type must have different lifelines Make sure that the caller knows the target object draw an Object Diagram to show who knows who at the beginning Make sure that the method being called is available through the target s known static type Create separate diagrams for polymorphic behavior Make sure that the same method behaves the same way in all diagrams Make sure to write operation parameters and results over the arrows Make sure that all operations exist in the class diagram Dr. Balázs Simon, BME, IIT 29

30 Informal Sequence Diagram Informal Sequence Diagrams: they alleviate the strict formalism of UML they don t exactly follow the UML standard however, they are great for brainstorming We usually don t model every little detail of the system in formal Sequence Diagrams this is usually unnecessary it is also time consuming, and programming the behavior is much easier and much quicker, than drawing sequence diagrams in clumsy design tools maintaining them later and keeping them in sync with the source code is also time consuming and error prone Usually informal Sequence Diagrams are sufficient to show the relevant behavior of the system these are much quicker to draw during brainstorming they provide enough detail to understand the overall picture they only have to be updated in the documentation, if the design principles of the behavior they show change Note: in the homework, in the exam and in the subject called Software project laboratory we expect you to draw formal Sequence Diagrams our goal is to see whether you know the UML standard you can always alleviate the strict formalism later Dr. Balázs Simon, BME, IIT 30

31 Reminder from earlier: Buy item use case Buy item Customer Cashier Use case: Buy item Actors: Customer, Cashier Main Success Scenario: 1. The Customer picks the item 2. The Customer hands the item to the Cashier 3. The Cashier records the item 4. The Cashier asks for money from the Customer 5. The Customer pays the amount to the Cashier 6. The Cashier gives the item and the receipt to the Customer Alternative 5.A: 5.A.1. The Customer has not enough money 5.A.2. The Customer leaves empty handed Dr. Balázs Simon, BME, IIT 31

32 Informal Sequence Diagram for the Buy item use case Item Money Customer 1 : Pick 2 : Hand over Cashier 3 : Record 4 : Ask for money alt [has enough money] 5 : Pay(Money) <<create>> 6 : Print Receipt 7 : Give(Item, Receipt) [not enough money] 8 : Leave empty handed 32

33 Where are we now? Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 33

34 Communication Diagram Dr. Balázs Simon, BME, IIT 34

35 Communication Diagram Requirements Design Implementation Testing Delivery Maintenance Communication Diagrams are graphical representations of interactions Communication Diagrams show the dynamic behavior of the system interactions focus on the passing of information between participants the sequencing of messages is given through a sequence numbering scheme Communication Diagrams correspond to simple Sequence Diagrams that use none of the structuring mechanisms such as Interaction uses and Combined fragments Sequence Diagrams are good at showing sequential logic, but not that good at giving a big picture Communication Diagrams are good at showing the big picture (participants and their relationships), but not that good at showing sequential logic a Communication Diagram is like a view of a simple Sequence Diagram from above Dr. Balázs Simon, BME, IIT 35

36 Reminder: Monster kills Pacman Sequence Diagram sd Monster kills Pacman m : Monster f1 : Field f2 : Field p : Pacman Move(d) GetNeighbor(d) f2 Time Remove(m) Accept(m) CollideWith(m) HitBy(p) Die() 36

37 Communication Diagram: Monster kills Pacman sd Monster kills Pacman Interaction name Interaction m : Monster Sequence number 4.1.1: HitBy(p) p : Pacman Frame (fragment) 1: GetNeighbor(d) 2: f2 3: Remove(m) f1 : Field Reply message : Die() 4: Accept(m) f2 : Field Synchronous message 4.1: CollideWith(m) Lifeline Name Type Dr. Balázs Simon, BME, IIT 37

38 Where are we now? Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 38

39 Interaction Overview Diagram Dr. Balázs Simon, BME, IIT 39

40 Interaction Overview Diagram Requirements Design Implementation Testing Delivery Maintenance Interaction Overview Diagrams define Interactions through a variant of Activity Diagrams in a way that promotes overview of the control flow However, the nodes are: Interactions or Interaction uses Interaction: inline Sequence Diagram or Collaboration Diagram or Interaction Overview Diagram Interaction use: reference to a Sequence Diagram or to a Collaboration Diagram or to an Interaction Overview Diagram Dr. Balázs Simon, BME, IIT 40

41 Restrictions Interaction Overview Diagrams differ from Activity Diagrams in some respects: the nodes are: Interactions or Interaction uses Alternative Combined Fragments are represented by a Decision node and a corresponding Merge node Parallel Combined Fragments are represented by a Fork node and a corresponding Join node Loop Combined Fragments are represented by simple cycles Branching and joining of branches must be properly nested Interaction Overview Diagrams are framed by the same kind of frame that encloses other forms of Interaction Diagrams Dr. Balázs Simon, BME, IIT 41

42 Interaction Overview example: Pacman game sd Pacman game Interaction Interaction name ref Select from main menu Interaction use Inline interaction sd Game loop [start game] [quit game] Start timer t : Thing Frame (fragment) loop [not end of game] loop [for all t:thing] refthing moves 42

43 Where are we now? Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 43

44 Summary Dr. Balázs Simon, BME, IIT 44

45 Outline Graphical representations of interactions Interactions focus on the passing of information between participants UML Diagrams: Sequence Diagrams are good at showing sequential logic, but not that good at giving a big picture Communication Diagrams are good at showing the big picture (participants and their relationships), but not that good at showing sequential logic Interaction Overview Diagrams define Interactions through a variant of Activity Diagrams in a way that promotes overview of the control flow Dr. Balázs Simon, BME, IIT 45

46 Where are we now? Structural UML diagrams: Component diagram Deployment diagram Class diagram Package diagram Object diagram Composite structure diagram Profile diagram Behavioral UML diagrams: Use case diagram Activity diagram Sequence diagram Communication diagram State diagram Timing diagram Interaction overview diagram Dr. Balázs Simon, BME, IIT 46