1 / 29

Composing Features by Managing Inconsistent Requirements

Composing Features by Managing Inconsistent Requirements. Robin Laney, Thein Than Tun, Michael Jackson and Bashar Nuseibeh (Department of Computing, Open University). {r.c.laney, t.t.tun, m.jackson, b.nuseibeh}@open.ac.uk. ICFI 2007, Grenoble, France. Outline. Motivation (3min)

katherinetobin
Download Presentation

Composing Features by Managing Inconsistent Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Composing Features by Managing Inconsistent Requirements Robin Laney, Thein Than Tun, Michael Jackson and Bashar Nuseibeh (Department of Computing, Open University) {r.c.laney, t.t.tun, m.jackson, b.nuseibeh}@open.ac.uk ICFI 2007, Grenoble, France.

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

  3. Motivation

  4. 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

  5. Smart Home • Feature-rich • Developed by disparate developers • Feature interactions in the environment • Dynamic conflict resolution approach is needed

  6. Window sash Window frame 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!

  7. Overview

  8. 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

  9. Problem Diagram: Security Feature • Three Descriptions • Requirement (R) • Problem World Domains (W) • Specification (S) • Argument for adequacy of the solution • W,S|─R

  10. 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 • …

  11. “Keep the awning window shut at night.” HoldsAt(IsIn(t,NBegin,NEnd), t) →HoldsAt(WindowShut, t) Formalization of Requirement

  12. If 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) Formalization of Domain Description

  13. Specifying Features

  14. Deriving Specifications Requirements Abductive Refinement Specification HoldsAt(…) Domain Descriptions Happens(…), Prohibits(…) EC Meta-rules Prohibit Predicate Initiates(…), Terminates(…), Trajectory(…)

  15. HoldsAt(β, τ) ← Initially(β) ^ ¬Clipped(0, β, τ) β … 0 τ 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)

  16. Clipped(τ1, β, τ2) ↔ ∃α, τ [ Happens(α, τ) ^ τ1 < τ < τ2^ Terminates(α, β, τ)] Terminates(α, β, τ) β Terminates(tiltOut, WindowShut, t) (D6) … 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

  17. Prohibit(α, τ1, τ2) ≡ ¬∃α,τ • Happens(α, τ) ^ τ1 < τ < τ2 Prohibit(α, 0, τ) β … 0 τ 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)

  18. ComposingFeatures

  19. 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

  20. 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}

  21. Composition Frame merge

  22. 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)

  23. Prohibit From To By P tiltOut 20:00 07:00 SF … … … … 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)

  24. ConcludingRemarks

  25. 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

  26. Questions?

  27. References

  28. Selected References • D. Bjørner. Towards posit & prove calculi for requirements engineering and software design, volume 2635 of LNCS, pages 58–82. Springer, 2004. • M. Jackson. Problem Frames. ACM Press & Addison Wesley, 2001. • P. Zave. Feature interactions and formal specifications in telecommunications. IEEE Computer, 26(8):20–30, 1993. • R. Laney, L. Barroca, M. Jackson, and B. Nuseibeh. Composing requirements using problem frames. In RE’04, pages 122–131. IEEE Computer Society, 2004.

  29. Department of ComputingThe Open UniversityWalton HallMilton KeynesMK7 6AAUK http://mcs.open.ac.uk/pass-external/

More Related