Principiile unui design de calitate

CURS 1

STRUCTURA CURSULUI
Descompunerea pe componente POO (Java) UML (Tool) Principii de Proiectare Orientat - Obiect (POO) abloane de proiectare software (DESIGN PATTERNS) Arhitecturi software Exemple
2

Bibliografie
James Cooper: The design patterns Java companion; Bruce Eckel: Thinking in patterns; Curs Java: grafic i fire de execu ie, liste nl n uite i iteratori; UML 2 for dummies- Wiley; Robert Martin: Principii de proiectare orientat obiect; etc.
3

Cum s devii expert

Piese, Mut ri Criterii, Principii, Reguli Solu ii contextuale

Cum se joac ?

Ce nseamn de calitate?

Cum se aplic practic calitatea?

Etapele nv
nva Regulile!

rii

 Algoritmi, structuri de date i limbaje de programare;  Scrie ct mai multe programe;

nva

Principiile!

 Software design, diferite paradigme de programare;  Importan a coeziunii, cuplajului, ascunderii informa iei, controlul dependen elor;

nva

abloanele!

 Studiaz design-ul mae trilor;  n elege! Memoreaz ! Aplic !

5

CitnduCitndu-l pe Robert Martin

Dar pentru a deveni un maestru n software design, trebuie s studiezi design-ul folosit de al i mae tri. n profunzimea acelui design vei descoperi abloane ce pot fi folosite n alte designuri. Aceste abloane trebuie memorate, i aplicate pn doua natur . n elese, ce devin a
6

Unde ne afl m?
Am auzit de Principii
 1-2 limbaje OO (Java, C++)  Pu in experien n programare  Deschis-nchis, Principiul substitu iei Liskov etc.  Am aplicat ntmpl tor unele dintre ele;

tim Regulile

Dorim s devenim mae tri n design dar Credem c scrierea de software de calitate este magic (rezervat geniilor)
7

O hart
Ce nseamn design de calitate?
 Scopurile design-ului  Concepte cheie i principii  Criterii ale calit ii design-ului  Principii i reguli ale design-ului de calitate  Reguli, euristici, criterii

Ce nseamn calitate?

design orientat-obiect de

Cum se aplic design-ul de calitate?

 abloane de proiectare  abloane (stiluri) arhitecturale

Scopurile design-ului design Descompunerea sistemului n componente Descrierea func ionalit

 Formal sau informal  Identific arhitectura software-ului

ii fiec rei componente

Determinarea rela iilor dintre componente

 Identific dependen ele ntre componente  Determin mecanismele de comunicare component intra-

Specificarea interfe elor componentelor

 Interfe ele trebuie s fie bine definite (pentru a u ura testarea fiec rei componente i comunicarea n cadrul unei echipe)

Ce nseamn design de calitate?

Tenta ia design-ului corect Nu exist design corect! Programatorul decide! Un design de calitate echilibreaz compromisurile necesare pentru minimizarea costului total al sistemului pe ntreaga sa durat de via . Deasemena, evit negative. caracteristicile ce duc la consecin e Coad & Jourdon Necesitatea unor criterii de evaluare a design-ului Necesitatea unor principii i reguli pentru crearea de design-uri de calitate.
10

 O asigurare mpotriva design-ului catastrofic  Metode de design ce garanteaz corectitudinea

Elemente cheie ale designdesignului

Scop principalcontrolarea sistemului software prin Descompunere/ compunere
 De ce i cum?  Dar ce este o component ?  Principii de descompunere  Defini ie, avantaje  Criterii  Principii
11

complexit ii

 Optimizarea factorilor de calitate software  Facilitarea reutiliz rii sistematice

Modularizarea

Descompunerea
DE CE? Pentru a reduce complexitatea prin mp r irea problemelor mari n componente mai mici, dup principiul divide et impera.

1. Selecteaz o parte a problemei componentele acestei p r i 2. Determin folosind o paradigm de design (func ional , OO, etc.) 3. Descrie interac iunile ntre componente 4. Repet 1-3 pn la satisfacerea unui anumit criteriu de terminare
12

 Ini ial, ntreaga problem

O component este
o entitate SW ce nglobeaz reprezentarea unei abstrac iuni o metod de a ascunde cel pu in o decizie de design o sarcin de lucru (pentru un programator/ grup de programatori) o unitate de cod care:
 Are un nume  Are grani e identificabile  Poate fi (re-)folosit de alte componente  ncapsuleaz date  Ascunde detaliile ne-necesare  Poate fi compilat separat (eventual)

13

Interfa a unei componente

Interfa a unei componente cuprinde mai multe sec iuni: Importuri
Servicii solicitate altor componente

Exporturi
Servicii oferite altor componente

Controlul accesului
Ex. private/protected/public
14

Principiile Schmidt de descompunere

1. Nu crea i componente care s pa i de execu ie 2. Descompune i astfel nct s deciziilor de design corespund unor
 ntruct deciziile de design transcend timpul execu iei  [Parnas72]

limita i efectele prin toat utilizarea

3. Componentele trebuie specificate informa ia necesar pentru componentei respective

 i nimic n plus!

 Tot ce influen eaz sistemul va fi costisitor de modificat

15

Modularitatea
Un sistem este modular dac este structurat n abstrac iuni identificabile numite componente
Componentele trebuie s aib interfe e abstracte bine specificate Componentele trebuie s se caracterizeze prin coeziune ridicat i cuplaj slab
O metod de construire SW este modular dac ajut designerii s produc sisteme SW alc tuite din elemente autonome, conectate printr-o structur simpl i coerent .
16

B.Meyer

Avantajele modularit ii
Modularitatea faciliteaz fi: Extensibilitatea Reutilizabilitatea Portabilitatea factorii de calitate software, cum ar
 Interfe e abstracte, bine definite  Cuplaj slab, coeziune ridicat  Independen a de ma in

Modularitatea este important pentru un design de calitate deoarece: Spore te gradul de separa ie a preocup rilor (programatorilor ntr-un proiect) Reduce complexitatea sistemului prin arhitecturi sw descentralizate Spore te scalabilitatea ntruct suport o dezvoltare concurent i independent de c tre mai multe persoane

17

Criteriile Meyer de evaluare a modularit ii

Decompozabilitatea Compozabilitatea Claritatea
 Sunt componentele mari descompuse n componente mai mici?  Sunt componentele mai mari compuse din componente mai mici?  Sunt componentele, luate separat, inteligibile?  Modific ri mici ale specifica iei afecteaz limitat de componente, n mod limitat? un num r

Continuitatea Protec ia

 Efectele anomaliilor din timpul execu iei sunt limitate la un num r mic de componente rela ionate?
18

1. Decompozabilitatea
Descompune i problema n subprobleme mai mici ce pot fi rezolvate separat
Exemplu: design top-down Contra-exemplu: modul de ini ializare
 Ini ializeaz tot pentru toat lumea

19

2. Compozabilitatea
Modulele se pot combina liber pentru a produce noi sisteme
Componente- n medii diferite; Exemplu: bibliotecile de func ii matematice; Contra-exemplu: utilizarea de biblioteci non-POSIX

20

3. Claritatea
Modulele individuale sunt inteligibile unui cititor uman; Contra-exemplu: dependen ele secven iale (A|B|C).

21

4. Continuitatea
Modific ri mici n specifica ie rezult n:
Modific ri n pu ine module; Nu afecteaz arhitectura; Exemplu: constantele simbolice; Contra-exemplu: tablourile statice

22

5. Protec ia
Efectele unei condi ii anormale la execu ie sunt limitate doar la cteva module
Exemplu: validarea intr rilor la surs ; Contra-exemplu: excep ii haotice

23

Regulile modularit ii ale lui Meyer

Coresponden a direct Interfe e pu ine Interfe e mici
 O rela ie consistent ntre modelul problemei i structura solu iei  fiecare component trebuie s minim de alte componente comunice cu un num r ele trebuie s

Interfe e explicite

 Dac dou componente comunic , schimbe ct mai pu in informa ie

Ascunderea informa iei

 Cnd dou componente A i B comunic , aceasta trebuie s fie evident din textul lui A sau B sau din al ambelor

24

1. Coresponden a direct
P stra i structura solu iei compatibil cu structura domeniului problemei modelate Impact asupra: Continuit ii
 O coresponden

clar ntre cele dou

Decompozabilit ii

 Mai u or de con tientizat unei eventuale schimb ri

i limitat impactul

 Descompunerea domeniului problemei modelate este un bun punct de plecare pentru descompunerea sw
25

2. Interfe e pu ine
Fiecare modul trebuie s comunice cu un num r minim de alte module
Mai bine n-1 dect n(n-1)/2 Afecteaz ? Continuitatea, protec ia, compozabilitatea

claritatea,

26

3. Interfe e mici
Dac dou module comunic , ele trebuie s schimbe ct mai pu in informa ie
Continuitatea i protec ia

27

4. Interfe e explicite
Cnd dou module A i B comunic , aceasta trebuie s fie evident din textul lui A sau B sau din al ambelor
Decompozabilitatea i compozabilitatea Continuitatea, claritatea

Problema cuplajului indirect

Partajarea datelor
Modul A modific Data x Modul B acceseaz
28

5. Ascunderea informa iei

Motiva ie: deciziile de design ce pot fi subiectul unei schimb ri trebuie ascunse n spatele unor interfe e abstracte (i.e. componente) Componentele trebuie s comunice doar prin interfe e bine-definite Fiecare component s fie specificat de minimul de informa ie necesar Dac detaliile interne se modific , componentele client trebuie s fie minimal afectate Ascunderea informa iei este o metod spori/nt ri abstractizarea!
 Nici m car recompilarea s nu fie necesar  Vezi principiile de descompunere Schmidt

de a

29

Abstractizarea vs. Ascunderea informa iei

30

n continuare
Ce nseamn design orientat obiect de calitate? De la criterii i reguli la design OO; Principii ale design-ului OO (R. Martin) Euristici de design (A.J. Riel)

31