composing features by managing inconsistent requirements robin laney, thein than tun, michael...

Composing Features by Managing Inconsistent Requirements

Robin Laney, Thein Than Tun, Michael Jackson and Bashar Nuseibeh

(Department of Computing, Open University)

ICFI 2007, Grenoble, France.

{r.c.laney, t.t.tun, m.jackson, b.nuseibeh}@open.ac.uk

Outline• Motivation (3min)• Overview (5min)• Specifying Features (5min)• Composing Features (5min)• Resolving Inconsistency (5min)• Concluding Remarks (2)

Motivation

Context• Approaches to system development involve

– decomposing requirements into features– solving sub-problems of individual features– recomposing the solutions

• What if feature solutions are inconsistent?• Static resolution can be over-restrictive

Smart Home• Feature-rich• Developed by

disparate developers• Feature interactions in

the environment• Dynamic conflict

resolution approach is needed

An Illustrative Example• Control of a motorized awning window in smart home applications

• Consider two requirements:– “Keep the awning window shut at night.”– “If it is hot indoors (i.e. hotter than the required temperature)

and cold outside (i.e. colder than the temperature indoors), open the awning window.”

• Resolving them statically is not very smart!

Window frame

Window sash

Overview

Ingredients of Proposed Solution• Problem Frames approach (PF) to organize descriptions

of features• Event Calculus (EC) to formalize requirement and

domain properties, and systematically derive specifications

• Composition Frames to recompose feature solutions and resolve conflicts

• Introduce the Prohibit predicate into EC which assists in dynamic composition

Problem Diagram: Security Feature

• Three Descriptions– Requirement (R)– Problem World

Domains (W)– Specification (S)

• Argument for adequacy of the solution– W,S|─R

Event Calculus• Predicate logic system• An event denotes an action that happens at a time

– Happens(e1, t1) -- the event e1 happens at time point t1

• A fluent denotes a state of the system– HoldsAt(f1, t1) -- the fluent f1 holds at time point t1

• Some Standard Predicates– Initiates(e1, f1, t1) -- the fluent f1 starts to hold after the event e1

at t1– Terminates(e1, f1, t1) -- the fluent f1 ceases to hold after the

event e1 at t1

– …

Formalization of Requirement

“Keep the awning window shut at night.”

HoldsAt(IsIn(t,NBegin,NEnd), t) → HoldsAt(WindowShut, t)

Formalization of Domain DescriptionIf the window is tilted out, it starts tilting out (D1) until the window is fully open (D2) or the window is tilted in (D7). …

Initiates(tiltOut, TiltingOut, t) (D1)

Trajectory(TiltingOut, t, WindowOpen, suffopentime) (D2)

Terminates(tiltIn, TiltingOut, t) (D7)

Specifying Features

Deriving Specifications

AbductiveRefinement

Requirements

DomainDescriptions

Specification

ECMeta-rules

ProhibitPredicate

HoldsAt(…)

Initiates(…),Terminates(…),Trajectory(…)

Happens(…),Prohibits(…)

Deriving Security Feature specification• (State the requirement)

HoldsAt(IsIn(t,NBegin,NEnd), t) → HoldsAt(WindowShut, t)

• (Refine the conclusion by applying EC1)Initially(WindowShut) ^ ¬Clipped(0,WindowShut, t)

HoldsAt(β, τ) ← Initially(β) ^

¬Clipped(0, β, τ)

0 τ…

β

Derivation (cont…)• (Apply DEF1 to the second sub-clause)

Initially(WindowShut) ^ ¬∃a1, t1 • Happens(a1, t1) ^ Terminates(a1, WindowShut, t1) ^ 0 < t1 < t

• (Unify the Terminate sub-clause with D6)Initially(WindowShut) ^ ¬∃t1 • Happens(tiltOut, t1)^Terminates(tiltOut, WindowShut, t1) ^ 0 < t1 < t

Clipped(τ1, β, τ2) ↔ ∃α, τ [ Happens(α, τ) ^

τ1 < τ < τ2^Terminates(α, β, τ)]

0 τ…

β

Terminates(α, β, τ)

Terminates(tiltOut, WindowShut, t) (D6)

Derivation (cont…)• (Terminate sub-clause is an axiom)Initially(WindowShut) ^ ¬∃t1 • Happens(tiltOut, t1) ^ 0 < t1 < t

• (Introduce the Prohibit predicate for partial spec)HoldsAt(IsIn(t,NBegin,NEnd), t) → Initially(WindowShut) ^ Prohibit(tiltOut, 0, t)

Prohibit(α, τ1, τ2) ≡ ¬∃α,τ • Happens(α, τ) ^

τ1 < τ < τ2

0 τ…

β

Prohibit(α, 0, τ)

ComposingFeatures

Composing Features• Four weakened conjunction operators

– Option 1: SR^{any} TR – No control

– Option 2: SR^{control} TR – Exclusion

– Option 3: SR^{SR} TR – Exclusion with priority

– Option 4: SR^{important,SR} TR – Exclusion with fine grain priority

Composition Frame

a:TiP! {NBegin, NEnd}a’:CC! {NBegin, NEnd} e:TeP! {NiceTemp} e’:CC! {NiceTemp} f:OTS! {OutTemp} f’:CC! {OutTemp} g:ITS! {InTemp} g’:CC! {InTemp} b:CC! {tiltIn, tiltOut} b’:SF! {tiltIn, tiltOut, Prohibit(...)} b”:CCF! {tiltIn, tiltOut, Prohibit(...)} c:W! {WindowShut, WindowOpen}

Composition Frame

merge

Specifying Composition Controller• SR ^{any} TR – any emergent behaviour is OK

– a:e → a’:e (1) – e:e → e’:e (2)– f:e → f’:e (3)– g:e → g’:e (4)– b’:e → b:e (5)– b”:e → b:e (6)

Specifying Composition Controller• SR ^{control} TR – give SR and TR exclusive control

– b’:prohibit (e, t1, t2) → insert((e, t1, t2, ‘SF’), P) (5.a)

– b’:e [∀t1, t2, m • t1 ≤ t ≤ t2 ^ m≠‘SF’ ^ (e, t1, t2, m) ∉ P] → b:e (5.b)

– b’:e [∃t1, t2, m • t1 ≤ t ≤ t2 ^ m≠‘SF’ ^ (e, t1, t2, m) ∈ P ] → ignore (5.c)

– b’:e [∀t1, t2, m • t1 ≤ t ≤ t2 ^ m=‘SF’ ^ (e, t1, t2, m) ∈ P] → error (5.d)

Prohibit

PFrom To By

tiltOut 20:00 07:00 SF… … … …

ConcludingRemarks

Concluding Remarks• Feature interactions caused by inconsistent

requirements• Interactions manifest in the environment• Problem Frames and Event Calculus as complementary

techniques• Feature specifications are derived systematically,

highlighting possible interactions in Prohibit predicate• Features can be developed independently• Inconsistency resolved at runtime

Questions?

References

Selected References1. D. Bjørner. Towards posit & prove calculi for

requirements engineering and software design, volume 2635 of LNCS, pages 58–82. Springer, 2004.

2. M. Jackson. Problem Frames. ACM Press & Addison Wesley, 2001.

3. P. Zave. Feature interactions and formal specifications in telecommunications. IEEE Computer, 26(8):20–30, 1993.

4. R. Laney, L. Barroca, M. Jackson, and B. Nuseibeh. Composing requirements using problem frames. In RE’04, pages 122–131. IEEE Computer Society, 2004.

Department of ComputingThe Open UniversityWalton HallMilton KeynesMK7 6AAUK

http://mcs.open.ac.uk/pass-external/