Sisteme informatice integrate.doc

Sisteme informatice integrate

Câteva principii legate de sistemele informatice integrate Datele sunt accesibile tuturor salariaţilor (şi unde este cazul), şi publicului. Datele sunt generate şi stocate o singură dată. Datele sunt actualizate în raport cu situaţia curentă (sunt ţinute la zi) Datele se prezintă într-o formă care este utilizabilă de toate programele fără translatare. Programele sunt uşor de folosit şi lucrează împreună. Există cursuri sau manuale de

utilizare Programele folosesc o bază de date comună care este accesibilă tuturor programelor şi

este ţinută la zi de toate programele Programele sunt interoperabile (adică pot să facă schimburi de date direct între ele fără a

fi necesar ca utilizatorul să efectueze conversii de date) Baza de date acceptă atât intrări de date în serie (batch) cât şi intrări din formularele de pe

ecran destinate utilzatorilor. Toate programele se rulează pe calculatoare de tip PC cuplate în reţea Programele pot opera în medii de programare flexibile în care numele, lungimea şi

locaţiile elementelor din compunerea datelor, se pot schimba fără a fi necesară reprogramarea.

Interfeţele utilizatorilor cu componentele sistemului sunt proiectate în aşa fel încât să fie intuitive (să emuleze funcţiile comune procesului sau activităţii ce face obiectul informatizării), să se poată naviga cu uşurinţă prin aceste interfeţe. Să includă funcţii de help extensibile, iar documentaţia necesară utilizatorilor să fie uşor accesat.

De-a lungul întregului sistem sunt folosite mecanisme de integritate a datelor (cum ar fi: standarde privitoare la date, salvarea datelor ce vor fi utilizate pentru restaurări, securitatea sistemului şi a datelor, verificări ale integrităţii datelor – prevenirea introducerii unor date eronate). Mecanismele de integritate a datelor vor fi cât mai sigure posibil, vor solicita minimum de intervenţii sau de activitate din partea utilizatorului şi vor trebui să minimezeze impactul negativ al utilizatorului.

1. Principiul integrăriiPrincipilu integrării derivă din principiul ordinii şi organizării conform căruia diferitele elemente au tendinţa de a se organiza în sisteme, iar sistemele, la rândul lor, au tendinţa de a se organiza în alte sisteme, din ce în ce mai complexe. Principiul integrării care rezultă din cele de mai sus, este că pe lângă organizare, fenomenele tind şi spre integrare. Ca urmare lumea devine o ierahie de integrări şi în univers nu există sisteme închise sau sisteme izolate, orice sistem fiind un subsistem al unuia mai mare. Şi invers: fiecare sistem de pe un anumit sistem de organizare a materiei este format dintr-o reuniune de subsisteme de ordin inferior. Dacă organizarea duce la integrare şi integrarea duce la creşterea complexităţii, aceasta la rândul ei determină diversificare.

2. Tipuri de integrăriIntegrarea genetică. Elementele unui sistem fac parte din acesta pentru că au apărut sau au luat naştere în acel sistem

Integrarea prin constrângere. Integrare prin forţă, elementele sistemului fiind obligate să funcţioneze într-un anumit cadru organizatoric. Rolul de factor coercitiv poate fi jucat de legi, acte normative, regulamente de organizare şi funcţionare, etc. Integrarea prin dependenţă. Elementele unui sistem continuă să rămână în cadrul lui pentru că depind într-un fel sau altul de alte elemente (exemplu, sistemul producţie este dependent de cel financiar sau ciclul bani-marfă-bani)Integrarea la alegere. Se referă la posibilitatea unor sisteme de a-şi alege sistemul căruia să-i aparţină. Pentru aceasta sistemele trebuie să aibă posibilitatea de a alege şi capacitatea de a prelucra informaţiile care ar putea genera criterii de alegere.Integrarea întâmplătoare. Apartanenţa unui sistem la un sistem sau altul este rezultatul unei întâmplări.

3. Reglarea prin integrareReglarea reprezintă procesul prin care sistemele tind să-şi menţină o anumită stare şi ea necesită substanţă, energie şi informaţie.Elementele sistemului reglabil pot fi organizate în serie sau în paralel.Pentru organizarea în serie, un exemplu îl poate constitui în metoda calculului pe faze, influienţarea costului de la o fază de fabricaţie la alta.În cazul organizăriii în paralel elementul “1” poate înlocui sau compensa o eventuală defecţiune a elementului “2”. De exemplu în cazul sistemelor de fabricaţie, un utilaj defect poate fi suplinit prin încărcarea suplimentară a altor utilaje. În cazul sistemelor cibernetice organizarea este în circuit, adică un element “2” care a fost influienţat de elementul “1”, poate la rândul său să influienţeze elementul “1” pentru a fi corectat. Când elementele “1” şi “2” , sunt contradictorii (la o reacţie pozitivă a elementului “1”, elementul “2” are o reacţie negativă), circuitul are un feedback negativ. Exemplu creştere cheltuieli materiale – reducere beneficiu şi invers.Dacă elementele “1” şi “2” sunt asemănătoare, atunci circuitul funcţionează cu un feedback pozitiv. Se poate observa din cele de mai sus că în sistemul reglabil există un element reglabil şi unul reglator. În sistemele complexe elementul reglator poate fi un adevărat element de reglare şi control, ceea ce poate constitui un început de integrare. Datorită adăugării de noi elemente cuplate în serie se poate ajunge la un lanţ, iar datorită adăugării de noi elemente cuplate în paralel se poate ajunge la o reţea. Reglarea în reţea este caracteristică sistemelor integrate, în care totul se leagă cu totul. În lanţuri şi reţele apar şi anumite cicluri, cu rol de reglare a sistemelor integrate.Dacă numărul elementelor înlănţuite devine foarte mare se ajunge la un exces sau redundanţă, ceea ce face posibilă apariţia altor mijloace de reglare, dar şi la posibilitatea înlocuirii, substituirii sau compensării unor elemente cu altele. Se poate ajunge chir la diferenţierea şi specializarea unor elemente. Elementele specializate devin dependente unele de altele În sistemele hiperintegrate, dependenţa poate constitui un mijloc de influienţare şi reglare a elementelor sistemului şi poate chiar de constrângere, ceea ce duce la sporirea capacităţii de autoorganizare, autogenerare, autoreglare, autoîntreţinere şi autoreparare a sistemelor hiperintegrate.Noile mijloace de reglare sunt deci cuplarea şi înlănţuirea elementelor, reţelele, ciclurile, redundanţa, substituirea, compensarea, dependenţa şi constrângerea.

4. Niveluri şi grade de integrareLa sisteme foarte complexe, nu este suficientă influienţarea reciprocă deoarece este necesară coordonarea activităţii tuturor elementelor şi ca urmare apare necesitatea constituirii unor subsisteme specializate care au rolul de realizare, coordonare şi integrare a tuturor elementelor dintr-un sistem.În funcţie de rolul integrării elementelor sistemului, integrarea se poate realiza prin - subsisteme care realizează integrarea structurală- subsisteme care realizează integrarea funcţională.Subsistemele care realizează integrarea funcţională pot realiza trei tipuri de integrări:- substanţială;- energetică;- informaţională.Deoarece pe lângă relaţiile de coordonare, între elementele sistemului apar şi relaţii de subordonare, se pune şi problema integrării sistemelor integrate.Se poate vorbi de o integrare pe orizontală şi de o integrare pe verticală,respectiv pe niveluri şi paliere.Nivelul cuprinde o mulţime de sisteme autonome între care nu există relaţii de subordonare dar dacă apar astfel de relaţii, atunci el se constituie într-un subsistem al celui superior.O mulţime de niveluri de organizare formează un palier.Între toate nivelurile şi toate palierele pot exista relaţii de interdependenţă.Gradul de integrare este diferit de la un sistem la altul. Datorită accentuării diferenţierii şi specializării elementelor a devenit necesară apariţia unor sisteme de integrare cu rol de sporire a gradului de integrare. Legăturile dintre elementele subsistemelor scad spre vârful sistemului, adică între elementele unor subsisteme aflate pe niveluri inferioare există legături mai puternice decât între elementele unor subsisteme aflate pe niveluri superioare de organizare.Pe măsura creşterii gradului de organizare scade gradul de integrare naturală şi creşte integrarea prin dependenţă.În cazul sistemelor complexe unde totul depinde de totul, apare o hiperintegrare prin dependenţă a elementelor sistemului, unde nici un element nu mai poate exista fără toate celelalte şi atunci, pentru realizarea legăturii dintre elemente, apare necesitatea reglării în reţea. Cu cât reţeaua este mai mare, mai densă şi mai ramificată, cu atât sistemul este mai integrat. În astfel de reţele la nivelurile inferioare de organizare forţa de integrare este înlocuită cu legătura prin reţea.În sistemele hiperintegrate peste reţelele care realizează legăturile substanţial-energetice au apărut şi reţele specializate pentru realizarea legăturilor informaţionale, formând o reţea de reţele. Cele mai multe sisteme îşi păstrează identitatea tocmai prin intermediul mecanismelor de reglare care le conferă hiperintegrarea.

5. Metode specifice moderne utilizate în realizarea şi implementarea sistemelor informatice integrate:

5.1. Metoda MERISEMetoda Merise este una din cele mai elaborate şi mai riguroase metode de abordare a sistemului informaţional şi în plus, dispune şi de programul AMC* Designer specializat în generarea automată a arhitecturii unui sistem informaţional financiar-bancar.

În cazul proiectării prin metoda Merise , ciclul de viaţă cuprinde:studiul de evaluare, modelarea globală, conceptuală, organizaţională, logică, fizică şi în final, implementarea , exploatarea şi întreţinerea sistemului .În cadrul fiecărei etape, în metoda Merise se au în vedere patru viziuni (puncte de vedere din care este văzut sistemul) ale sistemului informatic şi anume: descrieri şi definiţii, comunicaţie, date şi prelucrări. Ele străbat proiectul sistemului, la fel cum cele patru fire din compunerea unui cablu de curent trifazic, pot fi găsite oriunde pe lungimea cablului. Cu alte cuvinte, la orice nivel vrem să analizăm sistemul, aceste elemente trebuie luate în calcul. Dezavantajul acestei metode constă în aceea că implică o formalizare destul de complexă, care în cazul aplicaţiilor sau sistemelor informatice mai simple, mai ales dacă nu dispunem de programul AMC* Designer, nu este justificată. Complexitatea formalizării utilizate în metoda Merise este aproape inevitabilă în cazurile în care avem de a face cu posturi de lucru multiple, când trebuie să existe sincronizări ale acţiunilor unor actori, când se urmăresc timpi de răspuns, sau aspecte speciale legate de securitatea datelor, aşa cum este cazul sistemelor informatice financiar-bancare şi nu numai.

5.1.1. Modelarea globală (MG)a) Descrieri şi definiţii- studierea cadrului legislativ în care-şi desfăşoară activitatea unitatea studiată;- descrierea funcţiilor/domeniilor specifice unităţii studiate;- definirea activităţilor, subactivităţilor şi operaţiilor incluse în fiecare domeniu. În concepţia Merise, o unitate este structurată pe funcţii, domenii, activităţi, subactivităţi/procese, operaţii complexe şi operaţii simple. De exemplu. funcţia servicii financiar-bancare, domeniul credite bancare, activitatea acordare credite bancare, procesul analiza solicitării şi rambursării creditelor bancare, se poate descompune în operaţii complexe (analiza cererii de credit, analiza deciziei de creditare pe termen scurt, înregistrarea creditelor acordate, rambursarea creditului şi înregistrarea rambursării creditului), iar fiecare din aceste operaţii complexe se poate descompune în operaţii elementare, conform machetei de mai jos:FuncţiaDomeniulActivitateaProcesul

OperaţiiComplexe Elementare

Soluţia globală pentru realizarea şi administrarea unui SI trebuie să ţină seama de factori endogeni şi exogeni în raport cu activitatea unităţii economice, de considerente financiare, umane, organizaţionale, conjuncturale, informaţionale, manageriale şi ca urmare, cel puţin teoretic, ar trebui să existe şi un model matematic de optimizare a acesteia.b) Comunicaţiile din SI - descrierea sistemului de organizare: definirea de ansamblu a comunicaţiilor la nivelul structurii de organizare;- definirea soluţiilor globale şi previzibile de organizare a comunicaţiilor de date şi de prelucrări (comunicaţii locale sau după caz comunicaţii on-line cu alte unităţi);- specificarea generală a comunicaţiilor viitoare (instalare de workstations sau implementarea unei reţele);c) Viziunea asupra datelor- definirea obiectivelor manageriale şi funcţionale ale sistemului.- definirea intrărilor şi ieşirilor în concordanţă cu obiectivele stabilite.Se poate întocmi un tabel cu rubricile:activitate, obiective manageriale, obiective funcţionale, ieşiri solicitate şiintrări necesare. d) Viziunea asupra prelucrărilor- definirea subsistemelor informatice şi aplicaţiilor informatice - descrierea conexiunilor dintre subsisteme /aplicaţii în scopul asigurării funcţionalităţii sistemului realizat.

5.1.2. Modelarea conceptuală (MC)Modelarea conceptuală se mai numeşte studiu de detaliu sau conceptual.Ea prezintă specificaţii funcţionale care să asigure acordul între cerinţele utilizatorului şi soluţiile ce se vor adopta. Nu face referiri la tehnică de calcul, organizarea datelor sau prelucrarea acestora. MC asigură o soluţie stabilă căreia îi vor corespunde una sau mai multe soluţii concrete organizaţionale, logice şi fizice elaborate în etapele viitoare.a) Descrieri şi definiţii la nivel conceptual:

- stabilirea funcţiilor/domeniilor sau activităţilor informatizabile autonome; în cadrul acestora se identifică un sistem de conducere, unul informaţional şi unul operant;- stabilirea intrărilor sistemului pe tipuri: off-line (documente de intrare) şi on-line; se vor întocmi tabele cu documente având structura: cod document, denumire, frecvenţa, ce informaţii conţine (casete de editare texte); pentru fiecare document se va întocmi macheta, precum şi un tabel ale cărui coloane sunt chiar denumirile câmpurilor având specificate pe rândul următor tipul câmpului şi dimensiunea;- stabilirea ieşirilor (rapoarte, grafice, indicatori sintetici, ieşiri către alte sisteme). Pentru fiecare raport sau grafic se va prezenta macheta şi dispozitivul de ieşire, iar unde este cazul şi algoritmii de calcul precum şi reguli de disciplină informaţională concretizate în specificaţii legate de modul practic de utilizare a unui raport (funcţia, activitatea, compartimentul beneficiar, numărul de exemplare, frecvenţa, termen, dispozitiv periferic de ieşire, etc.);- sistemul de codificare (tabel cu coduri sau după caz, formule pentru coduri); coduri standard.

b) Modelul conceptual de comunicaţii (MCC)Foloseşte concepte specifice ca: actori, fluxuri, diagrame de flux, matrice de flux, diagramă conceptuală de flux.

Diagramele de flux materializează actorii, legaţi între ei cu săgeţi pe care sunt trecute simbolurile documentelor, iar lângă simboluri se trece în paranteză numărul curent al operaţiei în tabelul ce însoţeşte diagrama. Acest tabel conţine rubricile: nr. de ordine, actorul, descrierea acţiunii acestuia (fluxului realizat), documente/situaţii folosite. În diagrama de flux numele actorului se trece în simboluri reprezentate prin cercuri, hexagoane sau pătrate.Matricele de flux conţin actorii, atât pe orizontală cât şi pe verticală, iar la intersecţie se trec simbolurile documentelor care îi leagă ( de ex. BC bilanţ contabil, sau SS situaţia stocurilor şi cheltuielilor). Pe diagonala principală sunt marcate fluxurile interne. Celelalte sunt fluxuri externe.Diagramele conceptuale de flux seamănă cu diagramele de flux, dar pe săgeţi nu conţin simboluri de documente, ci numărul pasului din compunerea algoritmului referitor la circuitul informaţional reprezentat de diagramă. Un astfel de algoritm este în fapt reflectarea unor prevederi legale sau tehnice referitoare la modul de desfăşurare a activităţii analizate. Pasul descrie în cuvinte cine şi ce trebuie să facă. c) Modelul conceptual de prelucrare (MCP)Se bazează pe conceptele: actori, evenimente/rezultat/mesaje, operaţie, sincronizare, procese, reguli de verificare, reguli de sintaxă, reguli de funcţionare. Pentru fiecare concept există simboluri, iar dintr-un ansamblu de actori, evenimente/rezultat/mesaje, operaţie, sincronizare poate rezulta o operaţie complexă, care poate fi reprezentată cu un simbol general ca în figura de mai jos. Deoarece procesele sunt ansambluri structurate de operaţii complexe, ele pot fi reprezentate prin lanţuri formate din astfel de simboluri, pe baza faptului că rezultatele emise de la o operaţie vor fi evenimente de intrare pentru următoarea operaţie.

EVENIMENTE DE INTRARE

[nume actor] [ nume tip de [nume tip deeveniment] eveniment]

[expresiesincronizare logică]

[nume de operaţie complexă]

Operaţie – elementară – 1 OPERAŢIA .

.Operaţie – elementară – N

[Ecuaţia de [Ecuaţia deemisie R1] emisie Rn]

[nume actor [nume tip de [nume tip de [nume tip de rezultat] rezultat] rezultat]

REZULTATE EMISE

primari (pe baza algoritmilor de calcul) şi întocmirea bazei de atribute. În continuare se întocmeşte matricea dependenţelor şi apoi se poate întocmi MCD ca în exemplul de mai jos.

entităţi

CLIENTI tip relaţie CONTRACT

cheie primară 1,n încheie 1,1 cheie primară listă atribute: valoare credit listă atribute: de ex. adresă procent dobândă 1,n tip atribut entitate

tip relaţie RAMBURSĂRI

achită 1,1 număr OP# cheie primară suma data OP tip atribut

tip atributcardinalitate minimă şi maximă

EXEMPLU DE DIAGRAMĂ MCD

5.1.3. Modelarea organizaţională (MO)

MO vizează repartiţia organizaţională a sistemului informaţional (arhitectura şi localizarea fizică a reţelei de calculatoare, soluţia bazei de date) prin prisma departamentelor, serviciilor şi posturilor de lucru. Nu are în vedere particularităţi tehnice. Trebuie să îndeplinească criterii economice, organizatorice şi de ordin social. MO răspunde la întrebările cine?, unde?, când?. Din MO trebuie să rezulte:- organizarea previzibilă diferenţiată pe departamente/servicii/posturi de lucru privite ca centre de activitate;

d) Modelul conceptual de date (MCD). Urmăreşte determinarea atributelor. Se poate folosi:

- metoda deductivă : se pleacă de la intrări sau ieşiri şi se ajunge la entităţi, proprietăţi, relaţii; - metoda inductivă: prin analiza intrărilor şi a unui formalism se poate con-strui direct un MCP.

MCD se poate determina prin trei variante: ieşiri-intrări, intrări-ieşiri şi varianta mixtă. Subetapa MCD, începe cu analiza documentelor de intrare şi deieşire, extragerea de operanzi

MCD se aseamănă cu diagramele entitate-relaţie (vezi figura alătu-rată ) şi sunt însoţite de regulă, de un tabel de descriere a MCD cu o rubrică numită Descrierea tipurilor de entităţi şi alta Descrierea tipurilor de relaţii; prima este divizată în Tipul de entitate şi Tipul de proprietate, natură, lungime, iar a doua în Tipul de relaţie, Cardinalitate şi Colecţia. Vezi reguli referitoare la MCD, dependenţe funcţionale şi normalizarea Practic MCP se va întocmi după MCD.

- circulaţia informaţiilor între aceste centre de activitate;- sarcinile şi cronologia ce vor fi realizate la nivelul fiecărui post de lucru. a) Modelarea organizaţională a prelucrărilor (MOP) MOP are ca sursă evenimentele şi rezultatele-mesaje provenite din MCP şi asigură transformarea evenimentelor în subtipuri de evenimente şi a rezultatelor-mesaj în subtipuri de rezultate-mesaj. Se utilizează conceptele de post de lucru, sarcină, evenimentul şi rezultatul-mesaj, sincronizarea, resursele, faza, proceduri organizaţionale, reprezentare grafică a MOP, concepte adiţionale şi construcţia MOP. Resursele se pot grupa în:

- factorul uman;- resurse organizaţionale: departamente, servicii sau ghişee;- resurse informatice şi/sau de telecomunicaţii: videoterminale, imprimante, colecţii de

date, proceduri automate, faxuri/modemuri;- resurse de timp: termenele, succesiunea fazelor şi a sarcinilor.

Sarcina este un ansamblu de activităţi elementare având acelaşi scop. Operaţiei complexe din MCP îi corespunde în MOP faza. În MCP operaţiile complexe se descompun în operaţii elementare, iar acestora le corespunde în MOP, sarcina.Sarcinile sunt caracterizate prin: post de lucru (unde li se asociază resurse umane şi informatice), grad de automatizare (manual, conversaţional/interactiv şi automatizat), timp de răspuns şi mod de funcţionare (unitar, de tip lot). Sincronizările vizează operaţii de tip logic cu evenimente: ex. verificare data ordin de plată + ştampilă + semnătură autorizată. Procedura organizaţională (PO) vizează un ansamblu logic şi legal de evenimente tip, apelul evenimentelor iniţiale ale procedurii, sincronizările şi obţinerea tuturor rezultatelor tip. MOP se materializează într-un tabel conţinând coloanele: frecvenţa (Z, d, l, etc.), actori/posturi de lucru sau regrupări de actori şi tipul serviciului. Cu excepţia ultimei coloane şi a celei dintâi, în celelalte coloane este reprezentată grafic cronologia PO, a fazelor şi sarcinilor specifice, folosindu-se în acest scop simboluri de tipul celui de mai jos, care pe un rând dat se pune o singură dată, în coloana care derulează sarcina ce urmează în cadrul procedurii. Simbolurile se leagă între ele cu săgeţi ce marchează continuitatea procedurii.

Dacă este cazul, acest tabel poate fi precedat de un alt tabel unde în loc de reprezentări grafice pe actori, se tratează activitatea pe faze, sarcini aferente, actor implicat, frecvenţă şi tipul serviciilor.b) Modelarea organizaţională a comunicaţiilor (MOC) trebuie să evidenţieze:- locul şi rolul fiecărui actor (departament, serviciu, ghişeu, posturi de lucru) sub aspectul legăturilor informaţionale;

- numărul de apariţii ale fiecărui actor (de ex. un ghişeu apare în 5 exemplare identice);- resursele necesare fiecărui actor (umane, informatice, linii de comunicaţie, timp, secvenţă şi resurse organizatorice: tip actor, număr maxim de apariţii, resursele utilizate, fazele şi sarcinile realizate de el). Iniţial se întocmeşte un tabel cu rubricile: număr curent, tip actor, descriere actor (ex. agent economic, ghişeu, clientelă, contabilitate clienţi), faze realizate (ex. distribuire extrase cont), sarcini (ex. verificare sold curent pe cod client), frecvenţa (A, L, Z, etc.), tipul fazei. În final MOC rezultă prin înlănţiurea simbolurilor de tipul celui de mai jos (şi care seamănă cu un tabel), completat câte unul pentru fiecare actor, evidenţiindu-se legăturile dintre actori cu săgeţi, eventual de tip frânt ( ).

Simbol folosit pentru reprezentarea resurselor organizatorice:

[condiţielogică]

[nume fază]

sarcini[descriere]

[condiţie de emisie]

Sectorul Număr tip apariţii

resurse: RU/RI/RC/RTfaza:frecvenţa

sarcina 1sarcina 2

Tipul

c) Modelarea organizaţională a datelor (MOD). Se pleacă de la MCD şi se urmăreşte:- alegerea proprietăţilor ce vor fi memorate;- specificarea volumului informaţiilor memorate;- repartiţia organizaţională a datelor prin tipuri de unităţi organizaţionale; se specifică fiecare proprietate şi entitate memorată. MOD se defineşte la nivel global derivat din MCD, dar şi la nivel local pentru fiecare tip de unitate organizaţională. Merise oferă metode pentru calculul cardinalităţii medii (m) şi a volumului datelor, cu care se calculează în final coeficientul de participare (P) ca raport al numărului maxim de realizări pe fiecare din cele două entităţi aflate în relaţie. Valorile simbolurilor m şi P apar scrise pe liniile de legătură din diagramele de tip DER., în timp ce cardinalităţile minime şi maxime apar sub aceste linii.Dăm mai jos un exemplu de MOD la nivel global.MOD local se poate reprezenta grafic pe cel global, delimitând zonele fiecărui compartiment beneficiar cu linii întrerupte (a se vedea cadrele punctate – pentru serv financiar şi ghişeu şi cele cu liniuţe pentru serviciul clientelă; al treilea, nemarcat pe desen, destinat serviciului credite, ia totul, mai puţin relaţia "încheie"). Se poate reprezenta şi tabelar, într-un tabel cu rubricile: MOD locale, Tipuri de entităţi, (care este defalcat pe tipuri de entităţi) şi Tipuri de relaţii (care este defalcat pe tipuri de relaţii). În acest tabel, dacă o entitate sau o relaţie aparţine unui MOD local, la intersecţie se pune o steluţă.

BANCA CLIENŢI

1,n lucrează 1,1 1,n cif # nr. cont cif # denumire sold denumire adresă adresă … capital social 1,n forma propr.

1,1 rambursează încheie suma valoare contract obiect plată 0,n 1,1 clauze

pPLĂŢI Contract credit

nr_do #1,1 nr_co # data_dp data_co

. . .

Pentru exemplul de mai sus, tabelul va conţine în prima coloană câte un rând pentru MOD local serviciul clientelă, MOD local serviciul credite şi MOD local serviciul financiar şi ghişeu. Coloana a doua va fi defalcată pe rubricile Banca, Clienţi, Contracte şi Plăţi, iar coloana a treia va fi defalcată pe lucrează, rambursează şi încheie. Toate relaţiile MOD locale sunt definite în funcţie de tipurile de entităţi, proprietăţi şi relaţii din MOD global, de structura informaţională a ieşirilor sistemului şi de compartimentele beneficiare ale acestor ieşiri. După elaborarea MOD global, aceste elemente sunt amplasate într-un tabel cu câmpurile: tip atribut, MOD global divizat în entităţi şi relaţii implicate în MOD global, ieşiri + compartimente. Ultima coloană din acest

tabel este divizată pe ieşiri, sub care se specifică serviciul care beneficiază de ieşirea respectivă. Dacă un atribut se regăseşte într-o coloană, atunci intersecţia acelui atribut cu coloana respectivă se marchează cu steluţă.Estimarea securităţii datelor defineşte restricţiile: nici un fel de acces, creare (C), citire (R), modificare (M) şi ştergere (D). Există securitate intraunităţi, ce defineşte accesibilitatea unui anumit tip de utilizator şi securitate inter-unităţi ce definşte datele specifice partajate şi protejate. Unităţile organizaţionale pot avea acces la datele partajabile de următoarele tipuri: creare sau ştergere, partajabile la consultare, actualizare, fără restricţii de acces. Practic se definesc pentru fiecare (UO) date particulare şi date protejate ca în figura de mai jos.

U01 – serv. clientelă U02 – serv. credite

D1 Dpc1 Dpc2 D2

(date (date particulare) Da1 Da2 particulare)

Modalităţile de acces se pot reprezenta şi tabular ca în tabelul următor:

Tipuri deentităţi şi relaţii

Unităţi organizaţionaleClienţi Credite Financiar

BANCAlucreazăCLIENŢIîncheie

CONTRACTEPLĂŢIrambursează

C R M DC R M DC R M D R M D

R M D R R

R R RC R D

C R D R R

RRRR

RC R M DC R M D

d) Descrieri şi definiţii organizaţionalei. Verificarea coerenţei date - prelucrări: se foloseşte o grilă de coerenţă globală prin care se poate confrunta MCD cu MOD şi MOP. Practic se verifică dacă sarcinile descrise în MOP dispun de datele corecte şi necesare, adică se verifică modul în care tipurile de entităţi şi de relaţii din MCD sunt utilizate în funcţionarea sarcinilor MOP. O astfel de grilă este reprezentată mai jos unde, pentru acţiunile elementare utilizabile în verificarea coerenţei MCD/MOD + MOP se folosesc următoarele prescurtări:MAN – manual, CRE – creare, CIT – citire, MOD – modificare şi ST - ştergere:

MOPsarcini

MCD + MOD – tipuri de entităţi + relaţii tipuri de entităţi tipuri de relaţiiBanca Clienţi Contr Plăţi lucrează rambursează înbcheie

verificarecerere credit

CRE CRE CRE

Admiterecerere credit

CIT CIT

Încheierecontract credit

CIT CIT CRE CIT CRE

Rsmbursarecredit

CIT CIT CIT CRE CIT CIT CRE

Urmărirearambursăriicreditelor

CITMODST

CITMODST

CITMODST

CITMODST

MODST

CIT(MOD)(ST)

CIT(MOD)(ST)

ii. Modelarea mesajelor. Mesajele sunt ansambluri structurate de date, formate la interfaţa cu evenimentele declanşate în MOD. De ex. evenimentul contract client conţine odată mesajele: cif client, denumire, adresă şi data cererii, dar de mai multe ori tip credit, obiect credit, valoare credit, clauze credit, termen de recuperare.iii. Regulile de prelucrare (RP) exprimă algoritmii şi condiţiile utilizate în derularea sarcinilor din MOP. Ele sunt expresii aritmetice şi logice integrate într-o structură de calcul asociată unei sarcini, ca în tabelul de mai jos:

Structura RP Structurile de control utilizabile în RP

variabile: proprietăţile/atributele externe

bloc (secvenţial)

constante: proprietăţile/atributele cu valori fixe

alternativă

operatori aritmetici: =,<>,=>,=<, >,<

repetitivă

operastori relaţionali: SI, SAU, NU.

5.1.4. Modelarea logică (ML)a) Descrieri si definitii (se fac referiri la următoarele aspecte):Intocmirea dictionarului atributelor (un tabel de forma următoare)Nr. crt.

Denumire Identificator Tip, lungime

Conditii de validare

1 Numărul ordinului NR_ORDIN N,8 NR_ORDIN>0Observatie: la nr. crt. 1 tabelul de mai sus contine si un exemplu.b) Modelul logic de comunicatie (MLC)Precizări referitoare la reteaua de calculatoare (dacă este cazul): topologie, configuratie, soft utilizat, etc.c) Modelul logic de date (MLD) - Transformarea diagramelor entitate-relatie în relatii (vezi anexa 2, pag. 85) - Ordinea de prelucrare a bazei de date se poate reprezenta printr-un tabel având struc-tura de mai jos: Nr. crt. Den..rel

Ordinea de actualizare a BD1 2 3 4 5 6 7 8 9 1 7 2,3,4,5,6,9 5,8

1. CLIENTI 1 1unde cifrele de la intersectia unei relatii din prima coloană cu numărul altei relatii dispus pe orizontală în linia a doua, indică ponderile entitătii din prima coloană în raport cu celelalte entităti. Ponderea ia valoarea 1 dacă participarea entitătii din linia a doua în dependenta functională cu entitatea din coloana întâia este obligatorie si ia valoarea 0 dacă participarea entitătii din linia a doua în dependenta functională cu entitatea din coloana întâia este optională. În tabelul-exemplu de mai sus, la intersectia entitătii CLIENTI cu cea de a patra entitate, găsim 1, ceea ce înseamnă că unei realizări din entitatea 1 trebuie neapărat să-i corespundă o realizare în entitatea 4, dar unei realizări din entitatea 4 poate să nu-i corespundă nici o relizare în entitatea 1. Concret, în cazul în care coloana 4 s-ar referi la entitatea TRANZACTII, fraza precedentă trebuie înteleasă că o tranzactie nu trebuie neapărat să aibă un client, dar dacă în entitatea CLIENTI există o realizare, deci există un client, acela neapărat trebuie să se refere la o tranzactie.În continuare, se face suma pe linie si apoi se decide ordinea de prelucrare pentru entitătile care au cea mai mică sumă; astfel suma ponderilor pentru entitatea Clienti este 1. Fiind cea mai mică

din această coloană, o desemnează pe prima entitate ca făcând obiectul actualizării si pentru aceasta s-a conceput procedura P1. - ulterior entitătile care fac obiectul actualizării cu procedura P1 (ar fi putut fi si altele cu aceeasi sumă ca entitatea Clienti), se exclud din calculul sumei si se recalculează suma, urmând a se lua în calcul suma cea mai mică; se obtin astfel entitătile ce vor fi actualizate cu procedura P2 (în exemplul de mai sus intră entitatea 7).- se repetă pasul precedent până ce se stabileste ordinea de prelucrare pentru toate entitătile.

Coloanele rezultate în zona "Ordinea de actualizare a bazei de date", desemnează procedurile ce se disting pentru actualizarea bazei de date. Astfel în exemplul de mai sus, se distinge o procedură P1 care va actualiza entitatea 1, una P2 care va actualiza entitatea 7, P3 pentru entitătile 2, 3, 4, 5, 6 si 9 si P4 pentru entitătile 5 si 8. Exemplul este fictiv si nu trebuie căutată compatibilitatea solutiei.

In mod asemănător cu ordinea de actualizare a bazei de date, se mai stabileste si ordinea de obtinere a rapoartelor, care poate apare în tabelul de mai sus, ca o altă coloană în continuarea celei de actualizare a bazei de date. d) Modelul logic al prelucrărilor (MLP) - Structurarea sistemului, subsistemelor şi unităţilor funcţionale (valabil numai la sisteme informatice).Modelul logic de prelucrare are rolul de a preciza:

- frecventa de prelucrare;- actorii implicati;- fazele si sarcinile asociate acestora, inclusiv evenimentele si sincronizările aferente;- tipul fazelor: A (automate) si M (manuale).- Pentru aceasta se pleacă de la MCP. Mai exact operatiile complexe sunt transformate în

faze iar operatiile elementare sunt transformate în sarcini.- Modelul logic al prelucrărilor, un tabel cu structura: activitatea, faze, actiuni (sarcini), actor, frecventa (Z, d, l, etc.) si tipul activitătii (A – automat, sau M – manual). Astfel unei activităti A, pot să-i corespundă de ex. 4 faze (A1, A2, A3 si A4) . În acest tabel fiecare fază va ocupa un rând, dar fără a diviza prin linii orizontale si coloana atribuită activitătii A. Cu alte cuvinte coloana întâia continuă nedivizată până ce se trece la activitatea B, s.a.m.d. Pentru fiecare fază coloana Actiuni, poate cuprinde (una sub alta, cu linioară) mai multe actiuni.MLP-ul se poate reprezenta si grafic. Pentru aceasta se pleacă de la MOP folosindu-se în continuare simbolul grafic destinat reprezentării activitătilor, dar sarcinile nu mai apar una sub alta ci sunt deplasate pe orizontală, în dreptul actorului care trebuie să le execute.- În continuare, în documentatie vor fi incluse machetele documentelor de intrare, (dacă au fost reproiectate) organigrama unitătilor functionale (dacă au fost identificate mai multe unităti functionale), machetele formularelor şi rapoartelor, eventual a meniurilor (toate asamblate în aşa fel încât să se constituie în dialoguri şi interfete, specifice fiecărui actor din institutia beneficiară) precum si un tabel cu algoritmii folositi în diferite calcule.

5.1.5. Modelarea fizică (MF)a) Descrieri si definitii (se fac referiri la următoarele aspecte):- proiectarea strategiilor de prelucrare distribuită: modalitătile în care utilizatorul poate să dispună de date si facilităti de prelucrare distribuite în retea. În detaliu aceste modalităti vor fi prezentate în MFC

- proiectarea fisierelor fizice si a bazelor de date: aceasta vizează descrierea modului în care datele vor fi stocate si accesate în/din memoriile secundare si cum se va asigura controlul lor pentru a se oferi o securitate maximă. Concret solutia va fi dezvoltată la punctul c (MFD).- proiectarea structurii sistemului si a programelor: sunt descrise programele si modulele acestora urmărindu-se ca ele să fie în concordantă cu diagramele fluxurilor de date sau cu MLP (depinde de metoda de abordare a sistemelor informationale folosită) si cu celelalte piese ale documentatiei realizate în etapele anterioare;În legătură cu proiectarea fizică trebuie avut în vedere că dacă în fazele precedente s-au căutat răspunsuri la întrebarea "Ce trebuie să facem?" acum trebuie să răspundem la întrebarea "Cum vom face ce ne-am propus în etapele anterioare?". Fiind ultima fază înainte de implementare, proiectarea fizică este ultima sansă de punere de acord a solutiilor noastre cu cerintele utilizatorului dar si cu realitatea în care va functiona sistemul.b) Modelul fizic de comunicatie (MFC)Generarea concretă a unui model fizic de comunicatie (MFC) presupune realizarea în principiu a următoarelor elemente specifice:

- interconectarea topologiilor de tip LAN specificate în MLC;- securitatea LAN:

- servicii de securitate:- controlul accesului- autentificarea- confidentialitatea datelor- integritatea datelor- nonrepudierea.

- mecanisme de securitate:- criptarea;- semnătura digitală;- controlul acordului;- integritatea datelor;- integritatea unui câmp sau a unei entităti de date;- integritatea unor câmpuri sau a unor siruri de unităti de date;- schimburi de autentificare;- controlul dirijării: selectia fizică a căilor alternative;- notarea: asigură faptul că proprietătile datelor communicate între două sau mai

multe entităti sunt autentice sub aspectul integritătii, originii, timpului si destinatiei.

c) Modelul fizic de date (MFD) are rolul de a evidentia următoarele elemente:- specificatorul asociat relatiei la nivel fizic (denumire tabel/relatie în viziunea

beneficiarului si denumire tabel ca fisier, de ex. C:\SICSV\valute dbf);- structura înregistrării; - accesul si spatiul fizic specific relatiei;- constrângerile structurale referentiale interrelatii;

Tabelul următor este un exemplu de descriere a relatiei “VALUTE”:

MFD1. ENTITATEA Relatia fizicăValute C:\Exchange\valute.dbf2. ACCESUL SI SPATIUL FIZIC

Indexare Spatiul fizic ocupatchei Fisier index RCS R Total octetiCPCS

COD_V-

Valute.ndx-

18 1000

3. CONSTRÂNGERI STRUCTURALE REFERENTIALE INTERRELATIIidentificator relatie CP CETRANZ Nr_bsv Cod_vMISC Nr_doc Cod_v4. STRUCTURA ÎNREGISTRÃRIINr. Identificator Tip, lungime Conditii de validare1234

COD_VCURS_CUMPCURS_VPROC_C

C,3N,3N,4N,6,2

COD_V={ATS,AUD,BEF,…,USD, ROL}CURS_CUMP>=30000 AND CURS_CUMP=<9(5)CURS_V>=30000 AND CURS_V=<9(5)PROC_C>=0.01 AND PROC_C=<0.30

Se va întocmi câte un tabel ca cel de mai sus, pentru fiecare entitate.Videoformatele de I/E:

- se întocmeste o listă cu videoformatele (formularele) după modelul următor:Videoformatul Descriere Figura

Tip Denumire IdentificatorI Buletin de cumpărare BC Asigură introducerea datelor

aferente cumpărărilor de valută

19

- se include macheta fiecărui formular specificat în tabelul de mai sus.Meniuri de prelucrareSe face precizarea că meniul principal de prelucrare pentru aplicatia … este format din următoarele optiuni si suboptiuni descrise în ordinea utilizării acestora: (urmează un tabel cu structura celui de mai jos, exemplificat pe începutul tabelului specific unei case de schimb valutar):

Optiunea Suboptiunea Nivel Descriere FiguraPSV - 1 Crearea, schimbarea si eliminarea PSV 1

PSV schimbare 2 Schimbarea PSV activ 2PSV creare 2 Crearea unui PSV nou 3PSV eliminare 2 Stergerea unui PSV 4

CONFIGURARE - 1 Parametrizarea sistemului 5Generală 2 Particularizarea PSV: exercitiu financiar,

parametrizarea PSV, procentul de variatie între cursul de vânzare si cel de cumpărare, precum si conturile folosite: 5311 – casa în lei;708 – comision cumpărare;708 – comision vânzare;704 – diferente pret cumpărare/vânzare

Utilizatori 2 Definirea utilizatorilor si a drepturilor de accesImprimanta 2 Parametrizarea nmelui si tipului de imprimantă

Lungimea si lătimea hârtiei folositeCulori 2 Parametrizarea culorilor pentru ecran si date

Semnal sonor Stabilirea frecventei si duratei semnalului sonorFisiere - 1 Descrierea atributelor bazei de date

Devize 2 Declararea devizelor (valutelor): cod, denumire, contul Casa în valută 5314, precum si: data cursu-lui, cursul BNR, curs cumpărare, curs vânzare, etc.

Tabelul continuă, dar cele prezentate mai sus sunt suficiente pentru a reflecta spiritul în care se elaborează macheta meniului. În continuare în documentatie vor fi incluse machetele submeniurilor ce apar la alegerea unei optiuni de meniu si dacă este cazul se coboară în jos pe arborele meniului până la ultimul nivel

d) Modelul fizic al prelucrărilor (MFP) are rolul de a ilustra identificatorii procedurilor, sche-mele de sistem, intrările, iesirile si functiile asociate acestora. Pentru aceasta se întocmeste un tabel ca cel de mai jos:

Identificator Schema de sistem I/E FunctiiSe trece numele programului sau modulului.De exemplu:SICSV.prg

BMESI BMEAE BMEL BMETPSV BMETB CON: BMIAI BMITPSV BMITB C:\SICSV BC, BV SICSV

C:\SICSV

BC.lbxBV.lbxBMITB.lbxBMITPSV.lbxBMIAI.lbxBMETB.lbxBMETPSV.lbxBMEAE.lbxBMESI.lbx

CON:vdfi, vdfe

C:\SICSV.prg

C:\SICSV\CLIENTI.dbfC:\SICSV\ CLIENTI.ntxC:\SICSV\VALUTE.dbfC:\SICSV\VALUTE.ntxC:\SICSV\TRANZ dbfC:\SICSV\TRANZ.ntxC:\SICSV\MISC.dbfC:\SICSV\MISC.ntx

Introducere si validaretranzactii valutare.

ListareaIesirilorSICSV

ConfigurareBD

În continuare se mai specifică:- ordinea de apelare a optiunilor meniului principal ca în exemplul următor.

4 PSV

5 CONFIGURARE

1 FISIERE/BD

2 BULETINE

3 LISTARI

8 REVENIRE DOS

- configuratia minimă a calculatorului pe care urmează a se instala aplicatia;

LPT1:

JCV, JVV,RS, BC,BV, RBNR,TM

JCV.frxJVV.frxRS.frxBC.frxBV.frxRBNR.frxRM.frx

UTILITARE

7 INTRETINERE

- comenzi prin care se face instalarea si comenzi de lansare a aplicatiei în exploatare. Dacă sunt necesare anumite comenzi ce trebuie să fie prevăzute în fisiere CONFIG.SYS, se vor specifica si acelea.

5.2. Metodologia orientată obiect1. IntroducereSistemele informatice, ca şi subsistemele şi aplicaţiile care le compun, se concretizează în final, atunci când sunt distribuite utilizatorilor, în nişte produse program. Acestea au un pronunţat caracter abstract şi în ciuda faptului că atunci când sunt puse în funcţiune îi permit utilizatorului să recunoască multe aspecte din practica derulării manuale a aplicaţiei sau sistemului, în calculator ele există sub forme total diferite de ceea ce îşi închipuie utilizatorul. Avem în vedere tabelele, interogările, rapoartele, formularele, modulele program, macrourile, meniurile, etc. care sunt de fapt nişte fişiere; dacă nu ele sunt fisiere, măcar baza de date în care sunt constituite este reprezentată printr-un fişier (acest lucru depinde de SGBD-ul folosit). Rezultă foarte clar de aici că analistul programator trebuie să vadă activitatea de informatizat prin două prisme total diferite: cea a utilizatorului, care ştie cum funcţionează aplicaţia în practică şi cea a programatorului, care ştie cu ce noţiuni poate opera în programare. Se ştie că activităţile desfăşurate de analistul programator de la analiza domeniului de activitate ce trebuie informatizat şi până la darea în funcţiune a produsului program se pot constitui într-un proces, aşa numitul proces software. Acest proces are o etapizare (mai modern – un ciclu de viaţă) care depinde de metoda de abordare aleasă de analist.Mai cunoscută este abordarea funcţională, abordarea orientată spre proces, abordarea orientată spre date, apoi cea spre evenimente şi orientarea pe obiecte.Atunci când pentru realizarea produsului program folosim un mediu de programare bazat pe obiecte, cum este cazul Access sau Visual FoxPro, orientarea pe obiecte (OO), are un mare avantaj şi anume acela că obiectele pot fi folosite atât în modelarea activităţilor umane cât şi în realizarea produsului program. Cu alte cuvinte în modelarea pe obiecte nu mai există acea conversie, adeseori foarte dificilă, de la modelul extern la modelul conceptual, de la modelul conceptual la cel logic şi în final de la modelul logic la cel fizic. Întrebarea care se pune în continuare este cum am putea aborda orientat pe obiecte un sistem sau o aplicaţie informatică?Răspunsul ar putea începe de la faptul că trebuie să dispunem de un SGBD bazat pe obiecte şi ulterior să căutăm să aplicăm filozofia care a stat la baza programării acelui SGBD şi în analiza domeniului de activitate pe care vrem să-l trecem pe calculator. Cum aceste SGBD au fost realizate prin programare orientată pe obiecte _ POO, aceasta presupune să ştim cum se abordează realitatea în cadrul POO. Iată deci motivul care a inspirat tema acestui curs.În POO lumea reală este de la început percepută prin prisma obiectelor deşi nu este deloc lipsit de importanţă să precizăm că pe timpul modelării şi apoi a proiectării există şi aici o oarecare nuanţare a obiectelor, deci o oarecare evoluţie a lor, dar aceasta este mai uşor de suportat de analistul programator decât în cazul celorlalte metode de abordare. POO mai are un mare avantaj: acesta se manifestă în programare şi constă în faptul că multe entităţi din lumea reală, în ciuda faptului că sunt foarte diferite ca înţeles şi substanţă, în calculator pot fi modelate cu acelaşi tip de obiect (sau clasă de obiecte). Această constatare face posibilă o mare economie de timp şi de efort pentru realizarea produsului soft - lucru ce poate fi înţeles dacă vom analiza îndeaproape modul concret de programare în POO.Deocamdată ne mulţumim să precizăm că în POO un obiect modelează o entitate din lumea reală sau imaginară. Identificarea obiectelor şi a comportamentului lor constituie obiectivele principale ale analizei şi proiectării orientate spre obiecte. În prima etapă obiectele sunt lucruri reale având o delimitare clară. Fiecare obiect este unic. Fiecare obiect posedă propriul lui set de caracteristici

unice. Respectând aceste aspecte, este uşor în etapa doua, să-i asociem fiecărui obiect real, un obiect abstract, adică un obiect software şi să trecem în lumea proiectului fizic.Trebuie spus că deşi studiul obiectelor se pierde în negura timpului spre Platon şi Aristotel, odată cu apariţia orientării spre obiecte în programare, ideea s-a dovedit foarte atractivă şi pentru alte domenii de activitate astfel că a apărut o paradigmă a orientării spre obiecte. Conform acestei paradigme obiectul (obiectul software) este o entitate abstractă care execută anumite acţiuni la cerere. El este caracterizat de o stare, de un comportament bine definit si de identitate.Exemple de obiecte:- în cazul interfeţelor de programare a aplicaţiilor: o resursă a sistemului de operare, materializată printr-o structură internă a acestuia cum ar fi: fir, fişier, pictogramă, cursor, sau orice unitate de informaţie la care un subiect doreşte acces;- în cazul reţelelor: o resursă care nu conţine alte resurse, de ex. conectarea la obiect;- în cazul mecanismelor de tip OLE: orice poate fi ataşat sau mânuit de o aplicaţie: text, tabel, imagine grafică, sunet, videoclip, etc.Softul în concepţia OO este o colecţie de obiecte care au structuri de date şi comportări. Pentru a proiecta şi implementa soft orientat spre obiecte trebuie cunoscută metoda de abordare specifică acestei paradigme şi bineînţeles un limbaj de programare adecvat. Cele mai populare limbaje orientate spre obiecte sunt Smalltalk şi C++, la care se pot adăuga limbajele specifice bazelor de date relaţionale. Cu aceste limbaje se crează clase (de obiecte), iar obiectele reprezintă concretizarea unei clase. O clasă se poate concretiza (instanţia) în mai multe obiecte. În afară de "orientare-obiect" mai există sintagma “bazat pe obiecte”. Programarea care se face în cadrul SGBD Access sau Visual FoxPro, de către analistul programator care nu a abordat sistemul prin orientare pe obiecte este bazată pe obiecte. Adică analiza şi modelarea se face prin metode clasice iar generarea produsului program se face cu ajutorul unor medii de programare în care există definite clase şi programatorul doar le instanţează, adică le “dă fiinţă”. Astfel de clase există în mediile de programare bazate pe obiect sub forma tabelelor, interogărilor, formularelor, rapoartelor, DAO s.a.m.d. Prin analogie, putem spune că la o fabrică de automobile clasa este marca şi modelul automobilului, materializată prin proiectul automobilului, tehnologia de fabricaţie şi linia tehnologică de producţie a acelui automobil. Dacă în acel moment se construieşte automobilul cu seria X, acela este o instanţă a (clasei) automobilului pe care-l produce acea fabrică. Programatorul care crează obiecte în cadrul mediului de programare Access nu crează clase ci instanţează nişte clase, adică pe baza claselor disponibile în biblioteca acestui mediu de programare, crează nişte obiecte. Spre deosebire de Access, în visual FoxPro programatorul poate să şi creeze clase. şi în Access se poate face ceva în materie de obiecte şi anume se pot crea proprietăţi ale unor obiecte existente, dar nu se pot crea clase noi.

2. Fundamentele orientării spre obiecteIdentitatea este unicul cod care permite distingerea unui obiect faţă de altul. Aceasta este implementată software ca un identificator (ID) de tip read_only. Starea reprezintă setul de date care conţin informaţii cu privire la obiect. Starea se materializează în memorie prin structura esenţială a obiectului şi valorile sale curente. Un exemplu simplu de clasă de obiecte ar fi punctul în 2D, a cărei structură se materializează prin locul rezervat pentru valoarea ordonatei şi abscisei. Dacă în cadrul acestei clase am declarat punctul A acesta devine o instanţă a clasei punct în 2D. Dacă am mai declarat un punct B, acesta este o altă instanţă a clasei punct în 2D. Când datele privitoare la un punct, în cazul de faţă coordonatele lui, sunt completate cu valori, de exemplu completăm pentru punctul A abscisa egală cu 2 şi ordonata egală cu 3,

atunci obiectul A a căpătat o stare. Nu este nici o problemă dacă la un moment dat punctul A se suprapune cu B, adică dacă şi B ar avea aceeaşi stare cu A. Cu alte cuvinte când două obiecte au aceeşi stare, ele nu se dezintegreaza ci îşi păstrează identitatea, (contiună să existe ca obiecte separate) şi oricând îşi pot schimba starea în direcţii diferite. Comportamentul unui obiect corespunde serviciilor pe care acesta le oferă clienţilor săi. Comportamentul este concretizat prin modul în care obiectul reacţionează la evenimentele cauzate de sursele externe şi prin modul în care interacţionează cu alte obiecte. Determinarea comportamentului unui obiect depinde în mod hotărâtor de contextul în care se desfăşoară scenariul. Astfel dacă într-un mediu de grafică vectorială vom înzestra punctul numai cu proprietatea de a urma mouse-ul pentru a modifica forma unei curbe şi cu proprietatea de a ţine aproape de punctul care este tras cu mouse-ul (în cazul în care nu el este cel tras cu mouse-ul), într-un mediu destinat proiectării la scară cum este CAD, punctul va oferi mai multe servicii cum ar fi: aflarea distanţei dintre două puncte, returnarea coordonatelor sale, furnizarea reprezentării polare a poziţiei sale, etc. Comportamentul este corespunzător mesajelor pe care clientul i le transmite obiectului. Termenul client este legat de clasă.O clasă este o implementare, adică o definire de obiecte, care poate fi instanţiată în vederea creării de multiple obiecte având acelaşi comportament. Un obiect este o instanţă a unei clase. Există clase server, care oferă serviciile sale altor clase şi clase client, care utilizează serviciile altor clase. Astfel un obiect din clasa punct îşi poate oferi serviciile sale unui obiect din clasa segment. De exemplu punctul participă la calculul lungimii segmentului în care el este implicat. Clasa punct este în acest fel clasă server faţă de clasa segment, care este o clasă client. Să remarcăm că o clasă poate juca rolul de client pentru o clasă, dar în acelasi timp, poate constitui clasă server pentru o altă clasă. De exemplu clasa segment ar putea fi clasă server pentru un poligon căruia dorim să-i calculăm perimetrul.Definim interfaţa unei clase ca fiind implementarea întregului său comportament. Interfaţa corespunde metodelor care pot fi utilizate de un client al clasei. Mesajele clientului constă de fapt în apelarea de metode ale clasei server. Interfaţa unei clase poate conţine elemente publice şi/sau elemente private.Încapsularea şi ascunderea informaţieiStarea obiectului este o caracteristică statică, în timp ce comportamentul este o caracteristică dinamică. Ca să folosească un obiect, clientul trebuie să ştie cum să apeleze metodele acestuia, dar nu are nevoie să ştie şi starea obiectului. De aceea stările obiectelor nu sunt accesibile utilizatorilor, adică sunt încapsulate.Incapsularea este importantă pentru că permite producătorilor de soft să-şipăstreze secretul structurii programelor pe care le produc. Încapsularea se poate extinde şi asupra modulelor, sistemelor, interfeţelor. În acest caz avem de aface cu ascunderea informaţiei.

Mesaje şi metode Comportamentul unui obiect corespunde cu setul de mesaje care-i pot fi transmise. Obiectele comunică prin intermediul acestor mesaje. Metodele sunt segmente de cod (scris într-un limbaj de programare orientat spre obiecte) care implementează mesajele. Cu alte cuvinte fiecărui mesaj trebuie să-i corespundă o metodă. Metodele au acces la starea obiectului, atât cât este strict

necesar ca să-şi ducă misiunea la bun sfârşit. După influienţa lor asupra stării obiectului, metodele se împart în:- Constructori (metode care generează o nouă instanţă a unei clase date);- Destructori (metode care elimină din memorie un obiect aparţinând clasei la care se referă

distructorul);- Selectori (metode care invocă obiecte, dar nu modifică starea lor);- Modificatori (acestea modifică starea obiectului)Instanţa clasei şi proprietăţile claseiDin cele prezentate mai sus în legătură cu starea obiectelor şi a claselor putem deduce că starea unui obiect este echivalentă cu atributele sale şi cu valorile acestora. În cazul clasei aceste atribute pot fi de două tipuri: de instanţiere şi atribute de clasă.Este clar că atributele de instanţiere trebuie să definească identitatea unui obiect din clasa respectivă şi aceste atribute trebuie să aibă valori specifice unui obiect. De exemplu clasa Sportivi va trebui pentru a genera un sportiv, să ne permită să-i precizăm numele sau codul_personal, în timp ce atributele de clasă trebuie să reliefeze ceea ce este caracteristic clasei. De exemplu disciplina sportivă practicată. O metodă de instanţiere este aplicată unui singur obiect. Orice clasă trebuie să dispună de o metodă de instanţiere ( cum ar fi constructorul) şi trebuie să accepte un mesaj prin care i se cere să aplice metoda ei de instanţiere.Categorii de obiectePe timpul perioadei de analiză este bine să putem identifica categoria de obiecte ce se pretează a fi folosită pentru a modela diferite tipuri de entităţi şi concepte. În acest scop se folosesc următoarele categorii de obiecte:- tangibile (apar sub forma substantivelor din lumea reală: pompă, maşină, carte);- incidente (sau evenimente: accidente, plăţi, zboruri, clic, apariţii, etc);- interacţiuni (seamănă cu relaţiile din diagramele entitate_relaţie: rezervarea biletelor,

înscrieri, operaţii medicale, etc).;- specificaţii (metadate sau date ce descriu date: model de maşină, catalog, etc.);- intangibile (se referă la entităţi conceptuale: intersecţii, conturi, poziţii, etc.);- roluri (modelează organizările de personal: client, cititor, angajat, pacient, etc.);Pentru a uşura generarea claselor se folosesc aşa numitele tipuri abstracte de date sau TADAcestea conţin o încapsulare de date şi operaţiile asupra acestora. Unele limbaje ca Modula-2 şi Ada implemntează TAD-uri în timp ce Simula, Eiffel şi C++ se bazează pe implementarea de TAD_uri. Un TAD constă din două părţi: specificarea sintactică şi setul de axiome.Specificarea sintactică conţine informaţii despre nume, domenii şi spaţii ale valorilor ataşate tipului , în timp ce axiomele definesc sensul operaţiilor prin enunţarea relaţiilor dintre ele.

Specializarea, generalizarea şi moştenireaAcestea sunt concepte intercorelate des utilizate în dezvoltările de soft orientate spre obiecte .Specializarea şi generalizareaSpecializarea ne permite să derivăm clase care preiau toate proprietăţile unei clase date (clasă de bază) , dar care mai conţin şi stări şi operaţii specifice. Între clasa de origine şi specializarea ei (subclasa sau clasa derivată) apare o relaţie de moştenire. Pentru a specifica această moştenire (faptul că specializarea conţine toate proprietăţile clasei din care derivă) se foloseşte cuvântul

ESTE. Astfel pentru a specifica faptul că un cititor este un fel de persoană, vom spune că “un cititor ESTE o persoană”. Analog putem spune că:Un delfin ESTE un mamifer;Un proiect intern ESTE un proiect;Un triunghi ESTE un poligon, s.a.m.d.Generalizarea este opusă specializării: adică dacă B este o specializare a lui A, atunci A este o generalizare a lui B. În ce priveşte moştenirea, există două forme de moştenire: moştenirea simplă – când o clasă are o singură clasă de bază şi moştenirea multiplă - când o clasă poate avea două sau mai multe clase de bază. În 95% dintre cazuri moştenirea multiplă, deşi există, nu este necesară şi trebuie evitată pentru că ne complică programele.Agregarea apare atunci când un obiect conţine în structura sa mai multe obiecte componente. De exemplu un poligon presupune o listă de puncte, data calendaristică presupune specificarea zi, lună, an, s.a.m.d. Aşa cum relaţia de moştenire se poate reprezenta prin cuvântul ESTE, relaţia de agregare se poate reprezenta prin expresia PARTE A.Există agregate fixe (cu structură fixă cum este data), agregate variabile (de ex. stivă, liste, cozi, etc.) şi agregate recursive (când starea unui agregat poate conţine componente de acelaşi tip: de exemplu clasa articoleleor publicate într-o revistă cu articolele din alte reviste la care se face referire în articolele primei reviste.Expresia PARTE A poate însemna după caz: componentă_întreg, material_obiect, porţiune_obiect, loc_arie, membru_mulţime, membru_parteneriat.PolimorfismPolimorfismul în general înseamnă mai multe forme sub care se poate prezenta ceva plecând dela aceeşi structură (cazul cristalelor polimorfe), dar în informatică înseamnă că obiecte diferite pot înţelege în felul lor aceeaşi informaţie. De exemplu Design mode va duce la lansarea ferestrei de declarare a câmpurilor unui tabel, dar în cazul interogarii va duce la deschiderea grilei, în cazul formularelor la deschiderea ferestrei cu benzi, ş.a.m.d.În programare, polimorfismul trebuie nuanţat cu şi mai multă grijă. Astfel există polimorfism parametric (de exemplu o funcţie – în sensul de subprogram - poate fi aplicată uniform unui spectru de tipuri; astfel funcţia LEN poate calcula dimensiunea pentru o listă de elemente de un tip arbitrar), polimorfism de incluziune, polimorfism ad-hoc, polimorfism universal. Polimorfismul ad-hoc se poate întâlni sub forma redefinirii şi sub forma coerciţiei (de exemplu o funcţie aşteaptă un argument de tip Double şi primeşte unul de tip Integer. Dacă funcţia stie să convertească automat argumentul de tip Integer în Double, ea dă dovadă de polimorfism ad-hoc).

3. Procesul software orientat spre obiecte. Există mai multe metodologii de dezvoltare soft orientate spre obiect. Mai răspândită este OMT (Object Modeling Technique) şi RUP (Rational Unified Process) bazat pe UML (Unified Modeling Language).

3.1. Ciclul de dezvoltare orientat spre obiecte bazat pe metodologia OMT cuprinde etapele:- Determinarea cerinţelor. Pentru determinarea cerinţelor se folosesc tehnicile:

- identificarea (transpunerea) conceptelor;- lista eveniment-răspuns şi rezumatele;- modelarea cazurilor de utilizare;

- Analiza. Se folosesc trei modele diferite:- modelul obiectelor presupune:

- identificarea claselor de obiecte;- identificarea relaţiilor (asocieri) dintre clase;- descoperirea relaţiilor de generalizare;- crearea unui dicţionar de date.

- modelul dinamic presupune:- interacţiuni temporare dintre obiecte;- stimularea obiectelor şi răspunsurile acestora;- traducerea evenimentelor în operaţiile obiect.

- modelul funcţional presupune:- dependenţe funcţionale ale valorilor;- calculul obiectelor;- fiecare proces este implementat de către o metodă a unui singur obiect.

- Proiectarea având ca obiective- proiectarea sistemului care presupune:

- determinarea subsistemelor şi a secţiunilor;- alegerea unităţilor funcţionale pentru implementarea subsistemelor;- alegerea şi manevrarea depozitelor de date;- determinarea arhitecturii sistemului;- probleme de concurenţă şi control;- decizia de negociere.

- proiectarea obiectelor care presupune:- expandarea modelului obiectelor;- proiectarea algoritmilor de implementare a operaţiilor;- clase interne;- proiectarea asocierilor;- descoperirea rolurilor;- proiectarea orientată de date şi responsabilităţi;- rafinarea ierarhiilor de clasă;- stabilirea atributelor; - proiectarea obiectelor pentru probleme de management.

- Implementarea. Pentru implementare există patru alternative:- Implementare hardware;- Implementare într-un limbaj neorientat spre obiecte;- Implementare într-un limbaj orientat spre obiecte (C++, Smalltalk, Eiffel, Ada);- Implementare utilizând un sistem relaţional de baze de date.

În cazul implementării are loc:- construirea sistemului (scrierea programelor, testarea programelor, întocmirea

documentaţiei aferente) ;- punerea în funcţiune a noului sistem (asigurarea condiţiilor de implementare,

executarea procedurilor de conversie, punerea în funcţiune a sistemului, verificarea performanţelor sistemului informatic proiectat, definitivarea documentaţiei acestuia şi omologarea sau recepţia lui).

3.2. Ciclul de dezvoltare orientat spre obiecte bazat pe metodologia RUP conţine etapele:

- modelarea activităţii;

- cerinţe;- analiză şi proiectare;- implementare;- testare;- dezvoltare;- managementul schimbării;- managementul proiectului;- mediul.

Se pleacă de la premiza că parcurgerea acestui flow se va face iterativ de mai multe ori şi din puncte diferite. De asemeni se mai presupune că în cadrul fiecărei etape se pot parcurge patru faze: iniţiere, elaborare, construcţie şi tranziţie.Ca urmare fazele şi procesele de parcurs atunci când folosim un process de tip RUP se reprezintă mai uşor sub forma unei matrici conţinând pe verticală procesele iar pe orizontală cele patru faze pe care le poate parcurge oricare din cele 9 procese. Primele 6 procese sunt grupate sub numele de nucleu sau procese de lucru, iar ultimele 6 constituie suportul sau procese suport. La intersecţia unui proces cu fiecare din fazele prin care ar putea trece se marchează cu linie curbă situată mai sus sau mai jos faţă de axa rândului respectiv, ponderea fazei în cadrul procesului respectiv ca în rândul Analiză şi proiectare din tabelul de mai jos (dacă în cadrul unei intersecţii/casete sunt mai multe iteraţii linia se va diviza corespunzător):

FAZEProcese de lucru

Iniţiere Elaborare Construcţie Tranziţie

Modelare afacereCerinţeAnaliză şi proiectareImplementareTestareDezvoltareProcese suportManagementul schimbăriiManagementul proiectuluiMediul

Iniţial Elab#1 Elab#2 Con1 Con3 Con3 Tran#1 Tran#2Iteraţii

In metodologia RUP conţinutul etapelor este materializat prin alti paşi decât în metodologia OMT. Conţinutul etapelor în metodologia RUP este următoarea: Definirea cerinţelor:

Identificarea actorilor;- Cine este interesat de sistem?- Cine furnizează date sistemului?

- Cine beneficiază de funcţionarea sistemului?- Cine va administra şi întreţine sistemul?- Există persoane care îndeplinesc mai multe roluri diferite sau grupuri de

persoane care îndeplinesc acelaşi rol?- În ce compartimente sau structuri ale organizaţiei este utilizat sistemul?- Sistemul utilizează resurse externe?- Este necesară interacţiunea cu alte sisteme informatice în funcţiune?

Identificarea cazurilor de utilizare;- Care este sarcina principală a fiecărui actor?- Care sunt cazurile de utilizare care asigură actualizarea datelor din sistem?- Care sunt actorii care pot introduce, modifica sau şterge date din sistem?- Actorul/actorii trebuie să informeze sistemul despre modificările produse în

exteriorul acestuia?- Există actori care trebuie informaţi despre evoluţiile apărute în sistem?- Care este cazul de utilizare prin care se administrează şi se întreţine sistemul?- Cazurile de utilizare identificate răspund tuturor cerinţelor funcţionale?

Descrierea cazurilor de utilizare se bazează pe modelarea cazurilor de utilizare. Pentru fiecare caz de utilizare identificat se va face uz de diagramele puse la dispoziţie de UML (care este un limbaj de modelare obiectuală şi nu o metodă de proiectare orientată obiect);

- Diagrama cazurilor de utilizare şi se va ţine cont de:- Relaţiile dintre cazurile de utilizare;- Relaţiile dintre actori pentru a încheia cu:- Descrierea cazurilor de utilizare;- Realizarea cazurilor de utilizare.Descrierea trebuie să prezinte toate variantele posibile de înlănţuire a evenimentelor ce pot avea loc în cadrul fiecărui caz de utilizare. Prin eveniment facem referire la ceea ce face sistemul ca răspuns la o acţiune a actorului. Din descriere trebuie să rezulte scenariile de derulare a cazului de utilizare.

Definitivarea modelului cazurilor de utilizareAcest pas include revenirile şi corecţiile necesare referitoare la actorii şi cazurile de utilizare definite iniţial, ca urmare a completării şi aprofundării informaţiilor obţinute după parcurgerea celor trei paşi anteriori. Deoarece actorii sunt exteriori sistemului iar cazurile de utilizare fac parte din sistem în acest moment se poate trasa graniţa care delimitează sistemul.

În completarea celor de mai sus, este foarte utilă în acest moment descrierea interfeţei cu utilizatorii, specificând în acelaşi timp, datele ce vor fi comunicate şi logica de funcţionare. Se mai pot întocmi glosare de termeni care vor fi actualizate pe tot parcursul celorlalte etape.

Analiza se desfăşoară prin intermediul paşilor următori: Identificarea obiectelor şi claselor;

- Identificarea claselor entitate;- Identificarea claselor de prezentare şi control.

Generarea de realizări ale cazurilor de utilizare. O realizare a unui caz de utilizare desemnează funcţionarea acestuia conform unuia dintre fluxurile de evenimente (scenarii) identificate anterior. Interacţiunea se reprezintă prin diagrame de secvenţă şi diagrame de colaborare puse la dispoziţie de UML. Cu această ocazie sunt puse în evidenţă clasele de

obiecte participante, relaţiile (asocieri sau agregări) şi operaţiile pe care trebuie să le ofere fiecare clasă corespunzător mesajelor figurate în diagramele de secvenţă şi de colaborare;

Identificarea asocierilor şi agregărilor. Nu există reţete pentru găsirea asocierilor şi agregărilor dar următoarele reguli ne pot fi de folos:

- Toate clasele trebuie să participe la cel puţin o asociere sau agregare; nu pot exista clase total izolate în modelul de analiză;

- Există întotdeauna cel puţin o legătură între clasa de prezentare şi clasa de control a cazului de utilizare;

- Clasele care interacţionează trebuie să poată fi puse în legătură prin asocieri sau agregări directe sau indirecte;

- Asocierile derivabile (deci şi cele tranzitive) trebuie identificate şi eliminate;- Este recomandabilă înlocuirea asocierilor ternare cu mai multe asocieri binare.

Definirea atributelor claselor (identificarea atributelor şi operaţiilor) cu accent pe atributele prin care se face legătura între obiecte. Atributele specifice implementării trebuie evitate în această fază.

- Definitivarea se bazează pe enunţul problemei, descrierea cerinţelor, fluxurile de evenimente ale cazurilor de utilizare şi pe expertiza în domeniu.

Identificarea relaţiilor de moştenire. Se va folosi numai dacă s-au folosit relaţii de specializare între clase. Odată cu creşterea numărului de clase identificate este recomandabilă regruparea lor în unităţi mai mari – adică în pachete. În UML pachetele sunt definite ca un decupaj structural. Utilizarea pachetelor necesită stabilirea relaţiilor între pachete.

Definitivarea modelului analizei. Acest pas presupune revederea, şi dacă este cazul, modificarea soluţiilor iniţiale (în special clasele propuse în sistem)

Proiectarea urmăreşte completarea elementelor definite în cursul analizei cu toate detaliile necesare trecerii la implementare ceea ce presupune următoarele:

- Adăugarea de noi clase, necesare pentru asigurarea persistenţei, pentru realiza-rea efectivă a interfeţelor, pentru asigurarea comunicaţiei cu alte sisteme;

- Revederea şi definitivarea, până la nivelul necesar de detaliere, a claselor, atributelor, operaţiilor, relaţiilor definite în cursul analizei; sensul de urmat este acela de amplificare deoarece noile clase şi structuri menţionate anterior, vor cere completări şi adaptări şi pe acest nivel;

- Extinderea şi completarea laturii logice a arhitecturii, impreună cu crearea şi/sau definitivarea celorlalte laturi: de implementare, de distribuire şi de exploatare.

Principalii factori de influenţă sunt limbajul de programare, mediul de dezvoltare stilul de arhitectură, tehnologiile informaţionale avute în vedere (inclusiv cele prin care se asigură persistenţa), configuraţia şi caracteristicile echipamentelor şi mijloacelor de comunicaţie.

Proiectarea se realizează prin paşii următori: Proiectarea claselor. În afară de diagramele de clase, de cazuri de utilizare, de

secvenţe, de colaborări, va apare apare structurarea în subsisteme şi modelul de amplasare. Clasele de obiecte de pe nivelul proiectare se vor numi clase de proiectare spre deosebire de cele din etapa anterioară numite clase de analiză.

Identificarea claselor. Clasele de proiectare reprezintă soluţia de implementare a claselor de analiză . În identificarea lor se va ţine seamă de următoarele orientări generale:

- Claselor de prezentare din analiză le vor corespunde clasele de interfaţă cu utilizatorii necesare realizării lor;

- Claselor entitate le vor corespunde clase de gestiune, clase de persistenţă şi în unele cazuri, clase de reprezentare a asocierilor;

- Clasele de control nu vor avea, ca regulă generală, un echivalent în clasele de proiectare, responsabilităţile acestora fiind distribuite celorlate clase de proiectare, în conformitate cu comportamentul descris de diagramele de secvenţe şi de colaborare. Schimbările intervenite în clasele de proiectare în raport cu clasele de analiză impun reevaluarea tuturor celorlalte elemente: relaţii, atribute, operaţii. În plus, definirea lor trebuie făcută acum pe nivelul de detaliere cerut de programare.

Asocierile şi agregările. Indiferent de noua configurare a legăturilor, conservarea funcţionalităţilor definite în cursul analizei este obligatorie. Pentru identificarea sau re(verificarea) asocierilor se vor avea în vedere:

- Clasele de proiectare corespunzătoare claselor entitate din analiză, legăturile dintre acestea din urmă, care sunt determinate de logica problemei sau a domeniului analizat, trebuie să fie păstrate fără omisiuni sau deformări, şi în urma proiectării;

- Schimbul de mesaje între două obiecte menţionat într-o diagramă de interacţiune, trebuie să fie susţinut de prezenţa unei asocieri, directe sau indirecte , între clasele corespunzătoare; dacă aceasta nu există se vor face completările necesare;

- Dacă o clasă foloseşte o interfaţă definită de o altă clasă, atunci între acestea trebuie să existe o asociere.

Atributele urmează a fi definite acum cu toate caracteristicile: vizibilitate, nume, tip, lungime, în termenii limbajului de programare folosit. Memorarea obiectelor între două execuţii diferite poate solicita clase persistenţă cu atribute proprii, distincte de cele ale obiectelor de gestiune.

Operaţiile suportă acelaşi proces de reidentificare şi redefinire. Se vor introduce noi operaţii cum ar fi:

- operaţii ce răspund funcţionalităţilor stabilite în cadrul analizei;

- operaţii ce preiau responsabilităţile asumate de clasele de control;

- operaţii implicate de persistenţă;

- operaţii de răspuns la evenimentele sau acţiunile survenite în derularea interacţiunii cu utilizatorii (prin intermediul interfeţelor grafice) ;

- operaţii evidenţiate de diagramele de colaborare, de secvenţe, de stări şi de activităţi;

- operaţii introduse de interfeţele implementate prin clase.

Proiectarea realizărilor de cazuri de utilizare. În condiţiile în care setul de clase, asocieri, atribute şi operaţii au suferit modificări, este necesară revederea maierei de derulare a fiecărui flux de evenimente, respectiv scenariu şi operarea adaptărilor necesare. Tot în acest pas se vor revedea interfeţele cu utilizatorii aferente fiecărei realizări a cazurilor de utilizare.

Proiectarea subsistemelor (a structurii de exploatare). Se va face utilizând termeni cheie ca subsistem, componentă, post de lucru.

Subsistemul este o unitate de comportament în cadrul sistemului, bazată pe o grupare corespunzătoare a elementelor de modelare.

Componenta este o unitate fizică de implementare compusă din cod de program, ce corespunde unui proiect în Visual Basic. Componentele pot fi de mai multe tipuri: executabile, biblioteci dinamice (DLL), controale ActiveX, etc. şi formatul sursă- În proiectarea subsistemelor se pleacă de la modul de organizare a lucrului în reţeaua în

care se va exploata sistemul, adică de la diagrama de distribuire. - În continuare se vor defini componentele şi se vor stabili maniera de reapartizare a acestora

pe nodurile reţelei. Se recomandă ca fiecare pachet de clase de analiză să fie transformat într-o componentă de exploatare (ceea ce faciliteză reutilizarea), dar având grijă ca să nu se ajungă la componente instalabile parţial pe mai multe posturi de lucru diferite. Structurarea pe componente şi dependenţele dintre ele se reprezintă printr-o diagramă de componente, iar repartizarea pe nodurile reţelei printr-o diagramă de distribuire.

- Urmează definirea aplicaţiilor. Aplicaţia constituie grupul de funcţii executate de un actor, pe un anumit post de lucru, deci corespunde unui caz de utilizare. Totuşi se poate referi doar la o parte dintr-un caz de utilizare – dacă acesta se execută pe mai multe posturi de lucru, sau la mai multe cazuri de utilizare, dacă acestea se execută pe acelaşi post de lucru de acelaşi actor.

- Se trasează un model de exploatare sub forma unei diagrame a dependenţelor dintre componente, pentru fiecare dintre aplicaţii.

- Se grupează clasele de proiectare în pachete, definind astfel latura logică a arhitecturii sistemului. Gruparea pe pachete se face ţinând cont de componentele de exploatare, structurile cadru tehnice şi de tehnologiile folosite cum ar fi ADO (ActiveX data objects), RDS (Remote Data Service), DNA (Distributed iNternet Application), MTS (Microsoft Transaction Server) precum şi de pachetele de clase de analiză. Pachetele de clase de proiectare astfel constituite pot forma unităţi de producere independentă a programelor - subsisteme, după ce în prealabil s-au identificat şi extras structuri distincte, părţile cu utilizare multiplă.

Definirea tuturor acestor elemente nu se poate face dintr-o singură abordare. Ea se bazează pe arhitectură, fără de care nu este posibilă concertarea şi coordonarea eforturilor, având în vedere gradul foarte mare de interdependenţe.

Identificarea şi definitivarea interfeţelor. Acest pas se referă la interfeţele interne ale sistemului şi nu la interfeţele cu utilizatorii. Aceste interfeţe sunt constituite din setul de operaţii expuse de o clasă sau un grup de clase, restului sistemului, ceea ce formează parte publică, vizibilă. Ele se constituie în bariere între latura publică şi cea privată cu rolul ca schimbările interne să nu afecteze celelalte componente. Există posibilitatea de a defini mai multe interfeţe diferite pe aceeaşi structură, adresate fiecare unei anumite utilizări . Interfeţele pot apărea la punctele de comunicaţie dintre componente, pachete de clase de proiectare, sau pentru asigurarea dependenţelor dintre clase, subsisteme sau nivele de arhitectură.

Implementarea are ca scop obţinerea programelor necesare materializării proiectului.

UML admite pentru pentru acelaşi tip de diagramă grade de detaliere diferite, mergând până la nivelul cerut de programare. Implementarea mai are sarcina de a da o variantă definitivă pentru:

- Modelul de implementare, care descrie organizarea finală în componente, unele dintre acestea reutilizabile şi structurarea componentelor în subsisteme implementabile;

- Modelul de distribuire care indică amplasarea subsistemelor pe unităţi fizice de calcul ;

- Procedura de integrare a elementelor sistemului , dezvoltate potenţial în momente şi de către echipe sau persoane diferite, într-un sistem unitar.

Implementarea implică deci, transpunerea conţinutului diagramelor şi specificaţiilor de proiectare în forma specifică limbajului de programare folosit, urmată de compilări şi depanări ale codului, până când se va obţine varianta finală, executabilă. Testarea. Scopul acestei activităţi este acela de a identifica şi corecta erorile de programare.

Testarea se face cu seturi de date de test. Testele se pot desfăşura la nivel unitar (componentă sau grup de componente), de integrare (nivel subsistem) şi la nivel sistem.

5.3. Metodologia SSADM. SSADM – IntroductionSSADM (Structured Systems Analysis and Design Methodology) is used in the analysis and design stages of systems development. SSADM does not cover the construction, testing and implementation of software.SSADM is an open standard, i.e. it is freely available for use in industry and many companies offer training and Case tools for it. SSADM is mandated within government departments and many external contractors producing software for the government also have to use it. It is also widely used outside of government IT because it is nonproprietory.

SSADM - The Two Key Techniques:Data modeling identifies and documents the data requirements of a business information system. A Logical Data Model consists of an Entity-Relationship Model and the associated documentation. Data Flow Diagrams identify and document how data flows around a business information system. A Data Flow Model consists of a set of Data Flow Diagrams supported by appropriate documentation. DFDs represent processes, data stores, external entities and data flows. SSADM - DFD Introduction

Data flow diagrams can be used to provide a clear representation of any business function.The technique starts with an overall picture of the business and continues by analyzing eachof the functional areas of interest. This analysis can be carried out to precisely the level of detail required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way.The result is a series of diagrams that represent the business activities in a way that is clear and easy to communicate. A business model comprises one or more data flow diagrams (alsoknown as business process diagrams). Initially a context diagram is drawn, which is a simple representation of the entire system under investigation. This is followed by a level 1 diagram; which provides an overview of the major functionalareas of the business. Don't worry about the symbols at this stage, these are explained shortly. Using the context diagram together with additional information from the area of interest, the level 1 diagram can then be drawn.The level 1 diagram identifies the major business processes at a high level and any of these processes can then be analyzed further - giving rise to a corresponding level 2 business process diagram. This process of more detailed analysis can then continue – through level 3, 4 and so on. However, most investigations will stop at level 2 and it is very unusual to go beyond a level 3 diagram.Identifying the existing business processes, using a technique like data flow diagrams, is an essential precursor to business process re-engineering, migration to new technology, or refine-ment of an existing business process. However, the level of detail required will depend on the type of change being considered.

SSADM – DFD NotationThere are only five symbols that are used in the drawing of business process diagrams (data flow diagrams). These are now explained, together with the rules that apply to them.

This diagram represents a banking process, which maintains customer accounts. In this example, customers can withdraw or deposit cash, request information about their account (for example the balance) or update their account details (for example with change of address information).The five different symbols used in this example represent the full set of symbols required to draw any business process diagram.

External Entity

An external entity is a source or destination of a data flow which is outside the area of study. Only those entities which originate or receive data are represented on a business process diagram. The symbol used is an oval containing a meaningful and unique identifier. In this example the customer exists outside of the banking business system.Process

A process shows a transformation or manipulation of data flows within the system. The symbol used is a rectangular box which contains 3 descriptive elements: Firstly an identification number appears in the upper left hand corner. This is allocated arbitra-rily at the top level and serves as a unique reference.Secondly, a location appears to the right of the identifier and describes where in the system the process takes place. This may, for example, be a department or a piece of hardware. Finally, a descriptive title is placed in the centre of the box. This should be a simple imperative sentence with a specific verb, for example 'maintain customer records' or 'find driver'.Data Flow

A data flow shows the flow of information from its source to its destination. A data flow is represented by a line, with arrowheads showing the direction of flow. Information always flows to or from a process and may be written, verbal or electronic. Each data flow may be referenced by the processes or data stores at its head and tail, or by a description of its contents.

Data Store

A data store is a holding place for information within the system:It is represented by an open ended narrow rectangle. Data stores may be long-term files such as sales ledgers, or may be short-term accumulations: for example batches of documents that are waiting to be processed. Each data store should be given a reference followed by an arbitrary number. Resource Flow

A resource flow shows the flow of any physical material from its source to its destination. For this reason they are sometimes referred to as physical flows.

The physical material in question should be given a meaningful name. Resource flows are usually restricted to early, high-level diagrams and are used when a description of the physical flow of materials is considered to be important to help the analysis. External EntitiesIt is normal for all the information represented within a system to have been obtained from, and/or to be passed onto, an external source or recipient. These external entities may be dupli-cated on a diagram, to avoid crossing data flow lines. Where they are duplicated a stripe is drawn across the left hand corner, like this. The addition of a lowercase letter to each entity on the diagram is a good way to uniquely identify them.

ProcessesWhen naming processes, avoid glossing over them, without really understanding their role. Indications that this has been done are the use of vague terms in the descriptive title area – like 'process' or 'update'.The most important thing to remember is that the description must be meaningful to whoever will be using the diagram.

Data FlowsDouble headed arrows can be used (to show two-way flows) on all but bottom level diagrams. Furthermore, in common with most of the other symbols used, a data flow at a particular level of a diagram may be decomposed to multiple data flows at lower levels.

Data StoresEach store should be given a reference letter, followed by an arbitrary number. These reference letters are allocated as follows:'D' - indicates a permanent computer file'M' - indicates a manual file 'T' - indicates a transient store, one that is deleted after processing.In order to avoid complex flows, the same data store may be drawn several times on a diagram. Multiple instances of the same data store are indicated by a double vertical bar on their left hand edge.SSADM – DFD Relationship Grid

There are rules governing various aspects of the diagram components and how they can relate to one another.

Data FlowsFor data flows the rules are as follows:Data flows and resource flows are allowed between external entities and processes. Data flows are also allowed between different external entities. However, data flows and resource flows are not allowed between external entities and data stores.

ProcessesFor processes the data flow rules are as follows:Data flows and resource flows are allowed between processes and external entities and between processes and data stores. They are also allowed between different processes. In other words processes can communicate with all other areas of the business process diagram.Data StoresFor data stores the data flow rules are as follows:Data flows and resource flows are allowed between data stores and processes. However, these flows are not allowed between data stores and external entities or between one data store and another. In practice this means that data stores cannot initiate a communication of infor-mation, they require a process to do this. SSADM – Context Diagrams

The context diagram represents the entire system under investigation. This diagram should be drawn first, and used to clarify and agree the scope of the investigation.The components of a context diagram are clearly shown on this screen. The system under investi-gation is represented as a single process, connected to external entities by data flows and resource flows. The context diagram clearly shows the interfaces between the system under investigation and the external entities with which it communicates. Therefore, whilst it is often conceptually trivial, a context diagram serves to focus attention on the system boundary and can help in clarifying the precise scope of the analysis.The context diagram shown on this screen represents a book lending library. The library receives details of books, and orders books from one or more book suppliers. Books may be reserved and borrowed by members of the public, who are required to give a borrower number. The library will notify borrowers when a reserved book becomes available or when a borrowed book becomes overdue.

In addition to supplying books, a book supplier will furnish details of specific books in response to library enquiries.Note, that communications involving external entities are only included where they involve the 'system' process. Whilst a book supplier would communicate with various agencies, for example, publishers and other suppliers - these data flow are remote from the 'system' process and so this is not included on the context diagram.

SSADM – Context Diagram GuidelinesFirstly, draw and name a single process box that represents the entire system. Next, identify and add the external entities that communicate directly with the process box. Do this by considering origin and destination of the resource flows and data flows. Finally, add the resource flows and data flows to the diagram. In drawing the context diagram you should only be concerned with the most important information flows. These will be concerned with issues such as: how orders are received and checked, with providing good customer service and with the paying of invoices. Remember that no business process diagram is the definitive solution - there is no absolute right or wrong. SSADM – Level 1 Diagrams

The level 1 diagram shows the main functional areas of the system under investigation. As with the context diagram, any system under investigation should be represented by only one level 1 diagram.There is no formula that can be applied in deciding what is, and what is not, a level 1 process. Level 1 processes should describe only the main functional areas of the system, and you should avoid the temptation of including lower level processes on this diagram. As a general rule no business process diagram should contain more than 12 process boxes.The level 1 diagram is surrounded by the outline of a process box that represents the boundaries of the system. Because the level 1 diagram depicts the whole of the system under investigation, it can be difficult to know where to start. There are three different methods, which provide a practical way to start the analysis. These are explained in the following section and any one of them, or a combination, may prove to be the most helpful in any given investigation.There are three different methods, which provide a practical way to start the analysis. These are introduced below and any one of them, or a combination, may prove to be the most

helpful in any given investigation:

SSADM – Resource Flow AnalysisResource flow analysis may be a useful method for starting the analysis if the current system consists largely of the flow of goods, as this approach concentrates on following the flow of physical objects.Resource flow analysis may be a useful method for developing diagrams if the current system consists largely of the flow of goods. Physical resources are traced from when they arrive within the boundaries of the system, through the points at which some action occurs, to their exit from the system. The rationale behind this method is that information will normally flow around the same paths as the physical objects.

SSADM – Organizational Structure AnalysisThe organizational structure approach starts from an analysis of the main roles that exist within the organization, rather than the goods or information that is flowing around the system.Identification of the key processes results from looking at the organizational structure and deciding which functional areas are relevant to the current investigation. By looking at these areas in more detail, and analyzing what staff actually do, discrete processes can be identified. Starting with these processes, the information flows between them and between these processes and external entities are then identified and added to the diagram.

SSADM – Document Flow AnalysisThe document flow analysis approach is appropriate if the part of the business under investiga-tion consists principally of flows of information in the form of documents or computer input and output.Document flow analysis is particularly useful where information flows are of special interest. The first step is to list the major documents and their sources and recipients. This is followed by the identification of other major information flows such as telephone and computer transac-tions. Once the document flow diagram has been drawn the system boundary should be added. SSADM – Top Down Expansion

The section explains the process of top down expansion, or leveling. Furthermore, it illustrates that whilst there can only be one context and one level 1 diagram for a given system, these normally give rise to numerous lower level diagrams.Each process within a given business process diagram may be the subject of further analysis. This involves identifying the lower level processes that together constitute the process as it was originally identified. This procedure is known as top-down expansion or leveling.

As a business process diagram is decomposed, each process box becomes a boundary for the next, lower level, diagram. SSADM – Top Down Expansion Illustrated

In order to illustrate the process of top-down expansion, consider the three processes shown within this business process diagram. No detail is shown, only the outline of the process boxes, which have been identified during the drawing of a level 1 diagram. Any area of a level 1 diagram is likely to require further analysis, as the level 1 diagram itself only provides a functional overview of the business system. Therefore, below the level 1 diagram there will be a series of lower level diagrams. These are referred to as level 2, level 3, etcetera. In practice, level 2 is usually sufficient and it is unusual to carry out an analysis beyond level 3.In this example the process numbered 3, at level 1, will be investigated further thereby giving rise to a level 2 diagram.In the level 2 diagram four processes of interest have been identified and the numbering of these processes must reflect the parent process. Therefore the level 2 processes are numbered 3.1, 3.2, 3.3 and 3.4Suppose that of these four level 2 processes, one was of sufficient interest and complexity to justify further analysis. This process, let's say 3.3, could then be further analyzed resulting in a corresponding level 3 diagram. Once again the numbering of these processes must reflect the parent process. Therefore these three level 3 processes are numbered 3.3.1, 3.3.2 and 3.3.3.

SSADM – DFD Numbering Rules

The process boxes on the level 1 diagram should be numbered arbitrarily, so that no priority is implied. Even where data from one process flows directly into another process, this does not necessarily mean that the first one has to finish before the second one can begin.Therefore the processes on a level 1 diagram could be re-numbered without affecting the meaning of the diagram. This is true within any business process diagram - as these diagrams do not imply time, sequence or repetition.However, as the analysis continues beyond level 1 it is important that a strict numbering convention is followed. The processes on level 2 diagrams must indicate their parent process within the level 1 diagram. This convention should continue through level 3 diagrams, and beyond, should that level of analysis ever be required. The diagram on this screen clearly illustrates how processes on lower level diagrams identify their ancestral path.

SSADM - When to Stop Top Down ExpansionIt is important to know when to stop the process of top-down expansion. Usually this will be at level 2 or level 3. There are 3 useful guidelines to help you to decide when to stop the analysis: Firstly, if a process has a single input data flow or a single output data flow then it should beapparent that there is little point in analyzing it any further.Secondly, when a process can be accurately described by a single active verb with a singularobject, this also indicates that the analysis has been carried out to a sufficiently low level. For example, the process named validate enquiry contains a single discrete task.Finally, ask yourself if anything useful will be gained by further analysis of a process. Would any more detail influence your decisions? If the answer is no, then there is little point in taking the analysis further. SSADM – Keeping DFDs ClearIn this section a variety of simple techniques are introduced to show how a business process diagram can be clarified. The examples used do not relate to any specific scenario but are hypothetical abstracts used for the purpose of illustration.

Combining ProcessesFirstly, where a diagram is considered to contain too many processes, those that are related can often be combined. As a general rule no business process diagram should contain more

than 12 process boxes. In some examples multiple process boxes can be identified as being related and can be com-bined into a single process box with a collective description.

Exclude Minor Data FlowsWhere information is being retrieved from a data store, it is not necessary to show the selection criteria, or key, that is being used to retrieve it. In the banking example, the customer details are shown being retrieved from the data store but the key used to retrieve this information is not shown. Where a data store is being updated, only the data flow representing the update needs to be shown. The fact that the information must first be retrieved does not need to be shown.Only the most important reports, enquiries, etcetera should be shown on the diagram. Commu-nications that are of less significance can, if necessary, be detailed in support documentation.

Combining External EntitiesAnother way to reduce the complexity of a business process diagram is to combine any related external entities. For example, a business system will often be dealing with different units from within the same external organization, and these can be combined into a single external entity. Where these units are uniquely identified a number should follow the entity identification letter. However, when they are combined the numbers placed after the identifying alphabetic character are not shown.

Combining Data StoresIn a similar way, data stores that are holding related information should be suffixed with a lower case letter. Related data stores can also be combined, and where this is the case the numbers placed after the identifying alphabetic character are not shown. SSADM - Data Modeling

Data modeling is a technique that is widely used in the world of business and information technology to show how information is, or should be, stored and used within a business system.The success of any organization relies on the efficient flow and processing of information.In this example information flows around the various departments within the organization. This information can take many forms, for example it could be written, oral or electronic. Here is an example of the sort of information flows that you might be analyzing:The general manager regularly communicates with staff in the sales and marketing and

accounts departments by using e-mail. Orders received by sales and marketing are forwarded to the production and accounts departments, for fulfillment and invoicing. The accounts department forward regular written reports to the general manager, they also raise invoices and send these to the customers.Data modeling is a technique aimed at optimizing the way that information is stored and used within an organization. It begins with the identification of the main data groups, for example the invoice, and continues by defining the detailed content of each of these groups. This results in structured definitions for all of the information that is stored and used within a given system.The technique provides a solid foundation for systems design and a universal standard for system documentation. Data modeling is an essential precursor to analysis & design, maintenance & documentation and improving the performance of an existing system.

SSADM - Data Modeling Diagram NotationData modeling uses a standard set of symbols to represent each of these defined data groups and then proceeds by establishing the relationships between them. The first of these symbols is the

soft-box entity symbol. An entity is something about which data will be stored within the system under consideration. In this example the data group invoice can be identified as a system entity.The other main component on a data model is the relationship line. A Relationship is an association between two entities to which all of the occurrences of those entities must conform.

The relationship is represented by a line that joins the two entities, to which it refers. This line represents two reciprocal relationships:That of the first entity with respect to the second, and that of the second entity with respect to the first.

Data modeling is all about identifying entities and their relationships and then drawing a diagram that accurately depicts the system. This applies equally to the design of a new system or the analysis of an existing one. The end result of data modeling should be a clear picture of how information is stored and related within a proposed, or existing, system.

SSADM - Data Modeling EntitiesHere, we illustrate the concept of an entity, which can be applied to almost anything that is significant to the system being studied. Some examples of information systems and their entities are listed below:Banking system: Customer, Account, Loan.

Airline system: Aircraft, Passenger, Flight, Airport.An entity is represented by a box containing the name of that entity.A precise definition of ‘entity’ is not really possible, as they even vary in nature. For example, in the airline system, whilst an aircraft is a physical object (entities often are) a flight is an event and an airport is a location. However entities are nearly always those things about which data will be stored within the system under investigation.

Note that entities are always named in the singular; for example: customer, account and loan, and not customers, accounts and loans. This course uses symbols that are standard in the IT industry. This uses the soft-box symbol shown to represent an entity. If a site uses a different symbol set, this is not a problem, as data modeling techniques are the same regardless of the symbols being used.

SSADM – Entity Types & OccurrenceSimilar entity occurrences are grouped together and collectively termed an entity type. It is entity types that are identified and drawn on the data model. An entity occurrence identifies a specific resource, event, location, notion or (more typically) physical object.In this course the term 'entity' is, by default, referring to entity type. The term entity occurren-ce will be specifically used where that is relevant.Each entity has a data group associated with it. The elements of the data group are referred to as the 'attributes ' of the entity. The distinction between what is an attribute of an entity and what is an entity in its own right is often unclear. This is illustrated shortly.

SSADM – Entity Naming Entity names are normally single words and the name chosen should be one familiar to the users. The entity name can include a qualifier in order to clarify their meaning. However, if different names are currently used to describe a given entity in different areas of the organization then a new one should be chosen that is original, unique and meaningful to all of the users. For example, the terms 'signed contract', 'sale' and 'agreement' might be recreated as the entity 'completed'.Conversely an organization may be using a 'catch all' term to describe what the analyst identifies as being a number of separate entities. For example the term 'invoice' may be being used to describe 3 invoice types - each of which is, in fact, processed in a different manner.

In this case prefixing the entity names with qualifiers, is likely to be the best solution. SSADM – Entity IdentificationThe process of identifying entities is one of the most important steps in developing a data model. It is common practice for an experienced analyst to adopt an intuitive approach to entity identifi-cation, in order to produce a shortlist of potential entities. The viability of each of these potential

entities can then be considered using a set of entity identification guidelines. This should result in some of the potential entities being confirmed as entities, whilst others will be rejected.In this exercise you will be asked to identify a set of potential entities within a simple business scenario. This should help you to understand and appreciate the entity identification guidelines better.Read the following case study. Study this information carefully and see if you can identify the entities - remember that entities are those things about which data will be stored.Make your own list of those things that you think are likely to be entities, before moving to the next screen.

SSADM – Entity Identification Case StudyCity Cameras is an independent retailer of cameras, video-cameras and accessories. The owner fulfils the roles of shopkeeper and manager and he purchases a variety of products from a number of different suppliers.The owner can check on different suppliers wholesale and recommended retail prices with reference to their price lists, as shown.During a normal day several customers will enter the shop and a number of them will buy one or more of the products on sale.At some stage the owner may decide that one or more product lines need to be re-ordered, following a visual stock-take. He will then consult the latest suppliers price lists to see who is offering the best deals on given product lines.Following this, he will ring one or more of the suppliers to order some of their products. At the same time he will also make a written record of the orders that have been placed with each supplier on a separate sheet of paper. These records are then used to verify incoming orders and invoicing details. SSADM – Entity Identification – Exercise#1 With reference to the case study information, make a list of all of those things mentioned in the case study that could be entities - that is the potential entities. Your list should look something like that shown below:Suppliers Price List, Customer, Product, Order, Invoicing Details & Supplier

There are six potential entities listed. From this initial list we will consider the 'suppliers price list' to be a likely attribute of the entity 'supplier'. Therefore we shall consider this within the context of the supplier entity. The 'invoicing details' are stated to be attributes of the 'order record' entity, so we shall also discount this as a potential entity at this stage.Remember that entities are described in the singular as they relate to entity types. 'Customer' for example represents the entity type 'customer' which encompasses an infinite number of 'customer' entity occurrences.

Taking these four as our list of potential entities, each will be discussed in turn:

SSADM – Entity Identification – Exercise#2 In many business systems, information about the customer is of great importance. An insurance company or bank, for example, could not function without a customer database on which compre-

hensive personal details are stored. This customer database also serves as an essential resource for selling new financial products and services.But how much customer information is likely to be stored by City Cameras? Are they even going to record the name & address of their customers? Interviews with the owner reveal the answer to be that he has no real interest in storing 'information' about his customers. He only records their details onto any necessary warranty documents and then sends these off to the appropriate supplier. Therefore, in the context of this system customer is NOT an entity.

SSADM – Entity Identification – Exercise#3 It is a natural assumption that all retail businesses would hold a significant amount of product information. However in this study the only level of product information is that which is held on the suppliers' price lists. Lets look again at the suppliers price list in the case study. This confirms that product information is held within this system and it is apparent from the case study that products are of real interest.So have we identified an entity?At this stage it would be likely that product would be considered to be an entity. However, you will shortly see why the analysis phase needs to be iterative - enabling decisions to be altered later, if necessary. SSADM – Entity Identification – Exercise#4

Once again a natural assumption would be that a retail business would store substantial information about its' suppliers.On requesting to see information about City Cameras' suppliers, the owner once again reaches for the suppliers' price lists.Lets look again at the suppliers' price list in the case study. Each of these lists has the name, address and telephone number of the supplier on the first page. The suppliers' price list is the only place where City Cameras stores information about suppliers. Whilst the early investigation indicated that 'product' was probably an entity, it now becomes apparent that the unique identification of a product and access to the product information is also only possible after locating the relevant suppliers price list.

It has now been established that all of the information that is stored in relation to the two potential entities 'product' and 'supplier' are held in the same place - the suppliers' price list. This means that the suppliers' price list is an entity and that both product and supplier represent information held within this entity.Both supplier and product are therefore identified as being attributes of the entity 'suppliers price list'.

SSADM – Entity Identification – Exercise#5 What about the potential entity: 'Order'. Investigation reveals that the re-ordering process consists of visual stocktaking on an ad-hoc basis, followed by mental recall of those suppliers that stock the identified products.The appropriate suppliers price lists are then referred to for the up-to-date pricing information and contact details and the order is placed over the telephone. The owner keeps a written record of the orders he places, each order on a separate sheet of paper, and these are then filed. Let's look again at the record of an order, as shown in the case study.This written order record is used to check against incoming products, to verify invoicing details and to chase orders that may be overdue. The 'order' is held as stored information and therefore 'order' does represent an entity.

SSADM – Entity Identification – Exercise#6 Having started with six potential entities (suppliers price list, customer, product, order, invoicing details and supplier), the analysis has identified that only two of these are in fact entities.We eliminated customer, as no customer information is recorded or stored within this retail outlet. The stored information relating to both a product and a supplier was found to only exist within the suppliers' price list. Therefore Suppliers' Price List was identified as being the only entity amongst these three. Order was confirmed as a system entity and the invoicing details were identified early on as being an attribute of this entity.Even in this simple scenario it should be apparent that entity identification needs careful consi-deration. Interestingly, both of the entities that were identified existed as documents within the system. Entities are often synonymous with discrete information stores within a system – whether physical or electronic. The precise definition of what is an entity and what is an attribute will not always be clear. Therefore the process of entity identification should be iterative, enabling the review of decisions made earlier. Remember, entity types are always named in the singular and this name then represents all of the occurrences of that entity type. SSADM – Entity Identification Guidelines

There are a variety of methods that can be employed when trying to identify system entities. There follows a series of entity identification guidelines, which should prove helpful to the inexperienced analyst:

An informal questioning approach can be adopted, in which the analyst asks targeted questions to determine what information is necessary and whether or not that information is recorded within the system.During face to face discussions with users the nouns (or given names of objects) should be recorded - as these often indicate those things that are entities within a system. The existing documentation often contains clues as to the information that needs to be held and once again the nouns in the text may indicate potential entities. Every fact that is required to support the business is almost certainly an attribute (or data item). In turn each of these attributes will belong to an entity. If no 'parent' entity can be found for one or more of these low level facts, then this indicates that your entity search is incomplete. However, don't get hung up on the initial analysis. Entity identification can continue once the drawing of the data model diagram has begun. As this diagram is developed and refined further entities may become apparent. SSADM – Attributes Many different occurrences of a given entity type can usually be identified. In the gift shop example both of the entities 'order' and 'suppliers price list' had numerous occurrences.Each entity type can always be described in terms of attributes, and these attributes will apply to all occurrences of that given entity type. In the camera shop example, all occurrences of the entity 'supplier' could be described by an identifiable set of attributes, including:The Supplier Name, the Supplier Address, Telephone Number, etcetera.A given attribute belonging to a given entity occurrence can only have one value. Therefore, if a supplier could have more than one address or telephone number then this should be deter-mined before defining the attributes of that entity type. In this example the defined entity may require two or three address and/or telephone number attributes. It is the maximum practical instances of a given attribute that should be catered for in the entity type definition. SSADM – Entity KeysAn entity is defined by its attributes. Furthermore, each entity occurrence can be uniquely identified, by using an attribute or a combination of attributes as a key.The primary key is the attribute (or group of attributes) that serve to uniquely identify each entity occurrence. Consider the problem that might arise if the name and address of an indivi-dual were used as the primary key for identifying the patients within a hospital. Take the example of a patient called David Smith living at 23 Acacia Avenue. He has a son also called David Smith living at the same address.Name and Address would not necessarily provide a unique identifier and confusion could easily arise, potentially creating a mix up with the patient records. For this reason, in a hospital system patients each have a Patient Number as their primary key. If two or more data items are used as the unique identifier, then this represents a compound

key. For example, a compound key used to identify a book could be 'Title' together with 'Author'.There may be occasions of authors using a previously used title but not of an author using the same title for more than one of their own books.Where several possible primary keys exist they are called candidate keys.For example, a book could be identified, either by 'Title' together with 'Author' or by the widely used unique identifier for books - the ISBN number.

Where an attribute of one entity is a candidate key for another entity, it is termed a foreign key.

For example, the attribute 'Author' belonging to the entity Book is a foreign key within the entity Author. You may be able to think of some shortcomings to the use of this attribute as the primary key, for example two authors having the same name. It is worth noting that entity relationships are often indicated by the presence of foreign keys. SSADM – Relationships

The relationship is the association between two entities to which all of the occurrences of those entities must conform. The diagram shown represents the beginnings of a data model where the relationship between a manager and a department needs to be defined. The entities on data models are linked by relationship lines and together these are the only two components that make up a data model diagram. A relationship is an association between two entities to which all of the occurrences of those entities must conform. Every relationship line shows two reciprocal relationships:That of the first entity with respect to the second and that of the second entity with respect to the first. In this example a manager is responsible for a department and a department is the respon-sibility of a manager.Each relationship line has three distinct properties: Firstly the relationship link phrase, secondly the degree or cardinality of the relationship and thirdly the participation or optionality of the relationship. These three properties combine to form the relationship statement.

SSADM – Relationship Link Phrase

The first property of the relationship statement is the relationship link phrase. This should be a short description of the nature of the relationship, typically between three and five words long. It is always read clockwise with respect to the entities that it links, so in this example: 'Manager

is responsible for department', and 'Department is responsibility of manager'. If the same relationship were to be drawn with department on the left hand side then the positions of the link phrases would have to be reversed.

SSADM – Relationship CardinalityThe second property of the relationship statement is the degree, or maximum cardinality, of the relationship. If an entity has a crowsfoot symbol drawn against it, then many occurrences of that entity may relate to the other entity. Conversely if no crowsfoot is drawn against it, at most one occurrence of that entity may relate to the other entity.

In this example: Each company employs one or more employees, but Each employee is employed by only one company. This is called a one-to-many relationship. Maximum cardina-lities may be combined to give another two relationship types, In this example:

Each manager is responsible for only one department and each department is the responsibility of only one manager. This is called a one-to-one relationship.And in this example:

Each lecturer teaches one or more courses and each course is taught by one or more lecturers. This is called a many-to-many relationship.To recap, three different relationship types have been illustrated, one-to-many, one-to-one and many-to-many.

SSADM – Relationship ParticipationThe third and final property of the relationship statement is the participation or optionality. A solid line shows that an entity occurrence must be associated with each occurrence of the other entity. In this example:

Each passenger must possess a ticket, and Each ticket must belong to a passenger. A dotted line shows that an entity occurrence may be associated with each occurrence of the other entity, In this example:

Each book may be borrowed by a borrower, and Each borrower may borrow one or more books. Furthermore, these symbols can be combined. In this example:

Each book may be recalled by a reservation, but each reservation must be recalling a book.Remember, there are only two components to a data model diagram, entities and relationships. A relationship is an association between two entities to which all of the occurrences of those two entities must conform. There are three distinct properties of the relationship; firstly the relationship link phrase, secondly the degree or cardinality of the relationship and thirdly the participation or optio-nality of the relationship. These three properties are collectively termed the relationship statement. SSADM – Identifying RelationshipsThere are just two questions that need to be asked, in order to establish the degree of the rela-tionship that exists between any two entities.In order to identify the degree of the relationship between the entities X and Y the following two questions need to be asked.Question 1Can an occurrence of X to be associated with more than one occurrence of Y?Question 2Can an occurrence of Y to be associated with more than one occurrence of X?Each of these questions can be answered 'Yes' or 'No' and both questions must be answered. This means that there are four possible outcomes as shown in the table.

The nature of the relationship associated with each outcome is as follows:Option 1, Question1 equals Yes, Question2 equals No. In this case a one-to-many relationship has been identified, represented by the relationship line shown.Option 2, Question1 equals No, Question2 equals YesAs in the first case a one-to-many relationship has been identified, represented by the rela-

tionship line shown.Option 3, Question1 equals Yes, Question2 equals Yes In this case a many-to-many relationship has been identified.Many-to-many relationships may be shown in the early 'preliminary' data model in order to aid the clarity of these early diagrams. However, such relationships are invalid and are therefore always re-modeled using 'link entities' in later diagrams. This process is explai-ned later in the course.Option 4, Question1 equals No, Question2 equals No In this case a one-to-one link has been identified. Legitimate one-to-one relationships are rare and it is likely that this relationship is one that needs to be rationalized. The methods used to investigate one-to-one relationships and to re-model them where necessary are explained later in the course.In a one-to-many relationship the entity at the 'one' end is normally referred to as the master, and the entity at the 'many' end referred to as the detail entity. Some analysts adopt the 'no dead crows' rule and avoid drawing crowsfeet pointing upwards. This ensures that detail entities are shown below the master entities to which they belong. This makes the diagram clearer, although congestion may make this rule difficult to enforce throughout the data model.

SSADM – Relationship StatementsThe relationship statement is a formal description that encompasses the three properties of the relationship. The first property is the relationship link phrase, the second the degree or cardinality of the relationship and the third the participation or optionality of the relationship.

5.4. Metoda CMM (Capability Maturity Model)

I. The capability maturity model for software: background, concepts, structures and usage. 1. Introducing Software Process Maturity. The Evolution of the CMM.Immature versus Mature Software Organizations.Fundamental Concepts Underlying Process Maturity.Total Quality Management and the CMM.Customer Satisfaction.Benefits and Risks of Model-Based Improvement.

2. The Software Process Maturity Framework. Behavioral Characterization of the Maturity Levels.Skipping Maturity Levels.Visibility into the Software Process.Prediction of Performance.

3. The Structure of the Capability Maturity Model. Internal Structure of the Maturity Levels .

Maturity Levels.Key Process Areas.Key Practices.Common Features.

4. Interpreting the CMM. Interpreting the Key Practices.The Key Process Area Template.Interpreting the Common Features.Organizational Structure and Roles.Understanding Software Process Definition.The Evolution of Processes.Applying Professional Judgment.

5. Using the CMM. A CMM-Based Appraisal Method.Process Assessments and Capability Evaluation.Software Process Improvement.Using the CMM in Context.

6. A High-Maturity Example: Space Shuttle Onboard Software. Introduction.Background.Approaches to Process Improvement.Overall Lessons.

II. The key practices of the capability maturity model for software.

7. The Key Areas for Level 2: Repeatable. Requirements Management.Software Project Planning.Software Project Tracking and Oversight.Software Subcontract Management.Software Quality Assurance.Software Configuration Management.

8. The Key Process Areas for Level 3: Defined. Organization Process Focus.Organization Process Definition.Training Program.Integrated Software Management.Software Product Engineering.Intergroup Coordination.Peer Reviews.

9. The Key Process Areas for Level 4: Managed.

Quantitative Process Management.Software Quality Management.

10. The Key Process Areas for Level 5:Optimizing. Defect Prevention.Technology Change Management.Process Change Management.

Appendix A: References. Appendix B: Acronyms. Appendix C: Glossary. Appendix D: Abridged Version of the Key Practices. Appendix E: Mapping the Key Practices to Goals. Appendix F: Comparing ISO 9001 and the CMM. Appendix G: An Overview of ISO's SPICE Project. Appendix H: Change History of the CMM. Appendix I: Change Request Form. Index. 0201546647T04062001

5.5. Metoda costurilor sau ingineria valorii

ANEXA 1. Detalii cu privire la obiective, iesiri, formalizarea atributelor Detalii cu privire la obiective, iesiri, formalizarea atributelor şi documente de intrareşi documente de intrare

1. Definirea obiectivelor (se face în etapa MGD)Obiectivele sistemului informatic reprezinta scopuri imediate si de perspectiva ale

perfectionarii activitatii economice si de conducere, in vederea ridicarii nivelului de informare operativa si previzionala a structurilor organizatorice, a perfectionarii metodelor si proceselor tehnico-informationale si de conducere pentru asigurarea maximalizarii efieientei economice si a rentabilitatii unitatii beneficiare.

Obiectivele sistemului informatic presupun abordarea si rezolvarea informatica a unor probleme cu caracter sintetic si analitic, într-o maniera sistemica, pentru asigurarea scopurilor propuse. Aceste obiective sunt diferentiate în functie de nivelele micro, mezo si macroeconomice avand caracteristici generale si specifice, subordonate cadrului legislativ-normativ, dotarii cu tehnica de calcul si cerintelor dezvoltarii economice, imediate si de perspectiva, a unitatii beneficiare.

Obiectivele sistemului informatic pot fi: - generale ; - specifice.

•Obiective generale Obiectivele generale ale unui sistem informatic vizeaza probleme cu caracter global ale

conducerii unitatii comerciale si structurale specifice compartimentelor functionale, în scopul realizarii atributelor conducerii si ale functiilor unitatilor economice. in raport de aceste aspecte, obiectivele generale pot fi:

- de conducere (manageriale); - funcţionale.

Obiectivele de conducere urmaresc aspecte globale de conducere ale unitatii economice, si au în vedere urmatoarele probleme :

- rentabilizarea permanenta a activitatii economice; -realizarea globala si structurala a indicatorilor economico-

financiari (cifra de afaceri, valoarea adaugata, profitul brut si net, capitalul propriu, capacitatea de plata, rata rentabilitatii, eficienta utilizarii fondurilor fixe etc.), calculul si planificarea ·rezultatelor" planificarea financiara a investitiilor, previzionarea activelor circulante si a surselor de finantare, previzionarea activitatii de trezorerie, inclusiv utilizarea bugetului general al unitatii economice.

- perfectionarea activitatii de conducere în vederea asigurarii unui optim global la nivelul întregii activitati economice;

- fundamentarea deciziilor de conducere tactica, strategica si operativa pe baza informatiilor obtinute ca urmare a prelucrarilor sistemului informativ;

- asigurarea unei coordonari a intregului sistem informational- de cizional; - utilizarea selectiva a unor informatii de exceptie (rata anuala de înnoire a

mijloacelor fixe, tendintele preturilor de aprovizionare, etc.), pentru asigurarea unei gestiuni eficiente a patrimoniului net pe baza unor informatii cu caracter programatic si analitic;

- degrevarea conducerii de procesele decizionale de rutina, formalizarea prin noul sistem a informatiilor sintetice necesare derularii relatiilor informationale cu organismele de stat si cu alte regii autonome sau societati comerciale;

- furnizarea într-o forma adecvata, eficienta si facila a informatiilor globale necesare conducerii unitatii economice, sub forma unor indicatori globali, situatii cu caracter sintetic, grafice, etc., care trebuie sa contina date relevante, prin intermediul afisarii la videoterminal;

- cresterea calitatii procesului decizional prin abordarea sistemica a activitatii unitatii economice si utilizarea modelarii matematice,adoptate sistemelor electronice de calcule;

- extinderea principiului conducerii prin exceptie si pe baza de obiective. Obiectivele functionale ale unui sistem informatic au în vedere informatizarea

activitatilor în conformitate cu anumite functii ale unitatii economice (comerciala,· financiar-contabila si de personal), dosfasuratâ la nivelul compartimentelor functionale. Aceste obiective sunt fundamental dependente de specificul activitatii regiilor autonome sau al societatilor comerciale si cuprind urmatoarele deziderate generale: a) Activitatea comerciala (aprovizionare, desfacere, marketing,) desfasurata in cadrul unor compartimente corespunzatoare are în vedere elementele specifice fiecarei subactivitati din punct de vedere informatic, dupa cum urmeaza: - Subactivitatea de aprovizionare tehnico-materiala propune rezolvarea

urmatoarelor aspecte specifice: fundamentarea necesarului si a comenzilor de aprovizionat; contractarea necesarului de aprovizionat; urmarirea derularii contractelor de aprovizionare.

- Subactivitatea de desfacere a rezultatelor activitatii presupune: primirea si centralizarea comenzilor de la clienti; livrarea catre clientii interni si externi a productiei contractate; urmarirea ritmicitatii livrarilor în scopul onorarii contractelor

încheiate.Subactivitatea de marketingSubactivitatea de marketing presupune: presupune:

studierea caracteristicilor tehnico-economice, inclusiv astudierea caracteristicilor tehnico-economice, inclusiv a tehnicilor de comercializare a produselor concurente,tehnicilor de comercializare a produselor concurente, furnizate de alte societati comerciale din tara sau strainatate;furnizate de alte societati comerciale din tara sau strainatate;

studierea caracteristicilor specifice ale pietelor de desfacerestudierea caracteristicilor specifice ale pietelor de desfacere in vederea realizarii relatiilor valutar-financiare si dein vederea realizarii relatiilor valutar-financiare si de distribuire a produselor proprii; distribuire a produselor proprii;

cooperarea cu alte societati comerciale din tara saucooperarea cu alte societati comerciale din tara sau strainatate în vederea promovarii produselor pe terte piete. strainatate în vederea promovarii produselor pe terte piete.

b) Activitatea financiar-contabila (financiar, contabilitate, control financiar) desfasurata în cadrul compartimentelor specifice presupune rezolvarea din punct de vedere informatic a unor elemente specifice, dupa cum urmeaza : Subactivitatea financiara are în vedere:

Calculul si decontarea tuturor categoriilor de impozite (impozitul pe salariu, impozitul pe circulatia marfurilor sau impozitul pe valoarea adaugata, impozitul pe profit);

elaborarea bugetului general al unitatii economice pe an financiar, cu defalcare pe subunitati;

derularea relatiilor banesti cu bugetul statului, bancile comerciale interne, si externe, inclusiv cu alti agenti economici din tara sau strainatate;

efectuarea si urmarirea decontarilor cu tertii (persoane fizice sau juridice). Subactivitatea de contabilitate la nivelul unitatii economice se structureaza în doua componente:

Contabilitatea financiara (sintetica) concretizata în urmarirea existentului si miscarii elementelor patrimoniale (imobilizari, stocuri, creante si datorii, mijloace financiare, capital privit sub forma de fonduri, rezerve si finantari, credite, cheltuieli si venituri).

Contabilitatea de gestiune (analitica) poate fi organizata fie prin detalierea conturilor de evidenta a elementelor patrimoniale privite la nivelul contabilitatii financiare (grupele I-VIII), fie prin utilizarea unor conturi de gestiune interna care se organizeaza în functie de necesitatile de informare si conducere ale unitatü economice. Aceasta detaliere urmareste reflectarea stocurilor, veniturilor, cheltuielilor si rezultatelor pe intervalul de gestiune al unitatii economice. Din cele prezentate rezulta ca întreaga activitate de contabilitate asigura:

înregistrarea cronologica si sistematica a tuturor operatiilor economice;

prelucrarea datelor în concordanta cu principiile si metodele contabilitatii;

sintetizarea întregii activitati financiar-contabile prin intermediul instrumentelor de baza ale contabilitatii (balanta si bilantul contabil).

- Subactivitatea de control financiar la nivelul unitatii economice urmareste analiza si controlul gestiunii patrimoniului regiei autonome sau soeietatii comerciale prin instrumente proprii în scopul prevenirii si sesizarii încalcarii normelor legale de utilizare a resurselor umane, materiale si banesti.

c) Activitatea de personal (evidenta personalului, salarizare, perfectionarea calificarii salariatilor) desfasurata în cadrul unor compartimente adecvate, cu o pondere dependenta direct de specificul regiei autonome sau societatii comerciale, are în vedere rezolvarea sub aspect informatic a problemelor impuse de existenta, miscarea si scolarizarea personalului angajat, inclusiv aspectele specifice salarizarii,dupa cum urmeaza: Subactivitatea de evidenta a personalului, presupune:

evidenta existentului si a miscarii de personal pe profesii, functii, nivele de calificare, etc., pe diferite intervale de timp;

atestarea pe profesii, functii si locuri de munca a salariatilor in raport de evolutia specificului activitatii;

verificarea încadrarii personalului pe profesii, functii si locuri de activitate. - Subactivitatea de salarizare asigura:

evidenta timpului lucrat si nelucrat de salariati; calculul lunar al drepturilor banesti în raport de activitatea depusa;

evidentierea eventualelor imputatii sau popriri pentru rezultatele necorespunzatoare ale activitatii depuse, inclusiv determinarea impozitului pe salariu si alte categorii de retineri.

Subactivitatea de perfectionare a calificarii personalului are o pondere diferentiata în functie de sectoarele de activitate, caracterizate printr-o dinamica accentuata a tehnologiilor utilizate, motiv pentru care se urmareste realizarea sub raport informatic a urmatoarelor cerinte:

analiza raportului dintre nivelul de calificare mediu al personalului angajat si nivelul cerut de tehnologiile de productie utilizate;

urmarirea activitati de scolarizare si de atestare profesionala, dupa finalizarea cursurilor de pregatire;

stabilirea prioritatilor în angajarea a noi categorii de salariati, astfel încat activitatea unitatii economice sa se desfasoare, la cel mai înalt grad de tehnicitate.

•Obiective specifice Obiectivele specifice ale unui sistem informatic urmaresc rezolvarea unor probleme

dependente strict de activitatea de baza (productie, comert, servicii etc.) si de cea auxiliara, în raport de functiile de cercetare si productie. Acestea au un caracter propriu si dependent de rolul unitatii economice în meeanismul economiei de piata. Privite sub acest aspect, obiectivele specifice ule unui sistem informatic pot fi structurate în : - obiective specifice activitatii de baza; - obiective specifice activitatii auxiliare.

Obiectivele specifice activitatii de baza urmaresc realizarea sub aspect informatic a tuturor subactivitatilor de cercetare si productie ce constituie specificul activitatii regiei autonome sau al societatii comerciale. Aceste obiective sunt diferentiate (au caracter particular), dar ele se pot incadra într-o structura fundamentala, prin intermediul careia sistemul informatic trebuie sa realizeze: - utilizarea eficienta a capacitatilor de productie; - introducerea de tehnologii si produse noi la nivelul tehnicii actuale; - realizarea ritmica si de calitate a lucarilor de investitii; - modernizarea utilajelor si a altor factori de prodctie; - îmbunatatirea continua a calitatii productiei; - cresterea gradului de utilizare a capacitatilor de productie; - încadrarea consumurilor de materiale în normele tehnologice; - utilizarea rationala a capacitatilor de depozitare a materialelor si produselor.Obiectivele specifice activitatii auxiliare vor avea în vedere realizarea sub aspect informatic a tuturor subactivitatilor secundare, desfasurate în cadrul unitatii economice. Aceste obiective au un caracter particular, o pondere si o importanta diferentiata de la un agent economic la altul, avand ca scop rezolvarea unor aspecte specifice, cum ar fi: - urmarirea operativa a activitatii sectoarelor auxiliare a caror activitate determina in mod direct desfasurarea activitatilor principale;

- folosirea eficienta a capacitatilor auxiliare de productie; - robotizarea, paleatizarea si containerizarea activitatilor auxiliare din unitatea economica; - realizarea programelor de asimilare a noilor produse si de perfectionare a tehnologiilor de fabricatie în scopul generalizarii la nivelul activitatii de baza;

- asigurarea unei colaborari si specializari ale caror rezultate urmeaza a fi incluse în sectoarele de baza ale unitatii economice. Obiectivele generale si specifice ale unui sistem informatic, pot surprinde si alte aspecte concrete, ce decurg din: - marimea unitatii economice; - ponderea acesteia într-o ramura de activitate; - gradul de specializare a activitatilor de baza si auxiliare, într-un domeniu concret al economiei de piata; - gradul de participare al unitatii economice la derularea unor operatiuni de export-import, cooperare internationala etc., factori ce pot impune si alte tipuri de obiective, a caror nuantare va fi diferita de la o unitate economica la alta. Obiectivele sistemului informatic trebuie sa asigure: - utilizarea eficienta si extensiva a sistemelor electronice de ealcul si a retelei de calculatoare-teletransmisie, specifice întregului sistem informatic proiectat : - cresterea vitezei de circulatie a informatiilor, reducerea ciclului informational si a timpului de raspuns ca urmare a realizarii noului sistem informatic. - functionarea performanta, în conditii de fiabilitate si stabilitate în timp, a întregului ansamblu de echipamente de calcul, care trebuie sa realizeze

folosirea în retea a întregii game de echipamente de calcul într-o varianta arhitecturala, pentru a satisface integral cerintele sistemului informatic proiectat;

utilizarea eficienta a unitatii centrale a sistemului electronic de calcul printr-o alocare dinamica a spatiului de memorie în vederea satisfacerii permanente a tuturor utilizatorilor sistemului informatic;

folosirea alocarii virtuale a suporturilor externe de memorare in vederea realizarii unei confidentialitati adecvate , si a unei utilizari eficiente a acestora;

realizarea celei mai adecvate si operative metode de codificare si introducere a datelor, în scopul minimalizarii timpului de încarcare a colectiilor de date prin intermediul fisierelor sau bazei de date;

adoptarea unor solutii performante de realizare a procedurilor de exploatare a colectiilor de date în vederea obtinerii la videoterminale a tuturor iesirilor în care se concretizeaza obiectivele noului sistem;

asigurarea unei securitati si confidentialitati maxime a colectiilor de date si a utilizatorilor etc. Abordarea integrala a obiectivelor generale si specifice permite proiectarea

unui sistem informatic integrat (total) la nivelul unei unitatI economice în conditii de eficienta maxima.

Obiectivele sistemului informatic urmeaza a fi concretizate în iesirile specifice ale acestuia: indicatori economico-financiari, liste/situatii de iesire, grafice, iesiri catre alte sisteme.

2. Iesirile sistemului informatic (se identifică în MGD şi se aprofundează în MCDD)Realizarea practica a obiectivelor sistemului informatic se caracterizeaza prin satisfacerea

cerintelor informationale ale conducerii şi structurilor organizatorice din unitatea beneficiara. Iesirile sistemului informatic pot fi privite din punct de vedere:

- structural; - functional; - tipologic.

Din punct de vedere structural, iesirile sistemului informatic reprezinta a treia componenta din triada ce caracterizeaza structura generala a oricarui tip de sistem: Intrari – Prelucrari – Iesiri.

Din punct de vedere functional, iesirile sistemului informatic concretizeaza obiectivele generale si specifice ale sistemului proiectat. Din punct de vedere tipologic, iesirile sistemului informatic pot fi redate sub forma de:

- indicatori sintetici privind starea si rezultatele activitatii economico- financiare; - liste/situatii de iesire care cuprind indicatorii analitici ai starii si rezultatelor activitatii economico-financiare;

- grafice care redau sub forma sinoptica starea si evolutia indicatorilor economico-financiari - iesiri catre alte sisteme informatice, transmise în direct (off-line) prin intermediul suporturilor magnetice (disc flexibil, disc magnetic,banda magnetica etc.), sau direct (on-line) prin intermediul unei retele locale de calculatoare. Indiferent de tipologia iesirilor sistemului informatic, acestea trebuie sa respecte cerintele siIndiferent de tipologia iesirilor sistemului informatic, acestea trebuie sa respecte cerintele si restrictiile cadrului legislativ-normativ în vigoare, pentru ca activitatea unitatii economice sa serestrictiile cadrului legislativ-normativ în vigoare, pentru ca activitatea unitatii economice sa se desfasoare in coordonatele legalitatii economice. desfasoare in coordonatele legalitatii economice.

2.1. 2.1. Indicatorii economico-financiariIndicatorii economico-financiari specifici unitatii economice specifici unitatii economice au rolul de a au rolul de a caracteriza din punct de vedere sintetic si analitic activitatea economico-financiara princaracteriza din punct de vedere sintetic si analitic activitatea economico-financiara prin intermediul unor informatii care redau: intermediul unor informatii care redau: - patrimoniul net al regiei autonome sau a societatii comerciale prin intermediul inventarierii- patrimoniul net al regiei autonome sau a societatii comerciale prin intermediul inventarierii patrimoniului si a posturilor din bilantul contabil elaborate la finele perioadei de gestiune; patrimoniului si a posturilor din bilantul contabil elaborate la finele perioadei de gestiune; - starea si rezultatele economico-financiare ale unitatii economice pe o perioada determinata de - starea si rezultatele economico-financiare ale unitatii economice pe o perioada determinata de gestiune; gestiune; - calculul si planificarea financiara a investitiilor; - calculul si planificarea financiara a investitiilor; - calculul si planificarea rezultatelor economico-financiare; - calculul si planificarea rezultatelor economico-financiare; - calculul si previzionarea activelor circulante si surselor de finantare; - calculul si previzionarea activelor circulante si surselor de finantare; - calculul si previzionarea activitatii de trezorie. - calculul si previzionarea activitatii de trezorie.

Acesti indicatori au rolul de a concretiza obiectivele generale de conducere si functionaleAcesti indicatori au rolul de a concretiza obiectivele generale de conducere si functionale ale unitatii economice, motiv pentru care ei pot constitui rezultatul prelucrarii unui sistemale unitatii economice, motiv pentru care ei pot constitui rezultatul prelucrarii unui sistem informatic proiectat. informatic proiectat.

Selectarea concreta a anumitor indicatori din multimea totala a acestora se poate realiza înSelectarea concreta a anumitor indicatori din multimea totala a acestora se poate realiza în functie de: functie de: - - Tipul unitatii economiceTipul unitatii economice (regii autonome, societati comerciale in: (regii autonome, societati comerciale in:

nume colectiv, comandita simpla, comandita pe actiuni, societate nume colectiv, comandita simpla, comandita pe actiuni, societate pe actiuni sipe actiuni si societate cu raspundere limitata determina utilizarea societate cu raspundere limitata determina utilizarea nuantata a unor indicatorinuantata a unor indicatori economico-financiari. economico-financiari. - - Specificul activitatii de baza a unitatii economiceSpecificul activitatii de baza a unitatii economice poate determina poate determina

utilizarea unor indicatori economico-financiari comuni sau utilizarea unor indicatori economico-financiari comuni sau specifici. Despecifici. De exemplu, pentru regiile autonome de extractia exemplu, pentru regiile autonome de extractia petrolului, natura activitatiipetrolului, natura activitatii determina utilizarea unor indicatori determina utilizarea unor indicatori specifici, cum ar fi: productia marfa fabricata,specifici, cum ar fi: productia marfa fabricata, productia marfa vînduta si incasata etc., în timp ce la o societate comerciala a carei activitate deproductia marfa vînduta si incasata etc., în timp ce la o societate comerciala a carei activitate de baza consta în comercializarea bunurilor de consum, se vor utiliza indicatori .specifici activitatii,baza consta în comercializarea bunurilor de consum, se vor utiliza indicatori .specifici activitatii,

cum sunt: valoarea totala a vanzarilor de marfuri, cheltuieli totale cu depozitarea cum sunt: valoarea totala a vanzarilor de marfuri, cheltuieli totale cu depozitarea marfurilor, cheltuieli de reclama si publicitate etc. marfurilor, cheltuieli de reclama si publicitate etc.

Mentionam ca ambele categorii de unitati economice mentionate, pot utiliza indicatoriMentionam ca ambele categorii de unitati economice mentionate, pot utiliza indicatori economico-financiari comuni, cum ar fi: cifra de afaeeri, capitalul propriu, profitul total realizat,economico-financiari comuni, cum ar fi: cifra de afaeeri, capitalul propriu, profitul total realizat, profitul net, profitul folosit pentru autofinantare, capacitatea de plata, rata rentabilitatii,profitul net, profitul folosit pentru autofinantare, capacitatea de plata, rata rentabilitatii, rentabilitatea capitalului etc. rentabilitatea capitalului etc.

- - Complexitatea si volumul activitatii unitatii economiceComplexitatea si volumul activitatii unitatii economice poate poate impune selectarea anumitor indicatori care sa ofere informatii sintetice sau analitice raportateimpune selectarea anumitor indicatori care sa ofere informatii sintetice sau analitice raportate direct la arrumite aspecte concrete din activitatea unitatii economice. direct la arrumite aspecte concrete din activitatea unitatii economice.

- - Gradul de dispersare a activitatii unitatii economiceGradul de dispersare a activitatii unitatii economice poate poate determina determina utilizarea unor indicatori specifici pe subunitati si în dinamica, astfel încat la nivelul global alutilizarea unor indicatori specifici pe subunitati si în dinamica, astfel încat la nivelul global al unitatii economice, conducerea acesteia sa cunoasca operativ rezultatele întregii activitatiunitatii economice, conducerea acesteia sa cunoasca operativ rezultatele întregii activitati economico-financiare. economico-financiare.

2.2. Listele/situatiile de iesire2.2. Listele/situatiile de iesire reflecta cerintele informationale ale conducerii unitatii economice reflecta cerintele informationale ale conducerii unitatii economice sau compartimentelor functionale in cadrul obiectivelor generale ale sistemului informatic. sau compartimentelor functionale in cadrul obiectivelor generale ale sistemului informatic.

Listele/situatiile de iesire contin un sistem de indicatori economico-financiari, sintetici sauListele/situatiile de iesire contin un sistem de indicatori economico-financiari, sintetici sau analitici grupati într-o forma care sa asigure materializarea integrala a obiectivelor propuse. analitici grupati într-o forma care sa asigure materializarea integrala a obiectivelor propuse.

Listele sau situatiile de iesire trebuie sa reflecte, prin continutul lor, starea si dinamicaListele sau situatiile de iesire trebuie sa reflecte, prin continutul lor, starea si dinamica fenomenelor si proceselor economice care fac obiectul de prelucrare a datelor din sistemulfenomenelor si proceselor economice care fac obiectul de prelucrare a datelor din sistemul proiectat. Natura prelucrarilor sistemului informatic are un caracter specific in functie de naturaproiectat. Natura prelucrarilor sistemului informatic are un caracter specific in functie de natura activitatii unitatii economice si impune o anumita structurare a indicatorilor economico-financiariactivitatii unitatii economice si impune o anumita structurare a indicatorilor economico-financiari în cadrul listelor/situatiilor de iesire. în cadrul listelor/situatiilor de iesire.

Determinarea concreta a continutului, formei si a circuitului informational al situatiilor deDeterminarea concreta a continutului, formei si a circuitului informational al situatiilor de iesire sunt realizate în functie de natura activitatii, cerintele informationale ale conducerii unitatiiiesire sunt realizate în functie de natura activitatii, cerintele informationale ale conducerii unitatii economice, obiectivele propuse, cadrul legislativ-normativ (legi, decrete, hotârari, normeeconomice, obiectivele propuse, cadrul legislativ-normativ (legi, decrete, hotârari, norme metodologice, instructiuni, decizii interne) si cerintele specifice, unitatii beneficiare. Acestemetodologice, instructiuni, decizii interne) si cerintele specifice, unitatii beneficiare. Aceste restrictii impun un anumit continut economic al situatiilor inclusiv elementele referitoare larestrictii impun un anumit continut economic al situatiilor inclusiv elementele referitoare la destinatie, utilizare, frecventa si forma concreta în care vor apare. destinatie, utilizare, frecventa si forma concreta în care vor apare. Listele/situatiile de iesire ce urmeaza a se obtine în cadrul unui sislem informatic pot fiListele/situatiile de iesire ce urmeaza a se obtine în cadrul unui sislem informatic pot fi structurate si utilizate în concordanta cu: structurate si utilizate în concordanta cu: - specificul functiilor desfasurate concret în unitatea economica; - specificul functiilor desfasurate concret în unitatea economica; - destinatia listelor/ situatiilor de iesire; - destinatia listelor/ situatiilor de iesire;

- gradul de sintetizare a indicatorilor economico-financiari inclusi - gradul de sintetizare a indicatorilor economico-financiari inclusi in liste/situatii; in liste/situatii; - momentul generarii listelor/situatiilor de iesire; - momentul generarii listelor/situatiilor de iesire; - referinta în timp a acestora; - referinta în timp a acestora; - modul de obtinere a listelor/situatiilor de iesire etc. - modul de obtinere a listelor/situatiilor de iesire etc.

Listele/situatiile de iesire trebuie sa reflecte, prin continutul lor, starea si dinamicaListele/situatiile de iesire trebuie sa reflecte, prin continutul lor, starea si dinamica fenomenelor si proceselor economice desfasurate efectiv în cadrul unitatii economice beneficiare.fenomenelor si proceselor economice desfasurate efectiv în cadrul unitatii economice beneficiare. Natura prelucrarilor sistemului informatic are un caracter specific determinat de natura activitatiiNatura prelucrarilor sistemului informatic are un caracter specific determinat de natura activitatii unitatii economice, element care impune o anumita structurare a indicatorilor economico-unitatii economice, element care impune o anumita structurare a indicatorilor economico-financiari în cadrul listelor/situatiilor de iesire. financiari în cadrul listelor/situatiilor de iesire.

Determinarea concreta a continutului, formei si a circuitului informational specificDeterminarea concreta a continutului, formei si a circuitului informational specific situatiilor de iesire sunt determinate în functie de: situatiilor de iesire sunt determinate în functie de: - natura si complexitatea activitatii desfasurate de unitatea economica;- natura si complexitatea activitatii desfasurate de unitatea economica; - cerintele informationale formulate de conducerea unitatii economice beneficiare; - cerintele informationale formulate de conducerea unitatii economice beneficiare;

- cerintele informationale formulate de compartimentele functionale implicate in functionarea- cerintele informationale formulate de compartimentele functionale implicate in functionarea sistemului informatic; sistemului informatic;

Continutul informational al listelor/situatiilor de iesire determina modul concret deContinutul informational al listelor/situatiilor de iesire determina modul concret de structurare si ordonare a indicatorilor economico-financiari în raport cu structurare si ordonare a indicatorilor economico-financiari în raport cu cerintele legislative încerintele legislative în vigoarevigoare. Aceste restrictii impun un anumit continut concret al listelor/situatiilor de iesire, inclusiv. Aceste restrictii impun un anumit continut concret al listelor/situatiilor de iesire, inclusiv elementele referitoare la circuitul informational al acestora în cadrul unitatii economiceelementele referitoare la circuitul informational al acestora în cadrul unitatii economice benefïciare. benefïciare.

Structurarea situatiilor de iesire se realizeaza în functie de: Structurarea situatiilor de iesire se realizeaza în functie de: - specificul functiilor generale ale unitatii economice; - specificul functiilor generale ale unitatii economice; - destinatia listelor situatiilor de iesire; - destinatia listelor situatiilor de iesire; - gradul de sintetizare a indicatorilor economico-financiari; - gradul de sintetizare a indicatorilor economico-financiari; - momentul generarii situatiilor de iesire; - momentul generarii situatiilor de iesire; - modul de obtinere. - modul de obtinere. La definitivarea fiecarei liste/situatii de iesire se recomanda: La definitivarea fiecarei liste/situatii de iesire se recomanda:

- - titlul situatieititlul situatiei, care va reda într-o forma sintetica continutul , care va reda într-o forma sintetica continutul informational al acesteia si perioada sa de referinta;informational al acesteia si perioada sa de referinta;

--indicatorii prezenti în fiecare coloanaindicatorii prezenti în fiecare coloana cu specificarea: cu specificarea: - - algoritmul de calculalgoritmul de calcul(daca este cazul); (daca este cazul); - - natura si lungimea maximanatura si lungimea maxima a fiecarui indicator; a fiecarui indicator; - - gradele de total si subtotalgradele de total si subtotal; ; - - numarul de exemplarenumarul de exemplare, destinatia fiecarui exemplar, frecventa, , destinatia fiecarui exemplar, frecventa,

termenele de obtinere. termenele de obtinere. La definitivarea continutului si formei listelor/situatiilor de iesire se recomanda sa seLa definitivarea continutului si formei listelor/situatiilor de iesire se recomanda sa se urmareasca o valorificare cat mai deplina a posibilitatilor de prelucrare oferite de sistemulurmareasca o valorificare cat mai deplina a posibilitatilor de prelucrare oferite de sistemul electronic de calcul. De asemenea, se vor avea în vedere si anumite cerinte cu caracter general,electronic de calcul. De asemenea, se vor avea în vedere si anumite cerinte cu caracter general, cum sunt rezolvarea unor functii majore ale conducerii unitatii, existenta unei game suficiente sicum sunt rezolvarea unor functii majore ale conducerii unitatii, existenta unei game suficiente si reprezentative de informatii, pentru a permite analiza exhaustiva a fenomenelor si proceselorreprezentative de informatii, pentru a permite analiza exhaustiva a fenomenelor si proceselor economice reflectate. Aceste cerinte impun ca listele/situatiile de iesire sa fie prezentate într-oeconomice reflectate. Aceste cerinte impun ca listele/situatiile de iesire sa fie prezentate într-o forma simpla, inteligibila de natura sa asigure si facilitatea în utilizare, ceea ce impune omitereaforma simpla, inteligibila de natura sa asigure si facilitatea în utilizare, ceea ce impune omiterea detaliilor nesemnificative, ce nu corespund scopului propus. detaliilor nesemnificative, ce nu corespund scopului propus. 2.3. Graficele2.3. Graficele redau într-o forma sugestiva evolutia in timp a valorii indicatorilor economico- redau într-o forma sugestiva evolutia in timp a valorii indicatorilor economico-financiari continuti în listele/situatiile de iesire. Ele pot fi : financiari continuti în listele/situatiile de iesire. Ele pot fi : - graficele liniare- graficele liniare redau evolutia in timp a redau evolutia in timp a valorilor specifice fiecarui indicator, reprezentatevalorilor specifice fiecarui indicator, reprezentate prin puncte amplasate la o distanta de axaprin puncte amplasate la o distanta de axa orizontala, proportionala cu valorile respective.orizontala, proportionala cu valorile respective. intr-un asemenea grafic se pot reprezentaintr-un asemenea grafic se pot reprezenta maximum sase indicatori;maximum sase indicatori;

- graficele de tip bare- graficele de tip bare arata arata diferentele dintre valorilediferentele dintre valorile indicatorilor, prin intermediul unorindicatorilor, prin intermediul unor zone verticale ale caror dimensiunizone verticale ale caror dimensiuni sunt proportiona-le cu valorile realesunt proportiona-le cu valorile reale ale indicatorilor; ale indicatorilor;

- graficele de tip xy- graficele de tip xy reprezinta relatia dintre valorile indicatorilor. in zona x se va reda setul de reprezinta relatia dintre valorile indicatorilor. in zona x se va reda setul de valori pentru axa orizontala, iar în zona Y se vor reflecta valorile ce sugereaza relatia dintrevalori pentru axa orizontala, iar în zona Y se vor reflecta valorile ce sugereaza relatia dintre indicatorii prezentati; indicatorii prezentati;

-

- graficele stive specifica valorile indicatorilor prin intermediul unor zone verticale suprapuse, ale caror dimensiuni sunt proportionale cu valorile reale prezentate prin grafic;

- graficele rotunde asigura reflectarea ponderii unor valori aferente unui indicator în cadrul unui set complet de valori, ce reprezinta valorile integrale sau totale ale indicatorului. În mod concret, graficul are forma unui cerc, iar

fiecare valoare a indicatorului este reprnzentata prin intermediul unui sector de cerc si redat în unitatile procentuale.

Aceste grafice pot fi însotite de elemente complementare: Aceste grafice pot fi însotite de elemente complementare: - titlul si subtitlul graficului; - titlul si subtitlul graficului; - legende privind reprerentarea indicatorilor din grafic; - legende privind reprerentarea indicatorilor din grafic; - grile pentru redarea graficului prin linii orizontale, verticale sau prin patrate. - grile pentru redarea graficului prin linii orizontale, verticale sau prin patrate. - reprezentarea cromatica a graficului (alb-negru sau alte culori); - reprezentarea cromatica a graficului (alb-negru sau alte culori); - definirea unor formate corespunzatoare pentru valorile indicatorilor (numar fix de zecimale, - definirea unor formate corespunzatoare pentru valorile indicatorilor (numar fix de zecimale, reprezentare eu mantisa si exponent, prin procente; format histograma - semnul “+” pentru valorireprezentare eu mantisa si exponent, prin procente; format histograma - semnul “+” pentru valori pozitive si semnul “-“ pentru valori negative etc.). pozitive si semnul “-“ pentru valori negative etc.).

Graficele pot fi obtinute în cadrul unui sistem informatic prin prelucrarea colectiilor deGraficele pot fi obtinute în cadrul unui sistem informatic prin prelucrarea colectiilor de date, care conduc la obtinerea unor liste/situatii sub forma de tabele, ce pot fi reprezentate îndate, care conduc la obtinerea unor liste/situatii sub forma de tabele, ce pot fi reprezentate în continuare sub forma de grafice prin intermediul unor produse de programare specializatecontinuare sub forma de grafice prin intermediul unor produse de programare specializate (LOTUS 1-2-3, TBL, QUATTRO,EXCEL,ACCESS etc.). (LOTUS 1-2-3, TBL, QUATTRO,EXCEL,ACCESS etc.).

2.4. Iesiri c2.4. Iesiri căătre alte sisteme tre alte sisteme Sistemul informational propriu unitatii economice se afla în interconexiune cu sistemeleSistemul informational propriu unitatii economice se afla în interconexiune cu sistemele

informationale aferente altor unitati economice sau organisme guvernamentale. Aceastainformationale aferente altor unitati economice sau organisme guvernamentale. Aceasta caracteristica impune si necesitatea corelarii sistemului informatic specific unitatii economicecaracteristica impune si necesitatea corelarii sistemului informatic specific unitatii economice benefiaiare cu alte sisteme informatice conexe. in acest sens, iesirile sistemului informatic albenefiaiare cu alte sisteme informatice conexe. in acest sens, iesirile sistemului informatic al unitatii beneficiare pot constitui intrari în alte sisteme informatice, în timp ce iesirile altor sistemeunitatii beneficiare pot constitui intrari în alte sisteme informatice, în timp ce iesirile altor sisteme informatice pot fi intrari în sistemul informatic propriu unitatii economice. Acesteinformatice pot fi intrari în sistemul informatic propriu unitatii economice. Aceste interconditionari se pot realiza prin intermediul retelelor de calculatoare ce vor asigurainterconditionari se pot realiza prin intermediul retelelor de calculatoare ce vor asigura conexiunea dintre bazele informationale specifice, carora le vor corespunde bazele de dateconexiunea dintre bazele informationale specifice, carora le vor corespunde bazele de date asociate, între care se realizeaza schimbul efectiv de date. asociate, între care se realizeaza schimbul efectiv de date. Din punct de vedere tipologic, iesirile catre alte sisteme informatice pot fi: Din punct de vedere tipologic, iesirile catre alte sisteme informatice pot fi:

0 50

Ian

Apr

0

50

Ian Pla ti

0

50

Ian Pla ti

010203040

Ian

Apr

Plati

- - directedirecte (on-line), asigurate prin intermediul transmisiilor de date între doua retele locale de (on-line), asigurate prin intermediul transmisiilor de date între doua retele locale de calculatoare proprii agentului economic; calculatoare proprii agentului economic; - indirecte- indirecte (of f-line), asigurate prin transmiterea datelor într-o anumita structura, continut si un (of f-line), asigurate prin transmiterea datelor într-o anumita structura, continut si un anumit suport magnetic, la anumite frecvente stabilite de comun acord. anumit suport magnetic, la anumite frecvente stabilite de comun acord.

3. Formalizarea atributelor (se aplică în MCDD)Formalizarea atributelor are ca scop elaborarea codurilor si adaptarea documentelor de intrare la cerintele sistemului informatic. -3.1 Codificarea atributelor

Necesitatea codificarii atributelor este impusa de cerintele de grupare si ierarhizare a atributelor care ofera multiple posibilitati de prelucrare a colectiilor de date în care va fi transpusa baza informationala. Codificarea atributelor conduce si la utilizarea intensiva a suporturilor direct adresabile si a memoriei interne, ceea ce permite optimizarea accesului la diverse valori a atributelor, concomitent cu minimalizarea timpului de prelucrare a viitoarelor colectii de date. De asemenea, codurile aferente atributelor bazei informationale pot asigura confidentialitatea si integritatea valorii atributelor, ceea ce confera colectiilor de date o anumita protectie si securitate în timpul prelucrarii. In mod concret codificarea atributelor trebuie sa realizeze o corelatie directa între semantica atributelor existente în baza informationala de intrare si multimea de simboluri acordate acestora (codurile sistemului informatic) în concordanta cu cerintele si functiile specifice codurilor. În acest sens, se urmaresc: - cerintele si functiile codificarii; - tipurile de coduri utilizate într-un sistem informatic; - fazele realizarii codificarii.

a) Cerintele si functiile codificarii Activitatea de codificare a atributelor, trebuie sa asigure o legatura între specificul

unitatii economice si particularitatile bazei informationale de intrare. Codificarea trebuie sa raspunda urmatoarelor cerinte:

- Unicitatea codului, presupune existenta unui singur simbol pentru un atribut al bazei informationale de intrare (corespondenta biunivoca), prin asigurarea unei valori unice pentru fiecare tip de atribut proprietate care trebuie asigurata la nivelul întregului sistem informatic.

- Stabilitatea si supletea în timp a codului, exprima necesitatea utilizarii unui tip de cod pe toata perioada de existenta a bazei informationale, inclusiv adaptarea extensiilor de volum ale valorilor atributelor codificate la dinamica valorilor bazei informationale. Extinderea poate afecta fie numarul de valori atribuite în momentul generarii codului, fie numarul de pozitii maxim reprezentate în interiorul fiecarui interval din structura codului.

Atribuirea codurilor pentru eventualele noi valori ale atributelor se poate realiza prin doua modalitati: - acordarea de noi coduri pentru valorile atributelor ce apar ulterior alocarii initiale de coduri, în cadrul aceleiasi clase de coduri, astfel încat totalitatea codurilor utilizate la un anumit moment sa poata asigura corespondenta reala cu dinamica activitatii unitatii economice;

- folosirea unor tipuri de coduri care sa fie asociate claselor de coduri initiale, astfel încat noul cod utilizat, desi cu lungimea marita, sa caracterizeze în mod obiectiv fiecare tip de atribut. - Comoditatea utilizarii codului se refera la facilitatea operatiilor de codificare-decodificare precum si la detectarea si corectarea erorilor.

Codurile trebuie sa fie usor de înteles si aplicat, astfel încat personulul unitatii economice beneficiare sa asimileze intr-un timp cat mai scurt noul sistem de coduri. - Concizia codului se refera la necesitatea utilizarii unui numar cat mai mic de caractere pentru reprezentarea elementelor codificate. Aceasta asigura, pe de o parte, reducerea timpului de manipulare a codului si o crestere a conciziei de exprimare a atributelor informationale.

In vederea asigurarii acestor cerinte, codificarea atributelor o constituie atribuirea manuala sau automata, într-o forma sistematizata, a unor coduri pentru fiecare atribut component al bazei informationale. Functiile codificarii trebuie sa permita caracterizarea directa a fiecarui tip de atribut ce va fi supus operatiei de codificare, identificarea formala a acestora, controlul valorilor posibile ale atributelor în cadrul colectiilor de date, inclusiv functia de manipulare a atributelor codificate. Functia de caracterizare, asigura exprimarea intr-o forma concisa, unica si stabila în timp, a continutului semantic a fiecarui atribut, prin intermediul codurilor asociate acestuia. În mod concret functia de caracterizare permite utilizarea cu prioritate a codului specific atributului în locul denumirii integrale a acestuia (exemplu: în loc de Facultatea de Contabilitate şi Informatică de Gestiune se poate folosi codul descriptiv FCIG).Functia de identificare, ofera posibilitatea regasirii mai rapide a atributelor prin intermediul codurilor asociate lor, decat prin folosirea completa a semanticii atributului. Aceasta functie creeaza posibilitatea alterioara de selectare a anumitor atribute prin intermediul carora se vor identifica în mod unic anumite valori solicitate prin intermediul conceptului de cheie candidata, primara, externa etc. Functia de control, presupune existenta unui caracter de control care se ataseaza în ultima pozitie din dreapta structurii codului pe baza caruia, prin intermediul unor metode (aritmetica sau geometrica) si algoritmi specifici, sa se poata verifica integral, corectitudinea simbolurilor care intra în structura codurilor. Functia de manipulare a atributelor codificate, faciliteaza introducerea eficienta în memorie a acestora, reducerea timpului de preluclare, minimalizarea prelucrarilor atributului, inclusiv usurinta folosirii codului de catre compartimentele functionale implicate în realizarea sistemului informatic.

În vederea realizarii cerintelor si functiilor codificarii, conceptul de cod presupune utilizarea unor simboluri acordate atributelor bazei informationale de intrare. La randul sau simbolul este prezentat de un sir de caractere, care permite exprimarea intr-o forma conventionala a unui element din ansamhlu de atribute codificate.

Simbolul este format dintr-un sir de caractere numerice alfabetice sau alfanumerice, ce pot fi interpretate de factorul uman sau de procedurile automate ale sistemului informatic. În aceasta viziune, codul este o colectie ordonata de simboluri, formate la randul lor din siruri de caractere, care asigura identificarea si utilizarea unei entitati sau a unui atribut al bazei informationale.Codificarea atributelor este necesara deoarece asigura ca avantaje : - înlocuirea atributelor prin coduri numerice, alfabetice si afanumerice care permite folosirea intensiva a suporturilor externe si a memoriei centrale; - realizarea unei ierarhizari a atributelor, în functie de criteriile specifice prelucrarii, prin ordonarea acestora în raport de cerintele de selectare a atributelor din baza informationala si de obtinere a gradelor de total si subtotal pentru listele/situatiilor de iesire; - optimizarea timpului de acces la colectiile de date în care va fi transpusa baza informationala de intrare;

- reducerea erorilor prin folosirea codurilor care înlocuiesc utilizarea explicita a valorii atributelor; - simplitatea scrierii codurilor în comparatie cu folosirea denumirii explicite a atributelor pentru care regulile de scriere sunt complexe si greu de respectat.

In aceasta viziune, structura logica a codurilor trebuie sa asigure realizarea optima a unei corespondente biunivoce, între multimea valorilor reale ale atributelor si multimea codurilor asociate acestora, asa cum se reda în continuare: [COD] Û [ atribute, entitati, situatii, documente]b) Tipuri de coduri utilizate într-un sistem informatic. Diversitatea si complexitatea continntului bazei informationale de intrare, precum si multitudinea proceselor de prelucrare a atributelor componente, au condus la aparitia unei game variate de coduri ce se pot grupa dupa mai multe criterii asa cum se reda în figura urmatoare.

Codurile elementare au rolul de a identifica un element din cadrul unei multimi de elemente. Din aceasta grupa fac parte: codurile secventiale, secventiale pe grupe, sau clase, cu semnificatia mnemonica si descriptiva. - Codurile secventiale se formeaza prin atribuirea unui sir de caractere fiecarui element al multimii, stabilind o corespondenta (în ordine crescatoare) intre elementele acestora si, multimea numerelor naturale. Fiecarui element supus codificarii i se asociaza un cod crescator, imediat disponibil. De exemplu, daca o persoana care lucreaza la o unitate economica are marca 1412, aceasta este precedata de persoana cu marca 1411 si urmata de persoana cu marca 1413. Acest cod devine un analitic al contului “Decontari cu salariatii”.

Dupa structura - coduri secventiale simbolului - coduri secventiale pe grupe sau clase

- Elementare - coduri cu semnificatie mnemonica - coduri cu semnificatie descriptiva

- coduri - liniar simplu - Complexe ierarhizate - zecimal

- coduri juxtapuse

Dupa modul de -Autodetectoare de erori Tipuri de detectare si corectare -Autocorectoare de erori coduri a erorilor

Dupa natura - Numerice atributelor - Alfabetice - Alfanumerice

Dupa lungime - Fixa - Variabila

Dupa modul de - Manual elaborare (atribuire) - Automat

Codurile secventiale pot fi atribuite automat prin adaugarea valorii unu la o variabila care constituie codul secvential. Pentru a avea o lungime fixa a codului, este indicat a se stabili dimensiunea maxima a acestuia, ceea ce va asigura si estimarea dimensiunii fizice a codului. Codurile secventiale se pot realiza în functie de un sistem de numeratie (b) si lungimea simbolului propus (n), ceea ce asigura o lungime maxima a codului (Lmax = bn). In aceasta lungime a codului se va include un numar maxim de elemente dependent de valorile lui b si n.. Spre exemplu, daca se folosesc caracterele sistemului de numeratie in baza 10, iar lungimea simbolului preconizat este de 3 caractere n=3 atunci lungimea maxima a codului este Lmax= bn = 103 =1000, ceea ce conduce la posibilitatea atribuirii unui set maxim de simboluri intre limitele 001 si 999. De mentionat, ca în mod concret nu este indicata utilizarea codului zero. - Codurile secventiale pe grupe sau clase, se formeaza prin rezervarea unui set maxim de simboluri pentru fiecare tip de atribut omogen, caracterizat prin particularitati comune ce formeaza o grupa specifica supusa codificarii.

Grupele atribuite sunt dependente de specificul economic al atributelor si de cerintele de prelucrare omogena ale acestora, cu mentiunea ca în cadrul fiecarei grupe se vor atribui coduri secventiale pana la valoarea maxima rezervata acesteia. De exemplu în cadrul normelor metodologice privind reflectarea în contabilitate a capitalului social si a altor active si pasive din regiile autonome sau societati comerciale, planul de conturi este structurat in opt clase de conturi, în intervalul carora se folosesc coduri secventiale. Exemplu : Clasa a 7-a ,”Conturi de venituri” cuprinde: 70 – Vanzari de produse fabricate si de marfuri. 701 – Vanzari de produse intermediare. 702 – Vanzari de produse finite, s.a.m.d. - Codurile cu semnificatie mnemonica se formeaza fie prin consoanele unui cuvant, fie prin prescurtarea (abrevierea) denumirii atributului codificat (de exemplu OL pentru otel laminat). Acest tip de cod este foarte practic pentru prelucrarile manuale. - Codurile cu semnificatie descriptiva se formeaza prin combinarea initialelor denumirii cu particularitatile tehnico-constructive ale atributului de codificat. Acest tip de cod este utilizat în special la nomenclatoarele industriale, fiind extensibil pentru particularitatile tehnice semnificative. De exemplu, pentru codificarea conturilor analitice de materiale în cazul otelului rotund cu diametrul de 15 mm si lungimea barei de 10 m, codul atribuit este OR 15 10.Codurile complexe contin atribute ce apartin unor multimi distincte, dar sunt folosite în comun pentru viitoarele prelucrari. in aceasta categorie se includ codurile ierarhizate juxtapuse

- Codurile ierarhizate contin atribute între care exista relatii de incluziune astfel încat acestea sa poata fi reprezentate prin intermediul unei structuri arborescente. De exemplu, în cadrul unei unitati economice producatoare de aparatura electronica se fabrica mai multe grupe de produse (televizoare, aparate radio, casetofoane, videocasetofoane, etc.), în cadrul carora productia est.e diversificata pe subgrupe (televizoare alb-negru, color etc.) si tipuri de produse (Telecolor, Elcrom, Cromatic etc.), asa cum se reda în figura urmatoare.

Grup\ de produse

Televizoare

Aparate radio

Casetofoane

Video-casetofoane

Subgrupa

TV. alb negru color

Tipul produsului

Telecolor

Elcrom Cromatic

Treapta 1

Treapta 2

Treapta 3

Structura concreta a acestui cod ierarhizat se determina practic în functie de doi factori: - numarul de trepte ale codului; - numarul maxim de aparitii ale fiecarui tip de atribut în cadrul treptelor de ierarhizare. În aceste conditii codul mentionat are urmatoarea structura: Tl, T2, T3

Codurile ierarhizate se folosesc pentru acele atribute între care exista relatii de ierarhizare, cu mentiunea ca acestea se folosesc în comun. Codurile juxtapuse se realizeaza prin concatenarea codurilor ierarhizate sau a codurilor elementare în vederea utilizarii grupate sau individuale a atributelor codificate, în raport de cerintele statice sau dinamice de prelucrare. De exemplu, pentru codificarea personalului unei unitati economice, se poate realiza un cod juxtapus rezultat din concatenarea valorilor distincte ale atributelor (cod sectie, cod atelier, cod echipa si marca) asa cum rezulta in continuare.

Codurile complexe se asociaza atributelor bazei informationale de intrare, în functie de relatiile Codurile complexe se asociaza atributelor bazei informationale de intrare, în functie de relatiile de ierarhizare si numarul maxim de valori posibile pentru fiecare tip de atribut, cu mentiunea ca de ierarhizare si numarul maxim de valori posibile pentru fiecare tip de atribut, cu mentiunea ca

grup\ de produsegrup\ de produse

subgrup\ de produsesubgrup\ de produse

tip de produstip de produs

T1 T1 T2 T2 T3T3

SectieSectie

EchipaEchipa

atelieratelier

marcamarca

T1 T2 T1 T2 T3 T3 T4 T4

în situatia obtinerii unui cod cu lungime egala sau mai mare cu trei caractere, este oportuna în situatia obtinerii unui cod cu lungime egala sau mai mare cu trei caractere, este oportuna atasarea unui alt caracter în ultima pozitie din dreapta, denumita cifra sau litera de control.atasarea unui alt caracter în ultima pozitie din dreapta, denumita cifra sau litera de control.Codurile autodetectoare de eroriCodurile autodetectoare de erori

Acest caracter de control va face parte din structura codului si va avea aceeasi valoareAcest caracter de control va face parte din structura codului si va avea aceeasi valoare atata timp cat valorile atributelor componente nu se schimba. De asemenea, acest caracter deatata timp cat valorile atributelor componente nu se schimba. De asemenea, acest caracter de control poate asigura fie detectarea automata a eventualelor erori introduse, fie si corectareacontrol poate asigura fie detectarea automata a eventualelor erori introduse, fie si corectarea automata a acestora. automata a acestora.

Detectarea automata a erorilor introduse se poate face prin compararea caracterului deDetectarea automata a erorilor introduse se poate face prin compararea caracterului de control care însoteste codul respectiv cu caracterul de control determinat de calculator la fiecarecontrol care însoteste codul respectiv cu caracterul de control determinat de calculator la fiecare utilizare operativa a codului. utilizare operativa a codului. Pentru realizarea concreta a caracterului de control se pot folosi mai multe Pentru realizarea concreta a caracterului de control se pot folosi mai multe metode de calculmetode de calcul dintre care mentionam: dintre care mentionam:

-- aritmetica; aritmetica; -- geometrica. geometrica.

Metoda aritmeticaMetoda aritmetica consta în stabilirea caracterului de control (C) prin intermediul unei cifre consta în stabilirea caracterului de control (C) prin intermediul unei cifre obtinuta pe baza sumei produselor rezultate din inmultirea fiecarei cifre a codului (Cobtinuta pe baza sumei produselor rezultate din inmultirea fiecarei cifre a codului (C ii) cu anumite) cu anumite valori conventional alese, denumite ponderi (Pvalori conventional alese, denumite ponderi (Pii) ale codului, ce urmeaza a fi scazuta din cifra) ale codului, ce urmeaza a fi scazuta din cifra zecilor imediat superioara (Z), astfel: zecilor imediat superioara (Z), astfel:

Spre exemplu, folosind ca ponderi valorile alternative 2 si l, caracterul de control pentru codul 85432, se va calcula în felul urmator :

8 5 4 3 2 Ci 2 1 2 1 2 Pi

= (1+6) + 5 + 8 + 3 + 4 = 27 iar Z=30

Rezultă că C = 30 – 27 = 3 In situatia în care produsul dintre cifra codului si ponderea corespunzatoare depaseste

valoarea noua atunci acest produs se va lua in calcul ca suma cifrelor care-1 compun (exemplu 8 X 2 = 16 rezulta 1+ 6). Codul initial 85432 în urma stabilirii caracterului de control devine 854323.

Avantajul metodei aritmetice consta în simplitatea si acuratetea acesteia, iar dezavantajul consta în imposibilitatea sesizarii erorilor de compensare. Metoda geometrica consta în stabilirea caracterului de control (C) prin intermediul unei cifre sau litere obtinuta ca rest al împartirii sumei produselor fiecarei cifre a codului, cu puterile crescatoare ale lui 2, la un numar sau cu numerele naturale în ordine crescatoare, par sau impar ales conventional (x), în urmatoarele faze: - calculul sumei produselor dintre cifrele codului si ponderii:

- determinarea continutului de control :

( )/X

Marimea numarului par sau impar ales conventional (X) determina numarul de cifre si valoarea maxima a caracterului de control. Spre exemplu, pentru acelasi cod (85432) caracterul de control va fi calculat în felul urmator:

8 5 4 3 2 25 24 23 22 21

(8 X 32) + (5 X 16) + (4 X 8) + (3 X 4) + (2 X 2) 256 + 80 + 32 + 12 + 4 = 384

384 : 11 = 34 rest 10 Codul în urma stabilirii cheii de control este 85432l0. Aceasta metoda asigura un grad mai

ridicat de siguranta, dar se poate ajunge la o cifra de control formata din doua pozitii ceea ce conduce la o marire a lungimii codului.

Pentru a evita marirea lungimii codului si pentru a limita posibilitatea aparitiei erorilor de compensatie, se poate folosi o varianta a metodei geometrice caracterizata prin faptul ca numarul impar ales este 23 (cel mai mare numar natural asociat literelor alfabetului englez), iar caracterul de control este o litera ce se determina prin transformarea restului obtinut prin aplicarea algoritmului metodei geometrice în litera din alfabetul englez care are numarul natural corespunzator valorii restului. În acest caz algoritmul metodei este urmatorul:

( )/23

De exemplu, pentru codul 85432 utilizat si la celelalte metode, litera de control se determina astfel:

8 5 4 3 2 Ci5 4 3 2 1 Pi (unde Pi este ales ca fiind egal cu i).

40 + 20 + 12 + 6 + 2 = 80 =

80 : 23 = 3 rest 11, echivalentul literei cu numarul de ordine 11 din alfabetul englez, este litera K. Codul, în urma stabilirii literei de control este 85432K.

Metodele aritmetica si geometrica pot fi utilizate în corespondenta si cu alti algoritmi de calcul, cu pastrarea principiilor de determinare a caracterului de control si de asigurare operativa a controlabilitatii codului asociat unui atribut.

Indiferent de modalitatea de determinare a caracterului de control, principiul de verificare al codului ramane acelasi. La fiecare citire a codului calculatorul electronic aplica algoritmul de calcul al caracterului de control si compara rezultatul obtinut cu caracterul de control introdus odata cu codul. Daca caracterul de control calculat este diferit de caracterul de control care însoteste codul, se invalideaza atributul respectiv. Posibilitatea aparitiei erorilor este generata de inversarea sau însumarea eronata a cifrelor codului, scrierea eronata a codului în documentele de intrare sau de introducere gresita de la terminal. Coduri autocorectoare de eroriCorectarea automata a erorilor permite atat detectarea erorilor cat si rectificarea automata a acestora. in acest scop, codurile sunt aranjate sub forma matriceala, stabilindu-se pentru fiecare linie si coloana cate un caracter de control determinat prin însumarea cifrelor pe linie sau pe coloana si scazand rezultatul din ordinul zecilor imediat superior. Eventualele erori se localizeaza la intersectia liniei si coloanei ale caror caractere sunt diferite de caracterele de control initial stabilite. Abaterea dintre caracterul de control determinat pe liniile matricei in raport de cel determinat pe coloanele acesteia, constituie valoarea absoluta a erorii. In

determinarea caracterelor de control pe fiecare linie (j) si coloana (i) din matricea asociata codului, se folosesc urmatoarele relatii:

Clinj = Z-

Ccoli = Z-

iar caracterul general aferent liniei si coloanei din matrice se stabileste astfel :

Clinie = Z - si Ccoloana = Z-

Daca Clinie = Coloana atunci caracterul de control este corect si codul este validat, iar în caz contrar (Cline # Ccoloana) se stabileste dimensiunea erorii (E = Clinie _ Ccoloana), iar codul se invalideaza. Pentru exemplificare se consideră codul 734285411936 care se aranjează sub forma unei matrice de patru linii si trei coloane asupra carora se aplica algoritmii de calcul în doua etape : - prima etapa :

Grupul de coduri controlate dupa aceasta metoda se scrie în serie, urmat de caracterele de controlGrupul de coduri controlate dupa aceasta metoda se scrie în serie, urmat de caracterele de control pe linii, pe coloane si cel general astfel: 734 285 411 936 6542 854 3. Procedura automata depe linii, pe coloane si cel general astfel: 734 285 411 936 6542 854 3. Procedura automata de verificare a codurilor, citeste structura codului în aceasta ordine, dupa care calculeaza caractereleverificare a codurilor, citeste structura codului în aceasta ordine, dupa care calculeaza caracterele de control si localizeaza eroarea la intersectia liniei si coloanei pentru care caracterele de controlde control si localizeaza eroarea la intersectia liniei si coloanei pentru care caracterele de control nu corespund cu cele stabilite anterior. Vnu corespund cu cele stabilite anterior. Valoarea care se aplică cifrei greşite pentru a genera o cifră corectă este dată de diferenţa dintre cifra generală de control (în cazul analizat 3) şi caracterul general de control calculat de calculator.Spre exemplificare, daca în loc de secventa 285 apare 295, atunci procedura va sesiza eroarea Spre exemplificare, daca în loc de secventa 285 apare 295, atunci procedura va sesiza eroarea prin identificarea liniei , si coloanei eronate folosind acelasi algoritm de calcul; prin identificarea liniei , si coloanei eronate folosind acelasi algoritm de calcul; a doua etapa :

7 3 4 6 2 9 5 4 4 1 1 4 9 3 6 2 8 4 4 4

caracterul de controlcaracterul de control pe linii (Cpe linii (Clinlin))

caracterul de control caracterul de control general (Cgeneral (Clinie linie şi şi CCcoloanăcoloană))

Caracterul de Caracterul de control control pe coloane pe coloane (C(Ccolcol))

6 6 5 5 4 4 22

33

734 734 285 285 411 411 936936

854854

Linie Linie eronataeronata

Coloane Coloane eronataeronata

Pentru a realiza o codificare a nomenclatoarelor care sa satisfaca cerintele prezentate, este necesar ca responsabilitatea acestei munci sa fie încredintata unei persoane cu functie de raspundere în cadrul unitatii economice, care sa asigure generalizarea unor coduri eficiente si sa evite proliferarea unor coduri particulare. in acest scop se procedeaza la inventarierea tuturor atributelor care compun baza informationala de intrare, precum si tipurile de prelucrari aferente.

Înainte de a opta pentru un sistem de codificare se cerceteaza daca exista un asemenea sistem si în ce masura poate fi utilizat. Este necesar sa se precizeze modul de atribuire practica a codurilor precum si modalitatea de control. În continuare se stabilesc procedeele de difuzare a nomenclatoarelor de coduri si modalitatile de modificare operativa a acestora, pentru a elimina codurile perimate si a permite actualizarea acestora. Înainte de a se trece la utilizarea unui sistem de coduri este necesara testarea acestora pentru a depista si înlatura eventualele erori, deoarece orice greseala de codificare are consecinte imprevizibile asupra rezultatelor prelucrarii. Marimea erorii este data de, diferenta dintre caracterul de control stabilita initial ,si caracterul de control general calculat în timpul verificarii (3 - 4 = -1). Corectarea automata a erorilor implica utilizarea unui spatiu mare de memorie deoarece se utilizeaza matricele si tabelele de referinta necesare verificarii codului în cele doua etape. De asemenea, se ocupa mult suport tehnic deoarece alaturi de codurile propriu-zise apar si grupele de cifre de control pe linii si coloane, iar procedurile automate sunt mai complicate.

Atributele bazei informationale de intrare pot fi de tip numeric, alfabetic si alfanumeric, de lungime fixa sau variabila, ceea ce conduce la utilizarea unor coduri adecvate în realizarea sistemelor informatice. Codurile pot fi elaborate manual sau automat prin intermediul unor proceduri de generare a acestora. Oportunitatea activitatii de codificare se poate decide în functie de: - marimea si complexitatea continutului bazei informationale de intrare; - tipurile de atribute existente în baza informationala de intrare si masura în care codificarea acestora conduce la performante în prelucrare si economie de suport tehnic;

- complexitatea structurii sistemului informatic; - specificul operatiilor de prelucrare a colectiilor de date;

- solutia celui mai eficient sistem de coduri care sa permita codificarea si interpretarea facila a atributelor de catre factorul uman; - costul stabilirii si validarii sistemelor de coduri, a decodificarii atributelor din baza informationala a elaborarii, actualizarii si întretinerii nomenclatoarelor de coduri; - eforturi de adaptare a personalului din unitatea beneficiara la cerintele utilizarii sistemelor de coduri. Din punct de vedere al modului de realizare, codificarea poate fi: - cu pregatire prealabila; - fara pregatire prealabila.

Codificarea cu pregatire prealabila solicita o analiza a ansamblului atributelor de codificat care sa preceada codificarea propriu-zisa si sa evalueze exact volumul atributelor, ierarhizate si gama de valori posibile. Codificarea fara pregatire prealabila se realizeaza prin atribuirea de coduri pe masura aparitiei de noi valori pentru atributele introduse in sistem. Singura analiza necesara în acest caz consta în determinarea volumului maxim de atribute pentru a stabili lungimea si limitele codului.

Atribuirea codurilor poate fi realizata manual sau automat. Codificarea manuala este utilizata pentru orice tip de cod, în timp ce codificarea automata se aplica numai, la codurile simple pentru care se poate defini, un algoritm de atribuire programabil pe calculator. De asemenea, aceasta modalitate de codificare solicita standardizarea denumirii atributelor codificate si eventual redactarea unor programe sau rutine de recunoastere. Codificarea automata ofera în comparatie cu cea manuala o serie de avantaje automate a caracterului de control si cresterea preciziei în elaborarea nomenclatoarelor de coduri. c)c) Fazele realizarii codificarii Fazele realizarii codificarii

Fazele realizarii codificarii sunt dependente de specificul sistemului informatic, marimea unitatii economice, dimensiunea bazei informationale de intrare si tipologia codurilor utilizate, elemente care presupun abordarea codificarii în urmatoarea succesiune:

- pregatirea activitatilor de codificare; - codificarea atributelor bazei informationale de intrare; - întocmirea nomenclatoarelor de coduri; - întretinerea codurilor.

1. Pregatirea activitatilor de codificare presupune analizarea continutului si structurii bazei informationale de intrare ce urmeaza a fi codificata si examinarea codurilor existente, inclusiv masura în care acestea satisfac cerintele sistemului informatic. De asemenea, se stabileste esalonarea în timp a codificarii, modul de realizare si de control si se opteaza pentru o codificare cu sau fara pregatire prealabila, manuala sau automata. Stabilirea necesitatilor de codificare este dependenta de volumul atributelor supuse codificarii, tipul de cod utilizat, precum si de modul de realizare a acestuia. Astfel, în cazul unei codificari fara pregatire prealabila, activitatea se reduce la o analiza sumara a volumului atributelor. Daca se opteaza pentru codificarea cu pregatire prealabila este necesara ordonarea atributelor de codificat, analiza particularitatilor continutului bazei informationale de intrare si alegerea codului.

Ordonarea atributelor bazei informationale de intrare ce urmeaza a se codifica, presupune clasificarea atributelor pe nivele ierarhice in scopul definirii grupelor/claselor de codificare, inclusiv reguli de introducere a acestora în baza informationala de intrare. in fiecare grupa/clasa se vor stabili caracteristicile specifice si valorile posibile ale acestora. Analiza particularitatilor continutului bazei informationale de intrare, urmareste evaluarea dimensiunii actuale a multimii atributelor de codificat, precum si estimarea evolutiei ulterioare. Pentru aceasta este necesar sa se precizeze responsabilitatile de gestionare a bazei informationale de intrare, modul de utilizare concreta a codurilor în documentele de intrare, frecventa de utilizare, precum si modul de acomodare a utilizatorului cu sistemul de coduri propus. Toate aceste particularitati trebuie sa fie în corelatie cu strategiile de memorare si acces ale colectiilor de date asociate bazei informationale de intrare. Alegerea codului se va face in functie de dimensiunea , si particularitatile bazei informationate de intrare, natura, complexitatea si valorile atributelor, metoda de introducere si validare a codurilor, cerintele si restrictiile sistemului informatic proiectat, metoda de codificare, costul si timpul de realizare a activitatii de codificareDimensiunile si particularitatile bazei informationale de intrare determina alegerea tipurilor de coduri care sa reflecte în mod unitar continutul acesteia. Dimensiunea bazei informationale are implicatii asupra lungimii codurilor utilizate, în timp ce particularitatile acesteia influenteaza tipologia codurilor folosite. În situatia în care o baza, informationala de intrare contine atribute caracterizate printr-o subordonare a acestora, este indicat a se folosi codurile ierarhice, iar în

situatia în care atributele vor fi prelucrate în functie de mai multe criterii, atunci sunt utilizate codurile juxtapuse. Natura, complexitatea si valorile reale ale atributelor impun utilizarea unor coduri care pot servi la identificarea unica a acestora, inclusiv o buna conversie a naturii, complexitatii si valorilor reale ale atributelor. În asemenea situatii se recomanda utilizarea codurilor de tip secvential. Daca între atributele bazei informationale de intrare exista relatii de subordonare, atunci se poate opta pentru utilizarea codurilor ierarhizate. in alternativa în care se pot defini diverse proprietati ale atributelor, atunci este oportuna utilizarea codurilor juxtapuse. In situatia realizarii de sisteme informatice în domeniul bancar sau al serviciilor este indicata utilizarea codurilor cu semnificatia mnemonica sau descriptiva, deoarece este posibila o utilizare facila a acestora.

Cerintele si restrictiile sistemului informatic proiectat reprezinta factorii de baza in alegerea codului, deoarece activitatea de codificare este subordonata functionalitatii noului sistem. Din acest punct de vedere trebuie examinate în primul rand cerintele informationale pe nivele ierarhice, deoarece acestea determina aria de utilizare a codului si gradul sau de generalitate. În cazul în care sistemul este realizat pentru diverse nivele ierarhice (unitate, subunitate etc.), codul trebuie sa asigure relatiile existente în ambele sensuri. Metoda de codificare are în vedere realizarea codificarii cu sau fara pregatire prealabila, în mod manual sau automat. Codificarea fara pregatire prealabila prezinta avantajul realizarii acesteia cu un cost minim si într-un timp scurt, prin folosirea codurilor secventiale sau secventiale pe grupe, în timp ce codificarea cu pregatire prealabila utilizeaza coduri descriptive care solicita costuri si timp de realizare mai mari.

Costul si timpul de realizare a activitatii de codificare implica alegerea unor tipuri de coduri care necesita cheltuieli minime si un timp redus de realizare a nomenclatoarelor de coduri. in aceste conditii se recomanda utilizarea metodei de codificare automata cu pregatire prealabila, deoarece asigura costuri minime si perioade reduse de codificare. Pe baza cerintelor prezentate, se alege tipul de cod adecvat si se stabileste structura sa în functie de volumul atributelor, evolutia acestora si numarul total de caractere necesare codificarii fiecarui atribut. Alegerea trebuie sa se faca în corelatie cu celelalte coduri folosite si cu caracteristicile întregii baze informationale pentru a realiza o uniformitate a codurilor. De asemenea, trebuie examinata posibilitatea preluarii unor sisteme de codificare existente, deoarece se realizeaza scurtarea perioadei de implementare si experimentare a sistemului , informatic proiectat.

3. 2. Codificarea atributelor bazei informationale de intrare Consta în stabilirea codurilor corespunzatoare pentru fiecare atribut din nucleul informational. Pentru aceasta se elaboreaza un nomenclator al valorilor atributelor pe grupe omogene, cu precizarea particularitatilor si valorilor posibile ale acestora. De asemenea, se va întocmi si un nomenclator al tuturor codurilor posibile cu caracterele de control determinate. Pentru realizarea codificarii atributelor bazei informationale de intrare la nivelul unei unitati economice se vor avea în vedere, în principiu, urmatoarele tipuri de atribute : codurile sintetice si analitice din structura planului de conturi, cu dezvoltarea pe trepte a acestora, în functie de specificul activitatii si nevoile de informare operativa, prin folosirea unui cod ierarhizat cu urmatoarea structura:

Cont sinteticCont sintetic

999 99999 99 999999 9 999999 9

codificarea materialelor, produselor sau reperelor se va face prin intermediul unui cod ierarhizat, care sa permita atat identificarea variantelor tipologice de materiale sau produse, inclusiv stabilirea unei ierarhizari impusa de prelucrarile operative. În stabilirea ierarhizarii codului pe nivele trebuie sa se tina seama si de cerintele de detaliere ale caracteristicilor tehnologice pentru materiale, produse si repere, prin folosirea unui cod ierarhizat cu urmatorea structura

codificarea compartimentelor, presupune atribuirea de coduri pentru magazii si gestiuni, precum si coduri pentru sectii, ateliere si formatii de lucru prin utilizarea unor coduri ierarhice cu urmatoarea structura : codificarea salariatilorcodificarea salariatilor se poate realiza printr-un cod secvential de 4-5 cifre a carui lungime se poate realiza printr-un cod secvential de 4-5 cifre a carui lungime concreta este determinata de numarul mediu scriptic al salariatilor din unitate. Se recomanda ca concreta este determinata de numarul mediu scriptic al salariatilor din unitate. Se recomanda ca acest cod sa nu contina si elemente privitoare la specialitate, gradatie sau clasa de incadrare, acest cod sa nu contina si elemente privitoare la specialitate, gradatie sau clasa de incadrare, deoarece acestea sunt variabile în timp, în comparatie cu marca care ramane neschimbata pe toatadeoarece acestea sunt variabile în timp, în comparatie cu marca care ramane neschimbata pe toata durata de activitate. De asemenea, se recomanda ca marea persoanei sa nu constituie o treapta durata de activitate. De asemenea, se recomanda ca marea persoanei sa nu constituie o treapta suplimentara la codurile pentru sectii, ateliere si formatii de lucru, deoarece exista posibilitatea suplimentara la codurile pentru sectii, ateliere si formatii de lucru, deoarece exista posibilitatea transferarii personalului muncitor de la o structura organizatorica la alta, ceea ce va impune transferarii personalului muncitor de la o structura organizatorica la alta, ceea ce va impune operatii de recodificareoperatii de recodificarecodificarea clientilor si furnizorilor se realizeaza prin intermediul codului ierarhizat, care sa contina trepte referitoare la tipul acestuia (intern sau extern), locul de desfasurare a activitatii (tara sau judetul), felul unitatii economice (regie autonoma, societate comerciala), numarul de ordine.

Cont analitic de gradul 1Cont analitic de gradul 1

Cont analitic de gradul 2Cont analitic de gradul 2

Cifra de controlCifra de control

- clasificarea - clasificarea generalagenerala

- clasificarea - clasificarea detaliatadetaliata

- materia prima utilizate- materia prima utilizate

- destina]ia de consum- destina]ia de consum

- tehnologia de fabricaţie- tehnologia de fabricaţie

- codul analitic - codul analitic material/produsmaterial/produs - caracter de control- caracter de control

- grupe generale de - grupe generale de produse / produse / materialemateriale

999 999 9 9 9 9 9 9 999999 9 999999 9

codificarea unitatilor de masura se va realiza pe baza unui cod secvential sau o semnificatie mnemonica, ales astfel încat sa serveasca cat mai bine cerintelor, de prelucrare automata si de informare a unitatii beneficiare; codificarea operatiilor tehnologice se realizeaza prin intermediul unui cod secvential, pe grupe cu urmatoarea structura:

3.3. Întocmirea nomenclatoarelor de coduri Consta în elaborarea unor liste în care sunt precizate codurile si denumirea completa a atributelor la care acestea se refera. Pentru a facilita utilizarea nomenclatoarelor, se recomanda ca acestea sa fie sortate dupa codul sau denumirea atributelor. Un nomenclator de coduri va contine denumirea completa a atributelor, codul asociat, caracterul de control precum si alte informatii reteritoare la pretul unitar, unitate de masura, inclusiv trimiteri la alte clasificari sau instructiuni de completare. 3.4. Întretinerea codurilor Consta în efectuarea adaugarii sau stergerii de atribute în vederea actualizarii nomenclatoarelor de coduri, motiv pentru care este recomandabil ca această activitate sa fie efectuata de aceeasi echipa care a conceput si realizat codificarea. Nomenclatoarele de coduri se recomanda sa fie revizuite periodic pentru a elimina ambiguitatile si redondantele prin stergerea valorii atributelor care nu mai prezinta interes. De asemenea, nomenclatoarele de coduri vor fi actualizate atunci cand criteriile de utilizare a atributiilor se schimba, aria de cuprindere a sistemului proiectat se extinde, cand apar modificari în cadrul legislativ-normativ, etc.

4. Adaptarea documetelor primare la cerintele sistemului informatic (se identifică în MGD şi se aprofundează în MCDD)

Adaptarea documentelor primare la cerintele sistemului informatic este o faza importanta în cadrul proiectarii, deoarece în documente se consemneaza starea si dinamica fenomenelor si proceselor economice desfasurate în unitatea economica si reflectate prin intermediul sistemului informatic. Datele consemnate în documentele de intrare sunt introduse în sistemul informatic prin intermediul tranzactiilor externe efectuate asupra colectiilor de date organizate baze de date. Obiectivul principal al acestei faze îl constituie formalizarea documentelor din punct de vedere al continutului si al formei, în asa fel încat acestea sa raspunda exigentelor specifice sistemului informatic in concordanta cu cerintele concrete ale beneficiarului.

Operatie Operatie tehnologicatehnologica

Faze Faze tehnologicetehnologice

Caracter de Caracter de controlcontrol

9 9 99 999 9

Adaptarea documentelor primare la cerintele unui sistem informatic presupune: - scopul adaptarii documentelor de intrare; - tipuri de documente primare utilizate; - modificarile de continut si format ale documentelor primare.

Scopul adaptarii documentelor primare: - consemnarea fenomenelor si proceselor economice desfasurate in unitatea economica, în momentul si la locul producerii acestora (compartimentele functionale); - utilizarea codurilor proiectate pentru sistemul informatic in structura informationala a documentelor primare, în vederea transpunerii exacte si corecte a acestora în colectiile de date ce vor surprinde dinamica valorii atributelor; - caracterizarea dinamica a operatiilor economice desfasurate în unitatea beneficiara pentru crearea initiala si actualizarea periodica a colectiilor de date; - reflectarea în componentele sistemului informatic (subsisteme, aplicatii etc.), a naturii activitatii compartimentelor functionale prin intermediul datelor consemnate în documentele de intrare. - simplificarea si perfectionarea sistemului de evidenta prin utilizarea unui numar minim de documente de intrare, în care sa se surprinda într-o forma sintetizata starea si dinarnica utilizarii patrimoniului, în paralel cu gestiunea unor colectii de date, capabil sa reflecte dinamic aceste fenomene

Tipuri de documente de intrare. Documentele de intrare în care se consemneaza starea si dinamica fenomenelor si

proceselor economice pot fi structurate în functie de: - sfera; - frecventa de utilizare; - regimul de gestionare; - tipurile tranzactiiior externe; - formatul de prezentare, etc.

a) Sfera de utlizare a documentelor primare permite gruparea acestora în doua categorii: - documentele primare comune, folosite pentru înregistrarea datelor privind procesele tehnico-economice din activitati desfasurate in toate tipurile de unitati economice, indiferent de domeniul de activitate (ex.: Nota de Contabilitate); - documente de intrare specifice, folosite pentru înregistrarea datelor ce caracterizeaza anzumite procese tehnico-economice desfasurate în cadrul unor ramuri sau subramuri (exemplu: Extrasul de cont). b) Frecventa de utilizare si ponderea informatiior fixe continute în documentele de intrare permit gruparea acestora în doua categorii: - tiparite, caracterizate printr-o utilizare generala la nivelul tuturor unitatilor economice, ceea ce justifica din punct de vedere economic multiplicarea lor (ex.: factura fiscala). - netiparite caracterizate printr-o utilizare speciala numai la nivelul unor anumite unitati economice.c) Regimul de gestionare al documentelor impune gruparea acestora în doua categorii: - cu regim uzual sunt caracterizate, printr-o folosire si o evidenta similara cu cele tiparite în vederea utilizarii generale, fara restrictii exprese din punct de vedere legal.

- cu regim special, a caror gestionare, folosire si evidenta sunt impuse de reglementarile în vigoare, cu precizarea ca în continutul lor este tiparita mentiunea "Regim special"

(ex.: formularul cu codul 14-3-1 "Chitanta Fiscala“).

d) Tipul tranzactiilor externe asigura gruparea documentelor în doua categorii: - documente care redau starea initiala a fenomenelor si proceselor economice, prin care se asigura cuantificarea elementelor patrimoniale ale unitatii economice în momentul lansarii în executie a sistemului informatic; - documente care reflecta dinamica fenomenelor, si proceselor economice ce modifica elementele patrimoniale într-o anumita perioada de gestiune.

Documentele primare din prima categorie permit constituirea initiala a colectiilor de date în momentul lansarii în functiune a noului sistem informatic. Aceste documente surprind starea initiala a fenomenelor si proceselor economice prin intermediul valorii reale ale atributelor cu caracter conventional constant, inregistrate prin intermediul nomenclatoarelor (produse, materiale, clienti, furnizori, conturi, mijloace fixe, obiecte de inventar), cat si starea initiala a fenomenelor si proceselor economice supuse prelucrarii automate (exemplu: “Lista de inventar”). e) Formatul de prezentare a documentelor permite gruparea acestora in trei categorii: - documentele individuale asigura redarea denumirii si valorii atributelor prin amplasarea acestora pe întreaga suprafata in functie de suecesiunea logica a operatiei economice rezultate (ex.: chitanta, fisa personala a salariatului fisa mijlocului fix etc.); - documentele comune reflecta denumirile si valorile atributelor prin ordonarea acestora sub forma de tabel în cadrul caruia succesiunea atributelor este determinata de relatiile de apartenenta si incluziune dintre multimile specifice ale atributelor (ex.: Nomenclatoare de produse, clienti, materiale, obiecte de inventar etc.); - documente mixte, permit ordonarea numelui si valorii atributelor atat în format individual cat si în format comun, pentru a furniza intr-o forma eficienta, dispunerea atributelor în structura documentului de intrare (ex.: Bon de consum. Aviz de expeditie/Dispozitie de livrare, Factura fiscala etc.).

Documentele primare prezentate constiuie sursa principala a tranzactiilor externe utilizate într-un sistem informatic pentru gestiunea colectiilor de date, cat si sursa secundara pentru generarea tranzactiilor interne in cadrul nucleului sistemului informatic.

Astfel, utilizarea acestor doua categorii de documente trebuie sa asigure adaugarea de noi atribute ca urmare a operatiilor economice care reflecta miscarea elementelor patrimoniale, inserarea de noi atribute în scopul evidentierii noilor operatii economice, modificarea si stergerea de atribute impuse de dinamica elementelor patrimoniale, precum si necesitatea punerii de acord a colectiilor de date cu realitatea economica din unitatea beneficiara.

Documentele primare dostinate creerii si actualizarii colectiilor de date, în conditiile în care nu corespund integral din punct de vedere al cotinutului si al formei cu restrictiile impuse de sistemul proiectat si structura bazei de date de intrare, vor fi modificate in vederea realizarii acestor deziderate.

Modificarile de continut vizeaza: - adaugarea în documente a rubricilor pentru coduiri în masura in care acestea nu

sunt deja prevazute. in acest sens se va insista codurilor ce specifica natura operatiilor reflectate si a celor care servesc pentru identificarea si asocierea calectiilor de date (cod material, cod produs, marca, cod sectie, cod comanda etc.);

- eliminarea atributelor ce se obtin prin calcule (ex. valoarea); - regruparea si modificarea rubricilor aferente atributelor ce vor contine date care sa se

introduca în sistemul informatic în asa fel încat acesta sa se gaseasca in acelasi loc in toate documentele. Cu alte cuvinte, se pastreaza individualitatea fiecarui tip de document, dar se defineste o zona comuna identica pentru toate documentele din care se vor prelua datele pe suporturile tehnice. Modificările de format sunt impuse de necesitatea cresterii facilitatilor de preluare directa a datelor prin intermediul videoterminalelor si vizeaza urmatoarele aspecte

- gruparea în cadrul documentului a tuturor atributelor care urmeaza a fi introduse de la videoterminal, în asa fel încat rubricile corespunzatoare sa nu fie dispersate pe întreaga suprafata a documentului;

- evitarea intercalarii atributelor ce se preiau în colectiile de date cu atributele care au caracter constant sau rezulta din calcul.

- evidentierea în cadrul documentului a numarului maxim de caractere speciflcate pentru fiecare atribut, inclusiv precizarea pozitiei punctului zecimal;

- ordinea atributelor în cadrul documentelor trebuie sa asigure prezenta. atributelor de identificare, urmate de cele informative si terminand cu cele cantitativ-valorice; - evidentierea zonelor care contin atribute ce se preiau în colectiile de date, prin demarcarea cu linii mai groase sau de culori diferite etc. Ex.: din documentul primar “Bon de consum” nu se vor prelua atributele constante “pretul unitar” si “unitatea de masura”, inclusiv atributul rezultat din calcul “valoarea aferenta iesirilor” desi ele sunt consemnate în document pentru efectuarea controlului gestionar;

Toate modificarile si adaptarile enuntate se fac în asa fel încat documentele primare sa satisfaca în totalitate atat cerintele de evidenta, cat si cele de prelucrare automata a datelor, cu mentiunea ca rezultatele acestor modificari sunt supuse spre aprobarea organelor de conducere ale unitatii economice beneficiare sau a organelor centrale de sinteza.

Alaturi de definitivarea continutului si formatului se impune si stabilirea regulilor de completare si utilizare a documentelor primare, precizarea numarului de exemplare si a circuitului fiecarui exemplar, stabilirea frecventei si termenelor de introducere a datelor în colectiile de date. De asemenea, se precizeaza responsabilitatile pentru completare si verificare, vizele sau semnaturile care valideaza continutul documentelor primare, inclusiv persoanele împuternicite în acest sens. Aceste specificatii sunt folosite pentru proiectarea noilor circuite informationale în noul sistem, cat, si în manualul de utilizare definitivat în etapa de implementare.

Bibliografie

1. Dumitru Oprea, “Analiza şi proiectarea sistemelor informaţionale economice”, editura Polirom, Iaşi, 1999.

2. Nicolae Dumitru Davidescu, "Sisteme informatice financiar - bancare", Editura All Beck, Bucureşti, 1998.

3. Dorin Zaharie şi Ioan Roşca, “Proiectarea obiectuală a sistemelor informatice”, EdituraDual Tech, Bucureşti, 2002.

4. ITteam-SSADM-Core-Techniques-eBook, “SSDAM Core Techniques”, www.itteam-direct.com

Obiectivele

1. Structura de principiu a sistemului informatic al intreprinderiiSistemul informatic al intreprinderii cuprinde:- sistemul de producţie;- sistemul comercial;- sistemul de resurse umane;- sistemul tehnic.

Obiectivele sistemului informatic

Generale Specifice

de conducere (manageriale)

funcţionale

Activitatea comercială

Activitatea financiar-contabilă

Activitatea de personal

Subactivitatea de aprovizionare tehnico-materială

Subactivitatea de desfacere

Subactivitatea Subactivitatea de marketingde marketing

Subactivitatea financiară

Subactivitatea de contabilitate:- financiară- de gestiune

Subactivitatea de control financiar

Subactivitatea de evidenţă a personalului

Subactivitatea de salarizare

Subactivitatea de perfecţionare a calificării personalului

activităţii de bază

activităţii auxiliare

Structura sistemului informatic

Componentele funcţionale

Componenta pentru managementul strategic

Componenta pentru managementul financiar

Componenta pentru managementul contabil

Componenta pentru managementul comercial

Componenta pentru managementul resurselor umane

Componenta pentru managementul cercetării-dezvoltării

Componentele sistemelor informatice

Componentele speciale

Administrare

Componente interne ale sistemului informatic

Managementul protecţiei şi securităţii informaţiei

Componenta de sistem bazat pe cunoştinţe

Sistem expert

Componenta managementului cu funcţionare în timp real

Componenta pentru managementul activităţilor prin intermediul costurilor(managementul costurilor)

Componenta pentru managementul activităţilor prin intermediul proiectelor(managementul proiectelor)

Evidenţa personalului Salarizare

Aproviz. cu materii prime şi materiale

Aproviz. cumărfuri de la furnizori

Contractare, livrare produse şiîncasare facturi

Gestiune stocuri de materiale

Gestiune stocuri de mărfuri

Gestiune stocuri de prod. finite

Gestiunea mijl. fixe

Activitate financiară

Contabilitate Financiară(sintetică)

Contabilitate de gestiune(analitică)

Marketing

Evidenţa preg. personal

Componenta pentru managementul documentelor şi realizareaarhivei de documente

Date post:	26-Dec-2015
Category:	Documents
Upload:	iura1999
View:	72 times
Download:	1 times

Sisteme informatice integrate.doc

Documents