Victor Beșliu

Pavel Chirev
Nina Sava
PROIECTARE SISTEME INFORMAȚIONALE
Suport de Curs
PARTEA I
TEMA 1
1.1 Noțiuni generale. 1.2 Principii de bază la proiectarea sistemelor informaţionale. 1.3
Clasificare Sisteme Informaționale conform destinației. 1.4 Abordări arhitecturale în
realizarea sistemelor informaționale.
Conținutul cursului
În acest curs se vor reflecta unele probleme legate de managementul proceselor
de proiectare a sistemelor informaționale, despre modul de alegere a variantei optime de
proiect şi modul de întocmire a unui proiect informațional.
Vor fi prezentate și studiate metodele și standardele de modelare și proiectare a
sistemelor informaționale.
Va fi descris modelul ciclului de viață a produselor informatice, etapele de
proiectare, fazele aferente acestora și procesele etapelor de proiectare, fără a se insista la
detalierea acestora, doar la nivelul necesar pentru formarea unui analist de sistem.
Vor fi prezentate unele instrumente de modelare și proiectare a sistemelor
informaționale.
Obiectivele cursului:
- familiarizarea studenților cu metodele de analiză și modelare a sistemelor
tehnico-economice complexe și metodele de proiectare a Sistemelor
Informaționale, bazate pe standarde naţionale şi internaționale
- însuşirea principiilor construirii modelelor funcționale și informaționale,
modalităților de analiză a rezultatelor obținute
- utilizarea mijloacelor instrumentale de asistare în proiectarea sistemelor
informaționale
- pregătirea inginerilor în domeniul TI și a analiștilor de sistem.

Baza științifică - analiza de sistem și modelarea

1.1 Noțiuni generale
1.1.1 Noțiune de Inginer și inginerie

Un inginer este o persoană cu o pregătire tehnică - teoretică și practică, obținută

într-un institut de învățământ superior în care se studiază ingineria (aplicarea
cunoștințelor științifice, matematice economice, sociale, practice asupra realității
materiale și/sau sociale în vederea proiectării, executării, intreținerii, modificării unor
structuri și/sau ansamble care să fie capabile să furnizeze/genereze rezultate, produse,
procese și/sau efecte predefinite și/sau conforme unor așteptări predictibile și/sau
controlabile.
Spre deosebire de oamenii de știință, care studiază natura și fenomenele naturale
pentru a stabili principii, axiome și teoreme, inginerii aplică principiile teoretice din
matematică, fizică, chimie şi alte ştiinţe fundamentale pentru a crea un produs concret, ca
de exemplu un rulment, o tastatură de calculator sau un sistem informaţional.
Inginerul este persoana care practică o activitate de inginerie. Cuvântul inginerie
provine de la “ingenious” avînd diverse forme de definire. În literatură ingineria se
defineşte: «…aplicaţii ale tehnicii şi matematicii în scopul şi utilitatea populaţiei»; sau
«…proiectarea şi fabricarea de produse complexe». În unele surse se dau o serie de
citate referitor la această noţiune dintre care prezentăm doar unul: «ingineria este arta
sau ştiinţa de a face lucruri utile» (Samuel C. Florman).
Ingineria acoperă un domeniu foarte larg de activitate: de la agricultură la
construcţii navale, de la microelectronică la transporturi. În fiecare zi o serie de aplicaţii
au un rol ingineresc. Nu se poate vorbi despre o entitate fizică sau artificială în care să
nu se înglobeze şi o activitate de inginerie. În tabelul ce urmează se prezintă funcţiile şi
conţinutul activităţilor de inginerie.

Tabelul 1. Funcţiile şi conţinutul activităţilor de inginerie

1.1.2 Conceptul de proiectare

Proiectarea reprezintă o etapa care, deşi este mai puţin spectaculoasă, transformă
o idee în realitate. Indiferent de domeniu, un concept rămâne doar la nivelul de diamant
în stare brută dacă nu intervine „bijutierul” - proiectantul – pentru a finisa şi şlefui cât
mai multe faţete, făcându-l nepreţuit.
Proiectarea pune la dispoziţie „manualul de utilizare” pentru orice fantezie în
domeniul tehnic.
Ce inseamnă să fii proiectant? Proiectantul trebuie perceput ca o persoana cu
mintea deschisă şi cu o capacitate deosebită de a înţelege lucruri, situaţii, procese,
posibilităţi. Numai o asemenea persoana poate să transpună în practică ceea ce uneori
pare ceva „science fiction”.
Ce aptitudini trebuie să ai pentru a deveni proiectant?
Proiectantul trebuie să studieze permanent, să fie perseverent, să fie răbdător, să
fie inventiv şi, nu în ultimul rând, să fie curajos şi cu personalitate pentru că doar astfel
poate găsi soluţii optime pentru orice problemă.

Figura 1.1. Etapele procesului creativ

Figura 1.2. Dimensiunile creativitǎţii

1.1.3 Noţiuni de bază ale sistemelor

Sistem, Sistem Informațional, Sistem Informatic, Sistem Cibernetic.

Conceptul de sistem apare în forma embrionară încă din filozofia antică greacă.
Afirmând că întregul este mai mult decât suma părţilor, Aristotel dă o primă definitțe
noțiunii de sistem, care se va dezvolta și va evolua pentru a ajunge la forma actuală de
abia la inceputul secolului XX.
Cel care pune bazele unei teorii închegate privind teoria sistemelor (considerat
fondatorul teoriei generale a sistemelor) este biologul german Ludwig von Bertalanffy
(1901-1972) care între anii 1928 şi 1950 publică o serie de lucrări reprezentând
începuturile teoriei generale a sistemelor și a sistemelor deschise. Astfel, el a dedus
principiile universale care sunt valide pentru sisteme în general. În acest sens L. von
Bertalanffy a reformulat mai întâi conceptul clasic al sistemului și l-a determinat drept o
categorie prin care se cunosc relațiile dintre obiecte şi fenomene.
Conceptul nou dat sistemului reprezintă un set de componente interdependente, o
entitate complexă în care spațiul-timp arată asemănările structurale.
Ludowig Van Bertalanffy este considerat părintele teoriei sistemelor, el defineşte
sistemul ca un ansamblu de elemente aflate în interacţiune.
În accepţiunea teoriei matematice a sistemelor, informaţia e considerată expresie
a ordinei şi organizării, ce este specifică fiecărui subsistem în parte.
Este demonstrat că formula informaţiei este identică cu formula entropiei
descoperită de L. Baltzmann, adică: H = -pklog2pk, unde pk este probabilitatea de realizare
a unui eveniment k din sistem sau subsistem.
O. Onicescu în 1979 arată că gradul de organizare a unui sistem poate fi măsurat cu
ajutorul energiei informaţionale, astfel: E = pj2(A) , unde pj este probabilitatea de
apariţie a evenimentului A.
- informaţia, copie a evoluţiei ştiinţifice şi tehnice contemporane, se poate
considera ca o noţiune foarte veche, înţelegerea acesteia depinde de semnificaţia
ce i se poate atribui: ca suport al cunoştinţelor umane, ca biţi şi alte unităţi de
măsură specifice informaticii.
Teoria sistemelor arată că sistemele au următoarele principii: coordonabilitate,
incompatibilitate, optimalitate şi incertitudine.
- coordonabilitatea ne arată ca reglarea centralizată a unui sistem complex, dacă
ea este posibilă, nu este avantajoasă, datorită proceselor ce trebuie să fie reglate,
a contradicţiilor şi a neliniarităţii lor
- incompatibilitatea, arată cu cât complexitatea sistemului este mai mare, cu atât
scade posibilitatea de a-l descrie în mod riguros
- optimalitatea, arată că dacă un subsistem al uni sistem complex nu este optimal
în relaţiile sale cu celelalte subsisteme, atunci nici sistemul complex nu mai este
optimal
- incertitudinea ne relevă că într-un sistem complex, starea unui subsistem şi
interacţiunea sa cu celelalte subsisteme poate fi simultan determinată numai până
la un anumit grad de acurateţe.
Teoria sistemelor recunoaşte că după mulţimea elementelor şi relaţiile cu mediul,
după factorul timp, după coeficientul de complexitate şi după natura relaţiilor dintre
mărimile de intrare şi cele de ieşire, sistemele pot să fie: finite sau infinite, închise sau
deschise, statice sau dinamice, simple sau complexe, determinate sau probabilistice,
liniare sau neliniare, etc., această clasificare a fost făcută de Grunberg în 1977. Fiecare
sistem poate fi un subsistem şi fiecare subsistem poate face parte din mai multe sisteme,
devine necesară o abordare mult mai largă, deci una interdisciplinară.

Sistem informaţional: concept şi structură Commented [CA1]: De aici ar trebui să începem

Conceptul de sistem informaţional şi structura sa este pe deplin justificat prin cel

puţin argumente ca:
- acest concept a fost definit în funcţie de specializarea autorilor şi de contextul determinat
de tipul lucrărilor elaborate
- traducerea nu chiar exactă, a unor concepte din literatura străină şi de introducerea de
neologisme în limba română ce nu corespund conţinutului ce-l reprezintă
- abordarea încă firavă a problematicii complexe referitoare la proiectarea şi realizarea
sistemelor informatice.
V. Marinescu şi I. Faur dau următoarea definiţie: “ sistemul informaţional este
un ansamblu organizat şi integrat de date şi informaţii, precum şi procedurile şi mijloacele
pentru colectarea, prelucrarea şi transmiterea acestora”.
Alquier şi Barthet definesc sistemul informaţional astfel: “ansamblu de
informaţii manipulate într-o firmă”.
Lemoigne defineşte sistemul informaţional astfel: “un sistem de cuplaj între
sistemul operant şi sistemul de pilotaj.”
Sistemul informaţional este un ansamblu organizat de resurse: materiale, de
personal, date, mijloace şi proceduri de culegere, memorare, procesare şi comunicare
a informaţiilor, precum şi circuitele informaţionale utilizate.
a) un sistem reprezintă un ansamblu de elemente (componente) interdependente
între care se stabileşte o interacţiune dinamică, pe baza unor reguli prestabilite,
cu scopul atingerii unui obiectiv . Conform teoriei sistemelor orice organism
economic ( Unitate Social Economică) este un sistem
b) unitate Social Economică – întreprindere, instituţie, societate comercială, unitate
administrativ teritorială
c) în orice Unitate Social Economic se disting 3 componente:
1) sistemul de conducere sau de decizie
2) sistemul informaţional
3) sistemul decizional
d) orice Unitate Social Economică interacţionează cu mediul exterior (alte
organizaţii externe) primind informaţii din exterior şi furnizând informaţii către lumea
exterioară.
 Figura 1.4. Interacţiunea Unității Social Economică cu mediul exterior

În cadrul unui organism social-economic complex, apar trei sisteme: sistemul de

conducere/decizional, sistemul condus/operaţional şi sistemul informaţional. În
continuare ne vom axa pe cel de-al treilea sistem, cel informaţional.

Poziția Sistemului Informațional într-o Unitate Social-Economică

Figura 1.5. Poziția Sistemului Informațional într-o Unitate Social-Economică

1.1.4 Sisteme informaționale și sisteme informatice

a) sistemul informaţional cuprinde ansamblul informaţiilor interne şi externe

utilizate în cadrul organizaţiei precum şi datele care au stat la baza obţinerii
lor, procedurilor şi tehnicilor de obţinere a informaţiilor, precum şi personalul
implicat în culegerea, transmiterea, stocarea şi prelucrarea datelor
b) sistemul informaţional are două componente:
1) componenţa pentru stocare datelor
2) componenţa pentru prelucrarea informaţiilor.
 Figura 1.6. Poziţia sistemului informatic în cadrul sistemului informaţional
Sistem informaţional – definiție
Dintre cele mai corecte moduri de definire a sistemului informaţional putem evidenţia:
„Sistemul informaţional poate fi definit ca - ansamblul datelor, informaţiilor,
fluxurilor şi circuitelor informaţionale, procedurilor şi mijloacelor de tratare a
informaţiilor menite să contribuie la stabilirea şi realizarea obiectivelor instituţiei, precum
şi personalul implicat în culegerea, transmiterea, stocarea şi prelucrarea datelor”.
Sistemul informaţional al unui organism (activitate) este - „ansamblul
informaţiilor, surselor de informaţii şi nivelurilor receptoare, canalelor de circulaţie,
procedurilor şi mijloacelor de tratare a informaţiilor precum şi personalul implicat în
culegerea, transmiterea, stocarea şi prelucrarea datelor din respectivul organism”.
Dacă avem în vedere şi resursele umane o definire mai completă ar fi aceea în care
sistemul informaţional este - un ansamblu organizatoric format din totalitatea
metodelor, procedeelor, mijloacelor şi specialiştilor care asigură culegerea,
prelucrarea, transmiterea şi acumularea informaţiilor cu privire la fluxurile de bunuri
materiale şi informaţionale ce au loc în cadrul Unității Social-economice.
În cadrul unui sistem informaţional, majoritatea activităţilor se pot desfăşura cu
ajutorul tehnicii de calcul. Se pot prelucra datele primare şi apoi rezultatul poate fi
transferat mai departe, către alt compartiment spre prelucrare. Transferul se poate face şi
el pe cale electronică prin intermediul unei reţele de calculatoare.
Ansamblul de elemente implicate în tot acest proces de prelucrare şi transmitere a
datelor pe cale electronică alcătuiesc un sistem informaţional.
Într-un sistem informaţional pot intra: calculatoare, sisteme de transmisie a
datelor, componente hardware şi software, datele prelucrate, personalul ce exploatează
tehnica de calcul, teoriile ce stau la baza algoritmilor de prelucrare, etc.
Raportul sistem informaţional-sistem informatic:
Sistemul informaţional include în cadrul său sistemul informatic, acesta din urmă
fiind o componentă esenţială a primului. Trebuie reţinut faptul că sistemul informaţional
nu trebuie confundat sau suprapus complet cu sistemul informatic.
În general, sistemul informatic se interpune între sistemul decizional şi cel operaţional.
Sistemul informatic este un ansamblu structurat de proceduri şi echipamente
electronice care permit prelucrarea automată a datelor şi obţinerea de informaţii.
Sistem informatic
 Noţiunea de Sistem Informatic este legată de informatizarea activităţii unei
Unităţi Social Economice, deci folosirea echipamentelor hardware şi a produselor
software pentru organizarea şi administrarea informaţiilor. Utilizarea calculatoarelor în
cadrul Sistemului Informatic (SI) al unei Unităţi Social Economice conduce la definirea
componentei Sistem Informatic Automatizat (SIA) – care cuprinde numai lucrările
realizate cu ajutorul calculatoarelor.

1.1.5 Funcţiile unui sistem informaţional

Funcţiile unui sistem informaţional sunt:

- să colecteze date din sistemele operaţional şi decizional precum şi informaţiile ce provin
din mediul extern
- să memoreze aceste date precum şi informaţii rezultate din prelucrarea lor
- să asigure accesul la memorie în vederea comunicării informaţiilor stocate
- să prelucreze informaţiile la cerea sistemului operaţional şi a sistemului de conducere.

Componente ierarhizate ale SI

Practica de realizare a sistemelor informaţionale şi informatice a dovedit

necesitatea structurării sistemului în elemente componente, ierarhizate după anumite
criterii.

Figura 1.7. Structura ierarhică a unui sistem informaţional corporative

- sistemul trebuie să urmărească realizarea obiectivelor generale ale organizaţiei,
fixate pe o perioadă mai lungă de timp, către îndeplinirea acestora fiind orientat
ansamblul funcţiunilor de organizaţie/unitate economică
- subsistemul corespunde unor obiective derivate din cele generale, de exemplu:
aprovizionarea cu materii prime şi materiale, cercetarea şi proiectarea produselor şi
tehnologiilor noi care ar conduce la creşterea rentabilităţii, etc.
- aplicaţia, ca o componentă a subsistemului, se dezvoltă la nivelul unor activităţi
şi compartimente din cadrul organizaţiei (de exemplu: programarea, lansarea şi
urmărirea producţiei, planificarea cheltuielilor de producţie).

1.2 Principii de bază la proiectarea sistemelor informaţionale

În majoritatea lucrărilor care se ocupă cu realizarea sistemelor informaţionale, se

recomandă respectarea unor principii de bază:
- sistemul este pentru beneficiar, ceea ce implică participarea permanentă a acestuia în
toate etapele de realizare a sistemului
- problema cheie este cea a oamenilor, nu a echipamentelor şi în special a analiştilor-
proiectanţi de sisteme, specialişti care au o influenţă hotărâtoare asupra modului de
realizare a sistemelor
- SI trebuie justificate cantitativ şi calitativ, analistul de sistem stabileşte cele mai
corecte criterii prin care se pot măsura performanţele şi eficienţa sistemului proiectat
- realizarea sistemului este un proces iterativ, ceea ce înseamnă că întâi trebuie stabilit
numai cadrul general, detalierea făcându-se treptat, în mai multe iteraţii
- procedurile manuale sunt la fel de importante ca programele, de corecta lor
proiectare depinzând până la durata de implementare şi modul de funcţionare al
sistemului.
- sistemul trebuie să aibă o bună documentaţie în toate fazele, fapt care ajută la
structurarea lucrărilor, exploatarea sistemului și la împărţirea sarcinilor.

1.2.1 Gradualitatea implicării participanților la realizarea unui SI

Gradul de participare al beneficiarului şi al specialistului informatician în cursul

etapelor de realizare a sistemului la diferite etape de proiectare

Figura 1.8. Reprezentarea grafică a gradului de implicare

Figura 1.9. Reprezentarea grafică a resurselor pe tape de realizare

1.2.2 Evolutia sistemelor informaţionale

Începuturile în anii 1950 odată cu apariția primelor mașini de calcul. La prima

etapă metoda principală de proiectare a Sistemelor Informaționale era metoda “de jos - în
sus” (bottom-up).
Următoarea etapă - conștientizarea, că există necesitatea în mijloace relativ
standardizate de automatizare a activității diferitor întreprinderi și organizații. De-a
lungul timpului au existat diverse tipuri de sisteme, odată cu trecerea timpului, crescând
şi numărul acestora. Categoriile de sisteme sunt diferite, în funcţie de domeniile în care
se aplică.1[10] În tabelul ce urmează, este prezentată schematic, evoluţia sistemelor
informaţionale:

Tabelul 1. Evoluţia sistemelor informaţionale

Perioada Rolul Tipuri de sisteme informationale
1950- Prelucrarea Sisteme de procesare a datelor
tranzacţiilor Aplicaţii ale contabilităţii generale
1960
1960- Informarea Sisteme de raportare pentru conducere
conducerii Sisteme de informare a conducerii
1970
1970- Sprijinirea Sisteme de sprijinire a deciziilor
procesului Support interactive ad-hoc în procesul decizional
1980
decizional
1980- Sprijiniea Aplicaşii orientate către utilizatorii finali
utilizatorilor finali Sisteme informaţionale ale conducerii executive
2000
şi a strategiei Sistem expert
Sisteme informaţionale strategice
2000- Sisteme Aplicaţii orientate spre procesarea descentalizată
Informaționale Sisteme informaţionale bazate pe cunoștințe
20prezent
bazate pe Rețele Sistem informaționale e-Administrare, e- Servicii
de Transport Date Sistem informaționale e-Comerţ
și tehnologii Web Rețele informationale de socializare

Dezvoltarea sistemelor informatice apare ca o evoluţie de la simplu la complex,

în care rolul acestora a crescut permanent de-a lungul anilor, prin extinderea continuă a
funcţiilor sale. La inceputul anilor ’50, tehnologia informaţională [11] se afla încă în
prima faza a dezvoltării sale. Dar cu timpul, aceasta s-a remarcat printr-o serie de sisteme
informaţionale, cele mai cunoscute şi utilizate fiind: sistemele de prelucrare a
tranzacţiilor, sistemele de informare a conducerii, sistemele de sprijinire a procesului
decizional şi sistemele informaţionale pentru conducerea superioară.

1[10] Luminiţa, Fanaru, Sisteme informaţional și gestiunea financiară a întreprinderii,

Ed. Junimea, p.35
1.2.3 Etape de proiectare

Procesul creării S.I. include crearea și transformarea succesivă a unui șir de

modele coordonate pe etapele ciclului de viață a sistemului.
Modelele sunt create de către grupurile de lucru din cadrul echipei proiectului,
sunt acumulate și păstrate în depozitul (repozitoriul) proiectului.
Procesul de creare a unui S. I. include o serie de etape (stadii), determinate în
timp și care au drept finalitate crearea unui produs concret – model, program,
documentație etc.
Crearea modelelor, verificarea și validarea lor, prezentarea pentru utilizare
colectivă are loc folosind instrumente program speciale – mijloace CASE (Computer
Aided Software Engineering).
Principalele etape:
- planificarea sistemului
- analiza obiectului
- formarea cerințelor față de sistem
- proiectarea sistemului
- implementarea/realizarea și testarea sistemului
- exploatarea și mentenanța sistemului.

Ultimile două etape sunt în afara prezentului curs.

Planificarea sistemului – Etapa de început la care se determină are sau nu Unitatea
Social Economică nevoie de un nou S. I.
Analiza obiectului – presupune:
- modelarea proceselor business, care au loc în organizație
- crearea Modelului organizației, descris în termeni de procese și funcții
business - permite formularea cerințelor principale
- mulțimea modelelor de descriere a cerințelor este transformată într-un
sistem de modele, care descriu proiectul conceptual al SI
Sunt formate modelele arhitecturale ale SI.
Sunt determinate cerințele referitoare la asigurarea program și informațională.
Urmează formarea arhitecturii resurselor program și resurselor informaționale,
determinarea bazelor de date și identificarea modulelor program, formarea modelului de
cerințe față de programe și crearea acestora, testarea și integrarea.
Scopul etapei de analiză a activității organizației, este determinarea cerințelor
funcționale ale sistemului.
Formarea și formularea cerințelor este una din sarcinile cele mai responsabile,
dificil de formalizat și extrem de complicate și costisitoare în cazul unor erori.
Rzultatul etapei: Caietul de Sarcini
Proiectarea sistemului - crearea modelului logic și modelului fizic al datelor - partea
principală la proiectarea BD. Proiectarea proceselor pentru obținerea specificațiilor
modulelor SI.
Scopul principal al etapei de proiectare a proceselor constă în transformarea
funcțiilor, identificate la etapa de analiză, în module ale Sistemului Informațional.
Rezultatele etapei de proiectare sunt:
- schema bazei de date
 - specificațiile modulelor sistemului
- elaborarea arhitecturii
Căutare răspunsuri la caracteristici ale arhitecturii:
- tipul arhitecturii
- numărul de nivele
- tipul BD - centralizată sau distribuită
- omogenitatea BD
- paralelism.

Rezultatul etapei: Proiectul Tehnic

Etapa de realizare (implementare) are loc crearea programelor, instalarea resurselor
tehnice, elaborarea documentației de exploatare.
Etapa de testare este distribuită în timp.
La finalizarea lucrărilor de creare a unui modul al sistemului are loc testarea
autonomă (sau de detaliu), care urmărește două scopuri principale:
- detectarea refuzurilor în funcționare a unui modul
- stabilirea nivelului de corespundere specificațiilor.
Urmează testarea fiabilității setului de module când:
- sunt imitate situațiile de refuz în funcționare;
- este determinat timpul mediu dintre două căderi succesive (MTBF- Mean Time
Between Failures).
Ultima testare o reprezintă testarea de acceptare.

Figura 1.10. Etape de creare a unui produs

1.3 Clasificarea Sistemelor Informaționale conform destinației

1.3.1 Aplicaţiile informatice funcţionale la nivelul unei unități social - economice

sunt grefate pe câteva categorii structurale, destul de bine definite, în literatura de
specialitate. Mai jos sunt prezentate principalele categorii de sisteme informaționale şi
adresabilitatea acestora.
Sisteme pentru prelucrarea tranzacţiilor (TPS - Transaction Processing Systems)
permit prelucrarea şi stocarea datelor privind tranzacţiile zilnice, caracterizate printr-un
grad ridicat de repetabilitate. TPS este dedicat nivelului operaţional al agentului.
Sisteme destinate activităţii de birotică (OAS – Office Automation System) se
adresează personalului antrenat în prelucrarea informaţiei (data workers), contabililor,
funcţionarilor, asistent-manager-ilor dar şi conducerii operaţionale.
Sisteme destinate cercetării–dezvoltării (KWS – Knowledge Work System)
reprezintă “izvorul” şi integrarea noilor tehnologii obţinute prin compartimentele de
cercetare dezvoltare.
Sisteme informatice destinate conducerii (MIS –Management Information
Systems) asigură activităţile de planificare, control şi decizie, pe termen scurt urmărind
obţinerea rapoartelor de rutină, periodice, sintetice, precum şi informaţiile care privesc
perioada anterioară şi curentă 1.9 am reprezentat larga sferă de interes a sistemelor
informatice destinate conducerii corelată cu beneficiarii specifici.

Figura 1.11. Clasificarea sistemelor informatice

Sistemele suport de decizie (DSS – Decision Support Systems) fructifică

informaţiile furnizate de TPS, MIS conectate cu influenţa mediului economic extern. DSS
utilizează modele de analiză complexă şi aprofundată asistând managerii în elaborarea
deciziilor.
Sistemele suport ale executivului (ESS-Executive Support Systems) sunt
destinate elaborării unor decizii nestructurate adresate managementului strategic.
Sistemele suport ale executivului utilizează cele mai avansate produse software grafice şi
pot oferi imediat managerului general sau consiliului de administraţie diagrame şi
informaţiile solicitate. Pot concluziona că interdependenţa evidentă a tipurilor de sisteme
informatice apare concretizată prin faptul că informaţiile (ieşirile) oferite de unele dintre
acestea sunt utilizate drept date de intrare de către celelalte tipuri de sisteme.

1.3.2 Clasificare Sisteme Informaționale conform tipului de date

Figura 1.12. Clasificare Sisteme Informaționale conform tipului de date

1.3.3 Clasificare Sisteme Informaționale la nivelul organizaţiei

Un alt criteriu de clasificare al sistemelor informatice este în funcţie de nivelul

ierarhic
ocupat de sistemul economic în structura organizatorică a organizaţiei:
- sisteme informatice pentru conducerea activităţii la nivelul organizaţiilor
economice. Acestea pot fi descompuse în subsisteme informatice asociate funcţiunilor
organizaţiilor economico-sociale sau chiar unor activităţi
- sisteme informatice pentru conducerea activităţii la nivelul organizaţiilor
economico-sociale cu structură de grup. Sunt incluse sistemele informatice la nivelul
regiilor autonome .
- sisteme informatice teritoriale. Sunt constituite la nivelul unităţilor administrativ-
teritoriale şi servesc la fundamentarea deciziilor adoptate de către organele de conducere
- sisteme informatice pentru conducerea ramurilor, subramurilor şi activităţilor la
nivelul economiei naţionale. Se constituie la nivelul ramurilor, subramurilor şi
activităţilor individualizate în virtutea diviziunii sociale a muncii şi specificate în
clasificarea ramurilor economiei naţionale.

1.3.4 Clasificarea sistemelor informatice după scopul urmărit:

- automatizarea activităţilor de rutină

- sprijinirea proceselor de comunicare
- sprijinirea procesului decizional
- sprijinirea top-managerilor.
1.3.5 Clasificarea sistemelor informatice după elementul supus analizei:

- sisteme informaţionale orientate spre funcţii

- sisteme informaţionale orientate spre procese
- sisteme informaţionale orientate spre date
- sisteme informaţionale orientate spre obiecte
- sisteme informaţionale orientate spre mesaje /comunicări
- sisteme informaţionale orientate spre informaţii ştiinţifice.

1.3.6 Clasificarea sistemelor informatice după modul de organizare a datelor:

-sisteme bazate pe fişiere clasice

- sisteme bazate pe tehnica bazelor de date: ierarhice, reţea, relaţional, orientate- obiect,
neuronale
- sisteme mixte.

1.3.7 Clasificarea sistemelor informatice după metoda folosită în analiza şi

proiectarea sistemelor:

- sisteme dezvoltate după metoda sistemelor

- sisteme dezvoltate după metoda clasică a ciclului de viaţă a sistemelor
- sisteme dezvoltate după metoda structurată
- sisteme dezvoltate după metoda orientată obiect
- sisteme dezvoltate după metoda de realizare rapidă (RAD – Rapid Application
Development)
- sisteme dezvoltate după metoda echipelor mixte (JAD – Join Application Design)
- sisteme dezvoltate după metoda participativă
- sisteme dezvoltate după metoda prototipurilor.

1.4 Abordări arhitecturale în realizarea sistemelor informaționale

 În realizarea unui sistem informațional se poate opta pentru una din următoarele
soluţii:
- sistem informațional centralizat
- sistem informațional descentralizat

Sistemul informațional centralizat se caracterizează prin faptul că întregul proces

de stocare și procesare a datelor precum și de dezvoltare a sistemului se realizează la
nivelul unei singure locații în care se află un singur sistem de calcul, de regula un
mainframe, care stochează o bază de date unică precum și ansamblul programelor de
aplicație. Utilizatorii interactionează cu sistemul prin intermediul terminalelor.
Avantajele centralizării sunt reprezentate de:
- controlul efectiv asupra utilizării și dezvoltării software-ului
- controlul asupra securității și integrității datelor
- partajarea resurselor hard, soft și a datelor între utilizatori
- eliminarea riscului incompatibilității hard și soft în cadrul sistemului
- promovarea cu ușurință a standardelor (tehnice, de proiectare, procedurale etc)
la nivelul întregului sistem
- asigurarea serviciilor solicitate de către utilizători prin puterea de calcul a
sistemului central

Dezavantajele centralizării sunt reprezentate de următoarele aspecte:

- "căderea" sistemului de calcul blochează toţi utilizatorii
- alterarea datelor şi a programelor, voita sau accidentală, afectează toţi utilizatorii
- sistemul se poate dovedi lent şi inflexibil la nevoile utilizatorilor, adesea fiind
insuficient adaptat nevoilor locale sau de grup ale utilizatorilor
- poate realiza un timp mare de răspuns în cazul unor solicitari simultane ale mai
multor utilizatori.
Sistemul informatic descentralizat se caracterizează prin faptul ca datele,
software-ul si puterea de calcul sunt dispersate în diferite locaţii (chiar dispersate
geografic) ale organizaţiei. Prelucrarea se realizează pe calculatoare personale
independente sau în cadrul unor reţele locale.

Avantajele descentralizării:
- datele sunt stocate si prelucrate local
- soft-ul este mai bine adaptat nevoilor locale
- avariile hard, soft sau ale bazei de date la nivelul unei locaţii nu afectează celelalte locaţii
- configuraţia sistemului poate fi gândită în funcţie de nevoile diferitelor departamente
din cadrul organizaţiei sau chiar a utilizatorilor locali
- mai marea autonomie şi motivare la nivelul utilizatorului local.

Dezavantajele descentralizării:
- riscuri mari legate de incompatibilităţi hard şi soft între diferite locaţii
- apariţia inerentă a unor duplicări ale datelor şi software-ului în diferite locaţii
- dificultatea realizării unor proiecte complexe la nivel local
- riscul de fragmentare a politicii TI
- costuri mai mari în comparatie cu sistemul centralizat.
 Tendinta actuală este net orientată către descentralizare care trebuie să se realizeze
astfel încât:
- întreaga responsabilitate si autoritate pentru funcţiile descentralizate ale SI sa apartină
managementului local
- să se asigure alinierea la standardele utilizate la nivelul SI global al organizaţiei
- la nivel central urmează să se realizeze
- elaborarea strategiei la nivelul întregului SI al organizaţiei
- managementul comunicaţiilor în cadrul reţelei locale ale organizaţiei
- administrarea datelor
- refacerea în caz de dezastre.
Astăzi, arhitectura promovată în realizarea sistemelor descentralizate este
arhitectura clientserver caracterizată prin faptul că aplicaţiile şi datele puse la dispoziţia
utilizatorilor sunt dispersate pe diferitele componente hardware în funcţie de numărul
utilizatorilor care trebuie să aibă acces şi de puterea de calcul necesară.
Referințe
1. Oprea D., Airinei D., Fotache M. – “Sisteme informaţionale pentru afaceri“
Editura Polirom, 2002
2. Petersen J., Trad. Slavu O.V. – “Baze de date pentru începători”, Editura All, 2002
3. Militaru Gh. – “Sisteme informatice pentru management”, Editura All, 2003
4 Hernandez M. – “Proiectarea bazelor de date”, Editura Teora, 2003
5. Connolly Th., Begg C., Strachan A. – “Baze de date - proiectare, implementare,
gestionare”, Editura Teora, 2002
6. Muller N.J. – “Enciclopedia Internet”, Editura Tehnica, 2004
7. Levine J.R., Baroudi Carol, Levine Young M. – “Internet” Editura Tehnica, 2001
8. Bajenescu T.I. – “Inteligenţa distribuită şi serviciile în reţelele de telecomunicaţii”,
Editura Tehnica, 2002
9. Patic P.C. – “Tehnologii WAP”, Editura Tehnica, 2003
10. Popescu I. – “Modelarea bazelor de date”, Editura Tehnica, 2001
11. Karnyanszky T.M. – “Reţele de calculatoare şi comunicaţii de date”, Editura
Augusta Timişoara, 2001
12. Homorodean M.A., Iosupescu I. – “Internet şi pagini web: manual pentru
incepători şi iniţiaţi”, Editura Niculescu, 2001
13. Hammuda H. – “Sisteme radio celulare”, Editura Teora, 1999
14. Bajenescu T. – “Sisteme personale de comunicatii”, Editura Teora, 2000
15. Buraga S. – “Aplicaţii Web la cheie”, Editura Polirom, 2003
16. Graham S., Simeonov S., Boubez T., Davis Doug, daniels G., Nakamura Y.,
Nezama R. – “Servicii Web cu Java, XML, SOAP, WDSL si UDDI”, Editura Teora, 2003
17. Norton P., Kearns D. – “Retele de calculatoare”, Editura Teora, 2000
18. Ogletree T. – “Reţele de calculatoare - depanare si modernizare”, Editura Teora,
2000
19. Kilmer W. – “Reţele de calculatoare si Internet pentru oameni de afaceri”, Editura
Teora, 2003
20. XtremPC, Nr. 53/2004
21. Engineering, http://www.m-w.com/dictionary/engineering+
22. Inginerie, http://enciclopedie.citatepedia.ro/index.php?c=inginerie
TEMA 2

2.1. Ingineria programării. Ciclu de viață a Sistemelor Informaționale. Modele ale

Ciclului de viață. Metode și Metodologii de dezvoltare Sisteme Informaționale. 2.2.
Modele de elaborare Sisteme Informaționale. 2.3. Instrumente CASE pentru dezvoltarea
sistemelor informatice.

2.1. Ingineria programării. Ciclu de viață a Sistemelor Informaționale. Modele ale

Ciclului de viață. Metode și Metodologii de dezvoltare Sisteme Informaționale

Ingineria programării (Software engineering) Se referă la metodologiile folosite

în rezolvarea proiectelor mari care sunt rezolvate de echipe de oameni. Folosirea
principiilor inginereşti în analizarea, dezvoltarea, punerea în funcţiune, testarea,
întreţinerea, retragerea produselor software. Tot aici mai pot fi prinse: gestionarea
resurselor, coordonarea echipelor, planificare, buget.
- scop: obţinerea de programe sigure şi care funcţionează eficient pe maşini de calcul
concrete
Etapele dezvoltării produselor soft:
Analiza cerinţelor (Requirements analisys)
- proiectarea architecturală (Arhitectural design)
- proiectarea detaliata (Detailed design)
- scrierea codului (Implementation)
- integrarea componentelor (Integration)
- validare (Validation)
- verificare (Verification)
- întreţinere (Maintenance)

2.1.1 Ciclul de viaţă ca un întreg

Conceptul fundamental al ingineriei software îl constituie Ciclul de Viaţă

produselor software.
Odată dezvoltat, produsul software intra într-un ciclu de utilizare și modificare
(upgreat), care continuă pe toată durata sa de viață.
Tiparul nu este specific numai produselor software, el putând fi generalizat pentru
majoritatea produselor industriale, cu diferența că în cazul acestora din urmă etapa de
modificare se numeşte etapa de reparare sau de întreținere (ciclul este utilizare -
modificare, pe măsură ce componentele se uzează).
 Figura 2.1. Tiparul general a ciclului de viață a produselor

Ciclul de Viață a Sistemului Informațional - este succesiune de etape și procese,

executate în cadrul etapelor.
Pentru fiecare etapă este determinată componența și succesiunea lucrărilor
executate, rezultatele la ieșire, metodele și mijloacele necesare pentru îndeplinirea
lucrărilor, rolurile și responsabilitățile participanților.
Ciclul de viață - șir de evenimente, care se produc în procesul creării și exploatării
sistemului.

2.1.2 Modele ale ciclului de viață

Modelul Ciclului de Viață reflectă diferite stări ale sistemului, pornind de la momentul
apariției necesității de elaborare până la retragerea sistemului.
Modelul Ciclului de Viață - poate fi privit ca structura, care include procesele, acțiunile
și sarcinile realizate în timpul elaborării, funcționării și întreținerii produsului program pe
întreaga perioadă de existență a sistemului, de la stabilirea cerințelor până la retragerea
din utilizare.

2.1.3 Etape de proiectare Sisteme Informaționale

Etapa de analiză
Aceasta este etapa în care se constată că ar fi utilă o aplicație informatică și se ia
decizia dezvoltării unui sistem software. Fie că se constată existenţa unei pieţe pentru un
produs de uz general, fie că o anumită organizaţie are nevoie de o aplicaţie specializată,
în mare masură această primă etapă presupune mai degrabă luarea unor decizii de
management şi marketing decât abordarea unor problem legate de studiul algoritmilor.
După luarea deciziei de dezvoltare a unui sistem informatic începe adevarata
analiză, al cărei scop principal este identificarea necesităţilor utilizatorului potenţial al
sistemului.

Etapa de proiectare

În faza de proiectare sunt dezvoltate detaliile tehnice ale sistemului. În această

etapă, sistemul este decompus în componente mai uşor de realizat și de controlat, numite
module. Implementarea sistemelor complexe devine posibilă tocmai prin această
descompunere modulară.
 Altfel, mulţimea detaliilor tehnice care trebuie luate în considerare ar fi imposibil
de stăpânit; prin proiectarea modulară, este suficient să avem în vedere pentru fiecare
modul doar detaliile corespunzătoare acestuia.
Pe de altă parte, proiectarea modulară ajută şi la întreţinerea sistemului.
O structură modulară bine proiectată este importantă atât pentru implementarea
sistemului, cât şi pentru modificarea sa ulterioară. Acesta este unul dintre principalele
motive pentru care paradigma orientată spre obiecte câştigă teren: un sistem proiectat
orientat spre obiecte este prin definiţie un sistem modular.

Etapa de implementare/testare

- implementarea
Această fază se referă la scrierea efectivă a programelor, crearea fişierelor de date şi
dezvoltarea bazelor de date.
- Testarea-
Această fază este strâns legată de faza anterioară, deoarece în normal fiecare modul
al sistemului este testat în timpul implementarii, într-un sistem bine proiectat, fiecare
modul poate fi testat în mod independent, utilizându-se versiuni simplificate ale celorlalte
module pentru a se simula interacţiunile dintre modulul ţintă şi restul sistemului. Desigur,
pe masura ce diferite module sunt analizate şi combinate, testarea individuală trebuie
continuată cu testarea generală a întregului sistem.

2.1.4 Faze, ca elemente comune duiferitelor abordări:

- definirea cerinţelor utilizatorilor: utilizatorii vor preciza obiectivele pe care urmează

să le îndeplinească viitorul sistem informaţional, criteriile de eficienţă, securitate,
performanţă pe care acesta urmează să le asigure. Calitatea şi performanţele unui produs
software depind de abilitatea echipei de analiză în colectarea de specificaţii cât mai
complete de la viitorul utilizator şi de a-i face pe acestea vadă funcţionalitatea viitorului
sistem informaţional
- specificaţia cerinţelor sistemului: prezentarea detaliată a rezultatelor pe care sistemul
informaţional urmează să le asigure. Se va evidenţia ce anume urmează să facă sistemul,
fără a se sugera nici un fel cum va face acest lucru sistemul. Această fază este un răspuns
la specificaţie cuprinzând cerinţele utilizatorului şi va fi utilizată în faza de proiectare a
sistemului
- specificaţia cerinţelor software: evidenţiază ce urmează să facă produsul software şi
restricţiile sub care funcţionalitatea sa urmează să fie asigurată
- proiectarea generală, în cadrul căreia se defines soluţii cadru, conceptuale, privind
viitorul sistem informaţional.
- proiectarea de detaliu, care rafinează soluţia cadru , rezultat al proiectării generale,
având ca finalitate definirea soluţiei finale a sistemului informaţional.
- realizarea componentelor sistemului informaţional, pe baza soluţiilor oferite de
proiectarea de detaliu
- testarea componentelor: verificarea modului de funcţionare, modului de îndeplinire a
cerinţelor şi fiabilitatea în utilizare
- integrarea componentelor şi testarea finală a sistemului: reunirea componentelor în
cadrul produsului final şi verificarea funcţionării lui în ansamblu
- implementarea şi testarea produsului la beneficiar, urmate de acceptarea de către
beneficiar
- expluatarea şi mentenanţa sistemului: utilizarea curentă a sistemului informaţional
şi mentenanţa lui
- dezvoltarea sistemului informaţional: realizarea şi integrarea de noi componente
care să îmbunătăţească şi/sau dezvolte funcţionalitatea, şi performanţele sistemului
În cadrul diferitelor modele, aceste faze (alături de cele specific fiecărui model)
sunt reunite în cadrul unor etape şi anume:
- analiza sistemului, care pleacă de la analiza sistemului existent şi se conţin în
fazele 1-3
- proiectarea generală (faza 4)
- proiectarea de detaliu, (faza 5)
- realizarea sistemului informaţional (fazele 6-8)
- instalarea sistemului informaţional pe sistemele de calcul ale beneficiarului (faza
9)
- expluatarea şi mentenanţa sistemului (faza 4)
- dezvoltarea sistemului informaţional (faza 11).

2.2 Modele de elaborare Sisteme Informaționale

Modelele elaborate au cunoscut îmbunătăţiri permanente, încercânduse adaptarea

lor la noile cerinţe ale modelării orientate obiect, precum şi inserarea unor etape specific
managmentului proiectelor.
Criterii de selectare a unui model
Buget
- joacă un rol cheie
- dimensiunea echipei
- metodologii agile = echipe mici
- tehnologiile utilizate
- unelte şi tehnici
- natura proiectului
- procese existente în companie

2.2.1 Modelul cascadă

Modelul cascadă (Waterfall Model) a fost elaborate de W.W. Royce la începutul anilor
“70. Este un model de referinţă în literatura de specialitate, caracterizat prin parcurgerea
secvenţială a fazelor ciclului de viaţă, faze care , la rândul lor, sunt formate din activităţi,
iar acestea din urmă din subactivităţi.
Modelul prezintă următoarele facilități:
- controlul total al fazelor, datorită modului de ordonare a acestora
- uşor de însuşit de către membrii echipelor de analiză şi proiectare
- fiecare fază se încheie cu o verificare a soluţiei oferite şi asigură o documentaţie
prezentând soluţia elaborate.
În timp au fost propuse variante îmbunătăţite ale modelului:
- modelul cu revenire la pasul următor (Waterfall Model with back flow)
- modelul cu reluare de la faza iniţială (“Da Capo” Waterfall Model).
Figura 2.2. Ciclul de viaţă în Model cascadă cu control intermediar

Figura 2.3. Ciclul de viaţă în Model cascadă cu control intermediar

Rezultatul proiectării în modelul cascadă
Setul de documente ce formează minimul ce ar trebui produs în fiecare proiect sunt:
- document de cerinţe
- planul proiectului
- document de design al sistemului
- document de design detaliat
- plan de test şi raport de test
- cod final
- manuale software (manualul utilizatorului, manual de instalare etc.)
- raporturi de evaluare.

Avantajele modelului cascadă

- uşor de explicat utilizatorilor
- etapele şi activităţile sunt bine definite
- este utilă planificarea şi programarea proiectului
- verificarea în fiecare etapă asigură detecţia timpurie a erorilor/neînţelegerilor
- uşor de manevrat datorită rigidităţii modelului
- etapele sunt procesate şi completate pe rând
- funcţionează bine pentru proiectele mai mici unde necesităţile sunt foarte bine
înţelese sau pentru automatizarea unor sisteme deja existente.

Dezavantaje ale modelului cascadă

- ajustarea scopului în timpul ciclului de viaţă poate ”omorî” un proiect
- nu se introduce software funcţional până spre finalul ciclului de viaţă
- cantităţi mari de risc şi nesiguranţă
- model slab pentru proiectele complexe şi obiect-orientate
- model slab pentru proiectele lungi şi continue
- model slab acolo unde necesităţile au un risc moderat spre ridicat de a se schimba.

Modelul cascadă presupune că toate cerinţele unui sistem pot fi îngheţate înaintea
începerii design-ului. Acest lucru este posibil pentru sistemele create să automatizeze un
sistem manual deja existent. Dar pentru un sistem absolut nou, determinarea cerinţelor
este dificilă, din moment ce nici chiar utilizatorul nu ştie cerinţele. Astfel, a avea cerinţe
ce nu se schimbă (sau se schimbp doar puţin) este nerealistă pentru un asemenea proiect.
Îngheţarea cerinţelor necesită deseori alegerea hardware-ului (din moment ce formează o
parte a specificaţiilor necesităţilor).
Un proiect mare ar putea dura câţiva ani până la finalizare. Dacă hardware-ul este
selectat timpuriu, apoi datorită vitezei la care tehnologia hardware se schimbă, este foarte
probabil ca software-ul final să necesite o tehnologie hardware ce este pe cale să devină
învechită. Acest lucru este în mod clar nedorit pentru software atât de costisitor.
Modelul cascadă stipulează faptul că cerinţele ar trebui specificate complet înainte
ca restul dezvoltării să poată începe. În anumite situaţii ar putea fi de dorit ca mai întâi să
se dezvolte o parte a sistemului complet, iar apoi să se îmbunătăţească sistemul. Acest
lucru este deseori efectuat pentru produsele software ce sunt realizate nu neapărat pentru
un client (unde clientul joacă un rol important în specificarea cerinţelor), dar pentru piaţa
generală, în care cerinţele sunt determinate cel mai probabil de către dezvoltatori.
Modelul cascadă cu 7 etape
Etape - Se poate considera un model cascadă cu 7 etape ce se includ în cele patru faze
ale unui model SDLC (Software Development Life Cycle):
Faza de decizie- Faza de decizie a unui SDLC este atunci când se decide ce se doreşte a
se implementa ca software. În această fază sunt 3 etape:
- situaţia de afaceri – ceea ce utilizatorul doreşte să obţină de la software
- cerinţele utilizatorilor - ceea ce software-ul trebuie să facă pentru afacere
- specificaţiile sistemului – ceea ce software-ul trebuie să realizeze în termeni de
computare pentru a îndeplini cerinţele clienţilor.

Situaţia de afaceri

Cerinţele utilizatorilor Decizie

Specificaţiile sistemului

Design-ul sistemului

Design
Design-ul componentelor

Construcţia compoenentelor
Dezvoltare

Testare
Demonstrare

Figura 2.4. Modelul cascadă cu 7 etape și patru faze

Faza de decizie

Situaţia de afaceri

Aceasta este justificarea pentru a construi sistemul software şi trebuie să acopere

un număr de domenii, incluzând:
- care este situaţia curentă a afacerii şi software-ului
- care este oportunitatea de afaceri pe care software-ul o va rezolva
- care sunt diversele strategii de soluţii şi fezabilitatea lor
- care este strategia de soluţie preferată
- care este relaţia costuri – beneficii
- care sunt presupunerile, riscurile şi constrângerile posibile
- care este abordarea de implementare în linii mari.
O cantitate considerabilă de muncă trebuie să fie realizată de către utilizatori cu date
de intrare oferite de dezvoltatori pentru a produce o situaţie de afaceri.
Beneficiile realizării acestui lucru sunt oferirea tuturor din proiect a unei hărţi clare
a locului în care se îndreaptă utilizatorii şi de ce.
Cerinţele utilizatorilor

Următoarea etapă este aceea de a defini un set de cerinţe ale utilizatorilor. Acestea
definesc pentru strategia preferată de soluţii ceea ce sistemul software trebuie să obţină
pentru a împlini oportunitatea de afaceri.
Domeniile ce trebuie incluse sunt:
a) cerinţe funcţionale – ce trebuie să realizeze sistemul, de exemplu pentru a păstra
detalii ale arhivelor utilizatorilor
b) cerinţe non-funcţionale – sunt două tipuri:
1) constrângeri de performanţe – ce performanţă este necesară din partea
sistemului, de exemplu dacă va aduce la zi arhivele clienţior peste noapte
2) contrângeri de dezvoltare – ce restricţii asupra dezvoltării se vor aplica, de
exemplu dacă sistemul trebuie să fie disponibil la un anumit moment
c) obiectivele de design – care sunt cele mai importante caracteristici ce se aplică
sistemului

Specificaţiile sistemului

Specificaţiile sistemului au loc atunci când se trece de la concentrarea pe utilizatori la

sistemul în dezoltare. Este design-ul logic a sistemului software şi modul de a-l realiza.
Acoperă:
a) procesele sistemului – ce proces tehnic este necesar pentru a implementa fiecare
proces de afaceri
b) interfeţe externe – ceea ce este necesar pentru sistem pentru a comunica în afară,
inclusiv:
1) interfeţe tranzacţionale – ceea ce este necesar pentru a comunica cu utilizatorii
(cum ar fi monitoare)
2) interfeţe de raport – ce tipuri de rapoarte sunt necesare
3) interfeţe de aplicaţii – ce conexiuni sunt necesare pentru alte sisteme software
4) cerinţe non-funcţionale – care sunt constrângerile asupra sistemului.

Suprapunerea stadiilor

Caracteristica distinctivă a tuturor celor trei etape în Decizie este faptul că se ocupă
de ceea ce se doreşte. Totuşi, graniţele dintre ele se pot suprapune.
- utilizatorul dezvoltă atât situaţia de afaceri cât şi cerinţele utilizatorului şi
probleme din oricare pot trece la cealaltă etapă sau chiar să fie acoperite de ambele.
Cheia este de a asigura că ele sunt acoperite măcar într-un loc.
- graniţa dintre Cerinţele utilizatorilor şi Specificaţiile sistemului poate avea o mare
suprapunere, în special din moment ce ambele au ca scop informarea dezvoltatorilor
Diferenţele cheie dintre cele două sunt:
- cerinţele utilizatorilor sunt scrise de către utilizatori asistaţi de dezvoltatori, în
timp ce Specificaţiile sistemului sunt scrise de dezvoltatori asistaţi de utilizatori
- cerinţele utilizatorilor exprimă funcţionalitatea necesară în termeni de ceea ce
afacerea doreşte să obţină, în timp ce Specificaţiile sistemului exprimă
funcţionalitatea în termeni de ceea ce sistemele software ar putea realiza.
Faza de Design

Faza de Design are loc atunci când diverse cerinţe sunt mapate la mediul software
şi au loc deciziile de implementare. Această fază se concentrează pe modul în care
software-ul va fi realizat. Această versiune a modelului cascadă are două etape:
- design-ul sistemului – modul în care software-ul va fi structurat în componente
- design-ul componentelor – modul în care o componentă va fi structurată
Design-ul sistemului - Etapa de design a sistemului ia Specificaţiile sistemului şi
creează arhitectura sistemului. Acest lucru este realizat prin definirea unei serii de
componente împreună cu ceea ce realizează şi cum interacţionează cu alte componente.
Aceste componente pot fi alte sisteme, interfeţe, module de cod, ecrane, baze de date etc.
ceea ce nu este definit este detaliul cu privire la modul în care va funcţiona fiecare
componentă.
Design-ul componentelor - Etapa de design al componentelor este design-ul
detaliat a modului în care o anumită componentă va funcţiona, şi cum comunică
rezultatele sale către alte componente prin interfeţe. Nu este probabil să existe un
document ce acoperă design-ul tuturor componentelor deoarece ele sunt create de
persoane diferite. În multe cazuri, aceste design-uri sunt realizate de către cei ce codează.

Faza de dezvoltare

Faza de dezvoltare este etapa de Construcţie a componentei în modelul cascadă.

Ea se ocupă cu construcţia componentelor necesare pentru software. Componentele
software vin în multe forme şi variază de la software realizat pe comandă dezvoltat în
mod special pentru sistem, până la pachetul software ce este configurat pentru a satisface
cerinţele.
Există două principale tipuri de pachete software:
- COTS (Commercial Off The Shelf) – Acestea sunt pachete de aplicaţii ce acoperă
nevoi variate ale utilizatorilor ce sunt aduse şi configurate de funrizori comerciali
- Open Source – Acestea sunt pachete variate de aplicaţii, dar sunt întreţinute de o
comunitate de utilizatori.
Software-ul realizat pe comandă va putea îndeplini necesităţile exacte, dar este
costisitoare producţia sa. În teorie, există economii de preţ utilizând pachete software. În
teorie, deoarece costurile de instalare pot fi mai mici, dar costul rulării pachetului pe
parcursul vieţii sale poate fi mai mare.

Faza de demonstrare

Faza de demonstrare este etapa de test şi implică faptul că sistemul software

îndeplineşte toate etapele de design, specificaţii şi cerinţe din fazele de Decizie şi Design.

Observaţii

Aceste şapte etape realizează modelul cascadă aşa cum este utilizat în mod tradiţional,
dar flexibilitatea în modul în care este utilizat afectează cît de succes va avea. Există un
număr de probleme cu modelul cascadă, de aceea a evoluat în modelul în V.

Aplicare
 Modelul cascadă poate fi utilizat cu succes atunci când necesităţile sunt bine
înţelese de la început şi nu se aşteaptă să se schimbe sau evolueze pe parcursul vieţii
proiectului. Riscurile proiectului ar trebui să fie relativ joase.

2.2.2 Ciclului de viaţă Modelul în V

A fost utilizat în Germania și SUA în anii ’80

- partea stângă – analiza cerințelor și crearea specificațiilor sistemului
- partea dreaptă – integrarea părților și validarea lor
- V de la Verificare și Validare
Modelul în V este o variant a modelului cascadă, care aduce elemente calitative
noi importante. Un element careacteristic al modelului este introducerea conceptelor de
sistem şi componenta (subsistem), aplicânduse teste explicite pentru creşterea
controlului asupra modelului în care se desfăşoară etapele. Fazele plasate în partea
superior a modelului se caracterizează prin implicarea direct a viitorului utilizator.

Figura 2.5. “V” Model de la SEF (Ould, 1990)

 Figura 2.6. Modelul “V” cu planificare teste de acceptare

Descrierera diagramei

Braţul stâng al diagramei, parcurs descendent, reuneşte fazele în cadrul cărora se

realizează, pas cu pas, proiectarea şi realizarea sistemului informational. Detalierea
activităţilor de proiectare, codificare şi asamblare a componentelor se realizează gradual.
Dealtfel, Ould, creatorul modelului în forma sa consacrată, a prevăzut doar latura din
stânga, unde efortul principal de proiectare se focalizează pe descompunerea sistemului
pe component.
Braţul drept al diagramei parcurs ascendent cuprinde reprezentarea fazelor
asigurând asamblarea rogresivă a sisgtemului, pe măsura testării lor individuale, până la
obţinerea sistemului global şi acceptarea acestuia de către beneficiar.
În cadrul modelului, se remarcă realizarea distincţiei dintre verificare şi validare.
Verificarea se referă la testarea sistemului la diferite stadia pe care le parcurge, iar
validarera urmăreşte să identifice în ce măsură sistemul corespunde cerinţelor iniţiale,
ceea ce constitue un punct slab al modelului, datorită întârzierii cu care se produce această
validare. Tocmai din această cauză, i se reproşează că lasă validarea prea târziu, după
ce sistemul s-a construit, ceea ce îl face ineficient.

2.2.3 Ciclului de viaţă Modelul în ”W”

Acest model reia ideia modelului V, pe care îl dezvoltă şi perfecţionează prin

integrartea acivităţilor de validare la nivelul fazelor de proiectare.
 Figura 2.7 - Ciclul de viață Modelul în ”W”

2.2.4 Ciclul de viață Modelul evolutiv

Modelul evolutiv porneşte de la realizarea unui studiu inițial privind obiectivele

viitorului sistem informational, a cărui arhitectură este definită ulterior. Fiecare
componentă astfel definită îşi va urma propriul său ciclu de viaţă (definirea cerinţelor,
analiza, proiectare, testare, utilizare).
Un Sistem informaţional reprezintă ansamblul unor component în interacţiunea
lor, fiind rezultatul unei concepţii bazate pe arhitecturi deschise şi flexibile. O astfel de
abordare etste apropiată celei orientate obiect, caracterizate prin încapsularea datelor şi
funcţionalităţii obiectelor.
Reprezentarea grafică a modelului evolutiv este influenţată de modelul circular, a
cărui caracteristică o reprezintă marcarea unui ciclu complet al sistemului informatic
printr-un cerc.

Figura 2.8 - Reprezentarea grafică a modelului evolutiv

2.2.5 Ciclul de viață Modelul spirală

Modelul spirală, elaborate de Barry Boehm, se bazează pe aceleaşi principii ca şi

modelul evbolutiv. Modelul presupune construirea mai multor prototipuri successive, în
condiţiile unei analize a riscului pe fiecare nivel.
Fazele de dezvoltare sunt reluate la fiecare iteraţie, în aceiaşi siccesiune şi presupun:
- analiza riscurilor
- realizarea unui prototip
- simularea şi testarea prototipului
- determinatea cerinţelor în urma rezultetelor testării
- validarea cerinţelor
- planificarea ciclului următor.
În centrul spiralei este plasată cunoaşterea cerinţelor şi estimarea costurilor la nivel
preliminar. Evoluţia sistemului informaţional urmează desfăşurarea spiralei, înregistrând
acumulări successive ale costurilor şi este marcată de succesiunea prototipurilor.
Fiercare dintre acestea valorificând acumulările realizate la nivelul prototipului anterior.
Interacţiunea dintre faze nu este reliefată direct, atâta timp cât modelul prevede o
sccesiune continuă a rafinării, legate de decizii pe care riscurile proiectului le asociază cu
următoarea detaliere. Modelul evidenţiază atenţia acordată planificării, căutării de soluţii
alternative, evaluării riscurilor şi validării soluţiilor pentru fiecare prototip, văzut ca un
stadiu distinct în realizarea sistemului informaţional.
În ingineria software, un prototip este folosit atât pentru validarea cât şi pentru
identificarea cererilor utilitzatorilor, pentru verificarea soluţiei de proiectare şi oferirea
bazei dezvoltării ulterioare a proiectului de sistem informaţional. Apelarea la utilizarea
prototipului este consecinţa faptului că un model funcţional este mai uşor de înţeles de
către viitorul utilizator, decât un set de diagrame, fie chiar, însoţite de documentaţie. Un
Prototip funcţional presupune proiectarea sistemului, realizarea primului prototip
funcţional, verificarea măsurii în care corespunde cerinţelor formulate de utilizator şi
rafinarea acestei prime soluţii, prin dezvoltări viitoare care adaugă noi funcţionalităţi până
la obţinerea variantei finale a sistemului.

Figura 2.9. Reprezentarea grafică a modelului spirală

Descrierea modelului spiral
Evoluţia spiralei constă în cele 4 cadrane.
- primul cadran determina obiectivele, alternativele si constrangerile
- al doilea cadran evalueaza alternativele, identifica si rezolva riscurile
- al treilea cadran dezvolta si verifica produsul de la urmatorul nivel
- iar cadranul al patrulea planifică următoarele faze.
De altfel, spirala este orientată către dezvoltarea software, conceptul fiind egal aplicabil
sistemelor hardware.
Cadranul 1
Activităţile desfăşurate în acest cadran sunt următoarele:
- stabileşte un acord al sistemului sau a obiectivelor produsului: performanţa,
funcţionalitate şi abilitatea de adaptare la schimbări
- investighează implementările alternative: model, reutilizare, procurare si
modificare
- investighează constrângerile impuse cu privire la alternative: tehnologie, cost,
program, suport si riscuri
- o dată ce toate acestea au fost stabilite, se trece la cadranul al doilea.
Cadranul 2
Activităţile inginereşti reprezentate în acest cadran selectează o abordare alternative
ce satisfice mai bine tehnologia, costul, programul, suportul si riscul constrângerilor. Aici
se pune accentul pe atenuarea riscului. Este analizata fiecare alternativa şi este folosită în
aşa fel încât să reducă riscurile asociate dezvoltării deciziilor. Boehm descrie aceste
activităţi spunând că pot implica prototipuri, simulări, benchmarking, chestionare de
administrare, modelare analitică şi alte tehnici de rezoluţie a riscului. Dacă operaţia
critica şi/sau problemele tehnice precum riscul performanţei sau al interoperabilităţii
rămâne, este posibilă adăugarea unor detalii în plus a prototipului înainte de trecerea la
următorul cadran.
Cadranul 3
Dacă se determină ca prototipul anterior are rezolvate operaţiile critice/problemele
tehnice, activităţile de dezvoltare şi verificare, se trece la următorul nivel. Ca rezultat,
modul de bază ‘cascada’ poate fi utilizat(descrierea, conceptual operaţiilor, dezvoltarea,
integrarea si testarea următorului sistem). Se poate utiliza şi dezvoltarea incrementală.
Cadranul 4
Modelul de dezvoltare în spirala are o caracteristică comună cu toate celelalte
modele: nevoia planificării tehnice avansate şi analize multidisciplinare la aşteptarea
critică. Fiecare ciclu al modelului culmină cu o analiza tehnică ce evaluează starea,
progresul, maturitatea, meritele şi riscurile dezvoltării.

Avantaje şi dezavantaje modelului spiral

Avantaje:
- analiza crescută a riscurilor
- ideal pentru proiecte mari
- software-ul este produs devreme în ciclul de viaţă
- dezvoltare completă a modelului software la proiectele cu cereri neclare
- flexibilitate.
Dezavantaje
- model costisitor
- analiza riscurilor necesită expertiza specifica de nivel inalt
 - succesul proiectului depinde puternic de faza de analiză a riscurilor
- nu este potrivit pentru proiecte mici
- este greu de inteles de catre utilizatorii fără pregătire tehnică.
Aplicabilitate
Modelul spirala se foloseşte:
- atunci când crearea unui prototip este potrivită
- atunci când costurile şi evaluarea riscurilor este importantă
- pentru proiecte de risc mediu sau crescut
- pentru proiecte pe termen lung
- atunci când utilizatorii nu sunt siguri de nevoile lor
- atunci când cererile sunt complexe.

2.2.6 Ciclul de viață în Modelul ”Fântână arteziană”

Modelul fântână arteziană îşi are izvoarele în modelul spirală (ierarhic) şi modelul vârtej
de apă. Porneşte de la cunoaştertea lumii reale, a cerinţelor şi elaborarea studiului de
fezabilitate. Se parcurg apoi etapele de:
- analiză
- proiectarea sistemului
- proiectarea componentă
- codificare
- testare componentă
- testare sistem
- utilizare
- întreţinere
- dezvoltare.
 Figura 2.10. Ciclul de viață în modelul ”Fântână arteziană”

2.2.7 Ciclul de viață în ”Modelul tridimensional”

”Modelul tridimensional”promovat de metoda de proictare MERISE se caracterizează
prin reprezentarea grafică pe trei axe,
fiecare dintre acestea corespunzând:
- ciclului de viaţă al sistemului
- ciclului de decizii şi respective
- ciclului abstractizării.
 Figura 2.11. Ciclul de viață în ”Modelul tridimensional”

Ciclul abstractizării se dezvoltă pe trei nivele: conceptual, logic şi fizic.

Nivelul conceptual se aplică independent datelor şi prelucrărilor generând modelul
conceptual al datelor şi modelul conceptual al prelucrărilor. Se realizează succesiv
modelul logic al datelor şi modelul fizic al datelor, modelul logic al prelucrărilor
(organizaţional), modelul operaţional al prelucrărilor.
Ciclul de dececizie cuprinde ansamblul deciziilor legate de proiectarea, realizarea şi
exploatarea sistemului informaţional:
- deciziile globale vizează problemele cadru privind obiactivele sistemului
informaţional şi funcţionalitatea lui, domeniile de informatizat, priorităţile,
planificarea lucrărilor, etc.
- deciziile de organizare vizează arhitectura şi interacţiunile dintre component,
strategia de gestiune a datelor, planificarea activităţilor de proiectare generală,
proiectare de detaliu şi realizare a sistemului informaţional
- deciziile tehnice vizează suportul hardware şi de comunicaţie, suportul software
şi mediul de exploatare a sistemului informaţional. etc.
- deciziile legate de exploatare şi mentenanţă sunt decizii care asigură buna
funcţionare a sistemului informaţional şi aceste decizii aparţin utilizatorului.
Etape al Ciclului de viaţă presupune parcurgerea siccesivă următoarelor etape:
- schema directoare şi studiul prealabil presupune: analiza sistemului
informaţional existent, formularea cerinţelor şi obiectivelor sistemului
informaţional, definiţia priorităţilor în realizarea sistemului informaţional,
realizarea de scenarii globale alternative pentru fiecare domeniu investigat şi
alegerea scenariului considerat optim.
 - studiul detaliat pleacă de la soluţia cadru definite pentru scenariul ales, pe care o
dezvoltă, abordând problemele de la general la particular. Această etapă asigură
modelarea conceptuală şi organizational a viitorului sistem informaţional.
- studiul tehnic, prin soluţiile concrete pe care le defineşte, vă asigură modelarea
logică şi fizică. Codificarea corespunde etapei de scriere şi testare a procedurilor,
fiind apoi urmată de integrarea acestora şi de testare finală a sistemului
- implementarea şi testarea sistemului în condiţii reale de expluatare ale
beneficiarului vor fi urmate de acceptarea produsului, pe baza evaluării
rezultatelor testării
- exploatarea şi mentenanţa sistem informational au conţinutul conoscut deja din
prezentările anterioare.

2.2.8 Ciclul de viață în Modelul RAD (Rapid Application Development)

RAD este un model apărut ca răspuns la metodă tradiţională Waterfall, RAD se

bazează pe modificarea cerinţelor pe baza informaţiilor acumulate în urma dezvoltării
proiectului (se bazează pe dezvoltarea iterativă). Este un concept ce promite o dezvoltare
mai rapidă şi de calitate superioară care se bazează pe:
- obţinerea de informaţii în urma şedinţelor de stabilire a cerinţelor proiectului şi a celor
de brainstorming
- crearea de prototipuri (forme incomplete ale codului) şi reconstruirea acestora în bucăţi
de cod funcţionale ce pot fi introduse în producţie
- reutilizarea pe cât de mult posibil a codului
- formalitate scăzută în comunicarea cu membrii echipei

Business modeling – se referă la analiza fluxului de informaţii şi distribuţia informaţiei

între diferite funcţii ale produsului.
Data modeling – se referă la transformarea informaţiilor acumulate în prima etapă în
obiecte de date şi se construiesc relaţiile între obiecte.
Process modeling – se referă la crearea pe baza obiectelor construite anterior a unor
fluxuri de informaţii astfel încât să se atingă anumite obiective. Sunt detaliate procesele
prin care se fac operaţii de adăugare, editare sau ştergere a obiectelor.
Application generation - se referă la etapă de transformare (prin cod propriu-zis) a
obiectelor şi relaţiilor între ele în prototipuri.
 Figura 2.12. Schema modelului RAD

(http://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm)
Testing and turn-over – Sunt testate atât prototipurile cât şi interfeţele, deşi prototipurile
sunt testate indirect şi prin procesul iterativ interfeţele au o testare îndelungată reducând
riscul de a avea greşeli majore.
Avantajele modelului RAD sunt:
- timpul redus de dezvoltare a produsului
- se încurajează reutilizarea porţiunilor de cod
- este încurajată opinia clienţilor vizavi de proiect, modificări ulterioare putând fi făcute
rapid
- productivitatea este crescută datorită numărului relativ mic de membrii ai echipei
Deşi avem avantaje puternice modelul RAD, că multe dintre modelele de tip light, poate
prezenta numeroase dezavantaje:
- este dependent de o echipă puternică a căror cunoştinţe în domeniu sunt foarte bune
- se poate aplica doar pentru sistemele ce pot fi modularizate
- nu poate fi aplicat pentru proiecte cu buget redus deoarece costurile pot varia, mai ales
atunci când este vorba de un număr mare de programatori pentru a crea interfeţele.
Când se decide folosirea modelului RAD trebuie să ne asigurăm că proiectul este
de dimensiuni ce permit predarea în 2-3 luni şi că bugetul permite acest stil de lucru
(costisitor din punct de vedere al resurselor umane).

2.2.9 Modelul ciclului de viață "Incremental"

Modelul ciclului de viață "Incremental" este opus modelului «în cascadă».
El se bazează pe o idee foarte simplă:
Dacă un sistem este prea complex pentru a fi înțeles, conceput sau realizat într-o singură
fază este mai bine sa fie realizat în mai multe faze, prin evoluție.
Cum se aplică
Într-o fază iniţială:
Se studiază scopul proiectului şi fezabilitatea sa. În cazul deciziei de continuare a
proiectului:
- se detaliază cerinţele utilizatorilor şi se efectuează o analiză de nivel înalt, pentru
a se determina cerinţele software la un nivel general
- se determină o arhitectură generală a sistemului
- se împart cerinţele în subseturi care pot fi implemenate în incremente separate. Se
stabileşte planificarea în timp a incrementelor
- fiecare increment implementeaza un subset de cazuri de utilizare de nivel înalt,
care exprimă cerinţele utilizatorilor. El este construit urmând abordarea
“cascada”: analiza detaliată a cerinţelor din subset, proiectarea, implementarea şi
testarea. Rezultatul este un produs care satisface un subset al cerinţelor şi este
livrat utilizatorilor. Un produs tipic consta din 10-50 incremente
- se incepe cu o implementare simplă a unui subset al cerinţelor software. Rezultă
o prima livrare
- scopul primei implementări este de a crea un produs la care utilizatorul poate
reacţiona. El trebuie să pună în evidenţă aspectele cheie ale problemei şi să
furnizeze o soluţie suficient de simplă pentru a fi înţeleasă şi usor de implementat
- fiecare noua iteraţie include analiza ultimei versiuni şi adăugarea de noi
functionalităţi, ceea ce presupune reproiectarea, codificarea şi testarea. Se
urmăreşte ca proiectarea sa fie directă, modulară, să suporte reproiectarea
- analiza unei iteraţii se bazează pe feedback-ul utilizatorului şi pe instrumentele de
analiză disponibile. Ea se referă la: modularitea produsului, cuplarea modulelor,
utilizabilitatea, fiabilitatea, eficienţa şi realizarea scopurilor
- fiecare iteraţie este o variantă îmbunătăţită a celei anterioare, de aceea metoda se
mai numeşte “ îmbunătăţirea iterativă” (iterative enhancement).

Figura 2.13. Schema modelul ”incremental”

- se utilizează măsuri pentru evaluarea evoluţiei sistemului. Măsurile prin care se
evaluează un software sunt dificil de inţeles ca valori absolute, dar schimbările
 valorilor lor în evoluţia unui sistem sunt o bază de comparaţie. Astfel de măsuri
sunt: numărul de defecte, efortul de actualizare, dimensiune, complexitatea,
cuplarea modulelor. Schimbările diferitelor aspecte se pot monitoriza şi se pot
stabili limite pentru anumite măsuri, pentru a semnala probleme sau anomalii
- utilizarea analizei şi a măsuratorilor ca ghid în procesul iterativ este o diferenţă
majoră între aceasta metoda şi metodele de “dezvoltare agilă” (agile software
development). Ele sunt suportul pentru determinarea eficienţei procesului si a
calităţii produsului
- fiecare iterație a ciclului de viață iterativ și incremental reproduce ciclul de viață
în cascadă la o scară mai mică. Obiectivele unei iterații sunt stabilite pe baza
evaluării iterațiilor precedente
- documentația este construită treptat, în timpul fiecărei iterații. La sfârșitul
dezvoltării, documentele obținute au aceeași formă cu cele obținute în maniera
convențională.
Avantaje:
În fiecare etapă este livrat un produs executabil, care satisface o parte din cerinţele
utilizatorului. Opus modelului cascadă în care se elaborează documente.
- prototipurile sunt livrate clientului/utilizatorilor
- feedback-ul utilizatorilor este distribuit pe întreg parcursul dezvoltării
- în cazul apariției unor schimbări în cerințe acestea pot fi încoporate în următorul
prototip
- ciclul de viață iterativ se bazează pe evoluția prototipurilor executabile,
măsurabile și deci pe evoluția elementelor concrete. El este opus din acest punct
de vedere ciclului de viata în cascadă care se bazează pe elaborarea de documente.
Livrările forțează echipa să dea rezultate concrete în mod regulat
- integrarea diferitelor componente ale programului este realizată într-o manieră
progresivă în timpul construcției
- progresele se măsoară prin programe demonstrabile mai degrabă decât prin
documente sau estimări, ca în ciclul de viață în cascadă
- în cursul dezvoltării, clientul poate utiliza prototipurile. Demonstrarea
prototipurilor prezintă numeroase avantaje
- utilizatorul este pus în fața situațiilor de utilizare concrete care-i permit să-și
definească mai bine dorințele și să le comunice echipei de dezvoltare
- utilizatorul devine partener al proiectului
- el îşi ia partea de responsabilitate în noul sistem și de fapt îl acceptă mai ușor.
Dezavantaje
Ciclul de viață Incremental se bazează pe evoluția prototipurilor executabile. Din
nefericire, programele nu se pretează în mod natural evoluției, din contră, ele sunt deseori
foarte "fragile" la modificări. Efectul unei modificări locale se poate propaga în ansamblul
aplicației. Fiecare nou increment poate necesita reorganizarea structurii interne,
degradând arhitectura inițiala a programului, facându-l greu de verificat și de întreținut.
Erorile de proiectare sunt mai greu de eliminat.
Abordarea obiect bazată pe modularitate și incapsulare conduce la programe mai
robuste și mai rezistente față de schimbări. Din acest punct de vedere, abordarea obiect
furnizează un cadru confortabil pentru dezvoltarea prin evoluție, într-o manieră iterativă.
- clientul poate vedea ce se poate face și poate cere mai mult!
 - abordarea incrementala se poate transforma uşor într-una « codifică si
repară « (« build and fix »).
-
Planificarea
Principalul risc în utilizarea unui model incremental este de a lucra într-o manierea
“ad-hoc”. Determinarea unui plan de acţiuni este de prima importanţă pentru succesul
abordării incrementale. În faza de analiză preliminară se determină scopul proiectului
şi se încearcă determinarea riscurilor majore ale proiectului, se determină o listă a
cerinţelor şi constrângerilor mai importante, pentru a construi un plan de dezvoltare. Se
stabileşte natura fiecărui increment şi ordinea de construire a incrementelor.

Construirea în paralel a incrementelor: risc

Diferite incremente pot fi construite în paralel de diferite echipe. După începerea fazei
de proiectare a primului increment, echipa de specificare începe specificarea celui de-al
2-lea increment. Riscul este ca cele 2 incremente să nu “se potrivească”. În mod normal,
al 2-lea trebuie să-l includă pe primul. Fiecare increment are părţi comune cu altele. Este
necesară o bună comunicare şi coordonare între echipele care construiesc în paralel
incrementele care au părţi comune (privind implementarea părtţlor comune). Aceste
probleme cresc exponenţial cu numărul de incremente.

2.2.10 Ciclul de viață în Modelul cu prototipuri

Noţiuni generale
Pentru sisteme noi, în mod special dacă ele sunt mari și complexe este puțin
probabil să se construiască o specificație completă, logică şi validă inainte ca sistemul să
fie construit și utilizat. Acest fapt a condus la ideea prototipării. Ideea este de a permite
viitorilor utilizatori să exerseze cu o primă versiune a sistemului, care poate fi obținută
rapid prin tehnici de simulare și/sau de interpretare a specificațiilor. În acest ultim caz,
limbajele logico-funcționale sunt în mod sigur chemate să joace un rol important.
Prototipul este o schiță a viitorului sistem: el nu are performanțele și nu răspunde
exigențelor de calitate ale unui produs finit. Prototipul oferă utilizatorului funcţionalități
(nu în totalitate) ale viitorului sistem și interfața sa. El este dezvoltat într-o manieră
iterativă.
Cerinţele sunt extrase şi validate iterativ prin utilizarea prototipului. La fiecare
iterație specificația sistemului este modificată și detaliată până când prototipul satisface
necesitățile utilizatorilor. Un prototip care este utilizat pentru a desprinde cerințele
viitorilor utilizatori, este o "machetă exploratoare"

Figura 2.14. Ciclul de viață în Modelul cu prototipuri Commented [WU2]: De desenat în ro

 Activitatea de prototipare poate interveni de asemenea în etapa de proiectare,
pentru a experimenta şi compara diferite variante. Astfel de prototipuri se numesc
"machete experimentale".

Figura 2.15. Prototipare în etapa de proiectare

Aceasta este o versiune ciclică a modelului liniar.

Odată ce analiza cerinţelor este îndeplinită şi proiectarea este terminată, procesul de
dezvoltare este pornit.
Odată ce prototipul este creat, este dat consumatorului pentru evaluare
Consumatorul oferă feedback dezvoltatorului care rafinează produsul conform cu
aşteptările consumatorului.
După un număr finit de iteraţii, pachetul final este dat consumatorului. În această
metodologie, software-ul evoluează ca rezultat al schimbului periodic de informaţii dintre
consumator şi dezvoltator. Acesta este modelul cel mai popular din industria IT.
Majoritatea produselor software de succes au fost create folosind acest model,
întrucât este foarte dificil să înţelegi toate cerinţele utilizatorilor dintr-o singură încercare.
Există multe variante ale modelului, din cauza diverselor stilurilor manageriale ale
companiilor. Versiuni noi ale unui produs software apar ca rezultat al modelului cu
prototipuri.
În general prototipul simulează numai câteva aspecte ale atributelor programului
final şi poate fi complet diferit de implementarea finală.
Scopul convenţional al unui prototip este de a permite utilizatorilor de software să
evalueze propunerile dezvoltatorilor încercându-le practic şi nu pe baza descrierilor.
Utilizarea prototipurilor poate fi utilă şi end user-ilor pentru a descrie cerinţe pe care
dezvoltatorii nu le-au considerat, aşadar controlarea prototipului poate fi un factor cheie
în relaţia comercială dintre dezvoltatori şi clienţi. Folosirea prototipurilor are o serie de
beneficii: proiectantul soft şi dezvoltatorul pot obţine feedback de la utilizatori devreme
în ciclul de viaţă. Clientul şi contractorul pot vedea dacă produsul software respectă
cerinţele pe care se construieşte programul soft. De asemenea, oferă informaţii inginerului
soft legate de estimările iniţiale şi de acurateţea lor, acesta putând determina dacă se pot
respecta deadline-urile.
Limbaje folosite Pentru dezvoltarea prototipului

Pentru dezvoltarea prototipului se folosesc limbaje de nivel foarte înalt: Smalltalk,

PROLOG, LISP, SETL şi altele.
În prezent există limbaje şi medii de dezvoltare specializate pentru construirea
prototipurilor.
Astfel de limbaje sunt limbajele de generaţia a 4-a (4GL). Cu toate că se poate
folosi acelaşi limbaj de programare, atât pentru realizarea prototipului cât şi pentru
dezvoltarea aplicaţiei, se recomandă ca prototipul să fie considerat un sistem "închis",
adică să nu fie folosit ca baza pentru dezvoltarea aplicaţiei.
Deoarece:
- prototipul a fost dezvoltat prin modificări succesive, de aceea arhitectura sa
inițială a fost alterată, ceea ce îngreunează întreținerea
- prototipul trebuie să corespundă cerințelor utilizatorilor numai din punct de vedere
funcţional. De aceea, în dezvoltarea sa sunt neglijate aspecte ca: eficienţa,
adaptabilitatea, compatibilitatea şi chiar fiabilitatea[1].

Categorii de utilizare a prototipurilor

Există două mari categorii de utilizare a prototipurilor:

- prototipuri cu aruncare
- prototipuri evolutive

Prototipuri cu aruncare:
Numite şi prototipuri la capătul apropiat. Prototipurile cu aruncare sau rapide se
referă la crearea unui model care va fi până la urmă aruncat în loc să devină o parte
integrată a software-ului final. După ce se termină adunarea cerinţelor preliminare, un
model funcţional simplu al sistemului este construit pentru a arăta vizual utilizatorilor
cum arată cerinţele lor aplicate într-un sistem finalizat. Prototipurile rapide implică
crearea unui model al diferitelor părţi ale sistemului într-o fază incipientă, după o
investigaţie relativ scurtă.
Metoda folosită la construirea modelului este de obicei informală, cel mai
important factor fiind viteza cu care modelul este pus la dispoziţie. Modelul devine apoi
punctul de început de la care utilizatorii reexaminează aşteptările şi clarifică cerinţele.
Apoi, modelul prototip este aruncat şi sistemul este dezvoltat din nou, bazat pe cerinţele
identificate.
Motivul cel mai evident pentru folosirea acestei abordări este că poate fi
îndeplinită repede și dacă utilizatorii primesc un feedback rapid al cerinţelor lor, vor putea
să le schimbe mai devreme în procesul dezvoltării produsului.
Dacă un proiect este schimbat după ce s-a efectuat o muncă semnificativă, orice
schimbare minoră poate cauza eforturi mari pentru a fi implementată, din moment ce
sistemele software pot avea dependenţe.
Viteza este crucială în implementarea unui prototip de aruncat, deoarece cu un
buget limitat de bani şi timp se poate cheltui puţin pe un prototip care nu va fi luat în
considerare[1].
Un alt avantaj este abilitatea de a se construi interfeţe pe care utilizatorii le pot
testa. Interfaţa cu utilizatorul este ceea ce acesta vede ca fiind sistemul şi văzându-l în
faţa sa, îi este mult mai uşor să înţeleagă cum va funcţiona.
 Prototipurile pot fi clasificaţi în funcţie de gradul în care seamănă cu adevăratul
produs ca aparenţă şi interacţiune.
O metodă de a crea un prototip de aruncat cu fidelitate redusă este prototiparea pe
hârtie. Prototipul este implementat cu creionul pe hârtie şi mimează funcţia adevăratului
produs. O altă metodă prin care se pot modela prototipuri de fidelitate crescută este de a
folosi un GUI (Graphic User Interface) în care se crează un prototip care arată ca produsul
dorit dar nu are nici o funcţionalitate[3].

Rezumatul acestui tip de prototipare este următorul:

- scrierea cerinţelor preliminare

- proiectarea prototipului
- utilizatorul foloseşte prototipul şi specifică noile cerinţe
- se repetă paşii b) şi c) până când cerinţele nu se mai modifică
- scrierea cerinţelor finale
- dezvoltarea produselor reale.

Prototipuri evolutive

Prototiparea evolutivă este diferită de cea cu aruncare, întrucât scopul principal este
de a construi un prototip foarte robust într-o manieră structurată şi de a-l rafina constant.
Prototipul evolutiv, atunci când este construit va forma inima noul sistem. Când se
dezvoltă un sistem folosind această metodă, acesta este constant rafinat şi reconstruit.
Tehnica permite echipei să adauge trăsături, sau să facă schimbări care nu ar fi putut fi
concepute în faza de cerinţe şi proiectare.
Pentru ca un sistem să fie folositor, trebuie să evolueze prin folosire în mediul pentru
care a fost proiectat. Un produs nu este niciodată terminat, el se maturizează constant pe
măsură ce mediul de operare se modifică. Prototiparea evolutivă are avantajul că toate
prototipurile sunt sisteme funcţionale. Deşi e posibil să nu aibă toate funcţionalităţile pe
care utilizatorii le-au dorit, ele pot fi folosite ca o bază intermediară până la livrarea
sistemului final [1].
Dezvoltatorii se pot concentra pe dezvoltarea părţilor sistemului pe care le înţeleg, în
loc să lucreze la dezvoltarea întregului produs [2].
Ideea este de a permite viitorilor utilizatori să exerseze cu o primă versiune a
sistemului. Prototipul este o schiță a viitorului sistem, oferă clientului functionalități (nu
în totalitate) ale viitorului sistem și interfața pentru utilizator.
Este dezvoltat într-o manieră iterativă. În fiecare iterație specificația sistemului este
modificată și detaliată până când prototipul satisface necesitățile utilizatorilor.
Un prototip care este utilizat pentru a desprinde cerințele viitorilor utilizatori, este o
"machetă exploratoare". Activitatea de prototipare poate interveni de asemenea în etapa
de proiectare, pentru a experimenta și compara diferite variante. Astfel de prototipuri se
numesc "machete experimentale".
Scopul Modelului Prototip este de a contracara limitările modelului Waterfall,
legate de stabilirea cerințelor.

Avantaje prototipizare

- utilizatorii sunt implicați direct în dezvoltare

 - susține tendința utilizatorilor de a-și modifica cerințele pe parcursul ciclului de
implementare
- este lansat un model funcțional al sistemului - utilizatorii pot înțelege mai bine
modul de funcționare
- erorile pot fi detectate mult mai devreme
- feedback-ul utilizatorului este mai rapid - obținerea de soluții mai bune
- timpul și costurile sunt reduse.

2.2.11 Rational Unified Process (RUP)

Model iterativ folosit de IBM din 2003, Figura. 2.16(a), 2.16(b). Commented [WU3]: De tradus

Figura 2.1(a). Model iterative RUP

RUP- Ingineria funcționalității. Sunt sintetizate necesitățile funcționale.

Are la baza 4 etape:
a) Inception: pentru validarea costurilor și bugetului, studiu de risc, înțelegerea
cerințelor
b) Elaboration: analiza domeniului problemei, arhitectura proiectului este stabilită
c) Construction: construcția sistemului, se obține prima versiune a sistemului
d) Transition: tranziția la sistemul din producție
RUP defineste 6 principii de urmat:
1) dezvoltă software-ul în mod iterativ
2) gestioneaza cerinţele
3) utilizează arhitecturi bazate pe component
4) modelează în mod visual aplicaţiile
5) verifică calitatea software-ului
6) gestionează schimbările în software
Ciclul de dezvoltare al aplicaţiei este descompus în subcicluri, fiecare ciclu este cumpus
din faze.
Fazele sunt:
- iniţializare
- elaborare
- construcţie
- tranziţie

Figura 2.16(b). Etape majore

RUP Inițializare
- un document de viziune
- un model Use-case iniţial (10-20% complet)
- un plan de proiect cuprinzând fazele şi iteraţiile
- o analiză a riscurilor
- un model de business dacă e necesar
- unul sau mai multe prototipuri

RUP Elaborare
- cea mai critică fază a proiectului
- cele mai importante componente ale sistemului sunt dezvoltate acum
- un model use-case (80% complet)
- capturarea cerinţelor suplimentare
- arhitectura generală a sistemului
- un prototip executabil
- modelul de business şi riscurile revizuite
- planul de realizare al proiectului
- un manual preliminar de utilizare (opţional)
RUP Construcție
Restul componentelor nerealizate în faza anterioară construite şi integrate în produs
- toate componentele sunt testate
- rezultatul trebuie sa fie un produs pregatit pentru a fi livrat utilizatorului
- este realizat manualul de utilizare

RUP - Tranziţie
- produsul este instalat\livrat utiliatorului
- utilizatorul testeaza produsul
- defectele sunt raportate şi fixate
- această fază poate fi foarte simpla sau foarte complexă depinzând de tipul produsului
(ex. Aplicaţie desktop, aplicaţie pe mai multe niveluri)

RUP - Iteraţii
- fiecare fază din RUP poate fi descompusă în iteraţii
- avanatajele metodelor iterative
- riscurile sun gestionate mai bine
- schimbările sunt mai uţor de controlat
- calitate mai bună
RUP - Unelte
- Rational Requisite®Pro-- Păstrează întreaga echipă de dezvoltare actualizată și pe
drumul cel bun în timpul procesului de dezvoltare a aplicațiilor, făcând cerințe ușor de
scris, comunicat și schimbat.
- Rational ClearQuest™-- Un produs de gestionare a solicitărilor de schimbare a
cererilor pentru Windows și Web, care permite echipelor de proiect să urmărească și să
gestioneze toate activitățile de schimbare care au loc pe durata ciclului de viață al
dezvoltării.
- Rational Rose 98-- Cel mai important instrument de modelare vizuală din lume pentru
modelarea proceselor de afaceri, analiza cerințelor și proiectarea arhitecturii
componentelor.
- Rational SoDA-- Automatizează producerea documentației pentru întregul proces de
dezvoltare a software-ului, reducând dramatic timpul și costurile documentației.
- Rational Purify®-- Un instrument de verificare a erorilor în timpul executării
programelor de programare a aplicațiilor și a componentelor software în C / C ++; ajută
la detectarea erorilor de memorie.
- Rational Visual Quantify™-- Un avansat instrument de profilare a performanței pentru
programarea aplicațiilor și a dezvoltatorilor de software pentru componente în C ++,
Visual Basic și Java; ajută la eliminarea blocajelor de performanță.
- Rational Visual PureCoverage™ -- Modifică automat zonele de cod care nu sunt
exercitate în timpul testării, astfel încât dezvoltatorii să poată testa bine, eficient și eficient
aplicațiile lor.
- Rational TeamTest-- Creează, întreține și execută teste funcționale automate,
permițându-vă să vă testați cu atenție codul și să determinați dacă software-ul dvs.
îndeplinește cerințele și efectuează conform așteptărilor.
- Rational PerformanceStudio™-- Un instrument ușor de utilizat, precis și scalabil care
măsoară și prezice performanța sistemelor client / server și Web.
- Rational ClearCase®- Instrument de gestionare a configurației software-ului, care
oferă managerilor de proiect puterea de a urmări evoluția fiecărui proiect de dezvoltare
software.

2.3 Instrumente CASE pentru dezvoltarea sistemelor informatice

Proiectarea Sistemelor/Programelor Asistată de Calculator sau cu Ajutorul

Calculatorului (CASE) provine de la următoarele expresii:
Computer Aided Software Engineering
Computer Aided Systems Engineering
Computer Assisted Software Engineering
Computer Assisted Systems Engineering
Toate cele patru construcţii se regăsesc în literatura de specialitate.
Ingineria asistată de calculator (CASE) – instrumente de asistență a ciclulilor de
dezvoltare şi evoluţie software
Prin instrumente CASE înţelegem aplicaţiile software care-i sprijină/ ajută pe
analişti, proiectanţi, programatori, inclusiv personalul de testare şi întreţinere, să
analizeze, să proiecteze, să implementeze (cel puţin parţial), să modifice (extindă),
respectiv să construiască teste pentru sistemele informatice.
 Tendinţa însă este de a se întrebuinţa mai mult systems în loc de software, din
dorinţa de a scoate în relief faptul că prin CASE se pot realiza lucruri de o mai mare
complexitate.
La început s-a pornit de la ideea că şi activităţile de realizare a sistemelor
informatice să se desfăşoare după „o disciplină de tip inginerie", prin reunirea eforturilor
specialiştilor de „găsire a unor tehnici comune de dezvoltare a sistemelor/programelor, a
unor metodologii standard, a unor instrumente ce automatizează lucrul - similare celor
din inginerie".
Problema CASE-ului a devenit foarte importantă la mijlocul anilor 1980, când hardul
s-a extins prin seria PC-urilor, iar reţelele au devenit mai puternice, constituindu-se
sistemele distribuite.
Tehnologia CASE este un domeniu de integrare şi sinteză ce încorporează elemente
din proiectarea asistată de calculator, ingineria programării, proiectarea sistemelor
informatice, baze de date şi alte domenii ale informaticii.
Au fost create astfel o serie de instrumente software pentru asistarea realizării de
produse informatice în scopul uşurării activităţilor de proiectare a SGBD-urilor.
După apariţia CASE-ului, a intervenit un alt acronim pentru a descrie un semn al
schimbării, el fiind - I-CASE, pentru Integrated CASE.
I-CASE se referă la toate aspectele integrării, chiar dacă sistemele sunt deschise sau nu.

Figura 2.17. Tehnologia CASE

Istoric
Evoluţia instrumentelor CASE:
– programarea considerata o “forma de arta” – anii 60
– metode structurate – 1965
– tehnici de modelare a datelor – 1970
– limbaje de generaţia a patra – 1975
– instrumente de proiectare a specificaţiilor software – 1980
– instrumente pentru prototipizarea interfeţei utilizator – 1985
– instrumente pentru generarea automată a codului – 1990
– CASE-uri integrate, CASE-uri orientate obiect – 1995
– Component Software (Java)1996

Prima generaţie CASE

- un instrument pentru o anumită etapa a procesului software

– planificarea strategică (la nivelul sistemelor complexe)
– etapa de analiză
– etapa de proiectare
– generare de cod
Caracteristici:
– oferă interfaţă grafică pentru utilizator
– instrumente de dimensiuni mici, volum mare de date
– generare de cod se referă la definirea datelor (ecrane, rapoarte, definiţii, fragmente de
cod).

A doua generaţie de produse CASE

– aceleaşi facilităţi ca şi din prima generaţie şi în general aceleaşi tipuri de instrumente
– generarea de cod să se realizeze pe main-frame-uri pe care să existe un generator
central de cod şi care să stocheze codul generat într-un depozit
- permit lucrul în echipă pentru elaborarea de proiecte de obicei complexe
- asigură facilităţi de management de proiect
- acestei generaţii îi aparţin CASE-uri care oferă suport pentru întreg ciclul de viaţă
(integratedCASE sau I-CASE)
– oferă suport pentru realizarea proiectelor folosind mai multe metode de analiză şi
proiectare.

Generaţia a treia de produse CASE

– cuprinde CASE-urile ultimei perioade, numite şi medii sau Workbench (colecţie de

instrumente CASE şi de alte componente integrate care asigură suportul pentru
majoritatea tipurilor de interacţiuni între componentele mediului şi între utilizator şi
mediu)
Generaţia a treia de CASE presupune utilizarea acestora în organizaţii elaboratoare de
software şi este generaţia actuală care oferă:
– facilităţi individuale pe PC
– facilităţi la nivel de proiect pe LAN
– facilităţi la nivel de organizat pe mainfram.
 Figura 2.18. Instrumente, medii de lucru, medii de dezvoltare

Figura 2.19. Instrumente CASE şi procesul software

Facilităţi Instrumente CASE

Instrumentele CASE trebuie să asigure, în principal, următoarele facilităţi:

- suport pentru metodele şi tehnicile de analiză şi proiectare concretizat în editoarele
de diagrame şi text
- stocarea datelor ce descriu sistemul în dicţionarul central de date, numit repository
şi regăsirea şi vizualizarea lor prin intermediul browsere-lor
 - verificarea descrierii sistemului din punct de vedere al consistenţei şi
completitudinii
- suport pentru realizarea prototipurilor (limbaje de nivel înalt şi generatoare de
aplicaţii)
- suport pentru conducerea proiectului. Deosebit de utile sunt instrumentele de
planificare şi estimare a timpului şi resurselor necesare realizării sistemului,
precum şi gestiunea versiunilor proiectului
- generarea documentaţiei de realizare a sistemului
- acoperirea întregului ciclu de realizare a sistemelor. Instrumentele CASE trebuie
să asigure nu numai suportul tehnic pentru o anumită etapă, ci să faciliteze
tranziţia dintr-o etapă a ciclului de realizare în alta, în ambele direcţii
- generarea automată a codului de program pornind de la specificaţiile de proiectare.
Codul de program poate fi generat total sau parţial în unul sau mai multe limbaje
- inginerie inversată (Reverse Engineering). Permite revenirea din fazele realizării
sistemelor informatice în fazele de început, operând eventualele modificări care
au intervenit
- adaptabilitate şi extensibilitate. Utilizarea instrumentelor trebuie să poată fi
adaptată la cerinţele specifice ale utilizatorilor şi să permită extinderea cu noi
rutine sau instrumente.

Obiectivul principal al CASE

Punerea în practică a produselor-program de proiectare şi realizare a softului
cu ajutorul calculatorului.
Instrumentele oferite de CASE sunt utilizabile de la faza de definire a cerinţelor
până la întreţinerea fizică a produsului informatic.
Analiza şi proiectarea, bazate pe conceptele şi metodele structurale - sunt
elementele forte ale instrumentelor CASE,
În ultimii ani CASE a acordat atenție sporită analizei, proiectării şi programării
orientate pe obiecte.
Obiectivele urmărite prin utilizarea instrumentelor CASE sunt:
- reducerea timpului şi costului de realizare a sistemelor
- specificarea corectă şi completă a cerinţelor sistemului
- detectarea şi corectarea la timp a erorilor şi a deficienţelor sistemului
- elaborarea şi actualizarea documentaţiei de realizare a sistemului.
Caracteristicile CASE-urilor sunt:

CASE este văzut ca un set de instrumente folosite în procesul de realizare a softului.

Se ştie că acest proces presupune parcurgerea unor faze strâns legate între ele. Din cauza
particularităţilor fiecăreia dintre ele, şi mijloacele de utilizare vor fi altele.
Marea varietate a modurilor de lucru ale utilizatorilor conduce la o multitudine de
instrumente CASE, dintre care unele pot fi pentru grafice, cu o mare diversitate de
operaţiuni specifice, altele urmăresc controlarea listelor multidimensionale, în timp ce o
altă categorie oferă medii de lucru diverse din care utilizatorul poate să aleagă o variantă
anume.
 Simbolurile grafice trebuie să aibă o semnificaţie predefinită. Uneori simpla
legare a unui cerc cu un dreptunghi are un cu totul alt înţeles decât desenul în sine.
In fiecare instrument CASE trebuie să existe un sistem de verificare şi validare, altceva
decât simpla depistare a erorilor. .
CASE, în totalitatea lui, trebuie să aibă o derulare bidirecţională. Nu este de ajuns să
existe o suită de instrumente necesare analizei, proiectării, generării de coduri ale
programelor, toate folosite într-o singură direcţie. O etapă importantă din ciclul de viaţă
al sistemelor o constituie întreţinerea acestora, care necesită prelucrări în sens invers, de
la codurile programelor la reproiectarea sistemelor.
CASE-urile trebuie să fie deschise, oferindu-se astfel posibilitatea interconectării
instrumentelor CASE ale diverşilor furnizori şi să permită condiţii de lucru pentru mai
mulţi utilizatori în acelaşi timp.
Multe instrumente, îndeosebi cele ce lucrează în mediu grafic, necesită unele tipuri de
facilităţi de descompunere.
Instrumentele proiectării conceptuale a bazelor de date şi diagramele fluxurilor de
date sunt cele mai utile când se descriu prelucrările la un nivel superior şi obiectele
implicate, cu o descompunere a lor în mai mulţi paşi, până la nivelul cel mai de jos. în
plus, descompunerile elementare, superioare, cum sunt datele elementare ale unei
diagrame a fluxului de date, trebuie să fie evidenţiate pe nivelurile inferioare, fie automat,
fie în timpul verificării şi validării.
Deplasarea trebuie să fie posibilă, fie pentru trecerile de sus în jos, pe verticală,
ale nivelurilor de descompunere, fie între instrumentele de tip CASE, pe orizontală,
pentru scoaterea în evidenţă a integrării perfecte a acestora.
Automatizarea poate să fie diferită de la un instrument CASE la altul sau de la o etapă
din ciclul de viaţă al sistemelor la alta.
Cele mai multe dintre fazele proceselor de realizare a sistemelor sunt
semiautomate - cum ar fi cerinţa ca utilizatorul să introducă ceva sau să ajute la
normalizarea bazei de date.
Din această cauză CASE-ul este văzut în viitor mai mult ca un mijloc de creştere
a productivităţii, decât ca un sistem automat fără programatori.

Avantaje utilizare CASE

Folosirea sistemelor CASE este motivată în principal de următoarele avantaje:
- reducerea complexităţii logicii de descriere a sistemului
- posibilitatea de a alege dintre mai multe variante de proiectare
- creşterea vitezei de realizare a sistemelor
- realizarea succesivă a componentelor unui sistem
- creşterea integrării
- consolidarea disciplinei de proiectare
- oferirea unei interfeţe de integrare
- folosirea depozitelor modularizate
Automatizare activităţi:
- editoare grafice pentru dezvoltarea modelului sistemului
- dicţionare de date pentru gestionarea entităţilor proiectării
- constructor GUI pentru construirea interfeţei utilizator
- debugger-e pentru a sprijini găsirea erorilor în program
- traducătoare (translator) automate pentru generare de noi versiuni de
program.
Literatura Commented [WU4]: De făcut referință la V. Grecul de pe
V. Grecul. Проектирование информационных систем. www.intui.ru (de concretizat intuit.ru
1. Instrumente CASE Ciprian Dobre ciprian.dobre@cs.pub.ro
Universitatea Politehnica Bucuresti - Facultatea de Automatica si Calculatoare.
http://andrei.clubcisco.ro/cursuri/f/f-sym/4idp/3_Intrumente_CASE.pdf
2. Instrumente CASE. Curs nr. 7. Erwin data modeler, www.seap.usv.ro
TEMA 3

Procesele ciclului de viață

Proces conform standardului ISO/IEC 12207. Procese primare. Procesele

organizaționale. procese auxiliare. Procesele conform standardului ISO 15288

Figura 3.1. Ce este process?

3.1. Noțiunea de Proces conform cu standardul ISO/IEC 12207

Consecutivitatea fixată a evenimentelor, realizată printr-un grup de activităţi legate

logic, care utilizează resursele organizaţiei pentru obţinerea rezultatului la realizarea
scopurilor organizaţiei.
În conformitate cu standardul ISO/IEC 12207: toate Procesele CV
Se âmpart în 3 grupe:
5 procese principale (primare),
8 procese auxiliare, și
4 Procese organizaționale.
În conformitate cu standardul ISO/IEC 12207:
Procesele organizaționale – includ patru procese realizate de către o organizaţie, care
stabilește şi pune în aplicare o structură de bază formată din procesele asociate ciclului
de viaţă şi de personal şi care are grijă de îmbunătăţirea continuă a acestei structurii şi a
proceselor.
Procese primare – constau din cinci procese, care formează partea de bază a ciclului de
viață a produselor program. Partea primară este cea care inițiază și realizează dezvoltarea,
exploatarea sau menținerea produsului program. Componentele ei sunt achizitorul,
furnizorul, dezvoltatorul, exploatatorul și menținătorul produsului program.
Procesele auxiliare – includ opt procese, care susțin executarea altor procese cu scopul
garantării succesului și calității finale. Un proces auxiliar este lansat în execuție la
necesitate de un alt proces.

3.1.1. Procese primare

- achiziție – definește activitățile de achizitor, organizaţia care achiziţionează un sistem,

un PP sau un serviciu soft
- aprovizionare (livrare) – defineşte activităţile de furnizor, organizaţie care livrează
sistemul, PP sau prestează serviciul solicitat de achizitor
- elaborare/dezvoltare - defineşte activităţile de dezvoltator, organizaţia care defineşte şi
dezvoltă produsul program
- exploatare - defineşte activităţile operatorului – organizaţie, care oferă servicii de
operare a unui sistem informatic în mediul său pentru utilizatorii săi.
- întreţinere (mentenață) - defineşte activităţile de mentenanţă a organizaţiei care oferă
serviciul de menţinere a PP, de gestionare a modificărilor pentru a-l menţine actualizat şi
operaţional. Acest proces include activitățile de migrare şi de retragere din uz a PP.

Tabelul 3.1. Conținutul proceselor primare

Procese organizaționale

Managmentul Creare infrastructuă Perfecționarea Școlarizare

proiectelor a proiectului CV

Procese primare

Achiziția livrarea Elaborarea

Exploatarea Mentenanța

Procesele auxiliare

Documentarea Asigurarea Soluționarea

Managementul
calității configurației problemelor

Verificarea
Validarea Revizuirea Auditul
produselor
produselor comună
 Tabelul 3.1. (continuare)
Proces Acțiuni Intrare Ieșire
(executor)
1 2 3 4
Achiziție  Pregătirea  Decizia privind  Studiu de fezbilitate
(achizator) cererii de oferte lansarea lucrărilor de privind oportunitatea
(licitație) implementare a SI implementării
 Pregătirea și  Rezultatele  Sarcina tehnică
actualizarea analizai activității pentru crearea SI
contractului achizitorului  Contract de
 Monitorizarea  Rezultatele furnizare/creare a SI
furnizorului analizei pieței  Actele de primire a
 Acceptarea și produselor program etapelor lucrărilor
completarea  Planul de  Actul testărilor de
furnizare/dezvoltare primire/predare
 Test complex al
SI

Furnizare  Inițierea  Caietul de sarcini  Decizia de

(dezvoltatorul/  Pregătirea  Decizia participare
furnizorul) răspunsului la conducerii de  Oferta
cererea de oferte participare comercială/cerere de
 Pregătirea  Rezultatele participare la licitație
contractului licitației  Contract de
 Planificarea  Sarcina tehnică furnizare/crearea SI
executării  Planul de  Planul de
 Executare și management al management al
control proiectului proiectului
 Verificare și  SI elaborat și  Realizare/corectarea
evaluare documentat  Actul testărilor de
 Furnizarea SI primire/predare

Dezvoltare  Pregătirea  ST pentru  Modelul utilizat al

(dezvoltatorul)  Analiza elaborarea sistemului ciclului de viață,
cerințelor  ST pentru standardele de
 Proiectarea elaborarea dezvoltare
arhitecturii sistemului, modelul  Planul lucrărilor
softului ciclului de viață  Conținutul
 Proiectarea de  Subsistemele SI subsistemelor,
detaliu a softului  Specificațiile componetele tehnice
 Scrierea componentelor soft  Specificațiile
programelor și  Arhitectura cerințelor referitor la
testarea produselor program componentele program
 Integrarea  Materiale  Cinținutul
modulelor proiectării de detaliu componentelor
 Testarea de a produselor program, interfețele
calificare program BD, planul de integrare
 Integrarea de  Planul de  Proiectul BD,
sistem integrare, testele
 Tabelul 3.1. (continuare)
1 2 3 4
 Testarea de  Arhitectura SI,  specificațiile
sistem produselor, interfețelor
 Instalarea documentația SI, componentelor
softului testele. program, cerințele
Acceptarea pentu teste
menținerii softului  Codul modulelor
program, actele
testărilor unitare
 Evaluarea
conformității setului de
programe cerințelor ST
Evaluarea conformității
produsului program,
BD, echipamentelor
tehnice și setului de
documente cerințelor
ST

3.1.2. Procesele auxiliare

- documentarea – înregistrare a inf. produse de un CV

- managementul configurației - activitățile de gestiune a configurației
- asigurarea calității - activitățile de asigurare obiectivă a conformității produselor
program și proceselor cu specificațiile lor
- verificarea - activitățile pentru verificarea produselor program
- validarea - defineşte activităţile pentru atestarea PP
- revizuirea comună - activităţile de evaluare a stării şi produselor unei activități
- auditarea - activităţile pentru stabilirea conformităţii cu cerinţele, planurile şi clauzele
contractuale
- soluționarea problemelor - analizarea şi îndepărtarea problemelor.

Procesul Asigurarea calității (quality assurance process) presupune garanții că sunt

respectate cerințele conform caietului de sarcini la elaborarea S.I.
Procese de documentare (documentation process) – descrierea formalizată a informației
elaborată pe parcursul creării SI
Configuration management process – presupune aplicarea procedurilor administrative
și tehnice pe tot parcursul C.V. Soft pentru a controla starea componentelor, managmentul
modificărilor, descrierea și întocmirea rapoartelor despre starea componentelor și
solocitărilor de modificare componente, asigurarea integrității și compatibilității
componentelor soft, managmenul păstrare și livrare soft.
Processe de verificare (verification process) constă în determinarea faptului că produsul
program satisface în totalitate cerințelor sau condițiilor determinate de acțiunea
precedentă.
Procesul de validare (validation process) presupune constatarea că produsul corespunde
în totalitate cu cerințele înaintate pentru a realiza un funcțional concret.
Procesul de revizuire comună este conceput pentru a evalua starea proiectului și a
software-ului creat atunci când realizează aceste activități (acțiuni).
Procesul de audit este o definiție a respectării cerințelor, planurilor și condițiilor
contractului.
Procesul de rezolvare a problemei implică analiza și rezolvarea problemelor (inclusiv
neconcordanțele detectate) indiferent de originea sau sursa lor.

3.1.3 Procesele conform ISO 15288

- procese contractuale
- procesele întreprinderii
- procesele proiectului
- procesele tehnice
- procese speciale
Procese contractuale:
- achiziție (soluții interne sau ale unui furnizor extern)
- furnizare (soluții interne sau ale unui furnizor extern).
Procesele întreprinderii:
- managementul mediului extern
- management investițional
- managementul ciclului de viață a produselor program
- managementul resurselor
- managementul calității.
Procesele proiectului:
- planificarea proiectului
- estimarea proiectului
- controlul proiectului
- administrarea riscurilor
- managementul configurației
- managementul fluxurilor informaționale
- adoptarea deciziilor.
Procesele tehnice:
- identificarea cerințelor
- analiza cerințelor
- elaborarea arhitecturii
- implementarea
- integrarea
- verificare
- transmiterea către beneficiar
- validarea (atestarea)
- exploatarea
- menținerea
- retragerea din uz.
Procese speciale:
- determinarea și realizarea legăturilor reieșind din sarcini și scopuri.
Tabelul 3.2. Etapele creării sistemelor conform ISO/IEC 15288
TEMA 4

Standarde pentru modelarea activității social economice

Principii Fundamentale. I. Standarde cadru. II. Metamodele/Concepte. III. Standarde

Proiectare, Limbaje, Metode. IV. Business Process Choreography. V. Formalismele
reprezentarii Software. IV. Canale de comunicare, Semantica mesajelor, Modele de
inregistrare, Dicţionare conceptuale.

Principii Fundamentale Enterprise Models (EM)

Datorită complexității și naturii multiple a organizațiilor de întreprinderi și în

special a organizațiilor industriale, cadrele de modelare a întreprinderilor trebuie să
respecte următoarele principii:

Principiul # 2
Mai multe Puncte Principiul # 3
Principiul # 1
de vedere la
modelare Trei tipuri
Natura pluralistă a
fundamentale
modelelor
De fluxuri

Principii
fundamentale de
modelare a Principiul # 6
întreprinderilor
Principiul # 4 Conceptul de
modelare pe
Procese versus niveluri
agenți Principiul # 5
Sincronizarea
proceselor de
afaceri (BP)

Figura 4.1. Principii fundamentale în modelarea întreprinderilor

Principiul # 1: Natura plurală a modelelor de întreprindere

Aceasta înseamnă că nu există un "model de întreprindere". Există modele de

întreprindere. Într-adevăr, orice entitate comercială, fie ea o fabrică de producție, un
departament de cercetare-dezvoltare, o filială a unei companii, un lanț de aprovizionare
sau o întreprindere virtuală, este atât de complexă încât este imposibil să o reprezinte
printr-un singur model exprimat într-o singură limbă. Mai multe modele vor fi necesare
și, într-adevăr, modelul de întreprindere este o asamblare de submodele, fiecare
reprezentând câteva aspecte specifice.

Principiul # 2: Conceptul de vizualizări de modelare

Conceptul de vizualizare sau punct de vedere al modelării este un mecanism care

permite să se concentreze asupra unor aspecte ale unui sistem, în timp ce înlătură pe alții
să gestioneze complexitatea structurală. Un cadru de modelare va fi puternic, complet și
consistent dacă va oferi un set minim de opinii care nu se suprapun, pentru a acoperi toate
aspectele esențiale ale sistemului.

Figura 4.2. Principiile 1 și 2

Principiul # 3: Trei tipuri fundamentale de fluxuri

Există trei tipuri fundamentale de fluxuri care circulă în cadrul sau între orice tip
de întreprinderi (cu excepția fluxurilor financiare):
- fluxuri de materiale (realizate din obiecte fizice, cum ar fi materii prime, piese
semifabricate, produse, componente, instrumente ...)
- fluxuri de informații (realizate din obiecte de informare și de decizie, cum ar fi comenzi,
documente, date, fișiere informatice, e-mailuri, apeluri telefonice ...)
- fluxuri de control (sau flux de lucru, adică secvențe de execuție logică a sarcinilor).

Principiul # 4: Procese față de agenți

La un nivel macro, orice întreprindere poate fi privită ca o colecție mare de:

- procese simultane (procese de afaceri) executate pentru a atinge obiectivele de afaceri
și pentru a concura pentru resurse, pe de o parte, și -
- agenți de interacțiune sau entități funcționale (adică, resurse umane sau tehnice) care
execută pe de altă parte.
Arta managementului este aceea de a se asigura că, în fine, agenții (adică cei care
efectuează acțiuni) execută procesele într-un mod eficient, eficient și economic pentru a
atinge obiectivele de afaceri.

Principiul # 5: Sincronizarea proceselor de afaceri

Există trei tipuri fundamentale de sincronizare a proceselor de afaceri:

- sincronizarea bazată pe evenimente: evenimentele sub formă de mesaje, cereri, ordine
sau cronometre pot fi generate de un singur proces și folosite pentru a declanșa alte
procese (de exemplu, EV2 în Figura 2)
- sincronizarea bazată pe obiect: Un pas într-un flux de control al procesului poate
necesita disponibilitatea obiectelor produse de unul sau mai mulți pași de diferite procese
- sincronizarea bazată pe resurse: Executarea unui pas într-un proces poate necesita
disponibilitatea unor resurse care pot fi, de asemenea, necesare printr-un alt pas dintr-un
alt proces (acesta este un conflict de resurse care trebuie rezolvat prin intermediul
regulilor de prioritate sau un mecanism de soluționare a conflictelor).

Principiul # 6: Conceptul de niveluri de modelare

Modelele de întreprindere pot fi dezvoltate la trei niveluri generice, așa cum au

fost propuse în CIMOSA, GERAM și ISO 14258 (1998). Acestea sunt:
- definirea cerințelor: utilizat pentru a reprezenta "vocea utilizatorilor", adică ceea
ce este necesar, exprimat într-un mod detaliat și lipsit de ambiguitate într-un limbaj
orientat către utilizator sau descriptiv
- specificație de proiectare: Se utilizează pentru a specifica în mod oficial una sau
mai multe soluții care îndeplinesc setul de cerințe, pentru a analiza proprietățile acestora
și pentru a selecta cel mai bun. Aceste modele sunt exprimate printr-un limbaj executabil
formal și computerizat (predispus la validarea modelului, analiza performanței sau
simularea sistemului)
- descrierea implementării: Este folosit pentru a preciza în detaliu soluția de
implementare ținând cont de constrângerile tehnice fizice. Modelele operaționale sunt
definite la acest nivel.
Literatura ultimilor ani este inundată de articole orientate spre identificarea unui
metamodel și unificarea conceptelor generale valabile pentru modelarea întreprinderii.
Iată doar câteva inițiative:
- propuneri de unificare a modelelor ERP (PURDUE, BAAN, SAP) [Dalal, 2004]
– construirea unei baze teoretice unice, necesitatea introducerii elementelor de QS
(Quality of Service), perspective multiple care să include şi perspectiva economică
- Object Process Metodology [Soderborg, 2003] - obiectele (ce?) şi procesele
(cum?) sunt primitive de modelare cu importanţă egală, dar un proces nu poate
exista decât dacă transformă un anumit obiect. Metodologia introduce un nou
formalism grafic
- Levi&Arsanjani [Levi, 2002] încearcă definirea unei metodologii de armonizare
a arhitecturii afacerii cu cea software, pornind de la concepte organizaţionale
precum: entităţi de întreprindere, obiective, procese, reguli economice
- Creţu [Creţu, 2005] – în respectivul articol propune modelarea întreprinderii
pornind de la o arhitectură SOA (Service Oriented Architecture) şi un metamodel,
ce extinde UML, cu următoarele stereotipuri: resurse, produs, proces, operaţii,
reguli (şi mecanism de priorităţi), roluri (actori), context (obiective şi set de reguli)
- Marshall [Marshall, 2000] defineşte un metamodel şi extensii UML (stereotipuri)
pentru conceptele fundamentale: scop, proces, entitate, organizaţie
- Eriksson şi Penker [Eriksson, 2000] definesc un metamodel UML ce descrie relaţii
între următoarele concepte de modelare: proces economic (activităţi executate într-
o anumită ordine, dependente de anumite condiţii şi evenimente), activităţi (paşi ai
procesului), eveniment (activează un proces sau este generat de acesta), resurse,
scop, reguli economice
 - Metamodelul olandez [Jokers, 2003] - o abordare ce constă în definirea de
concepte general valabile pentru a descrie aspecte ale unui sistem, precum structura,
comportamentul şi informaţiile, pentru trei perspective de modelare preluate de la
standardul ISO 10746 (modelul economic, aplicaţii, tehnologii).

Fără standarde nu vom obţine interoperabilitate” [Kosanke, ”Standardisation in

Interoperability” IMS Workshop Zürich, November 15/16, 2007]. Astfel, activitatea
de standardizare, din ultimii ani, ce se adresează modelării întreprinderii, urmăreşte
trei direcţii principale de acţiune:
- elaborarea de limbaje pentru descrierea şi execuţia proceselor economice
- elaborarea de dicţionare e-business (Ontologia)
- concepte şi metamodele economice, într-o manieră independentă de un anumit
limbaj.
DA
F, M

ISO 14258
ISO 15704
GA

ISO19440
, TO

ISO15414
AF

BPDM,
, FE

Profile for EDOC

471

I. Concepte / Metamodele
E1
IEE

Limbaje
Metode
46,

ISO 10303/11
uri

DFD
107

ISO 15909
r k-

IDEF
ISO

UEML, XML,
wo

UML
BPMN
me

07

ebXML-BPSS
122
Fra

II. Proiectare/ Modelare

ISO
V.
88,

UEML, ebXML, BPML

152

Coregrafie procese
BPEL&BPEL4WS
EC

XPDL, ISO 18629

O/I
S
9, I

III. Formalizme de Reprezemtare software

943
O1
, IS

Semantica mesajelor
AN

Registre modele Dicționare concepte

Comunicația EDIFACT, ASICUDA,
HM

ROSETTANET edXML ROSETTANET

HTTP ISO 15531-MANDATE
C

UOOI ISO 18629-PSL

RMI
ZA

ISO 16668-BSR MOF-CWR OMG-SBVR

SOAP ISO 10303-STEP OMG-SBVR Mesagerie
CORBA-IOP

Figura 4.3. Piramida standardelor pentru modelarea întreprinderi

Preluat și actualizat din - Enterprise Engineering - A New Organizational Discipline. Liviu-

Gabriel CREŢU file:///C:/Users/User/Desktop/Cretu_Liviu_IE_Aug2006.pdf (1)

1 Standarde cadru (Framework-uri)

Framework - O structură esențială de susținere a unei clădiri, a unui vehicul sau a unui
obiect.
Cuvântul englez framework definește, în termeni generali, un ansamblu standardizat
de concepte, practici și criterii pentru a se aplica asupra unui tip particular....
Cadrul Zachman:
 În 1997, John A. Zachman, a propus o metodă de conceptualizare a elementelor
implicate în construirea arhitecturii oricărui sistem informatic, metodă care poartă
denumirea de cadru de lucru Zachman (Zachman Framework). El a evidențiat faptul că
proiectarea unui sistem informatic trebuie privită din mai multe puncte de vedere şi
realizată în mai multe etape, pentru specificarea fiecăreia dintre acestea fiind necesare
diagrame şi documentație specifică.
Cadrul Zachman este o ontologie a întreprinderii și este o structură fundamentală
pentru Enterprise Architecture, care oferă un mod formal și structurat de vizualizare și
definirea unei întreprinderi.
Ontologia este o schemă de clasificare de două dimensiuni care reflectă intersecția
dintre două clasificări istorice. Primele sunt interogative primitive: Ce, Cum, Când, Cine,
Unde, și Dece. Cea de a doua este o derivată din conceptul filosofic de reificare,
transformarea unei idei abstracte în relații dintre obiecte concrete (REIFICÁRE (după fr.
réification; de la lat. res „lucru”) s. f. (FILOZ.) Proces în cursul căruia relațiile sociale îmbracă forma
unor relații obiectuale, iar omul însuși devine din subiect (agent conștient) al proceselor sociale obiectul
acestora, asemenea unui lucru. Conceptul a fost formulat de G. Lukács și mai ales de Th. Adorno.).
Transformările de reificare Zachman sunt: Identificarea, definirea, Reprezentare,
Specificatie, Configurare și Relații.
Cadrul Zachman nu este o metodologie în care aceasta nu implică nicio metodă
specifică sau proces de colectare, gestionare, sau folosind informațiile pe care o descrie.
Mai degrabă, este o ontologie prin care o schemă de organizare a unor artefacte
arhitecturale (cu alte cuvinte, documente de proiectare, caietul de sarcini, și modele) este
folosit pentru a lua în considerare atât obiectivele artefact (de exemplu, proprietar de
afaceri și constructor) cât și anumite probleme (de exemplu, date și funcționalitate).
Acest cadru este explicat ca, de exemplu:
- un cadru de organizare si analiza a datelor
- un cadru pentru arhitectura de întreprindere
- un sistem de clasificare, sau schema de clasificare
- o matrice, de multe ori într-un format de matrice 6x6
- un model bidimensional sau un model analitic
- o schemă bidimensională, folosită pentru a organiza reprezentările detaliate ale
întreprinderii.
 Figura 4.4. Modelul Zchman (http://www.ia.ase.ro/Sie/SIE-4-2013.pdf)

Cadrul Zachman rezumă o colecție de perspective implicate în construcția arhitecturii

de întreprindere. Aceste perspective sunt reprezentate într-o matrice bidimensională, care
definește de-a lungul rândurilor tipul de părț interesate și de-a lungul coloanelor -
aspectele arhitecturii. Cadrul nu definește o metodologie pentru o arhitectura. Mai
degrabă, matricea este un șablon care trebuie să fie completat de obiectivele / norme,
procese, material, roluri, locații, și evenimentele solicitate în mod specific de către
organizație. Modelare în continuare prin mapare între coloane în cadrul framework-ului
identifică lacunele în stare documentată a organizației.

Cadrul ISO 19439:2006

Acest standard a fost revizuit și confirmat ultima dată în 2015. Prin urmare, această
versiune rămâne actuală. (SO 19439: 2006 specifică un cadru conform cu cerințele ISO
15704, care servește drept bază comună pentru identificarea și coordonarea dezvoltării
standardelor pentru modelarea întreprinderilor, subliniind, însă fără a se limita la,
producția integrată de calculator. baza pentru standarde suplimentare pentru dezvoltarea
de modele care să fie enactabile pe calculator și care să permită sprijin decizional bazat
pe modele de procese bazate pe procese de afaceri, care să conducă la funcționarea,
monitorizarea și controlul bazat pe modele).
Cadru ISO 19439 dorește să ofere o "bază conceptuală unificată pentru modelul bazat
pe ingineria întreprinderii care permite coerență, convergența și interoperabilitatea
diferitelor metodologii de modelare și instrumente de sprijin. Cadrul nu cuprinde procese
metodologice, este neutru în acest sens".
 Figura 4.5. Trei dimensiuni pentru modelare Întreprinderii Cadru ISO 19439
Acest standard specifică un cadru, care "servește ca o bază comună pentru a
identifica și de a coordona dezvoltarea standardelor pentru modelarea întreprinderilor, dar
nu se limitează la, producție integrată cu procese de calcul. De asemenea, servește ca bază
pentru standardele suplimentare pentru dezvoltarea unor modele care vor fi suportate de
calculator și permite modelului bazat pe suport decizional de conducere și operare să fie
baza pentru modelul de monitorizare și control ".
ISO 19439 definește trei dimensiuni pentru modelare Întreprinderii:
- Faza de Modele entrepriză: "Fazele Modelului întreprinderii se bazează pe ideea că
modelele de întreprinderi au un ciclu de viata care este legat de ciclul de viață al entității
modelate. Fazele definite în standardul sunt: Identificarea domeniu, Definiție Concept,
Definirea Cerintelor, Specificația de Proiectare, Descrierea Implementării,
Operațiunea de domeniu, Dezafectarea Definiției"
- Dimensiunea punctelor de vedere: ". Se bazează pe ideea că atât modelatori de
companie și utilizatorii pot filtra observațiile sale din lumea reală prin vizualizări
distincte. Punctele de vedere predefinite sunt: Function View, Information View,
Resource View, Organization View/Decision View".
- Dimensiunea generităților: ". Aceasta definește dimensiunea de la concepte de modele
generale la particulare. Standardul definește trei niveluri de genericitate: ”Generic Level,
Partial Level, Particular Level".
 Cadrul ISO/IEC 15288

ISO / IEC 15288 este un standard al sistemelor inginereşti care acoperă procesele și
etapele ciclului de viață. Planificarea inițială pentru standardul 15288 ISO / IEC: 2002
(E) a început în 1994, atunci când necesitatea unui cadru comun pentru procese ale
sistemelor inginereşti a fost recunoscută. Standardul MIL acceptat anterior STD 499A
(1969) a fost anulat, după o notă de la SECDEF, care interzice utilizarea celor mai multe
standarde militare ale Statelor Unite ale Americii fără o derogare. Prima ediție a fost
emisă la data de 1 noiembrie 2002. Stuart Arnold a fost editor și Harold Lawson a fost
arhitectul a standardului. În 2004 acest standard a fost adoptat ca IEEE 15288.

Figura 4.6. Procesele ciclului de viață standard Vizualizare: Prezentare generală

https://buildsecurityin.us-cert.gov/swa/process-view/overview

Standardul definește procesele împărțite în patru categorii:

- tehnic
- proiectul
- acordul
- întreprindere
Fiecare proces este definit printr-un scop, rezultate, și activități. ISO 15288
cuprinde 25 de procese care au 123 de rezultate obținute din 403 activități. Exemple ale
etapelor ciclului de viață, descrise în document sunt: concept, dezvoltare, producție,
utilizare, suport, și de pensionare.
- cerințe părților interesate de proces Definition (clauza 6.4.1)
- cerințe de analiză de proces (clauza 6.4.2)
- procesul de proiectare de arhitectură (clauza 6.4.3)
- procesul de implementare (clauza 6.4.4)
- procesul de integrare (clauza 6.4.5)
 - procesul de verificare (clauza 6.4.6)
- proces de tranziție (clauza 6.4.7)
- procesul de validare (clauza 6.4.8)
- procesul de operare (clauza 6.4.9)
- procesul de întreținere (clauza 6.4.10)
- procesul de eliminare (clauza 6.4.11)

Cadrul ISO/IEC 10746-3:2009

Tehnologia informației - model de referință - prelucrare distribuită deschisă: Arhitectura

ISO / IEC 10746 oferă un cadru de coordonare pentru standardizarea procesării
distribuite deschisă (ODP - open distributed processing). Această susține independența
de distribuție, de portabilitate, platformă si tehnologie. Aceasta stabilește un cadru
arhitectural de întreprindere pentru specificarea sistemelor ODP.
ISO / IEC 10746 definește noțiunile esențiale necesare pentru a specifica sisteme de
prelucrare distribuite deschise din cinci puncte de vedere prescrise. Acesta oferă un cadru
bine dezvoltat pentru structurarea specificației pentru scară largă a sistemelor distribuite.
Cadrul de specificație furnizat de ISO / IEC 10746 pentru sistem are patru elemente
fundamentale:
- o abordare de modelare obiectuala pentru specificația sistemului
- specificarea unui sistem în ceea ce privește caietul de sarcini distincte, dar
interdependente de opinie
- definirea unei infrastructuri de sistem, care ar asigura furnizarea
transparentă de distribuție pentru aplicații de sistem
- un cadru pentru evaluarea sistemului la conformitate.

Figura 4.7. Modelul de vizualizare RM-ODP, care oferă cinci puncte de vedere
generice și complementare asupra sistemului și a mediului său

ISO / IEC 10746-3: 2009 precizează caracteristicile necesare care califică procesarea
distribuită ca fiind deschisă, adică constrângerile la care trebuie să se conformeze
standardele de ODP. Acesta utilizează tehnici descriptive la ISO / IEC 10746-2 pentru a
defini cinci puncte de vedere ISO / IEC 10746. Aceste puncte de vedere sunt capitol
componente ale caietului de sarcini al unui întreg sistem, creat pentru a reuni piese
specifice de informații relevante pentru unele părți interesate sau domeniu de interes. ISO
/ IEC 10746-3: 2009 definește, de asemenea o taxonomie pentru funcții și structuri pentru
a realiza transparenţa de distribuție.
Cadrul IEEE 1471

IEEE 1471 este un standard IEEE înlocuit, pentru a descrie arhitectura unui "sistem
software intensiv", de asemenea, cunoscut sub numele de arhitectura software.
A fost mult timp recunoscut faptul ca "arhitectura" are o puternică influență asupra
ciclului de viață a unui sistem. Cu toate acestea, până relativ recent, probleme de hardware
au avut tendința de a domina gândirea arhitecturala, și aspectele software, atunci când au
fost luate in consideratie, au fost adesea primele compromise sub presiunea de dezvoltare.
IEEE 1471 a fost creat pentru a oferi o bază pentru gândire despre arhitectura sistemelor
software intensive.
Contribuțiile IEEE 1471 pot fi rezumate după cum urmează:
Acesta oferă definiții și un meta-model pentru descrierea arhitecturii.
Aceasta afirmă că o arhitectura ar trebui să abordeze preocupările părților
interesate dintr-un sistem.
Se afirmă că descrierile de arhitectura sunt în mod inerent multi-view, nu single-view,care
surprinde în mod adecvat toate preocupările părților interesate.
Acesta separă noțiunea de view din viewpoint, în cazul în care un punct de vedere
identifică setul de preocupări și reprezentări / tehnici de modelare, etc. folosit pentru a
descrie arhitectura care abordează aceste preocupări și un view este rezultatul aplicării
unui viewpoint la un anumit sistem.
Acesta stabilește cerințele de conținut pentru descrieri arhitecturală și ideea că o
descriere arhitecturală corecta are o corespondență 1-la-1 între puncte de vedere sale și
opiniile sale.
Acesta oferă îndrumări pentru captarea raţională a arhitecturii și identificarea
neconcordanțelor / problemelor nerezolvate între punctele de vedere în cadrul descrierii
unei arhitecturi.
IEEE 1471 prevede anexe informative care se referă la conceptele sale ca fiind concepte
de arhitectura în alte standarde, inclusiv RM-ODP și IEEE 12207.
Conform IEEE 1471 o descriere arhitecturală poate fi utilizată pentru următoarele:
- exprimarea sistemului și evoluția sa
- comunicarea între părțile interesate de sistem
- evaluarea și compararea arhitecturi în mod coerent
- planificarea, gestionarea și executarea activităților de dezvoltare a sistemului
- exprimarea caracteristicilor persistente și principiile de susținere a unui sistem
pentru a ghida o schimbare acceptabilă.

Cadrul Federal enterprise architecture framework (FEAF)

O arhitectură de întreprindere federală (FEA) este arhitectura de întreprindere a unui

guvern federal. Acesta oferă o abordare comună pentru integrarea strategică, afaceri și
management tehnologic, ca parte a structurii organizaționale și îmbunătățirea
performanțelor. Cea mai familiara FEA este arhitectura de întreprindere de guvernul
federal al Statelor Unite, Statele Unite "Federal Enterprise Architecture" (FEA) și SUA
corespunzător "Cadrul Federal Enterprise Architecture" (FEAF).

Figura 4.8. Metodologia de planificare colaborativă (CPM)

(29 ianuarie 2013. Cadrul federal pentru arhitectura întreprinderilor Versiunea 2)
Modelul consolidat de referință al cadrului Arhitectural Enterprise (Federal
FEAF) echipează OMB și agențiile federale cu un limbaj comun și un cadru pentru a
descrie și analiza investițiilor. Acesta constă dintr-un set de modele de referinţa
interdependente concepute pentru a facilita analiza eco-agențiilor și identificarea
investițiilor repetitive, lacunele și oportunități de colaborare în cadrul și între agenții.
Colectiv, modelele de referință cuprind un cadru pentru a descrie elemente
importante ale operațiunilor unei agenții federale într-o manieră comună și coerentă. Prin
utilizarea FEAF și vocabularul ei, portofolii IT pot fi mai bine gestionate și efectul de
levier în cadrul Guvernului federal, consolidarea colaborării și în cele din urmă
transformarea guvernului federal.
În întreprindere FEA, segmentul, și arhitectura soluție oferă diferite perspective
de afaceri prin varierea nivelului de detaliere și la abordarea preocupărilor legate, dar
distincte. Așa cum întreprinderile s-au organizat ierarhic, astfel încât sunt puncte de
vedere diferite oferite de fiecare tip de arhitectură. Federal Enterprise Architecture
Practice Guidance (2006) a definit trei tipuri de arhitectura:
- Arhitectura Enterprise
- Arhitectura Segment
- Arhitectura Soluției
 Figura 4.9. Model de referință consolidat
(January 29, 2013. Federal Enterprise Architecture Framework. Version 2)

FEA este construită folosind un set de modele de referință care dezvoltă o

taxonomie și ontologie comună pentru a descrie resurse IT. Modele de referință FEA II
inclus următoarele:
- Performanță de referință model (PRM)
- Model de referință de afaceri (BRM)
- Model de referință de date (DRM)
- Model de referință de aplicare (ARM)
- Infrastructura de referință model (IRM)
- Securitate model de referință (SRM)

Figura 4.10. Rolul principiilor arhitecturii. (Arhitectura Federală a Întreprinderilor,

Consilier Chief Information Officer, Versiunea 1.0, februarie 2001)
http://www.gao.gov/assets/590/588407.pdf

Cadrul arhitectural al grupului deschis (TOGAF)

Open Group Architecture Framework (TOGAF) este un cadru pentru arhitectura de

întreprindere, care oferă o abordare pentru proiectarea, planificarea, implementarea, și
reglementează arhitectura tehnologiei informației întreprinderii. TOGAF a fost o marcă
înregistrată de The Open Group în Statele Unite și în alte țări din 2011.
TOGAF este o abordare la nivel înalt pentru a proiecta. Aceasta este de obicei
modelată la patru niveluri: de afaceri, aplicații, date și tehnologie. Se bazează foarte mult
pe modularizare, standardizarea, tehnologii și produse deja existente.

Figura 4.11. Exemple de etape de fază

http://www.opengroup.org/public/member/proceedings/q312/togaf_intro_weisman.pdf

TOGAF reprezintă un set de instrumente care pot fi utilizate pentru dezvoltarea

unei game largi de diferite arhitecturi. Este construit pentru a:
- descrie o metodă pentru definirea unui sistem de informare în ceea ce privește un
set de blocuri de construcție
- arată cum blocurile se potrivesc
- conține un set de instrumente
- oferă un vocabular comun
- include o listă a standardelor recomandate
- include o listă de produse conforme, care poate fi folosit pentru a pune în aplicare
blocul de construcție
TOGAF se bazează pe patru domenii interdependente de specializare numite domenii
arhitecturale:
- arhitectura de afaceri care definește strategia de afaceri, guvernarea, organizarea,
și procesele cheie de business ale organizației
- arhitectura aplicației, care prevede un plan pentru sistemele individuale care
urmează să fie desfășurate, interacțiunile dintre sistemele de aplicare, precum și
relațiile lor cu procesele de afaceri de bază ale organizației cu cadrele de servicii
care urmează să fie expuse ca funcții de afaceri de integrare
- arhitectura de date care descrie structura activelor date logice și fizice ale unei
organizații și a resurselor de gestionare a datelor asociate
- arhitectura tehnică sau tehnologie arhitectura, care descrie hardware-ul, software-
ul, și infrastructurii de rețea necesare pentru a sprijini implementarea de bază,
aplicatii mission-critical.
 Cadrul ISO/IEC/IEEE 15288:2015

Sisteme și inginerie software - Procese ale ciclului de viață al sistemului

ISO / IEC / IEEE 15288: 2015 stabilește un cadru comun de descrieri de proces
pentru a descrie ciclul de viață al sistemelor create de om. Acesta definește un set de
procese și terminologia asociata din punct de vedere a ingineriei. Aceste procese pot fi
aplicate la orice nivel în ierarhia structurii unui sistem. Seturi selectate de aceste procese
pot fi aplicate de-a lungul ciclului de viață pentru gestionarea și efectuarea etapelor
ciclului de viață a unui sistem. Acest lucru este realizat prin implicarea tuturor părților
interesate, cu scopul final de a obține satisfacția clienților.

Figura 4.12. Procesele conform ISO/IEC/IEEE 15288:15

(Tranziția la ISO / IEC / IEEE-15288: 2015 Joseph P. Elm Vicepreședinte, divizia de

inginerie a sistemelor NDIA jelm@sei.cmu.edu)
ISO / IEC / IEEE 15288: 2015 prevede, de asemenea, procese care susțin definiția,
controlul și îmbunătățirea proceselor ciclului de viață al sistemelor utilizate în cadrul unei
organizații sau a unui proiect. Organizațiile și proiectele pot folosi aceste procese când
achiziționează și sisteme de alimentare.
ISO / IEC / IEEE 15288: 2015 se referă la acele sisteme care sunt dezvoltate de om și pot
fi configurate cu unul sau mai multe dintre elementele următoare de sistem: hardware,
software, date, oameni, procese (de exemplu, la procedee pentru furnizarea de servicii
pentru utilizatori), Procedurile (de exemplu, instrucțiunile operatorului), facilități,
materiale și entități în mod natural.

Cadrul Mechanics-Dynamics-Aesthetics (MDA)

În designul jocurilor, cadrul Mechanics-Dynamics-Aesthetics (MDA) este un

instrument folosit pentru analiză jocuri. Acesta formalizează consumul de jocuri
divizindule în trei componente - Mecanică, Dinamica si Estetica. Aceste trei cuvinte au
fost folosite informal de mai mulți ani pentru a descrie diverse aspecte ale jocurilor, dar
cadrul MDA prevede definiții precise pentru acești termeni și încearcă să explice modul
în care acestea se referă unul la altul și să influențeze experiența jucătorului.

Figura 4.13. Componentele de bază al unui joc

Mecanica reprezintă componenta de bază al unui joc- normele sale, fiecare acțiune
de bază pe care jucătorul o poate efectua în joc, algoritmi şi structuri de date într-un motor
de joc etc.
Dinamica este comportamentul run-time a mecanicii care acționează la intrarea
jucătorului și "cooperează" cu alte reguli ale mecanicii.
Estetica reprezintă răspunsurile emoționale evocate în player - bucurie, frustrare,
fantezie, părtășie.

Figura 4.14. Cadrul Mechanics-Dynamics-Aesthetics (MDA)

Lucrarea urmărește să precizeze mai bine termeni precum "gameplay" și

"distracție", și extinde vocabularul de studii de joc, ceea ce sugerează o taxonomie
neexhaustivă de opt tipuri diferite de joc. Cadrul utilizează aceste definiții pentru a
demonstra stimularea și proprietăților dinamicii in cele opt subcategoriile de utilizare a
unui joc.
Din punctul de vedere al proiectantului - mecanica genereaza o dinamică care
generează estetica. Această relație reprezintă o provocare pentru un designer de joc ca el
este apabil doar de a influența mecanica și numai prin ea, designerul poate să producă
dinamica semnificativa și estetică pentru jucător. Perspectiva jucătorului este invers. El
trăiește jocul prin estetica, care asigură dinamica de joc, care a rezultat de la mecanica.

2 Metamodele/Concepte

ISO 14258:1998

Sisteme de automatizare industriale - Concepte și reguli pentru modele de întreprindere

 Obiectivul major al acestui standard internațional este de a defini concepte și
reguli pentru modelele de întreprindere cu intenția de a ghida și constrânge alte standarde
sau implementări care există sau vor exista pe această temă. Acest lucru este realizat prin
definirea elementelor pentru utilizare atunci când producerea unui model de întreprindere,
concepte pentru fazele ciclului de viață și modul în care aceste modele descriu ierarhia,
structura, si comportamente. Prezentul standard internațional furnizează orientări și
constrângeri pentru modele de întreprindere pentru oricine încearcă să modeleze o
întreprindere sau procese.
Utilizatorii acestui standard internațional sunt în primul rând institutiile care
produc standarde mai detaliate despre o parte din domeniul integrării și modelarii.
Implementatorii sistemelor pot găsi, de asemenea valoare în structura dezvoltată în aceste
standarde internațional, astfel că implementarile lor sunt paralele conceptelor prezentate
în cadrul standardelor. Dacă design-ul implementării actuale este făcut conform aceluiași
domeniu tehnologic și nomenclatură, sau sunt în măsură de a le mapa usor, informațiile
de la o întreprindere sau proces pote fi mai ușor răspândite în comun cu informații de la
o altă întreprindere sau proces.
Motivul pentru acest standard internațional este că sunt necesare alte standarde
bine concepute în domeniul integrării si modelarii întreprinderii pentru a oferi un mediu
cunoscut pentru designeri de întreprindere. Astfel, riscul de a investi în domenii disjuncte
de integrare poate fi redus în mod semnificativ. În cazul în care nu există astfel de
domenii, atunci aceste standarde ajuta proiectantul pentru a crea transformarea necesara
pentru a interacționa cu mediul cunoscut. Un standard pentru modele de întreprinderi ar
trebui să sporească interoperabilitatea prin stabilirea elementelor care trebuie să fie
prezente într-un model de întreprindere. Aceste elemente vor intra în joc atunci când este
nevoie de un proces pentru a comunica cu un alt proces.

Scop: Prezentul standard internațional specifică concepte și reguli pentru modelele

ușor de înțeles pentru calculator, oferite de o întreprindere de producție, pentru a permite
o mai bună cooperare a proceselor de întreprindere. Acest standard internațional nu
definește procesele standard de companie, întreprinderi standard, structuri organizatorice
standard, sau de date standard de întreprindere. În plus, acest standard internațional nu
specifică procesul de modelare a întreprinderii, dar constituie baza prin care standardele
de modelarea întreprinderii poate fi dezvoltat în cazul în care acestea sunt necesare.

ISO 15704:2000

Sisteme de automatizare industriale - Cerințe pentru intreprinderi de tip arhitectural și

metodologii
Scop: Acest standard internațional definește cerințele pentru arhitecturi de întreprindere
și a metodologiilor, precum și cerințele pe care astfel de arhitecturi și metodologii trebuie
să le îndeplinească pentru a fi considerate o arhitectură complet de întreprindere și
metodologii. Domeniul de aplicare al acestor arhitecturi enterprise și a metodologiilor
acoperă aceste elemente constitutive considerate necesare pentru efectuarea tuturor
tipurilor de proiecte de creare de întreprinderi, precum și orice proiecte de schimbare
suplimentare cerute de întreprindere pe parcursul întregii vieți a întreprinderii, inclusiv:
- crearea de întreprinderi
- eforturi majore de restructurare întreprindere, și
- modificări incrementale care afectează doar o parte a ciclului de viață a
întreprinderii.
 Întreprinderile industriale crează și modifică operațiunile de fabricație și de afaceri
pentru a îmbunătăți performanța pe piețele locale și globale. În faza de exploatare, ele
implementeaza o varietate de resurse, cum ar fi oameni, sisteme de informare, și mașini
automate. Individual și colectiv aceste resurse oferă capacitățile funcționale necesare
pentru a accelera procesele de afaceri și activitățile lor constitutive. Interconectarea
resurselor trebuie să fie organizate și orientate pentru îndeplinirea misiunii. Acest lucru
necesită reguli de afaceri adecvate și structuri organizatorice pentru a permite
întreprinderii să furnizeze produse și servicii pentru clienții săi, în conformitate cu
criteriile convenite.
Întreprinderile operează în condiții de piață și de mediu incerte pentru ca ingineria
întreprinderii să poată fi în curs de desfășurare. Rezultă că personalul companiei au o
varietate de roluri pentru a juca în conceperea și dezvoltarea continuă a misiunii, regulile
de afaceri, procesele de afaceri, structurile organizatorice, precum și resursele și serviciile
de susținere a proceselor. Din cauza nivelului ridicat de complexitate implicat în ingineria
întreprindereii, invariabil este necesar pentru a implementa mijloacele de evaluare,
structurare, coordonarea și sprijinirea acestor activități de inginerie.
Arhitecturi de tip intreprindere susținute de metodologii de referință oferă mijloace
general aplicabile de organizarea și coordonarea de proiecte de inginerie. Prin adoptarea,
și adaptarea necesară, o metodologie de referință și arhitectură, personalul de
întreprindere poate coopera în progresul proiectelor întreprinderii de inginerie,
îmbunătățirea întreprinderii și utilizarea resurselor. Prin adoptarea unei metodologii de
referință arhitecturală, și a unui set de instrumente de sprijin, devine practic pentru
personal de a reutiliza modele de întreprinderi explicite și modele pentru a realiza o
inginerie de întreprindere pe o bază continuă si pentru a realiza îmbunătățiri suplimentare
în funcție de întreprindere. Prin urmare, o necesitate vitală este o bază de inginerie a
întreprinderii și referințe de integrare pentru furnizarea metodologiilor și sprijinirea
tehnologii care pot trata realist problema integrării întreprinderii.
 Figura 4.15. Arhitectura modelării

Activitatea IFAC / IFIP (Federația Internațională de Automatica / Federația

Internațională a Prelucrării Informații) Task Force pe arhitecturi de integrare a
Intreprinderii și de multe alte organizații similare din întreaga lume si-au concentrat
recent activitatea lor asupra acestei probleme în speranța de realizare generica a soluției
necesare. Munca lor a aratat ca o astfel de bază de referință poate fi concepută, și trebuie
să se bazeze pe o întreprindere de tip arhitectural, care:
- poate modela întreaga istorie de viață a unui proiect de întreprindere-integrare de
la conceptul inițial, prin definiție, design funcțional sau specificații, al proiectării
detaliate, implementarea fizică sau construcție, operare la defectare
- cuprinde oameni, procese, și echipamentele implicate în realizarea, gestionarea,
controlul și misiunea întreprinderii.
Este important să rețineți că întreprinderea de tip arhitectural are tangente
cu aranjamentul structural (organizare) din dezvoltarea și implementarea unui
proiect sau program, cum ar fi o integrare a întreprinderii sau alt program de
dezvoltare a întreprinderii. În contrast cu aceste întreprinderi de tip arhitecural,
sistemul arhitecural are de afacere cu aranjamentul structural (proiectare) a unui
sistem; de exemplu, partea de control a sistemului pe calculator a unui sistem de
integrare a întreprinderii.
Principiile-cheie ale integrării întreprinderii:
- aplicabilitatea la orice întreprindere
- identificarea întreprinderii și definirea misiunii
- separarea funcțiilor cu misiune de indeplinire de funcțiile cu misiune de control
 - identificarea structurilor de proces
- identificarea conținutului de proces
- recunoașterea fazelor ciclului de viață ale companiei
- abordare evolutivă a integrării întreprinderii
- modularitate
Scopul și beneficiile implementării întreprinderii de tip arhitectural și metodologii:
O arhitectură de tip enterprise cu metodologia asociată și tehnologii de
întreprindere inginereasca care îndeplinesc cerințele acestui standard, va nominaliza o
echipă de antrepriză-integrare-planificare pentru a determina și de a dezvolta un curs de
acțiune care este complet, exact, orientat corect la o viitoare evoluție a afacerii, cu
minimum de resurse, personal, și capital. Adică, să:
- descrie sarcinile necesare
- definească cantitatea necesară de informații
- specifice relaţiile dintre oameni, procese și echipamente în integrarea considerată
- adreseze preocuparile legate de gestiune
- adreseze factori economici, culturali, și tehnologici relevanţi
- detalieze gradul necesar de suport al calculatorului
- suporte modelarea bazata pe proces, care poate descrie întreaga istorie a vieţii
întreprinderii

Beneficii ale acestui standard:

Arhitecturile de tip înterprindere şi cerinţele metodologice în acest standard vor

permite o întreprindere specifică de tip arhitectural cu metodologia care urmează să fie
verificată pentru asigurarea integralității în ceea ce privește scopul său actual și viitor.
Acest standard va ghida dezvoltarea lor. Acest beneficiu va fi cel mai relevant pentru
orice grup responsabil de îmbunătățirea infrastructurii de întreprindere sau procesele sale.
Un astfel de grup va găsi că este necesar fie să creieze sau să selecteze o arhitectura de
tip enterprise, cu o terminologie care se referă în mod specific la companie, industrie,
cultură implicată. Acest standard va ghida acea selecție sau elaborare.

ISO 19440:2007

Integrarea Enterprise - Construcţii de modele a întreprinderii

Introducere: Acest standard internațional definește conceptele generice care sunt
necesare pentru a permite crearea de modele de întreprinderi pentru întreprinderi
industriale și de a oferi sprijin pentru utilizarea cadrelor de către întreprinderi industriale.
Prezentul standard internațional se bazează pe ISO 19439 prin definirea și detalierea unui
set de construcții de modelare a limbajului orientate spre utilizator, care oferă semantici
comune și permit unificarea modelor dezvoltate de diferitele părți interesate în diferite
faze de dezvoltare a modelului.
Astfel de modele sunt destinate suportului pe bază de model operaţional de luare
a deciziilor și pot fi folosite pentru modelul de monitorizare și control de funcționare.
Construcțiile de modelare a limbajului definite în prezentul standard internațional pot fi
specializate sau organizate în structuri pentru scopuri specifice, de exemplu, pentru un
sector industrial sau pentru un anumit tip de proiect de întreprindere, cum ar fi de
întreținere. La rândul său, astfel de structuri și construcții pentru modelarea generică a
limbajului pot fi folosite pentru dezvoltarea anumitor modele pentru o anumită
întreprindere.
Cerințele generale care determină caracteristicile de bază necesare pentru
modelarea la calculator sunt:
- asigurarea unui model explicit de Business Processes, cu propria lor dinamică,
funcții, informații, resurse, organizare și responsabilități
- detalierea suficienta și calificarea componentelor întreprinderii, pentru a permite
crearea unui model pentru o întreprindere specifică
- suport pentru managementul schimbării, și
- reprezentarea orientată spre utilizatorul final, pentru a permite utilizarea
operațională.

Scop: Acest standard internațional specifică caracteristicile construcțiilor de bază

necesare pentru modelarea suportată de calculator a întreprinderilor conform ISO 19439.
Acest standard internațional se concentrează asupra, dar nu se limitează la, integrarea
calculatorului asupra aspectelor de informare din procesul de fabricație, inclusiv
tehnologia de gestionare și control, precum și sarcinile umane necesare. Aceasta nu
specifică modul în care aceste construcții de bază pentru operațiunile bazate pe modele
urmează a fi implementate și, în special, nu include limba de control necesare pentru a
specifica și a executa comportamentul (intern) de activitate, nici cartografierea între
operațiunile și capacitățile funcționale.

ISO/IEC 15414:2015

Tehnologia informației - Procesarea deschisa distribuita - Model de referință -

limbajul Enterprise

Introducere:
Creșterea rapidă a prelucrării distribuite a condus la adoptarea modelului de referință
al procesarii deschise distribuite (RM-ODP, Reference Model of Open Distributed
Processing). Acest model de referință oferă un cadru de coordonare pentru standardizarea
prelucrării deschise distribuită (ODP). Aceasta creează o arhitectură în care suportul de
distribuție, de portabilitatea pot fi integrate. Această arhitectură oferă un cadru pentru
specificarea sistemelor ODP. Modelul de referință a procesîrii deschise distribuite se
bazează pe concepte precise derivate din evoluțiile actuale distribuite de prelucrare și, pe
cât posibil, pe utilizarea unor tehnici formale de descriere pentru specificarea arhitecturii.
Prezenţa recomandare redefineşte și extinde definiția modul în care sistemele ODP sunt
specificate din punct de vedere al întreprinderii, și este destinat pentru dezvoltarea sau
utilizarea specificațiilor ce vin de la companii de sisteme de ODP.

Scop: Prezenta recomandare prevede:

 - un limbaj (limbaju Enterprise), care cuprinde concepte, structuri, și reguli pentru
dezvoltare, reprezentând și raționamentul cu privire la o specificație a unui sistem
ODP din punct de vedere al întreprinderii
- norme care stabilesc corespondențe între limbajul de întreprindere și celelalte
limbaje de opinie pentru a asigura coerența de ansamblu a unui caiet de sarcini.
Limbajul este specificat la un nivel de detaliu suficient pentru a permite
determinarea conformității cu privire la orice limbaj de modelare pentru a prezenta o
recomandare. Această recomandare este destinata utilizării în prepararea caietul de sarcini
într-o companie de sisteme de ODP, și în dezvoltarea de notaţii şi instrumente pentru a
sprijini astfel de specificații. După cum se specifică la punctul 5 din Rec. X.903 ITU-T |
ISO / IEC 10746-3, o specificație din punct de vedere al întreprinderii definește politicile
unui sistem ODP, scopul si domeniul de aplicare.
Introducere: Acest Prestandard European (ENV) a fost aprobat de către CEN
(Comitetul European pentru Standardizare - the National Standardization Bodies of 33
European countries) la data de 1995-12-14 ca standard prospectiv pentru aplicarea
provizorie. Perioada de valabilitate a prezentului ENV se limita inițial la trei ani. După
doi ani membrilor CEN li se va cere să își prezinte observațiile, în special cu privire la
întrebarea dacă ENV poate fi transformat într-un standard european (EN). Membrii CEN
trebuie sa anunțe existența acestei ENV în același mod ca și pentru un EN și pentru a face
acest ENV disponibil imediat la nivel național într-o formă adecvată. Este permisă
menținerea standardelor naționale contradictorii în vigoare (în paralel cu ENV) până la
decizia finală cu privire la posibila conversie am ENV-ului într-o EN. Membrii CEN sunt
instituțiile naționale de standardizare din Austria, Belgia, Danemarca, Finlanda, Franța,
Germania, Grecia, Islanda, Irlanda, Italia, Luxemburg, Țările de Jos, Norvegia,
Portugalia, Spania, Suedia, Elveția și Marea Britanie.
Scop: Constituie un Prestandard european privind Modelarea Construcţiilor de
Întreprindere, sprijinind Views-urile definite în ENV 40003, a sistemelor de modelare
CIM în cadru arhitecturii. Acesta conține definiții și descrieri comune ale construcţiilor
necesare pentru modelarea pe calculator a întreprinderilor, concentrându-se pe
manufactura parţială discretă. Modelele generate folosind construcţii în conformitate cu
acest cadru vor fi în cele din urmă procesabile pe calculator şi vor permite operațiunile
zilnice ale unei întreprinderi pentru a fi rulate și controlate de către astfel de modele.

Metamodelul Business Process Definition (BPDM)

Introducere: Metamodelul Business Process Definition (BPDM) este o definiție

standard a conceptelor utilizate pentru a exprima modele proceselor de afaceri (un
metamodel), adoptate de OMG (Object Management Group). Metamodele definesc
concepte, relații, și semantici pentru schimbul de modele utilizate între diferite
instrumente de modelare. Formatul de schimb este definit de XSD (XML Schema) și XMI
(XML pentru Metadata Interchange), o specificație pentru transformarea metamodelelor
OMG la XML. BPDM oferă concepte abstracte ca bază pentru interpretări coerente a
conceptelor de specialitate folosite de modelatorii proceselor de afaceri. De exemplu,
ordonarea a mai multe elemente grafice într-o (Business Process Modeling Notation)
Diagrama BPMN este reprezentata prin săgeți între aceste elemente, dar elementele
specifice pot avea o varietate de caracteristici.
 Figura 4.16. Generic Meta-model generic al unui proces de afaceri
http://publik.tuwien.ac.at/files/pub-inf_3845.pdf

Scop: Caietul de sarcini se adresează obiectivelor BPDM din RFP OMG pe care se
bazează:
- BPDM "va defini un set de elemente abstracte pentru specificarea proceselor de
afaceri executabile în cadrul unei întreprinderi, și pot colabora între procesele de
afaceri; în caz contrar, acestea devin independente de executare în diferite unități
de afaceri sau întreprinderi."
- metamodel comun care să unifice diverse procese de afaceri care există în
industrie și care să conțină semantica compatibilă cu notațiile pentru modelarea
proceselor de afaceri
 - un metamodel care completează metamodele UML existente, astfel încât
procesele de afaceri a caietului de sarcini pot fi parte a sistemului de specificații
complete pentru a asigura coerența și exhaustivitatea
- capacitatea de a integra modele de proces pentru procese de management a
fluxului de lucru, procesele de business automatizate, si colaborări între unități de
afaceri
- sprijin pentru specificarea serviciilor web coregrafie, descriind colaborarea între
entitățile participante și capacitatea de a reconcilia cu coregrafia de sprijin a
proceselor de afaceri interne
- capacitatea de a face schimb intre specificațiile proceselor de afaceri si
instrumente de modelare, precum și între instrumentele și mediile de execuție,
folosind XMI.
Cererea de ofertă urmărește să "îmbunătățească comunicarea dintre modelatori,
inclusiv între afaceri și software modelatori, oferă selecție flexibilă de instrumente și
medii de execuție, și promovează dezvoltarea unor instrumente mai specializate pentru
analiza și proiectare a proceselor".
Pentru schimbul de modele a proceselor de afaceri, BPDM este o alternativă la
formatul existent pentru procesul de transfer XPDL (Process Definition Language XML).

Profilul UML pentru Enterprise Distributed Object Computing (EDOC)

Introducere: Necesitatea de a colabora și de a integra, a devenit de o importanță

strategică pentru întreprindere modernă. Integrarea lanțului de aprovizionare, de
management al clienților, B2B și integrarea aplicațiilor întreprinderii sunt toate
manifestări ale acestei nevoi de a îmbunătăți și automatiza colaborare folosind sisteme de
informații de întreprindere. Caietul de sarcini eDoc din OMG oferă o modalitate standard
de a modela colaborari de afaceri cu UML și "drill down" la sistemele de executabile care
folosesc middleware, cum ar fi servicii web, XML, J2EE web, MQ-Series, NET și,
desigur, Corba.

Figura 4.17. Puncte de vedere la modelare

Scop: EDoc face parte din viziunea OMG a unui "Model Driven Architecture", sau
MDA scurt. În viziunea MDA ciclul de viață al aplicației este condus de la nivel înalt,
modele UML axate pe Bussiness care pot fi "mapate" pentru diverse tehnologii de
implementare și execuție. Cei care au folosit UML știu că generarea de modele UML a
fost dificil și, de obicei produce cod care este "generic" pentru utilizarea practică. Din
acest motiv, cele mai multe modele UML sunt doar ghiduri la un proces subiectiv și
manual de implementare a aplicației. MDA abordează aceste probleme în două domenii
cheie; Modelele UML destinate pentru MDA sunt produse în conformitate cu unele
"Profiluri", un mod foarte specific de a utiliza UML pentru un anumit scop. Ar putea
exista profiluri pentru timp real, pentru modelarea datelor sau pentru întreprindere de
calcul. EDoc este profilul standard de UML pentru calcul distribuit de întreprindere, unde
departamentele si companiile trebuie să se integreze și să colaboreze. Ca atare, eDoc
devine cadrul de modelare utilizată la nivel de întreprindere. Profilurile fac UML suficient
de bine structurat și precis de a fi utilizat pentru MDA și de a conduce etapele ulterioare
din ciclul de viață pentru dezvoltare. Aceste modele precise la nivel înalt sunt cunoscute
ca "platforma Modele independente" (sau PIM) în limbajul de MDA.

3 Standarde Proiectare:

Limbaje
ISO 10303-11:2004

Sisteme industriale de automatizare și integrare - reprezentare a datelor de produs și de

schimb - Partea 11: Metode de Descriere: Manualul de referință a limbajului EXPRESS
Introducere: ISO 10303 - 11 a fost elaborat de Comitetul Tehnic ISO / TC 184,
sisteme de automatizare industriale si de integrare, Subcomisia SC 4, date industriale.
Această a doua ediție a ISO 10303-11 constituie o revizuire minoră a primei ediții (ISO
10303-11: 1994), care este reținută cu titlu provizoriu în scopul de a sprijini utilizarea în
continuare și întreținerea implementării bazate pe prima ediție și pentru a satisface
referințele normative de alte părți ale ISO 10303. Această a doua ediție include, de
asemenea, Rectificare tehnică ISO 10303-11: 1994 / Corinteni 1: 1999 (E).

ISO 10303 este organizat ca o serie de piese de schimb, fiecare publicate separat.
Structura ISO 10303 este descrisă în ISO 10303-1. Fiecare parte a ISO 10303 este un
membru al uneia dintre următoarele serii: Metode de descriere,

Metode de implementare, de testare

Metodologie de conformitate şi cadru,
Rresurse generice integrate,
Resurse integrate de aplicații,
Protocoale de aplicare,
Pachete abstracte de testare,
Construcții interpretate, și
Aplicatii si module de aplicații.

Această parte este componenta seriei de metode descriptive.

Scop: Această parte a ISO 10303 specifică un limbaj prin care aspectele legate de date
pot fi definite. Limbajul este numit EXPRESS. Această parte a ISO 10303 specifică, de
asemenea o reprezentare grafică pentru un subset de construcții în limbajul EXPRESS.
Această reprezentare grafică se numește EXPRESS-G. EXPRESS este un limbaj de
specificare a datelor astfel cum sunt definite în ISO 10303-1. Se compune din elemente
de limbaj, care permit o definiție lipsită de ambiguitate a datelor și specificarea
constrângerilor asupra datelor definite. Următoarele sunt în domeniul de aplicare al
acestei părți a ISO 10303:
- tipuri de date
- constrângeri asupra instanțe ale tipurilor de date
Următoarele sunt în afara domeniului de aplicare al acestei părți a ISO 10303:
- definirea formatelor de baze de date
- definiția de formate de fișiere
- definirea formatelor de transfer
- control al procesului
- procesarea informaţiei
- tratarea excepțiilor.
Express nu este un limbaj de programare.

ISO/IEC 15909-2:2011 (en)

Sisteme și inginerie software - Plase Petri de nivel înalt. Partea 2: Formatul de transfer.

Introducere: ISO / IEC 15909 se referă la definirea unui limbaj de modelare și

format de transfer, cunoscut sub numele Petri Net-uri de nivel înalt. ISO / IEC 15909-1
prevede definiția matematică a Petri Net-urilor de nivel inalt, numit modelul semantic,
forma grafică a tehnicii, cunoscut sub numele de grafic Petri net de nivel înalt (hlpngs),
și maparea ei cu modelul semantic.
Această parte a ISO / IEC 15909 definește un format de transfer pentru Petri Net-
uri de nivel înalt pentru a sprijini schimbul de Petri Net-uri la nivel inalt între diferite
instrumente. Acest format este numit Petri Net Markup Language (pnml). Există mai
multe versiuni diferite ale rețelelor Petri. Aditional, reţelelor Petri net de nivel înalt,
această parte a ISO / IEC 15909 definește conceptele de bază ale rețelelor Petri, împreună
cu o sintaxă XML, care poate fi folosit pentru schimbul de orice fel de Petri net.
Pe baza acestei Core model, această parte a ISO / IEC 15909 definește, de
asemenea, sintaxa de transfer pentru cele trei versiuni ale rețelelor Petri, care sunt definite
în ISO / IEC 15909-1: Locul / Transition Nets, simetric Nets1, și Petri net-uri de ordin
înalt, în cazul în care pot fi considerate Place / Transition net-uri, iar Symmetric Nets să
fie considerate versiuni limitate ale Petri nets de nivel inalt. Pentru Place/ Tranzition Nets,
această parte a ISO / IEC 15909 introduce două formate diferite de transfer: unul este un
format reglat special pentru a Place/ Transition nets, celălalt este un format care reprezintă
Place / Tranzition Nets ca o versiune restrânsă a Petri net-urilor de nivel înalt, astfel cum
sunt definite în ISO / IEC 15909-1.
 Figura 4.18. Petri net-uri de nivel înalt cum sunt definite în ISO / IEC 15909-1

Scop: Această parte a ISO / IEC 15909 definește un format de transfer bazat pe
XML pentru rețele Petri, care sunt definite conceptual și matematic în ISO / IEC 15909-
1. Acest format de transfer permite schimbul de rețele Petri între diferite instrumente Petri
net și între diferite părți. Mai mult decât atât, această parte a ISO / IEC 15909 definește
unele concepte și sintaxă bazata pe XML pentru definirea aspectul grafic detaliat al
rețelelor Petri.
Este punctul central al acestei părți a ISO / IEC 15909 privind formatul de transfer
pentru Place / Transition nets, la nivel înalt Petri Nets și Symmetric Nets.Prezentarea, cu
toate acestea, este structurată în așa fel încât este deschisă pentru extensii viitoare, astfel
încât alte versiuni ale rețelelor Petri pot fi adăugate mai târziu. Definiția exactă a acestui
mecanism extensie, numit definitie de tip Petri net, nu este definită în această parte a ISO
/ IEC 15909; Aceasta va fi definită în ISO / IEC 15909-3.
Formatul de transfer va fi utilizat pentru a transfera specificațiile sistemelor
dezvoltate în Petri net-uri de rang inalt între instrumentele pentru a facilita dezvoltarea
sistemelor în echipe.
Această parte a ISO / IEC 15909 este scrisă ca o referință pentru dezvoltatorii de
instrumente Petri net. În plus, va fi util pentru cercetatorii care definesc noile versiuni și
variante de rețele Petri.

Unified Enterprise Modelling Language (UEML)

Introducere: Unified Enterprise Modelling Language (UML) este o încercare în curs
de desfășurare pentru a dezvolta teorii, tehnologii și instrumente pentru utilizarea
integrată a întreprinderii și SI modele exprimate în limbi diferite. Prin aceasta ne referim
la păstrarea modelelor existente așa cum sunt și stabilim relații între ele într-un mod
explicit și ușor de utilizat, de sprijin, de exemplu, verificarea coerenței, modificare
reflecție automată, transfer de la model la model și la alte servicii dincolo de granițele
limbajului de modelare.

Figura 4.19. Clasele principale din modelul meta-meta reprezentare UEML

Scop: UEML se dorește a fi un limbaj intermediar - sau un hub - prin care diferite limbi
pot fi conectate, facilitând astfel o rețea de limbi și a modelelor exprimate în aceste limbi.
UEML cuprinde în prezent:
- o abordare structurată pentru a descrie întreprinderea și este modelarea unei limbi;
- o ontologie comună pentru a descrie semantica construcțiilor de modelare și, prin
urmare, interrelaționează construirea descrierii la nivel semantic;
- o abordare de analiză de corespondență pentru a determina corespondențe între
construcție;
- un cadru de calitate pentru a defini și de a evalua calitatea de întreprindere a
limbajelor de modelare pentru a ajuta selectarea limbii;
- un model de meta-meta a organiza și UEML;
- un set de instrumente pentru a ajuta utilizarea acestuia.

XML Metadata Interchange (XMI)

Introducere: XML Metadata Interchange (XMI) este un standard Object

Management Group (OMG) pentru schimbul de informații metadate prin Extensible
Markup Language (XML). Cea mai comună utilizare a XMI este ca un format de schimb
pentru modelele UML, deși poate fi de asemenea utilizat pentru serializare a modelelor
de alte limbi (metamodelului). XMI integreaza patru standarde ale industriei:
- XML - Extensible Markup Language, un standard W3C
- UML - Unified Modeling Language, un standard de modelare OMG
- MF - Meta Facilitatea obiect, un limbaj pentru specificarea OMG metamodel
- MF - Mapping la XMI Integrarea acestor patru standarde în XMI permite
dezvoltatorilor de instrumente de sisteme distribuite de a împărtăși modele de
obiecte și alte metadate.
 Figura 4.20. Utilizare XMI

Scop: Acest standard internațional sprijină Facilitatea Object Meta (MF) Core
definită în ISO / IEC 19508. MF este tehnologia bază pentru a descrie metamodelele.
Acesta acoperă o gamă largă de domenii, și se bazează pe un subset constrâns de UML.
XML Metadata Interchange (XMI) este un format XML de schimb utilizat pe scară largă.
Definește următoarele aspecte implicate în descrierea obiectelor în XML:
- reprezentarea obiectelor în ceea ce privește elementele XML și atributele
- mecanismele standard de a lega obiecte în același fișier sau peste fișiere
- validarea documentelor XMI folosind schemele XML
- identitatea obiect, care permite obiectelor să fie referite la alte obiecte în termeni
de ID-uri și UUID. XMI descrie soluții la problemele de mai sus, cu precizarea
regulilor de producție EBNF pentru a crea documente XML.

Business Process Model and Notation

Introducere: Business Process Model and Notation (BPMN)

(file:///C:/Users/User/Downloads/formal-11-01-03.pdf ) este o reprezentare grafică
pentru specificarea proceselor de afaceri într-un model de proces de afaceri. Business
Process Management Initiative (BPMI) a dezvoltat BPMN, care a fost menținut de Object
Management Group, deoarece cele două organizații au fuzionat în 2005. Versiunea 2.0 a
BPMN a fost lansat în ianuarie 2011, moment în care numele a fost adaptat la Business
Process Model and Notation ca semantica de execuție alături de elementele de notare și
de diagrame.
 Figura 4.21. Business Process Model and Notation (BPMN)

Scop: Un BPMN standard v-a oferi întreprinderilor capacitatea de a înțelege

procedurile lor de afaceri interne într-o notație grafică și va oferi organizațiilor capacitatea
de a comunica aceste proceduri într-o manieră standarda. În plus, notația grafică va
facilita înțelegerea colaborărilor de performanță și tranzacțiile de afaceri între organizații.
Acest lucru va asigura faptul că întreprinderile și participanții la afacerea lor vor înțelege
și vor permite organizațiilor să se adapteze la noile circumstanțe de afaceri interne și B2B
rapid.
ebXML Business Process Specification Schema

Introducere: EBusiness eXtensible Markup Language (ebXML) Procesul de afaceri

Specificații Schema (BPSS) specificație tehnică definește un limbaj standard prin care
sistemele de afaceri pot fi configurate pentru a sprijini executarea colaborărilor de afaceri
formate din tranzacții de afaceri (http://docs.oasis-open.org/ebxml-
bp/2.0.4/OS/spec/ebxmlbp-v2.0.4-Spec-os-en-html/ebxmlbp-v2.0.4-Spec-os-en.htm) .
Ea se bazează pe ONU / CEFACT, în special metamodelul din spatele ONU / CEFACT
Modelare Metodologie (UMM) definite în "/ CEFACT Modelare Metodologia ONU -
Meta Modelul - Revizuirea 10. În viitor, atunci când un ghid de referință devin disponibil
versiuni ulterioare vor fi evaluate și alte cerințe de metadate - analizate. Acestea ar putea
include cele dezvoltate în temeiul Centrul Națiunilor Unite pentru Comerț și Facilitation
and Electronic Business (ONU / CEFACT), cum ar fi de la acordurile de afaceri unitare
și contracte (Ubac).
Specificația tehnică ebBP sprijină caietul de sarcini a tranzacțiilor comerciale și
coregrafia tranzacțiilor comerciale în afaceri de colaborare. Toate tranzacțiile de afaceri
sunt puse în aplicare folosind una dintre multe modele standard disponibile. Aceste
modele sunt definite în caietul de sarcini UMM. Un model nu este executabil; mai degrabă
se specifică tipul de schimb de mesaje (cerere, răspuns și semnale) care se aplică pentru
o anumita definiție a tranzacției de afaceri. Este o modalitate de a defini clase de a defini
o tranzacție de afaceri. Aceste modele ar putea fi legate de diferite clase de tranzacții de
comerț electronic.
Versiunea actuală a specificației tehnice ebBP adresează colaborari de afaceri
între orice număr de părți. Acesta permite, de asemenea, participanților care sunt capabili
de a utiliza servicii Web sau tehnologii combinate (cum ar fi ebXML și servicii web),
pentru a participa la o colaborare de afaceri. Se anticipează că o versiune ulterioară a
acestei specificații tehnice va aborda caracteristici suplimentare, cum ar fi semantica
schimburilor economice și a contractelor, și de conținut pe baza context, pe baza
cerințelor de metadate furnizate de organizațiile relevante.

Figura 4.22. EBusiness eXtensible Markup Language (ebXML) Procesul de

afaceri
Scop: Definiţiile ebBP descriu procesele de afaceri interoperabile care permit partenerilor
de afaceri de a colabora și de a atinge un obiectiv comercial determinat. Aceste definiții
trebuie să fie executate de componente software care colaborează în numele partenerilor
de afaceri. Scopul specificației tehnice ebBP este de a oferi o punte între modelarea
proceselor eBusiness si executie de componente software eBusiness. Specificația tehnică
ebBP prevede pentru setul nominal de elemente necesare de a specifica o colaborare de
afaceri între parteneri de afaceri, și pentru a oferi parametrii de configurare pentru sisteme
de rulare a partenerilor în scopul de a executa o colaborare de afaceri între un set de
componente software eBusiness si caietul de sarcini.
Metode:

Data Flow Diagram

Introducere: O diagramă de flux de date (DFD) este o reprezentare grafică a
"fluxului" de date prin intermediul unui sistem informatic, de modelare a aspectelor sale
de proces. O DFD este adesea utilizata ca o etapă preliminară pentru a crea o imagine de
ansamblu a sistemului, care pot fi elaborate ulterior. [2] DFDS poate de asemenea fi
utilizată pentru vizualizarea de prelucrare a datelor (proiectare structurată). O DFD arată
ce fel de informații vor fi introduse la și spre ieșire din sistem, în cazul în care datele vor
veni de la și vor pleca spre, și în cazul în care datele vor fi stocate. Nu arată informații
despre calendarul de proces sau informații despre procesele ce se vor opera în ordine sau
în paralel (care este prezentat pe o schemă logică).

Scop: Diagrame de flux de date pot fi utilizate pentru a oferi utilizatorului final o idee
fizică în cazul în care datele de intrare pe care le are în cele din urmă au un efect asupra
structurii întregului sistem de la scopul de a trimite si a raporta. Cum un sistem este
dezvoltat poate fi determinat printr-un model de diagrama de date. În cursul dezvoltării
unui set de diagramele cu flux de date nivelat, analistul / designerul este obligat să se
adreseze în modul în care sistemul poate fi descompus în subsisteme componente, și de a
identifica datele tranzacției în modelul de date. Diagrame de flux de date poate fi utilizata
atât în analiza și in faza de proiectare a ciclului de viață a sistemului dezvoltat.

IDEF
Introducere: IDEF se referă la o familie de limbi de modelare în domeniul sistemelor
și inginerie software. Acestea acoperă o gamă largă de utilizări, de la modelarea
funcțională la date, simulare, analiză orientata pe obiect/ proiectare și dobândirea de
cunoștințe. Componentele din familia IDEF mai-larg recunoscute și folosite sunt IDEF0,
o structure de limbaj de modelare funcțională pe SADT, și IDEF1X, care abordează
modelele de informații și probleme de proiectare a bazei de date. Familia IDEF de
metode:
- IDEF0: pentru îndeplinirea funcției de modelare (scop: descriere)
- IDEF1: pentru Information Modeling. (scop: descriere)
- IDEF1x: pentru datele de modelare. (scop: de proiectare)
- IDEF3: pentru Process Modeling. (scop: descriere)
- IDEF 4: pentru Object-Oriented Design. (scop: de proiectare)
- IDEF 5: pentru Ontology Description Capture. (scop: descriere)
Scop: IDEF este folosit pentru activități necesare pentru a sprijini analiza de sistem,
proiectarea, îmbunătățirea sau integrarea de modelare. Inițial, IDEF a fost dezvoltat
pentru a îmbunătăți comunicarea între oameni care încearcă să înțeleagă sistemul. Acum,
IDEF este utilizat pentru documentare, înțelegere, proiectare, analiza, planificare, și
Integrare.

Unified Modeling Language

 Introducere: Unified Modeling Language (UML) este un limbaj pentru scop general
de dezvoltare, limbaj de modelare în domeniul ingineriei software, care este destinat să
furnizeze o modalitate standard de a vizualiza proiectarea unui sistem. UML a fost
proiectata inițial de dorința de a standardiza sistemul de notație disparate și abordările de
proiectare a software-ului. Unified Modeling Language (UML) oferă o modalitate de a
vizualiza planurile de arhitectură a unui sistem într-o diagramă, inclusiv elemente cum ar
fi:
- orice activitate (locuri de muncă)
- componentele individuale ale sistemului și modul în care acestea pot interacționa
cu alte componente software
- cum sistemul va rula
- cum entitățile vor interacționa cu celelalte (componente și interfețe)
- interfață de utilizator extern
Deși inițial a fost destinată exclusiv pentru documentația de proiectare orientată pe
obiect, Unified Modeling Language (UML) a fost extinsă pentru a acoperi un set mai
mare de documentație de proiect și a fost găsit util în mai multe contexte.
Scop: Procesul de colectare și analiză a cerințelor unei aplicații, și includerea acestora
într-un program de proiectare, este una complexă și industria sprijină în prezent mai multe
metodologii care definesc proceduri formale care să precizeze modul de a merge spre
asta. O caracteristică a UML - în fapt, cea care permite susținerea industriei larg
răspândită de care limbajul se bucură - este faptul că aceasta este o metodologie
independente. Indiferent de metodologia pe care o utilizați pentru a efectua analiza și
design-ul, aveți posibilitatea să utilizați UML pentru a exprima rezultatele. Și, folosind
XMI (XML Metadata Interchange, un alt standard OMG), puteți transfera modelul UML
dintr-o unealtă într-un fișier, sau în alt instrument pentru rafinament sau următorul pas în
procesul de dezvoltare aleasă. Acestea sunt beneficiile standardizării!
4 Business Process Choreography

Unified Enterprise Modelling Language (UEML)

Unified Enterprise Modelling Language (UML) este o încercare în curs de desfășurare

pentru a dezvolta teorii, tehnologii și instrumente pentru utilizarea integrată a
întreprinderii și IS modele exprimînd limbi diferite. Prin aceasta ne referim la păstrarea
modelelor existente așa cum sunt și stabilim relații între ele într-un mod explicit și ușor
de utilizat, de sprijin, de exemplu, verificarea coerenței, modificarea reflecției automate,
traducerea de la model la model și alte servicii dincolo de granițele limbajului de
modelare. UML poate fi privită ca o limbă intermediară - sau un hub - prin care diferite
limbi pot fi conectate, facilitând astfel o rețea de limbi și a modelelor exprimate în aceste
limbi.
Acestea și alte posibile evoluții viitoare au fost organizate într-o foaie de parcurs
UEML cuprinzând mai multe direcții de cercetare, fiecare detaliat de acțiuni specifice
(Opdahl & Berio 2006). Într-o anumită măsură, în continuare dezvoltarea UEML în
fiecare direcție poate progresa în paralel, fără o coordonare strictă. Cele zece direcții
originale au fost:
- lățimea Limba - include mai multe limbi
- adâncime ontologică - Căutare comun ontologia
- claritate ontologică - elaborarea limba comună ontologie
- prezentarea - extinde suportul pentru probleme de prezentare
- formalitate matematică - să definească în mod oficial semantica UEML
- suport Tool - dezvolta instrument prototip cu GUI și sprijin validare
- model de management - să ofere sprijin pentru management modelul în plus față
de gestionare a limbajului
- validarea - limba structurale și de comportament și de validare a modelului
- diseminarea - face UEML cunoscut în industrie și mediul academic și ca standard
- comunitatea - stabilească și să mențină o comunitate angajat și coezive pentru
gestionarea și evoluție UEML și abordarea sa.

Business Process Modeling Language (BPML)

BPML fost un limbaj propus, dar acum BPMI a scăzut din sprijinul pentru BPML în
favoarea BPEL4WS (Business Process Execution Language for Web Services). Ca şi în
2008, BPML a fost, de asemenea raportat ca fiind depăşit în favoarea BPDM (Business
Process Definition Metamodel).
BPML, un superset al BPEL, a fost pus în aplicare de către furnizorii de stadiu
incipient, cum ar fi Intalio Inc., dar operatorilor tradiționali cum ar fi IBM și Microsoft
nu au implementat BPMLin metodele lor de lucru existente şi în mediile de integrare
(BizTalk, WebSphere etc.). Prin urmare, au optat pentru o limbă simplă, BPEL. Astăzi,
implementări open source de BPML încă depășesc capacitatea a acestor produse
comerciale. Acest lucru a condus unii să spună că BPML versus BPEL a fost un caz de
SHV față de Betamax. Analogia nu este destul de corecta. In cazul VHS și Betamax
amândoua vă permit să urmăriți video - chiar dacă o implementare a câștigat. Însă nu este
cazul cu BPML și BPEL. BPML a fost conceput ca o limbă complet formală, posibilitatea
de a modela orice proces, și, prin intermediul unui BPMS (sistem de management al
proceselor de afaceri), desfășurat ca un proces de software executabil fără generarea
oricărui cod software. Acest lucru nu este posibil, cu BPEL, deoarece BPEL nu este un
limbaj complet orientat pe proces. Pentru a ilustra acest lucru, rețineți că BPEL este
adesea folosit în combinație cu Java pentru a umple în "lipsa" semanticii. În plus, BPEL
este adesea legat de implementări de proprietate de motoare broker workflow sau
integrare, intrucât, BPML a fost proiectat, implementat și, ca un motor de procesare pur
concurent și distribuit.
În mod ironic, cea mai completă versiune de BPEL implementată astăzi, este BPMS-
ul deschis al Intalio, care completeaza, de asemenea, semantica prin îndeplinirea spiritului
caietului de sarcini BPML. Poate că în viitor BPML va fi văzut în alte implementări
BPEL. Singura diferență în viitor va fi sintaxa, semantica nu. În acest sens, BPML nu
poate fi evitat, deoarece a fost proiectat pentru a fi semantic complet în conformitate cu
reprezentarea formală a proceselor de calcul Pi-calculus.
Lupta dintre BPML și BPEL este in general considerata ca un exemplu al puterii IBM
și Microsoft în startup-uri în stadiu incipient de a finaliza o stivă tehnologia de bază în
centrul modelului lor de afaceri.
BPEL și BPML sunt exemple de o tendință de programare orientată spre proces.
BPEL și BPML au mostenit conceptul de BPMS ca o capacitate IT de gestionare a
proceselor de afaceri, jucând un rol similar cu un RDBMS pentru datele de afaceri.

ebXML

Business electronic folosind eXtensible Markup Language, cunoscut sub numele de

XML e-business, sau ebXML cum este de obicei menționat, este o familie de standarde
de baza XML sponsorizate de OASIS și ONU / CEFACT a cărui misiune este de a oferi
o infrastructură deschisă, bazată pe XML care permite utilizarea la nivel mondial de
informații de afaceri electronice într-un mod interoperabil, sigur, și consecventă de către
toți partenerii comerciali.
Arhitectura ebXML este un set unic de concepte; partea teoretică și o parte pusă
în aplicare în activitatea standardelor ebXML existente. În timp ce standardele ebXML
adoptate de ISO și OASIS cauta sa ofere mecanisme formale, care pot fi implementat
direct XML-ului, arhitectura ebXML este pe concepte și metodologii care pot fi aplicate
în sens mai larg, pentru a permite practicanților să pună în aplicare mai bine soluții de e-
business.
O instanță specială este Core Components Specificatii tehnice (CCTs) activitatea
care continuă în ONU / CEFACT, în timp ce partenerul său - UBL - Universal Business
Language - caietul de sarcini este utilizat în OASIS care implementează operațiuni XML
specifice prin aplicarea principiilor de CCTs a lanțului tipic de efectuare a tranzacților,
cum ar fi factura, comanda de achiziție, o notificare a navelor și așa mai departe.
PSL (ISO 18629)
Process Specification Language (PSL) este un set de termeni logici folositi pentru
a descrie procese. Termenii logici sunt specificati într-o ontologie care oferă o descriere
formală a componentelor și relațiile lor, care alcătuiesc un proces. Ontologia a fost
dezvoltaat la Institutul National de Standarde si Tehnologie (NIST), și a fost aprobat ca
un standard internațional în documentul ISO 18629.
Process Specification Language poate fi utilizat pentru reprezentarea de fabricație,
de inginerie și procese de afaceri, inclusiv sistematizarea producției, procesul de
planificare, managementul fluxului de lucru, proceselor de afaceri reengineering,
simularea, realizarea procesului, modelarea proceselor, și management de proiect. În
domeniul de fabricație, obiectivul PSL este de a servi ca o reprezentare comună pentru
integrarea mai multor aplicații legate de proces de-a lungul ciclului de viață al procesului
de fabricație.
Aceasta ontologie oferă un vocabular de clase și relații pentru concepte la nivelul
de baza al evenimentelor-instante, obiecte-instanțe, și momente de timp. La nivel superior
PSL este construit astfel:
- activitatea, o clasă sau tip de acțiune, cum ar fi o parte de instalare, care este clasa
de acțiuni în care sunt instalate piese
- activitatea-eveniment, un eveniment sau o acțiune care are loc într-un loc și timp
specific, cum ar fi o instanță specifică pentru o parte de instalare care apare la un
anumit moment de timp
- momentul de timp, un punct în timp
- obiect, ceva care nu este o moment de timp sau o activitate.

XPDL

Limbajul de proces XML Definition (XPDL) este un format standardizat de

Workflow Management Coalition (WfMC) pentru a interschimba definiții ale proceselor
de afaceri între diferite produse in dezvoltare, și anume între diferite instrumente de
modelare și de management. XPDL definește o schemă XML pentru specificarea partii
declarative a fluxului de lucru / proceselor de afaceri.
XPDL este conceput pentru a redefini definiția de proces, atât grafica si semantica
unui proces de afaceri aflat în dezvoltare. XPDL este in prezent cel mai bun format de
fișier pentru schimbul de diagrame BPMN; acesta a fost special conceput pentru a stoca
toate aspectele legate de o diagramă BPMN. XPDL conține elemente care dețin informații
grafice, cum ar fi poziția X și Y a ganglionilor, precum și asupra aspectelor executabile
care ar fi folosite pentru a rula un proces. Aceasta distinge XPDL din BPEL care se
concentrează exclusiv pe aspectele executabile ale procesului. BPEL nu conține elemente
care să reprezinte aspectele grafice ale unei diagrame de proces. Se poate spune că XPDL
este serializarea XML al BPMN.
5 Mesagerie

Canale de comunicare

HTTP Hypertext Transfer Protocol (HTTP) este un protocol de cerere pentru sisteme
distribuite, colaborative, informații hipermedia. HTTP este fundamentul de comunicații
de date pentru World Wide Web.
Hypertext reprezintă textul structurat care utilizează legături logice (hyperlink-uri)
între noduri ce conțin text. HTTP este protocolul pentru a schimba sau de efectua un
transfer hipertext.
Funcțiile HTTP sunt protocoale de tip cerere-răspuns în modelul de calcul client-
server. Un browser web, de exemplu, ar putea fi clientul și o aplicație care rulează pe un
computer de găzduire pe un site web poate fi server. Clientul depune un mesaj de cerere
HTTP la server. Serverul, care oferă resurse, cum ar fi fișiere HTML și alte tipuri de
conținut, sau exercită alte funcții în numele clientului, returnează un mesaj de răspuns la
client. Răspunsul conține informații de stare de finalizare cu privire la cererea și pot
conține, de asemenea, conținutul solicitat în corpul său mesaj. Un browser web este un
exemplu de un agent utilizator (UA). Alte tipuri de agent utilizator includ software-ul de
indexare utilizat de către furnizori de căutare (web crawlers), browsere vocale, aplicații
mobile, și alte software-ul care accesează, consumă, sau afișează conținut web.
HTTP este conceput pentru a permite elemente intermediare de rețea pentru a
îmbunătăți sau a permite comunicarea între clienți și servere. Site-uri cu trafic mare de
multe ori beneficiaza de servere Web Cache cu livrare conținutului parţiala pentru a
îmbunătăți timpul de răspuns. Browsere Web Cache care au accesat anterior resurse web,
le reutilizeaza atunci când este posibil, pentru a reduce traficul în rețea. Servere proxy
HTTP la frontierele rețelei private pot facilita comunicarea pentru clienţi fără o adresă la
nivel global rutabil, prin retransmiterea cu servere externe.
HTTP este un protocol aplicație stratificat, proiectat în cadrul Internet Protocol Suite.
Definiția sa presupune un protocol de transport de bază și de încredere, unde
Transmission Control Protocol (TCP) este frecvent utilizat. Cu toate acestea, HTTP pot
utiliza protocoale nesigure precum User Datagram Protocol (UDP), de exemplu în
serviciu Simple Discovery Protocol (SSDP).
Resurse HTTP sunt identificate și situate pe rețeaua de resurse uniforme (URL-uri),
folosind Uniform Resource Identifier (URI) schemele HTTP și HTTPS. URI-urile și
hyperlink-uri în documente Hypertext Markup Language (HTML) formează documentele
interconectate hipertext.
HTTP / 1.1 este o revizuire a HTTP original (HTTP / 1.0). În HTTP / 1.0 o conexiune
separată la același server se face pentru fiecare cerere de resurse. HTTP / 1.1 pot reutiliza
o conexiune de mai multe ori pentru a descărca imagini, script-uri, foi de stil, etc., după
ce pagina a fost livrată. Prin urmare, comunicațiile HTTP / 1.1 suportă mai puţină latență
deoarece stabilirea de conexiuni TCP prezintă efort considerabil.
 Metoda revocării la distanţa

Metoda Java de revocare la distanţa (Java RMI) este un API Java care efectuează
echivalentul de apeluri si de proceduri orientate pe obiect la distanță (RPC), cu suport
pentru transfer direct de clase Java serializate și de colectare a resurselor uzate distribuite.
- implementarea originală depinde de mecanismul de reprezentare a claselor Java
Virtual Machine (JVM), prin urmare, doar efectuarea apelurilor de la un JVM la
alta. Protocolul care stă la baza acestei implementari Java este cunoscut sub numele
de Java Remote Method Protocol (JRMP)
- în scopul de a sprijini codul ce rulează într-un context non-JVM, o versiune
CORBA a fost dezvoltata ulterior.
Utilizarea termenului RMI poate însemna doar interfața de programare sau poate
însemna atât API și JRMP, IIOP, sau o alta implementare, în timp ce termenul de RMI-
IIOP denotă în mod special delegarea interfaței RMI cu maxim de funcționalitate pentru
suportul implementării CORBA.
Ideea de bază a Java RMI, protocolul colectarii resurselor uzate distribuite (DGC),
și o mare parte din arhitectura care stă la baza punerii în aplicare pentru SUN, provin de
la "obiecte de rețea", caracteristica Modula-3.
Programatorii de la RMI API au generalizat codul ca să sprijine diferite implementări,
cum ar fi transportul HTTP. În plus, capacitatea de a trece argumente "de valoare" a fost
adăugat in CORBA pentru a fi compatibil cu interfața RMI. Totuși, implementările RMI-
IIOP și JRMP nu au interfețe complet identice.

Common Object Request Broker Architecture (CORBA)

Common Object Request Broker Architecture (CORBA) este un standard definit de

Object Management Group (OMG) conceput pentru a facilita comunicarea de sisteme
care sunt dislocate pe diverse platforme. CORBA permite colaborarea dintre sistemele pe
diferite sisteme de operare, limbaje de programare, și hardware-ul de calcul. CORBA are
multe din aceleași obiective de design ca programarea orientată pe obiecte: încapsulare și
reutilizarea. CORBA foloseste un model orientat pe obiect, deși sistemele care folosesc
CORBA nu trebuie să fie orientate pe obiect. CORBA este un exemplu de paradigma a
obiectului distribuit.
CORBA permite comunicarea între software-uri scrise în diferite limbi și rulează pe
computere diferite. Detaliile de implementare de la sisteme de operare, limbaje specifice
de programare și platforme hardware sunt toate eliminate din responsabilitatea de
dezvoltatori care folosesc CORBA. CORBA normalizeaza semantica metodei de apel
între obiecte aplicație care se află fie în aceeași adresă de spațiul (cerere) sau adrese de
spații izolate (aceeași gazdă, sau gazdă de la distanță într-o rețea). Versiunea 1.0 a fost
lansat in octombrie 1991.
CORBA foloseşte un limbaj de definiție a interfaței (IDL) pentru a specifica
interfeţele pe care obiectele sunt prezentate în lumea exterioară. CORBA specifica apoi
o mapare de la IDL la o implementare în limbaje specifice, cum ar C ++ sau Java. Există
mapări standard pentru Ada, C, C ++, C ++ 11, COBOL, Java, Lisp, PL / I, Python, Ruby
și Smalltalk. Există mapări non-standard pentru C #, Erlang, Perl, Tcl și Visual Basic
implementat de object request brokers (ORBs) scrise pentru aceste limbi.
Caietul de sarcini CORBA dictează ca trebuie să existe un ORB, prin care o cerere ar
interacţiona cu alte obiecte. Acesta este modul în care este implementată în practică:
- cererea pur și simplu initializeaza ORB, și accesează un adaptor de obiect intern, care
menține lucruri cum ar fi numarărea referințelor, politici de instanțiere a obiectului (și de
referință), și a politicilor ciclului de viaţă a obiectelor
- adaptorul obiect este folosit pentru a înregistra instanţe a claselor generate. Clasele cu
codul generat sunt rezultatul compilării codului de utilizator IDL, care se traduce în
definiția de interfață de nivel înalt într-un OS - și clasa bazată pe limbaj specific pentru
utilizarea de către aplicația utilizator. Acest pas este necesar pentru a pune în aplicare
semantica CORBA și să ofere un procedeu de utilizare curat pentru interfațarea cu
infrastructura CORBA.
SOAP

SOAP, inițial un acronim pentru Simple Object Access Protocol, este o specificație
de protocol pentru schimbul de informații structurate în punerea în aplicare de servicii
web în rețele de calculatoare. Acesta utilizează setul de informaţii XML pentru formatul
mesajului, și se bazează pe alte protocoale strat de aplicare, mai ales Hypertext Transfer
Protocol (HTTP) sau Mail Transfer Protocol Simple (SMTP), pentru mesajul de
negociere și de transport.
SOAP poate forma stratul de fundație al unei stive pentru protocol de servicii web,
oferind un cadru de mesaje de bază pentru servicii web. Acest protocol bazat pe XML
este format din trei părți:
- un plic, care definește structura mesajului și cum să-l proceseze
- un set de reguli de codare pentru exprimarea cazuri de tipuri de date definite de
aplicați
- o convenție pentru reprezentarea procedură apeluri și răspunsuri
SOAP are trei caracteristici majore:
- extensibilitate (securitate și WS-rutare sunt printre extensiile în curs de dezvoltare)
- neutralitate (SOAP poate funcționa pe orice protocol de transport, cum ar fi HTTP,
SMTP, TCP, UDP, sau JMS)
- independența (SOAP permite orice model de programare)
Ca un exemplu de ceea ce pot face procedurile SOAP, o aplicaţie poate trimite o
cerere SOAP la un server care are servicii web, cum ar fi o baza de date cu parametrii
pentru o căutare. Serverul returnează apoi un răspuns SOAP (un document formatat-XML
cu datele rezultate), de exemplu, prețuri, locație, caracteristici. Având în vedere că datele
generate vin într-un format standardizat ce suporta prelucrarea de maşina, aplicația
solicitantă poate apoi integra direct răspunsul.
Arhitectura SOAP este formată din mai multe straturi ale caietulului de sarcini pentru:
- format de mesaj
- modele pentru schimbul de mesaje (MEP)
- protocolate pentru legături de transport
- modele de prelucrare a mesajelor
 - protocol pentru extensibilitate

Semantica mesajelor

EDIFACT

United Nations/Electronic Data Interchange For Administration, Commerce and

Transport (UN/EDIFACT) este standardul EDI internațional elaborat în cadrul
Organizației Națiunilor Unite. În 1987, în urma convergenţei ONU și propunerile de
sintaxă SUA / ANSI, / EDIFACT, regulile de sintaxă ONU au fost aprobate ca standardul
ISO ISO 9735 de către Organizația Internațională de Standardizare. Standardul
EDIFACT prevede:
- un set de reguli de sintaxă pentru a structura datele
- un protocol de schimb interactiv (I-EDI)
- mesaje standard care permit schimburi multinaționale și multi-industriale.
Activitatea de întreținere și dezvoltare ulterioară a acestui standard se face prin
Centrul Națiunilor Unite pentru facilitarea comerțului și afacerilor electronice (ONU /
CEFACT) sub supravegherea Comisiei Economice a ONU pentru Europa, în grupul de
lucru al domeniului de Finanțe ONU CEFACT TBG5.
Universal Business Language (UBL)

UBL este o bibliotecă de standarde XML electronice şi documente de afaceri, cum ar

fi ordinele de cumpărare și facturi. UBL a fost dezvoltat de un comitet tehnic OASIS cu
participarea de organizații de standardizare dintr-o varietate mare din industrie. UBL este
conceput pentru a conecta direct în afaceri existente, legale, de audit, precum și practicile
de administrare a înregistrărilor. Acesta este conceput pentru a elimina re-keying de date
în faxurile existente și a corespondenței de afaceri, pe suport de hârtie și să ofere un punct
de intrare în comerțul electronic pentru întreprinderile mici și mijlocii.
UBL este deţinută de OASIS şi este disponibilă în prezent pentru toți, fără taxe de
redevență. Biblioteca UBL de documente de afaceri este un limbaj de marcare bine
dezvoltat cu validatoare, software de creație, parsere și generatoare. UBL versiunea 2.0 a
fost aprobat ca standard OASIS în octombrie 2006, iar versiunea 2.1 a fost aprobat ca
standard OASIS în noiembrie 2013. Versiunea 2.1 este pe deplin compatibil cu versiunea
2.0, dar se adaugă 34 de noi scheme de documente, aducând totalul de tipuri de documente
de afaceri definit de UBL la 65. UBL urmăreşte originile sale înapoi la standardele EDI
și alte standarde XML derivate.

OAGIS

Open Applications Group Integration Specification (OAGIS): OAGIS definește un

model de conținut comun și mesaje comune de comunicare între aplicațiile de afaceri.
Aceasta include integrarea aplicație la aplicație (A2A) și business-to-business (B2B).
Organizație: OAGis.
OAGIS este un proiect comun al marilor companii în primul rând din industria IT
pentru integrarea aplicațiilor în cadrul unei întreprinderi și dincolo de granițele
corporative. OAGIS se bazează pe limbajul de marcare XML. OAGIS este împărțit în
cinci secțiuni:
- o arhitectură de referință abstractă pentru sisteme de informații de afaceri
- o descriere a "Componente Software Business" tipice
- "Diagramele scenariului" pentru a ilustra comunicarea între componente
- ca elemente de bază, o listă de interfețe de programare aplicații (API) a componentelor
- directorul de date Dicționarul asociat (OAG99a).

RosettaNet

RosettaNet este un consorțiu non-profit care vizează stabilirea unor procese standard
pentru schimbul de informații de afaceri (B2B). RosettaNet este un consorțiu de
calculator major și electronice de consum, Componente electronice, Semiconductor
Manufacturing, companii de telecomunicaţii şi logistica care lucrează pentru a crea și a
pune în aplicare, standardele pentru proces deschis de e-business la nivel de industrie.
Aceste standarde formează un limbaj comun e-business, procese între partenerii din lanțul
de aprovizionare la nivel global.
RosettaNet este o filială a GS1 SUA, fostul Uniform Code Council, Inc. (UCC).
Acesta a fost format în principal prin eforturile depuse de Fadi Chehade, primul CEO. In
cadrul RosettaNet, 500 de membri provin de la companii din intreaga lume. Consorțiul
are o prezență în Statele Unite ale Americii, Malaezia, Europa, Japonia, Taiwan, China,
Singapore, Thailanda și Australia.RosettaNet are mai multe grupuri de utilizatori locali.
Utilizatorul din Grupul european este numit EDIFICE.
Standardul RosettaNet se bazează pe XML și definește orientările mesajelor, interfețelor
pentru procesele de afaceri, și cadrele de punere în aplicare pentru interacțiunile dintre
companii. Cel mai mult adresata este zona lanțului de aprovizionare, dar, de asemenea
de fabricație, produse și materiale de date și procese de servicii care sunt în domeniul de
aplicare.
Standardul este larg răspândit în industria de semiconductori la nivel mondial, dar,
de asemenea, în componente electronice de larg consum, telecomunicații și logistică.
RosettaNet isi are originea în SUA și este utilizat pe scară largă acolo, dar este, de
asemenea, bine acceptată și chiar sprijinita de guvernele din Asia. Ca urmare a utilizării
pe scară largă a EDIFACT în Europa, RosettaNet este folosit mai puțin, dar este un
standard in dezvolatre.The RosettaNet Automated Enablement standard (RAE) utilizează
standardul document XML Office Open.
Dicționarul Tehnic RosettaNet (RNTD) este modelul de referință pentru clasificarea
și caracterizarea produselor în lanțurile de aprovizionare care utilizează RosettaNet pentru
interacțiunile lor.

MANDATE

ISO 15531-1: 2004 oferă o prezentare generală a întregului standard IOS 15531.
Acesta specifică domeniul de aplicare și oferă o serie de definiții de bază pe care întregul
standard este construit în conformitate cu "Teoria Sistemului General" și conceptele
definite în dicționarul APICS. Anexele sale informative oferă o descriere a relațiilor
dintre MANDATE și alte standarde (în special standarde ISO / TC 184), precum și o
clarificare a conceptelor de "capabilitate și capacitatea" așa cum sunt utilizate în
MANDATE și in alte standarde care se referă în mod explicit sau implicit la teoria
sistemului.
MANDATE abordeaza modelarea managementului fabricației de date , cum ar fi:
- managementul datelor resursa (Resource model)
 - caracteristici de timp (Time model)
- date gestionate in fluxul de fabricație (Flow management model).
MANDATE, în asociere cu STEP, PLIB și alte standarde SC 4 (sau non SC 4), pot fi
utilizate în orice aplicație software care se adresează gestionarii informațiilor referitoare
la datele de management a resurselor, fluxul de date de management. Ca atare, standardul
este destinat să faciliteze schimbul de informații între aplicații software, cum ar fi ERP,
software de management de fabricație, software de management de întreținere, software-
ul citat, etc.
MANDATE a fost scris în EXPRESS. În timpul fazelor de dezvoltare ale standardului
MANDATE, compatibilitatea standard cu 10,303 (STEP) standardul ISO a fost subiectul
unei analize aprofundate.

STEP (ISO 10301)

ISO 10303 este un standard ISO pentru reprezentarea interpretabilă pe calculator și

schimbul de informații despre produsul de fabricație. Titlul său oficial este: sisteme de
automatizare și integrare - reprezentare a datelor de produs și de schimb. Este cunoscut
informal drept "STEP", care vine de la "standard pentru schimbul de date pentru model
de produs". ISO 10303 poate reprezenta obiecte 3D în proiectarea asistată de calculator
(CAD) și a informațiilor relaţionate.
Obiectivul standardului internaţional, este de a oferi un mecanism care este capabil
de a descrie date de produse de-a lungul ciclului de viață al unui produs, independent de
orice sistem particular. Natura acestei descrieri îl face potrivit nu numai pentru schimbul
de fișiere neutre, dar, de asemenea, ca bază pentru punerea în aplicare și schimbul de baze
de date de produse si arhivare.
De obicei STEP poate fi folosit pentru a face schimb de date între CAD, fabricație
asistată de calculator, inginerie asistată de calculator, date produs de modelare a datelor
de management / întreprinderi și alte sisteme CAX. STEP adresează date de produse de
la proiectare mecanice și electrice, dimensionarea geometrică și toleranţa, analiza de
fabricație, precum și informații suplimentare specifice diferitelor industrii, cum ar fi
industria auto, industria aerospațială, pentru constructii, nave, petrol și gaze, instalații
industriale și altele.
STEP este dezvoltat și menținut de către comitetul tehnic ISO TC 184, Sisteme de
automatizare și integrare, sub-comisia SC 4, date industriale. Ca și alte ISO și IEC
standardul STEP are dreptul de autor de la ISO și nu este disponibil gratuit. Cu toate
acestea, 10303 schemele Express sunt disponibile în mod liber, la fel ca și practicile
recomandate pentru implementatori.
 Modele de inregistrare

UDDI

Universal Description, Discovery and Integration (UDDI) este independent de

platforma, bazat pe registrul Extensible Markup Language (XML), prin care
întreprinderile din întreaga lume se pot afisa pe Internet, precum și un mecanism de a
înregistra și localiza aplicațiile de servicii web. UDDI este o inițiativă pentru industria
deschisa, sponsorizata de Organizația pentru promovarea standardelor referitoare la
informația structurată (OASIS), pentru a permite companiilor de a publica anunțuri de
servicii și de a se descoperi reciproc, și pentru a defini modul în care serviciile sau
aplicațiile software vor interacționa pe Internet.
UDDI a fost inițial propus ca un standard de serviciu Web de bază. Acesta este
conceput pentru a fi interogat de mesaje SOAP și pentru a oferi acces la documente Web
Services Description Language (WSDL), care descriu legăturile de protocol și formatele
de mesaje necesare pentru a interacționa cu serviciile web enumerate în directorul său.
O înregistrare de afaceri UDDI este format din trei componente:
- paginile albe - adresa, contact, și date de identificare cunoscute
- pagini Aurii - clasificarea industrială bazată pe taxonomii standard
- pagini verzi - informații tehnice despre serviciile expuse de afaceri.

Paginile albe

Paginile albe oferă informații despre afaceri care furnizează serviciul. Aceasta include
numele de afaceri și o descriere a activității - potențial în mai multe limbi. Folosind
această informație, este posibil de a găsi un serviciu despre care unele informații sunt deja
cunoscute (de exemplu, localizarea un serviciu bazat pe numele furnizorului). Date de
contact pentru afaceri este prevăzut - de exemplu adresa întreprinderii și numărul de
telefon
Paginile aurii

Pagini aurii oferă o clasificare a serviciului sau a afacerii, bazat pe taxonomii standard.
Acestea includ Clasificarea Standard industrial (SIC), Industria de Clasificare pentru
Sistemul American de Nord (NAICS), sau de United Nations Standard Products and
Services Code (UNSPSC) și taxonomiile geografice. Deoarece o singură afacere poate
oferi o serie de servicii, pot exista mai multe Pagini Aurii (fiecare descriind un serviciu)
asociate cu o pagină albă (care oferă informații generale despre afaceri).
Paginile verzi

Paginile verzi sunt folosite pentru a descrie modul de a accesa un serviciu web, cu
informații cu privire la legăturile de servicii. O parte din informațiile sunt legate de
serviciul Web - cum ar fi adresa serviciului și parametrii, și trimiterile la specificațiile de
interfețe. Alte informații nu sunt direct legate de Serviciul Web - aceasta include e-mail,
FTP, CORBA și detalii de telefon pentru serviciul. Deoarece un Web Service poate avea
mai multe legături (așa cum este definit în descrierea WSDL), un serviciu poate avea mai
multe pagini verzi, deoarece fiecare mapare obligatoriu va trebui să fie evaluată în mod
diferit.
Meta-Object Facility (MOF)
Facilitatea Meta-Object (MOF) este un grup de gestionare a standardelor pentru
inginerie bazate pe modelul de obiecte (OMG). Scopul său este de a oferi un sistem tipic
pentru entitățile din arhitectura CORBA și un set de interfețe prin care aceste tipuri pot fi
create și manipulate. Pagina oficială de referință pot fi găsite pe site-ul OMG lui.
MF a fost dezvoltat pentru a oferi un sistem tipic pentru utilizare în arhitectura
CORBA, un set de scheme prin care structura, semnificația și comportamentul obiectelor
ar putea fi definită, și un set de interfețe CORBA, prin care ar putea fi create aceste
scheme, depozitate și manipulate.
MF este conceput ca o arhitectura de patru straturi. Acesta oferă un model-meta
de la stratul de sus, numit stratul de M3. Acest M3 model este limbajul folosit de MF
pentru a construi metamodelele, numit M2-modele. Cel mai important exemplu de un
model de Layer 2 MF este metamodelului UML, modelul care descrie UML în sine.
Aceste modele-M2 descriu elemente ale stratului M1, și astfel M1-modele. Acestea ar fi,
de exemplu, modelele scris în UML. Ultimul strat este M0-strat sau stratul de date. Este
folosit pentru a descrie obiecte din lumea reală.
Dincolo de M3-model, MF descrie mijloacele de a crea și manipula modele și
metamodele prin definirea interfețelor CORBA care descriu aceste operațiuni. Din cauza
asemănărilor dintre MOF M3-model și modele de structura UML, metamodelele MOF
sunt de obicei modelate ca diagrame de clase UML. Un standard de susținere a MF este
XMI, care definește un format de schimb bazat pe XML pentru modelele pe M3-, M2-,
sau M1-Layer.
Metadata Registry (MDR)

ISO / IEC 11179 (cunoscut anterior ca 11179 Metadata Registry (MDR) standardul ISO
/ IEC) este un standard internațional pentru reprezentarea metadatelor pentru o
organizație într-un registru de metadate.
Organizațiile fac schimb de date între sistemele informatice utilizând tehnologii
pentru integrarea aplicațiilor întreprinderii. Tranzacțiile finalizate sunt adesea transferate
în sistemele de depozitare a datelor și sisteme cu regule de business cu structuri concepute
pentru a sprijini datele pentru analiza. Un model de facto standard pentru platforme de
integrare a datelor este Common Warehouse Metamodel (CWM). Integrarea datelor este
adesea rezolvată ca o problemă de date, mai degrabă decât metadate, cu utilizarea așa-
numitelor date de bază. ISO / IEC 11179 susține că este un standard pentru schimbul de
date bazat pe metadate într-un mediu eterogen, pe baza definițiilor exacte ale datelor.
11179 Modelul ISO / IEC este un rezultat a două principii ale teoriei semantice,
combinate cu principiile de bază de modelare a datelor.
Primul principiu de la teoria semantică este relația de tip tezaur dintre concepte
mai largi și mai înguste (sau specifice), de exemplu, conceptul larg"venituri" are o relație
cu conceptul mai îngust "venitul net".
Al doilea principiu de la teorie semantică este relația dintre un concept și
reprezentarea sa, de exemplu, "cumpără" și "procura" sunt același concept, deși termeni
diferiți sunt used.Un principiu de bază al modelării datelor este o combinație de clase de
obiecte și o un caracteristică. De exemplu, "persoana - culoarea părului".
 Atunci când se aplică pentru modelarea datelor, ISO / IEC 11179 combina un
"concept de" lățime, cu o "clasă de obiecte", pentru a forma un "concept de element de
date" mai specific. De exemplu, la nivel înalt conceptul de "venituri" este combinat cu
clase de obiecte "persoană", pentru a forma conceptul element de date "venitul net de
persoane". Rețineți că "venitul net" este mai specific decât "venituri".
Diferitele reprezentări posibile ale unui concept element de date sunt apoi descrise
cu utilizarea unuia sau mai multor elemente de date. Diferențele în reprezentare poate fi
o urmare a utilizării de sinonime sau diferite domenii de valori în seturi de date diferite
într-o exploatație de date. Un domeniu valoare este gama permisa de valori pentru o
caracteristică a unei clase de obiecte. Un exemplu de domeniu valoare pentru "sex de
persoană" este "M = Barbat, F = Femeie, U = necunoscut". Literele M, F și U sunt apoi
valorile permise pentru sexul unei persoanei dintr-un anumit set de date.
Conceptul element de date "venit net lunar de persoană" poate avea, prin urmare,
un element de date numit "venit net lunar individual pentru grupări de 100 dolari" și unul
numit "venit net lunar individual din gama 0-1000 dolari", etc., în funcție de
eterogenitatea de reprezentare care există în exploatațiile de date care fac obiectul un
registru ISO / IEC 11179. Rețineți că aceste două exemple prezinta diferiti termeni de
clase de obiecte (persoană / persoana) şi seturi de valori diferiţo (interval 0-1000 dolari,
spre deosebire de grupări individuale de 100 dolari).
Rezultatul este un catalog de elemente sortate, în care conceptele de elemente de
date legate sunt grupate pe un concept la nivel înalt și o clasă obiect, iar elementele de
date grupate - după un concept element de date comune. Strict vorbind, aceasta nu este o
ierarhie, chiar dacă seamănă cu una.
ISO / IEC 11179 nu descrie exact metoda de stocare a datelor așa cum acestea
sunt fapt stocate. Aceasta nu se referă la descrierea fișierelor fizice, tabelor și coloanelor.
Construcţiile ISO / IEC 11179 sunt "semantice", spre deosebire de "fizice" sau "tehnice".
Standardul are două scopuri principale: de definiție și de schimb. Obiectul de bază
este conceptul elementului de date, deoarece definește un concept și, în mod ideal, descrie
date independente de reprezentarea sa în oricare dintre sisteme, tabele, coloane sau
organizații.
Dicţionare conceptuale

Object Management Group (OMG)

The Object Management Group (OMG) este un organism deschis internațional,

consorțiu non-profit al standardelor tehnologice. Grupuri Operative OMG dezvoltă
standarde de integrare ale companiei pentru o gamă largă de tehnologii și industrii.
Modelarea de standarde OMG permite design vizual, execuţie şi intreţinere de software
și a altor procese. Inițial vizează standardizarea sistemelor orientate pe obiecte distribuite,
compania se concentrează acum pe modelare (programe, sisteme și procese de afaceri) și
a standardelor bazate pe modele.
OMG oferă numai caietul de sarcini, și nu oferă implementări. Dar, înainte ca o
specificație să fie acceptată ca un standard de OMG, membrii echipei câştigătoare
submise trebuie să garanteze că acestea vor aduce un produs conform cu piaţa într-un an.
Aceasta este o încercare de a preveni standarde neimplementate.
 Alte companii private sau grupuri open source sunt încurajate pentru a dezvolta
produse conform OMG , iar acesta încearcă să dezvolte mecanisme pentru a pune în
aplicare adevărată interoperabilitate.
OMG găzduiește patru întâlniri tehnice pentru membrii săi și cei interesaţi să devină
membri. Întâlnirile tehnice ofere un forum neutru pentru a discuta, dezvolta și adopta
standarde care să permită interoperabilitatea software pentru o gamă largă de industrii,
inclusiv: finanţe, fabricație, asistență medicală, robotica, bazată pe software de
comunicații, securitate, guvern, spațiu și mai mult. În martie 2015, reuniunea a avut loc
în TC Reston, VA; în luna iunie 2015, în Berlin, Germania, în septembrie 2015, în
Cambridge, MA; iar în decembrie 2015, la reuniunea este La Jolla, CA.
Semantics of Business Vocabulary and Business Rules (SBVR)

Semantics of Business Vocabulary and Business Rules (SBVR) este un standard

adoptat de Object Management Group (OMG) destinat a fi baza pentru limba naturala
declarativ formală și detaliată a unei entități complexe, cum ar fi o afacere. SBVR este
destinat să oficializeze reguli de conformitate complexe, cum ar fi normele de exploatare
pentru o întreprindere, politica de securitate, respectarea standardelor, sau reguli de
conformitate de reglementare. Astfel de vocabulare formale și norme pot fi interpretate și
utilizate de către sistemele informatice. SBVR este o parte integrală din arhitectura bazata
pe model OMG (MDA).
Standardul SBVR definește vocabularul și regulile pentru documentarea semantica de
afaceri, fapte de afaceri, precum și regulile de business; precum și o schemă XMI pentru
schimbul de vocabulare de afaceri și reguli de afaceri între organizațiile și între
instrumente software.
SBVR permite producerea de vocabulare și reguli de afaceri; vocabularul plus regulile
constituie un model de domeniu comun cu aceeași putere expresivă a limbilor ontologice
standard. SBVR permite dezvoltarea multilingvă, deoarece se bazează pe separarea între
simboluri și semnificația lor. SBVR permite regulilor de afaceri sa devina accesibile
instrumentelor software, inclusiv instrumente care susțin experții de afaceri în crearea,
găsirea, validarea, și gestionarea regulilor de business, și instrumente care susțin experții
de tehnologie a informației în transformarea normelor de afaceri în norme de punere în
aplicare pentru sistemele automate.
SBVR foloseşte Meta-Object Facility (MF) al OMG-ului, pentru a oferi
funcţionalitate de schimb MF / XMI ale regulilor de mapare, permite generarea de
modele MOF-conforme și să definească o schemă XML. SBVR propune limba engleză
structurată ca una dintre mai multe, eventual, notații, care pot mapa metamodelul SBVR.
SBVR și Knowledge Discovery Metamodell (KDM) sunt concepute ca două părți ale
unui unic OMG Technology Stack de analiza software legate de sistemele de software
existente. KDM definește o ontologie legate de artefacte de software și, prin urmare, oferă
o formalizare inițială a informațiilor legate de un sistem software. SBVR pot fi utilizate
în continuare pentru a formaliza reguli complexe de conformitate referitoare la software-
ul.
 Regulile de afaceri reprezintă principalul mijloc prin care o organizație poate
direcționa activitatea, definind modul operativ de a ajunge la obiectivele sale și de a
efectua acțiunile sale.
O abordare bazată pe reguli pentru gestionarea de afaceri și informațiile utilizate de
afaceri este un mod de a identifica și articula normele care definesc structura și
controlează funcționarea unei întreprinderi. Acestea reprezintă un nou mod de a gândi
despre companie și normele sale, în scopul de a permite o reprezentare completă de
afaceri realizate de și pentru oamenii de afaceri. Reguli de afaceri pot juca un rol
important în definirea semantică de afaceri: ei pot influența sau ghida comportamentul și
politicile de sprijin, ca răspuns la situații și evenimente de mediu. SBVR este punerea în
aplicare a abordării OMG regulilor de afaceri.
Bibliografia

1 Enterprise Engineering - A New Organizational Discipline. Liviu-Gabriel CREŢU

Catedra de Informatică Economică, Universitatea “AL.I.Cuza” Iaşi. Revista Informatica
Economică, nr.4 (40)/2006.
2 Business Rules Group - The Business Rules Manifesto,
http://www.businessrulesgroup.org/brmanifesto.htm, 2003.
3 Dalal, P.N., et all – Toward an Integrated Framework for modeling enterprise processes,
CACM, martie 2004, vol 47/3
4 Eriksson, H., Penker, M – Business Modeling with UML, John Wiley&Sons, 2000.
5 ISO TC184 SC5 WG1 - Modeling and Architecture Work program and key resources,
http://www.mel.nist.gov/sc5wg1/wg1-on-apage.pdf , 2000.
6 ISO/IEC JTC1/SC21/WG7 - ISO 10746- ODPRM Architecture -
ftp://ftp.dstc.edu.au/pub/DSTC/arch/RMODP/PDFdocs/part3.pdf, 2002.
7 ISO/IEC JTC1/SC21/WG7 - ISO 10746- ODPRM Foundations,
ftp://ftp.dstc.edu.au/pub/DSTC/arch/RMODP/PDFdocs/part2.is.pdf, 2002.
8 ISO/IEC JTC1/SC21/WG7 - ISO 15414 – ODPRM -6 Enterprise Language,
http://www.joaquin.net/ODP/DIS_15414_X.911. pdf, 2004.
9 Jokers,H., et al - Towards a Language for Coherent Enterprise Architecture
Descriptions, Proceedings of the Seventh IEEE International EDOC Conference, 2003.
10 K. Kosanke- Standards in Enterprise Interand Intra-Organisational Integration,
CIMOSA Asoc, http://www.eil.utoronto.ca/ ICEIMT04/kosanke.pdf, 2004.
11 Kosanke K.- Overview on EM standardisation and international consensus activities,
CIMOSA Association, www.cimosa.de/ Standards/EMstand02.pdf, 2003.
12 Levi, K., Arsanjani, A. – A Goal Driven Approach to Enterprise component
identification and specification, CACM, oct 2002, vol. 45/10.
13 Marshall, C. – Enterprise modeling with UML, Addison-Wesley, 2000.
14 Martin, R- ISO 19439&19440 -Framework and Constructs for enterprise modelling,
OMGBEIDTF, 2005.
15 Niţchi, Ş. - Distributed, Cooperative and Collaborative support systems – a general
framework, în vol. Innovative Applications of information technologies in business and
management, PIM, Iaşi, 2005.
16 Niţchi, Ş., Niţchi, R. – On the paradigm of collaborative support systems, în vol.
Collaborative support systems in business and education, RisoPrint, Cluj-Napoca, oct.
2005 .
17 OMG – BPDM, http://www.bpmn.org/Documents/BPDM/OMGBPD-2004-01-12-
Revision.pdf, 2004.
18 OMG – Enterprise Collaboration Architecture Specification,
http://www.omg.org/docs/formal/04-02-01.pdf, 2004.
19 OMG – UML 2.0 Superstructure, www.omg.org/docs/formal/05-07-04.pdf, 2005.
20 Ross, R - Principles of the Business Rule Approach, Adisson Wesley, 2003.
21 Soderborg, N., Crawley, E.F, Dori, D. – System function and architecture: OPM based
definitions and operational templates, CACM, oct 2003, vol 46/10.
22 * * *, A survey of the real time economy, The Economist, 02.
23 Sisteme informaționale Economice. http://www.ia.ase.ro/Sie/SIE-4-2013.pdf.
24 Rich Hilliard June 2007, r.hilliard@computer.org.
25 Federal Enterprise Architecture Framework. Version 2. January 29, 2013.
https://www.google.com/#q=federal+enterprise+architecture+framework+2012
26 Federal Enterprise Architecture. Chief Information Officer Council. Version 1.0
February 2001. http://www.gao.gov/assets/590/588407.pdf.
27 Robert Weisman. MSc, PEng, PMP, CD. CEO / Chief Enterprise Architect
44 Montgomery Street, 1168 Ste Therese
Ottawa, Ontario, Canada, K1C2A6, robert.weisman@buildthevision.ca.
28 Transitioning to ISO / IEC / IEEE-15288:2015 Joseph P. Elm Vice Chair, NDIA
System Engineering Division jelm@sei.cmu.edu.
TEMA 5

Bazele Modelării Sistemelor Informaționale

Conotațiile IDEF
IDEF0, DFD, IDEF1x, IDEF3, IDEF4, IDEF5, IDEF9

La etapa de proiectare se construiesc modele care redau arhitectura sistemului,

alocarea cerinţelor pe subsisteme, distribuţia proceselor în sistem, sincronizarea lor,
stările şi tranziţiile între stări. Alte modele descriu realizarea fizica a sistemului,
echipamentele din componenta sa şi repartiţia componentelor program.
Fiecare vedere asupra unui sistem poate avea aspecte structurale şi aspecte
comportamentale. În funcţie de natura sistemului, unele modele pot fi mai importante
decat altele. De exemplu, pentru unele sisteme sunt mai importante aspectele structurale
şi funcţionale, pentru altele aspectele temporale.
Construirea modelelor este ghidată de metode. O metoda defineşte o abordare
reproductibilă care permite obţinerea de rezultate fiabile în mod repetat. Toate domeniile
cunoaşterii utilizează metode mai mult sau mai puţin sofisticate şi mai mult sau mai puţin
formalizate. De exemplu, bucătării utilizează reţete de bucătărie, arhitecţii construiesc
planuri, muzicienii urmează reguli de compoziţie.
Modelele sunt alcătuite din elemente de modelare care constituie concepte
fundamentale pentru reprezentarea sistemelor sau a fenomenelor. Elementele de modelare
sunt adesea notaţii grafice. Ele constituie limbajul de modelare.
E de menționat că față de limbajul de modelare, o metodă definește reguli de
aplicare care descriu coordonarea diferitelor puncte de vedere, înlănțuirea acțiunilor,
ordonarea sarcinilor și repartizarea responsabilităților.
Principalele scopuri ale modelarii sistemelor informatice sunt:
- vizualizarea, ca mijloc de uşurare a comunicării şi înţelegerii;
- specificarea, prin construirea de modele precise, neambigue şi complete
- documentarea cerinţelor, a soluţiilor de proiectare şi a modului de realizare
- diverse metode sunt aplicate pentru modelare și proiectare sisteme care prezintă
caracteristici ale ciclului de viaţă dorite cum ar fi: flexibilitate, receptivitate,
scalabilitate, mentenabilitate, usurinţa de utilizare, integrare, performanţă şi pentru
angajarea echipelor de oameni în activităţi critice de dezvoltare a ciclului de viaţă
al sistemului
 un limbaj de modelare este orice limbaj artificial, care poate fi folosit pentru a
exprima informaţii sau cunoştinţe sau sisteme într-o structură care este definită de
un set consistent de reguli. Regulile sunt folosite pentru a interpreta rostul
componentelor în structură
 IDEF (Integration DEFinition) este o familie de limbaje de modelare în domeniul
sistemelor şi ingineriei software. Acestea acoperă o gamă largă de utilizări, de la
modelarea funcţională la date, simulare, analiza / proiectarea obiect-orientata şi
achiziţia de cunoştinţe. Aceste "limbaje de definiţie" au fost elaborate în
conformitate cu finanţarea de la US Air Force şi, deşi încă cel mai frecvent folosite
de acestea, precum şi alte agenţii militare şi Departamentul de Aparare (DoD),
sunt în domeniul public.
- IDEF0: Modelare de funcţii
 - IDEF1: Modelare de informaţii
- IDEF1X: Modelare de date
- DFD:
- IDEF3: Captura descriere proces
- IDEF4: Design obiect-orientat
- IDEF5: Captura descriere ontologie
- IDEF9: Descoperirea constrangerilor de afaceri
- IDEF0: Modelare de funcţii - Metoda modelării funcţionale IDEF0 este destinată
să modeleze deciziile, acţiunile, şi activităţile unei organizaţii sau unui sistem.
IDEF0 - metodologie pentru simularea funcțională. Cu intuitiv IDEF0 limbă grafic
este sistemul de studiu la un set de funcții interdependente ( blocuri de funcții ). Ca
o regulă, instrumentul de modelare IDEF0 este primul pas în analiza și studiul
oricărui sistem
- IDEF1: Modelare de informaţii - Metodologie pentru modelarea fluxurilor
informaționale în cadrul companiei sau a sistemului. Vă permite să afișați și să
analizați structura fluxurilor informaționale și relațiile lor
- IDEF1X: Modelare de date.- IDEF1X (IDEF1 extinsă) - metodologia de
construcție a structurilor relaționale. IDEF1X se referă la tipul de metodologii
Esența relației, (ER - entitate-relație) și este utilizat de obicei pentru modelarea
bazelor de date relaționale relevante pentru acest sistem
- DFD: Modelarea Logică a datelor
- IDEF3: Captura descriere proces. - Metodologie pentru documentarea
proceselor care au loc în sistem. Cu IDEF3 se descriu scenariile și secvențele de
operații pentru fiecare proces. IDEF3 este direct legată de metodologia IDEF0 -
fiecare funcție (unitate funcțională) poate fi reprezentată prin intermediul IDEF3 ca
un proces separat
- IDEF4: Modelare (Design) obiect-orientat. - IDEF4 - metodologie pentru
construirea unor sisteme orientate-obiect. Instrumentul IDEF4 permite vizualizarea
structurii obiectelor și principiile de interacțiune a acestora, care permite analiza și
optimizarea sistemelor orientate pe obiecte complexe
- IDEF5: Captura descriere ontologie- IDEF5 - metodologie ontologică pentru
cercetarea sistemelor complexe. Cu ajutorul unui dicționar de termeni și norme
permite pentru a descrie și formaliza sistemul ontologic. IDEF5 sau Integrated
Definition pentru Metodei de capturare a descrierii ontologiei este o metodă de
inginerie software pentru a dezvolta si mentine ontologii utilizabile, exacte. În
domeniul ontologiilor informatice sunt utilizate pentru a captura concepte şi obiecte
într-un domeniu specific, împreună cu relaţiile şi semnificaţiile asociate. În plus,
captarea ontologiei contribuie la coordonarea proiectelor prin standardizarea
terminologiei şi creează oportunităţi pentru reutilizarea informaţiilor. Metoda de
capturare a ontologiei lDEF5 a fost dezvoltata pentru a construi fiabil ontologii într-
un mod care reflectă strâns înţelegerea umană a domeniului specific. În metoda
IDEF5, o ontologie este construită prin captarea conţinutul ale anumitor afirmaţii
despre obiectele din lumea reala, proprietăţile lor, şi relaţiile lor şi care reprezintă
acel conţinut într-o formă intuitivă si naturală. Metoda IDEF5 are trei componente
principale: un limbaj grafic pentru a sprijini analiza ontologiei conceptuale, un
limbaj text structurat pentru caracterizarea ontologiei detaliate, precum şi o
procedură sistematică, care oferă liniile directoare pentru a captura ontologia
eficient
 - IDEF9: Descoperirea constrangerilor de afaceri. - IDEF9 sau Integrated
Definition pentru descoperirea constrângerilor în mediul de afaceri este conceput
pentru a ajuta la descoperirea şi analiza constrângerilor într-un sistem de afaceri.
Motivaţia principală pentru stimularea dezvoltării IDEF9 a fost o recunoaştere a
faptului că o colecţie de constrângeri care fabrica un sistem de întreprindere este,
în general, slab definită. Cunoaştere a constrângerilor ce există şi a modului în care
interacţionează aceste constrângeri este incompletă, disjunctă, distribuită, şi de
multe ori complet necunoscută. Această situaţie nu este neapărat alarmantă. La fel
ca organisme vii, nu trebuie să fie conştienţi de constrângerile genetice sau
autonome care guvernează anumite comportamente, organizaţiile pot (şi cele mai
multe o fac) să funcţioneze bine fără a cunoaşte explicit care sunt structurile
sistemului. Cu toate acestea, în cazul în care există dorinţa de a modifica afacerile
într-un mod previzibil, cunoaşterea acestor constrângeri este la fel de critică ca şi
cunoştinţele de genetică pentru ingineria genetică
Semantica domeniului

Domeniul reprezintă un set denumit și definit de mai multe valori și atribute pe

care îl reprezintă. Domeniile sunt definite separat de entități și puncte de vedere, în scopul
de a permite reutilizarea și standardizarea lor în întreaga antrepriză.
Un domeniu este considerată o clasă pentru care există o structură fixă, și, eventual, set
infinit de cazuri
De exemplu, Codul de Stat ar fi considerat un domeniu în care setul de valori
admisibile pentru domeniu ar satisface definiția unui cod de stat (adică unicul
identificator al unei stări) și abrevierile de două litere ale statelor.
Domeniile sunt considerate clase imuabile ale căror valori nu se modifică în timp.
Fiecare instanță domeniu are o valoare unică într-o reprezentare - adică, unic în acest
domeniu.

Figura 5.1(a). Semantica domeniului

 Figura 5.1(b). Semantica domeniului

a) există două tipuri de domenii, domeniu de bază și domeniu tastat (tip)

b) unui domeniu de bază îi poate fi atribuit un tip de date care poate fi unul dintre
următoarele: Caracter, numeric sau boolean. Pot fi utilizate și alte tipuri de date,
cum ar fi data, ora, binar, etc.
c) domeniului de bază de regulă i se atribuie:
1) o regulă de domeniu
2) normele de domeniu
Normele de domeniu sunt folosite pentru a furniza valorile acceptabile ale unui
domeniu. Cele două reguli de domeniu sunt comune pentru listă de valori, precum și
pentru regulile de intervale.
Domeniile tip sunt sub-tipuri a domeniului de bază sau alte domenii tipizate, care
pot constrânge în continuare valorile acceptabile pentru domeniu. Un domeniu tip există,
în cazul în care acesta este de tipul de date, și respectă regulile de domeniu din domeniul
său superior. În acest fel, o ierarhie de domenii poate fi definită, cu reguli de domeniu din
ce în ce mai stricte mergând în jos pe ierarhie. O ierarhie de domeniu este o ierarhie
generalizată. Trebuie de reținut că domeniile tip nu se exlud reciproc.

Figura 5.2. Decompoziția domeniului

Diagrama de context (Context Diagram)

Diagrama de context: este un model al funcției din Domeniul (obiectul) la cel mai înalt
nivel de: intrări, control, mecanisme și ieşiri
 - intrări: elemente care declanşează activitatea
- control: ghidează sau regleaza actrivitateam
- mecanisme: sisteme, oameni, echipamente utilizate pentru a efectua
activitatea
- ieşiri: rezultatele efectuării activităţii.

Modelarea funcţiilor

Esența abordării structurale, Principiile de bază la abordarea structurală, Esența

metodologiei abordării funcționale IDEF0, Noțiuni principale a metodologiei IDEF0,
Reguli de construire modele în IDEF0, Exemple de modele funcționale în notația IDEF0.

Esența abordării structurale

Subsistem Aplicație 1
Funcțional 1
…
SUBFUNCȚIA 1
…
SISTEMA Subsistem
Funcțional 2 SUBFUNCȚIA 2 Aplicație 2
… … … …
Subsistem
Funcțional n
…
SUBFUNCȚIA n Aplicație n

Figura 5.3. Decompoziția structurală a domeniului

Principiile de bază la abordarea structurală

- principiul- «divide și domină»
- principiul- structurare ierarhică
- principiul- de abstracție
- principiul- eliminare conflicte
- principiul- structurare date
Modele ce se construiesc la Abordarea Structurală,
Tipuri de modele, sunt utilizate în abordarea structurală :
a) Modele Funcționale (М F)
b) Modele Informaționale (М I)
c) Modele Dinamice (М D)

МF SADT (IDEF0)-Modele Aplicații BPWin, Design/IDEF

DFD- Modele Aplicații BPWin

МI ERD (IDEF1X) Aplicații Design/IDEF, ERWin

МD IDEF/CPN Aplicații Design/IDEF

IDEF3 Aplicații BPWin

IDEF0: Modelarea funcţiilor

 IDEF0 modelează:
- deciziile
- acţiunile şi
- activităţile unei organizaţii sau
- activităţile unui sistem pentru a identifica perspectiva funcţională a sistemului.
Crearea Modelelor IDEF0 sunt una dintre primele sarcini în dezvoltarea unui sistem,
deoarece acestea :
- descriu funcţiile care sunt efectuate,
- descriu ce este necesar pentru a realiza aceste funcţii,
- descriu Sintaxa. (ontologia)
Diagrama de context

Figura 5.4 (a). Diagrama de context

- cutiile reprezintă activități (verbe)

- săgețile reprezintă entități (lucruri)
Fiecare cutie este etichetă, indexată și cu săgeți de pe fiecare parte reprezentând:
- Input: "lucrurile" transformate de sistem
- Output: la care sunt transformate intrările
- Controale: constrângeri / reguli ale unei activități
- Mecanisme: resurse / instrumente necesare pentru desfășurarea activității
- Apelurile sunt un tip de săgeți de mecanism care permit schimbul de informații cu alte
modele sau subsecțiuni ale modelului.
 Figura 5.4 (b). Diagrama de context

Figura 5.5. Decompoziția diagramei de Context (Decomposition Diagrama)

 А0

Цель:
А-0
Т.зрения:

А1
А2
А3

А0

А31
А32
А33

А3

Reguli de bază pentru construirea diagramei

- pe o diagramă se recomandă de a interpreta între 3 și 6 blocuri. În caz contrar diagrama
va fi greu de interpretat
- blocurile funcționale se poziționează de la stânga spre dreaptă și de sus în jos în ordinea
(dominantă) de subordonare.
- trebuie de evitat intersecții ecscesive ale arcurilor de interconexiuni.

Figura 5.6. Evitare intersecției

- ieșirea unui bloc poate fi o intrare pentru alt bloc din cadrul diagramei. Pot fi
conexiuni inverse spre ”intrare” și către ”control”

Conexiune pe control

Conexiune pe intrare
- arcurile de conexiune pot fi ”contopite” sau ”ramificate”

Contopire
Ramificare
Ramificare
 Figura 5.7. Reguli de bază pentru construire diagramei

Arcuri marginale

Arcurile pe diagrama conextuală servesc pentru a descrie interacțiunea Sistemei

cu mediul ambiant. Ele pot avea originea de la marginea diagramei și terminația la blocul
funcțional și invers în cazul ”ieșiri”. Aceste arcuri se numesc ”arcuri marginale”. ”Arcuri
marginale” se marchează cu ajutorul ICOM-semne (Input, Control, Output, Mechanism)

C1 I
C

I O1
1
I O2
2

I
C M
1
Figura 5.8. Semantica arcurilor ce conexiune

Tunelare arcuri

În unele cazuri este necesar de a indica arcuri marginale, care sunt importante
pentru nivelul respectiv dar mai puțin importante pentru diagrama paternală.
 De exemplu - careva date se utilizează doar la acest nivel.
În aceste scopuri se aplică arcuri cu tunelare

Glosare și pagina FEO

- pentru fiecare element din diagrama IDEF0 trebuie să fie creată ontologia
respectivă – noțiuni, cuvinte cheie, denumiri funcții, denumiri operații și altele ce
caracterizează obiectul (entitatea) reprezentată în diagramă.
Această ontologie se numește – glosariu, ce definește descrierea entității reprezentate.
- diagrama - FEO (For Exposition Only) – aceasta este o diagramă ce descrie unele
aspecte speciale din diagrame.
Diagramele - FEO nu sunt limitate sintaxa notației IDEF0. Ele pot conține informații
în format text, grafică, scheme, un alt punct de vedera asupra procesului dat și alte
însemnări, aceste diagrame nu se utilizează pentru dezvoltarea modelului – sunt numai
pentru discuții.

Pagina ”MASTER” (carcasa diagramei)

Este divizat în 3 câmpuri principale:

- câmpul informației de serviciu (pentru ghidarea diagramei în procesul de modelare)
- câmpul mesajelor (câmpul unde se desenează diagrama)
- câmpul de identificare (identificarea diagramei și poziționarea ei în ierarhie).

Figura 5.9. Pagina Master în IDEF0

Exemplul unui model

 1 Definirea contextului funcționării obiectuljui ce va fi informatizat
În lucrarea noastră subiectul modelării - este ”Compania” și anume procesele ce
se petrec în interiorul Companiei. Scopul modelării - construirea business-proceselor ce
se vor petrece în Companie (modelul TO-BY). Punctul de vedere - este viziunea
directorului Companiei ca persoană care cunoaște în general toată structura Companiei.

Pentru a efectua modelarea funcțională identificăm contextul fucționării

Companiei. În acest scop cercetăm toate documentele ce reglementează activitatea
Companiei: Statutul Companiei, Misiunea Companiei, Legislația ce reglementează acest
gen de activitate, Reulamentele interne ale Companiei, Standardele pentru produsele
Companiei, Nvormele interne, Fișele de post al angajaților Companiei și alte documente
ce reglamentează activitatea sa Companiei.

Dacă am definit contextul modelării putem începe construirea diagramei de

context (”cutia neagră”). Unde se indică ce avem la intrare și ce avem la ieșire fără a
detalia componentele sale (blocurile funcționale). Această diagramă este constituită
numai dintr-un singur bloc care va reflecta întreaga Companie (figura 2.1).

U SED AT: AU TH OR : R adu B as arabeanul D ATE : 03. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Modelare B us ines Proces e R EV: 04. 02. 2016 D RA FT
R EC OMMEND ED
TOP
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION

reglamentãri (control)

întrãri
iesiri
Ansamblare Calculatoare

0lei 0

mecanisme

N OD E: TITLE : N UMBER :
Ansamblare Calculatoare
A-0

Figura 5.10. Diagrama de context a Companiei

Întrări –aici se vor reflecta informația sau materialele ce vor fi procesate de această
lucrare (bloc).
Ieșire – informația sau materialele care sunt produse de această lucrare (bloc).
Reglementări (control) – proceduri, reguli, strategii, standarde și norme de care se
conduce lucrarea (blocul).
Mecanisme – resursele ce asigură executarea lucrărilor (angajații, echipamente, baze de
date și altele.
Pentru Compania noastră vor fi:
Arcurile de intrare:
 comenzile clienților – lista calculatoarelor și a notebook și completația lor
cerute de clienți
 ansamble și subansamble de la furnizori
 informații (propuneri comerciale) de la furnizori
  informații despre cererea pieței.
Arcurile de ieșire:
 produsele finite – calculatoarele și notebook-uri asamblate
 facturi pentru produsele ce vor fi livrate
 cereri pentru furnizori – lista ansamblelor, subansamblelor și materialelor
necesare Companiei
 achitările facturilor furnizorilor – achitări pentru ansamble, subansamble și
materiale necesare Companiei
 materiale de marketing a produselor proprii - price-lista, publicitate.
Arcurile de control (reglementare):
 cadrul legal – diverse acte legislative ce reglementează activitatea Companiei
 reguli și proceduri - reguli și proceduri care reglementează procesele de producere
(reguli de asamblare, reguli de testare, norme de asamblare produse, standarde
interne a produselor asamblate, procedura relațiilor cu clienții, norme de protecție
a muncii).
Arcurile mecanismelor:
 resursele umane, (ingineri în IT, programatori, marketologi, economiști)
 sistema de evidență contabilă
 sistema de evidență a contractelor
 echipamente tehnice
 unități de transport.

U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 03. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Modelare Bus ines Proces e R EV: 04. 02. 2016 D RAFT
R EC OMMEND ED
TOP
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION

carul legal
norme de asamblare
reguli de asamblare reguli de testare

procedura relatiilor cu clientii standade interne

Comenzile clientilor Cereri pentri furnizori

propuneri comerciale de la furnizori produse finite T

Ansamble si subansamble Ansamblare Calculatoare Achitãriile facturilor furnizorilor

Informatii despre cererea pietii

0lei 0
Materiale de marketing
Resursele umane
T
Echipamente tehnice
evidentã contabilã
T
T

unitãti de transport
evidentã a contratelor

N OD E: TITLE: N UMBER :
Ansamblare Calculatoare
A-0

Figura 5.11. Diagrama de context rezultativă a Companiei

2 Decompozișia funcțională de nivelul unu și doi în notația IDEF0

Scopul: de a efectua decompoziția de nivelul unu în notația IDEF0.
În sarcina precedentă a fost determinat contextul funcționării obiectului nostru și
a fost construită diagrama de context, constituită numai dintr-un bloc general care reflectă
activitatea Companiei în general (la macro) fără devalizarea componentelor principale ale
Companiei.
 În acest capitol vom evidenția care sunt subdiviziunile principale ale Companiei
ce asigură funcționalitatea ei și vom construi efectua decompoziția de nivelul unu și doi
prin costrucția diagramelor de decompoziție în notația IDEF0.
Decompoziția înseamnă partajarea unui obiect complex în părți componente care
interacționează între ele.
În acest scop identificăm procedurile principale care asigură procesul de asamblare
a calculatoarelor și laptopuri.
Procesele principale ale companiei:
 colaboratorii cercetează cerințele pieții în calculatoare și laptopuri
 vânzătorii recepționează comenzi de la clienți
 colaboratorii selectează comenzile conform tipurilor de calculatoare
 colaboratorii cercetează piața furnizorilor de ansamble și subansamble
 colaboratorii secției de achiziții comandă și procură ansamble și subansamble
necesare pentru asamblarea calculatoarelor
 colaboratorii planifică producerea produselor pe termen scurt și pe termen lung
 colaboratorii efectuează elaborare sinecostului și costul de livrare a produselor
finite
 colaboratorii asamblează și testează calculatoarele
 colaboratorii asigură deservirea pe garanții
 colaboratorii efectuează evidența produselor finite la depozit, evidența vânzîrilor,
evidența stocurilor de subansamble
 colaboratorii împachetează produsele finite conform comenzilor primite de la
clienți
 colaboratorii livrează clientului comanda respectivă
 colaboratorii efectuează evidența contabilă și evidența muncii
 colaboratorii perfectează comanda, eliberează conturi de plată, urmărește
achitările conform conturilor.

Vom grupa aceste procese pentru a evidenția subdiviziunile principale ale

Companiei ce asigură funcționalitatea ei.
Management :
 colaboratorii efectuează evidența contabilă și evidența muncii
 colaboratorii perfectează comanda, eliberează conturi de plată, urmărește
achitările conform conturilor
 colaboratorii efectuează evidența produselor finite la depozit, evidența vânzărilor,
evidența stocurilor de subansamble
 colaboratorii efectuează elaborarea sinecostului și costul de livrare a produselor
finite
 colaboratorii planifică producerea produselor pe termen scurt și pe termen lung.
Marketing și vânzări:
 colaboratorii cercetează cerințele pieții în calculatoare și laptopuri
 colaboratorii cercetează piața furnizorilor de ansamble și subansamble
 vânzătorii recepționează comenzi de la clienți.
Producer (Ansamblare și testare):
 colaboratorii selectează comenzile conform tipurilor de calculatoare
 colaboratorii asamblează și testează calculatoarele
 colaboratorii asigură deservirea pe garanții.
Achiziții și Livrări :
 colaboratorii împachetează produsele finite conform comenzilor primite de la
clienți
 colaboratorii livrează clientului comanda respectivă
 colaboratorii secției de achiziții comandă și procură ansamble și subansamble

necesare pentru asamblarea calculatoarelor.
În așa mod am evidențiat 4 subdivizi principale ala Companiei ce asigură
funcționalitatea ei și în conformitate cu aceasta vom face prima decompoziție:
 management
 marketing și vânzări
 producer (Ansamblare și testare)
 achiziții și Livrări.

Ca instrument de modelare vom utiliza aplicația AllFusion ProcessModeller (V.7.9).

Pentru a efectua decompoziția lansăm aplicația și activăm iconița Go to Child
Diagram și apoi butonăm pe lucrarea care vrem să-i facem decompoziție. Se va afișa o
fereastră Activity Box Count (figura. 5.12, figura 13) în care trebuie să alegem notația
modelului și numărul de blocuri funcționale în care va fi efectuată decompoziția (numărul
de diagrame fiică).

Figura. 5.12. Creare Decompoziție de nivelul unu

U SED AT: AU TH OR : R adu B as arabeanul D ATE : 05. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Modelare B us ines Proces e R EV: 05. 02. 2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A-0
C1 C2 C3 C4 C5 C6
U nnamed Arrow / 15 reguli de asamblare c arul legal reguli de t es tare norme de asamblare s tandade int erne

C om enzile c lient ilor U nnamed Arrow / 17

I1 0lei 1 O1

U nnamed Arrow / 18 C ereri pentri f urnizori

I2 O2
0lei 2

U nnamed Arrow / 19 U nnamed Arrow / 20

I3 O3

0lei 3

U nnamed Arrow / 21 Mat eriale de mark eting

I4 O4

0lei 4

U nnamed Arrow / 16 ev identã cont abilã ev identã a contrat elor Ec hipament e t ehnic e unit ãti de trans port

M1 M2 M3 M4 M5
N OD E: TITLE : N UMBER :
Ansamblare Calculatoare
A0

Figura 5.13. Decompoziție de nivelul unu

În continuare atribuim denumiri pentru blocurile funcționale și conectăm săgețile

marginale cu blocurile funcționale ( figura 5.13).
US ED AT: AUTHOR: Radu Basarabeanul DA TE: 05.02.2016 WORKING RE ADER DA TE CONTE XT:
PROJECT: Modelare Busines P rocese RE V: 05.02.2016 DRAFT
RE COMMENDED
NOTES : 1 2 3 4 5 6 7 8 9 10 PUBLICATION A-0
C1 C3 C2 C4 C5 C6
proceduri relatii cu clientii
carul legal

Comenzile clientilor reguli de testare norme de asamblare

I1
Mnagment cereri pentru furnizori
O1
0lei 1 reguli de asamblare standade interne

propuneri de la furnizori
I2 Marketing si Materiale de marketing
O4
informatii despre cerea pietii vânzãri
I4
0lei 2

Ansamblare
ansamble si subansamble
I3 si testare
0lei 3
evidentã a contratelor

Achizitii produse finite

O2
si Livrãri livrãri
O3
0lei 4

evidentã contabilã unitãti de transport

Echipamente tehnice

resurse umane

M1 M2 M3 M4 M5
NODE: TITLE : NUMB ER:
Ansamblare Calculatoare

Figura 5.14. Atribuim denumiri pentru blocuri și conectăm săgețile marginale

În continuare interconectăm blocurile funcționale pentru a asigura executarea

proceselor de producere și obținem diagrama finală de nivelul unu ( figura 2.6).

U SED AT: AU TH OR: R adu Bas arabeanul D ATE: 24. 01. 2016 W OR KI NG R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 10. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A-0

r eguli r e lat ii cu clie ntii s tandar de r eguli de as am blar e

inte r ne r egulide te star e nor m e de as am blar e
Cadr ul Le gal
ce re i pe ntr u fur nizori
Infor m atii bancar e

ofer te f ur nizor i Em isie fact ur i

manage me ntul
com enzi de la clienti companie i
noi cer inte
achitãri facturi
0 lei 1 plas ar e
m ate riale m ark e ting
com enzi
planuri
marke ting Inf. com e nz i plas ate
m ar ke ting piatã
si vânzãri
0 lei 2
inf.plas ar e produs e
com enzi finite
ans am ble/s ubansam ble ansamblare produs e s i
si te stare s er vicii
achizitii
0 lei 3
inf. pr odus e si livrare
as am blate s uplinir e
Achizitii e le m ente
s toc 0 lei 4 achzitionate
e le m ente produs e
finite

r es urs e um ane
contabilitat e
e vide nt ã e chipam ente te hnice unitãti de
contracte tr ansport
N OD E: TITLE: N UMBER :
Asamblare PC, lãptopuri si tablete
A0

Figura 5.15. Blocuri Funcționale, diagrama decompoziție de nivelul unu

2.3 Decompoziţie de nivelul doi în notația IDEF0

Din diagrama de decompoziție de nivelul unu (figura 2.6) se vede că blocurile

funcționale Marketing și Vânzări și Asamblare și Testare au mai multe interconexiuni,
asta vorbește de faptul că în aceste blocuri se petrec mai mule procese, este necesar de a
adânci decompoziția la următor nivel - nivelul doi ( figura 2.7).

U SED AT: AU TH OR : R adu B as arabeanul D ATE : 24. 01. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 05. 02. 2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

s tandarde interne regili relat ii cu noi c erint e

c lient ii

planuri
M arke ting
ofer te f ur nizor i infor m atie pata
Piata e xternã e xte rnã
0 lei 1

m ate riale m ark e ting

Analiza Pietii
0 lei 3

r ezultatul
analize i
m ar ke ting piatã infor m atie
M arche ting piat a
Piata inte rnã inte r nã Elaborare
r ecom andãri
com enzi de la clie nti 0 lei 2 Re comandãri
0 lei 4

e vide nt ã
contabilitat e
contracte

N OD E: TITLE : N UMBER :
marketing si vânzãri
A2

Figura 5.16. Diagrama de decompozitie de nivelul doi Marketing și Vânzări

În procesul de analiză a proceselor ce se petrec la testarea pieții externe și interne

sau evidențiat 4 blocuri funcționale –vezi figura 2.8.

În acelaș mod efectuăm decompoziția pentru Blocul Funcțional ”Asamblare și

testare”.
U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 05. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 05. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

regulide t est are reguli de asamblare s tandarde internenorme de asamblare

U nnamed Arrow / 32

rec om andãri
0 lei 1
noi c erint e

produs e

0 lei 2

ans ambe/ subansamble

0 lei 3

s uplinire s t oc

0 lei 4

echipamente t ehnic e c ontabilitat e res urs e umane

N OD E: TITLE: N UMBER :
ansamblare si testare
A3

Figura 5.17. Diagrama de decompozitie denivelul doi ”asamblare și testare”

În procesul de analiză a proceselor ce se petrec la asamblarea produselor sau

evidențiat 4 blocuri funcționale –vezi figura 5.18.

U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 05. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 05. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

r eguli de s tandar de U nnamed Arrow / 32

as am blar e inte r ne

r egulide te star e
nor m e de
r ecom andãri as am blar e
Asamblare
PC
0 lei 1

PC asam blate
ans am be /s ubans am ble
noi cer inte
Asamblare Te stare
laptopuri produse
0 lei 3
0 lei 2
produs e
finite
s uplinir e s toc
lapt opuri Elaborare conditii
as am blate
de garantie
0 lei 4
ce rt ificat
r ebut garantie

e chipam ente t ehnice contabilitat e r es urs e um ane

N OD E: TITLE: N UMBER :
ansamblare si testare
A3

Figura 5.18. Diagrama de decompozitie de nivelul doi ”asamblare și testare”

Modelarea proceselor. Standardul IDEF3

O bună definiție a unui proces o descrie ca o serie de pași sau acțiuni legate de
realizarea unui rezultat.
Un proces are următoarele caracteristici:
- un punct de pornire și un punct final. Acesta este domeniul de aplicare
- un scop sau un scop pentru rezultat
- reguli care reglementează standardul sau calitatea intrărilor pe tot parcursul
procesului
 - de obicei este legată de alte procese
- poate fi simplă și scurtă, sau complexă și lungă
Beneficiile modelării proceselor
- documentarea proceselor curente de standardizare
- oferiți liniilor directoare pentru noii membri ai procesului să reducă curba de învățare.
- capturează și analizează procesele AS-IS.
Proiectarea / redesignul scenariilor TO-BE i.
Testați proiectarea unui nou proces înainte de a începe un proiect de dezvoltare
costisitor.
IDEF3 Prezentare generală
- secțiunea 1: Elemente de bază ale diagramei de proces
- secțiunea 2: Documentarea fluxului de proces
- secțiunea 3: Îmbunătățirea descrierii procesului

Exemplu Limbi de modelare a proceselor de afaceri (metode):

- Format de interacțiune proces (PIF)
- Limba de specificare a procesului (PSL)
- Manualul MIT al proceselor organizaționale
- IDEF0 / IDEF3
- Diagrama de activitate a UML (diagrama de stare)
- SAP R / 3: EPC
- Petri Net
- Model de proces de afaceri, BSDM
- RAD, RACD
- Flow-Control, Diagrama fluxului de date
Cadru: Model de referință al fluxului de lucru (WfMC)
Recent, versiunea SW BPM: XPDL, OWL-S, BPML,
BPEL4WS, WSML.
Ce reflectă modelul în IDEF3?
În general, un рroces – sunt acțiuni consecutive într-o ordine respectivă.
Prin urmare, modelarea proceselor în IDEF3 permite:
- reflectarea consecutivității proceselor
- evidențierea logicii interacțiunilor elementelor sistemului.
Scopul IDEF3 – de a le facilita munca Analiștilor de a descrie situația când procesele
se execută într-o ordine determinată precum și obiectele ce participă la aceste procese.

Elementele de bază la modelare dinamică în IDEF3

- unități de lucru (UOW, Unit of Work)
- conexiuni
- joncțiuni (Intersecții)
- obiectele de referință.
Figura 5.19. Conotațiile IDEF3
 Figura 5.20. Regulile de construire model

Terminologii
a) schema de proces v.s. modele de proces
instanțierea / activarea unui proces
b) constrângerile temporale ale proceselor:
1) link-uri precedente
2) legături de dependență
3) link-uri de control
4) de asemenea, uneori denumită ordonare temporală sau ordonare între procese.

c) Activarea unui proces:

1) execuția procesului
2) adoptarea procesului.
Figura 5.20 (a). Regulile de construire model
 Figura 5.20 (b). Regulile de construire model

Basic Junction Combinations & Temporal Constraints on Activations

Figura 5.21 (a). Joncțiuni între elementele unui model

Cazul 1: După atingerea joncțiunii divizate se va genera o instanță de B și C;

joncțiunea și-join nu este terminată decât dacă ambele instanțe de B și C își termină
activările.
Cazul 2: După atingerea joncțiunii divizate, se generează cel puțin o instanță de tip B sau
C;
joncțiunea or-join nu este terminată decât dacă cel puțin o instanță a lui B sau C își termină
activările.

Figura 5.21 (b). Joncțiuni între elementele unui model

Cazul 3: După atingerea joncțiunii xor-split, se generează exact o instanță de tip B sau C;
conexiunea xor-join nu este terminată decât dacă instanța generată de B sau C își termină
activarea.
Cazul 4: Deși cazurile de B și C sunt generate după activarea joncțiunii și divizării. Nu
este necesar ca ambele instanțe să fie terminate înainte ca activarea să treacă prin
joncțiunea or-join la următoarea instanță de proces.

Alte combinații de joncțiuni de bază minore

Figura 5.21 (c). Joncțiuni între elementele unui model

Juncțiile sunt tipuri speciale de activități, cu semantică pre-determinată a logicii

proceselor.
Astfel de combinații simple permit menținerea practicilor de modelare de la 1 la
mulți și de la multe la 1 pentru joncțiuni; permițând în același timp impunerea unor
constrângeri asupra proceselor înainte și după acestea.
Este posibil să le scurtați pe acestea folosind o singură joncțiune, când începe și
se termină cu aceeași joncțiune.

EXEMPLE MODELARE PROCESE IDEF3

Exemplul 1
Căi de execuție ale unui model de proces într-o mașină secvențială

Figura 5.22 (a). Exemplu modelare procese

Constrângeri:
a → exe(b, c, d), b → exe(e, f), (e ∨f) ∧(c ∧d) →exe(g), (note that xor(e, f) and par(c, d) )
Given that: exe(List) → List (a simplified operation)

Calcularea tuturor căilor de execuție:

a, par(b, c, d), xor(e, f), g (6x2 = 12 aths)
a, par(b, c), e, d, g 2 paths
a, par(b, c), f, d, g 2 paths
a, par(b, d), e, c, g 2 paths
a, par(b, d), f, c, g 2 paths
a, b, xor(e, f), par(c, d), g (2x2 =4 paths)
În total, there are 24 possible execution paths.

Exemplul 2
Costul de timp al proceselor într-o mașină paralelă
Presupunând că toate procesele sunt executate cu succes, astfel încât să nu existe
o manipulare excepțională neașteptată necesară pentru a face orice întârziere;
și atunci când:
Nu există timp de așteptare pentru a începe executarea unui proces de îndată ce sa
atins în modelul de proces. Și când costul de timp al unui proces poate fi calculat precum
este arătat mai jos:
- procese paralele ale lui p1, pn: max (p1, ..pn)
- procese secvențiale ale lui p1, pn: sum (p1, ..pn)
- alegerea proceselor între p1, pn
- min (p1, ..pn) - cel mai bun caz
- max (p1, ..pn) - caz mai rău.
Studiu de caz: utilizați exemple de modele pentru a calcula costul de timp posibil.
Costul maxim și cel minim al unui model de proces

Figura 5.22 (b). Exemplu modelare procese

Care este costul maxim al timpului? Care este ruta de execuție?

Time cost: 3 + 18 + 12 = 33
Execution route: a, (b, c, d), e, g
Max(be, c, d) = 5+13 = 18
Care este costul minim al timpului? Care este ruta de execuție?
Time cost: 3 + 9 + 12 = 24
Execution route: a, (b, c, d), f, g
Max(bf, c, d) = 9

Exemplul 3
În acest exeplu o să modelăm procesele Companiei de asamblare lăptop-uri și
PC-uri pentru care am efectuat modelarea funcțională în standardul IDEF0.

O să efectuăm studiul proceselor ”Asamblare și testare”, blocul functional А3

(vezi diagramele IDEF0).
Executatrea acestei lucrări se începe odată cu procesul ”plasare comenzi” la
asamblare. Prima acțiune se începe cu:
- verificarea dacă sunt destule ”asamble și subansamble” și
- se ”comandă asamble și subansamble” de la depozit (elementele ce
lipsesc).
În continuare se pregătesc asamblele și subansamblele pentru asamblare (scoatere
din cutii, dcuparea capace de le fișele de inrare și ieșire...). În continuare se începe
procesul de asamblare:
- instalare plăcii de bază în carcasă și instalarea procesorului pe placa de
bază, Instalate (RAM) memorie opoerativă, Instalare Hard-Disk
Aceste acțiuni se efectuează pentru fiecare PC și nu depind de configutația
calculatorului. În continuare în dependență de comanda clientului pot fi instalate:
- DVD, TV- tuner, Card-ryder
Cu aceasta se termină asamblarea calculatotului. La următoarea operație:
- se instalează Sistemul de Operare,
- la solicitarea clientului pot fi instalate și alte aplicații soft.
Ultima acțiune la această etapă este perfectarea raporturi ”Raport PC asamblate” și
”Raport rezultate asamblare”.
Crearea diagramei de decompoziție în notația IDEF3
Pentru aceasta înserăm pe diagrama A3 lucrarea ”Asamblare și testare” butonăm
iconița "Go to Child Diagram" selectăm notația IDEF3.
U SED AT: AU TH OR: R adu Bas arabeanul D ATE: 09. 02. 2016 W OR KI NG R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 09. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A3

0 lei

0 lei

0 lei

0 lei

N OD E: TITLE: N UMBER :
Asamblare PC
A31.1

Figura 5.23. Diagrama inițială în notația IDEF3 nivelul unu

În Diagrama de decompoziție” fiică” oricând pot fi adăugate noi lucrări, din

această cauză când alegem numărul lucrărilor putem indica un număr de lucrări arbitrar.
La crearea diagramei ”fiică” aplicația BPWin nu transferă săgețile marginale din
diagrama maternă, ele trebuie înlocuite cu blocuri ”obiecte de referință”:
”plasare comenzi”, ”asamble și subansamble”, ”comanda asamble și subansamble”
”Raport PC asamblate” și ”Raport rezultate asamblare”.
– pentru asta activăm iconița ”R” (Referent) de pe bara de instrumente și în ferestruica de
dialog indicăm ”Arrow” și alegem din lista denumirilor de săgeți conexiunea necesară.

Figura 5.24. În ferestruica de dialog Referent

În continuare construim lucrările și conexiunile între lucrări în ordinea desfășurării

proceselor de asamblare și obținem diagrama finală (imaginea 3.5)
U SED AT: AU TH OR: R adu Bas arabeanul D ATE : 09. 02. 2016 W OR KI NG R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 10. 02. 2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A3

plas ar e r eguli de
com enzi 0 lei as am blar e nor m e de
com anda as am blar e com ponente ce lipse s c
ans am be /s ubans am ble
la depozit
0 lei 2
Ve r ificar e
Ans am ble/ 0 lei 0 lei 0 lei
s ubans am ble X 0 lei
Ins talar e plãcã Ins talate
pre gãtir e Ins talar e
1 asam blele / de bazã (RAM ) Hard-Dis k
J1 subans am ble le s i proce sor
7 10
com ponente ne ce sar e 3 9

Rapor t PC
As am blate
0 lei 0 lei
Ins talar e Ins talar e
DVD Aplicatii
4 14 0 lei
0 lei Per fe ctar e
0 lei
O ins talar e Ins talar e
X X r apor t
TV- tune r O SO 15

J2
11 13
J8 J9
0 lei
J10 Rapor t
ins talar e as am blar e
Car d-ryde r nor m e de
12 r eguli de as am blar e
as am blar e

N OD E: TITLE : N UMBER :
Asamblare PC
A3.1.1

Figura 5.25. Diagrama de decompoziție IDEF3 nivelul unu

Să vedem care sunt particularitățile principale a acestei diagrame.

După ce efectuăm lucrarea ”verifică prezența Asabmbe/subansamble” sunt
posibile două acțiuni - ori comandăm la depozt elementele ce lupsesc ori, dacă sunt toate
elementele necesare se execută lucrarea ”pregătire Ansamble/Subansabmle”- din
această cauză noi am inclus joncțiunea ” Sincron «Sau» (Synchronous OR). Lucrările
”pregătire Ansamble/Subansabmle” și ”instalare placa de bază și procesor” se
interconectează cu săgeata ”Fluxuri de obiecte” . Asta indică că între lucrări
se transmit obiecte. Lucrările ulterioare se interconectează cu săgeata
”conexiune predcesoară (Precedence)” deoarece ele arată conscutivitatea acțiunilor
asupra acelorași obiecte. După instalarea Hard-Discului este posibil instalarea DVD,
ТВ-tuner, Card-reader sau alte componente. Pentru aceasta am utilizat joncțiunea
”asincron «sau» (Asynchronous OR)”. Aceiași joncțiune construim și după terminarea
lucrării. În continuare după ce instalăm SO (Sistemul Operațional), la cererea clientului,
pot fi instalate și alte Aplicații soft, sau dacă nu, se perfectează Rapoartele. Pentru aceasta
noi am utilizat joncțiunea Exclusiv (exclude «sau») XOR (Exclusive OR), după cum
știm, după joncțiunea poate fi numai joncțiunea , din această cauză înaintea
lucrării ”Perfectare Raport” am utilizat aceiași joncțiune.

Rezumat
Sunt preferate legăturile (conexiunile)
-One-many and many-one relationships only
Diferența dintre joncțiunile split (fan-out) și join (fan-in):
- atunci când se ajunge la o joncțiune divizată, aceasta plasează controlul logic a
procesului la procesele ce urmează acestuia - aceasta este o relație 1-la-multe
- când se ajunge la o joncțiune de asociere, se asigură că procesele înainte de a se întâlni
cu constrângerile de joncțiune înainte de a trece la următorul nod - aceasta este o relație
multi-la-unu.
Combinații de joncțiuni ilegale:
- de exemplu. combinările și/xor și xor /și , oricare altele?
Sincronizări și tipuri de joncțiuni.
IDEF3 oferă multe relații fundamentale între două procese.

Modelarea obiect orientată

Standardul DEF4

Dezvoltarea programării orientate pe obiecte a facilitat în mod semnificativ

procesul de dezvoltare a produselor software. Cu toate acestea, dezvoltarea produselor
software cu un design bun, fiabilitate, modularitate şi avînd un grad de utilizare înalt, este
încă problematică.
Standardul IDEF4 a fost dezvoltat pentru utilizarea corectă a tehnologiilor obiect-
orientate. Conform standardului IDEF4 , procesul orientat pe obiecte este reprezentat cu
ajutorul unor diagrame, care ne ajută să analizăm acest proces şi să descoperim punctele
cheie.
Particularitate a standardului IDEF4 este posibilitatea de reprezentare a influenţei
eredității claselor, compoziţiei obiectelor, descompunerii funcţionale şi polimorfismul pe
proiectarea obiectelor.
Procesul proiectării obiect-orientate prin metoda IDEF4 este împărţit în blocuri
separate. Fiecare subrulare are notaţii, care indică ce decizie ar trebui să fie acceptată în
timpul procesului de proiectare şi cum va influenţa alte subrulări.
Diagrama comună, care descrie întregul proiect, nu este dezvoltată de standardul
IDEF4. Acest lucru ne permite evitarea confuziile și găsirea rapidă a informațiiei necesare
cu privire la proiect.
Standardul IDEF4 permite planificatorului, găsirea ușoară a compromisurilor între
ereditatea claselor, compoziția claselor, descompunerea funcțională și polimorfismul în
proiect.
Modelul IDEF4 este format din 2 submodele: modelul claseselor și modelul
metodelor.
Aceste submodele sunt conectate între ele cu ajutorul unei scheme de distribuție și
conțin toată informația cu privire la proiect. Din motivul mărimii subrulării claselor și
metodelor, planificatorul niciodată nu le folosește ca un întreg, dare folosește un set de
diagrame mai simple și caietul de sarcini care conține o parte din informații.
 Figura 5.26. Submodele: modelul claseselor și modelul metodelor

Un submodel de clase este format din următoarele tipuri de diagrame:

- diagrame de ereditate, ce definesc ereditatea claselor
- diagrame de tipuri, ce definesc compoziția claselor
- diagrame de protocoale care definesc protocoale a metodelor de apel
- diagramele de creare a obiectelor (Instanțierea), care descriu procesul de creare a
exemplarelor de presetare a obiectelor de clase.
Un submodel de metode este format din următoarele diagrame:
- diagrame a metodelor de sistematizare (Metoda taxonomiei), care clasifică
metodele după similitudinea comportamentului
- diagrame de clienți, care reprezintă clienți și operațiunile de furnizori, astfel încât
să se definească decopoziția funcțională.

Diagrama de ereditate

Diagrama de ereditate reprezintă legăturile ereditare între clase. De exemplu, în

imaginea de mai jos este reprezentată structura de ereditate și comportamentul clasei
”Filled-Rectangle”.
 Figura 5.27. Diagrama de ereditate

Diagramele de protocoale

Diagramele de protocoale definesc argumente de clase pentru protocoale de apel.

În imaginea de alături este arătată diagrama de protocol pentru ”Fill-closed-object”.
Este evident din diagramă că ”Fill-closed-object” primește cereri de la obiectul ”Polygon”
(argumentul primar) și ”Color object” (argumentul secundar) și returnează cererea spre
obiectul ”Polygon„.
 Figura 5.28. Diagrama de protocoale

Diagrama obiectelor

Diagramele obiectelor vine în diagrama de tipuri și descrie situațiile posibile la

compoziția legăturilor dintre crearea obiectelor.

Figura 5.29. Diagramele obiectelor

Diagrama de sistematizare a metodelor

Diagrama de sistematizare a metodelor descrie anumit tip de comportament al

sistemului la influența pe set de metode. Săgețile de pe diagramă sunt îndreptate spre
influențele suplimentare , realizate la seturi de metode. Seturile de metode sunt grupate
în mod corespunzător pentru condiții suplimentare obligatorii.
În exemplul dat, un set de metode ‘Print’ are o condiție obligatorie ca obiectul
trebuie să fie tipărit și setul de metode ‘Print-Text’ – că obiectul tipărit trebuie să fie text.
 Figura 5.30. Diagrama de sistematizare a metodelor

Diagramele de clienți

Diagramele de clienți reprezintă clienții și operațiunile de furnizori. Săgețile duble

pe diagramă sunt îndreptate de la operația chemată spre operația ce cheamă.
În exemplul dat este prezentată o diagramă de clienți. Pe această diagramă operația
”Redisplay” care aparține clasei ”Redisplayable-object” solicită operația clasei
”Erasable-object” și operația ”Draw” a clasei ”Drawable-object class”

Figura 5.31. Diagrama de clienți

Standardul IDEF4 presupune nu doar prezentarea grafică, dar și informații

suplimentare despre diagrame de ereditate, metode de sistematizare și de tipuri care sunt
cuprinse în caietul de sarcini. Conform standardului IDEF4 există caietul de sarcini a
claselor invariante și specificațiile condițiilor obligatorii.
Specificațiile claselor invariante sunt conectate cu diagrame de ereditate și
definesc influențele care formează proprietăți ale fiecărei clase de obiecte. Pentru fiecare
clasă există o specificație separată. De exemplu, proprietățile “Each square has four sides”
și “All square sides are equal” sunt proprietățile specificației clasei Square.
Specificațiile condiții obligatorii sunt conectate cu seturi de metode în schemele
metodelor de sistematizare și definesc condițiile obligatorii, care influențează asupra
metodelor și ce metode ar trebui satisfăcute. Pentru fiecare set de metode există o
specificare a condițiilor obligatorii. De exemplu, setul de metode "Pop", care șterge
valorile din stivă, ca o condiție obligatorie va avea absența unor încercări de a șterge
valoarea din stivă în cazul în care stiva este goală.
 Standardul IDEF 4 este dezvoltat de către proiectanți profesioniști și programatori
de la Laboratorul Air Force Armstrong SUA și are scopul de a facilita utilizarea
tehnologiilor obiect-orientate la dezvoltarea de software.

Modelarea logică a Fluxurilor de Date în conotația DFD

Flux de date?
- Flux de Date - totalitatea informațiilor transmise, într-un interval de timp
determinat, de la o sursă de informație la un receptor, printr-o mulțime de canale
informaționale
- mai multe: fluxuri informationale intr-un sistem
Conexiuni ce se stabilesc intre diferitele componente ale fluxurilor:
- Pe Orizontală
- Pe Verticală

Figura 5.32. Conexiuni ce se stabilesc intre diferitele componente ale fluxurilor

Indiferent de metodologiile folosite în realizarea unui sistem/aplicaţie, toate

apelează la operaţiunea de modelare logică a datelor şi prelucrărilor sub formă de
diagrame, diferenţele constând doar în folosirea mai pronunţată a diagramelor pentru
descrierea sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de
date fizice şi diagrame ale fluxului de date logice. Altele apelează la combinaţii de
diagrame, tabele şi forme descriptive. Diagrama de context scoate în evidenţă aria de
întindere a sistemului analizat, prin specificarea elementelor din interiorul organizaţiei şi
a celor externe, sub denumirea de entităţi externe sistemului analizat.

Diagramele fluxurilor de date (DFD)

- diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie,

reliefează funcţiile de prelucrare a datelor executate de către sistemul
informaţional curent
- diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor şi cerinţele funcţionale ale noului sistem
 - descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicţionare ale proiectelor
sau depozitele CASE (repository)
- diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer
al datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc
şi modele ale proceselor de prelucrare, iar operaţiunea se numeşte modelarea
proceselor
- DFD reprezintă doar una din tehnicile de analiză structurată. Tehnica de redare a
proceselor de prelucrare prin intermediul diagramelor fluxurilor de date a căpătat
noi accepţiuni prin încorporarea ei în instrumentele de analiză şi proiectare cu
ajutorul calculatorului, adică în instrumente CASE
- DFD – Data Flow Diagrams – Diagrama Fluxurilor de Date
- Modelul DFD al Sistemului este prezentat ca o ierarhie a diagramelor a fluxurilor
de date, ce descriu procesele asincron de transformare a datelor de la intrare în
sistem, procesarea lor și livrare utilizatorului
- scopul principal al acestei reprezentări îl constitue – de a identifica cum fiecare
proces transformă datele de intrare în date de ieșire și de a stabili relațiile dintre
aceste procese.
- Remarcă. Modelele DFD- în multe cazuri se utilizează ca complementare a
modelelor IDEF0 și IDEF3 pentru a relata circulația documentelor în sistemele
informaționale corporative

Simboluri și notații folosite în DFD

Două sisteme comune de simboluri sunt denumite după numele autorilor ce le-au creat:
- Yourdon and Coad
- Yourdon and DeMarco
- Gane and Sarson
O diferență majoră în simbolurile lor este faptul că Yourdon-Coad și Yourdon-
DeMarco folosesc cercuri pentru procese, în timp ce Gane și Sarson folosesc
dreptunghiuri cu colțuri rotunjite, uneori numite comprimate (tabletă). Există și alte
variații ale simbolurilor, astfel încât lucrurile importante pe care trebuie să le păstrați în
minte trebuie să fie clare și coerente în formele și notațiile pe care le utilizați pentru a
comunica și a colabora cu alții.
Folosind regulile sau liniile directoare ale convenției DFD, simbolurile descriu
(reprezintă) cele patru componente ale diagramelor fluxului de date.
 Figura 5.33. Conotațiile DFD

- DFD reguli și sugestii

- orice proces trebuie să posede cel puțin o intrare și ieșire
- orice depozit de date trebuie posede cel puțin
- datele păstrate în sistem trbuie să treacă prin procese
- toate procesele in DFD intractioneză cu un alt proces sau depozit de date
Proces
- nici un proces poate avea doar ieșiri (un miracol)?
- nici un proces poate avea doar intrări (gaură neagră)?
 - un proces are o etichetă (verb, fraza)
Depozit de date
- datele nu pot fi mutate de la un Depozit la altul.
- datele nu se pot deplasa dintr-o sursă externă la un Depozit de date
- datele nu se pot deplasa în mod direct de la un Depozit de date la o sursă de
date
- depozit de date are o etichetă ( substantiv)
Sursa
- datele nu se pot deplasa în mod direct de la o sursă
- o sursă are o etichetă – substantive
Flux de date
- un flux de date are o singură direcție de traversare a datelor(flux) între simboluri
- structura Fork ne arată că exact aceleași date provin dintr-o locație comună și
sunt recepționate de două sau mai multe procese, depozite de date sau surse
- structura Join ne arată că exact aceleași date provin de la oricare două (sau mai
multe): procese, depozite de date sau surse acestea fiind diferite sosind într-o
locație comună
- un flux de date nu poate merge direct înapoi la același proces de la care a provenit
- un flux de date într-un depozit de date înseamnă actualizare
- un flux de date dintr-un depozit de date înseamnă a prelua sau de a folosi
- un flux de date are ca o etichetă un substantiv.

Balansarea DFD-urilor

Cînd discompunem o DFD trebuie să conservăm intrările și ieșirile a procesului la

nuvelul următor de decompoziție. Aceasta se numește balansare. Noi putem împărți
fluxul de date în fluxuri de date mai mici separate ître ele în componența diagramei de
nivel mai jos.
Patru Reguli Adiționale Avansate de Balansare a DFD-urilor
Un flux de date compus un la nivel superior poate fi împărțită în subfluxuri la nivelul
următor, dar nu pot fi adăugate date noi și toate datele din fluxul cumpus trebuie să fie
lulate înconsiderație de unul sau mai multe subfluxuri.
Datele de intrare pentru un proces trebuie să fie suficientă pentru a produce ieșirile
(inclusiv și pentru datele deintrare) din proces. Astfel, toate ieșirile pot fi produse, precum
și toate datele din intrări se pot muta undeva, fie la un alt proces sau la un depozit de date
în afara procesului pe o DFD mai detaliată, care indică o descompunere a acestui proces.
La cel mai scăzut nivel al DFDS, noi fluxuri de date pot fi adăugate pentru a
reprezenta datele care sunt transmise în condiții excepționale; aceste fluxuri de date de
obicei reprezintă mesaje de eroare sau notificările de confirmare.
Pentru a evita liniile fluxului de date ce se intersectează, puteți repeta deposit de date
sau sursă de date pe DFD.

Reguli de desenare a DFD-urilor

 Nivele și straturi DFD

De la Diagrama de Context la pseudocod

O diagramă a fluxului de date poate fi detalizată prin utilizarea nivelelor și straturilor.

Nivelele DFD sunt numerotate de la 0, 1 sau 2, și, ocazional, chiar nivelul 3 sau mui mult
. Nivelul necesar de detalizare depinde de domeniul de aplicare a ceea ce se încearcă să
se realizeze.
DFD de Nivelul 0 se mai numeste și diagramă de Context. Acesta aste o shiță a
întregului sistem în ansamblu ce aste analizat sau modelat.Aceata ne prezintă sistemul ca
un proces de nivel înalt cu relații cu entități externe. Ea e ușor de lămurit la un public
larg precum: analiști de afaceri, analiștii de date și dezvoltatori.
DFD de Nivelul 1 oferă o descompunere mai detaliată a parților componente a
diagramei de context. Sunt atenționate principalele functii efectuate de sistemul în studiu
împărțind procesul de nivel înalt a diagramei de context în subprocese.
DFD de nvelul 2, apoi merge cu un pas mai jos analizînd părțile ale nivelului 1.Va
fi necesar demai mult text pentru a ajunge la nivelul necesar de detaliu cu privire la
funcționarea sistemului.
Progresînd la nivele 3, 4 și mai departe posibil, darutilizarea a mai mult de 3 nivele
e mai puțin frecventă. Acest lucru poate crea o complexitate pe care o face dificil de a
comunica, compara sau modela eficient.
Cu ajutorul straturilor DFD, nivelele în cascadă pot fi imbricate direct în diagramă,
oferind un aspect mai curat, cu acces ușor la nivele inferiore.
Cunoscînd bine DFD, dezvoltatorii și designerii îl pot folosi pentru a scrie pseudocod,
care e o combinație de limba engleză și limbaje de programare. Pseudocodul facilitează
dezvoltarea codului real.
 Figura 5.34. Nivele și straturi DFD

Numerotarea nivelelor

Înrtr-o diiagramă DFD cu multe nivele e ușor de uitat la ce nivel ne aflam întrun
moment de timp. Deaceea fiecare nivel are o numerotare diferită pentu procesele din
diagramă.’Nivelul’ corespunde numărului de cifre zecimale penru a defini un proces in
acesta De exemplu:
- Context Diagram Process labeled “0”
- Level 0 Processes labeled 1.0, 2.0, 3.0, .
- Level 1 Processes labeled 1.1, 1.2, 1.3, .
- Level 2 Processes labeled 1.11, 1.12,...

Figura 5.35(a). Unele reguli la construcția Fluxurilor de Date

Figura 5.35(b). Unele reguli la construcția Fluxurilor de Date

Figura 5.35(c). Unele reguli la construcția Fluxurilor de Date

Figura 5.35(d). Unele reguli la construcția Fluxurilor de Date

 Modelarea datelor. Standardul: IDEF1x

Aplicabilitatea IDEF1x

IDEF1x – Este o tehnică de modelare a informației și este utilizată pentru a modela

datele într-un mod standard, consecvent, previzibil, în scopul de a gestiona resursa.
Utilizrea acestui standard este puternic recomandată pentru toate proiectele care
necesită un mijloc standard pentru definirea și analiza resurselor informaționale în cadrul
unei Companii.
Astfel de proiecte includ:
- incorporarea unei tehnici de modelare a datelor într-o metodologie
- utilizarea tehnicii de modelare a datelor pentru managementul resursei
informaționale
- utilizarea tehnicii de modelare a datelor pentru integrarea sistemelor
informaționale
- utilizarea tehnicii de modelare a datelor pentru proiectarea bazelor de date.

Noțiuni de bază

Diagramele (ERD) « entitate – relaţii » sunt cele mai raspândite instrument de modelare
a datelor. Cu ajutorul ERD sunt detalizate depozitele de date în diagramele DFD.
Sunt documentate aspectele informaționale ale sistemului, inclusiv:
- identificarea obiectelor importante pentru domeniul obiectiv - entitățile
- identificarea proprietăților acestor obiecte - atribute și
- identificarea legăturile cu alte obiecte - relații.
Entitatea (Entity) este mulțimea obiectelor reale sau abstracte, care posedă aceleași
atribute sau caracteristici. Un obiect al sistemului poate fi reprezentat numai printr-o
singură entitate, identificată în mod unic. Numele entității nu va fi legat de un exemplar
(instanță) concret al obiectului. Fiecare entitate va poseda un identificator unic. Fiecare
exemplar al entității va fi identificat în mod univoc. Fiecare entitate va poseda anumite
proprietăți:
- nume unic
- unul sau câteva atribute
O entitate poate avea un număr arbitrar de relații cu alte entități ale modelului.

Relație și atribut

Relația (Relationship) este o asociere (căreia i-a fost atribuit un nume) între două
entități, relevantă pentru domeniul obiectiv considerat.
Relația este asocierea între entități în care fiecare instanță (exemplar) a unei entități este
asociată cu un număr arbitrar (inclusiv zero) de instanțe (exemplare) ale celeilalte entități,
și invers.
Atributul- este caracteristica entității, relevantă pentru domeniul obiectiv și
utilizată la: calificarea, identificarea, clasificarea și caracterizarea cantitativă sau
exprimarea stării entității.
Atributul reprezintă tipul de caracteristici sau proprietăți, asociate cu o mulțime de obiecte
reale sau abstracte (persoane, locuri, evenimente, stări, idei, obiecte etc.).
 Modelarea datelor este un proces analitic impus nu numai de nevoia de extragerea
caracteristicilor obiectelor date ci – deseori – și de necesitatea de a genera date noi din
datele inițiale.
Extragerea caracteristicilor are ca finalitate estimarea vizuală a informației cuprinsă
în structuri complexe de date. Generarea datelor noi are la bază modelarea matematică a
problemei pentru care au fost culese datele experimentale și are ca finalitate estimarea
vizuală a informației, achiziția de noi cunoștințe.
Un model de date reprezintă o colecţie integrată de concepte necesare descrierii
datelor, relaţiilor dintre ele, precum şi a constrângerilor asupra datelor (Connolly ş.a.
1998). Modelul de date este utilizat la descrierea schemei bazei de date, definind structura
datelor, legăturile dintre acestea, semantica lor, precum şi constrângerile impuse, deşi nu
este obligatoriu ca întotdeauna acestea să fie regăsite în orice model de date. Pe scurt, un
model de date este utilizat pentru a reprezenta date despre date.
Modelele de date oferă înţelegerea descriptivă necesară definirii schemelor logice şi
externe şi sunt utile descrierii formale a schemei bazei de date.
Schema logică a unei baze de date reprezintă o descriere abstractă a unei porţiuni din
realitatea modelată împreună cu instanţele bazei de date.

Destinație IDEF1X

IDEF1X este o metodologie pentru eleborare Baze de Date Relaționale.

Pentru aceasta IDEF1X utilizează o sintaxă convențională elaborată special în
acest scop pentru a putea construi scheme conceptuale.
Schemă conceptuală o să numim – Reprezentare generală a datelor (informației)
în cadrul Companiei, care este independentă de realizarea finală și de platforma pe care
va fi realizată această Bază de Date.
Utilizarea metodologiei IDEF1X este rațională pentru a construi structura logică
a Bazei de Date atunci, când sunt studiate toate resursele informaționale și decizia de a
construi o Bază de Date Relațională ca parte componemntă a Sistemului Informațional
Corporatv a fost deja adoptată.
Totodată trebuie de menționat că instrumentele de modelare IDEF1X a fost
elaborat special pentru a construi Sisteme Informaționale Relaționale și în caz ca este
necesitatea de a construi un alt S. I., de exemplu un sistem Obiect Orientat atunci ar fi
mai bine să alegem o altă metodologie de modelare.
Sunt cel puțin două motive pentru a nu utiliza IDEF1X în cazul când nu se
construesc Sisteme Informaționale relaționale.
În primul rând, IDEF1X cere de la proiectanți să determine atributele cheie, asta
pentru a putea diferenția entitățile una de alta, pe când sistema Obiect Orientată nu cere
determinarea atributelor cheie pentru a putea identifica obiectele.
În al doilea rând, în caz că există mai multe atribute ce identifică univoc entitatea,
proiectantul trebuie să desemneze unul din aceste atribute ca cheie primară, iar celelalte
ca chei secundare.

Bazele metodologiei IDEF1X

IDEF1X - este o abordare semantică la modelarea datelor,

IDEF1X – este bazat pe conceptul ”Entitate – Relații”; un instrument ce se utilizează la
analiza structurii informaționale a obiectelor.
 Modelul informațional, construit în conotația IDEF1X reprezintă – structura
logică a informației despre obiectele din componența sistemului. Poate fi interpretată ca
structura logică a Bazei de Date Modelul informațional – este o suplinire a modelului
funcțional (IDEF0), acest model detaliază obiectele, care sunt manipulate de funcțiile
sistemei.

Componentele principale ale standardului IDEF1x

Componentele principale ale acestui standard sunt: Entitate <-> Relații <->
Atribute
- oamenii, obiectele, fenomenele despre care se colectează și stochează informația (în
continuare – Entitate)
- interconexiunile între aceste entități ((în continuare – Relații)
- caracreristicile ce descriu aceste elemente ((în continuare – Atribute)
- Entitate – mulțimea obiectelor reale (oameni, obiecte, fenomene), ce au caracteristici
și atribute comune. Un obiect al sistemului poate fi reprezentat doar de o singură entitate,
ce trebuie să fie identificată în mod unic.
Exemplu, Entitatea – Studenți. Un exemplar al aceste entități – Vasile
BASARABEANUL.
– Relații – interconexiunile între două sau mai multe entități. Denumirea relațiilor este
formulată in mod determinant
Atribute – caracteristica entității.
Exemplu, Entitatea – Student are ca atribut ”Numele și Prenumele”.
Rezume - Entitatea - reprezintă tipul informație de bază ce se stochează și păstrează
în Baza de Date, dar relațiile indică cum aceste date sunt interconectate între ele.

Reguli de bază a ENTITĂȚILOR

- entitate trebuie să aibă o denumire unicală și să fie substantiv la singular.

Exemplu : student, angajat, contract, carnet de note, buletin de identitate,…
- entitate - poate avea unul sau mai multe atribute, care îi aparțin sau sunt moștenite
prin relații
- entitate - poate avea unul sau mai multe atribute care identifică univoc fiecare
exemplar al entității și se numesc ”cheie”
- entitate - poate avea unul sau mai multe relații cu alte entități
- în caz că cheia externă este integral utilizată în cheia primară a Entității atunci se
spune că Entitatea este dependentă de identificator
- în notația IDEF1X Entitatea este reprezentată în formă de dreptunghi,
 Figura 5.36. Tipuri ce Entități în IDEF1x

Reguli de bază pentru ”Atribut”

Atributul unei Entități are un nume unic.
O Entitate poate avea mai multe atribute.
Atributele sunt : proprii sau moștenite.
Atributele proprii sunt unicale în cadeul acestui model
Atributele moștenite se transmit de la Entitatea paternală odată cu determinarea
conexiunii de identificare.

Figura 5.37. Atribute Cheie

Figura 5.37(a). Clasificare Entități

Figura 5.37(b). Clasificare Entități

 Figura 5.37(c). Clasificare Entități

Relația (Relationship)
Relația (Relationship) este o asociere (căreia i-a fost atribuit un nume) între două
entități, relevantă pentru domeniul obiectiv considerat.
Relația este definită suplimentar prin cardinalul relației (numărul tuplurilor conținute în
relația dată) sau numărul de instanțe ale entității-descendent, care pot fi create de fiecare
instanță a entității-părinte.

Relații unitare

Figura 5.38. Relații unitare

relaţii one-to-one – acest tip de relaţie este destul de rar întâlnit.

Uneori astfel de relaţii pot fi modelate transformând una dintre entităţi în atribut al
celeilalte entităţi.
 Figura 5.39. Relații unitare

Relaţii one-to-many – sunt cele mai întâlnite tipuri de relaţii, însă şi aici cazurile c şi d
prezentate în figură sunt mai puţin uzuale.
Să facem câteva observaţii pe marginea exemplelor:
- cazul a este foarte des întâlnit
- la cazul b, am ales o relaţie opţională dinspre POEZIE spre POET deoarece
poate fi vorba de o poezie populară şi în acest caz nu există un poet cunoscut
- la cazul c, am considerat că o formaţie nu poate exista fără a avea cel puţin un
membru, însă un artist poate avea o carieră solo, deci nu face parte din nici o
formaţie.
Varianta d modelează o colecţie de filme memorate pe CD-uri. Pentru afacerea
considerată, un CD conţine obligatoriu un film, dar unul singur, însă un film poate să nu
încapă pe un singur CD de aceea el poate fi memorat pe unul sau mai multe CD-uri.

Figura 5.40. Relaţii one-to-many

Relaţii many-to-many – aceste tipuri de relaţii apar în prima fază a
proiectării bazei de date, însă ele trebuie să fie ulterior eliminate.
- figura de mai jos prezintă câteva exemple de relaţii many-to-many
- la punctul b am considerat că un curs poate apărea pe oferta de cursuri a unei
facultăţi, însă poate să nu fie aleasă de nici un student de aceea un curs poate fi
urmat de unul sau mai mulţi studenţi
- invers, este posibil ca un student să fi terminat studiile şi să se pregătească pentru
susţinerea examenului de licenţă şi de aceea el nu mai frecventează nici un curs
- la punctul c, un profesor angajat al unei şcoli trebuie să predea cel puţin o
disciplină. Iar o disciplină din planul de învăţământ trebuie să fie predată de cel
puţin un profesor.

Figura 5.41. Relaţii many-to-many

Nontransferabilitatea relațiilor

Spunem că o relaţie este nontransferabilă dacă o asociaţie între două instanţe ale
celor două entităţi, odată stabilită, nu mai poate fi modificată. Nontransferabilitatea unei
relaţii se reduce la faptul că valorile cheii străine corespunzătoare relaţiei respective nu
pot fi modificate.
Condiţia de nontransferabilitate a unei relaţii este asigurată prin program. De
aceea trebuie să documentăm această restricţie. În ERD o relaţie nontransferabilă se
notează cu un romb pe linia corespunzătoare relaţiei, înspre entitatea a cărei cheie străină
nu este permis să o modificăm (adică în partea cu many a unei relaţii one-to-many).
În figura de mai jos este dat un exemplu de relaţie nontransferabilă. Este vorba
despre notele date elevilor. Este normal ca o notă dată unui elev să nu poată fi apoi
transferată unui alt elev.
Relații binare

Relații triple

Simbolica interconexiunilor
 Figura 5.42. Simbolica interconexiunilor

Cazuri posibile

Fiecărei entități i se atrbuie un nume și un număr unic, separate prin "/" și plasate
de asupra blocului.
Relația este definită suplimentar prin cardinalul relației (numărul tuplurilor
conținute în relația dată) sau numărul de instanțe ale entității-descendent, care pot fi
create de fiecare instanță a entității-părinte.
În IDEF1X pot fi următoarele cazuri:
- fiecare instanță a entității-părinte poate fi legată de zero, unul sau mai multe instanțe
ale entității-descendent
- fiecare instanță a entității-părinte trebuie să fie legată de cel puțin o instanță a
entității-descendent
- fiecare instanță a entității-părinte trebuie să fie legată de cel mult o instanță a entității-
descendent
- fiecare instanță a entității-părinte este legată de un număr fix de instanțe ale entității-
descendent.

Legătură identificatoare

În cazul în care o instanță de entitate-descendent este determinată în mod univoc

prin legătura sa cu entitatea-părinte, relația este numită identificatoare (Authenticator), în
caz contrar - neidentificatoare.
Legătura (relația) este notată printr-o linie cu un punct bine pronunțat la sfărșitul
liniei la entitatea-descendent.
Cardinalul relației poate lua valorile: N – zero, unu sau mai multe, Z – zero sau
unu, P – unu sau mai multe.
Valoarea implicită este N.

Exemplu Relație identificatoare

Figura 5.42(a). Relație identificatoare
Legătura neidentificatoare
O legătură neidentificatoare este reprezentată cu ajutorul unei linii punctate.
Entitatea-descendent într-o relație neidentificatoare se numește independentă de
identificator, dacă nu este entitate-descendent într-o oarecare legătură identificatoare.

Figura 5.42(b). Relație identificatoare

Reguli de bază pentru ”Atribut”

- Atributul unei Entități are un nume unic
- o Entitate poate avea mai multe atribute
- Atributele sunt : proprii sau moștenite
- Atributele proprii sunt unicale în cadrul acestui model
- Atributele moștenite se transmit de la Entitatea paternală odată cu determinarea
conexiunii de identificare.

Figura 5.43. Atribute Cheie

Baza IDEF1x - abordarea, propusă de Peter Chen, care permite construirea unui
model al datelor echivalent modelului relațional în forma normală trei.
 Perfecționarea metodei IDEF1 a condus la crearea versiunii IDEF1X, care a fost
elaborată în scopul sporirii simplității și posibilităților de automatizare.
Diagramele IDEF1X sunt utilizate într-o serie de instrumente CASE, cum ar fi: ERwin,
Design/IDEF.
Există două nivele de prezentare a modelelor – logic și fizic.
În Modelul Logic datele sunt prezentate analogic cum există în lumea reală și pot
fi numite tot așa cum sunt numite în realitate, de exmplu “Client”, “Departament” sau
“Nume angajat”.
Obiectele modelului sunt numite entități și atribute.
Modelul logic al datelor este universal și sub nici o formă nu este legat de
realizarea concretă a SGBD.
În Modelul Fizic datelor depinde de SGBD. Într-un model fizic este inclusă
informația despre toate obiectele BD. Unui model logic îi pot corespunde câteva modele
fizice diferite.
Dacă într-un model logic nu importă tipul de date al unui atribut, într-un model
fizic este important să fie descrisă toată informația privind obiectele fizice concrete –
tabele, coloane, indici, proceduri etc.
Interfața Erwin
Fiecărui nivel de afișare a modelului îi corespunde panoul instrumental propriu.
La nivel logic panoul de instrumente include:
- butonul indicatorului de mouse
- pentru introducerea unei entități
- butonul categoriei
- introducere a unui bloc de text
- pentru deplasarea atributelor
- butonul pentru crearea legăturilor: identificatoare, “mulți-la-mulți” și
neidentificatoare.
La nivel fizic: în locul butonului categoriilor – butonul pentru introducerea
vederilor (view);
în locul butonului legăturii “mulți-la-mulți” – butonul pentru legarea vederilor.
Pentru crearea modelelor datelor pot fi utilizate două notații: IDEF1X și IE
(Information Engineering). În continuare vom utiliza notația IDEF1X.
Pentru comutarea între ML și MF al datelor servește lista cu două opțiuni din parte
centrală a panoului de iinstrumente ERwin.
Dacă la comutare MF nu există încă, el va fi creat automat.
Nivele de afișare
În ERwin există câteva nivele de afișare a diagramelor: (clik ”wiev”- ”display
level” - nivelul entităților (entity), nivelul atributelor (atribute) , nivelul cheilor
primare(primare key), nivelul cheilor (keys) , nivelul definițiilor (definition), și nivelul
pictogramelor (icon).
 Figura 5.44. Interfața ERWin

Nivelele modelului logic

În dependență de profunzimea prezentării informației despre date există trei
nivele ale modelului logic:
- diagrama entitate-relație (Entity Relationship Diagram, ERD)
- modelul datelor, bazat pe chei (Key Based model, KB)
- modelul atributiv complet (Fully Attributed model, FA).
Diagrama entitate-relație reprezintă modelul de nivel superior al datelor.
El include entitățile și legăturile reciproce, care reflectă procesele business
principale ale domeniului obiectiv. Aceste diagrame nu sunt detaliate în profunzime, ele
includ doar entitățile principale și legăturile între ele, entități care satisfac cerințele
principale ale sistemului informațional.

Modelul datelor, bazat pe chei,

permite prezentarea mai amănunțită a datelor.
Include descrierea tuturor entităților și a cheilor primare,
și este destinată prezentării strutucrii de date și a cheilor, care corespund domeniului
obiectiv.
 Figura 5.45. Modelul datelor, bazat pe chei

Modelul atributiv complet

Este cea mai detaliată prezentare a structurilor de date:
prezintă datele în forma normală trei și include toate entitățile, atributele și legăturile.

Figura 5.46. Modelul atributiv complet

SGBD susținute de ERWin

 - Modelul SGBD este generat în mod automat din modelul transformațional și
reflectă exact catalogul de sistem al SGBD
- nivelul fizic la care este prezentat modelul depinde de serverul selectat. ERwin
susține peste 20 de tipuri (relaționale și nu numai) de BD
- DB2 LUW 9.x, DB2 ZOS 9.x,
- Informix 11.x, Oracle 11g,
- MS SQL Server 2000,2005,2008,2012,
- MySQL 5.x, SQL Azure,
- Sybase (ASE) 15.0, Sybase IQ 12.x,
- Teradata v13, ODBC 3.x,
- DB2 iSeries 5.x/6.x,
- SAS, Progress 10.x,

Această aplicație poate fi descărcată -

http://download.freedownloadmanager.org/Windows-PC/CA-ERwin-Data-
Modeler/FREE-9.6.00.4430.html
Exemplu unui Sistem Informațional modelat în Standardul IDEF1x cu aplicația Erwin –
Data Modeler poate fi studiată -http://www.bsuir.by/m/12_100229_1_90142.pdf

PS. Această tema va fi pe larg reflectată în capitolul Modelaraea Datelor –Standardul

IDEF1x.
TEMA 6

Metode de proiectare

6.1.Principii de abordare în proiectare Sisteme Informaționale. 6.2. Metode de

proiectare. 6.2.1.Proiectarea canonică. 6.2.2.Proiectare tip.

6.1.Principii de abordare în proiectare S.I

Utilitatea S I

Eficiență economică

Principii de abordare Economice și de

proiectare S I organizare Respectare standarde
tehnologice

Abordare sistemică

Principiu de
modelare sistem inegrare

Principiu modularitate Inovare

Decompoziție Sistem
Principiu de Informațional
adaptabilitate

Principiu de Decompoziție procese

Sistem deschis de proiectare

Principiu de
intelectualizare Participare utilizator

Principiu interfață
prietenoasă Eficiență a activității
de proiectare

Figura 6.1. Principii de abordare în proiectare Sisteme Informaționale

Principii economice și de organizare -10 principii:

- principiul utilitatății
- principiul eficiență economică a sistemului
- principiul respectare standarde
- principiul abordare sistemică
- principiul de integrare
- principiul inovare
- principiul de decompoziție a sistemului informațional
- principiul de decompoziție a procesului de proiectare
- principiul de participare utilizator
- principiul de eficiență a activității de proiectare
Principiul utilității

Nu există sisteme informaționale care să poată afirma că sunt „ideale” din punct
de vedere al utilităţii oferite utilizatorilor. Cu toate acestea, produselor software cu o
utilitate percepută mai bună sunt preferate cu regularitate de către cumpărători, iar
utilitatea percepută bună este de regulă o expresie a unui process de concepție și execuție
care a ținut seama cu consecvență de nevoile publicului și în principiu, dacă se dorește
realizarea unui sistem informatic cu o utilitate percepută ridicată, procesul de design
trebuie să debuteze prin stabilirea obiectivului primar al acelui produs software,
identificarea publicului țintă și a competitorilor existenți la nivelul publicului țintă, în
specula a acelora care sunt la momentul respective lideri de piață. În principiu,
dacă se doreşte realizarea unui sistem informatic cu o
utilitate percepută ridicată, procesul de design trebuie să debuteze prin stabilirea
obiectivului primar al acelui produs software, identificarea publicului ţintă şi
a competitorilor existenţi la nivelul publicului ţintă, în special a acelora care sunt
la momentul respectiv lideri de piaţă.
Principiul eficiență economică a sistemului - presupune că Sistemul nou creat va
asigurarea îndeplinirea tuturor cerințelor formulate de beneficiar față de acest sistem.
Principiul respectare standarde - presupune aplicarea standardelor internaționale și
naționale precum și a recomandărilor ce reglementează etepele, fazele și acțiunile la
proiectarea Sistemelor Informaționale, la codificarea informației, la elaborare și creare
documentație. Aplicare proceduri standarde pentru schimb de informație între
componentele sistemului și la elaborare interfață a utilizatorului etc.
Principiul abordare sistemică – presupune determinarea și abordarea tuturor proceselor,
fenomenelor, conexiunile și interacțiunile atât între ele cât și cu mediul ambiant.
"întregul este mai mult decât suma părilor componente". Ascest principiu cere
aplicarea ideologiei unice către părțile componente al Sistemului – partea funcțională,
selectarea sistemului de programare, sistemului de codificare informație structura bazei
de date asigurarea coompatibilității și iteroperabilității componentelor structura bazelor
de date. Principiul abordare sistemică presupune ordinea de proiectare ”de sus în jos”
adică de la general spre particular adică la început se rezolvă sarcinile generale ale
sistemului și se formulează cerințele funcționale care ulterior vor fi elaborate într-o
consecutivitate. Abordare sistemică presupune determidarea emergenței adică
determinarea a noi proprietăți ale sistemului ce nu au fost formulate anterior.
Principiul de integrare - presupune crearea Sistemelor Informaționale cu funcționalităț
extinse. Adică subsistemele SI au o bază informațională comună. Acest principiu de
obicei duce spre integrarea subsistemelor intr-un Sistem corporativ.
Principiul inovare - identificarea funcțiilor anterior nerezolvate și rezolvarea.
Principiul de decompoziție - duce la ridicarea calității SI ptrin elaborarea a mai multor
subsisteme în special dacă avem de construit un Sistem Informațional de amploare cu
participarea a mai multor grupuri de proiectanți și programatori.
Principiul de participare utilizator – în special la etapa elaborării prototipurilor
participarea primelor persoane, participarea responsabililor de proces etc.
Principiul de eficiență a activității de proiectare – presupune că sinecostul proiectării
trebuie să fie ma mic de cât prețurile pe piață și termenii de realizare să fie respectați așa
precum este stipulat de condițiile Contractului.
Principii tehnologice – 6 principii
- principiul de modelare sistem
 - principiul de modularitate
- principiul de adaptabilitate
- principiul de Sistem deschis
- principiul de intelectualizare
- principiul de Sistem prietenos (friendliness)
Principiul de modelare sistem - Se determină relaţiile dintre mărimile caracteristice,
se construieşte un model simplificat, o imagine a procesului considerat. Modelarea
sistemelor se realizează în scopul obţinerii unor informaţii suplimentare sau a specializării
personalului folosindu-se diferite instrumente şi tehnici.
Modelul este o reprezentare simplificată, aproximativă a sistemului real. Nu e de
regulă nici posibil, nici necesar să se realizeze o descriere amănunţită a tuturor
mecanismelor interne. E suficient ca modelul să mimeze, să se comporte suficient de
aproape de sistemul real.
Modelul trebuie să fie într-o formă utilizabilă (care nu este un scop în sine). El
constituie o bază pentru analiză, luarea deciziilor şi în acest sens modelul trebuie să fie
de o complexitate suficientă pentru a reflecta toate procesele.
Există mai multe tipuri de modele şi anume:
- modele fizice (empirice sau la scară redusă– de exemplu se elaborează o
tehnologie în domeniul chimiei, un micropilot, se încearcă procesul tehnologic pe
acest model fizic şi se trag concluzii.)
- modele fenomenologice (conceptuale – sistemele respective sunt descrise prin
anumite legi) ¾ modele funcţionale (formale – sistemul e reprezentat prin relaţii
funcţionale, scheme funcţionale)
- modele matematice (analitice).
Principiul de modularitate
este procesul de partiţionare a unui sistem în componente individuale (module) ceea ce
permite reducerea complexităţii sistemului prin definirea unor graniţe bine stabilite şi
documentate.
– modularitatea constă în partiţionarea sistemului în module care pot fi elaborate separat,
dar care au conexiuni cu alte module ale sistemului.
– modulele servesc ca şi containere în care sunt declarate clasele şi obiectele sistemului.
Principiul de adaptabilitate
Adaptabilitate – presupune corelarea formei de prezentare, a gradului de prelucrare cu
nivelul de pregatire, gradul de informare, poziţia ierarhica detinute de catre receptor.
Principiul de Sistem deschis - Caracterul deschis/parial deschis al sistemelor:
un sistem care are legături cu mediul prin cel puțin o întrare și o ieșire este
considerat un sistem deschis, în timp ce absența uneia din legături (de întrare sau de ieșire)
determină caracterul parțial-deschis al acestuia. În absena ambelor legături cu mediul,
sistemul este izolat. Această proprietate caracteristică face o distincție clară între
sistemele biologice și cele economice care putându-se organiza îi sporesc ordinea
interioară și prin urmare îi micșorează entropia pe baza schimbului permanent de
substană, energie, informații cu mediul lor.
Caracterul antientropic al sistemelor cu structură cibernetică este legat în special
de posibilitatea perfecționării conducerii și a reducerii gradului de dezorganizare internă
a sistemelor deschise prin ameliorarea proprietăților structurale şi a celor informaţional
decizionale precum şi prin intensificarea schimbului de informații și a tranzacțiilor cu
mediul.
6.2 Metode de proiectare
În dependență de nivelul de utilizare a soluțiilor tip, metodele de proiectare a SI
se împart în:
- proiectare canonică
- proiectare tip.
Proiectarea canonică presupune elaborarea sistemelor fără utilizarea unor soluții gata
(de la zero) sau mijloace instrumentale speciale dar după careva reguli sau canon.
Proiectarea tip presupune crearea sistemului informațional din elemente tip existente.

Figura 6.2. Metode de proiectare

Proiectare canonică
Proiectarea canonică presupune elaborarea sistemelor fără utilizarea unor soluții
gata (de la zero) sau mijloace instrumentale speciale dar după careva reguli sau canoane.
Proiectare tip
Proiectarea tip presupune crearea sistemului informațional din elemente tip existente.
Care aplică:
- tehnologii de proiectare automatizată
- tehnologii de proiectare tip
- tehnologii de proiectare tip pe parametri
- tehnologii de proiectare tip pe modele.

6.2.1 Proiectarea canonică

Stadiile și etapele proiectării canonice. Scopurile și obiectivele etapei preproiect.

Modelele activității întreprinderii (“cum este” și “cum trebuie să fie”). Componența
lucrărilor la etapa elaborării proiectului tehnic. Documentația de proiect. Proiectarea
generică. Noțiune de proiect generic, premisele tipizării. Obiectele tipizării. Metodele de
proiectare generică. Estimarea eficienței utilizării soluțiilor tipizate. Soluție proiect tip.
Metode și mijloace de proiectare prototipizată a SI.
Organizarea proiectării canonice este orientată spre utilizarea modelului cascadă
a ciclului de viață. Etapele sunt standardizate în ISO 12207.
În dependență de complexitatea obiectului automatizării și problemele, care
trebuie soluționate prin crearea unui SI concret, etapele pot fi de complexitate diferită.
Este permis de a combina etape succesive și chiar de a exclude unele etape la orice fază
a proiectului.
Mai mult, următoarea etapă a lucrărilor poate începe până la sfârşitul etapei
precedente.
Etapele creării SI, executate de organizațiile participante, sunt fixate în contracte
și sarcini tehnice de executare a lucrărilor.

Figura 6.3(a). Etape de proiectare Sisteme Informaționale

Figura 6.3(b). Etape de proiectare Sisteme Informaționale

Etapa 1. Studiul SI existent și definirea cerințelor noului sistem

- cercetarea SI și motivarea necesității creării unui sistem nou
- formarea cerințelor față de sistemul nou
 - elaborarea raportului despre lucrările îndeplinite.
Studiul sistemului existent cuprinde un grup de activități care urmăresc cunoașterea:
- performanțelor tehnico-funcționale ale sistemului informațional, atât în ansamblul
său, cât și pentru elementele de structură ale acestuia
- a cerințelor informaționale ale conducerii
- cunoașterea lipsurilor și restricțiilor pe care le prezintă sistemul existent față de
aceste cerințe.
De modul de realizare a acestor activități depinde întregul proces de realizare a
sistemului informatic.
Studiul sistemului existent constă în:
- definirea caracteristicilor generale ale (unității de informatizare) obiectului social-
economic
- studiul activităților de bază desfășurate în sistemul obiectului social-economic
- studiul sistemului de conducere a obiectului
- studiul sistemului informațional existent
- identificarea metodelor și mijloacelor tehnice.

Definirea caracteristicilor generale ale obiectului de informatizare presupune:

- cunoaşterea profilului, obiectivelor agentului economic
- cunoaşterea locului în sfera serviciilor şi sfera producţiei
- cunoaşterea relaţiilor de cooperare cu alţi agenţi economici
- cunoaşterea specificului activităţii de bază ( producţie, servicii)
- cunoaşterea nivelului tehnic
- cunoaşterea principalilor indicatori economici şi evoluţia lor
- dezvoltarea, modernizarea etc.
Studiul activitatilor desfasurate in sistemul obiectului social-economic, modul de
realizare a funcțiunilor unității economice se face:
a) Pe baza ”Statutului” de funcționare a unității social-economoce
și se studiază:
1) activitățile și sarcinile din cadrul acestor funcțiuni
2) atribuțiile ce le revin subdiviziunilor unității economice
3) modul de realizare a activităților funcționale din cadrul unității economice.
b) În cazul activității de producție se prezintă:
1) fluxul de producție, amplasarea locurilor de muncă, amplasarea depozitelor,
regimul funcționare etc.
2) tipurile de produse, structura lor, ciclurile de realizare
3) modul de organizare a producției, mișcarea internă a producției, controlul calității
lucrărilor, stocarea producției
4) resursele existente
5) capacități
6) asigurarea tehnică / proiectarea de produse noi
7) norme tehnice
8) asigurarea cu materiale necesare
9) sistemul existent de planificare a producției.
c)Studiul sistemului de conducere se referă la:
1) identificarea caracteristicilor sistemului de conducere existent
2) sistemul de indicatori cantitativi, valorici și calitativi
3) structura organizării conducerii
 4) caracteristicile rezultate din ”Statutul” de functionare a societății, tipuri de
decizii, modul de realizare a deciziilor, controlul îndeplinirii deciziilor.
d) Studiul sistemului informațional presupune:
1) elaborarea schemei fluxului informațional global (cu punerea în evidență a
principalelor activități și a legăturilor statice si dinamice dintre acestea)
2) estimarea cantitativa si calitativa a informatiilor de intrare-ieșire, modul de
culegereșsi prelucrare
3) identificarea principalilor algoritmi, regulilor de calcul și a punctelor și regulilor
de control
4) cunoașterea principalelor restricții ale sistemului informațional
5) situația raționalizării fluxurilor și a documentelor din unitatea economică, studii
elaborate, stadiul lor de implementare
6) sistemul de codificare utilizat, restricții
7) performanțele și limitele sistemului informațional existent.
Identificarea metodelor și mijloacelor tehnice utilizate pentru prelucrarea datelor
în cadrul sistemului informațional existent se face evidențiind:
- mijloacele tehnice existente in dotarea unității economice ( modul de utilizare,
cheltuielile de exploatare, personalul implicat, performanţe)
- existenţa unor aplicații proiectate și/sau implementate.
Determinarea cerințelor sistemului - Determinarea cerințelor sistemului
este activitate esențială in aflarea situației existente și a ceea ce se dorește în viitor.
Rezultatul activității de determinare a cerințelor sistemului se concretizează în diferite
forme ale informațiilor colectate, cum sunt:
- copii ale interviurilor
- însemnări efectuate în timpul observării și analizei documentelor
- interpretări ale răspunsurilor la chestionare
- seturi de formulare
- rapoarte
- descrieri ale posturilor de lucru s.a., precum şi rezultate ale prelucrărilor efectuate
de calculator, cum ar fi prototipurile.

Rezultatele prezentate după această activitate pot fi rezumate astfel:

Informaţii obţinute în urma conversaţiilor cu utilizatorii sau prin observarea
activităţilor prestate de aceştia: copii sau sinteze ale interviurilor, răspunsurile la
chestionare sau interpretări ale acestora, însemnări şi rezultate din observarea activităţilor,
procese verbale ale şedinţelor ce au avut loc în acest scop.
Informații scrise care există în unitate: misiunea și strategia afacerii, exemplare
ale formularelor, rapoartelor și machetelor de ecrane, manuale ale procedurilor, descrieri
ale posturilor de lucru, manuale de instruire, scheme de sisteme și documentația
sistemului existent, rapoartele consultanților.
Informații obținute cu ajutorul calculatorului: rezultate ale sesiunilor JAD (Joint
application design), copii ale fișierelor sesiunilor grupului de sprijinire a sistemului,
conținutul depozitelor și rapoartele existente în CASE, ecrane și rapoarte rezultate din
prototipurile sistemului, ş.a.

Analiza situației și identificarea cerințelor sistemului nou

Cercetarea sistemului existent constă în:
- identificarea caracteristicilor generale ale obiectului automatizării
 - studiul activităţilor de bază desfăşurate în sistem
- studiul sistemului de conducere
- studiul sistemului informaţional
- identificarea metodelor şi mijloacelor tehnice.
Definirea caracteristicilor generale ale organizației pentru care va fi elaborat noul
sistem implică:
- cunoaşterea profilului, obiectivelor organizației
- cunoaşterea specificului activităţii de bază (producţie, servicii)
- cunoaşterea locului în sfera serviciilor și/sau sfera producţiei
- cunoaşterea relaţiilor de cooperare cu alţi agenţi economici
- cunoaşterea nivelului tehnic
- cunoaşterea principalilor indicatori de performanță şi evoluţia lor
- dezvoltarea, modernizarea etc.
Studiul activităţilor desfăşurate în sistemul economic, modul de realizare a funcţiunilor
unităţii economice se face prin:
Pe baza statutului de funcţionare a organizației se studiază:
În cazul activităţii de producţie se prezintă:
- fluxul de producţie, amplasarea locurilor de muncă, depozitelor etc.
- tipurile de produse, structura lor, ciclurile de realizare
- modul de organizare a producţiei, stocarea producţiei, transporturile interne,
controlul de calitate
- resursele existente: capacităţi; asigurarea tehnică; proiectarea de produse noi,
norme tehnice
- asigurarea cu materiale necesare
- sistemul existent de programare a producţiei.

Studiul sistemului de conducere se referă la:

- identificarea caracteristicilor SC existent
- sistemul de indicatori cantitativi şi valorici
- organizarea conducerii
- caracteristicile rezultate din statutul de funcţionare a societăţii, tipuri de decizii,
modul de lucru a deciziilor.

Studiul sistemului informaţional presupune:

- elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a
principalelor activităţi şi a legăturilor statice şi dinamice dintre acestea)
- estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de
culegere şi prelucrare a datelor
- identificarea principalilor algoritmi, regulilor de calcul, a punctelor si regulilor de
control
- cunoaşterea principalelor restricţii ale sistemului informaţional
- situaţia raţionalizării fluxurilor şi a documentelor din organizație, studii elaborate,
stadiul lor de implementare
- sistemul de codificare utilizat, restricţii
- performanţele şi limitele sistemului informaţional existent.
 Formarea cerinţelor sistemului nou este activitate esenţială în aflarea situaţiei
existente şi a ceea ce se doreşte în viitor. Rezultatul activităţii de determinare a cerinţelor
sistemului se concretizează în diferite forme ale informaţiilor colectate, cum sunt:
- copii ale interviurilor
-însemnări efectuate în timpul observării şi analizei documentelor
- interpretări ale răspunsurilor la chestionare
-seturi de formulare, rapoarte
-descrieri ale posturilor de lucru ş.a.
-precum şi rezultate ale prelucrărilor efectuate de calculator, cum ar fi prototipurile.
Activitățile enumerate pot fi executate total cu forțele achizitorului sau prin
contractarea unor servicii din partea unei organizații de consultanță.

Rezultatele prezentate după etapa 1:

Informaţii scrise care există în unitate: misiunea şi strategia afacerii,
exemplare ale formularelor, rapoartelor şi machetelor de ecrane, manuale ale
procedurilor, descrieri ale posturilor de lucru, manuale de instruire, scheme de
sisteme şi documentaţia sistemului existent, rapoartele consultanţilor.
Informaţii obţinute în urma conversaţiilor cu utilizatorii sau prin
observarea activităţilor prestate de aceştia: copii sau sinteze ale interviurilor,
răspunsurile la chestionare sau interpretări ale acestora, însemnări şi rezultate din
observarea activităţilor, procese verbale ale şedinţelor ce au avut loc în acest scop.
Informaţii obţinute cu ajutorul calculatorului: copii ale fişierelor sesiunilor
grupului de sprijinire a sistemului, conţinutul depozitelor şi rapoartele existente în
CASE, ecrane şi rapoarte rezultate din prototipurile sistemului, ş.a.
Materialele, create vor fi folosite pentru:
- motivarea necesității elaborării și implementării graduale a sistemului nou
- elaborarea Sarcinii Tehnice pentru crearea sistemului
- perfectarea Proiectului Tehnic și Proiectului de lucru.
Un raport special – studiul de fezabilitate a proiectului - poate fi parte componentă a
acestor rezultate. În acest raport vor fi clar definite beneficiile achizitorului, dacă va
decide finanțarea proiectului, termenul în care produsul finit va fi lansat în exploatare,
costurile aferente, modalitatea și graficul achitărilor, efectul economic și timpul de
recuperare a cheltuielilor.

Studiul de fezabilitate
Acest document va include cel puțin:
- constrângerile, riscurile, factorii critici, care pot influența succesul
- condițiile de exploatare a viitorului sistem: arhitectura sistemului, resursele
tehnice și logice, condițiile de funcționare, personalul de exploatare și utlizatorii
sistemului
- termenii de finalizare a etapelor, forma de primire-predare a lucrărilor, resursele
implicate, măsurile de protecție a informației
- descrierea funcțiilor sistemului
- posibilitățile de dezvoltare viitoare a sistemului
- obiectele informaționale ale sistemului
- interfețele și modalitatea de partajare a funcțiilor între om și sistem
- cerințele privind componentele program și informaționale, SGBD
- indicații privind lucrările, care nu vor fi realizate în cadrul proiectului dat.
 Va fi stabilită lista activităților, automatizarea cărora este recomandată și ordinea în
care aceasta va avea loc.
Funcțiile planificate pot fi clasificate conform formatului MuSCoW: Must have –
funcții obligatorii; Should have – funcții dorite; Could have – funcții posibile; Won't have
– funcții lipsă.
Realizarea funcțiilor din categoria a doua și a treia este limitată de cadrul temporal și
financiar: va fi realizat tot ce este obligatoriu și la maximum ce este dorit și posibil în
ordinea priorităților.
Este foarte importantă ultima categorie de funcții, deoarece este necesar să se
stabilească granițele proiectului și să se concretizeze explicit funcțiile, care vor fi lipsă.
Analiza situației și identificarea cerințelor sistemului nou
Modelele activității organizației vor fi de două categorii:
- modelul “cum este” (“as-is”), care reflectă procesele business existente în
organizație
- modelul “cum va fi” (“to-be”), care reflectă modificările necesare ale proceselor
business la introducerea SI.
Implicarea testerilor începând cu etapa de analiză. Vor participa la:
- soluționarea problemelor legate de obținerea caracteristicilor comparative ale
platformelor tehnice, ale sistemelor de operare, SGBD, alte medii de funcționare
- elaborarea compart. planului de lucru asociat fiabilității și testării SI.
Rezultatele primei etape servesc la elaborarea Concepției (etapa 2) și Sarcinii Tehnice
(etapa 3) a viitorului sistem informațional.

Etapa 2. Elaborarea Concepției SI

E
t
Elaborarea aConcepției SI
- studii și executarea lucrărilor de cercetare necesare
- studierea obiectului automatizării p
- elaborarea versiunilor Concepției, discutate în grupul de lucru, format din
reprezentanții beneficiarului și executorului
a
- perfectarea versiunii finale a Concepției și aprobarea ei de Conducere.

RT 38370656- 002:2006: Concepţia este documentul iniţial, elaborat la crearea

sistemului, care conţine rezultatele îndeplinirii lucrărilor de cercetare ştiinţifică şi
experimentală şi serveşte drept bază pentru elaborarea ulterioară a documentaţiei tehnice.
În dependenţă de scopurile propuse, Concepţia de bază sau cadru. Concepţia cadru
se elaborează în cazul, când sistemul descris constă dintr-o multitudine de sisteme
independente sau interconectate, pentru care ulterior vor fi elaborate concepţii de bază.
Concepţia cadru se deosebeşte de cea de bază printr-o expunere rezumativă a materialului
sau prin lipsa capitolelor/ subcapitolelor separate, care sunt obligatorii pentru Concepţia
de bază.
Destinaţia Concepţiei constă în prezentarea viziunii generale asupra sistemului,
funcţiilor îndeplinite de sistem, descrierii spaţiului de drept şi informaţional şi
interacţiunii cu alte SI.
Concepţia SI conţine capitolele
1 Introducere
2 Generalităţi
3 Spaţiul juridico-normativ al funcţionării sistemului
4 Spaţiul funcţional al sistemului
5 Structura organizaţională a sistemului
6 Documentele sistemului
7 Spaţiul informaţional al sistemului
8 Spaţiul tehnologic al sistemului
9 Asigurarea securităţii informaţionale
10 Încheiere.

Etapa 3. Sarcina tehnică

Etapa elaborării Sarcinii tehnice (ST) include activități de elaborare prin iterații a
versiunilor ST, discutarea și perfectarea lor, coordonarea cu și aprobarea de Conducere.

E
t
RT 38370656- 002:2006, Sarcina atehnică
Sarcina Tehnică (etapa 3) este documentul, care
determină scopurile și obiectivele, cerințele și datele principale de intrare, necesare pentru
elaborarea SI. p
La elaborarea ST vor fi soluționate următoarele probleme:
- stabilirea scopului creării SI, determinarea a funcțiilor și a subsistemelor
- elaborarea și fundamentarea cerințelor privind subsistemele
- elaborarea și fundamentarea cerințelor privind baza informațională, resursele
matematice, program și tehnice (inclusiv, mijloacele de comunicație și trasmitere
a datelor)
- identificarea cerințelor generale ale sistemului proiectat
- determinarea listei lucrărilor de creare a sistemului și a executorilor
- determinarea etapelor creării sistemului și termenilor de execuție a acestora
- calcularea preliminară a costurilor pentru crearea sistemului și determinarea
nivelului de eficiență economică a implementării lui.

Structura Caietului de sarcini

1 Generalități
2 Destinația și scopurile creării /modernizării Sistemului Informațional
3 Descrierea obiectului automatizării
4 Cerințe funcționale față de sistem
5 Componența și conținutul lucrărilor de creare a sistemului
6 Modul de testare / verificare și predare / primire a sistemului
7 Cerințe referitoare la componența și conținutul lucrărilor de pregătire a
obiectului automatizării pentru lansarea în exploatare a SI
8 Cerințe privind documentația
 9 Surse normatve și legale.

1 Generalități
- denumirea completă a sistemului și abrevierea
- codul (numărul) temei sau al contractului
- denumirea organizației executoare și a beneficiarului, rechizitele lor
- lista documentelor în baza cărora este creat sistemul
- termeni (executare) de începere și finalizare a lucrărilor
- informații despre surse și modalitatea de finanțare
- ordinea de perfectare și prezentare a rezultatelor creării: Sistemului Informațional,
al părților sistemului sau a unor module separate
2 Destinația și scopurile creării /modernizării Sistemului Informațional
a)categoria activităților de automatizare
b)lista obiectelor pentru care va fi utilizat sistemul
c)denumirea și valorile solicitate ale indicatorilor:
1) tehnici
2) tehnologici
3) economici etc.,
care vor fi atinși odată cu implementarea sistemului.
3 Descrierea obiectului automatizării
- informații succinte despre obiectul automatizării
- informații despre condițiile de exploatare și caracteristicile mediului ambiant
4 Cerințe funcționale față de sistem
Cerințe privind sistemul în totalitate:
- cerințe referitoare la structura și modul de funcționare a sistemului (lista
subsistemelor, nivelele ierarhice, gradul de centralizare, modul de schimb
informațional, regimurile de funcționare, interacțiunea cu alte sisteme,
perspectivele de dezvoltare)
- cerințe privind personalul (roluri, calificarea, regimul de lucru, organizarea
instruirii, utilizatorii)
- indicatori asociați destinației sistemului (adaptabilitatea la modificările sistemului
de conducere și a valorilor parametrilor, scalabilitatea)
- cerințe privind fiabilitatea, securitatea, ergonomia, transportabilitatea,
exploatarea, deservirea tehnică și reparația, protecția contra unor influențe
externe, drepturi de autor, standardizare și unificare
Cerințe referitoare la funcționalități (pe subsisteme):
- lista activităților automatizate
- cadrul temporal de realizare a fiecărei funcții
- cerințe privind calitatea realizării fiecărei funcții, forma de prezentare a ieșirilor,
exactitatea și autencitatea datelor
- lista și criteriile de stabilire a căderilor (refuz serviciu).
Cerințe referitoare la resurse:
- matematice (componența și sfera utilizării modelelor și metodelor matematice,
algoritmilor existenți și noi
- informaționale (componența, structura și organizarea datelor, schimbul intern de
date, compatibilitatea informațională cu alte sisteme, clasificatoarele utilizate,
SGBD, controlul datelor și folosirea masivelor de date, procedurile de conferire a
valabilității juridice documentelor la ieșire)
 - lingvistice (limbajele de programare, limbile de interacțiune a utilizatorilor cu
sistemul, sistemele de codare, limbajele pentru intrări/ieșiri
- tehnice
- metrologice
- organizaționale (structura și funcțiile departamentelor de exploatare, protecția
contra unor acțiuni eronate)
- metodice (documentația normativ-tehnică).
5 Componența și conținutul lucrărilor de creare a sistemului
- lista stadiilor și a etapelor
- termeni de executare
- lista orgaizațiilor executoare
- modalitatea și ordinea expertizării documentației tehnice
- programul de asigurare a fiabilității
- programul de asigurare metrologică
6 Modul de testare / verificare și predare / primire a sistemului
- tipurile, componența, volumul și metodele de testare
- cerințe generale privind acceptarea lucrărilor pe etape
- statutul comisiei de predare/primire
7 Cerințe referitoare la componența și conținutul lucrărilor de pregătire a
obiectului automatizării pentru lansarea în exploatare a SI
- transformarea informațiilor de intrare în formă mașinolizibilă (digitizare)
- modificările ce trbuie introduse în structura obiectul automatizării
- termenii și modalitatea de selectare și instruire a personalului
8 Cerințe privind documentația
- lista documentelor elaborate
- lista documentelor pe suporți magnetici
9 Surse normatv și legale
Legislație, standarde, documente și materiale informaționale, în baza cărora a fost
elaborată ST și Sistemul Informațional.

Etapa 4. Proiectul tehnic

Este documentul, care include solțiile generale sistemice de proiect, algoritmii de

soluționare a problemelor, estimarea eficienței economice a implementării sistemului
automatizat și lista activităților pentru pregătirea implementării.
În cadrul acestei etape sunt executate lucrări experimentale și de cercetare pentru
alegerea finală a solițiilor principale de proiect și calcularea eficienței economice a
implementării sistemului.

E
t
Proiectul tehnic – lucrări Proiectul a tehnic
- elaborarea soluțiilor de proiect pentru sistem și părțile sistemului
- elaborarea documentației de proiect pentrup sistem și părțile lui
- perfectarea documentației de furnizare a componentelor
a conexe ale proiectului.
- elaborarea sarcinilor pentru proiectarea părților

4
Structura Proiectului Tehnic
1 Notă explicativă
2 Structura funcțională și organizațională a sistemului
3 Enunțul problemei și algoritmii de soluționare
4 Organizarea bazei informațional
5 Albumul cu formele documentelor
6 Resursele matematice
7 Mijloace tehnice necesare
8 Calculul eficienței economice a sistemului
9 Măsuri privind pregătirea obiectului pentru implementarea sistemului
10 Borderoul documentelor

1. Notă explicativă
- cadrul justificativ pentru elaborarea sistemului
- lista organizațiilor executoare
 caracteristica succintă a obiectului cu lista indicatorilor tehnico-economici
principali de funcționare și legătuarile cu alte obiecte
 informații succinte privind soluțiile principale de proiect.
2 Structura funcțională și organizațională a sistemului
- justificarea subsistemelor, lista și destinația lor
- lista lucrărilor îndeplininte în cadrul fiiecărui subsistem, caracteristica succintă
și conținutul lucrărilor
- schema legăturilor informaționale între subsisteme și lucrări în cadrul unui
subsistem
3 Enunțul problemei și algoritmii de soluționare
- metoda, periodicitate și timpul de rezolvare, metodele de culegere și transmitere
a datelor, relația cu alte sarcini, natura utilizării rezultatelor)
- modelul economic și modelul matematic al problemei (prezentarea structurală și
detaliată)
- informaţii normative (conținutul și forma de prezentare)
- informații privind interconexiunile cu alte sarcini și procese
- informații pentru decizii ulterioare referitoare la problema dată
- informații cu privire la efectuarea modificărilor (modul de introducere a
schimbărilor și lista informațiilor care fac obiectul modificărilor)
- algoritmul de soluționare a problemei (modelul proceselor, secvențe și pașii,
schema, formule de calcul)
- studiu de caz (set de formulare ale documentelor de intrare completate, documente
convenționale de ieșire cu informații acumulate și stocate, formulare ale
documentelor de ieșire, completate cu rezultatele soluționării problemei conform
algoritmului elaborat)
4 Organizarea resuselor informaționale
- sursele de informații externe și interne și modul de transfer de la proces la proces
- setul de indicatori, utilizați de sistem
- lista de documente, termenii și periodicitatea intrării
- soluțiile principale de proiect privind organizarea fondului
- componența bazei informaționale, inclusiv rechizitele, ontologia și taxonomia
informației, marja de valori a datelor și lista documentelor bazei informaționale
- lista masivelor, volumul lor, modalitatea și frecvența corectării informațiilor
 - structura fondului cu descrierea legăturilor între elementele constitutive, cernițe
referitoare la tehnologia creării și operării fondului
- metodele de păstrare, căutare, modificare și control
- determinarea volumelor și fluxurilor informaționale
- exemplu de control la introducerea unor modificări
- propuneri privind unificarea documentației
5 Albumul cu formele documentelor
6 Resursele matematice
- justificarea structurii resurselor matematice
- justificarea alegerii mediului de programare (platforma de programare)
- lista resuselor program de sistem (Sisteme de operare, SGBD-ul).
7 Mijloace tehnice necesare
- descrierea și motivarea schemei procesului tehnologic de prelucrare a datelor
- justificarea alegerii structurii complexului tehnic și grupurilior funcționale ale
acestuia
- motivarea cerințelor privind echipamentele speciale
- motivare cerințelor privind rețele de transport date
- setul de acțiuni pentru asigurarea fiabilității funcționării echipamentelor

8 Calculul eficienței economice a sistemului

- devizul de cheltuieli pentru exploatarea sistemului
- calculul eficienței economice anuale obținute din optimizarea structurii
organizației
- diminuarea costurilor și a pierderilor
- îmbunătățirea deciziilor administrative
9 Măsuri privind pregătirea obiectului pentru implementarea sistemului
- lista măsurilor organizaționale pentru perfecționarea proceselor business
- lista lucrărilor pentru implementarea sistemului, care sunt necesare la etapa
proiectării tehnice, cu indicarea termenilor și responsabililor.
10 Borderoul documentelor

Etapa 5. Proiectarea de detaliu

E
Proiectareat de detaliu
a
Proiectarea de detaliu
Activitățile componente ale acestei etape sunt: p
- elaborarea soluțiilor de preproiect pentru sistem și părțile componente sistemului
- scrierea codurilor de programe, testarea și corectareaa lor
- elaborarea documentației de detaliu pentru sistem și a părților componente.
5
Etapa 6. Implementarea codului și perfectarea documentației
- scrierea și testarea codului modulelor
- integrarea modulelor și testarea subsistemelor și a sistemului
 - elaborarea documentației de lucru pentru sistem și părțile lui.

Este creat PP și documentația însoțitoare. Documentația va include informațiile

necesare și suficiente pentru îndeplinirea lucrărilor de implementare a SI, ca și pentru
menținerea nivelului caracteristicilor funcționale.
Calitatea este identificată prin testare. Sunt stabilite următoarele tipuri de testări:
preliminară, de exploatare pilot și testarea finală. La necesitate pot avea loc testări
suplimentare atât pentru întregul sistem, cât și pentru părțile componente.
În dependență de legăturile interne ale componentelor și obiectul automatizării, testările
pot fi autonome sau complexe. Testările autonome (de detaliu) includ unele părți ale
sistemului. Ele sunt executate gradual, odată cu finalizarea unei părți pentru darea în
exploatare experimentală (pilot). Testările complexe sunt executate pentru grupuri de
părți sau pentru întreg sistemul.
Pentru planificarea testărilor este creat documentul “Programul și metodica
testărilor”. Responsabilul de crearea documentului este fixat în Contract sau ST.
Documentul poate include teste sau exemple de control (în calitate de anexe).

Etapa 7. Lansarea în exploatare

- pregătirea obiectului automatizării
- instruirea personalului
- completarea sistemului cu toate componentele necesare
- executarea lucrărilor de construcție și montare
- lucrări de lansare și depanare
- testări preliminare
- exploatare pilot
- testare de primire-predare.
Etapa 8. Mentenanța SI
- îndeplinirea lucrărilor în conformitate cu obligațiunile de garanție
- deservirea postgaranție.
TEMA 6.2.2 Proiectare tip

Proiectare tip - sau ingineria softului bazată pe componente CBSE – Component Based
Software Engineering.
CBSE - proiectarea sistemelor software utilizând componente reutilizabile.
Crearea sistemului din elemente existente apriori.
Cerință: posibilitatea decompoziției.

SPT - soluție de proiect tirajată

Clase în dependență de nivelul decompoziției:
- SPT pe elemente
- SPT pe subsisteme
- SPT pe obiecte.
Abordarea orientată pe parametri, etape:
- determinarea criteriilor de estimare a SPT pentru soluționarea problemelor în
cauză
- analiza și evaluarea SPT accesibile conform criteriilor formulate
- selectarea și procurarea celei mai potrivite SPT
- acordarea (adaptarea) parametrilor SPT procurate.
O astfel de abordare SPT este văzut ca o ”cutie neagră”
Flux Informațional (FI) - sunt datele primare, care sunt procesate și sunt necesare pentru
a obține rezultate.
Bloc funcțional - procesează datele primare și formalizează rezultatul fucționării
pachetului.
Flux de Parametri (FP) - este informasția necesară pentru ajustarea pachetului la
conduții concrete de funcționare.
Blocul procesare parametri - setul de module ce interpretează parametrii.
Blocul de adaptare - interacționează cu blocul funcțional și poate adăuga module sau să
le modifice.
Criterii de estimare a SPT:
- destinația și posibilitățile pachetului
- caracteristici și proprietăți ale pachetului
 - cerințele pentru hardware și software
- documentația pachetului
- factori de ordin financiar
- caracteristici de instalare
- caracteristici de exploatare
- asistența furnizorului
- calitatea pachetului și experiența de utilizare
- perspectivele de dezvoltare a pachetului.

Etape din metodologia CASE*METHOD pentre realizarea sistemelor informatice.

Definirea strategiei de analiza-proiectare
- Prima etapa din metodologia CASE*METHOD pentre realizarea sistemelor
informatice o reprezinta definirea strategiei Obiective
O proiectare cu succes a produselor software presupune o buna formulare si întelegere
a problemei, evidentiind necesitatile informationale ale organizatiei. Aceasta
întelegere poate conduce la o distinctie netă între analiza ("ce trebuie făcut?") si
proiectarea ("cum trebuie făcut?") de sistem.
Obiectivul etapei de strategie este de a elabora de analiza-proiectare.
Analiza -proiectare
Această etapă constituie o analiză detaliata, completă a organizatiei, reprezentând
baza dezvoltării ulterioare a sistemului informatic.
Distribuția subetapelor fazei strategiei trebuie să pună clar în evidenţă obiectivele
urmărite de organizație prin proiectarea noului sistem (figura 1).
Subetape
- definirea direciților de analiză: obiective, priorităţi, limite, factori de influenţă.
- întocmirea diagramei entitate - relaţie
- definirea ierarhiei de funcţii
- recomandări de proiectare
- problemele organizaţionale şi tehnolo-gice
- definirea limitelor sistemului
- definirea unei posibile arhitecturi a sistemului
- aproximarea necesarului de resurse.
 Figura 6.3(b). Etape de proiectare Sisteme Informaționale

Abordarea orientată pe model

Abordarea orientată pe model - presupune adaptarea componentelor și
caracteristicilor SPT conform obiectului automatizării.
Depozitul cu metainformații conține modelul obiectului automatizării în baza
căruia are loc configurarea produsului program.
În consecință, abordarea model-orientată presupune construirea modelului
obiectului automatizării utilizând instrumente program speciale (Utilizarea
instrumentelor CASE, SAP Business Engineering Workbench (BEW), BAAN Enterprise
Modeler).
Depozitul include modelul de bază (de referință) a SI, modele tip pentru diferite
clase de SI, modelele SI ale unor organizații concrete.

Utilizarea instrumentelor CASE

Utilizarea instrumentelor CASE generează o serie de facilităţi, şi anume:
- pot deveni suport pentru mai multe metode de analiză
- sprijină conducerea proiectului
- ajută la realizarea de prototipuri
- generează documentaţia
- generează automat coduri.
Instrumentele CASE oferă sprijin utilizatorului prin metodologiile
prestabilite, pe care acesta le poate urma în cadrul proiectului de
modelare/implementare a sistemului informatic dorit. Instrumentele acestuia
oferă sprijin în realizarea diagramelor pentru:
- activităţii, care reprezintă comportamentul operaţiilor ce utilizează seturi de
acţiuni
- clasele, care exprimă structura statică a unui sistem relativ la clase şi relaţiile
dintre ele
 - colaborările, care ilustrează interacţiunile dintre obiectele utilizate: structură
spaţială ce reprezintă domeniul fizic
- componentele, care descriu componentele software ale unei aplicaţii în mediul de
implementare
- distribuire, care prezintă locaţiile componentelor software pe componente
hardware
- obiecte, care exprimă structura statică a unui sistem în funcţie de toate obiectele
sale şi relaţiile dintre ele
- secvenţe, care ilustrează interacţiunile dintre obiecte utilizând o structură
temporală de reprezentare a proceselor
- tranziţiile stărilor, care reprezintă comportamentul claselor utilizând maşini de
stări
- cazurile de utilizare, care sunt reprezentări ale funcţionalităţii unui sistem, din
punctul de vedere al utilizatorilor săi.

Figura 6.4. Componentele unui sistem CASE

Componentele unui sistem CASE

Editorul de diagrame - este componenta obligatorie a oricărui produs de tip CASE şi
permite construirea şi modificarea tuturor tipurilor de diagrame utilizate de metodologia
/ metodologiile implementate prin CASE. Introducerea informaţiilor în editor poate fi
făcută în două moduri:
- de către utilizator, prin intermediul unei interfeţe
- din repository, atunci când acesta este actualizat prin reverse engineering.
Editorul de diagrame trebuie să satisfacă următoarele condiţii:
- să permită introducerea şi modificarea uşoară a tuturor entităţilor grafice descrise
de metoda de proiectare
- suprafaţa grafică să fie de calitate, să permită operaţii de zoom, de grupare şi
aliniere a elementelor diagramei
 - să permită tipărirea eficientă a documentelor şi paginarea lor precum şi selectarea
informaţiilor ce vor fi tipărite
- să dea posibilitatea de a decide entităţile ce vor fi cuprinse într-o pagină fără a
trunchia informaţiile
- să permită construirea automată a unor tipuri echivalente de diagrame
- pentru realizarea acestor facilităţi şi deoarece opţiunile şi comenzile de editare a
diferitelor diagrame sunt foarte numeroase editorul de diagrame foloseşte în
general bare de comenzi, cutii de dialog sau meniuri senzitive de context.
Baza de informaţii (repository) - este, de asemenea, o componentă obligatorie care
are drept rol acumularea şi stocarea în maniera organizată a tuturor informaţiilor
introduse de persoane diferite la momente diferite, eventual în locuri diferite.
Repository-ul este elementul central, inima unui CASE, care trebuie să memoreze
toate informaţiile despre proiecte şi să permită ca pornind de la acestea să se creeze
informaţie nouă care să fie la rândul ei plasată în repository.
Pentru un proiect sunt verificate şi corelate toate informaţiile existente în
repository cu scopul de a asigura integritatea şi consistenţa lor. Mai exact diferitele
tipuri de diagrame reprezintă aceeaşi informaţie privită din diferite puncte de vedere,
deci trebuie să aibă o legătură logică între ele.
- datele introduse în anumite diagrame pot fi utilizate si în alte tipuri de diagrame
si depozitul de date este cel care asigura consistenta informaţiei între diferitele
diagrame. Modificările efectuate asupra unei entităţi dintr-o diagrama sunt
automat reflectate în reprezentarea ulterioară a aceleiaşi entităţi în orice altă
diagramă. Dintre caracteristicile şi în acelaşi timp avantajele oferite de acest
instrument sunt următoarele:
- documentaţia de realizare a oricărui proiect, în totalitatea ei, se găseşte în
repository, de unde poate fi tipărită integral sau parţial şi la cerere
- documentaţia finală a produsului software este realizată pe baza informaţiilor
despre proiect, conţinute în repository
- creşterea preciziei şi a acurateţei documentaţiei faţă de cazul în care aceasta este
realizată pe hârtie, deoarece sunt detectate erorile, inconsistenţele şi omisiunile,
ştiut fiind că mai cu seamă în cazul aplicaţiilor şi produselor software complexe
elaborate în cadrul unei echipe aceste aspecte sunt greu de controlat, asigură lucrul
în echipă şi în reţea, pe de-o parte prin accesul controlat al membrilor echipei la
componente de diferite nivele ale proiectului, pe de altă parte prin gestionarea
legăturilor dintre componentele ce formează arhitectura unei aplicaţii, a unui
proiect.
Analizorul de structură - este componenta care are drept rol depistarea şi eliminarea
unor erori dificil de localizat şi tratat în fazele ulterioare celei de introducere a
informaţiilor.
Analizorul este în strânsă legătură cu editorul de diagrame şi cu repository şi funcţia
lui este de a compara ultimele date introduse cu cele existente pe repository, şi de a
semnala:
- introducerea în acelaşi domeniu de vizibilitate (diagramă, dicţionar de date, etc.)
a două entităţi de acelaşi tip, cu acelaşi nume
- verifică dacă toate entităţile referite sunt definite
- semnalează relaţii de moştenire definite circular
- verifică corectitudinea semantică şi sintactică a adnotărilor formale.
 Instrumente pentru reverse engineering (inginerie inversă) au rolul de a reveni
din fazele de sfârşit ale realizării aplicaţiei în fazele de început, adică actualizarea
diagramelor în raport cu modificările efectuate în cod. Acest lucru permite dezvoltarea
interactivă a unui produs software prin bascularea între proiectare şi implementare.
Generatorul de cod - permite transformarea în cod, într-un anumit limbaj de
programare, a diagramelor realizate în faza de proiectare.
Browser specializat - este instrumentul pentru vizualizarea informaţiilor unei
mulţimi de entităţi cu structură complexă, entităţi între care există o multitudine de relaţii.
El permite accesul direct al utilizatorului la diagramele care descriu proiectele, conţinute
în repository şi pentru a facilita accesul la informaţii dispune de opţiuni de filtrare şi
căutare. Aceste posibilităţi fac posibilă regăsirea rapidă a resurselor unui proiect şi
reutilizarea unor module în cadrul diferitelor proiecte în curs de dezvoltare.
Generator de documentaţie - conţine modele de documente şi oferă utilizatorului
posibilitatea de a-şi concepe propriile documente în mod flexibil. Fiind legat de
repository, furnizează informaţii la zi referitoare la proiect. Orice modificare a unei
diagrame dintr-un proiect induce modificarea automată a documentului asociat. Pot fi
generate rapoarte standard pentru monitorizarea unui proiect si pentru evaluarea
informaţiilor de dezvoltare, dar pot fi realizate şi rapoarte proprii ale utilizatorului.
Gestiunea configuraţiei - configuraţia însemnând proiectul aplicaţiei, codul şi
documentaţia, toate putând fi gestionate global. Acest lucru permite membrilor echipei
de dezvoltare să lucreze în paralel şi în acelaşi timp să folosească informaţia conţinută în
modelul global pentru a dezvolta orice proiect nou.
Abordarea orientată pe model Etapele realizării
Etapele realizării
Modelul de bază al SI din depozit include descrierea funcțiilor, proceselor, obiectelor,
regulilor business, structurii organizaționale, pentru care pot fi utilizate modelele tip.
Modelele tip descriu configurațiile SI pentru ramuri sau tipuri de producție.
Modelul unei întreprinderi concrete este construit sau prin alegerea unor fragmente ale
modelului de bază sau modelului tip conform particularităților specifice ale întreprinderii
(BAAN Enterprise Modeler), sau prin adaptarea automatizată a acestor modele ca rezultat
al unor sondaje expert (SAP Business Engineering Workbench).
Modelul construit al întreprinderii este păstrat, sub forma unei metadescrieri, în depozit
și poate fi corectat la necesitate. În baza acestui model are loc configurarea automată și
acordarea parametrilor sistemului.
Modelul funcțiilor business - decompoziția ierarhică a activității întreprinderii.
Modelul proceselor business reflectă îndeplinirea lucrărilor pentru funcțiile de la cel mai
de jos nivel. Pentru descrierea proceselor este utilizat modelul ЕРС - Event-driven
Process Chain.
Modelele obiectelor business sunt utilizate pentru integrarea aplicațiilor, care realizează
diferite procese business.
Modelul structurii organizaționale a întreprinderii - structură ierarhică, care include
departamentele și personalul.
Implementarea unui SI tip începe cu analiza cerințelor, care sunt stabilite la etapa de
cercetare preproiect.
După alegerea PP în baza modelelor de referință are loc construirea modelului preliminar
al SI, în care sunt reflectate toate particularitățile realizării SI pentru întreprinderea dată.
Modelul preliminar servește ca bază pentru alegerea modelului tip al sistemului și
determinarea listei componentelor, care vor fi realizate utilizând alte resurse program sau
vor solicita crearea folosind instrumentele prezente în cadrul SI tip (de exemplu, ABAP
în SAP, Tools în BAAN).
3 Proiectarea sistemului informatic
În faza de proiectare a sistemului informatic vor fi preluate specificaţiile detaliate
elaborate în faza de analiză si se vor definitiva structura bazei de date, modulele si
procedurile funcţionale, formatele de intrare/ieşire şi ecranele aplicaţiei.
Subetape
- arhitectura sistemului
- proiectarea modulelor
- proiectarea fisierelor si a bazei de date
- detalierea dimensiunilor sistemului
- definirea modului de testare a sistemului
- întocmirea documentatiei aproape de forma finală
- revizuirea planului de dezvoltare a sistemului.
De asemenea, proiectarea este un proces predominant iterativ, cu posibilitatea revenirii
pe subetape când modul de finalizare a acestora nu este acceptat de catre echipa de
analiza-proiectare (figura 4).
SPT pe  integrarea componentelor  pot apărea probleme, generate de
obiecte datorită unității legarea proiectului tip de un obiect
Proiecte metodologice și concret, ceea ce poate conduce în unele
SI de informaționale, cazuri la necesitatea modificării structurii
ramură compatibilității tehnice și organizaționale și economice a obiectului
logice automatizării
 arhitectura deschisă permite
utilizarea SPT pentru
diferite platforme tehnice și
logice
 scalabilitatea permite
configurarea SI pentru un
număr variabil de posturi
 prin configurare este
posibilă alegerea
componentelor

Tabelul 3.3. Avantajele și dezavantajele SPT

Clasa SPT
Realizarea Avantaje Dezavantaje
SPT
SPT pe  abordăre modulară pentru  cheltuieli mari de timp pentru
elemente proiectarea și documentarea SI racordarea elementelor
Biblioteci de eterogene ca rezultat al
programe incompatibilității informaționale,
orientate pe logice sau tehnice
metode  cheltuieli mari de timp pentru
revizuirea SPT pentru unele
elemente
SPT pe  nivel înalt de integrare a  adaptabilitate insuficientă din
subsisteme elementelor punctul de vedere al ingineriei
Pachete de  permite realizarea proiectării continue a proceselor business
programe modulare, adaptarea  probleme în integrarea unor
aplicative parametrică a componentelor sisteme diferite, în special în
program pentru diferite obiecte cazul utilizării unor soluții de la
de gestiune producători diferiți
 asigură diminuarea cheltuielilor
 documentare bună a
proceselor de prelucrare a
informației
TEMA 7

Analiza și modelarea spațiului funcțional al Sistemului Informațional

7.1. Modelul busines complet. 7.2. Misiunea companiei. 7.3. Matricea

responsabilităților. 7.1.4. Modelele fluxurilor proceselor. 7.1.5. modelul structurilor de
date.7.1.6. modelul interacțiunii cu mediul exterior. 7.4. Șabloane in modelarea
companiei. 7.4.1. Șabloane pentru elaborarea misiunii. 7.4.2. Șabloane pentru formarea
afacerilor.

Ce este modelarea?- Modelarea este reprezentarea într-un mediu controlat, a

proprietăţilor şi/sau fenomenelor şi proceselor care caracterizează un obiect sau un
sistem real.
Cu alte cuvinte în modelare nu există adevăr absolut;
Modelarea presupune abstracţie şi aducerea în atenţie numai a unor aspecte ale realităţii
studiate şi anume acele aspecte care prezintă interes pentru modelator.
Unul din mediile controlate în care se poate reproduce realitatea, deci unul în care
se pot face modele, este calculatorul.
Modelul este o abstracţie a unei entităţi şi această abstracţie poate fi făcută fie
pentru a crea un model general (de referinţă) care să fie apoi folosit pentru a crea exemple
concrete de sisteme informatice (cazul arhitecturilor de referinţă), fie pentru a crea
modelul informatic al unei entităţi anume, deci un model de transpunere. În cele ce
urmează ne vom referi exclusiv la modele de transpunere.
La crearea modelului intervine viziunea analistului despre realitatea pe care o
studiază, adică paradigma.
Paradigma reprezintă "ochelarii" prin care analistul vede sistemul informaţional
real, acela pe care vrea să-l modeleze, trebuie de menționat că nu toate viziunile sau
concepţiile analiştilor ajung să fie considerate paradigme.

Figura 7.1. Viziuni asupra modelării

7.1 Modelul business complet

Construirea modelului business al companiei începe cu descrierea modelului

interacțiunii cu mediul extern conform legii unității și luptei contrariilor - cu definirea
misiunii companiei.
Analiza organizațională conform metodei engineering - după o schemă bine
determinată cu utilizarea modelului business complet al companiei.
Compania - sistem socio-economic deschis, creat pentru atingerea anumitor
obiective, element al setului de super-sisteme externe, ierarhice deschise - piața,
instituțiile statului etc., și subsisteme interne – departamente, secții, hale, brigăzi etc.
Posibilitățile companiei sunt determinate de caracteristicile componentelor structurale și
modul lor de organizare.

Figura 7.2. Modelul business complet

Noțiuni de bază din domeniul business modelării organizaționale

- misiunea companiei, arborele scopurilor și strategii de realizare
- descrierea statică a companiei: business-potențialul companiei, funcționalitățile
companiei, zonele de responsabililate ale managementului
- descrierea dinamică a companiei
- modele fluxuri de procese
- modelul business complet al companiei
- şabloane ale business modelării organizaționale
- construirea structurii organizaționale funcționale a companiei
- etapele elaborării
- cadrul normativ
- TI pentru modelarea organizațională.
7.1.1 Misiunea companiei

Conform ISO-15704 misiunea companiei include:

- activitățile desfășurate de către organizație în scopul îndeplinirii funcției pentru
care a fost înființată, oferind clienților produse sau servicii
- mecanismul prin care organizația își realizează scopurile și obiectivele.
Misiunea - compromis între interesele pieței și companiei.
Este dezvoltată, pe de o parte, reieșind din conjunctura pieței și poziționarea
companiei în raport cu alți membri ai mediului extern, iar pe de altă parte – reieșind din
posibilitățile obiective ale companiei și valorile sale subiective, așteptările proprii și
principiile de care se conduce.
Misiunea trebuie să dea un raspuns la câteva întrebări fundamentale:
- cu ce se ocupă firma noastră?
- cine sunt clienții noștri?
- cum va arăta firma noastră în viitor?
- cum ar trebui să fie ea în prezent?
Sunt întrebari simple în aparență, dar în realitate, sunt printre cele mai grele întrebări
la care trebuie să răspundă o firmă. Firmele care reușesc în afaceri își pun în permanență
aceste întrebări și caută cu foarte mare atenție raspunsuri complete la acestea.
Cinci elemente distincte a misiunii.
Misiunea unei firme se defineste prin cinci elemente distincte.
- primul este istoria sa
- cel de-al doilea element îl reprezintă preferinţele actuale ale proprietarilor firmei
şi ale conducerii acesteia
- în al treilea rând, conjunctura pieţei are o influenţă importantă asupra misiunii
firmei
- în al patrulea rând, în funcţie de resursele organizaţiei se hotărăşte care misiuni
sunt posibil de înfptuit şi care nu
- în sfârşit, o organizaţie trebuie să-şi stabilească misiunea ţinând cont de
capacităţile sale specifice.
Determinarea misiunii permite crearea
- arborelului obiectivelor companiei - liste ierarhice de precizare si detalizare a
misiunii
- arborelului strategiilor - liste ierarhice de precizare și detalizare a procedeelor de
atingere a obiectivelor
- la nivel corporativ - strategiile de creștere, integrare și investiții
- blocul strategiilor business- determină strategiile de producere, de segmentare și
promovare
- strategiile pentru resurse determină atragerea resurselor materiale, financiare,
umane și informaționale
- strategiile funcționale stabilesc strategiile de organizare a managementului și a
etapelor ciclului de viață a producției. Tot aici sunt clarificate necesitățile și
obiectul relațiilor de parteneriat (subcontractare, prestare servicii, promovare
etc.).
7.1.2 - Business potențialului companiei

Este Asigurarea clienților cu produse şi/sau servicii în cantităţi solicitate, la locul

potrivit, la momentul de timp dorit, cu o anumită calitate şi la costuri minime.
Business potențialului companiei – set de activități comerciale, direcționate spre
satisfacerea necesităților unor segmente concrete ale pieței.
Reieșind din particularitățile canalelor de distribuție este formată ideea inițială
referitor la structura organizatorică (sunt determinate centrele de responsabilitate
comercială). Apare înțelegerea a ceea ce reprezintă resursele de bază, necesare pentru
reproducerea nomenclaturii comerciale.
Potențialul business determină funcțiile companiei – listă de funcții business,
funcții de management și achiziții, necesare pentru menținerea la nivel adecvat a tuturor
activităților.
Suplimentar, mai sunt precizate resursele necesare (materiale, umane, informaționale) și
structura companiei.

7.1.3 Matricea responsabilităților în companie

Matricea responsabilităților în companie este un model reprezentat sub forma

unui tabel bidimensional, care stabilește sistemul de relații între clasificatoare pentru toate
combinațiile lor. Construirea potențialului business și funcționalităților companiei
permite, prin utilizarea matricei proiecțiilor, să fie stabilite zonele de responsabilitate
a managementului (responsabilități comerciale, funcționale). Fixează responsabilitatea
subdiviziunilor structurale privind veniturile de la realizarea activității comerciale.
Detalizarea ulterioară (prin stabilirea centrelor de responsabilitate financiară) asigură
construirea modelului financiar al companiei, care, la rândul său, permite implementarea
sistemului de management bugetar.
Pentru început, metoda RACI este un instrument uşor de utilizat în identificarea
rolurilor şi responsabilităţilor unui proces într-o echipă.
Deşi această matrice oferă o imagine asupra responsabililor şi responsabilităţilor,
cei care le pun în aplicare şi de care depinde reuşita sunt persoanele din echipă.
Este astfel util să se descrie task-urile şi responsabilul fiecăruia, pentru a nu exista
neînţelegeri.
 Figura 7.3. Matricea responsabilităților

Matricea RACI mai poartă numele si de RASCI sau RASIC. Numele provine de la o
abreviere a termenilor din limba engleză: Responsible (Realizator), Accountable
(Autoritate), Supportive* (Sustinere), Consulted (Consultat) şi Informed (Informat).
- Responsible – este cel care este responsabil de realizarea misiunii
- Accountable – cel care iși dă acordul asupra proiectului şi evoluţiei sale, care are
autoritatea, A fiind superior lui R.
- Supportive*– nu este folosit mereu însa când este nevoie, pune la dispozitie
resursele necesare şi susţine implementarea.
- Consulted – urmează a fi consultat, deţine informaţii cu caracter de expert şi
capacitatea de a ajuta la finalizarea proiectului.
- Informed – urmează a fi informat şi notificat asupra rezultatelor fără a fi consultat.
- prin acest proces se pot evidenţia activităţile de realizat, rolurile şi se pot completa
eventualele goluri sau soluţiona suprapunerile. Vertical se vor nota acţiunile,
sarcinile, pe orizontal, vor fi notate entităţile sau persoanele din echipa. Apoi
pentru fiecare acţiune, se va desemna un R, A, C, sau I.
 După cum se poate observa, A si R nu pot lipsi din nici o activitate, însa S, C si I
sunt cu rol opţional. De asemenea, A si R pot fi aceeaşi persoană.

Matricea Fixează responsabilitatea verigilor structurale pentru executarea funcțiilor

business la realizarea proceselor activității
- aprovizionare
- producere
- realizare
ca și a funcțiilor de management, asociate administrării acestor procese
- planificare
- contabilitate
- control
- marketing
- finanțe
- management resurse umane, etc.
Detalizarea de mai departe a matricei (până la nivelul de responsabilitate a angajaților)
va permite obținerea responsabilităților funcționale ale personalului, care, împreună cu o
descriere a drepturilor, obligațiunilor, și împuternicirilor va permite elaborarea pachetului
de instrucțiuni – fișe de post.
Motivele pentru care este indicată această metodă sunt variate. Dintre acestea, putem
menţiona pe cele mai importante şi anume:
Ușor de utilizat. Nu necesita tehnologie speciala şi costisitoare, astfel poate fi utilizată
în orice situaţie, oriunde.
Reflectă profesionalism. Fiecare echipa sau membru al echipei are destinată o misiune,
ceva care îi scoate în evidenţă calităţile, la ce are rezultate mai rapide şi eficiente.
Îmbunătățire perpetuă. Întotdeauna este loc de îmbunătăţire privind realizarea unui
proiect sau activitate şi de aceea, fiecare membru trebuie să ştie unde e nevoie de aceasta.
Responsabilizarea echipelor și membrilor. Câteodată, membrii echipei, lucrând cu
detalii, uită să privească imaginea de asamblu și își uită responsabilitățile.
Imaginea de ansamblu. Prin această metodă se crează o imagine de ansamblu care poate
fi aliniată strategiilor și obiectivelor care conduc echipa.
Descrierea potențialului business, funcționalităților și matricelor de responsabilitate
reprezintă descrierea statică a companiei.
În acestă descriere procesle, care au loc în companie, sunt identificate, clasificate
și repartizate pe executori (viitorii stăpâni ai acestor procese) la un nivel general (sub
formă de funcții). Este format setul de regulamente interne fundamentale și universal
recunoscute ale companiei:
- dispoziția de bază privind structura organizatorico-funcțională
- dispoziții privind activități separate (financiară, de marketing, producere, etc.)
- fișele de post.
Detalizarea ulterioară a modelului business are loc la etapa descrierii dinamice a
companiei la nivelul modelelor fluxurilor proceselor.

7.1.4 Modelele fluxurilor proceselor - modele, care descriu procesul de transformare

succesivă în timp a fluxurilor materiale și informaționale atunci când are loc realizarea
unei funcții business sau de management.
La nivelul de sus este descrisă logica interacțiunii participanților în proces,
La nivelul de jos – tehnologia de lucru a specialiștilor.

7.1.5 Modelul structurilor de date

Determină lista și formatul documentelor, asociate proceselor companiei și
stabilește formatele de descriere a obiectelor mediului extern, a componentelor și
regulamentelor companiei.
Pentru aceasta este creat un sistem de dicționare (cataloage, clasificatoare) în baza
cărora sunt elaborate seturile de documente și rapoartele necesare.
O astfel de abordare permite descrierea activității unei companii folosind o
mulțime universală de registre de management (obiectivelor, strategiilor, produselor,
funcțiilor, verigilor organizatorice etc.)
– clasificatoare ierarhice.

Figura 7.4. Matricea proiecțiilor

 Este obținută prin reunirea clasificatoarelor în grupuri funcționale și fixarea
elementelor diferitor clasificatoare prin utilizarea matricei proiecțiilor - se produce
descrierea scopuri-procese a companiei - permite să fie obținute răspunsuri
la întrebările (modelul Zachman în dezvoltare).

7.4 Șabloane in elaborarea modelelor

7.4.1 Șabloane pentru elaborarea misiunii

O companie, cu mediul înconjurător la nivel micro sau macro, reprezintă o ierarhie

de sisteme deschise, subiect-orientate, imbricate reciproc. Compania este parte a pieței,
pe de altă parte – își apără în luptă concurențială interesele proprii.
Misiunea este rezultatul poziționării companiei printre participanții pieței. Din această
cauză nu este posibilă descrierea misiunii prin analiza structurii interne a companiei.
Pentru descrierea modelului interacțiunii companiei cu mediul exterior este necesar:
- să fie identificată piața (super-sistemul)
- să fie determinate proprietățile (necesitățile) pieței
- să se determine destinația companiei, reieșind din rolul ei pe piață.

Figura 7.5. Misiunea - compromisul între necesitățile pieței și dorința companiei de a

satisface aceste necesități. Căutarea compromisului poate fi organizată folosind
șablonul de mai sus

Modele informaționale dependente reciproc.

Analiza organizațională - construirea unui set de modele informaționale dependente
reciproc, care include:
- Modelul strategic de direcționare
- Modelul funcțional-organizațional
- Modelul funcțional-tehnologic
- Modelul procesual-pe roluri
- Modelul cantitativ
- Modelul structurilor de date
 -

Figura 7.6. Modele informaționale dependente reciproc

Recomandări la elaborarea modelului ”misiunii”

La elaborarea modelului misiunii companiei se recomandă:
- să se descrie baza competitivității companiei – set de caractersitici ale companiei
ca sistem social-economic.
De exemplu:
- pentru obiect – originalitatea tehnologiilor și exclusivitatea resurselor (financiare,
materiale, informaționale etc.)
- pentru subiect – cunoștințele și aptitudinele personalului și experiența
managerilor.
Aceasta determină unicitatea resurselor și aptitudinilor companiei și formează poziția
“pot”.
 Baza competitivității estimare relațiile cu Societșții Civile
și structurilor guvernamentale

identificarea factorilor însoțitori

și compensatori pentru tipul misiunea
de activitate ales Să se identifice
conjunctura pieței

evaluare cheltuieli și
estimare perspectivei
Estimare limitările venituri posibile
dezvoltării tehnologiei
legale, morale,etice
în sfera aleasă
Figura 7.7. Set de caractersitici ale companiei ca sistem social-economic

- să se identifice conjunctura pieței (?există cerere efectivă la bunurile și serviciile

propuse și nivelul de satisfacere a pieței de către concurenți. Necesitățile pieței, poziția
“trebuie”)
- să fie identificată prezența factorilor însoțitori și compensatori pentru tipul de activitate
ales din partea instituțiilor statului
- să se estimeze perspectiva dezvoltării tehnologiei în sfera aleasă
- să se estimeze relațiile cu Societșții Civile și structurilor guvernamentale (susținerea
posibilă sau opoziția)
- să fie estimate rezultatele acestor acțiuni luând în considerație limitările legale,
morale,etice etc. din partea personalului (poziția “vreau”)
- să fie evaluat nivelul cheltuielilor și veniturilor posibile.
Misiunea și relațiile cu mediul

Figura 7.8. Relații misiune mediu

Să fie estimată posibilitatea realizării unui compromis acceptabil pentru toate

părțile și să se formuleze Misiunea companiei în conformitate cu șablonul de mai jos
Misiunea, în sens larg, reprezintă concepția de bază a activității companiei:
- ce va obține clientul pentru satisfacerea necesităților sale
- cine, pentru ce și cum poate fi partener al companiei
- care este baza construirii relațiilor cu concurenții (există posibilitatea unor
compromisuri temporare?)
- ce va obține proprietarul și acționării
- ce vor obține managerii
- ce va obține personalul
- în ce constă colaborarea cu Societatea Civilă
- cum vor fi construite relațiile companiei cu statul.

7.4.2 Șabloane pentru formarea afacerilor

În conformitate cu Misiunea companiei sunt determinate necesitățile social

relevante la satisfacerea cărora este direcționat businessul companiei.
În rezultat - piața formată și produsul de bază, detalizarea cărora determină oferta
companiei pe partea consumatorilor.
 Figura 7.9. Șabloane pentru formarea afacerilor

Cu ajutorul matricei proiecțiilor (șablonul formării afacerilor) este stabilită

corespondența între grupurile de produse și segmentele pieței și sunt determinate afacerile
companiei (la intersecția liniilor și coloanelor – celeulele matricei).

7.4.3 Șabloane pentru formarea funcțiilor business

În baza listei afacerilor, cu ajutorul matricei proiecțiilor, este format clasificatorul

funcțiilor business al companiei.

Figura 7.10. Șabloane pentru formarea funcțiilor business

7.4.4 Șabloane pentru formarea funcțiilor de administrare

 Pentru formarea funcțiilor de management principale sunt elaborate și aprobate
clasificatoarele– “Dispoziția privind componentele managementului” și “Dispoziția
privind etapele ciclului de management”. Exemple

Figura 7.11. Șabloane pentru formare funcțiilor de administrare

7.4.5 Șabloane pentru formarea direcțiilor strategice

Zonele de responsabilitate

Figura 7.12. Șabloane pentru formarea direcțiilor strategice

7.4.6 Șablonul de descriere flux-proces

 Asigură înțelegerea procesului de transformare succesivă a resurselor în produse
ca rezultat al eforturilor diferitor executori, care activează în baza regulamentelor.

Figura 7.13. Șablonul pentru descriere flux-proces

7.5 Abordarea organizațional-funcțională

În baza misiunii sunt formate obiectivele și strategiile companiei. Cu ajutorul lor

este stabilit setul necesar de produse și, ca și consecință – resursele necesare.
Reproducerea produselor are loc datorită prelucrării resurselor în ciclul de producție de
bază.
Componentele sale formează business-funcțiile necesare pentru achiziția
resurselor, producerea și distribuirea produselor la locul de vânzare.
Pentru gestiunea procesului de reproducere este format setul de componente de
management, care generează o listă de funcții de management.
Pentru a susține procesele de reproducere și de management sunt formate seturi
de funcții de sprijin aferente.
Această abordare ne permite de a descrie organizația cu ajutorul unui set
universal de registre de management.

Modelul organizațional-funcțional - Este construit în baza schemei funcționale a

activității companiei.
 Figura 7.14. Modelul organizațional-funcțional
Pentru construirea modelului funcțional-organizațional sunt utilizate două tipuri
de modele elementare:
- Modelele arborescente
- Modelele matriceale

În baza misiunii sunt formate obiectivele și strategiile companiei. Cu ajutorul

lor este stabilit setul programat de produse și, ca și consecință – resursele necesare.

MISIUNEA COMPANIEI
Domeniul de activitate
Obiectivele și strategiile
companiei
pentru acest domeniu
Setul stabilit
de produse
Resursele necesare
Pentr producere

Figura 7.15. Ciclul de producție de bază

Producerea produselor are loc datorită prelucrării resurselor în ciclul de producție

de bază.
Componentele sale formează business-funcțiile necesare pentru achiziția
resurselor, producerea și distribuirea produselor la locul de vânzare.
Pentru gestiunea procesului de reproducere este format setul de componente de
management, care generează o listă de funcții de management.
Pentru a susține procesele de producere și de management sunt formate seturi de
funcții de sprijin aferente.
Această abordare ne permite de a descrie organizația cu ajutorul unui set
universal de registre de management.

Modelul organizațional-funcțional este construit în baza schemei funcționale a activității

companiei.
 Figura 7.16. Schema funcțională a activității companiei

Pentru construirea modelului funcțional-organizațional sunt utilizate două tipuri

de modele elementare:
- Modelele arborescente
- Modelele matriceale

Exemple de modele arboriscente

Figura 7.17 (a). Model arboriscent simplu

 Figura 7.17 (b). Model arboriscent desfășurat

Modelul arborescent – este o listă ierarhică exactă ale obiectelor administrative

evidențiate:
- verigi organizaționale
- funcții
- resurse
inclusiv mecanisme de execuție a proceselor business, documente și structura lor. Fiecare
element al unui clasificator poate fi caracterizat suplimentar cu ajutorul unor atribute:
tipul, scara utilizată, comentarii etc.
De facto, clasificatoarele reprezintă un set de registre administrative, cu informații
de obicei calitative, mulțimea cărora stabilește sistemul de coordonate pentru descrierea
activității companiei.

Modele matriceale

Modelul matriceal – proiecții, care determină sisteme de relații pentru orișice

clasificator.
Legăturile pot avea atribute suplimentare (direcție, denumire, indice, scală,
greutate).
În modelul inițial (de început) sunt utilizate doar câteva clasificatoare ale
domeniul obiectiv:
- grupurile principale de produse și servicii ale companiei
- resursele de care are nevoie compania
- funcțiile (procesele) îndeplinite în companie
- verigile organizaționale ale companiei
Exemple Modele matriciale

Figura 7.17 (c). Model simplu

 Figura 7.17 (d). Model detaliat

În clasificatorul funcțiilor de obicei sunt evidențiate trei compartimente de bază:

- funcțiile principale (primare) – legate direct de procesul de transformare a
resurselor în produse și servicii
- funcțiile de management – sau funcțiile de conducere cu întreprinderea
- funcțiile de asigurare – care asistă activitățile de producere, activități comercială,
activități de management, activități de marketing .

Funcția principală a companiei - livrarea produselor și/sau prestarea serviciilor. Din

această cauză mai întâi are loc descrierea formală, coordonarea și aprobarea de către
conducerea întreprinderii a listei afacerilor (direcțiilor activității comerciale), produselor
și serviciilor. Din acest clasificator contragenților externi trebuie să le fie clar prin ce este
interesantă compania pentru piață, iar pe plan intern – cum este motivată necesitatea unei
funcții concrete.
În rezultatul acestor operații are loc identificarea setului de funcții (funcționalul) și
este creată ontologia unitară de descriere a funcțiilor companiei, care va fi coordonată cu
toți managerii relevanți.
7.6 Nivele de detalizare modele

Practica uzuală de construire a modelelor structurii organizaționale susține două

nivele de detalizare:
- modelul agregat
- modelul detalizat.
Modelul agregat - modelul structurii organizaționale în care registrele de evidență sunt
limitate la 2-3 nivele de detaliere.
Scopul construirii acestui model este punerea la dispoziția conducerii superioare
a informației despre structura organizațională pentru realizarea analizei strategice și
analiza privind corespunderea structurii date strategiei și mediului înconjurător al
companiei.
Modelul poate de asemenea fi pus la dispoziția utilizatorilor externi (de exemplu,
investitorilor potențiali sub formă de ilustrare a planului business, clienților mari ș.a.).
Modelul detalizat - modelul structurii organizaționale cu o detalizare mai adâncă
a registrelor de evidență, decât în modelele agregate. Nivelul de detalizare este determinat
de necesități concrete ale companiei.
Scopul: prezentarea informațiilor despre repartizarea obligațiunilor funcționale între
subdiviziunile companiei, ca și despre organizarea proceselor business în companie.
Permite crearea diferitor regulamente interne.

Figura 7.18. Detalizarea Compartimentelor de bază

Dezavantajele abordării funcționale

- partiționarea tehnologiilor de executare a lucrului
- lipsa unei descrieri integre a tehnologiilor
 - dificultatea reunirii celor mai simple sarcini
- lipsa responsabilității executorilor de rezultatul final
- costuri mari pentru coordonare
- lipsa orientării spre client

7.7 Abordarea procesuală

Orice activitate sau set de activități în care sunt utilizate resurse pentru
transformarea intrărilor în ieșiri poate fi considerată proces. Definiție conform
standadul ISO 9000:2000.
Pentru o funcționare rezultativă organizațiile trebuie să definească și să
administreze multiple procese interdependente și care interacționează între ele.
Ca regulă (dar nu este obligator) ieșirea unui proces formează intrarea altui proces.
Identificarea și managementul sistemic al proceselor utilizate în cadrul
organizației și, în special, interacțiunile acestor procese poate fi considerat fiind
”abordare pe procese”.
Instrumente (limbaje) utilizate pentru modelare în abordarea pe procese:
Business Process Modelling Languages (Methods):
- Process Interchange Format (PIF)
- Process Specification Language (PSL)
- MIT Handbook of Organisational Processes
- IDEF0 – > IDEF3
- UML’s Activity Diagram (state diagram)
- SAP R/3: EPC
- Petri Net
- Business Process Model, BSDM
- RAD, RACD
- Flow-Control, Data-Flow Diagram
Framework: Workflow Reference Model (WfMC)
Recently - “SW version” BPM: XPDL, OWL-S, BPML,
BPEL4WS, WSML

Modele de flux a proceselor

Descriu procesul de transformare succesivă a fluxurilor materiale și

informaționale la realizare a unei funcții business sau de management.
La nivelul superior este descrisă logica interacțiunii participanților la proces, la nivelul
inferior – tehnologia de lucru a specialiștilor la posturile lor de lucru.
Modelele de flux procesuale răspund la înrebările cine-ce-cum-cui.
La moment - trecerea de la modelul funcțional la modelul procesual.
Fiecare proces parcurge o serie de subdiviziuni, în îndeplinirea lui participă
specialiști din diferite secții ale companiei. Nimeni nu gestionează procesul propriu-zis,
administrate sunt doar subdiviziunile. Mai mult, structura companiei este construită fără
a lua în considerație optimizarea proceselor business, care asigură funcțiile necesare.
Abordarea procesuală deplasează accentele de la administrarea unor elemente
structurale separate la managementul proceselor business, care leagă activitatea tuturor
elementelor structurale.
 Abordarea procesuală permite eliminarea fragmentării activităților, decalajelor
organizaționale și informaționale, dublarea, utilizarea nerațională a resurselor
financiare, materiale și de personal.
Abordarea pe procese presupune:
- delegarea largă a împuternicirilor și responsabilităților utilizatorilor
- deciziile sunt luate la nivelurile de jos
- principiul managementului pe proces este combinat cu organizarea activității în
grup
- atenție sporită la asigurarea calității
- automatizarea tehnologiilor de exectuare a proceselor business.
Principiul de bază al abordării pe procese - Structurarea sistemului business conform
activității și proceselor business ale organizației, și nu conform structurii organizaționale.
Procesele business, care asigură rezultat relevant pentru consumator, prezintă valoare
și pentru specialiștii, care proiectează SI.
Modelul procesual al companiei trebuie să fie elaborat în conformitate cu următoarele
poziții:
- nivelul superior al modelului trebuie să reflecte doar contextul diagramei –
interacțiunea unicului proces contextual modelat al companiei cu lumea externă
- la nivelul 2 vor fi reflectate procesle business grupate tematic și legăturile lor
reciproce
- fiecare activitate trebuie detalizată până la procese business.
- descrierea unei operații business elementară are loc folosind minispecificațiile.

Abordarea pe procese Solicită:

Studierea complexă a tuturor părților vieții organzației – bazele juridice și regulile
de activitate, structura organizațională, funcțiile și rezultatele executării lor, interfețele,
asigurarea cu resurse, cultura organizațională. În rezultatul analizei este creat modelul
“cum este”. Cercetarea acestui model permite să se stabilească cât de raționale sunt
procesele business, să se determine dacă o operație anume este orientată spre un produs
final social relevant sau este o procedură birocratică redundantă.
La analiza P.B. sunt cercetate detaliat sferele de responsabilitate ale
subdiviziunilor, conducătorilor și angajaților. Sunt stabilite coordonatele proprietarilor
proceselor business, sunt create condiții pentru dezvoltarea și implementarea sistemelor
de stimulare și responsabilitate pentru rezultatele finale, sunt determinate momentele și
procedurile de transferare a responsabilității.
Realitatea
O companie “curat procesuală” este mai degrabă ilustrarea organizării corecte a
activităților. În realitate, toate procesele business ale companiei au loc în cadrul structurii
organizaționale a întreprinderii, care descrie competențele și relațiile funcționale.
Managementul activităților curente are loc pe două direcții – managementul
domeniilor funcționale, și managementul proceselor business integrate.
Managementul domeniilor funcționale – domeniilor, care susțin mulțimea
proceselor business unificate, și divizate pe operații.
Obiectivul managementului proceselor business integrate este direcționarea și
coordonarea proceselor unificate pentru îndeplinirea comenzilor operative ale clienților
și proiectelor proprii ale organizației.
Posesorii de procese

Atunci când compania începe să se orienteze spre procese foarte important devine
rolul proprietarilor proceselor, care au tangențe cu multe domenii funcționale.
Noua paradigmă de activitate generează apariția unui număr mare de procese de
management, repartizate pe întreaga companie (nu concentrate în unități organizaționale
specializate): sistemul de calitate, buget, marketing ș.a.m.d.
Delegarea înputernicirilor, (a puterii! nu se refuză ușor).
Simplificarea legăturilor între subdiviziuni și diminuarea numărului de nivele verticale
prin care trec documentele - condiție necesară pentru realizarea reingineriei.
Elementele de bază ale abordării procesuale

La abordarea procesuală - Întreprinderea este considerată ca un - sistem business

– sistem care constă dintr-o mulțime de procese business legate, obiectivele finale ale
cărora este producerea de bunuri sau servicii.
Procesul business - set de activități sau lanţ de activităţi, care creează rezultat cu valoare
pentru consumator, - un bun și/sau un serviciu.
Fiecare proces are Rolurile şi limitele sale:
Roluri
Proprietarul procesului - persoana responsabilă de mersul și rezultatele procesului în
totalitate.
Liderul echipei este - colaborator cu cunoștințe în domeniul procesului business.
Responsabil de executare (comunicatorul) - lucrătorul care instruiește echipa în metodele
de lucru.
Coordonatorul procesului – lucrătorul responsabil cu lucrul de coordonat toate părțile
afacerii.
Echipa este unul din elementele de bază ale abordării procesuale. Există câteva tipuri de
echipe procesuale:
Echipa situațională – lucrează de obicei în bază constantă și execută un lucru periodic
repetabil.
Echipa virtuală – este creată pentru dezvoltarea unui produs sau serviciu nou.
Membrii echipei - specialiști de diferite nivele din ierarhie.
Manager situațional – specialist, care poate îndeplini independent până la 90% din
volumul de lucru dîn proces.

Formarea echipelor procesuale

O sarcină importantă a abordării procesuale este formarea şi pregătirea echipelor
procesuale și trebuie să conțină:
- cursuri de instruire specializate
- formare profesională (training) se însușire a metodelor, metodicilor ș.a.
- testare compatibilitate psihologică a membrilor echipei
- testare aptitudini practice
testare aptitudinii de lucru în echipă.
Arborele obiectivelor - Atingerea unui set definit de obiective în rezultatul îndeplinirii
proceselor business se numește arbore al obiectivelor. Arborele obiectivelor are, de
obicei, formă ierarhică.
Fiecare obiectiv are propria pondere (cantitativă sau calitativă) și propriul criteriu de
accesibilitate.
Arborele funcțiilor - Mulțimea funcțiilor business reprezintă decompoziția ierarhică a
activității funcționale a întreprinderii și se numește arbore al funcțiilor.
Procesele business realizează funcțiile business ale întreprinderii. Prin funcție business
înțelegem un tip de activitate a întreprinderii.
Arborele indicatorilor - Indicatori de măsurare a performanței proceselor care
formează arborele indicatorilor. Funcțiile business sunt orientate la atingerea unor
indicatori de activitate a întreprinderii, care formează arborele indicatorilor. În baza
indicatorilor este construit sistemul indicatorilor de estimare a eficacității îndeplinirii
proceslor. Proprietarii proceselor controlează procesele business proprii utilizând acest
sistem de indicatori.
Indicatori de măsurare a performanței proceselor:
- cantitatea produselor de o calitate prestabilită într-un anumit interval de timp
- cantitatea de resurse utilizate la poducerea acestor produse
- durata executării operațiilor-tip
- sinecostul unei unitîți de produs, ș.a. indicatori
Descrierea proceselor - Fiecare activitate a companiei este realizată ca proces, care are
consumatorul său: extern – clientul sau inetrn – colaboratorii sau subdiviziunile
companiei, care realizează alte procese.
La etapa descrierii sistemice a proceselor este determinată relevanța fiecărui
proces, inclusiv are loc eliminarea activităților neclare. La această etapă sunt selectate
procesele cheie.
Probleme care trebuie soluționate la descrierea proceselor:
- identificarea întregului sistem de “domenii funcționale” și a proceselor companiei,
ca și legăturile reciproce între procese
- selectarea proceselor integrate “cheie” și descrierea lor la nivelul fluxurilor.
Tipuri de procese business
Cele mai frecvente sunt următoarele patru tipuri de procese business:
- procesele care creează cea mai mare plusvaloare
- procesele care creează cea mai mare valoare pentru clienți
- procesele cu cea mai intensivă interacțiune între verigile de producție, care
creează costuri tranzacționale
- procesele definite de standardele ISO 9000 ca fiind obligatorii pentru descrierea
și implementarea sistemului de management al calității.
Sunt recomandate următoarele categorii de procese:
- de bază (principale, primare)
- de management
- de asigurare (auxiliare și de dezvoltare).

Figura 7.19. Categorii de procese

Procesele de bază
 Formează ”ciclul de viață” al producției companiei. Criteriul de eficacitate al acestor
procese este calitatea, exactitatea și punctualitatea executării fiecărei comenzi. Procese
din această categorie pot fi multe. Toate trebuie descrise pe lanțuri producere-comerciale:
- interacțiunea primară cu clientul și determinarea cerințelor acestuia
- satisfacerea solicitării (cererea pieții, comenzile clientului,contractului…)
- suport post-vânzare și monitorizarea satisfacerii necesităților.
Decompoziția proceselor
Pentru a reflecta ciclul de producere procesele de bază pot fi decompuse, ca exemplu
Procesul “realizarea (solicitării clientului)” poate fi decompus în următoarele
subprocese – procese de nivel mai jos:
- elaborarea (proiectarea) producției
- achiziții (bunuri, materiale, componente)
- transportarea (achizițiilor și a producției )
- descărcarea, primirea la depozit și păstrarea (achizițiilor)
- producerea (conform ciclului tehnologic și logistica internă)
- primirea la depozit și păstrarea (producției finite)
- start-up (lansare și ajustare)
- prestare servicii (conform contractului sau individuale) ș.a.

Procesarea documentelor ce însoțesc procesele de producere

La estimarea etapelor de lucru cu un documentUtilizăm analiza “ciclului de viață a
documentului” parcurs de un specialist:
- prezintă datele inițiale
- pregătește, elaborează documentul
- completează
- corectează
- perfectează
- semnează
- verifică conformitatea cu cerințele stabilite
- vizează
- coordonează
- aprobă
- accentuează (referințe)
- păstrează
- face o copie.
La procesare pot fi utilizate modelele de referință ale activității unor companii
analogice –procesele din firmele concurente, lider ai ramurii.
Procesele de management
Sunt procesele, care acoperă tot complexul de funcții de management la nivelul fiecărui
proces și sistemului în întregime. Au drept obiectiv pregătirea și adoptarea deciziei
administrative.
Deciziile administrative pot fi luate pentru întreaga organizație, pentru un domeniu
funcțional separat sau pentru procese separate, de exemplu:
- management strategic
- proiectarea organizațională
 - marketing
- administrare financiar-economică
- logistica și organizarea proceselor
- managementul calității
- personalul.
O altă sistematizare posibilă a proceselor de management - este legată de noțiunea ciclu
de management și se bazează pe cinci funcții inițiale ale managementului:
- planificare
- organizare
- administrare
- coordonare
- control.
Ciclu de management - Orice activitate managerială se desfășoară în conformitate cu
“ciclul managerial” care include:
- colectarea informației
- elaborarea deciziei
- realizarea
- evidența
- controlul
- analiza
- reglarea.
Tipuri de management
În lanțul resurse –transformare resurse- produse și servicii - Pentru procesul de
management evidențiem două tipuri de procese asociate de management: convențional
notat
- “managementul resurselor”
- “managementul organizării”.

Figura 7.20. Tipuri de management în transformarea resurselor

Executorii
Fiecare din Tipuri de management de mai sus au executori caracteristici proprii –
manageri, care pot fi divizați în trei categorii principale:
- conducător (responsabil de adoptarea și organizarea îndeplinirii deciziilor);
- specialist-analitic (responsabil de pregătirea deciziei și analiza devierilor);
- executorii tehnici (colectarea informațiilor, evidența, comunicațiile).
La baza ciclului de management al resurselor sunt puse modelarea imitațională și
controlul calculelelor sau rezultatelor:
- alegerea (sau receptarea de la un sistem de nivel superior) a criteriului obiectiv de
estimare a calității deciziei
- colectarea informațiilor privind resursele întreprinderii sau posibilităților
mediului
- calculul variantelor (pentru diferite ipoteze privind posibilele valor ale
parametrilor)
- alegerea variantei optimale – adoptarea deciziei (= planului de resurse)
- raportarea rezultatelor
- compararea cu criteriul adoptat de estimare (=controlul rezultatelor)
- analiza cauzelor devierilor și reglarea lor (întoarcere la 1, 2 sau 3).
La baza ciclului de management organizațional stă modelarea structurală sau
procesuală și controlul procedural:
- determinarea componenței lucrărilor
- selectarea executorilor
- proiectarea procedurilor
- coordonarea și aprobarea regulamentului de execuție
- raportarea despre executare
- controlul executării
- analiza cauzelor devierilor și reglarea (întoarcere la 1, 2 sau 3).
Procesele de asigurare- Sunt procesele destinate să asigure posibilitatea desfășurării
proceselor de bază și auxiliare și care sunt orientate spre susținerea mijloacelor universale
ale acestora. La nivelul superior de detaliere pot fi evidențiate următoarele procese
auxiliare stadard:
- asigurarea producerii
- asistența tehnică și reparația
- asigurarea cu resurse energetice
- deservirea și reparația clădirilor
- asigurarea tehnologică
- asigurarea metrologică
- securitatea muncii
- controlul ecologic
- asigurarea managementului
- asigurarea informațională
- asigurarea comunicațională
- asigurarea juridică
- asigurarea securității.
 1.7.1 Matricele-generatoare de procese
Pentru fiecare dintre subprocesele evidențiate trebuie de asemenea să se determine,
care proces de bază sau de managemnt este consumatorul acestor servicii interne. Pentru
aceasta vor fi utilizate matricele-generatoare, care pot fi construite separat pentru
procesele de bază și procesele de management

Figura 7.21. Matricea Funcții Business

Figura 7.22. Matricea generatoare funcțiilor de management

Modele business de referință

Modele business de referință Este un model business procesual eficient, creat

pentru companii dintr-o ramură specifică, pus în aplicare în practică și destinat utilizării
în dezvoltarea / restructurarea proceselor de afaceri în alte întreprinderi.
Scheme etalon de organizare a afacerilor, concepute pentru procese de afaceri
specifice, bazate pe experiența reală de punere în aplicare în diverse companii din întreaga
lume.
 Acestea includ proceduri și metode de organizare a managementului, verificate în
practică. Modele de referință permit companiilor să înceapă dezvoltarea propriilor modele
pe baza unui set existent deja de funcții și procese.
Modelul de referință al procesului de afaceri include un set de funcții legate logic.
- pentru fiecare funcție este specificat un executor, documentele de intrare și de
ieșire sau obiectele informaționale.
- elementele (funcțiile și documentele) modelului de referință conțin referințe la
obiectele SI, precum și documente și alte informații (manuale de utilizare,
dezvoltatorii responsabili), situate în depozitul proiectului. De aici și numele -
modelul de referință (în engleză, reference model).

Obiectivul proiectării organizaționale

Obiectivul principal al proiectării organizaționale este determinarea

compromisului între eficiența resurselor și eficacitatea proceselor.
Specializarea rigidă a subdiviziunilor economisește resursele organizației, dar
diminuează calitatea realizării proceselor.
Crearea unor echipe “procesuale” cu specialiști proprii pentru operațiile cheie
diminuează timpul necesar și sporește exactitatea execuției procesului, dar costă scump.
Uneori organizațiile își pot permite alegerea acestei căi, în special în cazurile în care este
vorba despre procese cu valoare ridicată pentru care clientul este gata să plătească.
Dar, de regulă, este căutat un compromis folosind structurile matriceale procesuale.