UML part III. UML part III 1/36

Transcription

1 UML part III UML part III 1/36

2 UML part III 2/36 Collaboration Diagram Collaboration Diagram: shows objects working together describes objects by the role they play in a scenario are a good way to document design patterns

3 UML part III 3/36 An Example of Collaboration Diagram Training trainer:employee trainee:employee Figure: The Training collaboration as an example of the Collaboration Diagram

4 UML part III 4/36 Communication Diagrams Communication Diagrams: focus on links, participants and messages show which links are needed between participants to pass an interaction s messages they are similar to sequence diagrams they belong to logical view

5 UML part III 5/36 A simple Communication Diagram Participants involved in the interaction participant1: ParticipantClass1 1.messageA() 2.messageB() participant2: ParticipantClass2 Link needed to suport any interactions between participant1 and participant2 Figure: A simple Communication Diagram

6 UML part III 6/36 Specific Messages The looping constraint participant1: ParticipantClass1 1.messageA() *[i=1..9] 2a.messageB() [condition=true] 2b.messageC() 2c.messageD() participant2: ParticipantClass2 All of these messages are sent at the same time The guard condition Figure: Sending a Message Based on a Condition This message is invoked by participant1 on itself participant1: ParticipantClass1 1.messageA() Figure: Participant Sends a Message to Itself

7 UML part III 7/36 The sequence diagram (again) Figure: This sequence diagram describes the interactions that take place when a new blog account is created

8 UML part III 8/36 Communication Diagram Figure: he links required to support the message passing must be added to the communication diagram

9 UML part III 9/36 Communication Diagram Figure: The complete set of messages within the Create a new Blog Account interaction

10 UML part III 10/36 Communication Diagram Communication Diagrams Versus Sequence Diagrams Use sequence diagrams if you are mainly interested in the flow of messages throughout a particular interaction. Use communication diagrams if you are focusing on the links between the different participants involved in the interaction.

11 UML part III 11/36 Timing Diagrams Timing Diagram properties most commonly associated with real-time or embedded systems they are used to capture accurate timing information present process view

12 UML part III 12/36 Timing Diagrams Figure: Simple timing diagram

13 UML part III 13/36 Timing Diagrams Figure: Alternative timing diagram notation

14 UML part III 14/36 Timing Diagrams Figure: An example of the timing diagram

15 UML part III 15/36 Interaction Overview Diagrams Interaction Overview Diagram properties: they provide a high-level view of how several interactions work together to implement a system concern they look very much like an activity diagram except that each of the actions are interactions within their own right logic view

16 UML part III 16/36 Interaction Overview Diagrams Figure: Individual interactions are placed on an interaction overview diagram as though they were actions on an activity diagram Figure: or actions from activity diagrmas are presented.

17 Interaction Overview Diagrams example UML part III 17/36

18 UML part III 18/36 Interaction Overview Diagrams Can Include: Activity Diagrams Sequence Diagrams Communication Diagrams Timing Diagrams

19 UML part III 19/36 State Machine Diagrams State Machine Diagram: modesl states of an object and the events causing state changes behavioral state machines protocol state machine logical view

20 UML part III 20/36 State Machine Diagram basics A state A transition Off Lift switch Lower switch On Figure: The simplest State Machine Diagram

21 UML part III 21/36 State Machine Diagrams State active when entered through a transition inactive when exited through a transition Transition Represents a change of state, or how to get from one state to the next Trigger The event causing the state change

22 UML part III 22/36 Transitions keystroke [input<required_length] Gathering input keystroke/submit input [input=required_length] Processing input Initial pseudostate Final pseudostate Figure: The input processing state diagram The full notation for transition description: trigger[guard]/behavior

23 UML part III 23/36 Transitions [another disc] /change disc press stop Playing do/ read disc [no more discs] Stopped press play [disc in tray] press play press pause Paused press stop Figure: CD player state diagram

24 UML part III 24/36 Transitions Neutral see oponent [defeatable] lost oponent Attack entry/ unshealth sword do/ charge exit/ sheath sword see oponent [undefeatable] lost opponent receive blow/pray [health=0] Panic receive blow/pray [health=0] Die Figure: State diagram modeling a troll in a FPS game

25 UML part III 25/36 Signals keystroke [input < required_length] Gathering input keystroke/submit input [input = required_length] Processing input [input < required_length] A choice pseudostate Gathering input keystroke A receive signal [input = required_length] Submit input Processing input A send signal

26 UML part III 26/36 Deployment Diagram: Deployment Diagrams properties: physical view shows how software gets assigned to hardware how the system pieces communicate

27 UML part III 27/36 Artifacts Artifacts Artifacts are physical files that execute or are used by your software. Artifacts include: executable files library files source files configuration files Figure: Equivalent representations of an artifact

28 UML part III 28/36 Hardware and Execution Environment Nodes Node A node is a hardware or software resource that can host software or related files. Hardware nodes Server Desktop PC Disk drives Execution environment nodes Operating system J2EE container Web server Application server

29 UML part III 29/36 Hardware and Execution Environment Nodes <<device>> Desktop PC Figure: An example of a hardware node <<executionenvironment>> Application Server Figure: An Example of an execution environment node Nodes are marked by the use of stereotypes, for example: << executionenvironment >> << device >> << J2EEcontainer >>

30 UML part III 30/36 Deployment Specification Node <<device>> Desktop PC Artifact <<artifact>> 3dpacman.jar <<artifact>> 3dpacman.jar <<deploy>> <<device>> Desktop PC <<device>> Desktop PC 3dpacman.jar

31 UML part III 31/36 Communication Between Nodes <<device>> Komputer PC <<TCP/IP>> <<device>> Server Figure: A Desktop PC and Server communicate via TCP/IP

32 UML part III 32/36 Showing Node Instances read traffic :LoadBalancer write traffic Node Instance <<device>> svr1:server Sun Blade <<device>> svr2:server Sun Blade Figure: One node gets read traffic and the other gets write traffic

33 UML part III 33/36 Using software models A diagram is not a software project. A digram is just a representation of software project model, that shows specific aspect of a project in a form, that can be discussed. Software models usefulness Cost cutting Model Driven Architecture Platform Independent Model Platform Specific Model

34 UML part III 34/36 Software project preparation A possible order of work: use case diagram sequence diagram class diagram activity diagram

35 UML part III 35/36 CASE tools that support UML ArgoUML Enterprise Architect Poseidon for UML BOUML UML2tool

36 UML part III 36/36 Bibliography Miles R., Hamilton K.: UML 2.0. Wprowadzenie, Helion, Gliwice 2007, UML 2.1 Tutorial, resources/uml2_tutorial/