swe © solomon seifu 2010 1 models communication use caseactivity objectdeployment statesequence...

SWE © Solomon Seifu 2010 1

Models

CommunicationUse case Activity

ObjectDeployment

State Sequence

ComponentClass Package

Behavior diagram

Interaction Timing

Interaction diagrams

Structure diagram

Lesson 3-2Behavior, Interaction & Structure

Diagrams


SWE: UML - Sequence Diagram

A sequence diagram is a time-oriented view of the interaction between objects to accomplish a behavioral goal of the system

An interaction may be modeled at any level of abstraction within the system design, from subsystem interactions to instance-level interaction for a single operation or activity


SWE: UML - Sequence Diagram (Cont.)

myA:A myB:B

doXdoA(param: val)

doB (myA)

A found message whose sender will not be specified

Lifeline

Execution specification. Bar indicates

focus of control.

doC

Typical synchronous message shown with a filled-arrow line

Participant


SWE: UML - Sequence Diagram (Illustrating Reply Returns)

:A myB:B

doOneaDate = getDate

getDate

aDate

There are two ways to show the return result from a message: Using the message

syntax returnVar = message(parameter)

Using a reply (or return) message line at the end of an activation bar


SWE: UML - Sequence Diagram (Message to “self” or “this”)

:A

doX

doY

You can show a message being sent from an object to itself by using a nested activation bar

Another activation bar superimposed

on the previous activation bar


SWE: UML - Sequence Diagram (Creation of Instances)

Object creation notation is shown in the figure. Note the UML-mandated dashed line

The arrow is filled if it's a regular synchronous message (such as implying invoking a Java constructor), or open (stick arrow) if an asynchronous call

myA:A myB:B

doXdoY

doZ

myC:Cnew

Note that newly created objects are

placed at their creation “height”.

Creation


SWE: UML - Sequence Diagram (Object Lifelines & Object Destruction)

In some circumstances it is desirable to show explicit destruction of an object

For example, when using C++ which does not have automatic garbage collection, or when you want to especially indicate an object is no longer usable (such as a closed database connection)

myA:A

myB:B

doXNew

…

<<destroys>>

The <<destroys>> stereotype message, with

the large X and short lifeline indicates explicit object

destruction


SWE: UML - Sequence Diagram (Equivalent Java Code)

:A myB:B

doOnedoTwo

doThree

public class A { private B myB = new

B(); public void doOne() { myB.doTwo();

myB.doThree(); } // … }


SWE: UML - Sequence Diagram (When to Use?)

You should use sequence diagrams when you want to look at the behavior of several objects within a single use case

Sequence diagrams are good at showing collaborations (communication) among the objects; they are not so good at precise definition of the behavior

Sequence diagrams are better when you want to emphasize the sequence of calls


Sequence Diagram Exercise


Sequence Diagram ExerciseAnswer


Communication Diagram


SWE: UML - Communication Diagram

Communication diagrams illustrate object interactions in a graph or network format, in which objects can be placed anywhere on the diagram (the essence of their wall sketching advantage), as shown in figure

myA:A

myB:B

1: doOne

1.1: doTwo

1.2: doThree


SWE: UML - Communication Diagram

(Cont.) A link is a connection path

between two objects; it indicates that some form of navigation and visibility between the objects is possible

More formally, a link is an instance of an association. For example, there is a link or path of navigation from a myA to a myB, along which messages may flow, such as the msg2, msg3 & msg4

myA:A

myB:B

1: msg1

1.1: msg2

1.2: msg3Link line

1.2.1: msg4

15

SWE: UML - Communication Diagram (Message to “self” or “this”)

A message can be sent from an object to itself as shown in the figure

This is illustrated by a link to itself, with messages flowing along the link

myA:A

1: msg1

2: doX


SWE: UML - Creation of Instances

Any message can be used to create an instance, but the convention in the UML is to use a message named create for this purpose (some use new)

If another (less obvious) message name is used, the message may be annotated with a UML stereotype, like so: «create»

The create message may include parameters, indicating the passing of initial values. This indicates, for example, a constructor call with parameters in Java


SWE: UML - Creation of Instances

(Cont.)

:A :B

:A :B

1: create(param)

<<create>>1: make(param)

Create message, with optional initializing parameters. This will

normally be interpreted as a constructor call

If an unobvious creation message is used, the message may be stereotyped for clarity.


SWE: UML - Communication Diagram (When to Use?)

Communication diagrams are better when you want to emphasize the links and the messages exchanged between objects without concern to the actual sequence in time

Many people find that communication diagrams are easier to alter on a whiteboard, so they are a good approach for exploring alternatives


Communication Diagram Exercise


Communication Diagram Exercise Answer


State Diagram


SWE: UML - State Machine Diagram

State machine diagrams are a familiar technique to describe the behavior of a system

Draw a state machine diagram for a single class to show the lifetime behavior of a single object


SWE: UML - State Machine Diagram (Notations)

• A state S

• The start state S

• A transitionS1

S2

State name

e

Event name

S or

Sor


SWE: UML - State Machine Diagram (Transitions )

Name(parameters)[guards]{events/actions}Name – the name of eventParameters – parameters to the eventGuards – conditions that are true/falseEvents – cause transition to occur i.e. self

transition or external transitionActions – task to be executed on transition


SWE:UML - State Machine Diagram (Transitions Guards)

A guard is some conditions that must be met for the transition to be taken

Guards can be: Variable range specification Some other constraint (pre-conditional

invariant) must be met Boolean condition


SWE: UML - State Machine Diagram (Event, Transition & Activity)

S1

entry / g(x), h(y)

exit / m(a), n(b,y,z)

do / act(a,y,z)

S2

T1(int r)[r < 0]/f( r )

T2[IN(READY)]/g( )

Event Name

Event Parameter

Guard

Actionactivities


SWE: UML - State Machine Diagram (Handling Transitions)

If an object is in a state S that responds to a named event E, it will act on it i.e. It transitions to the specified state if

The event triggers a named transition and The guard on the transition (if any) evaluates to TRUE Includes executing transition actions and propagating

specified events

Handle the event without changing state if the event triggers a named reaction Includes executing action list associated with reaction



(Handling Transitions) (Cont.)

Events are quietly discarded if A transition is triggered but the transition’s

guard evaluates to FALSEThe event does not explicitly trigger a

transition, reaction, or deferment


SWE: UML - State Machine Diagram (Actions)

Several types of actions can be defined depending on the conditions and moment they are performed: Entry Action – An action done when the state

machine enters a state Exit Action – An action done when the state

machine leaves the state Transition Action – An action performed during

the state change (neither an entry nor an exit action). It is transition dependent



(Actions) (Cont.) Actions run to completion

Normally actions take an insignificant amount of time to perform i.e., they are instantaneous

They may be interrupted by another thread execution, but that object will complete its action list before doing anything else

Actions are implemented via An object’s operations Externally available functions Simple statements (e.g. “X += c * sqrt (d) ”)


SWE: UML - State Machine Diagram (Action Order of Execution)

1. First, exit actions of current state

2. Next, transition actions

3. Last, entry actions of next state


SWE: UML - State Machine Diagram (Activities)

Activities are behaviors that are executed as long as an object is in the state

Activities are not run-to-completion They may be interrupted by an incoming event

Indicated using “Do / <activity-list>” “Throughout / <activity-list>”

Examples Summing values


SWE: UML - State Machine Diagram (What to Do on Entry & Exit?)

Entry actions are often used to perform setup needed within a state. Because an entry action cannot be evaded, any actions that occur inside the state can assume that the setup has occurred, regardless of how the state is entered

An exit action is used to perform clean up. The exit action can clean up such cases so that the state of the object remains consistent


SWE: UML - State Machine Diagram (State Transition Table for One State)

State Entry action

Exit action

Next_State1

Next_State2

Transition_Condition1

Transition_Condition2

Entry_Action2

Entry_Action1

Exit_Action1

Exit_Action2

A state transition diagram displays the states and transitions, but the details are hidden (e.g. Actions)

State transition diagram needs to be supported by state transition table that contains full specification of states


SWE: UML - State Machine Diagrams

(Cont.)

State A

State B

State C

Initial pseudostate

Transition

Final state

State


SWE: UML - State Machine Diagram (When to Use?)

State diagrams are good at describing the behavior of an object across several use cases

State diagrams are not very good at describing behavior that involves a number of objects collaborating


State Diagram Exercise


State Diagram Exercise Answer


Activity Diagram


SWE: UML - Activity Diagram

Activity diagrams are a technique to describe procedural logic, business process, and work flow

In many ways, they play a role similar to flowcharts, but the principal difference between them and flowchart notation is that they support parallel behavior


SWE: UML - Activity Diagram (Cont.)

Activity diagrams describe the workflow behavior of the system

Activity diagrams can show activities that are conditional or parallel

Activity1

Activity2 Activity3

Activity4 Activity5

Activity6

branch

merge

fork

Join

Start

End


SWE: UML - Activity Diagram (When to Use?)

The great strength of activity diagrams lies in the fact that they support and encourage parallel behavior

This makes them a great tool for work flow and process modeling


Activity Diagram Exercise


Activity Diagram Exercise Answers


Interaction Overview Diagram


SWE: UML - Interaction Overview Diagram

Interaction overview diagrams are a grafting together of activity diagrams and sequence diagrams

UML 2.0 offers the Interaction Overview diagram as a means to combine the flow of control from an Activity diagram with the messaging specification from the Sequence diagram


SWE: UML - Interaction Overview Diagram (Cont.)

You can think of interaction overview diagrams either as activity diagrams in which the activities are replaced by little sequence diagrams, or as a sequence diagram broken up with activity diagram notation used to show control flow. Either way, they make a bit of an odd mixture


SWE: UML - Interaction Overview Diagram (Cont.)

Activity1

fork

Start

:A :B

merge

:C :D


SWE: UML - Interaction Overview Diagram (When to Use?)

These are new for UML 2, and it's too early to get much sense of how well they will work out in practice. Fowler says “I'm not keen on them, as I think that they mix two styles that don't really mix that well.”

Either draw an activity diagram or use a sequence diagram, depending on what better serves your purpose


Component Diagram


SWE: UML - Component Diagram

The Component diagram represents pieces of software in the implementation environment

Component diagram models the implementation view. For example: An Order class could be generated as an EJB

component An OrderEntry class could be generated as an HTML

page. You can also use components to represent source

code, XML, ASP, or virtually any piece of software

52


(Cont.) Components represent pieces that

are independently purchasable and upgradeable

Component diagram uses dependencies in the same manner that the Package diagram uses them

The successful operation of one component depends on its ability to communicate with the other component

Widget



(Cont.)

Wireless Web

Browser

TraditionalWeb

Browser

JSF WithHTML

Contents ASP.NET With

HTMLContents


SWE: UML - Component Diagram (When to Use?)

Use component diagrams when you are dividing your system into components and want to show their interrelationships through interfaces or the breakdown of components into a lower-level structure

Use component diagrams as an architecture-level artifact, either to model the business software architecture, the technical software architecture


Deployment Diagram


SWE: UML - Deployment Diagram

Deployment diagrams show a system's physical layout, revealing which pieces of software run on what pieces of hardware

Each node on a Deployment diagram typically represents one type of hardware, such as a disk drive, a client PC, a server, or a processor

A node may also represent a human being or organizational unit, or more precisely, the function that a person can perform


SWE: UML - Deployment Diagram

(Cont.)

DatabaseServer

WirelessClient

MiddlewareServer

TraditionalClient

1..* 0..*1

0..*

1

0..*

The figure depicts a deployment diagram with four nodes:

- A database server, - A middleware server, and - two types of client devices


SWE: UML - Deployment Diagram (When to Use?)

Use deployment diagram to show what is deployed where

If you have only one node, then there is no need to draw a deployment diagram


Package Diagram


SWE: UML - Package Diagram

UML package diagrams are often used to illustrate the logical architecture of a system; the layers, subsystems, packages (in the Java sense), etc.

A layer can be modeled as a UML package; for example, the presentation layer can be modeled as a package named UI


SWE: UML - Package Diagram (Cont.)

A UML package diagram provides a way to group elements. A UML package can group anything: classes, other packages, use cases, and so on

A UML package is a more general concept than simply a Java package or .NET namespace, though a UML package can represent those and more

Nesting packages is very common


SWE: UML - Package Diagram (Cont.) Each package represents a namespace, which means

that every class must have a unique name within its owning package

If one wants to create a class called Date, and a Date class is already in the System package, one can have a Date class as long as it is in a separate package (e.g. MyDate package). To make it clear which is which, one can use a fully qualified name, that is, a name that shows the owning package structure

You use double colons to show package names in UML, so the dates might be System::Date and MyDate::Util::Date.

63

SWE: UML - Package Diagram (Cont.)

In diagrams, packages are shown with a tabbed folder, as shown in the figure

You can simply show the package name or show the contents too

At any point, you can use fully qualified names or simply regular names

utilDate

util

java

Date

util

Date

java::util


SWE: UML - Packages & Dependencies

It is common to want to show dependency (a coupling) between packages so that developers can see the large-scale coupling in the system

The UML dependency line is used for this; a dashed arrowed line with the arrow pointing towards the depended-on package


SWE: UML - Packages & Dependencies

(Cont.)

A B

C D

A depends on B and C.

B & C depend on

D


SWE: UML - Package Diagram (When to Use?)

Package diagrams are extremely useful on larger-scale systems to get a picture of the dependencies between major elements of a system. These diagrams correspond well to common programming structures

Plotting diagrams of packages and dependencies helps you keep an application's dependencies under control


SWE: UML - Timing Diagram

Timing diagrams are another form of interaction diagram, where the focus is on timing constraints: either for a single object or, more usefully, for a bunch of objects

Timing diagrams are mainly used in diagramming hardware events

Object A

Object B

On Off

State Change

OnOff Off

State Change State

swe © solomon seifu 2010 1 models communication use caseactivity objectdeployment statesequence...

Documents