From Syst em Goals to Sof tware Architecture Axel van Lamsweerde - - PDF document

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 1

From Syst em Goals to Sof tware Architecture

Axel van Lamsweerde

Univer sit y of Louvain B-1348 Louvain-la-Neuve (Belgium)

SFM-03: Sof t war e Ar chit ect ur e Ber t inor o, 22/ 09/ 03

Two essent ial act ivit ies in t he SE process ...

Requirement s Engineering (RE) =

elicit, specif y, analyze & document ...

• bj ect ives, f unct ionalit ies, qualit ies, const r aint s

⇒ st ruct ured models of syst em-t o-be

Archit ect ural Design (AD) =

• rganize, specif y, analyze & document ...

component s, int eract ions, conf igurat ions, const raint s ⇒ st r uct ur ed model of sof t ware-t o-be

Archit ect ure has big impact on achieving NFRs

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 2

The problem ...

Requirement s Engineering (RE) =

elicit, specif y, analyze & document ...

• bj ect ives, f unct ionalit ies, qualit ies, const r aint s

⇒ st ruct ured models of syst em-t o-be

Archit ect ural Design (AD) =

• rganize, specif y, analyze & document ...

component s, int eract ions, conf igurat ions, const raint s ⇒ st r uct ur ed model of sof t ware-t o-be

Archit ect ure has big impact on achieving NFRs

?

The problem ... (2)

P

• or underst anding of ...

– relat ionships requirement s ↔ archit ect ure – int ert wining RE ↔ AD

No syst emat ic way t o ...

– build/ modif y archit ect ure t o meet f unct ional/ non- f unct ional requirement s – int egrat e archit ect ural const raint s in r equir ement s document ⇒ requirement-archit ect ure mismat ch

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 3

The mismat ch problem: exacerbat ing f act ors ...

Requirement s volat ilit y vs. archit ect ural st abilit y

(e.g. new requirement s f rom using t he sof t ware)

New generat ion sof t ware ...

– ubiquit ous, mobile – het er ogeneous – open – mission-crit ical – operat ing in changing, (host ile) environment s – open source (permanent , dist ribut ed evolut ion)

Resolving t he mismat ch problem: why not j ust f orget about requirement s ??

Survey of 350 US companies, 8000 proj ect s

– success: 16 % – f ailure: 33 % – so so: 51 %

(partial functionalities,

excessive costs, big delays)

maj or source of f ailure:

poor requirement s engineering ≅ 50% responses

(St andish Gr oup, 1995)

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 4

Resolving t he mismat ch problem: why not j ust f orget about requirement s ?? Maj or source of f ailure: poor requirement s engineering ≅ 50% responses:

– lack of user involvement 13% – incomplet e requirement s 13% – changing requirement s 9% – unrealist ic expect at ions 10% – unclear goals

5%

www.st andishgroup.com/ chaos.ht ml

Resolving t he mismat ch problem: why not j ust f orget about requirement s ??

Survey of 3800 EUR organizat ions, 17 count ries

main sof t war e problems are in... – requirement s specif icat ion

>

50% responses – requirement s management 50% responses

(Eur opean Sof t war e I nst it ut e, 1996)

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 5

The problem on t he research side ...

Much work on archit ect ural descript ion & analysis

– myriads of ADLs:

ACME, C2, DARWI N, RAPI DE, WRI GHT, UML2.0 (?), ...

t he ar chit ect ur e has t o be t her e – archit ect ural pat t erns & st yles how do you compose t hem t o meet NFRs ?

Some work on archit ect ural ref inement e.g., [Mor iconi' 96]

The problem: on t he research side ... (2)

Lit t le work on archit ect ure derivat ion t o meet

f unct ional & non-f unct ional reqs

some preliminary ef f ort s on goal-orient ed approaches f or... – it erat ive evaluat ion/ t ransf ormat ion against NFRs

[Bosch&Molin ’99]

– archit ect ural ref inement [van Lamsweerde' 00] – NFR-based document at ion of design pat t erns f or select ion [Gross&Yu' 01]

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 6

Obj ect ives

Support requirement s/ archit ect ure co-design/ co-

evolut ion

Support archit ect ure derivat ion f rom requirement s

models & sof t war e specs

Make der ivat ion pr ocess…

– syst emat ic, increment al – leading t o provably/ arguably cor r ect & “good” archit ect ure – highlight ing archit ect ural views (e.g. securit y view) ⇓ goal-based archit ect ural design process

Out line

Background: some bit s of RE From syst em goals t o sof t ware requirement s

– Building goal-orient ed requirement s models – I nt ert wining bet ween lat e RE & early AD – Goal-levl reasoning f or higher assurance

From sof t ware requirement s t o sof t ware specs From sof t ware specs t o sof t ware archit ect ure

– Derivat ion of abst ract dat af low archit ect ure t o achieve f unct ional specs – St yle-based ref inement t o meet archit ect ural const r aint s – Pat t er n-based r ef inement t o achieve NFRs

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 7

Background: what is RE about ? goals

WHY? WHAT?

• perationalization

requirements, assumptions

domain knowledge Background: what is RE about ? goals

WHY? WHAT? WHO?

• perationalization

responsibility assignment requirements, assumptions

domain knowledge

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 8

Background: what is RE about ?

Requirement s elaborat ion is hard ...

– requirement s are not t here, you have t o elicit t hem & st ruct ure t hem – ranges f rom high-level, st rat egic obj ect ives t o det ailed, t echnical requirement s – involves sof t war e + envir onment – requires evaluat ion of alt ernat ives, select ion (= ar chit ect ur al decisions ?) – r aises conf lict ing concer ns – requires ant icipat ion of unexpect ed behaviors (f or r equir ement s complet eness, syst em r obust ness)

Background: goal-orient ed RE

Goal: prescript ive st at ement of int ent

(cf . David ’s not ion of int ent ion/ t ask)

Domain prop: descript ive st at ement about domain Agent : act ive component , cont rols behaviors

sof t ware-t o-be, exist ing sof t ware, device, human Goal achievement requires agent cooperat ion The more f ine-grained a goal is, t he less agent s are required

Requirement : goal assigned t o sof t ware agent Expect at ion: goal assigned t o environment agent

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 9

Background: goal-orient ed RE (2)

Dif f erent goal cat egories ...

f unct ional: prescribe expect ed services

sat isf act ion, inf ormat ion, ...

non f unct ional, ref ined in applicat ion-specif ic t erms:

– qualit y of service: accuracy securit y: conf ident ialit y, availabilit y, int egrit y, ... usabilit y perf ormance, ... – development goals: maint ainabilit y: min coupling, max cohesion, ... reusabilit y, int eroperabilit y, ... – domain-specif ic archit ect ural const raint s

Background: goal-orient ed RE (3)

Domain-specif ic archit ect ural const raint s ...

– f eat ures of environment agent s & t heir organizat ion – const rain archit ect ural design space e.g. dist ribut ion of human agent s, devices, dat a Meet ing scheduling syst em: dist ribut ion of part icipant s, meet ing init iat or Train syst em: st at ion comput er , on-boar d cont r oller , t racking syst em, ...

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 10

Background: goal-orient ed RE (4)

Dif f er ent t ypes of goals ...

– Sof t Goal achievement cannot be est ablished in clear -cut sense

→ goal sat isf icing, qualit at ive r easoning

(Mylopoulos' 92, Chung' 00) – Achieve/ Maint ain goal achievement can be ver if ied

→ goal sat isf act ion, f ormal reasoning

(Dardenne' 93, Darimont ' 96) Saf eTr anspor t at ion Tr ainsOnSameBlock Door sClosedWhileMoving BlockSpeedLimit

...

Avoid Sof t

Maint ain

Background: goal-orient ed RE (5)

Goal G is AND-ref ined int o subgoals G1

, ..., Gn if f

achieving G1, ..., Gn cont ribut es t o achieving G

t he set {G

1, ..., G n} is called ref inement of G

Gi is said t o cont ribut e posit ively t o G

The set {G1, ..., Gn} is a complet e AND-r ef inement of G if f

G1, ..., Gn are suf f icient f or achieving G in view of known domain propert ies

{G1, ..., Gn, Dom} |= G

Goal G is OR-ref ined int o ref inement s R1, ..., Gm if f

achieving t he subgoals of Ri is one alt ernat ive t o achieving G (1 ≤i ≤m)

Ri is called alt er nat ive f or G

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 11

Background: goal-orient ed RE (6)

A goal is realizable by agent if

it amount s t o a r elat ion on variables t hat are monit orable & cont rollable by t he agent monit or ed var s cont rolled var s Agent Goal Goals need t o be ref ined unt il assignable t o single agent s

Background: goal-orient ed RE (7)

Agent responsibilit y:

G is assignable t o Ag if f G is realizable by Ag

Train Controller Train Driver Passenger OR-Assignment DoorsClosed WhileMoving

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 12

Modeling goals & responsibilit ies

Maintain[Safe Speed/AccelCom'ed] Maintain[WC-SafeDistanceBetwTrains] Maintain[Safe TrainRespToComd] Mt[AccurateEstimate OfSpeed/Position] Mt[SafeComdTo NextTrainFromEstim]

Speed/Accel Control Tracking System Communic Infrastruct OnBoard TrainControl

Achv[ComdMsg SentInTime] Mt[Safe ComdMsg] Achv[SentMsg DeliveredInTime] Mt[Msg Implem]

Const raint s Request ed

Modeling goals & responsibilit ies

Ef f ect iveMeet ingScheduling Const raint sKnown Meet ingPlannedFromConst raint s

Const raint s Collect ed Const raint s Received Const raint s Merged Meet ing Not if ied

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 13

Modeling obj ect s Goal-orient ed UML class diagrams

Station Train Block On

0..1 0..1 0..1

* At DoorsClosed WhileMoving Concerns

Background: goal-orient ed RE (8)

Goal operat ionalizat ion:

G is correct ly operat ionalized by Op1

, ..., Opn if f t he specs

• f Op1, ..., Opn are necessary & suf f icient f or ensuring G

{Spec(Op1), ..., Spec(Opn)} |= G complet eness

G |= {Spec(Op1), ..., Spec(Opn)} minimalit y OpenDoors Go

DoorsClosed WhileMoving Operationalization

(complete)

CloseDoors

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 14

Out line

Background: some bit s of RE From syst em goals t o sof t ware requirement s

– Building goal-orient ed requirement s models – I nt ert wining bet ween lat e RE & early AD – Goal-based reasoning f or higher assurance

From sof t ware requirement s t o sof t ware specs From sof t ware specs t o sof t ware archit ect ure

– Derivat ion of abst ract dat af low archit ect ure t o achieve FRs – St yle-based ref inement t o meet archit ect ural const r aint s – Pat t er n-based r ef inement t o achieve NFRs

The KAOS goal-orient ed RE met hod

• 1. Domain analysis:

r ef ine/ abst r act goals

SafeTransportation

NoTrainSameBlock

SafeTransportation

NoCollision NoTrainSameBlock

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 15

The KAOS goal-orient ed RE met hod

Train Block 0:1 On

• 1. Domain analysis:

r ef ine/ abst r act goals

• 2. Domain analysis:

der ive/ st r uct ur e

• bj ect s

SafeTransportation

NoCollision NoTrainSameBlock

The KAOS goal-orient ed RE met hod

Train Block 0:1 On

• 1. Domain analysis:

r ef ine/ abst r act goals

SafeTransportation

• 2. Domain analysis:

der ive/ st r uct ur e

• bj ect s
• 3. S2B analysis:

enr iched goals (alt er nat ives)

SafeComd NoTrainSameBlock

SafeTransportation

SafeComd NoCollision NoTrainSameBlock

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 16

The KAOS goal-orient ed RE met hod

Train Block 0:1 On

• 1. Domain analysis:

r ef ine/ abst r act goals

• 2. Domain analysis:

der ive/ st r uct ur e

• bj ect s
• 3. S2B analysis:

enr iched goals (alt er nat ives)

Command Driving

• 4. S2B analysis:

enr iched obj ect s f r om new goals

SafeTransportation

SafeComd NoCollision NoTrainSameBlock

The KAOS goal-orient ed RE met hod

Train Block 0:1 On

• 1. Domain analysis:

r ef ine/ abst r act goals

SafeAcceler SafeTransportation

• 2. Domain analysis:

der ive/ st r uct ur e

• bj ect s
• 3. S2B analysis:

enr iched goals (alt er nat ives)

Command Driving

• 4. S2B analysis:

enr iched obj ect s f r om new goals

• 5. Responsibilit y analysis:

agent OR-assignment

SafeComd NoTrainSameBlock

SafeTransportation

SafeComd NoCollision NoTrainSameBlock

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 17

The KAOS goal-orient ed RE met hod

Train Block 0:1 On

• 1. Domain analysis:

r ef ine/ abst r act goals

SafeAcceler SafeTransportation

• 2. Domain analysis:

der ive/ st r uct ur e

• bj ect s
• 3. S2B analysis:

enr iched goals (alt er nat ives)

Command Driving

• 4. S2B analysis:

enr iched obj ect s f r om new goals

• 5. Responsibilit y analysis:

agent OR-assignment 1-5. Obst acle & conf lict analysis

SafeComd NoTrainSameBlock

SafeTransportation

SafeComd NoCollision NoTrainSameBlock

The KAOS goal-orient ed RE met hod

Train Block 0:1 On

• 1. Domain analysis:

r ef ine/ abst r act goals

SafeAcceler SafeTransportation

• 2. Domain analysis:

der ive/ st r uct ur e

• bj ect s
• 3. S2B analysis:

enr iched goals (alt er nat ives)

Command Driving

• 4. S2B analysis:

enr iched obj ect s f r om new goals

• 5. Responsibilit y analysis:

agent OR-assignment 1-5. Obst acle & conf lict analysis

• 6. Oper at ionalizat ion

& behavior analysis

Send Command

OnBoardController :OBC SafeComd NoTrainSameBlock

SafeTransportation

SafeComd NoCollision NoTrainSameBlock

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 18

The KAOS goal-orient ed RE met hod

Train Block 0:1 On SafeAcceler SafeTransportation Command Driving Send Command

OnBoardController :OBC SafeComd NoTrainSameBlock

At any t ime: abst r act ion (e.g. f r om scenar ios)

SafeTransportation

SafeComd NoCollision NoTrainSameBlock

Specif ying goals, obj ect s & operat ions Formal specif icat ion is opt ional ...

– t o suppor t mor e f or mal analysis & derivat ions – in KAOS:

• only when & where needed
• abst r act language f or goals, r equir ement s,

assumpt ions, domain propert ies: real-t ime t emporal logic

• more operat ional language f or operat ions:

st at e-based spec wit h t raceabilit y t o underlying goals

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 19

Some bit s of real-t ime t emporal logic

• P: P shall hold in t he next st at e

P

: P shall hold in ever y f ut ur e st at e P

W N: P shall hold in every f ut ure st at e unless N holds

◊ P: P shall hold in some f ut ure st at e

≤T P

: P shall hold in every f ut ure st at e up t o T t ime unit s

ײT P: P shall hold wit hin T t ime unit s

+ past operators: "black" symbols @P: • ¬ P ∧ P

Specif ying goals: f ormal

Goal Maintain [DoorsClosedWhileMoving] ... FormalDef ∀ tr: Train, s: Station

At (tr, st) ∧ o ¬ At (tr, st) ⇒ tr.Doors = "closed" W At (tr, next(st))

Goal Achieve [NoDelay] ... FormalDef ∀ tr: Train, s: Station

At (tr, st) ⇒ ◊≤T At (tr, next(st))

char act er izes maximal set of int ended behaviors

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 20

Specif ying operat ions: f ormal

Operation OpenDoors Input tr: Train ; Output tr': Train DomPre tr.Doors = "closed" domain description DomPost tr.Doors = "open" ReqPre for DoorsClosedWhileMoving: permission ∃ s: Station At (tr, s) ReqTrig for NoDelay:

• bligation

Stopped (tr) charact erizes maximal set of int ended st at es at snapshot

Out line

Background: some bit s of RE From syst em goals t o sof t ware requirement s

– Building goal-orient ed requirement s models – I nt ert wining bet ween lat e RE & early AD – Goal-level reasoning f or higher assurance

From sof t ware requirement s t o sof t ware specs From sof t ware specs t o sof t ware archit ect ure

– Derivat ion of abst ract dat af low archit ect ure t o achieve f unct ional specs – St yle-based ref inement t o meet archit ect ural const r aint s – Pat t er n-based r ef inement t o achieve NFRs

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 21

I nt ert wining bet ween lat e RE & early AD

(1) Alt ernat ive goal ref inement s

Par t icipant s Const r aint sKnown Const r aint sKnown ByEmailRequest s Const r aint sKnown ByE-AgendaAccess

I nt ert wining bet ween lat e RE & early AD

(1) Alt ernat ive goal ref inement s (2) Alt ernat ive agent assignment s

Par t icipant s Const r aint sKnown Const r aint sKnown ByEmailRequest s Const r aint sKnown ByE-AgendaAccess

= early “archit ect ural” choices t o meet QoS goals

Const r aint s Request ed Sof t war eRequest or Meet ingI nit iat or

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 22

I nt ert wining bet ween lat e RE & early AD

(3) Alt ernat ive granularit ies f or sof t ware agent s

Const r aint s Request ed Sof t war eRequest or Sof t war e-t o-be

Fine, f unct ion-level granularit y will be select ed t o meet NFR Maximize [Cohesion (C)] I nt ert wining bet ween lat e RE & early AD

Maintain[Safe Speed/AccelCom'ed] Maintain[WC-SafeDistanceBetwTrains] Maintain[Safe TrainRespToComd] Mt[AccurateEstimate OfSpeed/Position] Mt[SafeComdTo NextTrainFromEstim]

Speed/Accel Control Tracking System Communic Infrastruct OnBoard TrainControl

Achv[ComdMsg SentInTime] Mt[Safe ComdMsg] Achv[SentMsg DeliveredInTime] Mt[Msg Implem]

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 23

Alt ernat ive goal ref inement & assignment

Mt[PrecedTrainInfo KnownToNextTrain] Maintain[WC-SafeDistanceBetwTrains] Mt[SafeAccelFrom PrecedTrainInfo] Mt[AccurateEstimate OfSpeed/Position] Achv[PrecedTrainInfo CommunicToNextTrain]

Tracking System Communic Infrastruct OnBoard TrainControl

... dif f erent syst em proposal: f ully dist ribut ed syst em

Out line

Background: some bit s of RE From syst em goals t o sof t ware requirement s

– Building goal-orient ed requirement s models – I nt ert wining bet ween lat e RE & early AD – Goal-level reasoning f or higher assurance

From sof t ware requirement s t o sof t ware specs From sof t ware specs t o sof t ware archit ect ure

– Derivat ion of abst ract dat af low archit ect ure t o achieve f unct ional specs – St yle-based ref inement t o meet archit ect ural const r aint s – Pat t er n-based r ef inement t o achieve NFRs

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 24

Formal goal-level reasoning f or higher assurance

Early analysis on part ial models, int ert wined wit h

model const ruct ion Wide range of opport unit ies:

checking/ deriving goal ref inement s checking/ deriving operat ionalizat ions generat ing obst acles gener at ing boundar y condit ions f or conf lict goal mining f rom scenarios generat ing st at e machines f rom operat ionalizat ions reusing goal-based specs by analogy

Formal goal-level reasoning f or higher assurance

Early analysis on part ial models, int ert wined wit h

model const ruct ion

Wide range of opport unit ies:

– checking/ deriving goal ref inement s – checking/ deriving operat ionalizat ions – generat ing obst acles – gener at ing boundar y condit ions f or conf lict – goal mining f rom scenarios – generat ing st at e machines f rom operat ionalizat ions – reusing goal-based specs by analogy

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 25

Checking goal ref inement s

Aim: show t hat ref inement is correct & complet e

R, Ass, Dom |-- G R: conj unct ive set of requirement s or subgoals

Checking goal ref inement s

Aim: show t hat ref inement is correct & complet e

R, Ass, Dom |-- G R: conj unct ive set of requirement s or subgoals

Approach 1: use TL t heorem prover

heavyweight , non-const ruct ive

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 26

Checking goal ref inement s

Aim: show t hat ref inement is correct & complet e

R, Ass, Dom |-- G R: conj unct ive set of requirement s or subgoals

Approach 1: use TL t heorem prover

heavyweight , non-const ruct ive

Approach 2: use f ormal ref inement pat t erns

light weight , const ruct ive:

• t o complet e part ial ref inement s
• t o explore alt ernat ive ref inement s

Checking goal ref inement s (2) I dea:

Buid library of pat t erns (st ruct ured by t act ics) Prove pat t erns once f or all Reuse t hrough inst ant iat ion, in mat ching sit uat ion

e.g. f requent pat t erns:

C ⇒ C W T C ∧ D ⇒ ◊ T C ⇒ ◊ D C ⇒ ◊ T M ⇒ ◊ T C ⇒ ◊ M C ⇒ ◊ T milest one-dr iven case-dr iven

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 27

Checking goal ref inement s (3)

Maintain [WorstCaseStoppingDistance] Maintain SafeAcceleration Computed milest one-dr iven Achieve AccelerCommand Sent Achieve SentCommand Received Maintain ReceivedCommand Executed

Checking goal ref inement s (4)

Achieve [TrainProgress] On (tr, b) ⇒ ◊ On (tr, next(b)) Achieve [ProgressWhenGo] On (tr, b) ∧ Go [next(b)] ⇒ ◊ On (tr, next(b)) Achieve [SignalSetToGo] On (tr, b) ⇒ ◊ Go [next(b)] missing subgoal !! det ect able aut omat ically

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 28

Checking goal ref inement s (4)

Maintain [TrainWaiting] On (tr, b) ⇒ On (tr, b) W On (tr, next(b)) Achieve [TrainProgress] On (tr, b) ⇒ ◊ On (tr, next(b)) Achieve [ProgressWhenGo] On (tr, b) ∧ Go [next(b)] ⇒ ◊ On (tr, next(b)) Achieve [SignalSetToGo] On (tr, b) ⇒ ◊ Go [next(b)] mat hemat ical proof hidden case-dr iven

Checking goal ref inement s (5)

Approach 3: Early bounded model checking

– checking of goal models – part ial models – increment al checking/ debugging – on select ed obj ect inst ances (proposit ionalizat ion) – ouput : OK KO + count er -example scenar io Roundt rip use of SAT solver, NuSMV, t heorem prover Time f or demo...

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 29

The GRAI L t ool

KAOS model editor Requirements documents generation KAOS model browser

The GRAI L/ FAUST t oolkit

Early Model Checker Goal-Oriented Animator Kaos Assertion Editor AcceptanceTest Case Generator Pattern Reuse Obstacle Generator/Resolver Consistency/Completeness Analyser

KAOS m odel

Runtime Monitor & Reconciler

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 30

Generat ing obst acles

MovingOnRunway ⇒ o ReverseThrustEnabled MovingOnRunway ⇔ WheelsTurning WheelsTurning ⇒ o ReverseThrustEnabled expectation

? ?

requirement

Generat ing obst acles (2)

Deriving precondit ion f or obst ruct ion

MovingOnRunway ⇒ WheelsTur ning

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 31

Generat ing obst acles (2)

Deriving precondit ion f or obst ruct ion

MovingOnRunway ⇒ WheelsTur ning

→ goal negat ion:

◊ MovingOnRunway ∧ ¬ WheelsTur ning

Generat ing obst acles (2)

Deriving precondit ion f or obst ruct ion

MovingOnRunway ⇒ WheelsTur ning

→ goal negat ion:

◊ MovingOnRunway ∧ ¬ WheelsTur ning

→ regress t hrough Dom:

? necessary condit ions f or wheels t urning ? WheelsTur ning ⇒ ¬ Aquaplaning

• i. e. Aquaplaning ⇒ ¬ WheelsTurning

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 32

Generat ing obst acles (2)

Deriving precondit ion f or obst ruct ion

MovingOnRunway ⇒ WheelsTur ning

→ goal negat ion:

◊ MovingOnRunway ∧ ¬ WheelsTur ning

→ regress t hrough Dom:

? necessary condit ions f or wheels t urning ? WheelsTur ning ⇒ ¬ Aquaplaning

• i. e. Aquaplaning ⇒ ¬ WheelsTurning

→ RHS unif iable:

◊ MovingOnRunway ∧ Aquaplaning Warsaw obst acle

Generat ing obst acles (3)

Using f ormal obst ruct ion pat t erns

in f act we j ust used a f r equent pat t er n: T ⇒ N

◊ C ∧ ¬ N

C ⇒ T domain propert y

• bst acle

◊ C ∧ ¬ T

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 33

Verif ying/ deriving operat ionalizat ions

Build a libr ar y of f or mal operat ionalizat ion pat t erns

f or f requent goal specif icat ion pat t erns

e.g. Achieve goals: C ⇒ ◊≤d T C ⇒ T Maint ain goals: C ⇒ T C ⇒ TW N + ext ensions adapt ed f r om Dwyer et al

Prove pat t ern correct ness once f or all Reuse t hrough inst ant iat ion, in mat ching sit uat ions

Verif ying/ deriving operat ionalizat ions

Operation Op2 DomPre T DomPost ¬ T ReqPre f or Root Goal ¬ C Operation Op1 DomPre ¬ T DomPost T ReqTrig f or Root Goal C C ⇒ T pat t erns proved correct

• nce f or all

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 34

Verif ying/ deriving operat ionalizat ions

WheelsP ulseOn ⇒ RevThrust Enabled

Operation EnableRevThr ust DomPre ¬ RevThrust Enabled DomPost RevThrust Enabled ReqTrig f or Root Goal

WheelsP ulseOn

Operation DisableRevThr ust DomPre RevThrust Enabled DomPost ¬ RevThrust Enabled ReqPre f or Root Goal

¬ WheelsP ulseOn C: WheelsP ulseOn T: RevThrust Enabled

Verif ying/ deriving operat ionalizat ions

Operation Op2 DomPre T DomPost ¬ T ReqPre f or Root Goal ¬ C B (N ∧ ¬ C) Operation Op1 DomPre ¬ T DomPost T ReqTrig f or Root Goal C C ⇒ (T W (N ∧ T)) "T shall hold bet ween C and N"

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 35 KAOS/ SMs mapping f or goal-orient ed animat ion

Obj ect model Operat ion model FSMs inst ance I nst ant iat ion Compilat ion FSMs class St ruct uring Goal model

Generat ing st at e machines f rom goal operat ionalizat ions Generat ing st at e machines f rom goal operat ionalizat ions (2) Step 1: Build FSM class declarations f or each e: Ent it y ∪ Agent in Obj ect model

• creat e a new FSM class;
• build st at e at t r ibut e declar at ion f or all

behavioural at t ribut es and relat ionships of e ;

• f or each behaviour al at t r ibut e at t r

ident if y all legal st at es of at t r in DomPre/ DomPost ident if y addit ional legal st at es of at t r in Goal

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 36

Goal Maint ain[DoorsClosedWhileMoving] FormaDef ∀t r: Train, s: St at ion At (t r, s) ∧ H ¬ At (t r , s) ⇒ t r.Doors = ‘closed ’ W At (t r, next (s)) Entity St at ion Entity Train Has Speed: speedUnit Relationship next Links St at ion {card 0:1} Relationship At Links Train {card 0:1}, St at ion {card 0:N} Operation OpenDoors I nput t r: Train; Output tr: Train DomP re t r.Doors = ‘closed ’ DomP

• st t r.Doors = ‘open’

ReqP re f or DoorsClosedWhileMoving ∃ s : St at ion At (t r,s) Operation St art Train I nput t r: Train; Output t r: Train DomP re t r.St at us = ‘st opped’ DomP

• st t r.St at us = ‘moving’

ReqP re f or DoorsClosedWhileMoving t r.Doors = ‘closed’

closed Train

• pen

moving stopped St ep1 Station next : Station speed : speedUnit At ¬ At

Generat ing st at e machines f rom goal operat ionalizat ions (3) Step 2: Build transitions For each op in Operat ion model

• cr eat e a new t ransit ion class;
• op.DomPr e → sour ce st at e; (pr oposit ionalizat ion)
• op.DomP
• st → dest inat ion st at e; (pr oposit ionalizat ion)
• op.ReqPr e → guard condit ion;
• op.ReqTr ig → t rigger condit ion;
• op.DomP
• st , op.ReqP
• st → act ion vect or;
• host t he t ransit ion;

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 37

St ep2 Transit ion St ar t Tr ain SourceSt at e st opped Dest St at e moving Guard closed Act ions null OpenDoors

Goal Maint ain[DoorsClosedWhileMoving] FormaDef ∀t r: Train, s: St at ion At (t r, s) ∧ H ¬ At (t r, s) ⇒ t r.Doors = ‘closed ’ W At (t r, next (s)) Entity St at ion Entity Train Has speed: SpeedUnit Relationship next Links St at ion {card 0:1} Relationship At Links Train {card 0:1}, St at ion {card 0:N} Operation OpenDoors I nput t r: Train; Output t r : Train DomP re t r.Doors = ‘closed ’ DomP

• st t r.Doors = ‘open’

ReqP re f or DoorsClosedWhileMoving: ∃ s : St at ion At (t r, s) Operation St art Train I nput t r : Train; Output t r : Train DomP re t r.st at us = ‘st opped’ DomP

• st t r.st at us = ‘moving’

ReqP re f or DoorsClosedWhileMoving: t r.Doors = ‘closed’

closed Train

• pen

moving stopped speed : SpeedUnit At ¬ At St art Train

Generat ing st at e machines f rom goal operat ionalizat ions (4) Step3: Structure the state space

• sour ce st at e st r uct ur ing:

if st at es s1, s2 have same t ransit ion t o same dest st at e t hen aggregat e s1, s2 int o more general st at e;

• guar d migr at ion:

if guard Grd on t ransit ion T ref ers t o st at e s of host ing

• bj ect t hen move Grd as subst at e s of T.SourceSt at e

(+ i/ o t r ansit ions)

• addit ional st at e space st ruct uring by analyst

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 38

St ep3 OpenDoors closed Train

• pen

moving stopped speed : SpeedUnit At ¬ At St art Train Transit ion St ar t Tr ain SourceSt at e st opped Dest St at e moving Guard closed Act ions null Transit ion St ar t Tr ain SourceSt at e st opped Dest St at e moving Guard Act ions null CloseDoors LeaveStat StopTrain ArriveStat stopped St art Train closed Train

• pen

moving speed : SpeedUnit At ¬ At StopTrain ArriveStat LeaveStat

(Tran Van & AvL, 2003)

Out line

Background: some bit s of RE From syst em goals t o sof t ware requirement s

– Building goal-orient ed requirement s models – I nt ert wining bet ween lat e RE & early AD – Goal-based reasoning f or higher assurance

From sof t ware requirement s t o sof t ware specs From sof t ware specs t o sof t ware archit ect ure

– Derivat ion of abst ract dat af low archit ect ure t o achieve FRs – St yle-based ref inement t o meet archit ect ural const r aint s – Pat t er n-based r ef inement t o achieve NFRs

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 39

From requirement s t o sof t ware specs

Requirement s vs. sof t ware specif icat ions: measuredSpeed I : input data DoorsClosed C: controlled variables TrainMoving doorsState Envir onment M: monit ored variables O: out put result s Sof t war eToBe Out put Devices (e.g. actuators) I nput Devices (e.g. sensors)

Req ⊆ M × C Spec ⊆ I × O Spec = Translat ion (Req) such t hat {Spec, Dom} |= Req

From requirement s t o sof t ware specs (2)

To map Reqs t o Specs:

– t ranslat e goals assigned t o sof t ware agent s in vocabulary

• f sof t ware-t o-be: input -out put variables (if needed)

– map (domain) obj ect model element s t o t heir images in t he sof t ware’s obj ect model (if needed) – int roduce (non-f unct ional) accur acyGoals requiring t he consist ency bet ween monit ored/ cont rolled variables in t he environment & t heir sof t ware image (input / out put

vat iables, dat abase element s)

– int roduce input / out put agent s t o be responsible f or such accuracy goals (sensor , act uat or & ot her input / out put devices)

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 40

From requirement s t o sof t ware specs (3)

Example:

– Req: MotorReversed ⇔ MovingOnRunway – Target Spec: Reverse = ‘enabled’ ⇔ WheelPulses = ‘on’ – accuracyGoals: MovingOnRunway ⇔ WheelPulses = ‘on’ expect at ion on wheelSensor MotorReversed ⇔ Reverse = ‘enabled’ expect at ion on mot orAct uat or

Out line

Background: some bit s of RE From syst em goals t o sof t ware requirement s

– Building goal-orient ed requirement s models – I nt ert wining bet ween lat e RE & early AD – Goal-level reasoning f or higher assurance

From sof t ware requirement s t o sof t ware specs From sof t ware specs t o sof t ware archit ect ure

– Derivat ion of abst ract dat af low archit ect ure t o achieve f unct ional sw specs – St yle-based ref inement t o meet archit ect ural const r aint s – Pat t er n-based r ef inement t o achieve NFRs

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 41 Out put of archit ect ure derivat ion process St ruct ure of ...

component s, port s connect ors

– st at ic: channels, roles, const raint s – dynamic: int eract ion prot ocol

conf igurat ions

... t o be...

• cor r ect : f unct ional requirement s are met
• good qualit y: QoS & development goals are met

Assumpt ion: requirement s conf lict s are resolved bef ore

Deriving an abst ract dat af low archit ect ure

For each “f unct ional” or “crit ical” goal assigned t o

sof t ware-t o-be: def ine one dedicat ed component ... – sof t ware agent + all operat ions operat ionalizing t his goal – int erf ace = monit ored & cont rolled variables in goal f ormulat ion

Derive dat af low connect or bet ween component s f rom

dat a dependency links Flows (d, C1, C2) ≡ Cont rols (C1, d) ∧ Monit ors (C 2, d)

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 42

Const raint s Request ed

Deriving dat af low archit ect ure: example Ef f ect iveMeet ingScheduling Const raint sKnown Meet ingPlannedFromConst raint s ...

Const raint s Collect ed Const raint s Received Const raint s Merged Const raint s Request ed

Deriving dat af low archit ect ure: example Ef f ect iveMeet ingScheduling Const raint sKnown Meet ingPlannedFromConst raint s ...

Const raint s Collect ed Const raint s Received Const raint s Merged

Const r aint sRequest or Const r aint sMer ger Par t icipant

MeetRequest (Plist, m) ∧ p in Plist ⇒ ◊≤ RT ConstrReq (p, m)

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 43

Const raint s Request ed

Deriving dat af low archit ect ure: example Ef f ect iveMeet ingScheduling Const raint sKnown Meet ingPlannedFromConst raint s ...

Const raint s Collect ed Const raint s Received Const raint s Merged

Const r aint sRequest or Const r aint sMer ger Monit or s Meet Request [Plist ,m] Cont r ols Const r Req[Plist ,m] Par t icipant

Const raint s Request ed

Deriving dat af low archit ect ure: example Ef f ect iveMeet ingScheduling Const raint sKnown Meet ingPlannedFromConst raint s ...

Const raint s Collect ed Const raint s Received Const raint s Merged

Const r aint sRequest or Const r aint sMer ger Monit or s Meet Request [Plist ,m] Cont r ols Const r Req[Plist ,m] Monit or s Const r Req[Plist ,m] Par t Const r Cont r ols Const r aint sTable Par t icipant Monit or s Const r Req[Plist ,m] Cont r ols Par t Const r

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 44

Const raint s Request ed

Deriving dat af low archit ect ure: example Ef f ect iveMeet ingScheduling Const raint sKnown Meet ingPlannedFromConst raint s ...

Const raint s Collect ed Const raint s Received Const raint s Merged

Const r aint sRequest or Const r aint sMer ger Monit or s Meet Request [Plist ,m] Cont r ols Const r Req[Plist ,m] Monit or s Const r Req[Plist ,m] Par t Const r Cont r ols Const r aint sTable Par t icipant Monit or s Const r Req[Plist ,m] Cont r ols Par t Const r

Result ing dat af low archit ect ure

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Par t Const r Par t icipant

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 45 Result ing dat af low archit ect ure

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Par t Const r Const r Req[...] Par t icipant

Result ing dat af low archit ect ure

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Par t Const r

Meet ingPlannedFromConst raint s

Const r Req[...] Par t icipant

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 46 Result ing dat af low archit ect ure

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Planner Const r aint sTable[...] Par t Const r Not if ier P lan[d,loc,CT] Const r Req[...] Par t icipant

Meet ingPlannedFromConst raint s Result ing dat af low archit ect ure

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Planner Meet Request [...] Const r aint sTable[...] Par t Const r Not if ier P lan[d,loc,CT] Not if [d,loc,CT] Const r Req[...] Meet ingI nit iat or Par t icipant

Meet ingPlannedFromConst raint s

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 47

Out line

Background: some bit s of RE From syst em goals t o sof t ware requirement s

– Building goal-orient ed requirement s models – I nt ert wining bet ween lat e RE & early AD – Goal-level reasoning f or higher assurance

From sof t ware requirement s t o sof t ware specs From sof t ware specs t o sof t ware archit ect ure

– Derivat ion of abst ract dat af low archit ect ure t o achieve f unct ional specs – St yle-based ref inement t o meet archit ect ural const r aint s – Pat t er n-based r ef inement t o achieve NFRs

Ref inement t o meet archit ect ural const raint s

Domain-specif ic const raint s ... – f rom environment agent s: f eat ures, int er-relat ionships – global const raint s on archit ect ural design space e.g. Meet ing scheduling syst em: dist ribut ion of part icipant s, meet ing init iat or

I dea:

Document st yles by rules

(domain condit ions, t arget _NFR) → ef f ect

Apply r ule mat ching archit ect ural const raint Proof obligat ion: rule applicat ion must preserve propert ies

• f component s & connect or s (e.g., dat af lows)

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 48

Event Pr od Event Cons

C Event Br oker Fr ont EndEvPr od Fr ont EndEvCons

d1 d2 ! d1 ? d2 ! d2 ! d2 ? d1 ! d1 d1

Avoid Knows (Ci, Cj ) Dist ribut ed (Event P rod, Event Cons)

Event Pr od Event Cons

C

d2 St yle-based r ef inement r ule: example publishes subscr ibes

From Meet ingScheduler dat af low archit ect ure ...

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Planner Meet Request [...] Const r aint sTable[...] Par t Const r Not if ier P lan[d,loc,CT] Not if [d,loc,CT] Const r Req[...] Meet ingI nit iat or Par t icipant

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 49

Meet ingI nit iat or Par t icipant

Event Br oker

Fr ont EndI nit iat or Fr ont Endpar t icipant Const r aint sRequest or Const r aint sMer ger ? Par t Const r [...] Planner Meet Request [...] ? Const r Table[...] Par t Const r Not if ier ? Plan[...] Not if [...] Const r Req[...] ! Meet Request [...] ? Meet Request[...] ! Par t Const r ! Not if [...] ! Not if [...]

Out line

Background: some bit s of RE From syst em goals t o sof t ware requirement s

– Building goal-orient ed requirement s models – I nt ert wining bet ween lat e RE & early AD – Goal-level reasoning f or higher assurance

From sof t ware requirement s t o sof t ware specs From sof t ware specs t o sof t ware archit ect ure

– Derivat ion of abst ract dat af low archit ect ure t o achieve f unct ional specs – St yle-based ref inement t o meet archit ect ural const r aint s – Pat t er n-based r ef inement t o achieve NFRs

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 50

Archit ect ure ref inement

Many non-f unct ional goals impose const r aint s on component

int er act ion – Accuracy (C1,C2): dat a consist ency – Conf ident ialit y (C1,C2): limit at ion on inf o f low – Usabilit y (C1,C2): requirement on present at ion, dialog – et c: MinCoupling (C1,C2), I nf oHidden (C1, C2), I nt eroperable (C1,C2), ...

Some NFGs impose cont raint s on single component

– MaxCohesion (C): f ine-grained f unct ionalit y

Archit ect ure ref inement (2)

• 1. For each t er minal NFG in goal r ef inement gr aph ...

– ident if y all connect ors/ component s const r ained by it – inst ant iat e it t o t hose connect ors/ component s

Planner Not if ier Plan[d,loc,CT]

...

Securit y

Conf ident ialit y Conf ident ial P art icipConst r ...

... ...

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 51 Archit ect ure ref inement (3)

• 2. For each NFG-const rained connect or/ component ...

– ref ine it t o meet inst ant iat ed NFG

C1 C2

ch

NFG

C1 C2

ch’

C

ch” Ref inement example: mult i-level securit y

...

Securit y

Conf ident ialit y Avoid[Classif ied Dat aFlowing] ...

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 52 Ref inement example: mult i-level securit y

...

Securit y

Conf ident ialit y Avoid[Classif ied Dat aFlowing] ...

∀d: Data, C1, C2 Flows (d, C1, C2) ⇒ d.Label ≤ C2.Clearance Ref inement example: mult i-level securit y ∀d: Data, C1, C2 Flows (d, C1, C2) ⇒ d.Label ≤ C2.Clearance

C1 C2 DF

...

Securit y

Conf ident ialit y Avoid[Classif ied Dat aFlowing] ...

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 53 Ref inement example: mult i-level securit y ∀d: Data, C1, C2 Flows (d, C1, C2) ⇒ d.Label ≤ C2.Clearance

C1 C2 DF C1 C2 DF’ DF” MLS Filt er

...

Securit y

Conf ident ialit y Avoid[Classif ied Dat aFlowing] ...

Ref inement example: mult i-level securit y ∀d: Data, C1, C2 Flows (d, C1, C2) ⇒ d.Label ≤ C2.Clearance

C1 C2 DF C1 C2 DF’ DF” MLS Filt er

ReqPost for Avoid[CDF]: d.Label ≤ C2.Clearance

...

Securit y

Conf ident ialit y Avoid[Classif ied Dat aFlowing] ...

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 54 Archit ect ure ref inement (4)

• 2. For each NFG-const rained connect or/ component ...

– ref ine it t o meet inst ant iat ed NFG ...

by use of archit ect ural ref inement pat t erns:

• cat alog of ref inement pat t erns
• each pat t ern is annot at ed by underlying design

goals & t radeof f document at ion (cf . [Gross&Yu' 01])

• pat t ern select ion by goal mat ching

(conf lict resolut ion by goal priorit izat ion based on t radeof f analysis à la NFR) A f ew gener al pat t er ns ...

Avoid [Conf ident ial Dat aFlowing (C1, C2)]

C1 C2 DF C1 C2 DF’ Secur it y Filt er DF”

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 55 A f ew gener al pat t er ns ... (2)

Maint ain [Accurat e Dat a (C1, C2)]

C1 C2 DF C1 C2 DF’ Consist ency Maint ainer DF” DF

cf . Observer, MVC pat t erns A f ew gener al pat t er ns ... (3)

Maint ain [Availabilit y (C1, C2, C3)]

C1 C2 Monit or C3 C1 C2 C3

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 56 A f ew gener al pat t er ns ... (4)

Maint ain [Fault Tolerant Communicat ion (C1, C2)]

C1 C2 C1 C2 C1 C2

A f ew gener al pat t er ns ... (5)

I nf oHiding (C1,C2)

C1 C2 C1 C2 O DF get put ... put get

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 57 A f ew gener al pat t er ns ... (6)

MinCoupling (C1,C2)

C1 C2 DF C1 C2 gener at e event Regist r ar not if y event

Dat aI nt egrat ion (C1,C2)

C1 C2 DF C1 C2 Reposit or y wr it e r ead r egist er int er est

A f ew gener al pat t er ns ... (7)

MaxCohesion

C1 C C2 C Use C1 C2 C Use

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 58 Pat t ern applicat ion: back t o meet ing scheduling

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Planner Meet Request [...] Const r aint sTable[...] Par t Const r Not if ier P lan[d,loc, CT] Not if [d,loc,CT] Const r Req[...] Meet ingI nit iat or Par t icipant

Pat t ern applicat ion: back t o meet ing scheduling

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Planner Meet Request [...] Const r aint sTable[...] Par t Const r Not if ier P lan[d,loc, CT] Not if [d,loc,CT] Maint ain[Conf ident ial Par t icipant Const r aint s] Const r Req[...] Meet ingI nit iat or Par t icipant

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 59 Pat t ern applicat ion: back t o meet ing scheduling

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Planner Meet Request [...] Const r aint sTable[...] Par t Const r Not if ier P lan[d,loc,CT] Not if [d,loc,CT] Const r Req[...] Par t icI nf o Filt er

d,loc,AnonymCT

Meet ingI nit iat or Par t icipant

Pat t ern applicat ion: back t o meet ing scheduling (2)

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Planner Meet Request [...] Const r aint sTable[...] Par t Const r Not if ier P lan[d,loc,CT] Not if [d,loc,CT] Const r Req[...] Par t icI nf o Filt er

d,loc,AnonymCT

I nf oHiding (Const r aint sTable) Meet ingI nit iat or Par t icipant

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 60 Pat t ern applicat ion: back t o meet ing scheduling (2)

Const r aint sRequest or Const r aint sMer ger Const r Req[...] Planner Meet Request [...] get put ... Const r aint sTable Par t Const r Not if ier P lan[d,loc,CT] Not if [d,loc,CT] Const r Req[...] Par t icI nf o Filt er

d,loc,AnonymCT

put get Meet ingI nit iat or Par t icipant

Conclusion

Much room f or increment al analysis of part ial

models at goal level

Derivat ion of archit ect ure f rom requirement s ...

– syst emat ic – increment al – localit y principle; composit ional

Ref ined connect ors/ component s explicit ly linked

t o non-f unct ional goals ⇓ view ext ract ion t hrough archit ect ural net queries:

securit y view, accuracy view, reusabilit y view, ...

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 61

Conclusion

Much room f or increment al analysis of part ial

models at goal level

Derivat ion of archit ect ure f rom requirement s ...

– syst emat ic – increment al – localit y principle; composit ional

Ref ined connect ors/ component s explicit ly linked

t o non-f unct ional goals ⇓ view ext ract ion t hrough archit ect ural net queries:

securit y view, accuracy view, reusabilit y view, ...

Conclusion

Early Model Checker Goal-Oriented Animator Kaos Assertion Editor AcceptanceTest Case Generator Pattern Reuse Obstacle Generator/Resolver Consistency/Completeness Analyser

KAOS m odel

Runtime Monitor & Reconciler

Opport unit ies f or goal-level t ool support

From System Goals to Software Architecture SFM ’03, 22/09/03 @ Axel van Lamsweerde 62

Limit at ions & f urt her work

Only ref inement -based:

no bot t om-up propagat ion of middleware requirement s

⇓

need f or complement ary abst ract ion pat t erns

No derivat ion of int eract ion prot ocols

⇓

int egrat ion of previous work on synt hesis of concurrent int eract ion schemes f rom goal-based invar iant s

RE_NET: t owards requirement s/ archit ect ure

co-design & co-evolut ion...

– at development t ime – at run t ime

For more inf o ...

P

apers:

GOOGLE Axel van Lamsweerde goals KAOS

Fort hcoming book