7.

METODOLOGII SI INSTRUMENTE IN
REALIZAREA SISTEMELOR INFORMATIONALE

Obiective
1.Prezentarea cadrului metodologic de realizare a SI
2.Utilizarea metodologiilor traditionale :
- Analiza structurata
-Proiectarea structurata
-Programarea structurata
-Diagramele de flux
3.Metodologiile orientate obiect si metodologia unificata RUP
4.Instrumente si medii CASE
5.Mediu CASE integrat bazat pe UML
 În capitolul precedent s-a prezentat modul de realizare a unui S.I. prin
parcurgerea mai multor etape, care se constituie în ceea ce se numeşte ciclul de
viaţă al S.I. În ultima etapă a ciclului, odată cu operarea şi exploatarea S.I.
realizat, se face cu adevărat o evaluare a performanţelor şi eficienţei S.I., în aceste
condiţii rezultând şi cerinţele inevitabile pentru perfecţionări şi dezvoltări,
determinate de factori interni şi externi ai organizaţiei, dar mai ales de progresele
realizate în tehnologiile TIC, care au stat la baza realizării S.I.Din aceste motive,
rezulta necesitatea unei interventii continui asupra SI, folosind mijloace care sa
permita realizarea acestor dezvoltari cu maximum de eficienta si costuri cat mai
mici, oferite de un cadru metodologic si instrumente adecvate.

7.1. Definiţii privind cadrul metodologic

Metodologia poate fi definită ca o expresie a parcurgerii ciclului de viaţă al

S.I., cuprinzând:
-activităţile specifice fiecărei etape;
-procedurile şi regulile care se aplică în fiecare etapă;
-standardele asociate fiecărei activităţi;
-metodele, tehnicile şi instrumentele utilizate în realizarea diferitelor
activităţi şi etape.

Metodologia de realizare şi dezvoltare a S.I. reprezintă în sine o colecţie de

metode, una sau mai multe, pentru fiecare activitate desfăşurată în cadrul unei
etape a proiectului de realizare şi dezvoltare. Unele metodologii sunt asociate cu
tehnologii specifice, pe când altele reflectă diferite abordări conceptuale în
dezvoltarea sistemelor. Clasificarea metodologiilor realizate în timp se poate face
după mai multe criterii [LUNG 03]:
După gradul de generalitate:
Metodologii generale, utilizate la realizarea S.I. din diferite domenii, cum ar
fi: SSADM (Structured System Analysis and Design Methodology), MERISE
(Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise),
OMT (Object Modeling Technique), RUP (Rational Unified Process).

Metodologii cadru, care cuprind elemente asociate aplicării cu anumite

produse software, cum ar fi SIIPS (Selection and Implementation of Integrated
Packaged Software), pentru produsele SAP şi ORACLE.
Metodologii specializate, asociate cu utilizarea unui singur produs software, cum
ar fi AIM pentru ORACLE e Business Suite, ASAP pentru SAP.

După modul de abordare a realizării S.I.:

Metodologii cu abordare structurată, care au în vedere realizarea sistemului
pe baza funcţiilor realizate (abordare funcţională), sau pornind de la prelucrările pe
care le suferă datele (abordare bazată pe date). În această categorie există multe
metodologii, între care SSADM [GOOD 95] şi Metodologia ICI [ICCI 81].

Metodologii cu abordare orientată-obiect, care permit realizarea S.I.

folosind tehnologii orientate – obiect şi agenţi, între care OOD (Object Oriented
Design), OMT (Object Modeling Technique) etc. Pe ansamblul acestor
metodologii s-a ajuns la elaborarea unui standard cu privire la simboluri, notaţii,
tipuri de diagrame, de modele etc., numit UML, despre care s-a amintit în
capitolele precedente. Utilizarea practică a UML se face în RUP, ca proces general
pentru dezvoltarea orientată – obiect de produse informatice.

După modul de parcurgere a etapelor ciclului de viaţă:

Metodologii cu parcurgere a etapelor în cascadă, secvenţial, cu eventuale
reveniri la etapele învecinate.
 Metodologii cu parcurgerea etapelor în spirală care pleacă de la realizarea
rapidă a unei versiuni iniţiale ca prototip, de la care se defineşte şi realizează apoi
sistemul.
Metodologii cu realizarea S.I. pe subsisteme (funcţii), module, aplicaţii,
obţinându-se în final integrarea prin extensii succesive (incrementare).

7.2. Utilizarea metodologiilor tradiţionale

Metodologiile tradiţionale, faţă de clasificarea prezentată, sunt generale, cu
abordare structurată. Aceste metodologii au fost şi mai sunt utilizate pentru etapele
de analiză şi proiectare, cu elaborarea documentaţiei cerute de realizarea S.I. Ele
sunt bazate pe o abordare top-down, plecând de la nivelul cel mai înalt de
abstractizare şi progresând, pas-cu-pas, până la nivelul cel mai de jos, al detaliilor,
care intervin în definirea şi realizarea S.I. Aceste metodologii sunt orientate mai
mult pe procese şi funcţii, componenta referitoare la date accentuând mai mult
modul în care datele şi informaţiile sunt transformate şi mai puţin pe
date/informaţii în sine. Cu aceste metodologii se presupune realizarea liniară
(secvenţială) a diferitelor etape, fiecare etapă începând atunci când precedenta s-a
finalizat. În principal, aceste metodologii se bazează pe o analiză şi proiectare
structurate, incluzând programarea structurată, cu utilizarea diagramelor de flux
(flow charts).
Analiza structurată este larg utilizată în definirea sistemelor prin procese
asociate cu intrări şi ieşiri, oferind ca soluţie un model logic, grafic, ca flux de
informaţii între diferite module care definesc nivelurile ce pot fi controlate în
detaliu. În acest fel, obţinem o imagine a proceselor şi transformărilor care se
realizează în fiecare modul şi a interfeţelor între aceste module. Ca reprezentare se
folosesc diagramele de flux de date (Data Flow Diagram – DFD).
În lucrarea [LUNG 03] se prezintă numeroase exemple de utilizare a DFD în
analiza şi proiectarea S.I. De exemplu, diagrama de flux a documentelor în cadrul
satisfacerii unei comenzi de produs pentru un client, se prezintă în Figura 7.1.,
unde se prezintă entităţile (organizaţionale) care intervin: clientul, livrările,
aprovizionarea, furnizorii, transport-expediţie, financiar-contabilitate, depozit,
fabricaţie.
Financiar-
Client
contabilitate

Livrări
Marketing
Fabricaţie

Aprovizionare

Transport
Furnizori Depozit
Expediţie

Figura 7.1.: Diagrama de flux a documentelor în realizarea unei comenzi de produs

În această diagramă, entitatea client intră în relaţii cu alte trei entităţi, cu

generarea unor documente specifice:
cu livrări şi marketing prin: oferta de produse, comanda de produs (desfacere),
factura de desfacere;
cu financiar – contabilitate prin documentul de plată;
cu transport – expediţie prin avizul de însoţire al produsului comandat.
Fiecare entitate din această diagramă poate fi detaliată prin procesele, activităţile,
datele şi interfeţele care o definesc în raport cu celelalte entităţi. În acest fel se
ajunge la o analiză profundă a tuturor elementelor care stau la baza construcţiei S.I.
În analiza structurată, se constituie un instrument foarte util realizării S.I. denumit
dicţionar de date, un fişier manual sau automat (în cadrul unui SGBD), care
memorează definiţia elementelor datelor vehiculate în sistem, cu caracteristicile lor
privind utilizarea, reprezentarea fizică (pe suporţi), responsabilitatea actualizării,
autorizarea în utilizare şi securitatea privind accesul neautorizat etc. Dicţionarele
de date pot realiza liste sau rapoarte privind utilizarea datelor, localizarea şi
gruparea etc., constituindu-se ca un instrument important pentru management.
Specificaţiile proceselor/activităţilor descriu transformările la care sunt supuse
datele la nivelul primar al diagramelor de flux, reflectând în acest fel logica pentru
fiecare proces/activitate.
Proiectarea structurată cuprinde un set de reguli şi tehnici prin care se uşurează,
sistematizează şi simplifică efortul necesar de programare (codificare), punere la
punct a programelor şi întreţinerea lor. La baza proiectării structurate stă principiul
abordării top-down: considerarea mai întâi a funcţiilor de bază ale
programului/sistemului, iar după aceea se trece la descompunerea fiecărei funcţii
în subfuncţii şi mai departe, până la atingerea detaliilor de la nivelul cel mai de jos.
În acest fel, logica de nivel înalt şi modelul de proiectare sunt realizate înaintea
etapei de codificare, de programare în detaliu. Dacă faza de analiză structurată este
terminată, documentaţia cu specificaţiile din ultima etapă, constituie intrarea în
procesul de proiectare. Documentaţia părţii de proiectare structurată constă într-o
diagramă de structură (structure chart), realizată în conceptul top-down, în care,
pentru fiecare nivel se urmăresc conexiunile cu celelalte niveluri şi locul ei în
structura de ansamblu a aplicaţiei/sistemului.
În Figura 7.2 se prezintă diagrama de structură top-down pe trei niveluri a unei
aplicaţii cunoscute privind salariile într-o organizaţie. Dacă proiectarea aplicaţiei
are multe niveluri şi conexiuni, atunci se recurge la extinderea diagramei de
structură, până la cele mai mici detalii, ajungându-se astfel la o documentare clară,
uşor de înţeles, pentru un program, pentru o parte a lui sau pentru întregul sistem
(ca un set de programe).
 Procesul de calcul
al salariului

Culegerea datelor Tipărirea informaţiilor

Calculul salariului
şi validarea lor privind salariul

Tipărirea
Găsirea Calculul Calculul Actualizarea
Validarea informaţiei
datelor de salariului salariului fişierului
intrărilor pe diferiţi
intrare brut net de bază
suporţi

Figura 7.2.: Diagrama de structură pentru aplicaţia de salarii într-o organizatie

Programarea structurată extinde principiile proiectării structurate la realizarea

programelor, pentru a le face mai uşor de înţeles şi de modificat, mai ales când se
pune problema integrării lor în aplicaţii şi sisteme complexe, având la bază
principiul modularizării, care urmăreşte analiza şi proiectarea top-down. În acest
fel se ajunge la o structură de module, reprezentând fiecare un element al
diagramei de structură care rezultă la nivelul de detaliu (cel mai de jos) al
proiectării structurate.
Modulul dintr-o programare structurată constituie o unitate logică, prin care se
realizează una sau mai multe funcţii, care îşi pot partaja date. Ideal, modulele ar fi
de dorit să fie independente unul de altul, având fiecare numai o intrare şi o ieşire
în conexiunea cu fiecare din celelalte module. Pentru a îndeplini o asemenea
condiţie, orice program trebuie scris astfel încât sa posede în structura lui trei
„instrucţiuni – patern” (sau construcţii de control):

- paternul secvenţial, în care declaraţiile din program se execută succesiv, cu

trecerea controlului de la una la alta în mod necondiţionat (Figura 7.3);

- paternul de selecţie, în care se testează o condiţie şi se execută una din

două alternative, pe baza rezultatului obţinut la testare;
 - paternul de iteraţie, în care se repetă un segment de cod (din program),
atâta timp cât testul de condiţii rămâne „adevărat” (true) ca valoare logică.

Acţiunea Fals Adevărat

A (“0”logic) Condiţie (“1” logic)

Acţiunea
Acţiunea Acţiunea
E
D C

Acţiunea
B Condiţie
Adevărat
(“1” logic)
Fals
(“0”logic)

Paternul secvenţial, Paternul de selecţie prin testarea Paternul de iteraţie de repetarea

cu execuţia înlănţuită condiţiei pentru a trece la Acţiunea Acţiunii E dacă se îndeplineşte
a Acţiunilor A şi B C (pentru “1”) sau la Acţiunea D condiţia (este “1”)
(pentru“0”)

Figura 7.3. Ilustrarea paternurilor în structurarea unui sistem

Diagramele de flux, reprezintă o abordare veche, ca instrument de

proiectare grafică prin care se descrie mediul fizic şi etapele unui proces în cadrul
unui S.I. Prin aceste diagrame se descriu procesele care se desfăşoară într-un
program din aplicaţie/sistem, în succesiunea în care se execută. Chiar dacă nu se
mai foloseşte, acest sistem este utilizat pentru a face documentaţia specificaţiilor în
proiectarea fizică, mai ales a procedurilor manuale din S.I., deoarece se pot
evidenţia intrările, fişierele, prelucrările şi ieşirile, folosind simboluri speciale
(convenţionale) şi linii de flux (Figura 7.4).
 Pregătirea datelor
Preluare
Intrare/Ieşire Document
manuală

Conector în
pagină

Prelucrarea Bloc de decizii Memorie on-line

datelor (proces) (Disc magnetic) Legături de
Conector în comunicaţii la
afara paginii distanţă

Figura 7.4. Exemple de simboluri folosite în diagramele de flux

Diagramele de flux se pot realiza pe mai multe pagini folosind conectori

speciali (în afara paginii) pe lângă conectorii din pagină.
Chiar dacă metodologiile tradiţionale rămân valabile în realizarea S.I., ele
sunt totuşi rigide, inflexibile şi mari consumatoare de timp:
Analiza, proiectarea şi programarea nu se pot realiza decât succesiv, orice
modificare în specificaţii având tot o propagare secvenţială, începând cu
documentele de analiză.
Metodologiile structurate sunt orientate pe funcţie, concentrându-se asupra
proceselor de prelucrare a datelor, chiar dacă în prezent majoritatea aplicaţiilor
complexe şi S.I. sunt orientate pe date.
În acest fel s-a ajuns la alte opţiuni metodologice ale realizatorilor de S.I., către
orientarea obiect, instrumente CASE şi reingineria software.

7.3. Metodologie unificată, orientată obiect şi instrumente CASE

Tehnica modelării obiectelor (OMT) în realizarea S.I. prezentată în Cap. 4,

s-a extins la rangul de metodologie, diferind conceptual de cele tradiţionale prin
schimbarea accentului de la modelarea separată a proceselor şi datelor la
combinarea datelor şi procedurilor asociate de prelucrare în obiecte unificate.
Sistemul este văzut în acest fel ca o colecţie de clase şi obiecte, inclusiv relaţiile
dintre ele. Obiectele sunt definite, programate, documentate şi reţinute (saved) ca
blocuri constructive pentru aplicaţii (inclusiv cele care se vor realiza în
perspectivă, ca dezvoltare a celor actuale). Obiectele sunt reutilizabile, de aceea
noua orientare are un mare impact asupra timpului şi costului în fazele de
proiectare şi programare, în condiţiile în care există o bibliotecă de obiecte în
organizaţie, cu o situaţie a frecvenţei cu care sunt utilizate în diferite aplicaţii.
Metodologia orientată obiect utilizează pentru descrierea formală a
sistemului trei tipuri de modele:
- modelul structural al obiectelor, care descrie din punct de vedere statistic
obiectele, relaţiile dintre ele şi operaţiile fiecărei clase de obiecte;
- modelul dinamic al obiectelor, care pune în evidenţă starea lor în timp,
definită prin date şi fluxul evenimentelor care conduc la schimbarea stărilor;
- modelul funcţional prin care se descrie modul de realizare a ieşirilor din
sistem, pe baza intrărilor, a stării obiectelor şi a altor elemente care pot apărea ca
informaţii intermediare.
Metodologia unificată de realizare a S.I., denumită RUP (Rational Unified
Process) este un proces general pentru dezvoltarea, orientată obiect, a produselor
informatice, aşa cum s-a prezentat în Cap. 4. RUP se poate considera o
metodologie activă, vie, întreţinută de firma Rational Software, care oferă şi un
instrument CASE foarte cunoscut, de utilizare a ei, bazat pe UML, Rational
Rose.
Instrumentele CASE sunt asociate cu ingineria software (Software
Engineering), alteori cu ingineria sistemelor (System Engineering), în care este
folosit calculatorul (Computer- Aided), pentru automatizarea pas – cu – pas a
metodologiilor de realizare şi dezvoltare a software-ului şi sistemelor bazate pe
software. Prin aceste instrumente se asigură preluarea pe calculator a activităţilor
de rutină, repetitive, colaborării şi evaluării documentaţiei, permiţând specialiştilor
de concepţie şi celor care dau soluţii problemelor ridicate de realizarea S.I., să se
concentreze pe activităţi care nu pot fi preluate de calculator. Membrii echipelor
implicate în realizarea S.I. pot să acceseze şi să partajeze uşor rezultatele muncii
lor, ajungând la obţinerea unor soluţii fiabile, cu mai puţine intervenţii de corecţie
în timp. Utilizarea instrumentelor CASE conduce în acest fel la creşterea
productivităţii muncii şi a calităţii sistemelor prin:
asigurarea utilizării unor metodologii de realizare şi dezvoltare a S.I., cu
îmbunătăţirea disciplinei în proiectare;
asigurarea unei comunicări facile între utilizatori şi specialişti;
organizarea şi corelarea realizării componentelor, pe etape, cu asigurarea unui
acces facil la ele, prin realizarea unui „depozit” (repository) de proiectare;
automatizarea activităţilor plicticoase, de rutină, generatoare de erori în partea de
analiză şi proiectare;
automatizarea generării de cod, a testării şi controlului.
În aceste condiţii, instrumentele CASE sunt folosite în realizarea aplicaţiilor
şi sistemelor complexe prin tehnici de tipul RAD (Rapid Application
Development) sau JAD (Joint Application Design), sau prin aplicarea conceptului
de reinginerie. Reingineria implică parcurgerea a trei etape principale:
ingineria inversă (reverse engineering), prin care se extrag specificaţiile din
sistemul existent ;
revederea proiectării şi specificaţiilor pentru toate programele existente;
o nouă inginerie (forward engineering) prin aplicarea instrumentelor CASE.

Programele Specificaţii de
Detalii de Noua inginerie
sursă realizare
proiectare pentru sistem
(în exploatare) (fizice, logice)

Instrumente
CASE

Figura 7.5. Procesul de inginerie inversă în dezvoltarea unui S.I.

Procesul de reinginerie a unui sistem existent este prezentat în Figura 7.5. În

primul rând, din sursele aplicaţiilor în exploatare se deduc detaliile de proiectare şi
apoi specificaţiile care au stat la baza proiectării (logice şi fizice). Pe baza acestor
specificaţii, folosind instrumentele CASE se trece la realizarea noului sistem, care
va avea un nou cod, structurat, uşor de întreţinut şi exploatat, îndepărtând
deficienţele fostului sistem. Reingineria se impune pentru sistemele realizate în
mod tradiţional fie şi numai dacă vedem deosebirile în modul de realizare,
comparativ, aşa cum se arată în Tabelul 7.1.

Dezvoltarea tradiţională a S.I.
Se acordă atenţie codificării şi
testării
Specificaţiile se fac manual pe suport Se face o prototipizare rapidă
de hârtie
Codificarea se face manual
Documentaţia se face manual
Testarea programelor se face
continuu
Întreţinerea codului şi documentaţiei
Tabelul 7.1.
Dezvoltarea S.I. folosind
instrumente CASE
Se pune accent pe analiză şi
proiectare
Codul este generat automat
Documentaţia se generează automat
Testarea şi validarea se fac automat
Întreţinerea la nivelul specificaţiilor

Diversitatea instrumentelor CASE existente pe piaţă acoperă o multitudine

de cerinţe, impuse de modul în care se realizează sau dezvoltă aplicaţiile complexe
şi S.I. [LUNG 03]:
cele care acoperă parţial etapele ciclului de viaţă;
cele care acoperă o activitate din cadrul unei etape sau toate etapele;
cele care folosesc anumite tipuri de metodologii.
Ţinând seama de evoluţia dezvoltării instrumentelor CASE, evidenţiem pe
cele bazate pe metode orientate – obiect, care oferă o serie de beneficii legate de
flexibilitatea modelării sistemelor, de diversificarea posibilităţilor de reutilizare,
parţială sau integrală a unor proiecte dezvoltate anterior. În această categorie intră
mediile CASE, care acoperă cu instrumente toate etapele de realizare a S.I., prin
integrarea mai multor instrumente cu diferite destinaţii, aşa cum se prezintă în
Figura 7.6
Instrumente
• Generare automată a codului şi documentaţiei
• Validare şi verificare
• Inginerie inversă
• Managementul de proiect

Editoare pentru diagrame Depozitul Generatoare de rapoarte şi

de flux cetnral de date forme
şi informaţii

Utilizare
• Testare şi depanare
• Transformări /conversii

Figura 7.6 Componentele unui mediu CASE integrat

Depozitul central de date şi informaţii (repository) conţine: dicţionarul de

date, în care se stochează datele şi descrierea lor, cu resursele de prelucrare, şi
depozitul de informaţii, care stochează informaţii despre activităţi, procese şi
portofoliul de aplicaţii al întreprinderii / organizaţiei. În depozitul central se găsesc
acele module / funcţii care sunt comune mai multor aplicaţii, făcând posibilă
reutilizarea lor, în dezvoltarea sau realizarea unor aplicaţii noi.
Între mediile CASE integrate, cu un suport de produse-program deosebite
este cel al firmei ORACLE, denumit ORACLE Designer, utilizat în special de
analiştii de sistem. Acest instrument conţine produsele ORACLE Forms şi
ORACLE Reports şi utilizează o platformă client / server pe care se află un
depozit central (Repository) cu un set de tabele şi alte obiecte în spaţii distincte ale
bazei de date Oracle, cu o interfaţă API care permite utilizatorilor să acceseze
informaţiile din depozit, asigurând integritatea lor.
În ultimul timp se impune, cu perspectiva de extindere foarte rapidă pe piaţa,
mediul CASE integrat al firmei IBM, RATIONAL ROSE (RR) care se bazează pe
tehnologia RUP. Platforma de dezvoltare RR integrează cele mai bune practici în
ingineria software, o serie de instrumente şi servicii, cu o bază metodologică
tipizată / standardizată, agreată de cele mai reprezentative asociaţii profesionale în
domeniu. Facilităţile oferite acoperă toate etapele în ciclul de viaţă al unui sistem:
- Analiza şi definirea cerinţelor noului sistem, printr-un set de instrumente
integrate referitoare la managementul elaborării cerinţelor, elaborarea concepţiei de
dezvoltare, realizarea modelării pentru activităţi / procese şi date.
- Proiectarea şi construcţia, prin instrumente pentru arhitectura şi
proiectarea modelelor, dezvoltarea şi integrarea lor, testarea componentelor şi
analiza activităţilor de exploatare prin simulare.
- Testarea automată, prin instrumente care acoperă toate dimensiunile
calităţii în software: funcţionalitate, performanţă, siguranţă / fiabilitate.
- Managementul configurării software pentru sistem, prin soluţii de
raţionalizare / simplificare, în cazul unor schimbări şi controlul versiunilor,
urmărirea defectelor şi a modificărilor, utilizarea resurselor software.
- Managementul ciclului de viaţă (LCM), prin soluţii oferite echipelor în
compatibilizarea cerinţelor şi schimbărilor, prin modelarea şi testarea sistemelor,
prin asigurarea unei dezvoltări verificate a proceselor, cu evaluări şi rapoarte
privind derularea activităţilor.
Înţelegerea mai uşoară a mediilor CASE integrate orientate obiect, bazate pe UML,
se realizează prin cunoaşterea principiilor care stau la baza modelării orientată
obiect folosind acest limbaj.

7.4. Mediu CASE integrat ( IBM-RR ), bazat pe UML

Limbajul unificat de modelare (UML-Unified Modeling Language) este un limbaj

standard folosit la descrierea tehnică, inteligibilă, a documentaţiei unui S.I. bazat
pe T.I.C. UML permite vizualizarea, specificarea, realizarea/construirea şi
documentarea artifactelor unui S.I. bazat pe software şi T.I.C ( artifactul: un
ansamblu de informaţii care este produs, modificat şi utilizat de către proces ).
În general, un limbaj are un vocabular şi reguli de combinare a cuvintelor din acest
vocabular, cu scopul comunicării între oameni. Un limbaj de modelare dispune de
un vocabular şi reguli orientate pe reprezentarea conceptuală şi fizică a unui
sistem. În particular, UML este un limbaj standard de modelare pentru asigurarea
unei comunicări prin scheme detaliate (blueprints), reprezentând modelele unor
procese / activităţi, care se realizează sau au fost realizate. De aici rezultă rolul
central al modelării în realizarea unui S.I. Cum se poate defini un model în cazul
realizării S.I.: o descriere simplificată, formală a unei realităţi. Modelul este
realizat cu scopul înţelegerii mai aprofundate a unui sistem dat, cu scopul
dezvoltării lui. Prin modelare, urmărim patru obiective:
vizualizarea sistemului aşa cum este sau cum am dori să fie (prin dezvoltare);
specificarea structurii sistemului şi a mediului în care el există;
asigurarea unor paternuri / documente / prototipuri (templates), cu expresie
software (artifacte), necesare în construcţia sistemului;
documentarea deciziilor în realizarea sistemului asigurând managementul riscului
în finalizarea lui.
Activitatea de modelare trebuie să se bazeze pe câteva principii, valabile şi în
modelarea orientată-obiect din S.I.:
Alegerea modelului are o importanţă capitală asupra problemei de rezolvat şi
soluţiei propuse.
Fiecare model poate fi realizat cu diferite niveluri de precizie (aproximare)
Modelele cele mai bune sunt cele conectate la realitate.
Nu este suficient un singur model, ci un set de modele (mai mici sau mai mari),
aproape independente, în sensul că pot fi studiate separat, dar care sunt de fapt
corelate.
Modelarea prin software se poate realiza clasic, bazată pe algoritmizare sau
modern, bazată pe orientarea-obiect. În acest scop se foloseşte UML, în construcţia
S.I. pentru întreprinderi, chiar cu o distribuţie geografică mare (în conceptul de
întreprindere virtuală) a aplicaţiilor (bazate pe tehnologie web) şi cu facilităţi de
timp real, similar cu cele din sistemele integrate. UML asigură realizarea obiectelor
urmărite prin modelarea orientată-obiect prezentate mai sus:
UML este un limbaj grafic care permite vizualizarea şi realizarea de modele prin
care facilitează comunicarea.
UML este un limbaj de specificare, de construcţie a modelelor componente ale S.I.,
precis, neambiguu şi complet.
UML este un limbaj de construcţie, din modelele realizate în acest limbaj putând fi
generat cod în diferite limbaje de programare (C++, Visual Basic etc.). Este
posibilă şi situaţia reversă: reconstrucţia modelului din cod, însă cu intervenţie
umană. De asemenea, UML permite realizarea de simulări.
UML este un limbaj pentru realizarea documentării, prin faptul că, în afară de
codul executabil, poate realiza în plus o serie de artifacte necesare pe timpul
realizării S.I. dar şi după terminarea proiectului în activităţi de control, evaluare /
măsurare, comunicare, arhitectura, specificaţii, proiecte, teste, prototipuri şi cod
sursă, versiuni software etc.
Înţelegerea UML presupune prezentarea modelului conceptual pentru limbaj, care
se bazează pe trei elemente:
Elementele constructive de baza (building blocks)
Regulile de interconectare a blocurilor
Mecanisme comune specifice
În vocabularul UML sunt cuprinse trei elemente constructive de bază:
Lucruri (things, ca obiecte) care pot fi: structurale (statice), de ambient
(dinamice), de grupare (organizaţionale) şi de explicare / comentare.
Relaţiile (relationships) care pot fi: de dependenţă, de asociere, de
generalizare şi de realizare.
Diagramele (diagrams), ca reprezentări grafice pentru un set de elemente,
care se află într-un graf, teoretic ca o reprezentare a oricăror lucruri şi a relaţiilor
între ele.
O ilustrare a utilizării UML în modelare se poate realiza prin prezentarea
diagramelor, care, în practică, cuprind un număr mic de combinaţii comune care
sunt folosite în arhitectura S.I., aşa cum se arată în Figura 7.7. [MILL 05, KRUC
99]. Chiar daca în UML pot fi create şi alte diagrame, acestea sunt cele mai
folosite.

Diagrame Diagrame
de de
utilizare interactiune

Diagrame Diagrame
de de
activitate Diagramele clase
UML

Diagrame
Diagrame
de
compuse
dezvoltare

Diagrame Diagrame
de de
componente stari

Figura 7.7. Diagramele folosite în UML

Diagramele de activităţi, prin care se prezintă fluxul de la o activitate la

alta, subliniind şi fluxul de control între obiecte, exprimând o viziune dinamică
asupra sistemului. Un exemplu, pentru preluarea şi execuţia unei comenzi într-o
întreprindere, se arată în Figura 7.8.
Fabricaţie

Primeşte Execută Trimite Închide

factura comanda comanda comanda
Întreprindere

Contabilitate-
financiar

Trimite Acceptă
factura plata

Facturează
Client

Execută
plata

Figura 7.8. Diagrama de activităţi la execuţia unei comenzi

 Diagramele de utilizare, sunt create pentru o a vizualiza relaţiile între
diferiţi actori şi tranzacţiile realizate între aceştia în dialog cu sistemul (cazuri de
utilizare a sistemului/use cases). Un actor este o persoană sau un lucru, care
interacţionează cu sistemul, conform unor nevoi. De exemplu, un pasager, caută
un zbor, face rezervare, plăteşte zborul, iar banca primeşte plata de la cel autorizat
să plătească. În Figura 7.9 se arată diagramele de utilizare ale celor doi actori
(pasager, bancă) în raport cu sistemul de rezervare.

Figura 7.9 Diagrame de utilizare pentru rezervarea biletului de avion

Diagramele de interacţiune, arată mediul de comunicare între

componentele/părţile sistemului şi se referă la o vedere asupra dinamicii
sistemului, cuprinzând de fap patru tipuri de diagrame:
- cele de secvenţă, ilustrează secvenţa comunicării între părţi (succesiunea
în timp a mesajelor);
- cele de comunicare, arată structura şi căile de comunicare între părţi;
- cele de timp, arată modificarea stărilor de timp;
- cele de ansamblu, ilustrează fluxul de control între diferite interacţiuni.
În Figura 7.10 se prezintă diagrama de secvenţă pentru rezervarea unui zbor,
comandat de un client.
Figura 7.10. Diagrame de secvenţă în cadrul diagramelor de interacţiune

Diagramele de clase, prezintă structura statică a sistemului, reprezentând un

set de clase, cu interfeţe şi relaţiile dintre ele. Diagramele de acest tip sunt
destinate să genereze cod. Clasele sunt colecţii de obiecte cu structură comună, cu
comportament comun, cu semantică şi relaţii comune. Clasele se reprezintă printr-
un dreptunghi compartimentat pe orizontală în trei zone, purtând un nume (ca
substantiv singular scris cu literă mare). Structura unei clase este reprezentată prin
atributele ei, care pot fi găsite prin analiza definiţiei acelei clase, a cerinţelor
problemei, a regulilor de desfăşurare a activităţilor într-un domeniu al cunoaşterii.
Operaţiile (prin comportamentul obiectelor din clase) şi relaţiile se pot identifica în
diagramele de interacţiune, împreună cu gradul de multiplicare (ca număr de
obiecte incluse într-o relaţie) şi direcţia de navigare (una sau mai multe, care pot
fi restricţionate). În diagramele de clase apar relaţiile de moştenire (inheritance),
ca relaţii între o superclasă şi subclasele componente. În Figura 7.11 se prezintă
diagrame de clase pentru un sistem de rezervare a zborurilor, cu o serie de
reprezentări pentru relaţii (de asociere, agregare, compoziţie, de dependenţă) şi
realizări (între specificaţie şi realizarea ei) şi interfeţe.
 Depozit de
e-mail (mailer )
Manager de
Interfaţă Pasager rezerv ări

Nume (…) 1
Asociere
Adresa (…)
1P Persoana

Pasager ca Rezervare
Realizare
persoană 1
Agregare
Nume Evidenţă (…)
Adresă Nomin.scaun (…) Compoziţie
Ştrerge scaun (…) Dependenţă

1 1
Pasager
Scaun Zbor
ca firmă
Rând Firma
Decontare
Poziţii Zborul
Actualizare dată

Figura 7.11. Diagrame de clase pentru un sistem de rezervare

Diagramele de stări arata istoria unei clase, cu evenimente care produc

tranzacţii între stări şi acţiunile care rezultă din schimbarea stărilor. Aceste
diagrame se referă la dinamica sistemului şi sunt realizate pentru obiecte cu o
comportare dinamică semnificativă, aşa cum se arată în Figura 7.12, pentru
executarea unei plăţi pe bază de carte de credit.

Figura 7.12. Diagrama de stare pentru execuţia unei plăţi

 Diagramele de componente arată organizarea şi dependenţele unui set de
componente care sunt, fiecare în parte, o unitate-modul, cu interfeţe bine definite,
care poate fi înlocuibilă în cadrul mediului în care se află. Aceste diagrame se
referă la o viziune statică a sistemului, în care o componentă corespunde la una sau
mai multe clase, interfeţe sau colaborări. În Figura 7.13 se arată trei componente
care aparţin unui sistem de rezervare. Componentele pot fi logice (procese,
activităţi etc.) sau fizice.

Figura 7.13. Diagrame de componente

Diagramele de dezvoltare se folosesc în modelarea aspectelor fizice din
sistemele orientate obiect, cum ar fi configuraţiile de prelucrare a datelor şi
componentele lor (topologia hardware pe care se implementează sistemul). Prin
aceste diagrame se vizualizează aspectele statice ale topologiei, ca expresie fizică
(servere, modemuri, rutere, reţele locale, internet etc.), cum se arată în Figura 7.14.

Figura 7.14. Diagrame de dezvoltare

 Diagramele compozite prezintă structura internă a claselor (sau
clasificatorilor) şi punctele de interacţiune cu alte părţi ale sistemului. Aceste
puncte sunt asociate cu porturi (ports), fiecare dedicat unui anumit scop,
prezentând interfaţa corespunzătoare acelui scop, asa cum se arata in Figura 7.15.

Figura 7.15. Diagrame compozite

Ca orice limbaj, UML are un număr de reguli care specifică un model bine format
(semantic consistent) în armonie cu celelalte modele. UML are reguli semantice
pentru: nume, scop, vizibilitate, integritate, execuţie. De asemenea, UML dispune
de o serie de paternuri arhitecturale, reprezentate de patru mecanisme comune
folosite consistent: specificaţii, ornamente, diviziuni comune, mecanisme de
extensibilitate.
Pentru a înţelege arhitectura unui sistem orientat obiect, modelat prin UML, prin
mediu CASE integrat, se impune prezentarea sistemului celor interesaţi din mai
multe puncte de vedere: utilizator final, analist, proiectant, manager de proiect.
Fiecare dintre aceştia îşi face propria agendă în raport cu sistemul, inclusiv fazele
ciclului de viaţă. Arhitectura sistemului este, din această cauză, un artifact care
poate fi utilizat pentru fiecare din cei interesaţi. Arhitectura S.I. poate fi descrisă
prin cinci viziuni corelate (Figura 7.16).
Figura 7.16. Reprezentarea modelului arhitectural pentru S.I.

Prin viziunea de utilizare (use case view), se cuprind cazurile care descriu mediul
comportamental al S.I. aşa cum îl percep utilizatorii, analiştii şi cei care îl
evaluează (testează). Prin utilizarea UML, această cerinţă se asigură prin
diagramele de utilizare, cele de interacţiune, de stare şi activităţi .
Viziunea proiectantului cuprinde clasele, interfeţele şi colaborările, care definesc
problema şi soluţiile ei. Viziunea asupra proceselor cuprinde firul conducător şi
procesele care definesc concurenţa şi mecanismele de sincronizare din sistem,
evidenţiind performanţa, scalabilitatea şi productivitatea lui (în UML, prin
diagramele de interacţiune, de stare, activităţi sau componente). Viziunea de
implementare şi de dezvoltare, prin UML, se regăseste, atât ca statică cât şi ca
dinamică, în reprezentări realizate cu diagramele prezentate în acest capitol.

**********************
Termeni si notiuni de baza
• Metodologie (de realizare a SI) :
- cadru ;
- specializata ;
- cu abordare structurata ;
- orientata obiect ;
- unificata.
• Diagrame de flux
• Dictionar de date
 • Patern (instructurarea unui program)
• Model stuctural
• Model dinamic
• Model functional
• Inginerie software
• Ingineria sistemelor
• Instrument CASE
• Mediu CASE
• Inginerie inversa (reverse engineering)
• Depozit central de date si informatii
• Limbaj unificat de modelare (UML)
• Diagrame UML

****************************
Intrebari si teme recapitulative
1.Definiti cadrul metodologic de realizare a SI.
2.Evaluati utilizarea metodologiilor traditionale in realizarea aplicatiilor
specifice SI.
3.Care sunt caracteristicile metodologiei unificate RUP ?
4.Ce sunt instrumentele CASE si cum se folosesc in dezvoltarea SI ?
5.Caracterizati UML si prezentati diagramele folosite in acest limbaj.

*****************************

Tema de casa
Analizati si prezentati caracteristicile de baza pentru un mediu CASE
integrat, bazat pe UML ( EX. IBM – RR ).

*****************************