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/