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.
- 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.
- 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ă.
- 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.
Tabelul nr. 1 Clasificarea DPs în funcţie de scop
Scop
|
Design
Pattern
|
Descriere
|
DPs
Fundamentali
|
Abstract
Superclass
|
Asigură o
unitate conceptuală a unui set de clase
|
Delegation
|
O modalitate de
extindere si folosire a unei clase
|
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
Abstract Class
|
O clasă care
implementează o interfaţă şi extinde o clasa abstractă
|
Marker
Interface
|
O clasă care
implementează o interfaţă pentru a indica valoarea booleană a unui atribut al
unei alte clase
|
Proxy
|
O modalitate de
a accesa un obiect prin intermediul altuia
|
DPs
Creaţional
|
Abstract
Factory
|
O modalitate de
a crea un obiect care implementează un set de interfeţe similare.
|
Builder
|
O modalitate de
construire a unui obiect complex
|
Factory Method
|
Un obiect care
reprezintă date externe sau 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
|
DPs de Partiţionare
|
Composite
|
Permite crearea
recursivă de obiecte similiare într-o manieră similară unui arbore
|
Filter (Pipe)
|
Permite
obiectelor sa fie conectate dinamica pentru a realiza operaţii pe şiruri de
date
|
Read-Only
Interface
|
Asigură
modificarea unui obiect numai de către unii dintre clienţii lui
|
DPs
Structural
|
Adapter
|
Implementează o
interfaţa cunoscută clienţilor săi asigurând acces la o interfaţă necunoscută
clienţilor săi
|
Bridge
|
Impelementează
abstractizările şi implementările în clase separate permiţând combinarea lor
dinamică
|
Cache
Management
|
Permite
accesarea rapidă a unor obiecte care în alt fel ar dura mai mult
|
Decorator
|
Extinde
funcţionalităţile unui obiect într-un mod transparent clienţilor săi
|
Dynamic Linkage
|
Permite unui
program să încarce la cerere diferite 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 Proxy
|
Ascunde
inexistenţa unui obiect printr-un
altul care implementează aceeaşi interfaţă permiţând intarzierea
instanţierii celui din urmă
|
DPs
Comportamen-
tal
|
Chain of
Responsibility
|
Permite unui
obiect transmiterea unei comenzi fără să ştie ce obiect sau ce tip de obiecte
o vor recepţiona
|
Command
|
Incapsulează
comenzile în obiecte pentru o uşoară manipulare a lor
|
Little Language
/ Interpreter
|
Permite
definirea unui mic limbaj care sa faciliteze rezolvarea unui set similar de
probleme
|
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
|
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 Method
|
O clasa abstractă
care conţine doar o parte din 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.
|
DPs de Concurenţă
|
Asynchronous
Processing
|
Asigură o coadă
de procese pentru executarea lor asincronă.
|
Balking
|
Dacă o metodă
este apelată în momentul în care obiectul nu o poate executa atunci se
asigură ca acea metodă nu execută nimic
|
Double
Buffering
|
Asigură
producerea de date asincrone astfel încât 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
Suspension
|
Asigură
execuţia unei metode până când este îndeplinită o condiţie
|
Lock Object
|
Asigură un
obiect unitar care să solicite acces unic la mai multe obiecte
|
Producer-Consumer
|
Coordonează
producţia şi consumarea asincronă de informaţii şi obiecte
|
Read/Write Lock
|
Asigură acces
concurent la citire şi acces exclusiv la scriere
|
Scheduler
|
Controlează
ordinea în care sunt executate metodele unui singur fir de execuţie
|
Single Threaded
Execution
|
Previne
apelurile concurente la o metodă să ducă la executarea concurentă a metodei
|
Two-Phase Termination
|
Asigură
ordonarea încheierii unui proces sau unui fir de execuţie
|
Tabelul nr. 2 Clasificarea DPs în funcţie de etapa de
dezvoltare
Etapa
|
Design
Pattern
|
Descriere
|
DPs cu Responsabilită
ţi Generale
|
Controller
|
Adaugă un
eveniment care să decupleze clasa sursa a unui eveniment de clasa sursă care
il rezolvă.
|
Creator
|
Determină care
clasă crează o instanţă a unei alte clase
|
Expert
|
Adaugă
responsabilitate unei clase care deţine informaţia necesară pentru realizarea
responsabilităţii
|
Law of Demeter
|
Daca două clase
nu trebuie să ştie de prezenţa celeilalte atunci acestea nu trebuie să
interacţioneze direct
|
Low
Coupling/High Cohesion
|
Permite
modificarea unei clase astfel încât sa ducă la o modificare facilă a
designului
|
Polymorphism
|
Permite
folosirea de metode diferite în funcţie de typul obiectului
|
Pure
Fabrication
|
Permite crearea
unei clase care sa nu devină greu de modificat
|
DPs ai
Interfetei Grafice
cu Utilizatorul
|
Conversational
Text
|
Desigunul
trebuie să admită comenzi sub formă de text
|
Direct
Manipulation
|
Permite
utilizatorului să interacţioneze cu obeictele manipuland reprezentări ale
acestora oferită de interfaţă
|
Ephemeral
Feedback
|
Asigură
feedback utilizatorilor despre starea muncii lor fără a interveni în fluxul
natural de muncă
|
Explorable
Interface
|
Designul
interfeţelor trebuie să fie indulgent cu greşelile utilizatorului
|
Form
|
Permite
utilizatorului să adauge date structurate sub formă de informaţii discrete
|
Disabled
Irrelevant Things
|
Ascunde
elementele de interfaţă care nu sunt necesare într-un anumit context
|
Interaction
Style
|
Mapează
modalităţile de de interacţiune oferite de interfaţă utilizatorului cu
cerinţele aplicaţiei
|
Limited
Selection Size
|
Evită
prezentarea de valori pentru selectare la un anumit moment în afara unui
număr maxim
|
Selection
|
Permite
utilizatorului să selecteze comenzi sau valori din liste
|
Step-by-Step
Instructions
|
Conduce
utilizatorul informândul ce urmează să facă la pasul următor
|
Supplementary
Window
|
Afişează o
fereastră suplimentară pentru informaţii suplimentare despre o fereastră
părinte
|
Window per Task
|
Fiecare acţiune
completă trebuie săă aibă o fereastră unică
|
DPs de
Organizare a Codului
|
Accessor Method
Name
|
Foloseste nume
si definitii de funcţii care sunt uşor de citit
|
Anonymous
Adapter
|
Foloseşte
obiectele de tratare a evenimentelor ca adaptoare anonime
|
Checked vs.
Unchecked Exceptions
|
Toate
excepţiile interne vor fi unchecked iar cele externe vor fi checked
|
Conditional
Compilation
|
Controlează
dacă un compilator intorduce sau ignoră comenzi pentru debug
|
Composed Method
|
Reorganizarea
unor metode care sunt prea mari ]n metode mai mici
|
Convert
Exceptions
|
Excepţiile
netratate în layerul curent vor fi convertite si trimise la layerul superior
|
Define
Constants in Interfaces
|
Se definesc
constantele în interfeţele claselor
|
Extend Super
|
Impelmentarea
unei metode care modifică logica unei clase parinte
|
Intention
Revealing Method
|
Folosirea de nume
semnificative pentru acţiuni care nu sunt executate de funcţii cu denumiri
clare
|
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
Constant Name
|
Folosirea de
nume simbolice pentru constante
|
DPs de Optimizare
a Codului
|
Double Checked
Locking
|
Evită dublarea
eforturilor de iniţializare ale unei resurse de către două fire de execuţie
|
Hashed Adapter
Objects
|
Transmite un
apel de metodă către un obiect adaptor asociat cu un obiect arbitrar
|
Lazy
Initialization
|
Iniţializrea
unui obiect doar în momentul în care acesta este necesar
|
Lookup Table
|
Evită
recalcularea unor valori prin calcularea lor iniţială şi salvarea lor
ulterioară
|
Loop Unrolling
|
Măreşte numărul
de operaţii efecutate într-o singură iteraţie
|
DPs de
Robusteţe a Codului
|
Assertion
Testing
|
Verifică dacă o
metode este conformă cu apelurile clineţilor
|
Copy Mutable
Parameters
|
Copierea unui
obiect în cazul în care se doreşte nemodificarea stării acestuia prin
modificarea lui.
|
Guaranteed
Cleanup
|
Asigură
terminarea unui obiect în cazul în care acesta nu execută corect terminarea
lui
|
Maximize
Privacy
|
Membrii
claselor trebuie să fie cât mai privaţi posibil
|
Return New
Objects from Accessor
|
Un obiect
returnat trebuie să fie copiat şi nu transmis prin valoare
|
DPs de
Testare
|
Acceptance
Testing
|
Testarea făcută
pentru a vedea dacă software livrat respectă nevoile organizaţiei pentru care
a fsot realizat
|
Black Box
Testing
|
Definirea de
teste numai pe baza cerinţele
|
Clean Room
Testing
|
Cei care au
proiectat sistemul nu trebuie să discute specificaţiile cu cei care
realizează testele
|
Integration
Testing
|
Testarea
împreuna, pentru prima dată, a
claselor dezvoltate separat
|
Regression
Testing
|
Retestarea unor
module pentru a observa dacă modificările au introdus noi buguri
|
System Testing
|
Tetstarea unui
sistem ca o entitate, într-un mediu similar cu cel în care va lucra
|
Unit Testing
|
Testarea
claselor individuale isolat de celelalte clase din program
|
White Box
Testing
|
Definirea de
teste pentru toate situaţile semnificative
|
Tabelul nr. 3 Clasificarea DPs în funcţie de domeniul de
aplicabilitate
Clasa
|
Design
Pattern
|
|
DPs de
Transacţii
|
ACID
Transaction
|
Asigură ca
rezultatul unei tranzacţii nu este inconsistent.
|
Audit Trail
|
Menţine un set
de înregistrări ale tranzacţiilor efectuate asupra unui obiect sau unui set
de obiecte
|
Composite
Transaction
|
Definirea de
tranzacţii complexe alcătuite din tranzactii ACID
|
Two Phase
Commit
|
Un obiect care
asigură că o tranzacţie complexe alcătuită din două tranzacţii ACID fie se
termină, fie eşuează
|
DPs de Arhitecturi
Distribuite
|
Demilitarized
Zone
|
Serverele
publice de Internet se vor lega la o reţea LAN care este conectată la
firewall şi la reţeaua Internet
|
Mobile Agent
|
Un obiect are
nevoie să acceseze volume mari de date aflate la distanţă
|
Object
Replication
|
Multiplicarea
unui obiect pe mai multe maşini astfel încât el să apară clienţilor ca fiind
unic
|
Object Request
Broker
|
O arhitectură
care permite obiectelor să facă apeluri la 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
Independent Objects
|
Păstrarea unor
obiecte redundante în cazul în care una dintre masini cade
|
Shared Object
|
Un obiect care
va efectua logica necesară partajării unui alt obiect
|
DPs de
Procesare Distribuită
|
Connection
Multiplexing
|
Un obiect care
gestionează conexiunile dintre mai multe alte oiecte
|
Heartbeat
|
Transmiterea de
mesaje periodice care să confirme clientului că serverul execută acţiuni în
numele clientului
|
Heavyweight/Lightweight
Object
|
Proiectarea de
clienţi care sunt cât mai mici
|
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-Subscribe
|
Transmiterea
fiecărui mesaj către destinatarul precizat
|
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
|
DPs de Concurenţă
|
Ephemeral Cache
Item
|
Folosirea unei
copii locale a unor obiecte de la surse de date aflate la distanţă
|
Deep
Transaction Nesting
|
Implementarea
posibilităţii de a restaura starea unui obiect modificat prin folosirea de
tranzacţii imbricate
|
Lock File
|
Folosirea unui
fişier de blocare care să gestioneze accesul exclusiv la resurse partajate
|
Optimistic
Concurrency
|
Folosirea de
copii ale obiectelor pentru executarea de tranzacţii
|
Session Object
|
Folosirea unui
singur obiect pentru informaţiile despre o sesiune de pe server
|
Static Locking
Order
|
Asigură
preluarea blocării obiectelor în aceeaşi ordine pentru toate obiectele
|
Thread Pool
|
Refolosirea
unui fir de execuţie aflat într-un pool dacă recrearea unuia nou durează mai
mult
|
DPs de
Timp
|
Temporal
Property
|
Menţinerea unui
istoric al valorilor unor atribute care se 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
|
DPs de
Baze de date
|
CRUD
|
Organizarea
operaţiilor pe baza de date în operaţii de Creare, Selectare, Modificare,
Ştergere (Create, Retrieve, Update and Delete)
|
isDirty
|
Evitarea
modificării unor date din baza de date care nu 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
1.
[GoF95] E. GAMMA, R. Helm, R. Johnson, and J. Vlissides, “Design Patterns: Elements of Reusable Object-Oriented
Software”. Reading, MA: Addison-Wesley, 1995.
2. [ECKE03] B.
ECKEL, “Thinking in Patterns”, Revision 0.9, 20-05-2003, MindView, Inc.
3. [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
4. [SHAL01]
A. SHALLOWAY, J.R. Trott – “Design Patterns Explained – A New perspective On
Object Oriented Design” , 2001
5. [ALEX79]
ALEXANDER, C., Ishikawa, S., Silverstein, M., “The
Timeless Way of Building”, New York: Oxford University Press, 1979.
6. [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
7.
[WILL00]
WILLIAMS J D, “Raising Components”, Application Development
Trends, vol. 7, no.9, Sep 2000, pp.27--32.
8.
[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
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.
- 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.
- 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ă.
- 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.
Tabelul nr. 1 Clasificarea DPs în funcţie de scop
Scop
|
Design
Pattern
|
Descriere
|
DPs
Fundamentali
|
Abstract
Superclass
|
Asigură o
unitate conceptuală a unui set de clase
|
Delegation
|
O modalitate de
extindere si folosire a unei clase
|
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
Abstract Class
|
O clasă care
implementează o interfaţă şi extinde o clasa abstractă
|
Marker
Interface
|
O clasă care
implementează o interfaţă pentru a indica valoarea booleană a unui atribut al
unei alte clase
|
Proxy
|
O modalitate de
a accesa un obiect prin intermediul altuia
|
DPs
Creaţional
|
Abstract
Factory
|
O modalitate de
a crea un obiect care implementează un set de interfeţe similare.
|
Builder
|
O modalitate de
construire a unui obiect complex
|
Factory Method
|
Un obiect care
reprezintă date externe sau 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
|
DPs de Partiţionare
|
Composite
|
Permite crearea
recursivă de obiecte similiare într-o manieră similară unui arbore
|
Filter (Pipe)
|
Permite
obiectelor sa fie conectate dinamica pentru a realiza operaţii pe şiruri de
date
|
Read-Only
Interface
|
Asigură
modificarea unui obiect numai de către unii dintre clienţii lui
|
DPs
Structural
|
Adapter
|
Implementează o
interfaţa cunoscută clienţilor săi asigurând acces la o interfaţă necunoscută
clienţilor săi
|
Bridge
|
Impelementează
abstractizările şi implementările în clase separate permiţând combinarea lor
dinamică
|
Cache
Management
|
Permite
accesarea rapidă a unor obiecte care în alt fel ar dura mai mult
|
Decorator
|
Extinde
funcţionalităţile unui obiect într-un mod transparent clienţilor săi
|
Dynamic Linkage
|
Permite unui
program să încarce la cerere diferite 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 Proxy
|
Ascunde
inexistenţa unui obiect printr-un
altul care implementează aceeaşi interfaţă permiţând intarzierea
instanţierii celui din urmă
|
DPs
Comportamen-
tal
|
Chain of
Responsibility
|
Permite unui
obiect transmiterea unei comenzi fără să ştie ce obiect sau ce tip de obiecte
o vor recepţiona
|
Command
|
Incapsulează
comenzile în obiecte pentru o uşoară manipulare a lor
|
Little Language
/ Interpreter
|
Permite
definirea unui mic limbaj care sa faciliteze rezolvarea unui set similar de
probleme
|
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
|
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 Method
|
O clasa abstractă
care conţine doar o parte din 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.
|
DPs de Concurenţă
|
Asynchronous
Processing
|
Asigură o coadă
de procese pentru executarea lor asincronă.
|
Balking
|
Dacă o metodă
este apelată în momentul în care obiectul nu o poate executa atunci se
asigură ca acea metodă nu execută nimic
|
Double
Buffering
|
Asigură
producerea de date asincrone astfel încât 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
Suspension
|
Asigură
execuţia unei metode până când este îndeplinită o condiţie
|
Lock Object
|
Asigură un
obiect unitar care să solicite acces unic la mai multe obiecte
|
Producer-Consumer
|
Coordonează
producţia şi consumarea asincronă de informaţii şi obiecte
|
Read/Write Lock
|
Asigură acces
concurent la citire şi acces exclusiv la scriere
|
Scheduler
|
Controlează
ordinea în care sunt executate metodele unui singur fir de execuţie
|
Single Threaded
Execution
|
Previne
apelurile concurente la o metodă să ducă la executarea concurentă a metodei
|
Two-Phase Termination
|
Asigură
ordonarea încheierii unui proces sau unui fir de execuţie
|
Tabelul nr. 2 Clasificarea DPs în funcţie de etapa de
dezvoltare
Etapa
|
Design
Pattern
|
Descriere
|
DPs cu Responsabilită
ţi Generale
|
Controller
|
Adaugă un
eveniment care să decupleze clasa sursa a unui eveniment de clasa sursă care
il rezolvă.
|
Creator
|
Determină care
clasă crează o instanţă a unei alte clase
|
Expert
|
Adaugă
responsabilitate unei clase care deţine informaţia necesară pentru realizarea
responsabilităţii
|
Law of Demeter
|
Daca două clase
nu trebuie să ştie de prezenţa celeilalte atunci acestea nu trebuie să
interacţioneze direct
|
Low
Coupling/High Cohesion
|
Permite
modificarea unei clase astfel încât sa ducă la o modificare facilă a
designului
|
Polymorphism
|
Permite
folosirea de metode diferite în funcţie de typul obiectului
|
Pure
Fabrication
|
Permite crearea
unei clase care sa nu devină greu de modificat
|
DPs ai
Interfetei Grafice
cu Utilizatorul
|
Conversational
Text
|
Desigunul
trebuie să admită comenzi sub formă de text
|
Direct
Manipulation
|
Permite
utilizatorului să interacţioneze cu obeictele manipuland reprezentări ale
acestora oferită de interfaţă
|
Ephemeral
Feedback
|
Asigură
feedback utilizatorilor despre starea muncii lor fără a interveni în fluxul
natural de muncă
|
Explorable
Interface
|
Designul
interfeţelor trebuie să fie indulgent cu greşelile utilizatorului
|
Form
|
Permite
utilizatorului să adauge date structurate sub formă de informaţii discrete
|
Disabled
Irrelevant Things
|
Ascunde
elementele de interfaţă care nu sunt necesare într-un anumit context
|
Interaction
Style
|
Mapează
modalităţile de de interacţiune oferite de interfaţă utilizatorului cu
cerinţele aplicaţiei
|
Limited
Selection Size
|
Evită
prezentarea de valori pentru selectare la un anumit moment în afara unui
număr maxim
|
Selection
|
Permite
utilizatorului să selecteze comenzi sau valori din liste
|
Step-by-Step
Instructions
|
Conduce
utilizatorul informândul ce urmează să facă la pasul următor
|
Supplementary
Window
|
Afişează o
fereastră suplimentară pentru informaţii suplimentare despre o fereastră
părinte
|
Window per Task
|
Fiecare acţiune
completă trebuie săă aibă o fereastră unică
|
DPs de
Organizare a Codului
|
Accessor Method
Name
|
Foloseste nume
si definitii de funcţii care sunt uşor de citit
|
Anonymous
Adapter
|
Foloseşte
obiectele de tratare a evenimentelor ca adaptoare anonime
|
Checked vs.
Unchecked Exceptions
|
Toate
excepţiile interne vor fi unchecked iar cele externe vor fi checked
|
Conditional
Compilation
|
Controlează
dacă un compilator intorduce sau ignoră comenzi pentru debug
|
Composed Method
|
Reorganizarea
unor metode care sunt prea mari ]n metode mai mici
|
Convert
Exceptions
|
Excepţiile
netratate în layerul curent vor fi convertite si trimise la layerul superior
|
Define
Constants in Interfaces
|
Se definesc
constantele în interfeţele claselor
|
Extend Super
|
Impelmentarea
unei metode care modifică logica unei clase parinte
|
Intention
Revealing Method
|
Folosirea de nume
semnificative pentru acţiuni care nu sunt executate de funcţii cu denumiri
clare
|
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
Constant Name
|
Folosirea de
nume simbolice pentru constante
|
DPs de Optimizare
a Codului
|
Double Checked
Locking
|
Evită dublarea
eforturilor de iniţializare ale unei resurse de către două fire de execuţie
|
Hashed Adapter
Objects
|
Transmite un
apel de metodă către un obiect adaptor asociat cu un obiect arbitrar
|
Lazy
Initialization
|
Iniţializrea
unui obiect doar în momentul în care acesta este necesar
|
Lookup Table
|
Evită
recalcularea unor valori prin calcularea lor iniţială şi salvarea lor
ulterioară
|
Loop Unrolling
|
Măreşte numărul
de operaţii efecutate într-o singură iteraţie
|
DPs de
Robusteţe a Codului
|
Assertion
Testing
|
Verifică dacă o
metode este conformă cu apelurile clineţilor
|
Copy Mutable
Parameters
|
Copierea unui
obiect în cazul în care se doreşte nemodificarea stării acestuia prin
modificarea lui.
|
Guaranteed
Cleanup
|
Asigură
terminarea unui obiect în cazul în care acesta nu execută corect terminarea
lui
|
Maximize
Privacy
|
Membrii
claselor trebuie să fie cât mai privaţi posibil
|
Return New
Objects from Accessor
|
Un obiect
returnat trebuie să fie copiat şi nu transmis prin valoare
|
DPs de
Testare
|
Acceptance
Testing
|
Testarea făcută
pentru a vedea dacă software livrat respectă nevoile organizaţiei pentru care
a fsot realizat
|
Black Box
Testing
|
Definirea de
teste numai pe baza cerinţele
|
Clean Room
Testing
|
Cei care au
proiectat sistemul nu trebuie să discute specificaţiile cu cei care
realizează testele
|
Integration
Testing
|
Testarea
împreuna, pentru prima dată, a
claselor dezvoltate separat
|
Regression
Testing
|
Retestarea unor
module pentru a observa dacă modificările au introdus noi buguri
|
System Testing
|
Tetstarea unui
sistem ca o entitate, într-un mediu similar cu cel în care va lucra
|
Unit Testing
|
Testarea
claselor individuale isolat de celelalte clase din program
|
White Box
Testing
|
Definirea de
teste pentru toate situaţile semnificative
|
Tabelul nr. 3 Clasificarea DPs în funcţie de domeniul de
aplicabilitate
Clasa
|
Design
Pattern
|
|
DPs de
Transacţii
|
ACID
Transaction
|
Asigură ca
rezultatul unei tranzacţii nu este inconsistent.
|
Audit Trail
|
Menţine un set
de înregistrări ale tranzacţiilor efectuate asupra unui obiect sau unui set
de obiecte
|
Composite
Transaction
|
Definirea de
tranzacţii complexe alcătuite din tranzactii ACID
|
Two Phase
Commit
|
Un obiect care
asigură că o tranzacţie complexe alcătuită din două tranzacţii ACID fie se
termină, fie eşuează
|
DPs de Arhitecturi
Distribuite
|
Demilitarized
Zone
|
Serverele
publice de Internet se vor lega la o reţea LAN care este conectată la
firewall şi la reţeaua Internet
|
Mobile Agent
|
Un obiect are
nevoie să acceseze volume mari de date aflate la distanţă
|
Object
Replication
|
Multiplicarea
unui obiect pe mai multe maşini astfel încât el să apară clienţilor ca fiind
unic
|
Object Request
Broker
|
O arhitectură
care permite obiectelor să facă apeluri la 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
Independent Objects
|
Păstrarea unor
obiecte redundante în cazul în care una dintre masini cade
|
Shared Object
|
Un obiect care
va efectua logica necesară partajării unui alt obiect
|
DPs de
Procesare Distribuită
|
Connection
Multiplexing
|
Un obiect care
gestionează conexiunile dintre mai multe alte oiecte
|
Heartbeat
|
Transmiterea de
mesaje periodice care să confirme clientului că serverul execută acţiuni în
numele clientului
|
Heavyweight/Lightweight
Object
|
Proiectarea de
clienţi care sunt cât mai mici
|
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-Subscribe
|
Transmiterea
fiecărui mesaj către destinatarul precizat
|
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
|
DPs de Concurenţă
|
Ephemeral Cache
Item
|
Folosirea unei
copii locale a unor obiecte de la surse de date aflate la distanţă
|
Deep
Transaction Nesting
|
Implementarea
posibilităţii de a restaura starea unui obiect modificat prin folosirea de
tranzacţii imbricate
|
Lock File
|
Folosirea unui
fişier de blocare care să gestioneze accesul exclusiv la resurse partajate
|
Optimistic
Concurrency
|
Folosirea de
copii ale obiectelor pentru executarea de tranzacţii
|
Session Object
|
Folosirea unui
singur obiect pentru informaţiile despre o sesiune de pe server
|
Static Locking
Order
|
Asigură
preluarea blocării obiectelor în aceeaşi ordine pentru toate obiectele
|
Thread Pool
|
Refolosirea
unui fir de execuţie aflat într-un pool dacă recrearea unuia nou durează mai
mult
|
DPs de
Timp
|
Temporal
Property
|
Menţinerea unui
istoric al valorilor unor atribute care se 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
|
DPs de
Baze de date
|
CRUD
|
Organizarea
operaţiilor pe baza de date în operaţii de Creare, Selectare, Modificare,
Ştergere (Create, Retrieve, Update and Delete)
|
isDirty
|
Evitarea
modificării unor date din baza de date care nu 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
1.
[GoF95] E. GAMMA, R. Helm, R. Johnson, and J. Vlissides, “Design Patterns: Elements of Reusable Object-Oriented
Software”. Reading, MA: Addison-Wesley, 1995.
2. [ECKE03] B.
ECKEL, “Thinking in Patterns”, Revision 0.9, 20-05-2003, MindView, Inc.
3. [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
4. [SHAL01]
A. SHALLOWAY, J.R. Trott – “Design Patterns Explained – A New perspective On
Object Oriented Design” , 2001
5. [ALEX79]
ALEXANDER, C., Ishikawa, S., Silverstein, M., “The
Timeless Way of Building”, New York: Oxford University Press, 1979.
6. [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
7.
[WILL00]
WILLIAMS J D, “Raising Components”, Application Development
Trends, vol. 7, no.9, Sep 2000, pp.27--32.
8.
[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
************************
Materialul este referit prin:
Ion IVAN, Liviu MIJACHE - Design Patterns – cale de crestere a fiabilitatii software - Software 2003, ASE Publishing House, pp. 609-625, Bucuresti , 2003
