Ingineria programării – tema 3 Sergiu Voloc CR 3.

1B

Răspundeți sintetic la următoarele întrebări:

a) Enumerați trei motive importante pentru care ați crea un model pentru
un sistem existent. Este necesar ca un asemenea model de sistem să
fie deopotrivă corect și complet?

Dat fiind faptul că modelele joacă un rol important în ingineria cerințelor și a proiectării în sine,
acestea ajută atât dezvoltatorii sistemului cât și utilizatorii acestuia, 3 motive importante ce
demonstrează necesitatea modelelor ar fi:
 Faptul că acestea ajută la clarificarea a ce face un sistem în uz, existent.
 Modelul unui sistem existent este ca o bază de discuție a părților sale tari și slabe.
 Medelele elaborate pentru sistemele existente conduc la stabilirea cerințelor pentru un nou
sistem care poate deveni mai eficient datorită experienței modelelor anterioare.
Un model pentru sistemele existente nu este neapărat necesat să fie atât corect cât și complet
pentru că acesta servește drept o bază de cunoștințe pe care se bazează modul de lucru ap
sistemului cu date reale și condiții neprevăzute. Astfel se poate identifica și trata mai ușor micile
erori. Uneori este mult mai avantajoas din punct de vedere financiar și ar resurselor, crearea unui
sistem în modul acesta din motiv că crea unui sistem imperfect și îmbunătățirea acestuia la scurt
timp după distribuție (release 1.0) decât crearea unui model perfect din start.

b) Enumerați trei motive importante pentru care ați crea un model pentru
un nou sistem. Este necesar ca un asemenea model de sistem să fie
deopotrivă corect și complet?
Crearea unui model pentru un sistem nou este foarte importantă și avantajoasă, acest model
este creat:
 Pentru a facilita înţelegerea funcţionalităţii sistemului intenționat spre creare.
 Pentru a discuta propunerile de design și pentru a documenta sistemul în vederea
implementării.
 Pentru a comunica cerințele propuse altor stakeholderi.
Cu toate că crearea modelelor pentru sisteme noi este un proces complex, este necesar sau
măcar de dorit ca acestea să fie totalmente corecte și complete de la început, din cauza că astfel se
va obține o performanță maximă cu funcționalitățile necesare implementate și toate cerințele luate
în considerare.

c) În ce situații ați recomanda și în ce situații NU ați recomanda folosirea

unui model structural de sistem?

Folosirea unui model structural este foarte potrivit în situația în care este proiectat pentru o
bază de date deoarece evidenţiază entităţile sau fluxurile de date ce sugerează arhitectura
sistemului.
Este cunoscut faptul că aceste modele prezintă câteva dificultăți și anume : identificarea
claselor (cere o înţelegere profundă a domeniului de aplicaţie), modelarea de entităţi abstracte și
reutilizarea intre sisteme diferite, NU se recomandă utilizarea acestor modele în situații cu un număr
mare de clase, multe entități abstracte și sisteme care necesită o utilizare sporită cu alte sisteme
diferite.
d) Explicați utilitatea modelului arhitectural 4+1, dar și caracterul generic
al său, din punctul de vedere al fiecărei categorii de stakeholderi.

Modelul arhitectural 4+1 este folosit pentru descrierea arhitecturii a sistemelor software
intensive (SSI) care se bazează pe utilizarea multiplă și concurentă a perspectivelor. Perspectivele
sunt folosite pentru a descrie sistemul din diferite puncte de vedere ale stakeholder-ilor precum end-
users, dezvoltatori, inginer de sistem și manager de proiect.
Cele patru perspective ale modelului sunt : logic, dezvoltare, proces și fizic. În plus, anumite
scenarii sunt folosite în vederea ilustrării arhitecturii ce servește ca fiind perspectiva “+1”, de aceea
modelul arhitectural este numit și 4+1.
Modelul arhitectural 4+1 deține un caracter generic și nu este restricționat niciunei notații,
instrument sau metodă de proiectare. Această abordare este consistentă cu viziunea 4+1 a lui
Krutchen(1995) asupra arhitecturilor de sistem.
Din punct de vedere a categoriilor de stakeholderi putem analiza următoarele:
1. Perspectiva logică sprijină cerințele funcționale – ce anume ar trebui ca sistemul să furnizeze
cu privire la serviciile oferite utilizatorilor. Diagramele UML sunt folosite pentru a reprezenta
această perspectivă și includ diagramele de clase și de stare.
2. Perspectiva de proces se ocupă cu aspectele dinamice ale sistemului, explică procesele
sistemului și modul cum aceste comunică și se focusează pe comportamentul timpului de
rulare al sistemului. Diagramele UML includ diagramele de secvență, comunicare și activitate.
3. Perspectiva de dezvoltare ilustrează un sistem din punctul de vedere al unui programator și
se ocupă cu gestiunea software-ului. Utilizează diagrama de componente UML pentru a
descrie componentele sistemului. Diagramele UML folosite în reprezentarea perspectivei de
dezvoltare includ diagramele de pachete
4. Perspectiva fizică descrie sistemul din punctul de vedere al unui inginer de sistem și se
ocupă cu topologia componentelor software pe stratul fizic precum și conexiunile fizice între
aceste componente. Diagramele UML folosite în reprezentarea perspectivei fizice includ
diagramele de implementare.
5. Scenarii : descrierea arhitecturii este ilustrată utilizând un set micuț de scenarii care devin a
cincea perspectivă. Scenariile descriu secvențe de interacțiuni între obiecte și între procese.
Acestea sunt folosite pentru a identifica elementele arhitecturale, să exemplifice și să valideze
proiectarea arhitecturii. De asemenea, joacă un rol important ca fiind un punct de începere
pentru teste la un prototip de arhitectură.

e) Care sunt diferențele dintre modele de flux de date (dataflow) și cele

de tip mașină de stare (state machine)?
Data flow este un model de comunicații de date, în timp ce State machine este un model de
control, între componentele programului.
Modelul de flux de date(Dataflow) arată modul cum sunt procesate datele în diverse etape
de către sistem, pune accent pe datele de intrare și ieșire. Ignoră, în general, problemele legate de
sincronizare. Acest model ajută la descrierea relației dintre subsisteme ce aparțin unui sistem mai
mare.
Modelul de tip mașină de stare(State Machine) arată modul cum răspunde sistemul la
apariţia unor evenimente, descrie comportamentul sistemului, joacă un rol fundamental în a explica
comportamentul interfeței utilizatorului a unei piese dintr-un software, dar nu precizează cu nimic în
legătură cu aspectul ei. Acest model constă dintr-un set de stări, un set de tranziții între stări și un
set de acțiuni asociate cu aceste stări sau tranziții. Fiecare tranziție este o funcție ce determină
starea următoare din starea curentă și intrarea, iar fiecare acțiune este o funcție ce determină
ieșirea din starea curentă și/sau intrarea.
f) Care este diferența între explorarea eficientă a spațiului de proiectare și
validarea proceselor de proiectare?
Proiectarea devine, în contextul ingineriei software și al programării orientate pe obiecte, un
proces de rezolvare de probleme al cărui obiectiv constă în descoperirea și descrierea unor moduri
de implementare a cerințelor funcționale, implementare a constrângerilor impuse de cerințele non-
funcționale cu respectarea principiilor generale de calitate.
Proiectarea este, de cele mai multe ori, separată în două :
 Proiectare arhitecturala (de ansamblu)
 Proiectare de detaliu
Validarea proceselor de proiectare joacă un rol important în ingineria software, dar dat fiind
daptul că acest proces este posibil să se execute repetitiv, prin imbunătățirea continuă a proiectării
inițiale, acest proces nu este unul vital.

Spațiul de proiectare cuprinde opțiunile de proiectare pentru un posibil proiect software.

Fiecare decizie tehnică trebuie inregistrată, impreună cu rațiunea de proiectare pe care se bazează.
Inginerii software rezolvă probleme de proiectare. Pentru fiecare problemă de proiectare există mai
multe soluții alternative sau opțiuni de proiectare. Rezolvarea unei probleme implică decizii de
proiectare. Decizia de proiectare este un proces de alegere a celei mai bune opțiuni dintre mai
multe alternative. În luarea acestor decizii un inginer software trebuie să țină cont de :
 Cerințele software
 Partea de proiect construită până în acel moment
 Tehnologia disponibilă
 Principii și practici de proiectare
 Experiența proiectelor anterioare
Explorarea eficinetă a spațiului de proiectare este vitală din motiv că aceasta determină modul de
evoluție a sistemului intenționat spre proiectare.

g) De ce subsistemele/ modulele unui SSI trebuie să aibă un grad redus

de cuplare și un grad înalt de coeziune? Explicați acest lucru pentru
diferitele tipuri de coeziune între module/ subsisteme.

În general, un subsistem/modul are un grad ridicat de coeziune (consistență) atunci când

manifestă unitate și legătură internă puternică între elementele componente.
Cuplarea apare când există interdependențe între module. Un modul trebuie să aibă un grad redus
de cuplare, deoarece o rețea de interdependențe îngreunează înțelegerea componentelor
individuale. Pentru reducerea gradului de cuplare trebuie să se reducă numărul conexiunilor între
module și tăria conexiunilor.
Tipuri de coeziune :
Coeziune funcțională : modulul efectuează o sarcină de calcul specifică și returnează un
rezultat fără a produce efecte laterale. Un modul este lipsit de efecte laterale dacă nu modifică
starea de ansamblu a sistemului atunci când realizează o sarcină de calcul.Gradul înalt de coeziune
este recomandat din motiv că atunci sistemul este este ușor de înțeles, de reutilizat și de înlocuit.
Coeziune de nivel : toate serviciile sunt furnizate utilizatorului/nivelelor superioare sunt
grupate, iar orice altă funcționalitate este plasată în altă parte a sistemului. Nivelele alcătuiesc o
ierarhie. Nivelele superioare pot accesa serviciile nivelelor inferioare, dar nivelele inferioare nu
accesează nivelele superioare. Efectele laterale sunt permise, si chiar esențiale in unele aplicații
(de ex. într-un nivel de acces la baza de date)
Coeziune de comunicare : Toate elementele de procesare ce accesează anumite date sunt
păstrate împreună (de exemplu, în aceeași clasa). Orice altă funcționalitate este plasată în altă
parte a sistemului.
Coeziune de secvențiere : o serie de proceduri de calcul, ce își furnizează intrări și se
execută în secvență, sunt păstrate împreună și orice altă funcționalitate este plasată în altă parte a
sistemului
Coeziune procedurală : mai multe proceduri care se execută într-o anumită ordine sunt
păstrate împreună – din considerente de eficiență. Acest lucru se recomandă chiar dacă ele nu își
furnizează intrări una alteia
Coeziune temporală : operațiile efectuate în aceeași fază a execuției unui program sunt
păstrate împreună. Orice altă funcționalitate este plasată în altă parte a sistemului
Coeziune de utilitate : Utilitățile logic conectate sunt păstrate împreună. Aici, o utilitate este
o procedură sau o clasă care are aplicabilitate largă la mai multe subsisteme și este proiectată a fi
reutilizabilă.

h) Care sunt efectele menținerii unui grad înalt de abstractizare în fiecare

etapă de proiectare a unui SSI?

Menținerea unui nivel înalt de abstractizare permite inginerului software să ignore detaliile
irelevante și să se concentreze asupra fiecărei probleme la un anumit nivel de generalitate.
Proiectarea cu flexibilitate este anticiparea eventualelor modificări ale proiectului și pregătirea
pentru acestea. Moduri de realizare a unui proiect flexibil :
1. Crearea de entități abstracte
2. Reducerea gradului de cuplare și creșterea gradului de coeziune a modulelor
3. Păstrarea opțiunilor de proiectare
4. Construirea de cod reutilizabil și reutilizarea codului
De asemenea un efect de menținere a unui grad înalt de abstractizare în fiecare etapă de
proiectare conduce la un nivel înalt de abstractizare a sistemului prin ascunderea sau amânarea
tratării detaliilor. La fel, se păstrează un nivel de abstractizare cât mai înalt în vederea reducerii
complexității.

i) Folosind exemplul unei componente (clase) de tip stivă proiectate să

incorporeze reutilizabilitatea, pentru sistemul LIBSYS, indicați modul
în care e necesară adaptarea sau extinderea sa pentru reutilizabilitate.

Diferite aspecte ale unui sistem software trebuie proiectate astfel incat sa poata fi reutilizate
in diferite contexte, in cadrul sistemului curent sau in cadrul altor sisteme.
Reutilizabilitatea poate fi incorporata la nivel de:
 Procedura
 Clasa
 Cadru (Framework)
Câteva strategii pentru sporirea gradului de reutilizabilitate (construirea de componente
reutilizabile) pentru stiva din cadrul sistemului LIBSYS ar fi:
1. Construirea unui proiect cat mai simplu si general
2. Aplicarea precedentelor trei principii de proiectare:
3. Cresterea gradului de coeziune
4. Reducerea gradului de cuplare
5. Sporirea nivelului de abstractizare

j) Dați un exemplu complet de proiectare flexibilă a unui SSI.

Proiectarea cu flexibilitate (sau adaptabilitate) este anticiparea eventualelor modificari ale
proiectului si pregatirea pentru acestea.
Spre exemplu proiectarea unei platforme de evaluare a studenților în cadrul unei universități.
Pentru ca proectarea să fie flexibilă se pot lua următoarele măsuri:
 Reducânduse gradul de cuplare prin stabilirea de interdependențe cât mai simple între
studenți – profesori.
 Crescând gradul de coeziune a modulelor prin stabilirea sarcinilor de calcul simple și clare și
returnarea unui rezultat fără a produce efecte laterale, în alte module.(exemplu, un sutdent
să poată încărca/ comenta/ vizualiza decât datele atribuile lui, nu și altor studenți).
 De asemenea un mod bun de fexibilitate a proiectării ar fi să se creeze cât mai multe entități
abstracte pentru a permite utilizarea avantajelor acestora corespunzătoare.(exemplu: student
/ profesor / administrator / secretariat...)
 La fel un aspect important pentru facilitarea flexibilității este faptul de a nu limitata opțiunile
de proiectare pentru cei ce vor modifica ulterior sistemul. (exemplu: să existe posibilitatea
logării de către secretariat sau persoane speciale pe cont de administrator cu drepuri
depline).