ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 11
Abonament PDF

Din bucătăria arhitectului software carduri de scenarii

Attila Antal
Software Arhitect
@ISDC



PROGRAMARE


Metodologia care urmează a fi prezentată în acest articol a fost dezvoltată de cei de la SEI (Software Engineering Institute, Carnegie Mellon) și face parte din metodologia ATAM (Architecture Tradeoff Analysis Method).

Articolul prezintă într-o formă simplificată această metodologie accentând latura practică.

Cardul de Scenarii

Cardurile de scenarii sunt folosite pentru argumentarea decizilor din diferite puncte de vedere. Cardurile sunt create de arhitectul din proiectul respectiv și sunt distribuite pentru evaluare de către membrii decizionali ai echipei, inclusiv de către client.

Un șablon al cardului de scenarii este prezentat în schema de mai jos. După cum se observă cardul are patru zone:

  • Zona cu detalii, unde se introduce un cod relevant al scenariului și o scurtă descriere a lui.
  • Zona cu detalii legat de mediu de lucru din punct de vedere arhitectural.
  • Zona cu deciziile care urmează să fie luate specific scenariului.
  • Zona cu argumentele arhitecturale, motivul și o diagramă simplă care reflectă obiectul scenariului.

Zona cu deciziile are un câmp de explicatii și alte patru de impact asupra arhitecturii curente. Acestea fiind:

  • Pucte Sensibile marcate cu cod S1, S2, …
  • Puncte de Compromis marcate cu cod T1, T2, …
  • Riscuri marcate cu cod R1, R2, …
  • Non-riscuri marcate cu cod N1, N2, …

Un punct sensibil înseamnă o proprietate a unei componente care este critică pentru obținerea unui atribut de calitate.

Punctul de compromis e o proprietate care afectează mai multe atribute de calitate sau e un punct sensibil pentru mai multe atribute.

Riscurile sunt decizile arhitecturale care pot să cauzeze probleme potențiale.

Non-riscurile sunt menționarea deciziilor arhitecturale bune, în cardul de scenarii au caracter informativ.

Aceste coloane pot conține una sau mai multe valori în foma codificată (menționat deja mai sus). Aceste coduri urmează să fie explicate în liste dedicate.

Studiu de caz

Pentru a prezenta cât mai real cum funcționează procedeul prin care se găsește o soluție potrivită cu ajutorul cardurilor de scenarii, voi prezenta în continuare un caz ipotetic.

Deci, un presupus client are o aplicatie în care în stratul de logică de business vrea să introducă un modul care decide și influențează rezultatele la anumite calcule. Aceasta îi va cere arhitectului proiectului (în acest context fiind vorba de noi) să vină cu niște idei de implementare.

Arhitectul, adica noi, vom realiza trei scenarii și îl vom trece printr-un procedeu de evaluare și la final încearcăm să găsim soluția cea mai potrivită.

Să vedem scenariile!

DL1: Logică Hardcodată

Scenario #: DL1

Se va folosi o logică de decizie internă, hardcodată.

Attribute(s)

Performance

Environment

În timpul rulării (Runtime)

Stimulus

Cerere de luare decizii dinspre Business Logic.

Response

Decizii luate pe baza logicii interne.

Architectural decisions

Sensitivity

Tradeoff

Risk

Nonrisk

Hardcodare

S1

 

R1

N1

Reasoning

Folosind modul de decizie "hardcoded" se reduce complexitatea și în plus se poate obține performanța maxima de executie.

Architecture Diagram

Image72022.PNG 

DL2: Logică Configurabilă

DL3: Logică Bazată pe Rule Engine

Scenario #: DL3

Se va folosi un Rule Engine pentru decizii.

Attribute(s)

Flexibilitate

Environment

În timpul rulării (Runtime)

Stimulus

Cerere de luare decizii dinspre Business Logic.

Response

Decizii luate de Rule Engine.

Architectural decisions

Sensitivity

Tradeoff

Risk

Nonrisk

Folosirea unui Rule Engine

S2, S3

T2

 

 

Maintenanță pentru baza de reguli

S4

 

R3

N2

Reasoning

Introducerea în arhitectură a unei Rule Engine aduce flexibilitate și configurabilitate.

Architecture Diagram

Image72217.PNG 

Lista Punctelor Sensibile

Code

Description

S1

Logica de decizie e greu de modificat mai târziu și necesită relansarea produsului în producție.

S2

Introduce complexitate în proiect.

S3

Necesită expertiză și/sau experiență.

S4

Comunicarea și planificarea în sync cu echipa care întreține baza de reguli.

Lista Punctelor de Compromis

Code

Description

T1

Trebuie decis dacă proprietătile vor fi recitite imediat după modificare sau numai după relansarea aplicației (flexibilate vs. garanția calculațiilor ptr. toți).

T2

Trebuie ales un Rule Engine portivit.

Lista Riscurilor

Code

Description

R1

Schimbarea logicii necesită development.

R2

Fiind fișierul de proprietăți un punct sensibil al sistemului trebuie protejat și asignate roluri specifice modificării.

Lista Non-Riscurilor

Code

Description

N1

Este ușor de realizat și garantează lansarea în timp în productie.

N2

Găsită o soluție ușoară de lansare a regulilor.

Evaluare

Pentru evaluarea scenariilor vom folosi forma tabelară a unui "Utility Tree". Enumerăm scenariile de pe carduri dar putem adăuga si altele (fără card) și rugăm părțile participante din partea clientului să dea o notă de importanță (L - low, M - medium, H - High). Coloana de dificultate va fi marcată de arhitectul proiectului.

În cazul nostru tabela va arăta astfel (coloana de importanță fiind o presupunere):

Quality Attribute

Scenario

Importance

Difficulty

Performanță

DL1: Logică hardcodată

L

L

Configurabilitate

DL2: Logică configurabilă

H

M

Flexibilitate

DL3: Logică bazată pe Rule Engine

H

H

Din tabela de mai sus trebuie selectate cele cu importantă mare, deci:

  • DL2: Logică configurabilă (H,M)
  • DL3: Logică bazată pe Rule Engine (H,H)

Fiindcă scenariul # DL3 are și dificultate mare avem nevoie de mai multe analize din partea părților și de văzut dacă într-adevăr au nevoie de această solutie. Dificultatea mare în cazul nostru putând fi tradusă prin: mai scump, timp mai mare de implementare și eventuale costuri de licentă și întreținere.

Deci putem pronunța că până se naște o decizie legat de # DL3 soluția câștigătoare va fi cel de # DL2.

Sumar

Concluziile pe care le putem trage după citirea acestui articol sunt:

  • Arhitectul trebuie să vină tot timpul cu diferite scenarii pentru o singură problemă.
  • Cardul de scenarii este un mediu de prezentare a unei idei și în același timp este și mediu pentru a aduce decizii.
  • Cardul de scenarii este prima linie unde vor fi menționate punctele sensibile, compromisurile și riscurile.
  • Fiecare card trebuie sa fie evaluat de către client sau de către reprezentantul tehnic al clientului
  • Cardurile de scenarii trebuie colectate și catalogate pentru că fac parte din procedeul de luare de decizii și pe de altă parte ele pot fi reutilizate.

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects

Attila Antal a mai scris