Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 7

53
06/16/22 CPSC-4360-01, CPSC-5360-01, Lecture 7 1 Software Engineering, CPSC-4360-01, CPSC-5360- 01, Lecture 7

description

Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 7. Review of Last Lecture. Class Diagram Association Class, Reification N-Ary Association Qualified Association Interface Interactions diagrams Collaborations, classifier and association roles - PowerPoint PPT Presentation

Transcript of Software Engineering, CPSC-4360-01, CPSC-5360-01, Lecture 7

Page 1: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 1

Software Engineering, CPSC-4360-01, CPSC-5360-01,Lecture 7  

Page 2: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 2

Review of Last Lecture Class Diagram

Association Class, Reification N-Ary Association Qualified Association Interface

Interactions diagrams Collaborations, classifier and association roles Interaction diagrams, object creation and destruction Role multiplicity and iterated messages Multi-objects Conditional messages, messages to self

Page 3: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 3

Overview of This Lecture

Statechart State-dependent behaviors, events, transitions Initial and final states, guard conditions Actions, activities, composite states, history states

Page 4: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 4

Where are we now?

Requirement

Analysis

Design

Implement

Test

Topic Covered: Detailed Class Diagram Object Diagram Collaboration Diagram Sequence Diagram

Page 5: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 5

Object Behavior The behavior of an object is defined by its reaction to

messages at any point in execution. Some object behaviors can be studied by:

Object Diagram, OR Interaction Diagram.

Not sufficient: Cannot model all possible scenarios, e.g., only specific

sequence of messages are studied. Only model some legal (possible) states - show how an

object behaves in particular interactions. We need to know about illegal or impossible states to plan for

them.

Page 6: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 6

Specifying Behaviour in UML A different notation is needed to summarize the

overall behaviour of objects. UML defines a statechart for this purpose. Complement interaction diagrams for understanding

the dynamic behaviour of the system: Interaction Diagram:

Models some inter-object messages with well defined order during a short duration.

Statechart: Models the entire lifetime of a single object, specifying all

possible sequences of messages and responses.

Page 7: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 7

State-dependent Behaviour Objects respond differently to the same

stimulus/events at different times. Can be modelled by defining a state machine:

It has a set of states: an object can be in one state at any time; the state it is in determines how it responds to events.

It has a set of transitions: an event can cause the object to move from one state to

another.

Page 8: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 8

CD Player: An Example Behaviour of a simple CD player:

A drawer to hold the CD; Control interface with 3 buttons:

Load button: the drawer will open if it was shut and will shut if it was open;

Stop button: the player will stop playing. If there is no CD, there is no effect;

Play button: the CD will be played. If the drawer is open, the drawer shuts before playing starts.

Page 9: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 9

UML Statechart Semantics A statechart defines the behaviour of instances of a

given class. It shows:

The possible states of an object; The events it can detect; Its response to those events.

An object is in one active state at a time: Events may be received at any time, which can trigger a

transition to the next active state; If an Event only causes a loop on a state (i.e., no change of

an active state), the transition is known as self-transition.

Page 10: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 10

Statechart: Deciding States Identifying separate states:

Informal principle: States S1 and S2 are separate if an object in state S1

responds differently to at least one event from the way it responds to that event in state S2.

Syntax: States: rounded rectangles with the name of the

state ( ). Example:

There are 3 states for the CD player: Closed, Playing, Open.

StateName

Page 11: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 11

Statechart: Identifying Events Events are usually external stimulus:

E.g., messages that can be sent to an object; Internal stimulus will be covered later in the lecture.

Events usually cause an object to change state: Moving from one state to another is known as transition; Events that causes transition are known as trigger; Events can optionally carry data (similar to message

parameter). Syntax:

An arrow with the trigger attached ( ). Example:

There are three events for the CD Player: load, play, stop.

trigger

Page 12: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 12

CD Player: Statechart Ver. 1

Statechart

State:The Open state.

Transition:From Closed state to Open state triggered by load event.

Page 13: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 13

Initial and Final States To specify the first active state when an object is

created/initialized: Use Initial State:

A transition leading from the initial state indicates the first active state.

No event should be written on a transition from an initial state. Syntax: a black disc ( ).

To model the destruction of an object: Use Final State:

Represent the end of flow, i.e., the object no longer exists. May correspond to actual destruction for software object. Syntax: a circled black disc ( ).

Page 14: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 14

CD Player: Statechart Ver. 2

Statechart

Initial State:CD Player

switched on

Final State:Switched Off

the CD Player

Page 15: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 15

Non-Deterministic System When two or more transitions leading from a

state share the same trigger: No way to distinguish between them; Randomly choose one of them; The same history of events may end up in a

different state; Known as non-deterministic system.

Can be removed by adding information to distinguish between transitions with the same trigger.

Page 16: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 16

CD Player: Non Deterministic Example

Statechart

This transition should be for no CD inside.

This transition should be used when

there is a CD inside.

In real-life, a CD player will not play if there is no CD inside.

Statechart Ver. 2 does not describe this. Correct Behaviour:

When the play event is detected, the CD Player should remain in the Closed state if there is no CD inside.

Resulting Statechart (partial):

Page 17: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 17

Guard Condition Although the two transitions are meant for different

scenarios, the statechart does not distinguish among the two, resulting in a non-deterministic behavior.

The non-determinism can be removed if we can specify the condition that determine the correct transition to use.

Syntax: trigger [guard_condition]

Semantics: If a transition has a guard condition, it can only fire if that

transition is evaluated to true; If all guard conditions are false and there is no unguarded

transition, the event will be ignored. Usually, only one condition is true (determinism).

Page 18: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 18

CD Player: Statechart Ver. 3

Statechart

Guard Condition

Note that guard conditions are also added to transitions leading from the Open state. What do they represent?

Page 19: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 19

Actions A state can have actions triggered. There are three ways an action can be triggered:

By an event; By entering a state; By leaving a state.

An action triggered by an event takes place in response to that event: Syntax:

Trigger [Guard_Condition] /action Example:

The CD drawer will be closed when play is detected in the Open state.

Page 20: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 20

CD Player: Statechart Ver. 4

Statechart

Action triggered by Event

Page 21: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 21

Action: Entering/Exiting a State An action can be triggered as soon as the state is

entered. Useful to capture actions that must be performed

regardless the transition used to arrive at the state. Syntax:

Write in a compartment in the state box: entry/action Similarly, an action can be performed just before

leaving a state. Syntax:

Write in a compartment in the state box: exit/action

Page 22: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 22

CD Player: Statechart (partial)

Statechart

Action triggered by entering a

state.

Action triggered by leaving a

state.

Question: What happened when the play button is pressed during CD playing?

Page 23: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 23

Action and Activity Properties of Actions:

Short, self-contained processing; Finished “instantaneously”; Cannot be interrupted by events.

An “action” that does not conform to the above is termed as activity instead.

Property of Activities: Performed during a state; Carry out for an extended period of time; Can be interrupted by events.

Syntax: Write in a compartment of the state box: do/activity

Page 24: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 24

CD Player: Activity Example

Question: When the play track activity is being performed, what happen if the stop button is pressed?

Statechart (Partial)

Activity performed during the Playing

state.

Page 25: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 25

Completion Transition As well as being interrupted by events, some

activities will come to an end of their own accord. If an activity completes uninterrupted, then it can

trigger a completion transition. these are transitions without event labels.

Multiple completion transitions can be distinguished by guard conditions.

Example: When the play track activity is completed:

If it is the last track, go to Closed state; If it is not the last track, play the next track.

Page 26: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 26

CD Player: Completion Transition Example

Statechart (Partial)

Completion Transition:

Play the next track

Completion Transition:

No more track. Stop playing

Page 27: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 27

Internal Transition There are transitions that leave the object in the same

state but does not trigger the entry and exit actions: A self-transition is not appropriate. Why? Use an Internal Transition which does not trigger the

entry and exit actions. Syntax:

Write in a compartment of the state box: event/action Example:

Suppose we add an info button for the CD Player to display the remaining playing time for current track.

Page 28: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 28

CD Player: Internal Transition

Statechart – Internal Transition (Partial)

Statechart – Self- transition(Partial)

Info /display time

Compare the two different ways to model the info button.

Page 29: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 29

Composite State States that share similar behavior can be grouped

into a Composite State to simplify the statechart. Composite State:

Syntax similar to simple state; Contains a number of substates; When a composite state is active, exactly one of the

substate must be active; Transitions can lead away from a composite state as well as

any of its substates. Example:

CD Player: the response to the play event is similar during the Open or Closed states.

Page 30: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 30

CD Player: Composite State

Statechart

Composite State

Sub-State

Transition shared by all

substates

Transition specific to one

substate

Page 31: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 31

Composite State: Additional Property A composite state is just like a simple state:

Can have Entry/Exit actions; Can have extended activity.

A composite state is also like a mini-statechart: Can have an Initial State to indicate the default substate if a

transition terminates at boundary of a composite state; Can have a Final State, which is triggered when ongoing

activity within the state has finished. Transitions:

Leading away from a composite state apply to all substates; Arrive at composite state go to the default state; Can cross composite state boundaries.

Page 32: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 32

CD Player: pause button Pressing the pause button causes playing to be interrupted; When the button is pressed again, playing continues from the

position where it was paused.

Statechart

Only triggers if the Composite State

is entered.

As there is no entry action, reentering

the Playing substate will not restart the track.

Page 33: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 33

History State When a composite state is entered, it begins at the initial

state or directly transits into one of the substates. Sometimes, it is useful to re-enter a composite state at a

point at which it was left. Re-enter the last active substate.

Indicate this using the History State. Transitions arriving at the History State activate the last

active substate. If there is no last active substate, a default state can be

indicated by an unlabelled transition from History State. Syntax:

A circled ‘H’ ( ) H

Page 34: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 34

CD Player: History State Suppose re-pressing the play button:

During Playing: restart and play the current track; During Paused: restart the current track but remain paused.

Statechart

Make use of History State to

model the behavior correctly.

Page 35: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 35

CD Player: Final Version Statechart

Statechart

Page 36: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 36

Statechart Notation Summary

Event(param) [condition] /actionEntry /actionExit /actionDo /activityEvent /action

State Name

H

State

Transition and Trigger

Initial State

Final State

HistoryState

Page 37: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 37

Steps for Constructing Statechart1. Identify the objects that have complex behavior;2. Determine the initial and final states of the object;3. Identify the events that affect the entity;4. Working from the initial state, trace the impact of

events and identify the intermediate states;5. Identify any entry and exit actions on the states;6. Expand states into a composite state if necessary;7. Check which actions in the state are supported by

operation (method);8. Refine the class if necessary. Another example of constructing Statechart: “Ticket

Machine”.

Page 38: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 38

Creating a Statechart How information from interaction diagrams

can be used to derive statecharts? It can be hard to identify all necessary states. Statecharts can be developed incrementally:

consider individual sequences of events received by an object;

these might be specified on interaction diagrams; start with a statechart for one interaction; add states as required by additional interactions.

Page 39: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 39

Ticket Machine Consider a ticket machine with two events:

select a ticket type; enter a coin.

Basic interaction is to select a ticket and then enter coins. model this as a ‘linear’ statechart.

Problems: It defines only one transaction, whereas the ticket machine

is able to carry out repeated transactions; It shows only 3 coins, but this number should be arbitrary.

Page 40: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 40

Refining the Statechart This can be improved by adding ‘loops’:

the number of coins entered will vary: entry will continue until the ticket is paid for;

the whole transaction can be repeated. State ‘Idle’: no transaction is in progress.

Page 41: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 41

Adding Another Interaction

Suppose the requirements allow the user to enter a coin before selecting a ticket.

A ‘coin’ transition from the ‘Idle’ state is needed to handle this event. this transition can’t go to the ‘Paying for Ticket’

state as the ticket is not yet selected. so a new state ‘Inserting Coins’ is required.

The statechart is thus built up step-by-step.

Page 42: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 42

Adding a Second Interaction If all coins are entered before ticket selected:

Page 43: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 43

Integrating the Interactions Suppose the requirements allow the user to enter some

coins before selecting a ticket and the rest after that. In fact, events can occur in any sequence:

Page 44: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 44

Time Events Suppose the ticket machine times out after 30

seconds. We need to fire a transition that is not triggered by a

user-generated event; UML defines time events to handle these cases. Example: a transition will fire 30 seconds after the

‘no ticket selected’ state is entered.

Page 45: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 45

Activity States Both ‘No Ticket Selected’ and ‘Ticket Selected’

should check if the machine is able to return any change that is required.

Efficient solution: activity states! Activity states define periods of time when the

object is carrying out internal processing. unlike normal activities, these cannot be interrupted

by external events; only completion transitions leading from them; useful for simplifying the structure of complex

statecharts.

Page 46: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 46

Returning Change Note that activity as a property of state (slide

23) is not the same as activity states. Use an activity state to calculate change.

Page 47: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 47

Ticket Machine Statechart It incorporates

‘Pressing Cancel’ in the middle of a transaction.

The composite state ‘Transaction’ reduces the number of statechart transitions.

Still room for refining: When ‘cancel’ event occurs, the machine should give the money back

Statechart

Page 48: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 48

Comparison between statecharts and activity diagrams There are many similarities between state diagrams and

activity diagrams (Chapter 3 of [Bimlesh, Andrei, Soo; 2007]), as activity diagrams are state diagrams extended with some extra notation.

The main difference between activity diagrams and state diagrams is that activity diagrams do not normally include events.

Moreover, an activity is intended to proceed without getting stuck, whereas for state diagrams it is perfectly acceptable for an object never to reach some of its potential states.

Page 49: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 49

Where are we now?

Requirement

Analysis

Design

Implement

Test

Topic Covered: Detailed Class Diagram Object Diagram Collaboration Diagram Sequence Diagram Statechart

Page 50: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 50

Summary Statechart

State-dependent behaviors, events, transitions Initial and final states, guard conditions Actions, activities, composite states, history states

Page 51: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 51

Reading Suggestions

Chapter 6 of [Bimlesh, Andrei, Soo; 2007] Chapter 10 of [Priestley; 2004]

Page 52: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 52

Coming up next

Chapter 7 of [Bimlesh, Andrei, Soo; 2007] Chapter 14 of [Priestley; 2004] Chapter 6 of [Lethbridge, Laganiere; 2002]

Object-Oriented Software Engineering [Gamma, Helm, Johnson, Vlissides; 1999]

(‘Gang of Four’), Design Patterns: Elements of Reusable Object-Oriented Software

Page 53: Software Engineering,  CPSC-4360-01, CPSC-5360-01, Lecture 7

04/22/23CPSC-4360-01, CPSC-5360-01,

Lecture 7 53

Thank you for your attention!

Questions?