Arhitecturi pentru sisteme software Curs 3 Cristina Mîndruţă Arhitecturi pentru sisteme software Slide 1 PLAN CURS Elementele care dirijează definirea arhitecturii Exprimări tipice pentru cerinţe referitoare la.
Download ReportTranscript Arhitecturi pentru sisteme software Curs 3 Cristina Mîndruţă Arhitecturi pentru sisteme software Slide 1 PLAN CURS Elementele care dirijează definirea arhitecturii Exprimări tipice pentru cerinţe referitoare la.
Slide 1
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 2
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 3
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 4
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 5
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 6
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 7
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 8
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 9
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 10
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 11
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 12
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 13
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 14
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 15
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 16
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 17
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 18
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 19
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 20
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 21
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 22
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 23
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 24
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 25
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 26
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 27
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 28
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 29
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 30
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 31
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 32
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 33
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 34
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 35
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 36
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 37
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 38
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 39
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 40
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 41
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 42
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 43
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 44
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 45
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 46
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 47
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 48
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 49
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 50
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 51
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 52
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 53
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 2
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 3
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 4
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 5
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 6
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 7
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 8
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 9
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 10
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 11
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 12
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 13
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 14
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 15
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 16
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 17
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 18
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 19
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 20
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 21
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 22
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 23
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 24
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 25
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 26
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 27
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 28
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 29
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 30
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 31
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 32
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 33
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 34
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 35
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 36
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 37
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 38
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 39
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 40
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 41
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 42
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 43
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 44
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 45
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 46
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 47
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 48
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 49
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 50
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 51
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 52
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53
Slide 53
Arhitecturi pentru sisteme software
Curs 3
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 1
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 2
Elementele care dirijează arhitectura
Elementele care dirijează (motorul) arhitectura sunt date de
cerinţele ce stau la baza proiectării arhitecturii software.
Cerinţele
funcţionale
Arhitectura
software
Atributele de
calitate
Constrângerile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 3
Cerinţele funcţionale
Cerinţele funcţionale descriu CE trebuie să facă sistemul.
La nivelul proiectării arhitecturale se stabilesc fucţiile de nivel
înalt (nu detaliile).
Pe măsură ce arhitectura este creată şi rafinată, vom afla mai
multe informaţii despre cerinţele funcţionale de detaliu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 4
Constrângerile
Constrângerile reprezintă decizii de proiectare “pre-fabricate”.
•
Constrângeri tehnice (directe).
•
Constrângeri impuse de nivelul business, de piaţă, şi/sau de
companie (indirecte).
Uneori pot apare constrângeri impuse de proiectant.
Exemplu: Pentru persistenţa datelor se poate selecta utilizarea unei baze de date.
•
Orice selecţie/decizie
devine o constrângere
pentru activitatea ulterioară de proiectare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 5
Constrângeri – exemple de constrângeri business cu
impact arhitectural
Piaţa ţintă şi timpul de lansare pe piaţă
Aşteptările referitoare la costuri şi la beneficii
Planul de furnizare incrementală
Durata de viaţă proiectată pentru sistem
Disponibilitatea forţei de muncă şi alocarea experizelor
Alinierea structurii echipei cu expertiza disponibilă şi cu
structurile software
Liniile de producţie
sau alte strategii de reutilizare
pentru amortizarea investiţiilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 6
Constrângerile tehnice
Decizii de proiectare prestabilite ce devin elemente ce îngrădesc
spaţiul de proiectare.
•
Utilizarea şi/sau integrarea cu sisteme legacy
•
Tehnologii impuse, limbaje, protocoale, standarde, etc.
Deşi originile constrângerilor sunt diferite, toate vor avea impact
(mai mult sau mai puţin) asupra deciziilor arhitecturale iniţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 7
Atribute de calitate
Cerinţele funcţionale descriu ceea ce trebuie să facă sistemul.
Cerinţele non-functionale reprezintă tot ceea ce nu este legat
de funcţionalitatea sistemului, cum ar fi modificabilitate,
performanţă, etc.
Termenul “cerinţe non-funcţionale” introduce o falsă
partiţionare, deoarece nu se pot descrie atributele de calitate
fără a descrie funcţionalitatea sistemului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 8
Atribute de calitate
Def. Atribute de calitate - caracteristici pe care sistemul trebuie să
le posede în plus faţă de funcţionalitatea sa.
Reprezintă elementele de dirijare a arhitecturii software care
sunt cel mai greu de descoperit, de exprimat şi de testat.
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 9
Atributele de calitate şi arhitectura
Deciziile arhitecturale
•
•
•
•
implementează funcţionalitatea,
îndeplinesc constrângerile,
promovează unele atribute de calitate
inhibă alte atribute de calitate.
Arhitectura este element critic în realizarea atributelor de calitate.
O modificare în arhitectură care îmbunătăţeşte o calitate poate
promova şi/sau inhiba îndeplinirea altor atribute de calitate.
Arhitectura este element critic în echilibrarea compromisurilor asupra
atributelor de calitate înainte de proiectarea de detaliu, de
implementare sau de investire în actualizări la un sistem software.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 10
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 11
Descrieri tipice pentru cerinţe de sistem
“Timpul de răspuns al sistemului pentru orice acţiune va fi mai mic de 0.5 sec”
“Funcţiile critice în raport cu timpul cum ar fi trimiterea unei comenzi,
comutarea de imagini, grafica, trebuie să fie “suficient” de performante”
“Sistemul trebuie să fie tolarant la defecte – astfel încât să fie minimizate sau
eliminate posibilitatea şi impactul căderii serverului. Disponibilitatea şi
funcţionalitatea staţiilor client trebuie menţinută pe timpul căderii serverelor sau
a altor clienţi.”
“Sistemul va permite shutdown şi restart şi toate componentele RCM
(Reliability-Centered Maintenance) pentru a reporni întregul sistem.”
“Sistemul va avea capabilitatea de a detecta căderile software şi de a reporni
automat componenta corespunzătoare.”
“O componentă softwarede tip RCM interogată va răspunde la un mesaj în
timp de max. 1 secundă.”
“...modificare şi adaptare flexibilă a HMI (Human-Machine Interface) în
vederea creării unui “look and feel” specific clientului”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 12
Descrierea atributelor de calitate (1)
Atributele de calitate sunt deseori dificil de descoperit şi de
exprimat.
Doar numele nu este suficient.
Probleme:
•
Nu există un standard larg acceptat şi utilizat – vocabularul are
variaţii mari.
•
Descrierile sunt vagi şi le lipseşte o măsura cunatificabilă.
•
Din discuţiile asupra “ilităţilor” sistemului şi ceea ce înseamnă
ele cu adevărat rezultă dezbateri non-productive.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 13
Descrierea atributelor de calitate (2)
De exemplu, fie următoarea cerinţă: “Sistemul trebuie să fie
modificabil.”
Cerinţă cu înţeles neclar.
•
Nu se poate proiecta un sistem modificabil pentru toate
schimbările potenţiale.
•
Fiecare sistem este modificabil în raport cu un set de schimbări
şi nemodificabil în raport cu alt set de schimbări.
•
Ceea ce poate interzice schimbarea sistemului sunt costul şi
planul de timp (schedule).
Problema nu este modificabilitatea – problemele sunt:
•
Cum putem anticipa mai devreme schimbările?
•
Cum putem planifica şi proiecta sistemul pentru a face faţă
schimbărilor?
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 14
Descrierea atributelor de calitate (3)
Relaţiile dintre atributele de calitate pot fi complexe.
Exemplu: Căderea sistemului poate fi un aspect de disponibilitate, de
securitate şi de utilizabilitate.
Atributele de calitate sunt deseori în tensiuni reciproce.
Dacă nu se cunoaşte care atribute de calitate sunt importante
atunci:
• Nu contează care este promovat de arhitectura proiecatată
• Tensiunile nu pot fi rezolvate în mod satisfăcător
• Nu există o bază pentru a analiza structurile
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 15
Descrierea atributelor de calitate (4)
Arhitectura software afectează majoritatea calităţilor, dar nu toate
aspectele tuturor calităţilor.
Exemplu: Să considerăm utilizabilitatea.
•
Alegerea butoanelor radio, casetelor de dialox sau a liniilor de
comandă afectează utilizabilitatea, dar acestea nu sunt decizii
arhitecturale.
•
Izolarea acestor decizii astfel încât să fie schimbabile ţine de
arhitectură, dar nu afectează modificabilitatea sau
utilizabilitatea.
Obs. Utilizabilitatea slabă este deseori un simptom al altor probleme legate
de atribute de calitate.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 16
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 17
Scenarii pentru atribute de calitate
Scenariile pentru atribute de calitate sunt metode pentru
caracterizarea mai bună a atributelor de calitate.
Caracteristicile metodei:
cuantificarea atributelor de calitate prin intermediul scenariilor.
scenariile sunt prioritizate.
bază de raţionament pentru decizii arhitecturale privind
structurile necesare pentru echilibrarea tuturor factorilor care
dirijează arhitectura.
cuantificarea este bază pentru măsurare conformanţei,
completitudinii şi succesului.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 18
Scenarii pentru atribute de calitate – 6 componente
1.
Stimul – O condiţie care afectează sistemul.
2.
Sursă de stimuli – Entitatea care a generat un stimul.
3.
Mediu (Context) – Condiţia în care a apărut stimulul.
4.
Artefact – Artefactul ce a fost stimulat de către stimul.
5.
Răspuns – Activitatea ce a rezultat din cauza stimulului.
6.
Măsura răspunsului – Măsura prin care va fi evaluat răspunsul
sistemului.
Exemplu: aributul de disponibilitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 19
Atribute de calitate
Pentru a ilustra proprietăţile diferitelor atribute de calitate folosim
următoarele exemple (atribute de calitate de prim rang) – “first class”:
•
•
•
•
Cristina Mîndruţă
disponibilitatea
modificabilitatea
performanţa
securitatea
Arhitecturi pentru sisteme software
Slide 20
Atribute de calitate - Disponibilitatea
Def. Disponibilitatea se ocupă de avariile sistemului şi de
consecinţele asociate acestora.
Avarierea (căderea) unui sistem are loc atunci când acesta nu mai
furnizează un serviciu consistent cu specificaţiile sale.
Zone de interes :
•
Prevenirea avariilor catastrofice ale sistemului
•
Detectarea avariilor sistemului
•
Revenirea cu succes din avarie
•
Timpul necesar recuperării sistemului din avarii
•
Frecvenţa avariilor
•
Moduri degradate de operare datorate avariilor
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 21
Atribute de calitate - Disponibilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• defect de: omisiune, crash,
temporizare, evenimente,
răspuns
Surse
• interne, externe, software,
hardware
Artefacte
• sistem, procesoare, software,
hardware, memorie, reţele
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Răspunsuri
• Detectare şi notificare,
înregistrare,
• Dezactivare, indisponibilizare,
continuare operare în mod
degradat
Măsuri pentru răspunsuri
• Intervalele critice de timp când
sistemul trebuie să fie disponibil
• Timpul de disponibilitate
• Intervalele de timp în care
sistemul poatre opera în mod
degradat
• Timpul de reparare
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 22
Atribute de calitate - Disponibilitatea
Exemplu de scenariu de disponibilitate:
“Un mesaj extern neanticipată este recepţionat de proces în timpul
funcţionării normale. Procesul informează operatorul despre
recepţionarea mesajului şi continuă să funcţioneze.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 23
Atribute de calitate - Modificabilitatea
Def. Modificabilitatea se referă la costul schimbării şi la uşurinţa cu
care un sistem software se poate adapta la schimbări.
Zone de interes :
• Identificarea schimbărilor posibile.
• funcţii, platforme, hardware, sisteme de operare, middleware, sisteme cu
care trebuie să opereze, protocoale, etc.
• atribute de calitate: performanţă, disponibilitate, modificabilitate ulterioară,
etc.
• Stabilirea momentului şi a executantului schimbării.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 24
Atribute de calitate - Modificabilitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• adăugare/ştergere/modificare
funcţionalitate sau atribut de
calitate
Surse
• Utilizator final, dezvoltator,
administrator sistem
Artefacte
• Sisteme, OS, hardware, software
Medii
• La execuţie, la compilare, la
construire (build), la proiectare
Cristina Mîndruţă
Răspunsuri
• Localizarea zonelor ce vor fi
modificate
• Realizarea modificărilor fără a induce
efecte colaterale
• Testarea modificării cu efort minim
• Repartizarea modificării cu efort
minim
Măsuri pentru răspunsuri
• Costul în termeni de componente,
efort şi bani
• Măsura în care modificarea afectează
alte funcţii şi/sau atribute de calitate
Arhitecturi pentru sisteme software
Slide 25
Atribute de calitate - Modificabilitatea
Exemplu de scenariu de modificabilitate:
“Un membru al echipei de dezvoltare doreşte să modifice interfaţa utilizator a.î.
fundalul să devină albastru. Modificarea se va face în cod şi vor fi necesare
3 ore prntru realizarea şi testarea ei. În urma acestei modificări nu trebuie
să apară efecte colaterale asupra comportamentului aplicaţiei.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 26
Atribute de calitate - Performanţa
Def. Performanţa se referă la temporizare: de cât timp are nevoie
sistemul pentru a răspunde la apariţia unui eveniment.
Zone de interes :
• Surse diferite de evenimente: întreruperi, mesaje, cereri de la
utilizatori, tranzacţii, etc.
• Viteze şi şabloane variabile de apariţie a evenimentelor: sporadic,
periodic, stocastic, combinaţie
• Timpul de răspuns: timpul scurs între apariţia evenimentului şi reacţia
sistemului
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 27
Atribute de calitate - Performanţa
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• Apariţia periodică, sporadică sau
stocastică a evenimentului
Surse
• internă, externă, software,
hardware
Artefacte
• sisteme, OS, hardware, software
Răspunsuri
• Procesare stimuli
Măsuri pentru răspunsuri
• întârziere, termen (deadline),
rată de transfer, rată de
insucces, pierdere date
Medii
• operaţional, test, dezvoltare,
încărcare, inert
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 28
Atribute de calitate - Performanţa
Exemplu de scenariu de performanţă:
“500 utilizatori iniţiază 1 000 tranzacţii pe minut în manieră stocastică
în cursul operării în condiţii normale şi fiecare tranzacţie este
procesată cu o întârziere medie de 2 secunde.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 29
Atribute de calitate - Securitatea
Def. Securitatea – măsura abilităţii sistemului de a rezista la
încercările neautorizate de utilizare a datelor sau serviciilor,
oferind în acelaşi timp acces utilizatorilor legitimi.
Zone de interes :
• non-repudiere: Tranzacţiile nu pot fi repudiate de către nici una din părţile
participante la tranzacţie.
• confidenţialitate: Datele şi serviciile sunt protejate la accesele neautorizate.
• integritate: Datele şi serviciile sunt furnizate conform cu specificaţiile.
• asigurare: Participanţii la o tranzacţie au în realitate identitatea pe care o
declară.
• disponibilitate: Sistemul va fi disponibil pentru utilizările legitime.
• auditing: Activităţile sunt urmărite în cadrul sistemului la nivele suficiente
pentru reconstituirea evenimentelor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 30
Atribute de calitate - Securitatea
EXEMPLE DE COMPONENTE ALE SCENARIULUI
Stimuli
• O entitate încearcă să afişeze/modifice/şteargă date sau să acceseze
date servicii din sistem
Surse
• O entitate necunoscută care este identificată corect/incorect, care este
internă/externă sistemului, autorizată/neautorizată, şi care are acces la
resurse limitate/vaste
Artefacte
• sisteme, servicii, date
Medii
• online/offline, conectate/deconectate, protejate/neprotejate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 31
Atribute de calitate - Securitatea
Răspunsuri
EXEMPLE DE COMPONENTE ALE SCENARIULUI
• Autentificare utilizator
• Ascunderea identităţii utilizatorului
• Blocarea accesului la date/servicii
• Garantarea/respingerea accesului la date/servicii
• Întegistrare acces/tentativă de acces la date, modificări la date
• Memorare date în format codificat
• Recunoaşterea de cereri de date sau servicii inexplicabil de mari sau neobişnuite
• Raportare/restricţionare acces.
Măsuri pentru răspunsuri
• Timp/efort/resurse necesare pentru a eluda cu succes măsurile de securitate
• Timp/efort/resurse necesare pentru a restaura datele/serviciile
• Probabilitatea de detectare a atacurilor
• Probabilitatea de identificare a indivizilor responsabili de atac
• Procentul serviciilor disponibile în cursul unui atac de tip “denial-of-services”
• Măsura în care datele/serviciile au fost avariate
• Măsura în care accesele legitime au fost repudiate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 32
Atribute de calitate - Securitatea
Exemplu de scenariu de securitate:
“Un individ identificat corect încearcă să modifice date din sistem de
la un site extern. Sistemul detectează comportamentul maliţios,
menţine un audit al istoricului acţiunilor individului şi reface datele
în cursul zilei curente.”
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 33
Atribute de calitate
Alte atribute de calitate la nivelul sistemului:
•
•
•
•
•
•
•
•
•
Cristina Mîndruţă
interoperabilitate
siguranţă
utilizabilitate
extensibilitate
portabilitate
scalabilitate
uşor de învăţat
mentenabilitate
testabilitate
Există şi atribute de calitate mai
particulare, specifice strict unui domeniu
(ex. Calibrabilitate).
Arhitecturi pentru sisteme software
Slide 34
Atribute de calitate
Atribute de calitate ale arhitecturii propriu-zise:
• Integritate conceptuală – există o temă (viziune) care unifică
proiectarea sistemului la toate nivelele.
• Corectitudine şi completitudine – îndeplinirea tuturor
cerinţelor cu respectarea tuturor constrângerilor.
• Constructibilitate – sistemul poate fi construit de echipa
disponibilă în timpul dat şi este deschis anumitor modificări pe
timpul procesului de dezvoltare.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 35
Atribute de calitate
•
Numirea unui atribut de calitate nu este suficientă pentru a-i
înţelege corect şi complet semnificaţia.
•
Semnificaţia reală, corectă şi completă a atributului se poate
transmite utilizând un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 36
PLAN CURS
Elementele care dirijează definirea arhitecturii
Exprimări tipice pentru cerinţe referitoare la atributele de
calitate
O metodă mai bună pentru exprimarea cerinţelor pentru
atribute de calitate
O metodă pentru descoperirea cerinţelor pentru atribute de
calitate
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 37
QAW – Quality Attribute Workshop
QAW - metodă care implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale pentru un sistem
software.
Caracteristici cheie ale metodei QAW
•
Centrată pe sistem
•
Concentrată pe stakeholder
•
Utilizată înainte de proiectarea arhitecturii software
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 38
QAW – Quality Attribute Workshop
PROCEDURA
1. Introducere şi prezentare QAW
2. Prezentarea afacerii/misiunii
3. Prezentarea planului arhitecturii
4. Identificarea elementelor care dirijează
arhitectura
5. Brainstorming pentru scenarii
6. Consolidarea scenariilor
7. Prioritizarea scenariilor
8. Rafinarea scenariilor
Cristina Mîndruţă
Reiterare de câte ori este necesar,
cu lărgirea comunităţii de stakeholder-i.
Arhitecturi pentru sisteme software
Slide 39
QAW – Quality Attribute Workshop
Participanţii:
•
O reprezentare cât se poate de diversă a
stakeholder-ilor. (nu este neobişnuită o participare de 20
stakeholder-i).
•
Echipa QAW - externă proiectului :
• Scrib QAW : capturează scenariile brute, prioritizările
lor, scenariile rafinate şi orice chestiuni relevante
• Coordonator QAW : facilitează discuţiile şi asigură
faptul că metoda este aplicată în manieră eficace şi
oportună.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 40
QAW – Quality Attribute Workshop
Pas 1:
Introducere şi prezentarea metodei QAW
Obiectiv:
Asigurarea faptului că toţi stakeholder-ii înţeleg metoda QAW şi
toţi participanţii au şansa să se prezinte.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 41
QAW – Quality Attribute Workshop
Pas 2: Prezentarea afacerii / misiunii
Obiectiv: Asigurarea faptului că toţi cei prezenţi înţeleg:
•
Contextul business al sistemului
•
Cerinţele funcţionale de nivel înalt
•
Constrângerile de nivel înalt
•
Cerinţele de nivel înalt pentru atributele de caliate
•
Planurile generale pentru dezvoltare (ciclu de viaţă,
domeniu, responsabilităţi, etc.)
OBS: Aceste elemente reprezintă date de intrare pentru QAW.
(Dacă nu sunt încă cunoscute, atunci este prea devreme pentru QAW).
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 42
QAW – Quality Attribute Workshop
Pas 3:
Prezentarea planului arhitecturii
Obiectiv:
Arhitectul explică audienţei rezultatele curente al activităţilor de
definire a arhitecturii, care includ :
•
•
•
Cristina Mîndruţă
Extragerea şi analiza cerinţelor
Constrângeri cheie la nivel tehnic şi la nivel business
Domeniul (de acţiune al) sistemului şi contextul său
Arhitecturi pentru sisteme software
Slide 43
QAW – Quality Attribute Workshop
Pas 4:
Identificarea elementelor determinante pentru arhitectură
Obiectiv:
Acord asupra elementelor cheie determinante pentru
arhitectură în raport cu contextul business
Coordonatorul QAW prezintă elementele care dirijează
arhitectura pe care le cunoaşte şi obţine
clarificări/adăugări/eliminări din partea stakeholder-ilor.
Pe lista astfel obţinută se va concentra sesiunea de brainstorming.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 44
QAW – Quality Attribute Workshop
Pas 5:
Brainstorming pentru scenarii
Obiectiv:
Generarea unei liste iniţiale de scenarii brute care reflectă
necesităţile stakeholder-ilor reprezentaţi.
Sesiune de brainstorming în care fiecare stakeholder are
ocazia să genereze cel puţin un scenariu.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 45
QAW – Quality Attribute Workshop
Pas 6:
Consolidare scenarii
Obiectiv:
Combinarea scenariilor similare pentru a preveni diluarea în
cursul procesului de votare.
Stakeholder-ii care au iniţiat scenariile au cuvântul final referitor
la faptul că scenariul lor este reprezentat în mod adecvat
într-un scenariu combinat.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 46
QAW – Quality Attribute Workshop
Pas 7: Prioritizare scenarii
Obiectiv: Prioritizarea scenariilor conform nevoilor stakeholder-
ilor reprezentaţi.
Se utilizează o schemă de votare în care fiecare
stakeholder are alocat un număr de voturi egal cu aprox.
30% din numărul scenariilor prezente.
Votarea are loc în 2 runde; fiecare stakeholder alocă în
fiecare rundă ½ din voturile sale.
Stakeholder-ii pot aloca voturi la scenarii oricum doresc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 47
QAW – Quality Attribute Workshop
Pas 8:
Rafinare scenarii
Obiectiv:
Scenariile principale sunt rafinate.
Pentru fiecare scenariu (dacă timpul o permite) coordonatorul elaborează:
•
Obiectivele business afectate
•
Descrierea atributelor de calitate relevante
•
Refrazare ca scenariu format din 6 părţi componente (stimuli, surse
stimuli, artefacte, medii, răspunsuri, măsuri pentru răspunsuri)
•
Orice întrebare pe care stakeholder-ii o au referitoare la scenariu
•
Orice problemă ce apare în cursul rafinării
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 48
QAW – Quality Attribute Workshop
produce
QAW
poate fi utilizat pentru
Cristina Mîndruţă
• Scenarii brute pentru atribute de calitate
• Prioritizarea scenariilor
• Scenarii rafinate
•
•
•
•
•
Rafinare cerinţe
Prioritizare activităţi de dezvoltare
Identificarea şi diminuarea riscurilor
Prototipuri
Proiectarea arhitecturii
Arhitecturi pentru sisteme software
Slide 49
QAW – Quality Attribute Workshop
QAW în context
QAW poate ajuta arhitecţii să înţeleagă contextul business,
comunitatea de stakeholder-i, dorinţele, necesităţile şi
aşteptările acestora în raport cu sistemul software.
Informaţiie produse de QAW reprezintă doar începutul
•
•
•
•
E posibil ca să nu fie prezenţi toţi stakeholder-ii
Timpul este limitat
Compania ar putea vrea să modifice priorităţile
Întrebări/probleme adiţionale pot să apară deoarece nu
toate datele sunt disponibile la momentul desfăşurării unui
QAW
va fi necesară o rafinare considerabilă a scenariilor.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 50
Metodologie generală
Identificarea şi gruparea cerinţelor pe categorii: funcţionale,
atribute de calitate, constrângeri tehnice şi business
Formularea cerinţelor funcţionale folosind cazuri de
utilizare
Crearea scenariilor pentru atributele de caliutate
Determinarea fixităţii constângerilor
Colaborare cu stakeholder-ii pentru a prioritiza fiecare grup
în termeni de importanţă
•
Iniţial: critice, importante, bine de avut
•
Ulterior: prioritizare în termeni de dificultate
concentrarea atenţiei pe cerinţele importante şi dificile.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 51
Şablon pentru descriere atribut de calitate
Titlu scenariu: Titlu (descriptiv)
ID scenariu: Referinţă
Descriere brută a atributului de calitate:
Fie un nume (ex. Modificabilitate) fie o propoziţie ce încearcă să descrie o cerinţă pentru un atribut de calitate sau
pentru o proprietate a sistemului.
Surse stimuli:
Sursa/sursele generatoare sau potenţial generatoare pentru stimul(i).
Stimul(i):
Fenomenul care determină sistemul să reacţioneze într-un anume fel.
Poate fi o cerinţă utilizator, un eveniment sau o întrerupere, o eroare,
o cerere de modificare, etc.
Condiţii de mediu:
Descrierea oricăror condiţii de mediu relevante care ar putea afecta
răspunsul şi măsuri semnificative ale răspunsului. Poate include
condiţii ca operare normală, încărcare de vârf, operare degradată, în
timpul dezvoltării, etc.
Elemente sistem:
Elementele sistem afectate de stimul. În etapele iniţiale ale ciclului de
dezvoltare (înainte de proiectarea arhitecturală) elementele afectate
ar putea să nu fie cunoscute. După începerea proiectării, scenariile
trebuie rafinate iar elementele identificate în momentul în care devin
cunoscute.
Răspunsul sistemului:
Răspunsul dorit din partea sistemului.
Măsuri semnificative:
Una sau mai multe măsuri semnificative prin care va fi judecată
calitatea răspunsului. Măsurile răspunsului poate fi date în termeni
de ore-persoană, detecţie erori, timp de răspuns, timp de recuperare,
etc.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 52
CONCLUZII
Elementele care dirijează arhitectura impun forma acesteia
•
cerinţe funcţionale de nivel înalt, constrângeri tehnice şi
constrângeri business, atribute de calitate
Atributele de calitate şi constrângerile sunt preponderente faţă
de funcţionalitate în dirijarea definirii structurii arhitecturale.
Atributele de calitate sunt dificil de descoperit şi de
documentat.
Scenariile pentru atribute de calitate permit caracterizarea clară
şi completă a atributelor de calitate.
QAW este o metodă ce implică stakeholder-ii sistemului în
descoperirea atributelor de calitate esenţiale.
Cristina Mîndruţă
Arhitecturi pentru sisteme software
Slide 53