Design patterns – cale de creştere a fiabilităţii software

Ion IVAN
Liviu MIJACHE

Rezumat: Una dintre cele mai noi şi puternice posibilităţi de creştere a

fiabilităţii software este folosirea design pattern ca modalitate de proiectare a
unor aplicaţii software care să răspundă cerinţelor crescânde de fiabilitate.
Sunt prezentate concepte de bază, efectele acestui mod de lucru şi se propun
modalităţi de evaluare pentru fiabilitate.
Cuvinte cheie: Pattern, design, fiabilitate, enterprise applications

Software actual se confruntă cu frontiera complexităţii. Pe de-o parte se

aşteaptă ca aplicaţiile software să facă să funcţioneze, fără erori, sisteme mari,
precum si reţele de astfel de sisteme, cum sunt: reţelele electrice, sistemele de
control al traficului aerian, reţelele ale sistemelor financiare, sisteme militare de
comandă şi control, Internet. Tot al fel se aşteaptă ca aplicaţiile software să
conducă activităţile diverselor echipamente cum sunt: monitorizarea implantului
de inimă, diagnosticarea folosind instrumente nanometrice, protezele digitale.
Sistemele de dimensiuni mari, care cuprind de la câteva sute până la câteva mii
de platforme, milioane de linii de cod, miliarde de byte de date, au devenit rapid
foarte populare. Pe de altă parte de la toate aceste sisteme se aşteaptă să
funcţioneze la nivele din ce în ce mai înalte de fiabilitate, securitate şi siguranţă.
Aceste două caracteristici - creşterea rapidă a dimensiunilor şi a complexităţii –
sunt cauzele principale pentru problemele actuale ale dezvoltatorilor de sisteme
şi aplicaţii software. De aici apar cele mai multe erori şi aici trebuie îmbunătăţit
procesul de dezvoltare a aplicaţiilor software.
 1. Fiabilitatea Software

În continuare se va face referire la aplicaţiile informatice cu caracter

economic, dedicate structurilor organizaţionale orientate spre producţie şi
servicii Enterprise Applications - EA. Acum când aplicaţiile Web influenţează
totul, începând cu experienţa clienţilor până la relaţia cu vânzătorii, fiabilitatea
sistemelor informatice ale organizaţiilor sunt în creştere, devenind critice pentru
companii, clienţi, şi parteneri de afaceri. Pentru că o cădere a unei aplicaţii va
duce la o afacere pierdută şi la costuri semnificative de reparare, şi pentru că
Internet este întotdeauna deschis pentru afaceri, companiile solicită ca
fiabilitatea EA, să fie de 24 de ore timp de 7 zile. Internet a făcut din informaţie
şi în mod imediat şi din accesarea fără eroare a acesteia bunul cel mai valoros
pentru o companie.
EA reprezintă o colecţie de hardware, servicii ale sistemului de operare,
componente software, şi de cele mai multe ori procese umane care sunt
concepute pentru a colabora în scopul asigurării serviciului de procesare
aşteptat. Fiabilitatea întregii aplicaţii depinde foarte mult de fiabilitatea fiecărei
componente. Pentru că toate componentele dintr-un sistem sunt în strânsă
legătură, o cădere a unei componente va afecta fiabilitatea altora.
Căderile aplicaţiilor survin în urma a mai multe aspecte dintre care
amintim:
¾ testare inadecvată,
¾ probleme ale schimbării managementului,
¾ erori de operare,
¾ cod slab calitativ,
¾ lipsa unui proces de asigurare a calităţii,
¾ interacţiuni cu servicii sau aplicaţii externe,
¾ condiţii de operare diferite - grade de folosire mai mari,
supraîncărcare ,
¾ evenimente întâmplătoare - căderi de securitate,
¾ căderi hardware - hard-disk-uri, echipamente de reţea, servere, surse
de energie, memorie, CPU,
¾ probleme legate de mediu - energia, răcirea, focul, praf, dezastre
naturale.
Pe scurt fiabilitatea software se referă la cât de bine o aplicaţie asigură
cu acurateţe, fără eroare, conform serviciul care a fost definit în specificaţiile
funcţionale. În plus faţă de cât de mult rulează o aplicaţie fără eroare,
fiabilitatea software se mai referă şi la oferirea rezultatelor corecte şi la detecţia
şi recuperarea erorilor cu scopul de a evita căderile.
 Fiabilitatea unui sistem este o măsură a abilităţii sistemului de a
funcţiona în timp fără a înregistra căderi. în funcţie de sistem, e posibil ca
fiabilitatea pe termen lung să nu reprezinte o preocupare pentru cei ce dezvoltă
sistemul. De exemplu, să considerăm un sistem de auto-aterizare. Cerinţa de
disponibilitate a sistemului este ridicată - trebuie să fie disponibil în momentul
când primeşte o cerere de aterizare. Pe de altă parte, cerinţa de fiabilitate este
destul de redusă în sensul că sistemul nu trebuie să rămână operaţional pentru o
lungă perioadă de timp. Fiabilitatea unui sistem este măsurată în mod normal ca
timpul mediu până la cădere Mean Time To Failure , durata de viaţă aşteptată a
sistemului.
MTTF = Ore de lucru /Numărul de căderi

De exemplu dacă echipa de design se aşteaptă ca aplicaţia să ofere o

fiabilitate de o cădere la fiecare 30 de zile de operare timp de 24 de ore pe zi,
adică o cădere la fiecare 720 de ore de funcţionare. Testarea va dovedi că
aplicaţia rulează corect timp de 1800 de ore şi înregistrează numai două căderi,
rezultă că MTTF = 1800/2 = 900 ore. Altfel spus ne vom aştepta ca aplicaţia să
ruleze aproximativ 900 de ore între două căderi succesive. În acest exemplu
fiabilitatea a depăşit parametrii din design. De aceea o noţiune importantă a
fiabilităţii software este aceea că o cădere software va apărea doar în momentul
în care aplicaţia este disponibilă şi se execută.
Consecinţele căderilor variază de la a nu asigura serviciul, până la
asigurarea unui serviciu incorect, şi până la a genera date corupte şi a afecta
stabilitatea sistemului. În timp ce unele dintre căderi sunt doar inconveniente,
alte căderi variază de la întreruperi cauzatoare de pierdere de timp atunci când
un sistem de achiziţie nu este prea solicitat pentru a mai răspunde unei noi cereri
de achiziţie, până la inconveniente serioase cum ar fi un sistem bursier care nu
mai are resurse pentru a mai accepta o nouă autentificare şi până la catastrofe
majore în cazul căderii unui sistem de navigaţie al unei nave.

2. Design Patterns

În mod tradiţional fiabilitatea software este privită din punctul de

vedere al comportamentului produsului existent în comparaţie cu nivelurile
planificate înaintea ciclului de realizare. Căile de creştere tradiţionale vizează
un produs existent şi modificări pe acesta în vederea eliminării de erori.
Abordarea modernă a fiabilităţii vizează definirea de tehnici şi metode
care interacţionează pe toată durata proceselor specifice ciclului de realizare
asigurând ca fiecare stadiu al producţiei software să aibă un nivel de fiabilitate
ridicat. Este un mod activ de creştere a fiabilităţii software în timpul proiectării,
a codificării, respectiv în timpul celorlalte etape ale ciclului de realizare. Nu se
mai aşteaptă efectuarea modificărilor pe un produs finit ci, se intervine în timpul
procesului pentru a utiliza astfel de resurse încât ceea ce se obţine să fie fiabil.
Software bazat pe componente este o tehnologie eficientă de creştere a
productivităţii dezvoltatorilor şi de creştere a calităţii software în general. Din
nefericire multe dintre componente nu întrunesc specificaţiile iniţiale, chiar şi
cele care sunt construite folosind arhitecturi middleware populare cum sunt:
COM+, EJB, CORBA Component Model. Motivul pentru aceasta sunt simple:
modelele pentru componente middleware furnizează numai infrastructura care
formează elementele de bază pentru construirea sistemelor software complexe.
În mod particular, designul specific al componentelor, aspectele legate de
evoluţia, configurarea, distribuţia, concurenţa, scalabilitatea componentelor nu
sunt prezentate de modelele convenţionale ale componentelor. Rezolvarea
eficientă a acestor aspecte rămâne în responsabilitatea dezvoltatorilor. Pentru
crearea unei componente de succes pe lângă rezolvarea corectă a problemei
specifice, trebuie să se implementeze complet serviciile si funcţiile necesare
fiecărui model.
Design Pattern este o disciplina de rezolvare a acestor problemele
software care s-a dezvoltat în rândul comunităţii programatorilor de aplicaţii
orientate-obiect. Scopul principal al comunităţii de dezvoltatori ce folosesc
patterns este acela de a crea o literatură de bază care să îmbunătăţească designul
şi dezvoltarea în general. DP au devenit populari odată cu descrierea unora
dintre aceştia în [GoF95].
În această disciplină se utilizează terminologia în limba engleză, pentru
că dezvoltarea tehnologiilor a fost făcută în limba engleză. Astfel termenul
pattern este asimilat direct în limba română la fel ca termenul software. Pattern
este folosit pentru a desemna un set de elemente cheie după care se pot realiza
soluţii pentru o anumită clasă de probleme similare. Formele la plural au fost
asimilate tot în limba engleză. Numele diferiţilor patterns au fost preluate tot în
limba engleză pentru a se identifica uşor cu cele din terminologia de
specialitate. Desigur că se pot adapta şi traduce denumirile, dar în acest mod
s-ar crea confuzie între denumirile în română şi cele în engleză şi de aceea am
preferat adoptarea denumirilor internaţional recunoscute.
Patterns au rădăcini în multe discipline inclusiv literatura de
programare, dar în mod special în cartea despre panificarea urbană şi
arhitecturile clădirilor[ALEX79]. El afirmă acolo că “fiecare pattern este o
regulă tripartită, care exprimă relaţia între un anume context, o problemă şi o
soluţie”. Un pattern ca element de lucru exprimă o relaţie între un anume
context, un anume sistem de forţe care apar în mod repetat în acel context şi o
anume configuraţie spaţială care permite acestor forţe să fie rezolvate. Ca
element de limbaj, un pattern este o instrucţiune, care arată cum va fi folosită în
mod repetat, această configuraţie spaţială, pentru a rezolva sistemul de forţe dat,
de fiecare dată când contextul este relevant.
Drept urmare se afirmă că din punct de vedere software, fiecare pattern
este o regulă tripartită care exprimă o relaţie între un anume context, un anume
sistem de forţe care se manifestă în mod repetat în acel context, şi o anumită
configuraţie software care permite acestor forţe să se anuleze.
În general un pattern are patru elemente esenţiale: numele pattern,
problema, soluţia, consecinţele.
Numele pattern este un element folosit pentru descrierea unei
probleme de design, a soluţiei, şi a consecinţelor. În general conţine unul sau 2
cuvinte. Numele pattern ne permite să sporim vocabularul de design, şi să
proiectăm la un nivel superior de abstractizare. Astfel folosirea numelui ne
permite să rezumăm o cantitate apreciabilă de informaţie în doar câteva cuvinte,
ceea ce face comunicarea cu colegii, sau alţi designeri mult mai uşoară
Problema descrie când se aplică pattern. Explică problema şi contextul
ei. Descrie probleme specifice de design cum sunt modul de reprezentare al
algoritmilor ca obiecte; descrie clase sau structuri de obiecte care sunt fixe ca
design. Uneori problema include o lista de condiţii care trebuiesc îndeplinite
pentru a avea sens aplicarea pattern.
Soluţia descrie elementele care formează designul, relaţiile,
responsabilităţile şi colaborările. Soluţia nu descrie un design particular concret
sau o anume implementare, pentru că un pattern este ca un şablon care va fi
aplicat în multe situaţii diferite. În schimb pattern asigură o descriere abstractă a
problemei de design şi cum se aranjează în general elementele, clase şi obiecte,
pentru rezolvarea ei.
Consecinţele sunt rezultatul şi urmările aplicării pattern. Deşi
consecinţele nu sunt prezentate de cele mai multe ori când descriem deciziile de
design, ele sunt critice pentru evaluarea alternativelor de design precum şi a
costurilor şi beneficiilor aplicării lor. Consecinţele pentru software se referă cel
mai adesea la echilibrul spaţiu – timp. Prezintă de asemenea probleme legate de
limbaje şi implementare. Pentru că reutilizarea este un factor important în
designul software orientat obiect, consecinţele unui pattern includ impactul
asupra flexibilităţii sistemului, extensibilităţii sau a portabilităţii. Listarea
acestor consecinţe ajută şa înţelegerea şi evaluarea lor.
Numele unui DP abstractizează şi identifică aspectele cheie ale unei
structuri de design comune care face utilă crearea unui design orientat obiect,
reutilizabil. DP identifică clasele şi instanţele, rolurile şi colaborările precum şi
distribuţia responsabilităţii lor. Fiecare DP prezintă o anumită problemă de
design, şi descrie când se aplică această soluţie în contextul constrângerilor de
design existente, şi a consecinţelor aplicării acesteia.
Un PL defineşte o colecţie de patterns şi regulile pentru combinarea lor
într-o arhitectură. Limbajele de pattern descriu framework-uri sau familii
unitare de sisteme. Un framework este un set de clase care cooperează şi care
fac posibil reutilizarea designului pentru o anumită clasă de aplicaţii software.
De exemplu un framework ajută la construirea unor compilatoare pentru limbaje
diferite şi pentru platforme ţintă diferite; sau ajută la modelarea unor aplicaţii
financiare. Un framework se customizează pentru o aplicaţie particulară, prin
crearea unor subclase specifice aplicaţiei prin moştenirea unor clase abstracte
ale framework-ului.
Deşi se numesc DPs, în realitate nu se referă numai la design, ci vin să
schimbe modul tradiţional de gândire despre analiza, designul şi implementarea
aplicaţiilor software. Pentru aceasta DPs propun crearea de noi nivele de
abstractizare. De fiecare dată când se abstractizează ceva, se izolează practic
detaliile particulare de restul problemei, cu scopul declarat de a separa lucrurile
care se schimbă de lucrurile care rămân la fel. Astfel fiabilitatea respectivei
probleme supuse abstractizării este separată în fiabilitatea lucrurilor
modificabile şi fiabilitatea lucrurilor care rămân la fel. Se pleacă de la premisa
că aducerea a cât mai multe lucruri care rămân la fel într-o problemă anume va
duce la o fiabilitate sporită. Practic părţile care rămân fixe sunt considerate a
avea o fiabilitate maximă, diferenţa fiind făcută de părţile modificabile, care
sunt considerate a avea o fiabilitate mai mică. Cu cât rămân mai puţine astfel de
părţi, şi cu cât fiabilitatea părţilor fixe este mai mare se afirmă că fiabilitatea
produsului pe ansamblu a crescut.
Un pattern se spune că este bun dacă:
¾ rezolvă o problemă: pattern prezintă o soluţie nu doar principii
abstracte sau strategii;
¾ este un concept dovedit: pattern prezintă o soluţie cu rezultate
urmărite, nu doar teorii sau speculaţii;
¾ soluţia nu este evidentă: multe dintre tehnicile de rezolvare a
problemelor - de exemplu paradigmele sau metodele de design
software, încearcă se deriveze soluţiile plecând de principii; cele
mai bune patterns generează soluţii indirecte pentru o problemă
anume, abordare necesară pentru cele mai dificile probleme de
design;
¾ descrie o relaţie: patterns nu numai că descriu module, dar descriu
structuri şi mecanisme interne acestor module;
 ¾ are o componenta umană semnificativă: toate aplicaţiile software
servesc confortului uman şi calităţii vieţii; de aceea cei mai buni
patterns se referă explicit la utilitate şi estetică.

3. Categorii de design patterns

Au fost identificate următoarele categorii de patterns:

¾ idiom: se referă la modul în care este scris codul într-un limbaj

particular, pentru a rezolva o anume problemă;
¾ design specific: prezintă soluţia cu care se vine pentru rezolvarea
unei anumite problemă;
¾ design standard: se referă la modul în care se rezolvă un anumit tip
de problemă; de cele mai multe ori sunt patterns care au devenit
generali datorită reutilizării;
¾ design pattern: prezintă modul în care se rezolvă o clasă întreagă
de probleme similare; de cele mai multe ori aceştia apar după
aplicarea de mai multe ori a unui design standard, şi apoi găsirea
unui pattern comun în toate acele aplicaţii.
În [GoF95] sunt discutaţi 23 de patterns diferiţi, clasificaţi după trei
scopuri, fiecare dintre aceste scopuri referindu-se la un anume aspect care
variază: creaţional, structural şi comportamental.
Creaţional: cum este creat un obiect. Acest lucru implică adesea
izolarea detaliilor de creare a unui obiect astfel încât codul să nu fie dependent
de ce tipuri de obiect sunt, în aşa fel încât să nu fie necesară modificarea codului
când se adaugă un nou tip de obiect. În această categorie sunt incluşi patterns
denumiţi: Singleton, Factory Method şi Prototype
Structural: proiectarea obiectelor pentru satisfacerea constrângerilor
particulare ale proiectului. Aceasta se referă la modul în care obiectele sunt
conectate între ele pentru ca schimbările din sistem să nu necesite schimbări ale
acestor conexiuni.
Comportamental: obiectele care sunt responsabile cu un anume tip de
acţiuni dintr-un program . Acestea încapsulează procese care se doresc a se
executa, de exemplu interpretarea unui limbaj, răspunsul la o cerere,
implementarea unui algoritm. În această categorie sunt incluşi denumiţi:
Observer şi Visitor
Un alt criteriu pentru clasificarea DPs, ţine cont dacă un pattern se
aplică pentru clase sau pentru obiecte. Patterns pentru clase se ocupă cu relaţiile
dintre clase şi subclasele aferente. Aceste relaţii sunt stabilite prin moştenire,
aşa că sunt statice – la momentul compilării. Patterns pentru obiecte sunt
răspunzători cu legăturile dintre obiecte, care se modifică la momentul rulării şi
sunt mult mai dinamici.
Ulterior acestei abordari, care este considerată ca fiind definitoare
pentru conceptul de design patterns, pornind de la aceşti 23 de patterns s-au
dezvoltat numeroşi alţii, din ce in ce mai complecşi, care au fost clasificaţi în
noi categorii. În ultimii ani patterns au început sa fie clasficaţi în funcţie de
scop, domeniul de aplicabilitate şi de etapa din cadrul ciclului de dezvoltare
referită. În tabelele nr. 1, 2 şi 3 sunt prezentaţi o suită de patterns reprezentativi,
clasificaţi după aceste categorii. Se observă includerea între aceştia a tutror
celor 23 de patterns iniţiali precum şi participarea aceestora la definirea altora.
Clasificarea DPs în funcţie de scop
Tabelul 1
Design
Scop Descriere
Pattern
Abstract Asigură o unitate conceptuală a unui set de clase
Superclass
DPs Delegation O modalitate de extindere si folosire a unei clase
Fundamentali
Immutable Nu permite informaţiilor despre un obiect să fie
modificate după ce acesta a fost construit
Interface Instanta unei clase ofera servicii si date unei
instantei a altei clase.
Interface and O clasă care implementează o interfaţă şi extinde o
Abstract clasa abstractă
Class
Marker O clasă care implementează o interfaţă pentru a
Interface indica valoarea booleană a unui atribut al unei alte
clase
Proxy O modalitate de a accesa un obiect prin intermediul
altuia
Abstract O modalitate de a crea un obiect care
DPs Factory implementează un set de interfeţe similare.
Creaţional Builder O modalitate de construire a unui obiect complex
Factory Un obiect care reprezintă date externe sau
Method procesează evenimente externe.
Object Pool Permite refolosirea obiectelor care sunt greu de
creat sau care sunt create într-un număr limitat.
Prototype Permite unui obiect sa creeze copii ale lui însuşi
Singleton Asigură instanţierea unui singur obiect dintr-o
anumită clasa
 Design
Scop Descriere
Pattern
Composite Permite crearea recursivă de obiecte similiare într-o
DPs de manieră similară unui arbore
Partiţionare Filter (Pipe) Permite obiectelor sa fie conectate dinamica pentru
a realiza operaţii pe şiruri de date
Read-Only Asigură modificarea unui obiect numai de către
Interface unii dintre clienţii lui
Adapter Implementează o interfaţa cunoscută clienţilor săi
asigurând acces la o interfaţă necunoscută clienţilor
săi
DPs Bridge Impelementează abstractizările şi implementările în
Structural clase separate permiţând combinarea lor dinamică
Cache Permite accesarea rapidă a unor obiecte care în alt
Management fel ar dura mai mult
Decorator Extinde funcţionalităţile unui obiect într-un mod
transparent clienţilor săi
Dynamic Permite unui program să încarce la cerere diferite
Linkage clase care implementează o interfaţă cunoscută
Façade Simplică accesul la un set de obiecte prin
intermediul unui obiect pe care toate celelate
obiecte il folosesc ca sa comunice cu setul.
Flyweight Permite partajarea unei informaţii comune între
mai multe instante ale aceleiasi clase
Iterator Defineşte o interfaţă care declară metode pentru
accesul secvenţial la obiectele dintr-o colecţie
Virtual Ascunde inexistenţa unui obiect printr-un altul
Proxy care implementează aceeaşi interfaţă permiţând
intarzierea instanţierii celui din urmă
Chain of Permite unui obiect transmiterea unei comenzi fără
Responsibilit să ştie ce obiect sau ce tip de obiecte o vor
y recepţiona
DPs Command Incapsulează comenzile în obiecte pentru o uşoară
Comportame- manipulare a lor
tal Little Permite definirea unui mic limbaj care sa faciliteze
Language / rezolvarea unui set similar de probleme
Interpreter
Mediator Foloseşte un obiect pentru a coordona schimbarea
stărilor unor alte obiecte
Null Object Defineşte o alternativă la folosirea null pentru a
indica absenţa unui obiect
Observer Permite înregistrarea dinamică de către un obiect a
obiectelor care depind de el în vederea notificării
 Design
Scop Descriere
Pattern
Snapshot Permite creare de imagini ale stării unui obiect
astfel încat aceasta să fie refăcută ulterior
State Incapsulează starea unui obiect ca obiecte discrete
Strategy Încapsulează algoritmi similari în clase care sunt
subclase ale unei superclase comune.
Template O clasa abstractă care conţine doar o parte din
Method logica necesară realizării scopului
Visitor Permite realizarea unei anume operaţii pentru mai
multe obiecte prin definirea unei clase separate cu
logica necesară realizării operaţiei.
Asynchrono Asigură o coadă de procese pentru executarea lor
us asincronă.
Processing
Balking Dacă o metodă este apelată în momentul în care
DPs de obiectul nu o poate executa atunci se asigură ca
Concurenţă acea metodă nu execută nimic
Double Asigură producerea de date asincrone astfel încât
Buffering acestea sa fie pregătite înainte ca ele să fie necesare
Future Incapsulează toată logica astel încât pentru client să
nu conteze daca procesarea este sincronă sau nu
Guarded Asigură execuţia unei metode până când este
Suspension îndeplinită o condiţie
Lock Object Asigură un obiect unitar care să solicite acces unic
la mai multe obiecte
Producer- Coordonează producţia şi consumarea asincronă de
Consumer informaţii şi obiecte
Read/Write Asigură acces concurent la citire şi acces exclusiv
Lock la scriere
Scheduler Controlează ordinea în care sunt executate
metodele unui singur fir de execuţie
Single Previne apelurile concurente la o metodă să ducă la
Threaded executarea concurentă a metodei
Execution
Two-Phase Asigură ordonarea încheierii unui proces sau unui
Termination fir de execuţie
 Clasificarea DPs în funcţie de etapa de dezvoltare
Tabelul 2
Design
Etapa Descriere
Pattern
Controller Adaugă un eveniment care să decupleze clasa sursa a
unui eveniment de clasa sursă care il rezolvă.
DPs cu Creator Determină care clasă crează o instanţă a unei alte clase
Responsabilităţi
Generale Expert Adaugă responsabilitate unei clase care deţine
informaţia necesară pentru realizarea responsabilităţii
Law of Daca două clase nu trebuie să ştie de prezenţa
Demeter celeilalte atunci acestea nu trebuie să interacţioneze
direct
Low Permite modificarea unei clase astfel încât sa ducă la o
Coupling/Hig modificare facilă a designului
h Cohesion
Polymorphis Permite folosirea de metode diferite în funcţie de typul
m obiectului
Pure Permite crearea unei clase care sa nu devină greu de
Fabrication modificat
Conversationa Desigunul trebuie să admită comenzi sub formă de text
l Text
Direct Permite utilizatorului să interacţioneze cu obeictele
Manipulation manipuland reprezentări ale acestora oferită de
interfaţă
DPs ai Ephemeral Asigură feedback utilizatorilor despre starea muncii lor
Interfetei Grafice Feedback fără a interveni în fluxul natural de muncă
cu Utilizatorul Explorable Designul interfeţelor trebuie să fie indulgent cu
Interface greşelile utilizatorului
Form Permite utilizatorului să adauge date structurate sub
formă de informaţii discrete
Disabled Ascunde elementele de interfaţă care nu sunt necesare
Irrelevant într-un anumit context
Things
Interaction Mapează modalităţile de de interacţiune oferite de
Style interfaţă utilizatorului cu cerinţele aplicaţiei
Limited Evită prezentarea de valori pentru selectare la un
Selection Size anumit moment în afara unui număr maxim
Selection Permite utilizatorului să selecteze comenzi sau valori
din liste
Step-by-Step Conduce utilizatorul informândul ce urmează să facă la
Instructions pasul următor
Supplementar Afişează o fereastră suplimentară pentru informaţii
y Window suplimentare despre o fereastră părinte
Window per Fiecare acţiune completă trebuie săă aibă o fereastră
Task unică
 Design
Etapa Descriere
Pattern
Accessor Foloseste nume si definitii de funcţii care sunt uşor de
Method Name citit
Anonymous Foloseşte obiectele de tratare a evenimentelor ca
Adapter adaptoare anonime
DPs de Checked vs. Toate excepţiile interne vor fi unchecked iar cele
Organizare a Unchecked externe vor fi checked
Codului Exceptions
Conditional Controlează dacă un compilator intorduce sau ignoră
Compilation comenzi pentru debug
Composed Reorganizarea unor metode care sunt prea mari ]n
Method metode mai mici
Convert Excepţiile netratate în layerul curent vor fi convertite si
Exceptions trimise la layerul superior
Define Se definesc constantele în interfeţele claselor
Constants in
Interfaces
Extend Super Impelmentarea unei metode care modifică logica unei
clase parinte
Intention Folosirea de nume semnificative pentru acţiuni care nu
Revealing sunt executate de funcţii cu denumiri clare
Method
Server Socket Cod standard scris pentru a controla partea de server a
unui socket
Client Socket Cod standard scris pentru a controla partea de client a
unui socket
Switch Selectarea diverselor parti din cod pentru executie intr-
o clauză switch
Symbolic Folosirea de nume simbolice pentru constante
Constant
Name
Double Evită dublarea eforturilor de iniţializare ale unei
DPs de Checked resurse de către două fire de execuţie
Optimizare a Locking
Codului Hashed Transmite un apel de metodă către un obiect adaptor
Adapter asociat cu un obiect arbitrar
Objects
Lazy Iniţializrea unui obiect doar în momentul în care acesta
Initialization este necesar
Lookup Table Evită recalcularea unor valori prin calcularea lor
iniţială şi salvarea lor ulterioară
Loop Măreşte numărul de operaţii efecutate într-o singură
Unrolling iteraţie
 Design
Etapa Descriere
Pattern
Assertion Verifică dacă o metode este conformă cu apelurile
DPs de Testing clineţilor
Robusteţe a Copy Mutable Copierea unui obiect în cazul în care se doreşte
Codului Parameters nemodificarea stării acestuia prin modificarea lui.
Guaranteed Asigură terminarea unui obiect în cazul în care acesta
Cleanup nu execută corect terminarea lui
Maximize Membrii claselor trebuie să fie cât mai privaţi posibil
Privacy
Return New Un obiect returnat trebuie să fie copiat şi nu transmis
Objects from prin valoare
Accessor
Acceptance Testarea făcută pentru a vedea dacă software livrat
Testing respectă nevoile organizaţiei pentru care a fsot realizat
Black Box Definirea de teste numai pe baza cerinţele
Testing
DPs de Clean Room Cei care au proiectat sistemul nu trebuie să discute
Testare Testing specificaţiile cu cei care realizează testele
Integration Testarea împreuna, pentru prima dată, a claselor
Testing dezvoltate separat
Regression Retestarea unor module pentru a observa dacă
Testing modificările au introdus noi buguri
System Tetstarea unui sistem ca o entitate, într-un mediu
Testing similar cu cel în care va lucra
Unit Testing Testarea claselor individuale isolat de celelalte clase
din program
White Box Definirea de teste pentru toate situaţile semnificative
Testing
 Clasificarea DPs în funcţie de domeniul de aplicabilitate
Tabelul 3
Clasa Design Pattern
ACID Asigură ca rezultatul unei tranzacţii nu este inconsistent.
DPs de Transaction
Transacţii Audit Trail Menţine un set de înregistrări ale tranzacţiilor efectuate
asupra unui obiect sau unui set de obiecte
Composite Definirea de tranzacţii complexe alcătuite din tranzactii
Transaction ACID
Two Phase Un obiect care asigură că o tranzacţie complexe alcătuită
Commit din două tranzacţii ACID fie se termină, fie eşuează
Demilitarized Serverele publice de Internet se vor lega la o reţea LAN
Zone care este conectată la firewall şi la reţeaua Internet
Mobile Agent Un obiect are nevoie să acceseze volume mari de date
DPs de aflate la distanţă
Arhitecturi Object Multiplicarea unui obiect pe mai multe maşini astfel
Distribuite Replication încât el să apară clienţilor ca fiind unic
Object Request O arhitectură care permite obiectelor să facă apeluri la
Broker distanţă fără a cunoaşte detaliile apelului
Process Pair Două obiecte care lucrează în pereche pentru ca în
momentul în care unul cade celălalt să îl repornească
Prompt Repair Repararea unui obiect care cade imediat după această
cădere
Redundant Păstrarea unor obiecte redundante în cazul în care una
Independent dintre masini cade
Objects
Shared Object Un obiect care va efectua logica necesară partajării unui
alt obiect
Connection Un obiect care gestionează conexiunile dintre mai multe
Multiplexing alte oiecte
Heartbeat Transmiterea de mesaje periodice care să confirme
DPs de clientului că serverul execută acţiuni în numele clientului
Procesare Heavyweight/Lig Proiectarea de clienţi care sunt cât mai mici
Distribuită htweight Object
Mailbox Stocarea mesajelor în recipiente pentru fiecare dintre
destinatari
Object Identifier Fiecare obiect trebuie să aibă un identificator unic
Protection Proxy Limitarea accesului la un obiect furnizând alte obiecte
care pe baza drepturilor de securitate accesează un proxy
Publish- Transmiterea fiecărui mesaj către destinatarul precizat
Subscribe
Registry Un mecanism care returnează un proxy la un obiect
dându-i-se numele obiectului sau numele serviciului
Retransmission Reluarea transmisiei unui mesaj până când se încheie cu
succes
 Clasa Design Pattern
Ephemeral Cache Folosirea unei copii locale a unor obiecte de la surse de
Item date aflate la distanţă
Deep Transaction Implementarea posibilităţii de a restaura starea unui
DPs de Nesting obiect modificat prin folosirea de tranzacţii imbricate
Concurenţă Lock File Folosirea unui fişier de blocare care să gestioneze
accesul exclusiv la resurse partajate
Optimistic Folosirea de copii ale obiectelor pentru executarea de
Concurrency tranzacţii
Session Object Folosirea unui singur obiect pentru informaţiile despre o
sesiune de pe server
Static Locking Asigură preluarea blocării obiectelor în aceeaşi ordine
Order pentru toate obiectele
Thread Pool Refolosirea unui fir de execuţie aflat într-un pool dacă
recrearea unuia nou durează mai mult
DPs de Temporal Menţinerea unui istoric al valorilor unor atribute care se
Timp Property modifică de-a lungul timpului
Time Server Asigură sincronizarea ceasurilor calculatoarelor dintr-o
aplicaţie distribuită
Versioned Object Asigură regăsirea unei stării mai vechi sau viitoare a unui
obiect în funcţie de momentul temporal
CRUD Organizarea operaţiilor pe baza de date în operaţii de
Creare, Selectare, Modificare, Ştergere (Create, Retrieve,
Update and Delete)
DPs de isDirty Evitarea modificării unor date din baza de date care nu
Baze de date necesită acest lucru
Lazy Retrieval Amânarea aducerii de atribute din baza de date pentru
obiecte complexe până în momentul în care acestea sunt
necesare
Persistence Layer Menţine independenţa aplicaţiei faţă de baza de date
Stale Object Folosirea informaţiilor despre ultima stare a unui obiect
cu atribute aduse din baza de date pentru operaţii cu
versiunea actuală a obiectului
Type Conversion Organizarea metodelor de conversie a tipurilor de date în
clase de conversie

4. Descrierea design pattern

Pentru descrierea unui DP se vor folosi atât metodele grafice cât şi cele
descriptive. Metodele grafice deşi sunt importante şi utile nu sunt suficiente
deoarece prezintă produsul final al designului ca relaţie între clase şi obiecte.
Pentru reutilizarea designului, trebuie înregistrate deciziile, alternativele, şi
consecinţele care au condus la alegerea acestuia. Exemplele concrete sunt şi ele
importante pentru că ajută la înţelegerea designului prezentând modul cum
acesta este folosit în producţie.
Descrierea fiecărui DP trebuie împărţită în secţiuni după următorul model, care
face ca deciziile de alegerea a acestora să fie mai uşoare, mai uşor de citit,
înţeles, învăţat, comparat şi folosit.
¾ Numele Pattern şi clasificarea: numele pattern rezumă în unu, două
cuvinte esenţa unui pattern. Un nume bine ales este vital, pentru că
va deveni parte a vocabularului de design.
¾ Scopul: rezumă răspunsul la următoarele întrebări: Ce face
respectivul design pattern? Care îi sunt raţiunile şi scopul? Ce
problemă particulară de design este rezolvată prin respectivul
pattern?
¾ Pseudonim: alt nume sub care mai este cunoscut pattern, în cazul în
care există
¾ Motivaţia: un scenariu care ilustrează o problemă de design şi
modul în care clasele sau obiectele se structurează în cadrul pattern
pentru soluţionarea problemei. Scenariul ajută la înţelegerea descrieri
care urmează şi care este mai abstractă.
¾ Aplicabilitatea: răspunde la următoarele întrebări: Care sunt
situaţiile în care design pattern se aplică ? Care sunt exemplele de
design mai slab pe care pattern le rezolvă ? Cum sunt recunoscute
aceste situaţii?
¾ Structura: o reprezentare grafică a claselor din pattern folosind o
notaţie bazată pe OMT – Object Modeling Technique. Se folosesc de
asemenea diagrame de interacţiune, pentru a ilustra secvenţele de
cereri şi colaborările dintre obiecte.
¾ Participanţii: clasele şi/sau obiectele participante la design
pattern şi responsabilităţile lor.
¾ Colaborare: prezintă modul în care participanţii colaborează între ei
pentru rezolvarea responsabilităţilor.
¾ Consecinţe: ilustrează cum îşi suportă pattern obiectivele, care sunt
consecinţele şi rezultatele folosirii patterns şi care sunt aspectele din
structura sistemului care variază independent.
¾ Implementări: se referă la tehnicile, şi sugestiile care trebuiesc
ştiute pentru implementarea pattern, precum şi la problemele
specifice unui sau altuia dintre limbajele de programare.
¾ Exemple de cod: sunt fragmente de cod care ilustrează cum va fi
implementat pattern în diverse limbaje.
¾ Utilizări cunoscute: se referă la exemple de patterns care sunt
regăsiţi în sisteme reale.
 ¾ Relaţii cu alţi patterns: identifică alţi patterns care sunt foarte legaţi
de cel în cauză; care sunt diferenţele importante; cu care dintre
ceilalţi patterns vor fi aceştia din urmă folosiţi.

5. Concluzii

Conform unui studiu al grupului Gartner [Will00], se apreciază ca piaţa

pentru componentele prefabricate a crescut de la 1,4 miliarde USD în 1997 la
aproape 8 miliarde USD in 2002. Tot în acest studiu se aprecaiză că un procent
de 70 % din aplicaţiile software nou create vor fi asamblate din componente
până în 2003. Acelaşi studiu afirmă că piaţa componetelor va deveni domeniul
cel mai activ din cadrul pieţei de software. Windows 2000 şi mai nou Windows
Server 2003 şi EJB – Enterprise Java Beans sunt platforme mature care suportă
EA scalabile bazate pe componete. În următorii ani, majoritatea aplicaţiilor nou
create vor fi livrate pentru aceste platforme, şi în ambele cazuri folosirea
componentelor este obligatorie din punct de vedere tehnic. Iată de ce folosirea
unor componente care să fie în prealabil fiabile duce către o fiabilitate mult
sporită a aplicaţiilor. DPs sunt cheia atât pentru realizarea acestor componente
cât şi pentru asamblarea acestora în aplicaţii.

Bibliografie

[GoF95] E. GAMMA, R. Helm, R. Johnson, and J. Vlissides − Design Patterns:

Elements of Reusable Object-Oriented Software, Reading, MA:
Addison-Wesley, 1995.

[ECKE03] B. ECKEL − Thinking in Patterns, Revision 0.9, 20-05-2003,

MindView, Inc.

[COPE01] J.W. COOPER − Design Patterns and Object Oriented Programming

in Visual Basic 6 and VB.NET , IBM Thomas J Watson Research Center
January 14, 2001

[SHAL01] A. SHALLOWAY, J.R. Trott – Design Patterns Explained – A New

perspective On Object Oriented Design, 2001
[ALEX79] ALEXANDER, C., Ishikawa, S., Silverstein, M. − The Timeless
Way of Building, New York: Oxford University Press, 1979.

[LYU96] LYU, R., M., ed. − Handbook of Software Reliability Engineering,

IEEE Computer Society Press − 50 years of service −, Los Alamitos, CA.;
Computing McGraw-Hill, 1996

[WILL00] WILLIAMS J D − Raising Components, Application Development

Trends, vol. 7, no.9, Sep 2000, pp.27-32.

[FOWL02] FOWLER Martin, RICE David, FOEMMEL Matthew, HIEATT

Edward, MEE Robert, STAFFORD Randy – Patterns of Enterprise Application
Architecture - Addison-Wesley Pub Co, November , 2002

Anexa nr 1 - Lista de acronime

1. P – Pattern = prezintă modul în care se rezolvă o clasă întreagă de probleme

similare

2. DP – Design Pattern = prezintă modul în care se rezolvă o clasă întreagă de

probleme similare de proiectare software

3. DPs – Design Patterns = mulţimea de design pattern

4. PL – Pattern language = limbaj de design