UNIVERSITATEA PETROL-GAZE DIN PLOIEŞTI

Specializarea INGINERIA ŞI INFORMATICA PROCESELOR

CHIMICE ȘI BIOCHIMICE
- Învăţământ cu frecvenţă –

SISTEME INFORMATICE INTEGRATE

Suport de curs

Ploiești 2020
 Unitatea de învățare 8. Faza de proiectare

6. 1. Introducere .................................................................................................................................. 3
6. 2. Procesul de proiectare ................................................................................................................ 4
6. 3. Arhitectura software ................................................................................................................... 4
6.3. 1. Tipuri de proiectare ............................................................................................................. 5
6.3. 2. Modelul arhitectural............................................................................................................ 6
6. 4. Proiectarea modulelor................................................................................................................. 6
6.3. 3. Modele de proiectare a modulelor ..................................................................................... 7
6.3. 4. Caracteristici ale modulelor................................................................................................. 8
6.3. 5. Principii de modularizare..................................................................................................... 9
6.3. 6. Reguli de proiectare a modulelor ...................................................................................... 10
6. 5. Documentul de proiectare arhitecturala (ADD) ........................................................................ 10
6. 6. Proiectarea de detaliu ............................................................................................................... 12

Durata: 4 ore

Cunoștințe și deprinderi
La finalul parcurgerii acestei unități de învățare veți înțelege:
- care sunt cele două niveluri ale procesului de proiectare;
- care sunt cele mai utilizate tehnici de proiectare;
- care sunt avantajele și dezavantajele modelelor de proiectare ale modulelor.
La finalul parcurgerii acestei unități de învățare veți putea să:
- explicați conținutul documentului de proiectare arhitecturală;
- descrieți caracteristicile de calitate ale modulelor;
- enumerați principiile de modularizare.

8 1. Introducere

Etapa de proiectare reprezintă al doilea pas în dezvoltarea unui produs software, etapă
ce răspunde la întrebarea CUM se va rezolva problema și implică atât proiectarea arhitecturală,
cât și proiectare detaliată a fiecărui modul în parte.
În 1981, Hoare făcea o observație interesantă legată de această etapă: Sunt două moduri
de a proiecta un produs software. Primul este de a-l face atât de simplu încât este evident că nu
există deficiențe. Al doilea este de a-l face atât de complicat încât nu există deficiențe evidente.
Prima metodă este mult mai dificilă.
Absența unei proiectări eficiente și coerente duce la scris de cod haotic, greu de înțeles
și de modificat. Cu cât te apuci mai repede să scrii cod, cu atât termini mai târziu. Deși, de
obicei, nu e niciodată timp să se proiecteze corect, întotdeauna e timp să se proiecteze de două
ori. Astfel codul proiectat corect este mai ușor de scris, de înțeles, de corectat, de extins [2].
 8 2. Procesul de proiectare

Procesul de proiectare (Figura 1) cuprinde diferite niveluri de abstractizare în descrierea

sistemului, permițând descoperirea erorilor cât mai devreme din etapa de proiectare. Ieșirea
fiecărei activități de proiectare este o specificație care poate fi abstractă, o specificare formală
care este produsă pentru a clarifica cerințele, sau poate fi o specificare a modului în care o parte
din sistem va fi realizată [4].

Figura 1 Procesul de proiectare [4]

Cele două niveluri ale proiectării sunt:

• Arhitectura sistemului, ce implică identificarea subsistemelor principale și a modului
în care comunică acestea. Are ca efect un impact major asupra performanțelor
sistemului;
• Module / componente, ce conține partiționarea subsistemelor (un modul poate însemna
un namespace, un pachet, o bibliotecă de funcții etc.).

8 3. Arhitectura software

Arhitectura unui sistem software este modul de organizare a tuturor elementelor

software ținând cont de caracteristici precum: suportabilitate (claritate, mentenabilitate,
scalabilitate), managementul interdependențelor, organizarea în module specifice (clase,
pachete, componente), comportamentul modulelor, tipare și principii arhitecturale [7]
Proiectarea arhitecturală reunește setul de decizii ce au ca scop asigurarea unei
arhitecturi eficiente și logice din spatele acestor decizii. Proiectarea este un proces creativ. Ca
ajutor în această etapă pot fi răspunsurile următoarelor întrebări [7]:
• Există o arhitectură generică ce poate fi utilizată?
• Ce stil arhitectural se potrivește?
• Ce concept pot fi aplicate pentru structurarea sistemului?
• Cum va fi sistemul descompus în module?
• Va fi distribuit sistemul? Dacă da, cum se va realiza distribuirea?
• Cum va fi evaluată proiectarea arhitecturală?
• Cum va fi documentată arhitectura propusă?
 Obiectivele proiectării arhitecturale constau în identificarea componentelor (unități
logice ale sistemului- baze de date, clase, procese, biblioteci, etc) sistemului și a conexiunilor
dintre ele (apeluri de funcții, mesaje ale sistemului de operare sau din rețea, evenimente etc).
Astfel, în etapa de proiectare se construiește soluția problemei iar rezultatul este descris
în Documentul de Proiectare Arhitecturala. Acest document trebuie să specifice rolul fiecărei
componente, cerințele care i-au fost alocate, interfața de comunicare cu celelalte componente
ale sistemului.
De asemenea, în etapa de proiectare arhitecturală se întocmește Planul Testelor de
Integrare. Acesta conține precizări legate de ordinea în care modulele identificate vor fi
integrate în subsisteme, iar apoi modalitatea de integrare a subsistemelor până la nivel de sistem.
De o importanță majoră o reprezintă specificarea testelor ce vor fi efectuate la integrare.

8. 3. 1. Tipuri de proiectare
Obținerea modelului de proiectare arhitecturală se poate realiza prin:
• Tehnica top-down, în care problema este recursiv împărțită în subprobleme, până când
sunt identificate toate subproblemele elementare;
• Tehnica bottom- up, în care se pornește de “jos”, de la proiectarea modulelor și se
continuă cu îmbinarea acestora până la proiectarea sistemului pe ansamblu;
• Tehnica hibridă, în care se pornește de la nivelului arhitectural și se urmărește
împărțirea sistemului în subsisteme care sa poată refolosi unele module deja existente.
Tehnica top – down
Proiectarea top- down presupune existența documentului cu specificațiile sistemului
creat în etapa anterioară. Astfel, setul cerințelor P se descompune în subseturi de cerințe P1, P2,
..., Pn, alocat fiecare unei subsistem al arhitecturii, PA1, PA2, ..., PAn.
Următorul pas constă în prelucrarea fiecărui set de cerințe Pi. Dacă Pi este suficient de
simplă, modulul PAi poate fi codificat direct în pseudocod, dacă nu, împărțim Pi, de exemplu, în
două alte module de specificații Si1 și Si2. Un exemplu este reprezentat în Figura 2.

Figura 2 Exemplu de descompunere aferentă proiectării top – down [8]

Această descompunere se realizează până când nivelul său de detaliu permite atât
continuarea dezvoltării în paralel de către mai mulți membrii ai echipei de dezvoltare cât și
planificarea activităților următoare ale procesului de dezvoltare (până la livrare) [1].
Tehnica bottom – up
 Este o tehnică centrată pe reutilizare în care se ține o evidență a componentelor deja
existente (module funcționale sau clase). Plecând de l acest set de module existente se caută o
descompunere a cerințelor în subseturi ce pot fi implementate folosind componentele deja
existente. Rezultatul este tot o structură modulară de tip arbore, numai că procesul începe de “jos”
până ce ajungem “sus” la P.

✎Exercițiul 1
Prezentați două dezavantaje ale utilizării tehnicii hibride.

8. 3. 2. Modelul arhitectural
Reprezintă o structură ierarhică realizată din subsisteme interconectate, ce conțin la
rândul lor module interconectate ș.a.m.d. Modelul poate fi reprezentat prin:
• Diagrame de structură, în cazul unei descompuneri funcționale: descompunerea
iterativa a funcțiilor pe care trebuie sa le implementeze sistemul;
• Diagrame de clase, în care relațiile ierarhice se bazează pe generalizare si
specializare;
• Diagrame de componente și diagrame de distribuție combinate cu diagrame de
componente.
Fiecare modul identificat în arhitectura software se descrie în Documentul de proiectare
arhitecturală prin următoarele informații:
• Identificatorul (unic) si tipul sau (clasa, funcție, fișier, program);
• Scopul său – cerințele software pe care le implementează;
• Componentele subordonate: modulele apelate/ obiectele utilizate/ fișierele unei
baze de date;
• Interfața componentei: fluxul datelor și al controlului;
• Dependențele sale: condiții care trebuie să fie satisfăcute înainte sau după
execuția sa, operații interzise în timpul execuției componentei;
• Prelucrarea interna a componentei, la nivelul cel mai coborât în limbaj natural;
• Structurile de date interne.

8 4. Proiectarea modulelor

Descompunerea în module ale unui sistem software se realizează după două modele
principale:
• Modelul obiectual – un sistem este compus din mai multe obiecte ce
interacționează între ele;
• Modelul funcțional (pipeline sau flux de date) – un sistem este descompus în
module funcționale.
 8. 3. 3. Modele de proiectare a modulelor
Modelul obiectual structurează sistemul într-un set de obiecte slab conectate dar cu
interfețe bine definite. În această abordare, pașii principali constau în identificarea și rafinarea
claselor, a atributelor și a operațiilor caracteristici. Printre avantajele modelului se numără:
• Modificarea unui obiect nu influențează celelalte obiecte deoarece cuplarea între
ele este slabă;
• Entitățile din lumea reală sunt modelate cât mai aproape de realitate;
• Limbajele orientate pe obiecte sunt larg utilizate
Dezavantaje:
• Probleme pot apărea odată cu schimbarea interfețelor obiectelor;
• Entitățile complexe pot fi greu de reprezentat ca obiecte.
În Figura 3 este reprezentată modelarea obiectuală a unui sistem de facturare. Se observă
existența claselor Client, Factură, Plată, Confirmare ce modelează entitățile implicate în acest
proces și mesajele ce reflectă interacțiunile dintre ele.

Figura 3 Model obiectual pentru procesat facturi [6]

✎Exercițiul 2
Prezentați alte două avantaje ale modelului obiectual.

Modelul funcțional procesează intrările în ieșiri conform unor transformări funcționale

și este asemănător cu modelul pipe din shell-ul UNIX. Este des întâlnit când transformările sunt
secvențiale. Printre avantajele acestui model se pot aminti:
• organizarea intuitivă;
• posibilitatea de a adăuga relativ ușor noi transformări;
• facilitatea de a fi implementat atât concurent cât și secvențial.
Limitele acestui model:
• Interacțiunea bazată pe evenimente este dificil de implementat;
• De-a lungul pipeline-ului este necesar un format comun pentru transferul datelor.
 În Figura 4 este reprezentat modelul funcțional pentru procesare facturi. Sunt
reprezentate acțiunile ce au loc în model, ordinea și modalitatea de interacțiune dintre ele.

Figura 4 Model funcțional pentru procesat facturi [6]

Conform [8], în modelul funcțional, pentru a realiza în mod sistematic proiectarea

modulară a programului se recomandă următoarea tehnică de descompunere, bazată pe o
analiză amănunțită a structurii problemei, a fluxului datelor și a transformărilor pe care acestea
le suferă:
• selectați o structură funcțională a problemei care să conțină câteva procese de prelucrare
principală (3-10);
• în această structură identificați fluxul principal de date de intrare și fluxul principal de
date de ieșire;
• localizați în structura problemei punctul în care fluxul datelor de intrare dispare și
punctul în care fluxul datelor de ieșire apare prima oară. Aceste două puncte disecă
problema în trei părți. Descrieți aceste trei părți prin trei funcțiuni și definiți o procedură
(modul) pentru fiecare în parte. Aceste trei proceduri sunt subordonate programului
principal;
• luați pe rând fiecare din aceste module, considerați funcția fiecăruia ca pe o “subfuncție”
și repetați procedeul;
• descompunerea continuă până când întreaga problemă se descompune în module de
aproximativ 50 de instrucțiuni.
După cum se poate observa, urmând pașii propuși mai sus se pot obține structuri diferite.
Alegerea modelului potrivit se poate realiza pe baza unei caracteristici numită independența
modulară.
8. 3. 4. Caracteristici ale modulelor
Un sistem software este caracterizat de independența modulară dacă fiecare modul este
cât mai robust, iar cuplajul între module este cât mai slab.
Robustețea unui modul este o măsură a relațiilor din interiorul modulului. Deosebim mai
multe forme de robustețe, care în ordine crescătoare, de la forma cea mai puțin robustă la cea mai
robustă, sunt [8]:
• robustețe întâmplătoare (normală) – modul în care există relații fără sens între
elementele sale;
• robustețe logică - modul care de fiecare dată când este apelat execută o funcție bine
precizată dintr-o mulțime de funcții logice legate între ele;
• robustețe clasică - modul care execută două sau mai multe funcții, funcțiile fiind legate
între ele ca proceduri (o procedură apelează o altă procedură);
 • robustețe funcțională - modul care execută o singură funcțiune.
Cuplajul dintre module este o măsură a relațiilor dintre module. Și aici deosebim mai multe
forme de cuplaj care, în ordine de la cel mai rău (cuplaj tare) la cel mai bun (cuplaj slab), sunt:
• cuplaj al conținutului – două module sunt cuplate în conținut dacă unul dintre ele se
referă în mod direct la conținutul celuilalt;
• cuplaj extern – un grup de module sunt cuplate în mod extern dacă în ele există referințe
la unele date globale, de exemplu blocuri organizate în comun;
• cuplaj decizional – două module sunt cuplate decizional dacă unul din ele controlează
în mod explicit funcțiile celuilalt;
• cuplaj prin date – două module sunt cuplate prin date dacă unul îl apelează pe celălalt și
toate intrările și ieșirile sunt sub formă de parametri ai procedurilor.
Dacă două module prezintă mai multe forme de cuplaj, cuplajul lor este definit de forma
cea mai rea de cuplaj.
Pentru a conferi independență modulară programului, programatorul trebuie să țină cont
și de următoarele:
• dimensiunea modulului conferă claritate și inteligibilitate programului; de dimensiunea
modulului depinde și ușurința testării;
• previzibilitatea modulului. Toate modulele trebuie să fie previzibile: la apeluri repetate
ale aceluiași modul să se obțină același rezultat când datele de intrare sunt identice. Cu
alte cuvinte modulul nu trebuie să aibă o memorie a execuțiilor anterioare;
• structura decizională. Organizarea funcțională trebuie alcătuită în așa fel încât modulele
ce sunt direct afectate de o decizie să fie subordonate modulului ce conține decizia;
• acces minim de date. Datele furnizate unui modul să fie limitate exact la minimul
necesar pentru a-și îndeplini funcțiunea.

✎Exercițiul 3
Prezentați alte aspecte de care un programator trebuie să țină cont în proiectarea modulelor.

Odată ce structura modulară a programului a fost stabilită urmează stabilirea logicii

fiecărui modul, codificarea și testarea.
8. 3. 5. Principii de modularizare
Modulele trebuie sa fie simple si cat mai independente unul de altul [4]:
• Modificarea unui modul are influență minimă asupra altor componente;
• O schimbare mica a cerințelor nu conduce la modificări majore ale arhitecturii software
(gruparea cerințelor corelate în același modul);
• Efectul unei condiții de eroare este izolat în modulul care a generat-o;
• Un modul poate fi înțeles ca o entitate de sine-stătătoare;
• Modulele trebuie sa “ascundă” modul de implementare a funcțiilor descrise de interfața
lor, de ex. cum sunt memorate datele cu care lucrează (tablou, lista, arbore, in memorie
sau într-un fișier).
 8. 3. 6. Reguli de proiectare a modulelor
• Minimizarea cuplării intre module:
o Minimizarea numărului de elemente prin care comunica modulele;
o Evitarea cuplării prin structuri de date;
o Evitarea cuplării prin variabile “steag” (cuplarea prin control);
o Evitarea cuplării prin date globale.
• Maximizarea coeziunii interne a fiecărei componente: elementele grupate într-o
componenta trebuie sa fie corelate, de ex. sa contribuie la aceeași prelucrare;
• Restrângerea numărului de module apelate (fan-out) de un anumit modul;
• Maximizarea numărului de module care utilizează un modul (fan-in) –
încurajează reutilizarea
“Fan-in” mare: un număr mare de module depind de el.
„Fan-out“ mare: modulul depinde de multe module.
• Factorizare: funcționalitățile comune sunt definite in module reutilizabile.

Figura 5 Exemplu de diagrama de structura [4]

8 5. Documentul de proiectare arhitecturala (ADD)

Rezultatele etapei de proiectare sunt centralizate în documentul de proiectare

arhitecturală ce conține descrierea arhitecturală cât și o prezentare cât mai detaliată a modulelor
identificate. În Tabelul 1 este descris șablonul acestui document în standardele ESA.
 Tabelul 1 Sablonul documentului in standardele ESA (versiunea engleza)

a. Abstract
b. Table of Contents
c. Document Status Sheet Status sheet for configuration control.
Document Change Records
d. A list of document changes.
since previous issue
1. Introduction
1.1 Purpose The purpose of this particular ADD and its intended readership.
Scope of the software. Identifies the product by name, explains
1.2 Scope
what the software will do.
1.3 List of definitions The definitions of all used terms, acronyms and abbreviations.
1.4 List of references All applicable documents.
1.5 Overview Short description of the rest of the ADD and how it is organized.
Short introduction to system context and design. Background of
2. System overview
the project.
3. System context (for each external interface ...)
3.n External interface definition The relationship with external system n.
4. System design
4.1 Design method Name and reference of the method used.
Overview of components: decomposition, dependency or
4.2 Decomposition description
interface view.
5. Component descriptions (for each component ...)
5.n Component identifier A unique identifier.
5.n.1 Type Task, procedure, package, program, file, ...
5.n.2 Purpose Software requirements implemented.
5.n.3 Function What the component does.
Child components (modules called, files composed of, classes
5.n.4 Subordinates
used).
Components to be executed before/after, excluded operations
5.n.5 Dependencies
during execution.
5.n.6 Interfaces Data and control flow in and out.
5.n.7 Resources Needed to perform the function.
5.n.8 References To other documents.
5.n.9 Processing Internal control and data flow.
5.n.10 Data Internal data.
6. Feasibility and resource A summary of computer resources needed to build, operate and
estimates maintain the software.
A table showing how each software requirement of the SRD is
7. Requirements traceability matrix
linked to components in the ADD.
 8 6. Proiectarea de detaliu

Proiectarea de detaliu se efectuează la nivelul modulelor definite în proiectarea

arhitecturală și poate avea loc in paralel, pentru diferite module.
Elemente conținute în detalierea modelului de proiectare arhitecturala:
• pot fi definite module de nivel mai coborât;
• se detaliază componenta claselor: atributele și funcțiile membre;
• se aleg biblioteci utilizate in implementare;
• se încurajează reutilizarea;
• sunt descriși algoritmii.
Bibliografia UI
1. Moldoveanu F., Ingineria programării- notițe de curs, UPB, Facultatea de Automatică și
Calculatoare, specializarea Calculatoare și Tehnologia Informației 2014,
http://andrei.clubcisco.ro/cursuri/anul-3/semestrul-2/ingineria-programelor.html, accesat 1
august 2017
2. Leon, F., Ingineria programării, notițe de curs, Facultatea de Automatica si
Calculatoare Iași, 2016, http://florinleon.byethost24.com/curs_ip.htm?i=1, accesat 1
iulie 2017
3. Iftene, A., Ingineria programării, notițe de curs Facultatea de Informatica, Iași, 2016,
https://profs.info.uaic.ro/~adiftene/studenti.html, accesat 12 iulie 2017
4. Ududec Novac, C., Ingineria sistemelor de programe, Editura Alma Mater, Bacău,
2011
5. Anderson,R., Software engineering- course, University of Cambridge, 2015,
https://www.cl.cam.ac.uk/teaching/1516/SWEng/, accesat 20 iulie 2017
6. Sommerville, I., Software Engineering, Pearson, 2015
7. Pescaru, D., Fundamente de inginerie software, notițe de curs, Universitatea
“Politehnica” din Timișoara, Facultatea Automatică și Calculatoare, specializarea
Calculatoare, 2010
8. Rotar, D., Ingineria programelor, Editura Alma Mater, Bacău, 2007