Modelling Features as Statecharts Pourya Shaker and Joanne M. Atlee

Modelling Features as Statecharts

Pourya Shaker and Joanne M. Atlee

Feature-Oriented Requirements Modelling

Research study will evaluate the readability and writeability of two approaches to modelling features

– Model a feature AND its context– Model just the feature (state its context)

Time Commitment: 2 hours– 50 minute tutorial on modelling language (July 17th)– 50 minute questionnaire about models (July 24th)– $30 renumeration

Asked to consent us to use questionnaire answers in thesis or publication

– Can withdraw consent at any time– Can withdraw from study at any time

Agenda

• Remember SE463?– A reference model for requirements engineering– Modelling requirements using UML class and statechart

models• Feature-oriented software development• FORML: A feature-oriented requirements

modelling language– Two approaches to evolving FORML models with new

features• Overview of questionnaire

A Requirements Engineering Framework

• Requirements – desired goals or behaviour

A Requirements Engineering Framework

• Requirements – desired goals or behaviour

• Requirements – desired changes to the world– Expressed in terms of world phenomena

World (aka domain, environment) Software System

Requirements

World Phenomena Software-System PhenomenaInterfacePhenomena

Modelling Requirements Using UML

• The world can be modelled as a UML class diagram


• The world can be modelled as a UML class diagram


• The requirements can be modelled as UML state machines– Events, guards, and actions in terms of world phenomena

Feature-Oriented Software Development (FOSD)

• Stakeholders (e.g., users, developers) often think of a software system in terms of its features– Feature – a coherent bundle of functionality (e.g.,

call waiting, call forwarding, voice mail)• FOSD – advocates the use of features as first-

class entities throughout the lifecycle of a software system– Make features explicit in software artefacts (e.g.,

code, design models, requirements models)

FORML: A Feature-Oriented Requirements Modelling Language

• World Model • Behaviour Model

feature modules

events &conditions

actions

FOSD + UML-based requirements modelling

Example

• A telephone system with a basic-call service (BCS) feature– Responds to user commands to start, accept, and

end calls– Notifies users about the callee’s status

FORML World Model

feature: groups shared phenomena by features

software system



feature modules

events &conditions

actions

World States

• The inputs and outputs of the behaviour model are over world states – instances of the world model, representing a possible snapshot of the world

BCS Feature Module

• One statechart instance perTelephoneSystem object• Keyword this refers to the TelephoneSystem objectof a statechart instance

BCS Feature Module

Transition Labels:id: e [c] / id1: [c1] a1, … , idn: [cn] an

• Transition or action name• Triggering event: world-change event• Guard condition: world-state conditions• Action: world-change action

macros

FORML World Model

Adding a New Feature to a FORML Model

• Example: adding the requirements of call-forwarding on busy (CFB) to the model in the previous slides– CFB: when a user of a telephone system receives a call

while he/she is busy (i.e., already in a call), forward the call to a designated user of a different telephone system

• Update the world model (new phenomena)• Add a new feature module to the behaviour model

(add new behaviours, modify existing behaviours)

Alternative Approaches to Modelling New Features

• Approach 1 – The requirements of a new feature can always be specified as a complete statechart

• Approach 2 – But sometimes, it is convenient to specify a new feature’s requirements as differences with the requirements of existing features – i.e., as statechart fragments that extend the feature modules of existing features

Approach 1: CFB as a Complete StatechartU

pdat

ed W

orld

Mod

elCF

B Fe

atur

e M

odul

e

override action a2 of transition t7 in the BDS feature module

updates

BCS Feature Module

Approach 1: Composed Behaviour model

in parallel with

Approach 2: CFB as Statechart FragmentsU

pdat

ed W

orld

Mod

elCF

B Fe

atur

e M

odul

e

updates

add actions a1, a2, and a3 to transition t7 in the BDS feature module

Approach 2: Composed Behaviour Model

element names qualified withthe name of the feature modulein which they were introduced

CFB extensions of BDS feature module

Statechart FragmentsF1 feature module F2 feature module

Composed model


Composed model

new region

existing state


Composed model

new transition and destination state

existing regionand source state


Composed model

new actionexisting transition


Composed model

new strengthening clause

existing transition


Composed model

new weakeningclause

existing transition


Composed model

new strengtheningclause

existing action


Composed model

new weakeningclause

existing action



feature modules

events &conditions

actions

How are these expressed?

World-State Expressions

• Basic Set Expressions: – Calls : the set of Call objects– this : the TelephoneSystem object of a statechart instance– o : an world-change event parameter

• Selection– Calls[voice = true] : the set of Call objects whose voice attribute has the value true


• Basic Set Expressions: – Calls : the set of Call objects– this : the TelephoneSystem object of a statechart instance– o : an world-change event parameter

• Selection– Calls[voice = true] : the set of Call objects whose voice attribute has the value true


• Navigation– set-expr.feature-name

• this.BCS

– set-expr.association-name.role-name• this.BCS.Processing.Call

– set-expr.attribute-name• this.BCS.Processing.Call.voice

– set-expr.role-name• this.BCS.Processing.Call.caller



• this.BCS






• this.BCS






• this.BCS





• Set, boolean, and integer operations: Binary Set Ops Set-Cardinality Predicates Boolean Ops Integer Ops

+ (union) no set-expr (set has zero elements)

and # set-expr (number of elements in set)

- (intersection) one set-expr (set has exactly one element)

or =>, =<

= (equals) lone (set has zero or one elements)

implies >, <

in (subset of) some (set has one or more elements)

iff ==

not !=


• World-change events– s ? M(o) : message o sent to a system s

• this ? StartCall(o)

– C+(o) : object o of type C added to world state• Call+(o)

– C-(o) : object o of type C removed from world state• Call-(o)

– C.a~(o): attribute a of object o of type C changed value• Call.voice~(o)


• World-change actions– o = +C(a1 = exp1, ..., an = expn) creates a C object (that can be

referenced by the variable o) whose attributes ai have values expi• o = +User()

– +A(a1 = exp1, ..., an = expn, r1 = o1, ..., rm = om) creates an A link that relates objects oj in roles rj, and whose link attributes ai have values expi

• c = +Call(caller = set-expr, callee = set-expr, voice = false)


• World-change actions– s ! M(p1 = exp1, ..., pn = expn) creates an M message object sent

by system s whose parameters pi have values expi

• this ! Busy()

– -o removes the objects o and their dependent links• -Calls[voice = true]

– o.a := exp changes the value of o’s attribute a to value exp• o.voice := true

Transition and Action Overrides

Transition and Action Overrides

• An action override specifies a new action, a2, that overrides an existing action, F{a1} in a transition t in feature-module F.– F{t} : / a2: override(a1) [c]– Literally, this states that whenever F’s transition t

executes, action a2 is performed in place of a1 — provided that the guard condition c is true.

Transition and Action Overrides• Transition priority: specifies that a new transition, t2, has

priority over an existing transition, F{t1} in feature module F, whenever both are simultaneously enabled.– t2 > F{ t1} : ...

• Transition override: specifies that a new transition, t2, that overrides an existing transition, F{t1} in feature-module F. An override differs from a transition priority in that the enabling condition of t2 is implicitly the same as that of t1, but could be strengthened with an additional guard c:– t2 : override(F{t1}) [c] / ...– Literally, this states that whenever F’s transition t1 is enabled, t2

executes instead — provided that the behaviour model is in t2’s source state and guard condition c is true.

Questionnaire

• You will be asked to perform model-reading and writing tasks with respect to one of the two approaches to adding a new feature to a FORML model of TelephoneSystem with BCS

• Model-reading task: – Reading-comprehension questions about a given

model of a new feature added to TelephoneSystem• Model-writing task:

– Modelling of a new feature added to TelephoneSystem

Thank you for your participation!

Any Questions?Slides will be made available at: www.cs.uwaterloo.ca/~p2shaker

Also, please feel free to contact me (Pourya) at [email protected] Joanne M. Atlee at [email protected]

with any questions about this presentation or about the study

http://www.cs.uwaterloo.ca/~p2shaker

mailto:[email protected]

mailto:[email protected]

Documents

Modelling Features as Statecharts Pourya Shaker and Joanne M. Atlee