Analiza sistemului existent si definirea cerintelor noului sistem

In cadrul acestui capitol este prezentata prima etapa a ciclului de viata al sistemelor informatice, etapa prin care se determina modul in care functioneaza sistemul informational curent si se evalueaza ceea ce ar dori utilizatorii sa realizeze noul system .Astfel, sunt prezentate o serie de aspecte privind:

determinarea cerintelor sistemului;

metodele traditionale utilizate in analiza si determinarea cerintelor sistemulu (interviul si chestionarul);

metode moderne de analiza si determinare a cerintelor sistemului (JAD, prototipizarea);

structurarea cerintelor sistemului - modelarea logica a datelor si prelucrarilor (diagramele fluxurilor de date DFD);

modelarea conceptuala a datelor (diagramele entitate - relatie, D ER).

1. Studiul sistemului informational existent

Prin sistem existent se intelege realitatea obiectiva din organizatia pentru care urmeaza a se realiza sistemul informatic solicitat printr-o comanda numita cererea beneficiarului.

Analiza sistemului existent si definirea cerintelor noului sistem este prima etapa din ciclul de viata al dezvoltarii sistemelor informatice, etapa prin care se determina modul in care functioneaza sistemul informational curent si se evalueaza ceea ce ar dori utilizatorii sa realizeze noul sistem. Studiul si analiza sistemului existent are ca obiectiv principal stabilirea cerintelor informationale ale conducerii in vederea realizarii unui sistem informatic.

Studiul sistemului existent cuprinde un grup de activitati care urmaresc cunoasterea performantelor tehnico-functionale ale sistemului informational, atat in ansamblul sau, cat si pentru elementele de structura ale acestuia, a cerintelor informationale ale conducerii, cunoasterea lipsurilor si restrictiilor pe care le prezinta sistemul existent fata de aceste cerinte. De modul de realizare a acestor activitati depinde intregul proces de realizare a sistemului informatic [2].

Studiul sistemului existent consta in [2]:

definirea caracteristicilor generale ale sistemului economic;

studiul activitatilor de baza desfasurate in sistem;

studiul sistemului de conducere;

studiul sistemului informational;

identificarea metodelor si mijloacelor tehnice.

Definirea caracteristicilor generale ale sistemului economic implica :

cunoasterea profilului, obiectivelor agentului economic;

cunoasterea locului in sfera serviciilor si sfera productiei;

cunoasterea relatiilor de cooperare cu alti agenti economici;

cunoasterea specificului activitatii de baza ( productie, servicii);

cunoasterea nivelului tehnic;

cunoasterea principalilor indicatori economici si evolutia lor;

dezvoltarea, modernizarea etc.

Studiul activitatilor desfasurate in sistemul economic, modul de realizare a functiunilor unitatii economice se face prin [2]

1. Pe baza statutului de functionare a societatii se studiaza:

activitatile si sarcinile din cadrul acestor functiuni;

atributiile ce revin compartimentelor;

modul de realizare a activitatilor functionale din cadrul unitatii economice.

2, In cazul activitatii de productie se prezinta:

fluxul de productie, amplasarea locurilor de munca, depozitelor etc.;

tipurile de produse, structura lor, ciclurile de realizare;

modul de organizare a productiei, stocarea productiei, transporturile interne, controlul de calitate;

resursele existente:

capacitati;

asigurarea tehnica / proiectarea de produse noi;

norme tehnice;

asigurarea cu materiale necesare;

sistemul existent de programare a productiei.

Studiul sistemului de conducere se refera la [2]

identificarea caracteristicilor sistemului de conducere existent;

sistemul de indicatori cantitativi si valorici;

organizarea conducerii;

caracteristicile rezultate din statutul de functionare a societatii, tipuri de decizii, modul de lucru a deciziilor.

Studiul sistemului informational presupune

elaborarea schemei fluxului informational global (cu punerea in evidenta a principalelor activitati si a legaturilor statice si dinamice dintre acestea);

estimarea cantitativa si calitativa a informatiilor de intrare-iesire, modul de culegere si prelucrare;

identificarea principalilor algoritmi, regulilor de calcul si a punctelor si regulilor de control;

cunoasterea principalelor restrictii ale sistemului informational;

situatia rationalizarii fluxurilor si a documentelor din unitatea economica, studii elaborate, stadiul lor de implementare;

sistemul de codificare utilizat, restrictii;

performantele si limitele sistemului informational existent.

Identificarea metodelor si mijloacelor tehnice utilizate pentru prelucrarea datelor in cadrul sistemului informational existent se face evidentiind: mijloacele tehnice existente in dotarea unitatii economice ( modul de utilizare, cheltuielile de exploatare, personalul implicat, performante); existenta unor aplicatii proiectate si/sau implementate [2].

2. Determinarea cerintelor sistemului

Determinarea cerintelor sistemului este activitate esentiala in aflarea situatiei existente si a ceea ce se doreste in viitor. Rezultatul activitatii de determinare a cerintelor sistemului se concretizeaza in diferite forme ale informatiilor colectate, cum sunt copii ale interviurilor, insemnari efectuate in timpul observarii si analizei documentelor, interpretari ale raspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru s.a., precum si rezultate ale prelucrarilor efectuate de calculator, cum ar fi prototipurile [1].

Rezultatele prezentate dupa aceasta activitate pot fi rezumate astfel:

Informatii obtinute in urma conversatiilor cu utilizatorii sau prin observarea activitatilor prestate de acestia: copii sau sinteze ale interviurilor, raspunsurile la chestionare sau interpretari ale acestora, insemnari si rezultate din observarea activitatilor, procese verbale ale sedintelor ce au avut loc in acest scop;

Informatii scrise care exista in unitate: misiunea si strategia afacerii, exemplare ale formularelor, rapoartelor si machetelor de ecrane, manuale ale procedurilor, descrieri ale posturilor de lucru, manuale de instruire, scheme de sisteme si documentatia sistemului existent, rapoartele consultantilor [1];

Informatii obtinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii ale fisierelor sesiunilor grupului de sprijinire a sistemului, continutul depozitelor si rapoartele existente in CASE, ecrane si rapoarte rezultate din prototipurile sistemului, s.a [1].

2.1. Metodele traditionale utilizate in analiza si determinarea cerintelor sistemului

Analiza sistemului informational-decizional fiind, in general, axata pe sistemul obiect, metodele utilizate sunt in general comune cu cele ale analizei economice

Metodele utilizate frecvent in analiza sistemului existent sunt:

Interviul;

Chestionarul.

Interviul este o metoda foarte raspandita pentru culegerea informatiilor din sistemul informational. Utilizatorii acestei metode sunt in general analistii care nu sunt familiarizati cu unitatea studiata si cu problemele ei. Prezinta avantajul ca lasa foarte multa libertate creativa analistului in construirea si desfasurarea lui [2]. In alegerea persoanelor de intervievat trebuie avute in vedere urmatoarele constatari [10]:

persoanele care ocupa pozitii medii in ierarhia structurii organizatorice furnizeaza informatiile cele mai apropiate de realitate;

colectarea de informatii corecte necesita intervievarea atat a personalului de conducere, cat si a celui de executie;

in prealabil trebuie verificata competenta subiectilor intervievati;

lipsa unei atitudini critice poate sa denote retineri in exprimarea ideilor.

Se vor efectua interviuri la nivelul conducerii si interviuri la nivelul posturilor de lucru.

Rezultatul interviului este consemnat in raportul de interviu care trebuie semnat de catre persoanele intervievate.

Chestionarul poate fi utilizat atat de catre analistii incepatori, cat si de catre cei avansati, familiarizati sau nu cu problemele informationale-decizionale ale unitatii. Prin utilizarea lui dispare "filtrul de informatii" care este analistul iar cel care furnizeaza informatii are posibilitatea sa se concentreze mai bine asupra raspunsurilor. Utilizand aceasta metoda, participa un numar mare de "furnizori de informatii". Limitele chestionarului constau in faptul ca este o metoda de verificare a unor cunostinte prealabile, fapt ce implica cunoasterea prealabila a domeniului.

Aceasta metoda necesita timp relativ indelungat pentru intocmirea chestionarului precum si de culegere si prelucrare a raspunsurilor. Chestionarul nu are o arie larga de utilizare [2].

2.2. Metode moderne de analiza si determinare a cerintelor sistemului

Ca efect al tendintelor de marire a timpului de analiza a sistemelor existente, in ultimii ani, s-a efectuat trecerea spre analiza mai putin pronuntata a sistemelor ce urmeaza a se realiza. Tehnicile moderne, JAD si prototipizarea, preiau tot mai putine elemente din sistemele existente, ca urmare a analizei efectuate. Altele mai radicale renunta aproape total la analiza sistemului existent, este cazul proceselor controlate prin RAD, care apeleaza la JAD, prototipizare si alte instrumente de tip CASE [1].

Joint Application Design(JAD)

Spre sfarsitul anilor 1970, specialistii in realizarea de sisteme de la IBM au elaborat un nou proces de culegere a cerintelor informationale ale sistemelor si de revizuire a proiectelor sistemelor, numindu-se JAD [1].

Ideea principala a lui JAD o constituie punerea laolalta a tuturor fortelor interesate in dezvoltarea sistemelor: utilizatori-cheie, managerii si analistii de sistem implicati in analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel de grup. Totusi in sesiunea JAD se urmareste o anumita secventa de derulare a activitatilor, pe baza unor roluri bine stabilite.

Prototipizarea si determinarea cerintelor sistemelor

Prototipizarea este un proces interactiv prin care analistii si utilizatorii pun in discutie o versiune rudimentara a unui sistem informational, care va fi intr-o continua schimbare, in functie de reactia utilizatorilor. Prototipizarea renunta la ciclul de viata al dezvoltarii sistemelor sau la cresterea rolului sau [1].

Pentru culegerea informatiilor despre cerintele utilizatorilor inca se apeleaza la interviuri, dar prin prototipizare, operatiunea va fi mai simpla si va solicita un timp mai scurt. Prototipul este vazut si testat de utilizator, avand posibilitatea sa precizeze ce ar mai dori, dar si sa-si genereze aceasta forma noua, cu ajutorul specialistilor [1].

Prototipizarea este facilitata de cateva limbaje sau produse program, inclusiv instrumentele de tip CASE.

Prototipizarea este foarte utila in determinarea cerintelor sistemului cand [1]:

cerintele utilizatorului nu sunt prea clar formulate sau bine intelese;

unul sau mai multi utilizatori sau sustinatori sunt implicati in sistem;

anumite mijloace de lucru (formulare si rapoarte predefinite).

Prototipizarea genereaza si deficiente, cum ar fi:

tendinta de evitare a unui cadru formal de elaborare a documentatiei privind cerintele sistemului, ceea ce va ingreuna in viitor orice control;

fiind conceput de un numar mic de utilizatori va fi probabil respins de viitorii utilizatori;

fiind conceput izolat este putin probabil ca el sa fie integrat in sistemul existent;

nerespectandu-se etapele ciclului de viata al dezvoltarii sistemelor pot fi omise aspecte esentiale, cum ar fi securitatea, controlul datelor introduse si standardizarea la nivel de sistem.

Pasii prototipizarii sunt [1]

Identificarea cerintelor principale ale sistemului;

Realizarea prototipului initial;

Proces iterativ de adaptare a sistemului la cerintele utilizatorului;

Folosirea sistemului aprobat de utilizatori.

Dupa determinarea cerintelor sistemului urmeaza structurarea acestora prin utilizarea unor instrumente specifice de modelare logica.

Structurarea cerintelor sistemului - modelarea logica a datelor si prelucrarilor

Indiferent de metodologiile folosite in realizarea unui sistem/aplicatie, toate apeleaza la operatiunea de modelare logica a datelor si prelucrarilor sub forma de diagrame, diferentele constand doar in folosirea mai pronuntata a diagramelor pentru descrierea sistemului, incadrandu-le in diagrame de context, diagrame ale fluxurilor de date fizice si diagrame ale fluxului de date logice. Altele apeleaza la combinatii de diagrame, tabele si forme descriptive [1]

Diagrama de context scoate in evidenta aria de intindere a sistemului analizat, prin specificarea elementelor din interiorul organizatiei si a celor externe, sub denumirea de entitati externe sistemului analizat.

1. Diagramele fluxurilor de date (DFD)

Diagrama fluxului de date ale nivelului logic curent, independenta de tehnologie, reliefeaza functiile de prelucrare a datelor executate de catre sistemul informational curent.

Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor, structura lor si cerintele functionale ale noului sistem.

Descrieri ale obiectelor DFD se regasesc in asa-zisele dictionare ale proiectelor sau depozitele CASE (repository) [1].

Diagramele fluxului de date DFD au ca obiectiv urmarirea modului de transfer al datelor intre procesele de prelucrare a lor, astfel de diagrame se mai numesc si modele ale proceselor de prelucrare, iar operatiunea se numeste modelarea proceselor.

DFD reprezinta doar una din tehnicile de analiza structurata.

Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de date a capatat noi acceptiuni prin incorporarea ei in instrumentele de analiza si proiectare cu ajutorul calculatorului, adica in instrumente CASE [1].

Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru            construirea DFD

Cand analizam sistemele folosim frecvent reprezentarile grafice, de exemplu diagramele. In continuare vom folosi tehnica reprezentarii grafice a fluxului informational. Proiectarea fluxului informational reprezinta circulatia informatiei in sistem, transformarile suferite de acesta, stocarea informatiei precum si scurgerile de informatie in afara sistemului.

Scopul diagramelor de date DFD pentru o anumita componenta organizatorica sau functionala la care se refera (sectie, birou, compartiment, intreaga unitate, o anumita activitate - vanzari, cumparari, incasari, plati, s.a) este de a scoate in relief, intr-o maniera cat mai sugestiva, urmatoarele aspecte [1]:

sursa datelor de prelucrare;

operatiunile de prelucrare prin care trec datele;

destinatia datelor prelucrate;

legatura existenta intre prelucrari si activitatea de stocare a datelor.

Intocmirea diagramelor de flux de date (DFD)

DFD este o reprezentare grafica a transformarii datelor de intrare in date de iesire
folosind un set de simboluri de reprezentare si un set de reguli de completare si validare.

Simboluri folosite in diagramele realizate cu SSADM

Conventii folosite in diagramele de reprezentare a DFD:

procesele si stocurile de date sunt numerotate secvential, pentru a putea fi identificate. Numerele asociate proceselor nu semnifica ordinea de executie a acestora;

pentru a evita fluxurile de date intretaiate si aspectul de "paienjenis" al diagramei, entitatile externe si stocurile de date pot fi duplicate. O entitate externa duplicata se reprezinta prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie suplimentara verticala in partea stanga a cutiei;

pentru a face diagramele mai lizibile, entitatile externe sunt plasate, pe cat posibil, in jurul diagramei iar stocurile de date, in partea centrala a diagramei;

fluxurile de date de la - catre stocurile de date sunt unidirectionale (fie de adaugare, fie de consultare) si nu sunt etichetate.

2. Descompunerea functionala si rafinarea DFD

Daca sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil sa realizam de la inceput o DFD detaliata. Pentru a putea descrie in detaliu sistemele complexe, metodele structurate propun o abordare TOP-DOWN, respectiv o descompunere functionala a sistemului, care este realizata prin rafinarea succesiva a proceselor.

Primul nivel (nivelul 0) il constituie DIAGRAMA CONTEXTUALA, care defineste granitele intre sistemul analizat si mediu.

Nivelele urmatoare se obtin prin rafinarea proceselor complexe intr-o diagrama de nivel inferior.

In cazul aplicatiei Decontari, au rezultat urmatoarele diagrame:

Figura 1. Diagrama contextuala pentru aplicatia Decontari

Figura 2. Diagrama fluxului de date de nivel 1 pentru aplicatia Decontari

Figura Diagrama fluxului de date de nivel 2 pentru aplicatia Decontari

Definirea directiilor de perfectionare a actualului sistem

Pe baza activitatilor de evaluare si analiza critica se identifica neajunsurile actualului sistem si se propun solutii de inlaturare a acestora se formuleaza variante de solutii, iar in cadrul acestora se definesc cerintele si restrictiile de realizare a sistemului informatic.

Definirea directiilor de perfectionare presupune:

specificarea obiectivelor si a performantelor sistemului informatic;

stabilirea domeniilor de probleme si a principalelor functiuni ale sistemului informatic;

definirea cerintelor si restrictiilor informationale pe domenii de probleme si functiuni care consta in:

definirea principalelor intrari/ iesiri;

definirea solutiei de organizare a datelor;

definirea variantelor tehnologice de prelucrare;

definirea restrictiilor informationale si de control.

formularea conditiilor pentru realizarea sistemului informatic, care consta in:

specificarea termenelor si duratelor solicitate;

precizarea prioritatilor in realizarea obiectivelor sistemului informatic;

specificarea cerintelor speciale privind flexibilitatea, compatibilitatea cu alte sisteme, gradul de generalizare al sistemului.

Pentru fiecare varianta de solutie informatica se procedeaza la:

evaluarea resurselor necesare (costurile de sistem);

evaluarea efectelor economice directe si indirecte;

calculul indicatorilor de eficienta economica.

Modelarea sistemului curent

Indiferent de tipul sistemului analizat, manual sau informatizat, o problema este comuna: el va fi inlocuit de un nou sistem. Oricat de ineficient, vechiul sistem trebuie sa transfere celui nou o serie de elemente, cum sunt datele folosite, procedurile existente. Deci sistemul fizic actual efectueaza in parte sau in intregime ceea ce-si propune sa faca noul sistem fizic, dar la alt nivel de performanta. Tocmai necesitatea trecerii de la vechiul la noul sistem ne obliga sa decidem asupra celor doua elemente specificate anterior, date si proceduri, ceea ce conduce la obligativitatea constituirii unui model logic al sistemului propus, care sa contina una sau mai multe DFD, un model de date si logica procesului de prelucrare. Problema comuna ar consta in identificarea unei cai de realizare a modelului logic al sistemului propus [1]

O modalitate de abordare consta in prezentarea detaliata a sistemului fizic curent, dupa care sa se realizeze construirea modelului logic curent, prin abstractizarea celui fizic existent. Se va continua cu scoaterea in relief a ceea ce trebuie neaparat schimbat din sistemul curent si ceea ce trebuie sa se realizeze in cel nou. Deci, modelul logic propus poate fi conceput pe baza modelului logic curent.

Pornind de la modelul fizic, se deriva modelul logic in cadrul caruia se realizeaza:

pune in evidenta ce face sistemul, eliminand detaliile referitoare la modul cum functioneaza sistemul in implementarea actuala;

pune in evidenta functiunile de baza ale sistemului;

permite identificarea si eliminarea problemelor legate de redundanta datelor si duplicarea proceselor de prelucrare;

permite stabilirea cu o mai mare precizie a granitelor sistemului prin eliminarea proceselor manuale care nu pot fi automatizate complet.

Derivarea modelului logic al sistemului existent

Construirea modelului logic presupune transformarea diagramei de flux a datelor fizice in diagrama de flux a datelor logice.

Procesul de derivare a diagramei logice va incepe de la ultimul nivel de descompunere alcatuit de la procesele "frunza" si va continua prin agregarea proceselor catre nivelurile superioare.

Se parcurg urmatorii pasi:

1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin gruparea intr-un stoc logic de date a entitatilor inrudite sau utilizate frecvent.

Dupa identificarea stocurilor logice de date se construiesc:

diagrama de corespondenta intre stocuri logice si entitatile din modelul logic;

diagrama de corespondenta intre stocuri fizice si stocuri logice de date.

2. Inlaturarea dependentelor fizice si temporale din denumirea proceselor si a fluxurilor de date: din DFD la nivel fizic (se observa ca nu exista referinte fizice si temporale in aplicatia decontari).

Derivarea proceselor logice:

scoaterea in afara granitelor sistemului a proceselor manuale care nu pot fi automatizate (deciziile);

inlocuirea proceselor care nu realizeaza nici o transformare asupra fluxurilor de date cu fluxurile propriu-zise;

combinarea proceselor care realizeaza prelucrari asemanatoare sau multiple care se executa impreuna sau in secventa;

inlaturarea proceselor care tin de implementarea actuala si a proceselor redundante.

In cazul aplicatiei prezente:

se combina procesele "Inregistrare incasari in numerar" si "Inregistrare incasari prin virament" deoarece realizeaza prelucrari asemanatoare;

se inlatura procesele redundante "Inregistrare incasari in jurnal" si "Inregistrare plati in jurnal".

4. Derivarea fluxurilor logice care presupune inlocuirea numelui de document numai cu fluxul de   

informatii utilizate efectiv de proces.

Gruparea proceselor elementare si transformarea diagramei fizice in diagrama logica, aplicand cei 5 pasi.

Relatia existenta intre DFD si modelul datelor

Dupa cum reiese din prezentarile anterioare, fiecare sageata din DFD reprezinta un flux al datelor, in sensul unui traseu pe care structurile datelor elementare sau grupate se vor deplasa in sistem. De exemplu, Facturi desfacere este o data grupata. Cand numele ei se plaseaza pe un flux de prelucrare trebuie sa vedem si obligativitatea ca acel flux sa fie descris prin prisma structurii datelor respective, deci, trebuie prezentate rubricile documentului. Similar va fi abordat si simbolul pentru stocare. La prima vedere, el reprezinta locul unde se realizeaza operatiunea, dar foarte important este sa prezentam structura datelor pastrate. Firesc, si in cazul fluxului de date, si in cel al stocarii lor nu trebuie uitata descrierea semnificatiei economice. Structura datelor trebuie sa fie redusa la a treia forma normalizata, iar continutul locurilor de stocare a datelor sa fie prezentat prin reduceri la unul sau mai multe tabele relationale in forma a treia normalizata [1].

In cazul aplicatiei decontari, se obtine urmatoarea DFD a sistemului logic.
Decontari cu beneficiarii .Nivelul elementar al DFD a sistemului logic. Nivelele superioare ale DFD a sistemului logic sunt identice.

Figura 4. Diagrama fluxului de date

Tabel 1 aplicatia Decontari

Modelarea logicii proceselor

Dupa ce au fost descrise procesele de conversie a datelor in informatii, prin intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefeaza si logica interna a proceselor, oricat ar fi de detaliate, chiar si la nivelul proceselor primare, se impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie astfel descrise incat sa poata fi convertite in programe prin intermediul limbajelor de programare [1].

In faza de analiza modelarea logicii proceselor se va derula cat mai detaliat si complet posibil, dar operatiunea nu va respecta structura sau sintaxa unui anumit limbaj de programare: aceasta se va realiza intr-o etapa ulterioara proiectarea. Modelarea logicii proceselor ca si diagramele fluxurilor de date face parte din etapa de analiza a sistemului.

In analiza structurata, rezultatele obtinute in urma modelarii proceselor sunt descrieri si diagrame structurate care vor prezenta logica fiecarui proces, precum si diagrame care vor evidentia dimensiunea temporala a sistemelor, cand apar procesele sau evenimentele si modul in care aceste evenimente schimba starea sistemului [1].

Pe scurt se poate spune ca modelarea logica a proceselor se va concretiza in urmatoarele elemente ale documentatiei [1]

reprezentarea in engleza structurata;

reprezentarea logicii proceselor prin tabele de decizie;

reprezentarea logicii proceselor prin arbori de decizie;

tabelul sau diagrama starilor de tranzitie.

Reprezentarea logicii proceselor prin engleza structurata

Engleza structurata este o forma mult simplificata si modificata a limbii engleze, folosita pentru descrierea continutului casetelor care marcheaza procesele (prelucrarile) din diagrama fluxului de date. Cuvintele folosite sunt in stransa legatura cu logica folosita in conceperea procedurilor componente ale sistemelor informatice [1]

Se folosesc verbe pentru cuvintele cheie si substantive pentru descrierea structurii datelor.

Nu exista o forma standard de engleza structurata, fiecare analist ar putea apela la o forma proprie, dar scopul este de a inlesni accesul mai multor persoane la rezultatele analizei inglobate in documentatie. Utilizarea englezei structurate pentru procesul "Analiza situatie client" din decontari cu beneficiarii este reprezentata mai jos.

Analiza situatie client

WRITE CLIENTI,FACTURI_DESF, INCASARI
READ (FACTURI_DESF)
cod = FACTURI_DESF.codclient;
den = FACTURI_DESF.denclient;
adr = FACTURI_DESF.adresac;
cont = FACTURI_DESF.contc;
banca = FACTURI_DESF.bancac;
while (not eof (FACTURI_DESF))

else

vb1=1;
}
else if (vb1=1) vb=1
READ (INCASARI)
}
MOVE FIRST LINE INCASARI
READ (FACTURI_DESF)
}
CLOSE (FACTURI_DESF, INCASARI, CLIENTI)

4. Modelarea conceptuala a datelor (diagramele entitate - relatie, DER)

In cadrul modelarii conceptuale a datelor se va renunta la abordarea proceselor si se va trece la abordarea sistemelor prin prisma datelor. La fel ca si in cazul modelarii proceselor si modelarii logicii proceselor elementele esentiale vor fi diagramele.

James Martin si Carma McClure, atunci cand reliefeaza importanta tehnicilor structurate prin obiectivele ce si le propun, considera ca o parte a acestora au legatura si cu datele, si anume [1]:

Sa se realizeze o administrare riguroasa a datelor. Administrarea datelor se refera la structurarea corecta a datelor, la uniformitatea modalitatilor de definire si proiectare a datelor la nivel de intreprindere si nu a sistemului. Corect efectuate, acestea accelereaza procesele de analiza si proiectare si permit sa se utilizeze in comun componentele esentiale ale sistemelor: resursele.

Sa se efectueze o analiza sanatoasa a datelor. Analizele datelor clarifica problemele de structurare a lor si conduc la structuri stabile ale acestora, concretizate prin costuri reduse ale realizarii sistemelor. Daca baza de date a unitatii este deosebit de importanta, atunci pe analiza datelor trebuie sa se puna un accent aparte, ea fiind intotdeauna realizata inaintea proiectarii programelor. Firesc, daca stim care sunt cerintele unui sistem (iesirile), imediat ne vom pune intrebarea din ce se obtin acestea (intrarile) si apoi vom urmari cum se pot obtine iesirile (procesele).

Obiectivul principal al ingineriei informatiei este crearea unui set de metodologii care sa poata fi folosite in cele mai diverse medii de lucru, astfel incat sa se construiasca modele ale datelor la nivele de intreprindere, iar sistemele proiectate izolat sa se integreze in aceste modele.

Datele trebuie sa fie unice. Asupra lor, la nivel de intreprindere, pot fi vazute doua categorii mari de operatiuni:

asigurarea datelor (creare, actualizare);

utilizarea datelor (obtinere de documente, de diverse rapoarte, analize "What-If", sprijin decizional, diferite cautari de informatii, control si auditare intreprindere).

Modelul conceptual al datelor inseamna o modalitate de reprezentare a datelor organizatiei. Rolul sau este de a scoate in relief toate regulile privind identitatea si legaturile existente intre date [1].

Cea mai cunoscuta forma utilizata pentru modelarea datelor este diagrama entitate-relatie (DER). O modalitate aproape identica este folosita si in analiza si proiectarea orietata-obiect.

Modelarea datelor prin DER prezinta caracteristicile si structura datelor independent de modul in care acestea sunt memorate in calculator. Modelul se creeaza iterativ. De cele mai multe ori, operatiunea are loc la nivel de intreprindere, prin apelarea la o categorie foarte larga de date neglijandu-se detaliile exagerate. Doar in etapele urmatoare, in speta cand se trece la definirea proiectului, are loc construirea unui model anume entitate-relatie prin care sa fie scoasa in evidenta aria de intindere a proiectului. In timpul structurarii cerintelor, un model entiatate-relatie reprezinta cerintele conceptuale de date pentru sistemul luat in discutie. Dupa ce sunt descrise complet intrarile si iesirile sistemului in cadrul proiectarii logice, modelul conceptual al datelor, redat sub forma entitate-relatie, este rafinat inainte de a fi trecut intr-un format logic (de regula, un model relational al datelor) din care se definesc bazele de date si are loc proiectarea fizica a acestora [1].

DER joaca un rol deosebit de important in formarea profesionala a veritabililor analisti.

Se considera ca, in timpul modelarii conceptuale a datelor, se produc si se analizeaza cel putin patru diagrame entitate-relatie [1]:

DER care sa acopere datele necesare aplicatiei proiectului. Ea va permite stabilirea necesarului de date ale aplicatiei proiectului, fara sa se tina seama de constrangerile sau confuziile generate de detaliile care nu sunt inca necesare.

DER pentru aplicatia ce va fi inlocuita. Diferentele dintre aceste diagrame arata ce schimbari trebuie intreprinse pentru convertirea bazei de date in noua aplicatie. Nu se aplica in cazul sistemelor complet noi.

DER care sa scoata in relief intreaga baza de date din care noua aplicatie isi va extrage datele. Cat timp mai multe aplicatii pot folosi aceeasi baza de date, aceasta diagrama si prima evidentiaza modul in care noua aplicatie apeleaza la continutul unor baze de date mult mai extinse.

DER pentru intreaga baza de date din care aplicatia curenta isi extrage datele necesare. Ea este discutata doar pentru sistemele care exista si pentru care se urmareste imbunatatirea. Din nou, diferentele dintre diagrama precedenta si cea de fata vor indica modificarile majore de efectuat pentru a se putea influenta noua aplicatie.

Metodele de determinare a cerintelor trebuie sa fie orientate, prin intrebarile puse, prin anchetele efectuate, si asupra datelor, nu numai asupra proceselor si logicii lor. La inceput, chiar fara utilizarea unei terminologii de specialitate, analistul va fi preocupat de modul in care va afla cat mai multe informatii despre datele necesare viitorului sistem pentru a functiona la parametrii proiectati. Intrebarile vor fi astfel formulate incat sa se realizeze o buna intelegere a regulilor dupa care vor fi folosite datele in noul sistem, ce politici vor fi utilizate. Nu trebuie, inca, sa se intre in detalii de genul: cand si cum sunt prelucrate sau folosite datele, pentru a se realiza modelarea datelor [1].

Modelarea datelor se realizeaza printr-o combinatie a punctelor de vedere.

Un prim punct de vedere, formulat in literatura sub numele de metoda top-down, va scoate in evidenta regulile derularii activitatii firmei, printr-o intelegere foarte clara a naturii afacerii, si nu se va opri asupra detaliilor privind modul in care ecranele, rapoartele sau documentele sunt folosite in organizatie [1].

In afara metodei top-down, informatiile necesare construirii modelului datelor se pot obtine si prin urmarirea documentatiei firmei, ecrane, rapoarte, formulare, din interiorul sistemului. Acest proces este cunoscut in literatura de specialitate sub numele de metoda bottom-up [1].

Elementele rezultate vor figura in diagramele fluxurilor de date prin care vor fi evidentiate datele prelucrate in sistem si de aici va rezulta necesarul de date mentinute in baza de date a sistemului.

Definirea conceptului de entitate

Entitatile sunt obiecte sau evenimente (fenomene sau procese economice, in cazul nostru). Obiectele se caracterizeaza printr-o existenta de-a lungul timpului, iar evenimentele isi fac simtita prezenta la un moment dat [1].

La randul lor, obiectelor li se pot asocia cel putin doua evenimente: aparitia si disparitia lor. Exemple: incheierea si incetarea contractului de munca; predarea produselor la sectia expeditie si desfacerea lor la beneficiari s.a.

La fel putem spune si despre evenimente. Ele reprezinta asocieri intre doua sau mai multe obiecte. Exemplu: CLIENT COMANDA PRODUS.

Entitatile contin in structura lor atributele prin care ele sunt descrise.

O entitate este o persoana, un loc, un obiect, eveniment sau concept din domeniul de activitate a utilizatorului despre care organizatia doreste sa pastreze anumite date. Se cuvine precizata diferenta dintre tipurile entitatilor (entity types) si cazurile/instantele entitatii (entity instances) [1].

Tipul entitatii, cunoscut si sub numele de clasa entitatii, este o colectie de entitati care au proprietati sau caracteristici comune. Fiecarui tip de entitate i se atribuie un nume. Cat timp numele reprezinta o clasa sau un set de cazuri, el este singular. Si inca o conventie. Cum referirea generala la elementele ce pot fi catalogate ca entitati se poate face prin notiunea de obiect (desi sensul lui poate fi altul in contextul analizei si proiectarii orientate obiect), referirea la acesta se va realiza printr-un substantiv la singular. Se vor folosi litere majuscule, plasate in interiorul dreptunghiului corespunzator entitatii.

O instantiere a entitatii sau instanta, denumita de noi in continuare, caz al entitatii sau caz, este o manifestare singulara a unui tip de entitate. Un tip de entitate se descrie o singura data prin modelul datelor, in timp ce mai multe cazuri ale acelui tip de entitate pot fi reprezentate prin datele stocate in bazele de date. De exemplu, exista o singura entitate CLIENT, dar ea poate sa aiba sute sau mii de cazuri/instante ale acestei entitati stocate in baza de date.

Atribute

Fiecare tip de entitate are un set de atribute asociate lui.

Un atribut este o proprietate sau o caracteristica a unei entitati care prezinta interes pentru organizatie. La randul lor, si relatiile pot avea propriile lor atribute.

Exemplu de entitate pentru aplicatia DECONTARI si unele dintre atributele posibile:

CLIENT : CodClient, DenClient, AdresaC

Ca si numele tipurilor entitatilor, numele atributelor sunt substantive scrise cu majuscule, plasate in interiorul elipselor, legate de entitatea careia i se asociaza. De multe ori insa, chiar si in cazul folosirii produselor CASE, pentru a nu se incarca o diagrama entitate-relatie, se evita prezentarea atributelor. Operatiunea se face, in schimb, in repository, depozitul de informatii despre proiect. Aici orice atribut se descrie separat, ca orice obiect distinct.

Unul dintre exemplele anterioare poate fi reprezentat in diagrama conform fig. 5.

Figura 5. Model de reprezentare a atributelor DER

Cheie candidat si cheie primara

Fiecare tip de entitate trebuie sa aiba un atribut sau un set de atribute prin care sa se efectueze diferentierea unui caz de acelasi tip.

O cheie candidat aste un atribut sau o combinatie de atribute prin care se poate identifica in mod unic un caz (o instanta) al tipului entitatii respective.

Sunt entitati care pot avea doua sau mai multe chei-candidat. In exemplul nostru, pot fi chei-candidat CodClient, NumeClient, AdresaC (presupunand ca ele identifica in mod unic un angajat). Atunci cand sunt mai multe chei-candidat, proiectantul trebuie sa decida care din ele va fi folosita drept cheie-primara.

O cheie-primara este o cheie-candidat care a fost selectata pentru a servi ca identificator de cazuri in cadrul unui tip de entitate [1]

In reprezentarile din DER, in elipsa sau elipsele aferente atributului sau atributelor ce formeaza cheia primara, numele respective se subliniaza (vezi CodClient din entitatea CLIENT ).

Relatiile entitatilor

Relatiile reprezinta legaturile intre componentele unei diagrame entitate-relatie. O relatie este o asociere intre cazurile/instantele uneia sau mai multor tipuri de entitati care prezinta interes pentru organizatie. Ele se pot simboliza printr-un romb. De regula, relatiile sunt redate prin verbe.

Cardinalitatea relatiilor

Presupunem ca exista doua tipuri de entitati, A si B, intre care exista o linie de legatura pentru a marca relatia. Cardinalitatea unei relatii este data de un numar al cazurilor/instantelor entitatii B care pot sau care ar putea sa fie asociate cu fiecare caz al entitatii A. Cardinalitatea este sugerata prin 0 (zero), 1, M ("multe"), cu mentiunea ca ele pot avea prezenta obligatorie sau optionala. Trimiterea la cardinalitate se face in moduri destul de diferite, in functie de notatia folosita. Recomandam citirea cu atentie a diagramelor si descifrarea elementelor strict necesare intelegerii, indeosebi pentru reflectarea cardinalitatii. De exemplu, ea poate fi notata cu semne (0, 1, M, N) sau prin simboluri (linie cu varf simplu de sageata pentru 1, linie cu varf dublu de sageata pentru M. Alteori, 1 se reprezinta prin linie simpla si M prin varf de sageata). In multe materiale, inclusiv produse CASE, se foloseste notatia model-date, cunoscuta mai mult sub numele laba-gastei, conform carei cardinalitatea se reprezinta prin urmatoarele simboluri [1]:

Entitati compuse sau asociative (gerundive)

Atributele pot fi asociate cu o relatie multe-la-multe sau cu o entitate. Un exemplu, din lumea cursurilor-credit, transferabile in cadrul unei perioade. Un student poate lua mai multe cursuri dintr-o lista, dar finalizarea cu nota se poate efectua in momente (la date) diferite. Prezentam, mai jos, cateva dintre datele concrete [1]

Din analiza cazurilor rezulta ca atributul DATA_PROMOVARII nu este o proprietate a entitatii STUDENT, cat timp examenele pot fi date la momente diferite. Dar nu este nici o proprietate a entitatii CURS, cat timp acelasi curs poate fi sustinut la date diferite. In schimb, DATA_PROMOVARII este o proprietate a relatiei dintre STUDENT si CURS. Atributul se asociaza relatiei si se prezinta sub forma de diagrama, ca in fig. 7.

Figura 7. Asocierea unui atribut la o relatie

De aici rezulta un caz aparte de entitate, numita gerundiva sau compusa sau asociativa care, de fapt, este o relatie folosita de analist in model ca un tip de entitate. In astfel de cazuri, se foloseste un simbol special: dreptunghi cu romb in interior, in care se scrie numele entitatii (fig. 8) [1].

Figura 8. Redarea unei entitati gerundive (asociative) [1]

Nu trebuie confundata aceasta situatie cu relatiile transformate in entitati nepurtatoare de informatii, descrise anterior.

Scopul diagramelor entitate-relatie este de a surprinde cele mai complete sensuri posibile ale datelor necesare sistemului informational din organizatie.

Tipuri de relatii

Din cele prezentate mai sus, rezulta ca intre entitatile descrise, luate doua cate doua, se pot identifica trei tipuri de relatii: unu-la-unu, unu-la-multe, multe-la-multe. In diagrame, descrierea relatiilor se face de-a lungul liniilor care leaga cele doua entitati. Simbolul varf-de-sageata este cunoscut ca indicator al cardinalitatii (cardinality indicator).

In cele ce urmeaza sunt prezentate exemple de tipuri de relatii

Relatia unu-la-unu (1:1)

Figura 9. Descrierea relatiei 1:1

"Fiecare BIROU este condus de un, si numai un, MANAGER"

"Fiecare MANAGER conduce un, si numai un, BIROU".

Relatia unu-la-multe (1:M)

Figura 10. Descrierea relatiei 1:M

Fiecare VANZARE implica unul sau mai multe ATRICOL(e)_VANDUT(e) "

"Fiecare ATRICOL_VANDUT face parte din numai o VANZARE"

Relatia multe-la-multe

Figura 11. Descrierea relatiei M:N

"Fiecare FURNIZOR livreaza unul sau mai multe PRODUS(e)"

"Fiecare PRODUS este livrat de unul sau mai multi FURNIZOR(i)"

In anumite cazuri, intre doua entitati pot exista mai multe relatii.

De exemplu, s-ar putea spune ca "FURNIZOR ofera PRODUS", dar si "PRODUS este cumparat de la FURNIZOR", ceea ce s-ar putea reprezenta ca in fig. 12.

Figura 12. Descrierea relatiilor multiple intre doua entitati

Relatii optionale si obligatorii

Alteori, relatiile dintre entitati nu-si fac simtita prezenta in toate situatiile. Chiar cazul cu studiile la care lucreaza diverse persoane este destul de elocvent; o persoana poate sa lucreze la un singur studiu sau la cateva, sau la niciunul si, invers, un studiu poate fi efectuat de o persoana, de mai multe sau de nici una. In astfel de situatii, se apeleaza la urmatoarea forma de reprezentare. (fig. 13)

Figura 1 Exemplu de relatie optionala

Cercul suprapus pe latura entitatii indica, de fapt, pozitia 0 (valoarea minima poate fi si zero), conferind relatiei caracterul optional.

Un alt aspect se refera la caracterul obligatoriu al relatiilor. Cu alte cuvinte, o entitate poate exista fara cealalta?

Sa luam exemplul vanzarilor. In relatia 1:M, dintre VANZARE si ARTICOL_VANDUT. Ar fi total eronat ca o entitate sa existe fara cealalta: nu poate fi o vanzare fara cel putin un articol vandut si, invers, un articol nu poate fi vandut fara o vanzare (operatiunea nu ar avea sens). Simbolul folosit pt a marca relatiile obligatorii este acelasi cerc, cu deosebirea ca este hasurat.

Figura 14. Exemplu de relatie obligatorie

Relatia unei entitati cu ea insasi

In practica, apar si situatii in care o entitate este pusa in relatie cu ea insasi.

Ne oprim la exemplul entitatii ANGAJAT. Unii dintre ei dobandesc statutul de coordonatori ai activitatii celorlalti, situatii in care se poate apela la o diagrama de genul celei din fig.15.

Figura 15. Redarea relatiei unei entitati cu ea insasi

Reprezentarea anterioara se citeste astfel:

"Un angajat poate fi coordonatorul unuia sau mai multor angajati"

"Oricare angajat intotdeauna raporteaza altui angajat"

Relatii alternative (sau/sau)

Uneori se ivesc situatii cand relatiile posibile se redau alternativ: fie o varianta este de urmat, fie cealalta. De exemplu, o marfa destinata vanzarii poate fi realizata de unitatea care o vinde sau poate fi procurata din afara. In ambele cazuri, obiectul comercializat, MARFA, care este o entitate, va fi pusa in legatura cu cele doua surse posibile, PRODUCTIA_ALTORA si PRODUCTIA_PROPRIE, printr-un punct comun, dar nu cu linii de relatii distincte, asa cum este prezentat in figura 16.

Figura 16. Exemplu de diagrama pentru relatiile alternative

Citirea diagramei este:

"O marfa se poate asocia sau cu un producator din afara, sau cu productia unitatii"

"Un producator din afara poate livra mai multe marfuri"

"O linie proprie de productie poate livra mai multe marfuri"

Desi diagramele entitate-relatie se cunosc de catre multi specialisti din lumea bazelor de date, ele constituie unul din conceptele esentiale ale analizei si proiectarii structurate si, ca atare, provin din acest domeniu [1].

Dupa cum reiese si din citirea cu atentie a numelui diagramei, scopul ei este de a evidentia entitatile de date (obiectele despre care se solicita pastrarea datelor) si relatiile ce exista intre ele.

De remarcat diferenta dintre diagrama fluxului de date si diagrama entitate-relatie. In timp ce diagrama fluxurilor de date indica atat procesele de prelucrare, cat si entitatile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER trateaza doar entitatile de date. Din aceasta cauza, DER poate fi considerata si ca diagrama modelului datelor sau diagrama conceptuala a datelor [1].

In sistemul analizat pentru descrierea DER se apeleaza la simbolul dreptunghi, pentru fiecare entitate. Se recomanda ca numele entitatii sa fie redat printr-un substantiv la singular (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE, INCASARI).

Dupa ce se identifica entitatile se continua cu imperecherea lor, fiecare cu fiecare, pentru a descrie relatiile dintre ele.

Figura 17. DER pentru aplicatia Decontari

4.1. Modelul Entitate/Relatie (E/R)

Cercetarile efectuate pentru definirea unui model de date care sa permita reprezentarea cat mai fidela a realitatii au condus la definirea conceptului de model semantic inca din 1976 cand Chen a prezentat modelul Entitate-Relatie (E/R), care constituie astazi o tehnica larg acceptata pentru proiectarea bazelor de date.

Modelul E/R permite proiectantului bazei de date sa elaboreze un model conceptual de nivel inalt, fara a tine seama de anumite constrangeri impuse de utilizarea unui anumit SGBD, de o anumita platforma hardware, sau de anumite considerente de eficienta privind exploatarea bazei de date, ceea ce permite o reprezentare mai fidela a realitatii avute in vedere, constituind astfel o etapa intermediara in proiectarea unei baze de date, fiind din acest punct de vedere asemanator pseudocodului utilizat in activitatea de programare.

Modelul Entitate/Relatie (E/R) permite reprezentarea schematica a realitatii avute in vedere cu ajutorul unei diagrame E/R definita plecand de la conceptele de baza: tip de entitate, tip de relatie (legatura, corelatie), atribut.

Pentru reprezentarea unor probleme complexe de tip baza de date, aparute incepand din anii 80, modelul de date semantic a fost extins cu noi concepte semantice, rezultand astfel modelul entitate relatie extins EER. In acest sens la conceptele de baza au fost adaugate conceptele suplimentare de superclasa, subclasa si mostenire.

O superclasa reprezinta un tip de entitate care contine subclase distincte care trebuie sa fie reprezentate in cadrul modelului, iar o subclasa este un membru al unei superclase. O subclasa, fiind un tip de entitate distinct, poate avea la randul sau subclase, astfel incat se pot construi ierarhii de clase. O subclasa mosteneste toate atributele superclasei, putand avea in plus si alte atribute. In diagrama EER, pentru subclase se vor reprezenta numai atributele specifice subclasei.

Pentru elaborarea unei diagrame EER, se utilizeaza [11], [13] o serie de simboluri reprezentate in figura 18.

Problema rezolvata

Folosind modelul entitate - relatie sa se reprezinte diagrama E/R pentru un sistem informatic simplificat al unei firme care desfasoara activitate de comert fiind avute in vedere subsistemele;

aprovizionare (evidenta furnizorilor);

desfacere (situatia vanzarilor);

urmarirea stocurilor.

5. Selectarea celei mai bune variante strategice de proiectare

Intregul efort depus pana in momentul de fata s-a concretizat intr-o bogata acumulare de informatii despre cerintele sistemului, structurate sub diverse forme, precum si despre modul in care am dori sa fie conceput noul sistem sau ce corectii sa i se aduca celui vechi.

Ne aflam in asa-zisa faza a strategiei proiectului.

In afara certitudinilor concretizate in specificatiile elaborate pana acum, asupra variantei noului sistem planeaza si o seama de incertitudini, generate de nehotararea sau, inca, needificarea asupra formei finale dorite. Un cuvant greu au utilizatorii si finantatorii proiectului. Pentru a-i ajuta sa ajunga la o concluzie finala comuna, trebuie pornit de la cerintele structurate si se vor prezenta cateva strategii concurente de proiectare, dintre care doar una va fi continuata in pasul urmator al ciclului de viata al sistemului, faza de proiectare, in functie de performantele ei si de incadrarea in resursele disponibile [1].

Rezultatul final al studiului de identificare a cerintelor de informatii se concretizeaza intr-un raport detaliat al cerintelor sistemului, in care vor fi prezentate informatiile necesare noului sistem. Raportul cuprinde tot ceea ce trebuie sa fie produs de catre sistem. El va lasa fazei de proiectare o imagine clara a modului in care se vor obtine cerintele sistemului.

Raportul contine urmatoarele elemente [1]

descrierea functiilor principale executate in noul sistem, inclusiv ce trebuie facut si de cine, cum se realizeaza interfata functiilor cu intregul sistem si cum functiile noi vor afecta utilizatorii;

descrierea tuturor datelor necesare sistemului, inclusiv nume, marimea, format, sursa, importanta, precum si o lista a regulilor pentru a se asigura securitatea si controlul datelor;

o structura preliminara a datelor, prin care se va arata cum datele vor fi organizate in inregistrari logice si care este legatura dintre date;

descrierea modului de functionare a noului sistem si a subsistemelor componente, precum si a modului in care vor fi atinse obiectivele de catre intregul organism;

descrierea si prezentarea unui exemplar al tuturor intrarilor in sistem, inclusiv numele fiecarei intrari, sursa, cine il completeaza, ce date va contine si cum vor fi culese datele din el;

o descriere si un model de exemplar pentru fiecare iesire din sistem (rapoarte, documente);

descrierea unor norme interne de conduita privind raportarile, programarea activitatilor, securitatea si protectia, personalul implicat si zona de acces pe categorii ale acestuia;

prezentarea restrictiilor existente in sistem, cum ar fi statutele si regulamentele de organizare.