Chương 15: A goaloriented modelbuilding method in action potx

www.wileyeurope .com/college/van lamsweerde Chap.15: A goal oriented model building method in action © 2009 John Wiley and Sons
Building System Models for RE
Building System Models for RE
Chapter 15
A goal-oriented model-building
method in action
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 2
A goal-oriented model-building method in action:
outline

Overview and case study introduction

Modelling the system-as-is
– S1: Build a preliminary goal model illustrated by scenarios
– S2: Derive a preliminary object model

Modelling the system-to-be
– S3: Update the goal model with new goals…
– S4: Derive the updated object model
– S5: Analyse obstacles, threats and conflicts
–
S6: Analyse responsibilities and build the agent model
–
…

Handling model variants for product lines
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 3
Main steps of a model building method for RE

Figure 15.1 – Main steps of a model building method for RE

Build a preliminary goal model
illustrated by scenarios
Modeling the
system-as-is
Derive a preliminary
object model
Update the goal model with new
goals illustrated by scenarios
Modeling the
system-to-be
Derive the updated
object model
Analyze obstacles, threats,
and conflicts
Analyze responsibilities
and build the agent model
Make choices among
alternative options
Operationalize goals
in the operation model
Build and analyze the
behavior model
data dependency
backtracking
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 4
Case study: Mine safety control
.
Mine safety control
[System as-is.] Miners are exposed to multiple hazards while working inside a mine.
These include life-threatening levels of percolating water, carbon monoxide, methane,

and airflow.
Currently, dedicated supervisors have to alert miners inside the mine for prompt
evacuation when any of those levels is estimated to be dangerous.
Sumps are placed at selected places in the mine for water collection. Each sump is
equipped with a pump. The water level in each sump is regularly checked by dedicated
operators to see if the water level is not too high. When this level is too high, the
corresponding pump must be turned on to pump the water out of the mine.
To avoid the risk of explosion, pumps may not be operated when the methane level
exceeds some critical threshold.
The current situation results in unacceptable exposure to risks, due to possible human
unawareness or misjudgement of potentially dangerous situations; sudden flows of
gas or water without operators at the right place to act upon; or pump functioning
problems. On the other hand, lack of accurate assessment sometimes results in
unnecessary evacuations. The cost of manpower for safety control is another concern.
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 5
Case study: Mine safety control (2)
.
[System to-be.] To address these problems, a ubiquitous Safety Control system will be
installed. Each sump will be equipped with water level sensors to detect when the
water is above a high or below a low level, respectively. A software-based controller
shall turn a pump on whenever the water in the corresponding sump is reaching the
high water level, and off whenever the water is reaching the low water level.
The mine will also be equipped with sensors at selected places to monitor the carbon
monoxide, methane, and airflow levels. An alarm shall be raised, and the operator
informed within one second, whenever any of these levels is reaching a critical
threshold, so that the mine can be evacuated promptly.
Human operators can also control the operation of the pump, like previously, but
within limits. An operator can turn the pump on or off if the water is between the low
and high water levels. A special operator, the supervisor, can turn the pump on or off
without this restriction.

The Safety Control system shall also maintain sensor readings and pump operation
records for history tracking and analysis of anomalies.
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 6
Modeling the system-as-is

Purpose:
–
Structuring the goals and concepts
–
Analyse the system-as-is to extract:
preliminary goal model
Devive conceptual objects

Two steps:
– Step 1: Build a preliminary goal model illustrated by
scenarios
– Step 2: Derive a preliminary object model
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 7
Step 1: Build a preliminary goal model illustrated by
scenarios

WHAT:
–
Analysing any available material to identify stable goals
–
Each goal is defined and classified in term of type and category.
– The goals are refined to get sub-goals
–
The goals are abstracted until the sys’s boundary is reached


HOW:
–
Search for prescriptive or intentional keywords.
–
Ask HOW and WHY questions about such statements
–
Check for responsibility assignments in prescriptive statements.
–
Elicit illutrative scenarios of current ways of doing thing.
–
Use goal refinement patterns to restructure the model
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 8
Step 1: Build a preliminary goal model illustrated by
scenarios
Figure 15.2 – Preliminary identification of stable goals and refinements in the system-as-is

Maintain [HighWaterDetected]




Achieve [MineEvacuatedIfCriticalLevel]




Def The mine must be evacuated promptly when
the level of methane, carbon monoxide, or airflow
is estimated critical.
“… supervisors have to alert miners inside the mine for prompt evacuation when…”

Achieve [MinersAlertedIfCriticalLevel]




…
Def Miners inside the mine must be alerted when
the level of methane, carbon monoxide, or airflow
is estimated critical.
Supervisor




Operator




“The water level in each sump is regularly checked by dedicated operators to see if the water level is not too high.”
Def A too high water level in a sump must
be detected at any time.
Maintain [SumpPumpedOutIfHighWater]




Def When the water level in a sump is too high,
the water must be pumped out of the mine.
“When , the pump must be turned on to pump the water out …”

Maintain [PumpOnIfHighWater]




Def When the water level in a sump is too high,
the corresponding pump must be turned on.
…
Operator




Avoid [Explosion]




Def Risks of explosion inside the mine must
be prevented at any time.
“…To avoid the risk of explosion, pumps may not be operated when …”
Maintain [PumpOffIfHighMethane]




Def Pumps may never be operated when the
methane level exceeds some critical threshold.
…
Operator

www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 9
Step 1: Build a preliminary goal model illustrated by
scenarios
Figure 15.3 – Scenario illustrating the goal Maintain[PumpOnIfHighWater]

pumpOn

: PumpActuator

pumpStart

: Operator

WaterTooHigh?

WaterOK?

pumpOff

pumpStop

www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 10
Step 1: Build a preliminary goal model illustrated by
scenarios
Figure 15.4 – Goal model fragment for the system-as-is

Operator

PumpOnIfHighWaterDetected




milestone-driven



HighWaterDetected




WaterPumped
Out If PumpOn




Sufficient
PumpCapacity




Maintain[SumpPumpedOutIfHighWater]

NoExcessive
WaterFlow




PumpOn If HighWater




Avoid[MinersInFloodedMine]




Operator



SumpsWell
Distributed

Achieve[MineEvacuatedIfCriticalLevel]




MineEvacuated
If HighMethane




MineEvacuated
If HighAirflow




by cases



HighMethane
Detected

MinersAlerted
If HMDetected




MineEvacuated
If HMAlert




Supervisor



Miner








HOW ?

WHY ?



www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 11
Step 2: Derive a preliminary object model

WHAT:
–
Identifying the stable concepts.
– Each concept is defined and classified as an entity,
assciation, attribute, agent or event.

HOW:
–
Take any conceptual object referred to by the goals
identified in the previous step.
– Identify associations and participating objects.
–
Identify generalization from objects characterized by
similar attributes, associations or domain descriptions.
– Elicit prescriptive statements about conceptual objects if
they really seem relevant. Drop them otherwise.
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 12
Step 2: Derive a preliminary object model
Figure 15.5 – Deriving a preliminary object model from goals and domain descriptions

Achieve [MinersAlertedIfHMDetected]

Def Miners inside the mine must be alerted whenever
the level of methane is estimated too high.
Maintain [PumpOnIfHighWater]




Def When the water level in a sump is too high,
the corresponding pump must be on.
1
Regulation

Pump

Motor: {on, off}
1
…
Sump


WaterLevel
Each sump is
equipped with a pump
Inside

Mine

MethaneLevel
CO-Level
Airflow
…
Miner


…
waterEvacuation

Location

Operator

…
Inspection

1 *
1 *
Def Person in charge of
safe working conditions.
Def Container placed at
selected bottom places
of the mine to collect
percolating water.
the corresponding
pump must be on.
Def Electrical device regulating the
level in each sump by water
evacuation out of the mine.

www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 13
Modeling the system-to-be

Purpose:
– Expanding the preliminary structure of stable goals and
domain concepts towards a model for system-to-be.
–
Considering alternative goal refinements and assignments

Two steps:
–
Step 3: Update the goal model with new goals…
–
Step 4: Derive the updated object model
–
Step 5: Analyse obstacles, threats and conflicts
–
Step 6: Analyse responsibilities and build the agent model
–
Step 7: Make choices among alternative options
–
Step 8: Operationalize goals in the operation model
–
Step 9: Build and analyse the behaviour model
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 14
Step 3: Update the goal model with new goals

WHAT:
–
Replay step 1 on system-to-be.

–
Goal model in step1 is expanded with alternative sub-goals and
assignments specific to system-to-be.

HOW:
–
For each problem identified in the system-as-is, derive an goal for
the system-to-be.
–
Search for prescriptive, intentional keywords in statements about
system-to-be.
–
Ask HOW/WHY questions about goals already identified.
–
Explore illustrative scenarios of alternative, better ways of doing
things.
–
Split responsibilities among agents.
–
…
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 15
Step 3: Update the goal model with new goals
Figure 15.6 – Expanded goal model fragment for the system-to-be
PumpOn If HighWater





…

PumpOn
Iff SwitchOn




PumpSwitchOn
If HighWaterDetected




SafetyController



uncontrollability-driven



highWaterSensor




PumpOn If HighWaterDetected

PumpActuator



milestone-driven



HighWaterDetected




PumpingEngine




HOW ?



WaterPumped
Out If PumpOn

Sufficient
PumpCapacity




SumpPumpedOutIfHighWater




PumpOff If LowWater



Avoid[PumpOn
WhenNoWater]




Avoid[PumpBurnedOut]




WHY ?

LowWaterDetected




PumpOff If
LowWaterDetected





…




…



lowWaterSensor




Avoid[MinersInFloodedMine]

NoExcessive
WaterFlow




SumpsWell
Distributed




www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 16
Step 4: Derive the updated object model

WHAT:
–
Replay step 2 on system-to-be.
–
The object model in step 2 is expanded by identifying the
new conceptual objects specific to the system-to-be.
–
Each new conceptual object is defined, classified and linked
to others base on the new goal definitions.

HOW:
– Use all heuristics for object model derivation in step 2.
– Identify tracking associations between environment objects

and software counterpart.
– Check the goal-object inter-view consistency rules in S[14.2]
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 17
Step 4: Derive the updated object model
Figure 15.8 – Updated object model from goals and descriptions of the system-to-be
Def Mechanism for generating
different types of alerts in the mine.
Def Person authorized to switch
the pump on or off at any time.
1
Regulation

Pump

Motor: {on, off}
Switch: {on,

off}
Capacity
1
…
Sump


WaterLevel
highThreshold
lowThreshold
Mine

MethaneLevel

CO-Level
Airflow
…
Miner


…
waterEvacuation

Location

Operator

Informed
Inspection

1 *
1 *
Supervisor

…
GasAlarm

Buzz
Alerting

AirflowAlarm

…
MethaneAlarm

Switch:
{
on,

off}
COAlarm

…
WaterSensor

Readings
Tracking

Inside

lowWater
Sensor

lowWaterSignal
highWater
Sensor

highWaterSignal
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 18
Step 5: Analyse obstacles, threats and conflicts

WHAT:
–
Identifying as many obstacles, threats and boundary

conditions as possible.
– Assessing their likelihood and criticality.
–
Exploring resolutions yielding new candidate goals as
countermeasures in the goal model.

HOW:
– Ref. Chapter 8-9.
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 19
Step 5: Analyse obstacles, threats and conflicts
Figure 15.9 – Obstacle analysis: mine safety control examples

PumpOn If HighWater




PumpOn If HighWaterDetected




HighWaterDetected




WaterPumped
Out If PumpOn

SumpPumpedOut If HighWater




LimitedWaterFlow




PumpOn
Iff SwitchOn




PumpSwitchOn
If HighWaterDetected




HighWater Not Detected



IncorrectOutput

FromController




HighWaterDetected And
Not PumpSwitchOn



SwitchOn And
Not PumpOn



ExcessiveWaterFlow




ControllerOutput
Not InTime




WaterSensor
Failure

Sump
CloggedUp




Pump
Failure




highWaterSignal
Corrupted




Avoid [MinersInFloodedMine]




MineEvacuatedIfCriticalWater

MineEvacuated
If WaterAlert

Def There is a sump with water
flow exceeding the worst-case
figure of X litres per hour.
PumpOn And
Not SwitchOn



…





MinersAlerted
If CriticalWater

strong mitigation




WaterAlarm
If CriticalWater

MinersAlerted
If WaterAlarm

www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 20
Step 6: Analyse responsibilities and build the agent model

WHAT:
–
Exploring alternative responsibility assignments.
–
All the agents forming the system need to be defined.
–
The realizability of leaf goals by the agents assigned to them has
to be checked.

HOW:
–
Ref. Chapter 11.
–
Identify any active object that a leaf goal concerns.
–
Look for agents whose capabilities match the variables evaluated in
and constrained by a leaf goal.
–
Consider abstract agents and refine these until individual roles are
reached.
–
…
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 21
Step 6: Analyse responsibilities and build the agent model

Figure 15.12 – Agent diagram for mine safety control

Motor




Buzz




Switch




Switch




Switch




highWaterSignal

lowWaterSignal




highMethaneSignal




highWater
Sensor


highWater
Sensor




HighWaterDetected




PumpSwitchOn If HighWaterDetected
And Not HighMethaneDetected

Safety
Controller



highWaterSignal




InstanceResponsibility The high-water sensor of a
sump is responsible for detecting high water in this sump

PumpSwitchOff If LowWaterDetected



lowWater
Sensor


WaterLevel




lowWater

Sensor




LowWaterDetected




Sump


lowWaterSignal




highMethane
Sensor


highMethane
Sensor




HighMethaneDetected

highMethaneSignal




Mine


MethaneLevel




MethaneAlarmSwitchOn If
HighMethaneDetected




Pump


Methane
Alarm


methaneAlarm

Actuator




PumpOn If SwitchOn




Switch




PumpActuator




MethaneAlarmOn If
MethaneAlarmSwitchOn




PumpSwitchOff If HighMethaneDetected

www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 22
Step 6: Analyse responsibilities and build the agent model
Figure 15.13 – Generated context diagram for mine safety control

Pump.Switch




highMethaneSensor.
highMethaneSignal



highWaterSensor.
highWaterSignal




Safety
Controller



methaneAlarm
Actuator

PumpActuator




highWater
Sensor




Sump.WaterLevel




lowWater
Sensor




highMethane
Sensor

Mine.MethaneLevel




lowWaterSensor.
lowWaterSignal




Pump.Motor




MethaneAlarm.
Switch




methaneAlarm.
Buzz




www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 23
Step 7: Make choices among alternative options


WHAT:
–
Evaluating the various options arising in the previous steps to
select one “best” set of options defining the final system-to-be.
–
Evaluation/selection may proceed in parallel with the preceding
steps.

HOW:
–
Using qualitative reasoning techniques to select those options
contributing the most to higher-priority soft goals.
–
Using quantitative techniques, including multi-criteria analysis
(Vincke, 1992). Ref. 16.3.2
–
Using various kinds of heuristics: favour refinements or
assignments introducing fewer or less severe risks, favour
refinements or assignments introducing fewer or less severe
conflicts,…
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 24
Step 8: Operationalize goals in the operation model

WHAT:
–
Identifying and specifying the system services
operationalizing the leaf goals in the goal model.
–
“What operations will ensure this goal?” for each behavior

leaf goal.
– Specify operations with their signature, dompre, dompost,
reqpre, reqpost, reqtrig ensuring their underlying goals.

HOW:
–
Identify operations from interaction events in illustrative
scenarios.
– Derive operations from goal fluents.
–
Refine goals, not operations.
– Generate use case diagrams.
–
…
www.wileyeurope .com/college/van lamsweerde Chap.14: Integrating multiple system views © 2009 John Wiley and Sons 25
Step 8: Operationalize goals in the operation model
Figure 15.14 – Portion of operationalization diagram for the SafetyController agent

Raise
Methane
Alarm

Switch
PumpOn


ma.Switch

PumpSwitchOn If
HighWaterDetected And
Not HighMethaneDetected




MethaneAlarmOn If
MethaneAlarmSwitchOn




PumpSwitchOff If
HighMethaneDetected




Switch
PumpOff


highWater
Sensor


lowWater
Sensor

highMethane
Sensor


Pump


Methane
Alarm


Reset
Methane
Alarm

PumpSwitchOff If
LowWaterDetected




p.Switch