From System Goals SFM ’03, 22/09/03 to Software Architecture 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 ... obj 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) = organize, 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 @ Axel van Lamsweerde 1
From System Goals SFM ’03, 22/09/03 to Software Architecture The problem ... � Requirement s Engineering (RE) = elicit, specif y, analyze & document ... obj 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) = ? organize, 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 oor 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 @ Axel van Lamsweerde 2
From System Goals SFM ’03, 22/09/03 to Software Architecture 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) @ Axel van Lamsweerde 3
From System Goals SFM ’03, 22/09/03 to Software Architecture 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) @ Axel van Lamsweerde 4
From System Goals SFM ’03, 22/09/03 to Software Architecture 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] @ Axel van Lamsweerde 5
From System Goals SFM ’03, 22/09/03 to Software Architecture 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 @ Axel van Lamsweerde 6
From System Goals SFM ’03, 22/09/03 to Software Architecture Background: what is RE about ? WHY? goals domain knowledge operationalization requirements, WHAT? assumptions Background: what is RE about ? WHY? goals domain knowledge operationalization requirements, WHAT? assumptions responsibility assignment WHO? @ Axel van Lamsweerde 7
From System Goals SFM ’03, 22/09/03 to Software Architecture 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 @ Axel van Lamsweerde 8
From System Goals SFM ’03, 22/09/03 to Software Architecture 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, ... @ Axel van Lamsweerde 9
From System Goals SFM ’03, 22/09/03 to Software Architecture 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) Sof t Saf eTr anspor t at ion Maint ain ... BlockSpeedLimit Door sClosedWhileMoving Tr ainsOnSameBlock Avoid Background: goal-orient ed RE (5) � Goal G is AND -ref ined int o subgoals G 1 , ..., G n if f achieving G 1 , ..., G n cont ribut es t o achieving G t he set { G 1 , ..., G n } is called ref inement of G G i is said t o cont ribut e posit ively t o G � The set { G 1 , ..., G n } is a complet e AND -r ef inement of G if f G 1 , ..., G n are suf f icient f or achieving G in view of known domain propert ies { G 1 , ..., G n , Dom} |= G � Goal G is OR -ref ined int o ref inement s R 1 , ..., G m if f achieving t he subgoals of R i is one alt ernat ive t o achieving G (1 ≤ i ≤ m) R i is called alt er nat ive f or G @ Axel van Lamsweerde 10
From System Goals SFM ’03, 22/09/03 to Software Architecture 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 OR-Assignment Controller DoorsClosed Train WhileMoving Driver Passenger @ Axel van Lamsweerde 11
Recommend
More recommend
