Analiza Sistemelor Informationale. Modelarea Conceptuala a Datelor
Capitolul I
ANALIZA SISTEMELOR INFORMAȚIONALE
I.1. ACTIVITATEA DE DETERMINARE A CERINȚELOR
Rezultatele activității de determinare a cerințelor se concretizează în diferite forme ale informațiilor colectate, cum sunt copii ale interviurilor, însemnări efectuate în timpul observării și analizei documentelor, interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru ș.a., precum și rezultate ale prelucrărilor efectuate de calculator, cum ar fi prototipurile.
Sintetic, rezultatele obținute după această activitate pot fi prezentate astfel:
Informații obținute în urma conversațiilor cu utilizatorii sau prin observarea activităților prestate de aceștia: copii sau sinteze ale interviurilor, răspunsuri la chestionare sau interpretări ale acestora, însemnări și rezultate din observarea activităților, procese verbale ale ședințelor ce au avut loc în acest scop.
Informații scrise care există în unitate: misiunea și strategia afacerii, exemplare ale formularelor, rapoartelor și machetelor de ecrane, manuale ale procedurilor, descrieri ale posturilor de lucru, manuale de instruire, scheme de sistem și documentația sistemului existent, rapoartele consultanților, etc.
Informații obținute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii ale fișierelor sesiunilor grupului de sprijinire a sistemului, conținutul depozitelor și rapoartelor existente în CASE, ecrane și rapoarte rezultate din prototipurile sistemului, etc.
Odată cu procesul de culegere a informațiilor prezentate, analistul trebuie să afle și alte aspecte despre organizație, cum ar fi:
obiectivele firmei, pentru a se vedea modul în care sunt derulate activitățile ei;
informațiile de care au nevoie persoanele din unitate pentru exercitarea sarcinilor ce le revin;
datele (descrierea lor, volumul, mărimea, periodicitatea ș.a.) vehiculate în unitate pentru fiecare loc de muncă;
când, cum, de către cine și ce date circulă, se transformă sau se înregistrează;
ordinea de prelucrare și dependența dintre datele trecute prin diverse activități desfășurate;
regulile prin care se specifică modul în care sunt transmise și prelucrate datele;
evenimentele marcante și momentele declanșării lor, prin care se schimbă valoarea datelor.
Timpul necesar culegerii informațiilor este imens, iar cheltuielile sunt pe măsură. Este necesară cunoașterea sloganului care circulă printre analiști “analysis paralysis” (analizele paralizează), referindu-se la excesele de zel din faza de analiză.
Ca efect al tendințelor de mărire a timpului de analiză a sistemelor existente, în ultimii ani s-a efectuat trecerea spre analiza mai puțin pronunțată a sistemelor ce urmează a se realiza. Tehnicile moderne, JAD și prototipizarea, preiau tot mai puține elemente din sistemele existente, ca urmare a analizelor efectuate. Altele, mai radicale, renunță aproape total la analiza sistemului existent. Este cazul proceselor controlate prin RAD (Rapid Application Development), care apelează la JAD, prototipizare și alte instrumente integrate de tip CASE.
Datorită interesului tot mai crescut pentru aceste tehnici moderne de analiză, dintre metodele de determinare a cerințelor sistemului, voi prezenta în amănunt doar metodele JAD (Joint Application Design) și prototipizarea.
I.1.1 Metode moderne de determinare a cerințelor sistemului
Metodele moderne spijină procesul de culegere și structurare a informațiilor prin diminuarea substanțială a timpului dedicat analizei de sistem. O variantă opusă ciclului de viață al dezvoltării sistemelor este Rapid Application Development (RAD) care combină metoda JAD, instrumentele CASE și prototipizarea.
I.1.2 Joint Application Design
Spre sfârșitul anilor 1970, specialiștii în realizarea de sisteme IBM au elaborat un nou proces de culegere a cerințelor informaționale ale sistemelor și de revizuire a proiectelor sistemelor. El se numește Joint Application Design (JAD). Ceva mai târziu, în Europa de Nord, apare o replică a JAD, numită Participatory Design (PD). Elementul de noutate al PD față de JAD îl constituie accentuarea mult mai puternică a rolului jucat de utilizatori. Fiecare dintre ei are drepturi egale în stabilirea cerințelor sistemului, precum și în acceptarea lui. În alte cazuri, se delegă un grup de utilizatori care să aibă aceste atribuții. Sub auspiciile PD, analiștii sun la dispoziția utilizatorilor, iar managerii și consultanții nu au rol de control, ci de avizare. Se afirmă că toate acestea sunt posibile în Europa de Nord deoarece aici forța de muncă este mult mai bine organizată și angajații sunt mult mai receptivi la mutațiile tehnologice.
În timp s-au dezvoltat mai multe metode de realizare a sesiunilor JAD, conform prezentărilor făcute de Wood și Silver (Wood, J., Silver, D. – Joint Application Design, John Wilez / Sond, New Zork, 1989)
Ideea pricipală JAD o constituie punerea laolaltă a tuturor forțelor interesate în dezvoltarea sistemelor: utilizatorii-cheie, managerii și analiștii de sistem implicați în analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel de grup. Totuși, în sesiunile JAD se urmează o anumită secvență de derulare a activităților, pe baza unor roluri bine definite.
Sesiunile JAD se desfășoară în locuri diferite de cele unde lucrează personalul antrenat în ele. Scopul este de a-i ține departe de grijile locului de muncă și de a-i folosi intens în ședințele de lucru.
Participanții la sesiunile JAD:
Conducătorul sesiunii JAD (leader) are rolul de organizare și desfășurare a sesiunilor JAD. El trebuie să fie bun specialist în managementul grupurilor și în analiza de sisteme. El stabilește și urmărește respectarea agendei de lucru, trebuind să-și mențină neutralitatea pe durata derulării sesiunii. De asemenea, va rezolva eventualele conflicte și dezacorduri și va solicita emiterea tuturor ideilor posibile.
Utilizatorii. Principalii utilizatori ai sistemului vor juca un rol determinant în sesiunile JAD, întrucât ei știu cel mai bine ce înseamnă folosirea zilnică a sistemului.
Managerii. De regulă, sunt managerii grupurilor de lucru ce folosesc sistemul. Ei cunosc direcțiile de dezvoltare, elementele de motivare și sunt implicați direct în determinarea erințelor sistemului prin sesiunile JAD.
Susținătorul (spunsorul). Datorită cheltuielilor mari implicate de sesiunile JAD, ele trebuie să aibă susținerea unei persoane cu o poziție înaltă în firmă. Susținătorul nu participă la toate sesiunile, ci doar la cele de început și sfârșit.
Analistul de sistem. Membrii echipei de analiză participă la sesiunile JAD, deși implicarea lor este destul de limitată. Ei trebuie să afle cât mai multe lucruri de la utilizatori și manageri și nu trebuie să-și exprime punctul de vedere.
Scribul. Scribul va nota totul în timpul sesiunilor JAD, prin intermediul unui calculator sau laptop. Se pot folosi procesoarele de text sau o serie de instrumente CASE speciale.
Informaticienii. Alături de analiștii de sistem, participă și alte categorii de personal din domeniul sistemelor informaționale, cum sunt programatorii, analiștii bazelor de date, planificatorii de sisteme informaționale, precum și personalul antrenat în alte operațiuni de prelucrare a datelor. Ei vin să afle părerile utilizatorilor și managerilor și, dacă este cazul, să ajute la definitivarea studiului de fezabilitate tehnică.
Când sesiunea JAD este încheiată, rezultatul final înseamnă un set de documente referitoare la activitățile din sistemul curent care au legătură cu studiul noului sistem. Analiștii vor obține o nouă imagine asupra a ceea ce se intenționează a se realiza și ceea ce există în unitate. Principalele activități și persoane cheie din JAD sunt redate în tabelul următor.
I.1.3 Sistemele de sprijinire a grupurilor
Sesiunile JAD nu beneficiază prea mult de ajutorul calculatorului, în pofida recomandărilor unora de a se folosi cât mai multe instrumente CASE.
Unul dintre dezavantajele sesiunilor JAD îl constituie numărul mare de participanți și, de aici, diversitatea părerilor afișate într-un timp limitat. Timpul alocat unei persoane pentru a lua cuvântul se reduce la câteva minute. Dar, și în acest caz, unii vor încerca să domine grupul, alții nu vor spune nimic sau se vor teme să spună totul, fie din cauza șefilor, fie pentru a nu fi criticați.
Soluția este oferită de sistemele de sprijinire a grupurilor care vor rezolva problemele întâlnirilor în grup.
Pentru a-i acorda oricărui membru al grupului șansa de a-și exprima părerea, aceștia vor introduce în calculator tot ceea ce cred despre problema discutată, fără a mai fi nevoiți să o expună verbal.
Se cunosc și alte modalități de folosire a sistemelor de sprijinire a grupurilor pentru determinarea cerințelor sistemului. Acestea se referă la posibilitatea achiziției de cunoștințe de la grupuri de experți, și nu de la unul singur, cum se procedează de obicei. Rezultatele au fost excelente. Pe o astfel de cale se poate realiza orice prototip mult mai performant.
I.1.4. Prototipizarea și determinarea cerințelor sistemelor
Prototipizarea este un proces iterativ prin care analiștii și utilizatorii pun în discuție o versiune rudimentară a unui sistem informațional, care va fi într-o continuă schimbare, în funcție de reacția utilizatorilor. Prototipizarea conduce la renunțarea la ciclul de viață al dezvoltării sistemelor sau la creșterea rolului său.
Pentru culegerea informațiilor despre cerințele utilizatorilor încă se apelează la interviuri, dar, prin prototipizare, operațiunea va fi mai simplă și va solicita un timp mai scurt. Prototipul este văzut și testat de utilizator, având posibilitatea să precizeze ce ar mai dori, dar să-și genereze această formă nouă, firesc, cu ajutorul specialiștilor din preajmă.
Prototipizarea este facilitată de câteva limbaje sau produse program din generația a patra, inclusiv CASE.
Prototipizarea este foarte utilă în determinarea cerințelor sistemului atunci când:
cerințele utilizatorilor nu sunt prea clar formulate sua bine înțelese, ceea ce se întâmplă cu noile sisteme sau cu cele de sprijinire a procesului decizional;
unul sau mai mulți utilizatori sau susținători sunt implicați în sistem;
în trecut s-au înregistrat dificultăți în comunicarea dintre utilizatori și analiști și se încearcă formulatea cât mai corectă a cerințelor sistemului;
anumite mijloace de lucru (formulare și rapoarte predefinite), precum și datele de test existente sunt elemente care contribuie la construirea mai rapidă a sistemului.
Totuși, prototipizarea generează și deficiențe, cum ar fi:
tendința de evitare a unui cadru formal de elaborare a documentației privind cerințele sistemului, ceea ce va îngreuna mai târziu orice control;
fiind conceput în colaborare cu un grup nesemnificativ de utilizatori, va fi probabil respind de viitorii utilizatori;
fiind conceput izolat, este puțin probabil ca el să fie ușor de integrat în sistemul existent;
nerespectându-se etapele ciclului de viață al dezvoltării sistemelor pot fi omise aspecte esențiale, cum ar fi securitatea, controlul datelor introduse și standardizarea la nivel de sistem.
Pașii prototipizării și elementele caracteristice ale acestora sunt prezentați, intr-o formă descriptivă, în continuare:
Avantajele și dezavantajele prototipizării:
Dintre avantajele prototipizării:
o mai bună definire a cerințelor utilizatorilor;
o implicare mai puternică a utilizatorilor și, ca atare, creșterea satisfacției lor;
creșterea vitezei de realizare a sistemelor;
un număr redus de erori;
flexibilitate mai mare la potențialele schimbări;
costuri mai mici de realizare a sistemului (aproximativ 10%+20% din costurile sistemelor tradiționale).
Ca dezavantaje ale prototipizării menționez:
o creștere semnificativă a timpului dedicat de utilizatori pentru realizarea noului sistem;
o folosire mai puțin eficientă a resurselor sistemului;
realizarea unor sisteme incomplete;
sisteme testate și documente în forme nesatisfatorilor nu sunt prea clar formulate sua bine înțelese, ceea ce se întâmplă cu noile sisteme sau cu cele de sprijinire a procesului decizional;
unul sau mai mulți utilizatori sau susținători sunt implicați în sistem;
în trecut s-au înregistrat dificultăți în comunicarea dintre utilizatori și analiști și se încearcă formulatea cât mai corectă a cerințelor sistemului;
anumite mijloace de lucru (formulare și rapoarte predefinite), precum și datele de test existente sunt elemente care contribuie la construirea mai rapidă a sistemului.
Totuși, prototipizarea generează și deficiențe, cum ar fi:
tendința de evitare a unui cadru formal de elaborare a documentației privind cerințele sistemului, ceea ce va îngreuna mai târziu orice control;
fiind conceput în colaborare cu un grup nesemnificativ de utilizatori, va fi probabil respind de viitorii utilizatori;
fiind conceput izolat, este puțin probabil ca el să fie ușor de integrat în sistemul existent;
nerespectându-se etapele ciclului de viață al dezvoltării sistemelor pot fi omise aspecte esențiale, cum ar fi securitatea, controlul datelor introduse și standardizarea la nivel de sistem.
Pașii prototipizării și elementele caracteristice ale acestora sunt prezentați, intr-o formă descriptivă, în continuare:
Avantajele și dezavantajele prototipizării:
Dintre avantajele prototipizării:
o mai bună definire a cerințelor utilizatorilor;
o implicare mai puternică a utilizatorilor și, ca atare, creșterea satisfacției lor;
creșterea vitezei de realizare a sistemelor;
un număr redus de erori;
flexibilitate mai mare la potențialele schimbări;
costuri mai mici de realizare a sistemului (aproximativ 10%+20% din costurile sistemelor tradiționale).
Ca dezavantaje ale prototipizării menționez:
o creștere semnificativă a timpului dedicat de utilizatori pentru realizarea noului sistem;
o folosire mai puțin eficientă a resurselor sistemului;
realizarea unor sisteme incomplete;
sisteme testate și documente în forme nesatisfăcătoare;
reacții comportamentale negative;
un sistem aflat în continuă construcție.
Avându-se în vedere avantajele și dezavantajele prototipizării, se recomandă o analiză lucidă a oportunității prototipizării, recomandându-se ca firească folosirea sa în următoarele condiții:
utilizatorii nu știu prea bine ceea ce vor sau cerințele lor sunt într-o continuă schimbare;
cerințele sistemului sunt greu de definit;
nu sunt cunoscute intrările și ieșirile sistemului;
activitățile de executat sunt semistructurate sau nestructurate;
proiectanții nu sunt siguri de tehnologiile ce vor fi folosite;
sistemul de realizat este necesar într-o perioadă foarte scurtă de timp și constituie o cerință majoră pentru unitate;
riscul oferirii unui sistem inadecvat este foarte mare;
reacțiile utilizatorilor față de noul sistem contribuie esențial la realizarea lui;
cerința de testare a mai multor strategii de proiectare;
sistemul va avea o utilizare temporară.
Dintre sistemele ce se pretează prototipizării, relevante sunt sistemele de sprijinire a procesului decizional, sistemele informaționale pentru top manageri, sistemele expert și schemele de reconstituire a informațiilor. Prototipizarea nu este recomandată în cazul sistemelor mari sau al celor complexe, cu o arie mare de întindere la nivelul organizației. De asemenea, nu este indicată pentru aplicațiile contabile din domeniile standard, cum sunt: creanțe, plăți sau gestiune stocuri.
În cele mai multe cazuri, prototipizarea servește ciclului de viață al dezvoltării sistemelor și nu contribuie la renunțarea la o astfel de metodologie. Așadar, ea nu va conduce la înlocuirea în totalitate a metodologiilor și instrumentelor tradiționale de realizare a sistemelor.
I.1.5 Rapid Application Development
Nu au trecut decât câțiva ani de la recunoașterea lui James Martin ca părinte al unui nou concept (Martin, J. + Rapid Application Development, New York, NY: Macmillan Publishing Companz, 1991) : RAD (Rapid Application Development) și, în pofida părerilor diferite, RAD câștigă teren datorită simplității cu care sunt abordate sistemele. Din ciclul de viață al sistemelor, Martin folosește doar patru etape.
RAD este o metodologie de realizare a sistemelor informaționale care promite sisteme mai bune, mai ieftine și realizate mai rapid. O primă explicație constă în selectarea celor mai buni proiectanți de sisteme și a celor mai reprezentativi utilizatori care, împreună, în timp real, lucrează la realizarea sistemului.
Se consideră, de asemenea, că alți doi factori au contribuit substanțial la creșterea RAD:
sporirea vitezei de derulare a operațiunilor economice și, odată cu acestea, diminuarea posibilităților de control asupra lor;
apariția multor instrumente puternice bazate pe folosirea calculatoarelor în domeniul realizării sistemelor (CASE și prototipizarea, îndeosebi).
De fapt, RAD a exploatat o serie de elemente favorabile care și-au făcut apariția în același timp: investirea utilizatorilor cu o mai mare implicare în realizarea sistemelor, îndeosebi în procesul de prototipizare, care la rândul lui, se bazează tot mai mult pe tehnica JAD.
Diferența majoră a RAD față de JAD constă în faptul că prototipul devine elementul fundamental al noului sistem – ecranele afișate în timpul prototipizării devin ecrane ale sistemului, și nu modele ale unui posibil sistem. Suportul central este oferit de instrumente integrate CASE, în care se includ și generatoarele de coduri ale programele. Reutilizarea unor componente este, de asemenea, încurajată în RAD.
Nu trebuie să se înțeleagă faptul că doar dispunând de instrumente CASE se garantează și realizarea de sisteme în varianta RAD. Reușita depinde și de alte elemente, cum ar fi:
instrumentele folosite
personalul
managementul
metodologia
Martin afirmă că un sistem vechi nu poate fi convertit în altul nou peste noapte. El consideră că trebuie să se înceapă cu un grup mai restrâns de specialiști, bine pregătiți, numit celulă RAD, care va începe să lucreze la un proiect pilot pentru a demonstra viabilitatea RAD. Cu timpul, celula va crește, adăugându-se noi persoane și proiecte, până când RAD devine calea dominantă de realizare a sistemului informațional.
Etapele ciclului de viață al sistemelor informaționale, în concepția lui Martin, sunt: planificarea, analiza, proiectarea și implementarea, deși el le numește: planificarea cerințelor, proiectul utilizatorului, construirea și fasonarea (cutover). Mulți văd RAD ca o variantă în care se combină unele etape ale ciclului de viață al dezvoltării sistemelor. De exemplu, faza RAD “Proiectul utilizatorului” combină analiza cu proiectarea logică și fizică din ciclul de viață al dezvoltării sistemelor, deci trei etape comasate în una.
Planificarea cerințelor RAD înseamnă tradiționalele activități de identificare și selecție a proiectelor, precum și activități tip analiză. Acordul privind forma viitorului sistem este dat de utilizatori și analiști.
În timpul proiectului utilizatorului, utilizatorul final și informaticienii vor participa la ateliere de lucru JAD, în care cei implicați apelează la mijloace de lucru CASE pentru obținerea rapidă a prototipului proiectului sistemului. Oric\nd este necesar clientul poate interveni să-și reformuleze cerințele, ceea ce în cazul ciclului de viață tradițional al sistemelor era posibil doar în faza de început a lui.
De remarcat diminuarea substanțială a timpului necesar de la finalizarea schițării proiectului la folosirea lui, până la 3 luni, față de 18 luni în vechile condiții, datorită efortului imens investit în sistem în activitățile anterioare. Ceea ce trece de la o etapă la alta constituie forma certă, și nu una presupusă a fi acceptată.
Într-o primă parte, eforturile utilizatorului vor fi concntrate spre zona datelor, interfețele cu utilizatorul fiind foarte importante, astfel încât operațiunile de adăugare, modificare, ștergere sau interogare a datelor să fie lejere. Si cum aceste componente pot fi deseori generate de modelele conceptuale ale datelor, primele sesiuni JAD se vor axa pe semnificația și structura datelor necesare sistemului. Următoarele sesiuni vor urmări modul în care datele necesare sunt utilizate, astfel încât să onoreze anumite funcții. Ulterior, alte sesiuni JAD se vor adresa unor funcții mai specializate, care vor analiza modalitățile în care datele răspund și cerințelor altor compartimente (marketing, financiar, contabil, etc.). Pentru aceste funcții complexe vor fi dezvoltate modele ale logicii prelucrărilor sau proceselor decizionale. Prin ele se va arăta modul în care datele sunt supuse unor transformări logice, declanșate de anumite evenimente, astfel încât funcțiile să poată fi realizate. Modelele proceselor pot fi dezvoltate prin engleza structurată, diagrama stărilor de tranziție sau prin alte tehnici de modelare logică pe care le voi prezenta in capitolele următoare.
În etapa de construcție, aceiași specialiști în informatică, autori ai proiectului, vor genera codurile produsului, folosind instrumente CASE de acest gen, precum și manuale de codificare, dacă va fi necesar. În acestă fază este vorba de asmblarea unor componente realizate anterior, prin interfețe interne care să efectueze legăturile dintre ele. Componentele nerealizabile cu instrumente automate trebuie să fie create de către membrii echipei. Utilizatorii finali participă și în faza de construcție, validând ecrane și rapoarte și confirmând alte aspecte referitoare la proiectul aplicației în lucru. Membrii echipei efectuează și lucrări de altă natură: manuale pentru utilizatori, materiale pentru instruire.
Pentru sistemele mai mici, etapa de construcție poate fi cumulată cu proiectul utilizatorului.
Fasonarea înseamnă distribuirea produsului către utilizatorul final. Cum metodologia RAD este extrem de rapidă, planificarea fasonării (implementării) trebuie să înceapă mai devreme. Ea constă în testare, instruirea utilizatorilor, urmărirea eventualelor schimbări organizaționale, execuția în paralel a vechiului și a noului sistem. Toate activitățile enumerate se vor derula într-un ritm accelerat. După această etapă, sistemul trece în regimul procesului normal de întreținere.
Martin afirmă că un sistem poate fi produs în 6 luni, spre deosebire de sistemele tradiționale, realizate în 24 de luni.
Avantajele și dezavantajele RAD:
Primul avantaj a fost deja amintit: sistemele informaționale pot fi realizate într-un timp de patru ori mai scurt decât prin metodele tradiționale. Aceasta înseamnă și sisteme mai ieftine, datorită volumului mai mic al resurselor antrenate. Dintre ele, o importanță deosebită o au resursele umane pentru că echipele RAD sunt mai mici.
De asemenea, prin implicarea personală a utilizatorilor, riscul nereușitei se diminuează. Calitatea sistemului este sporită datorită numeroaselor teste ce au avut loc pe parcurs.
Prin reducerea intervalului de timp dintre definitivarea proiectului și punerea lui în lucru se răspunde mai repede și mai bine cerințelor organizațiilor.
Alții, ușor nostalgici ai vechilor metodologii, fac trimitere la zicala “Graba strică treaba”. Totuși, există și critici obiectivi (Gibson, Hughes și, îndeosebi, Bourne) care fac trimitere la concepte fundamentale ale ingineriei programării trecute cu vederea de susținătorii ardenți ai RAD.
Dintre aceste obiecțiuni, merită trecute în revistă:
Consistența. În graba lor de a proiecta cât mai repede ecrane, analiștii RAD neglijează existența unora chiar în interiorul aplicației, dar, cu siguranță, și în alte aplicații. Preocuparea principală trebuie să o constituie respectarea mărimii, culorilor, formatelor și a modalităților de afișare a mesajelor.
Standarde de programare. Standardele documentației și ale atribuirii de nume datelor sunt realizate în faze timpurii RAD, ceea ce le va face dificilă implementarea mai târziu.
Refolosirea modulelor. În timpul prototipizării, analiștii omit sau nu au timp să cerceteze dacă aceleași ecrane sau rapoarte mai există deja în alte aplicații. Deseori RAD nu oferă posibilitatea analiștilor să verifice dacă modulele ce ar putea fi refolosite există sau nu.
Scalabilitatea. Dacă sistemul proiectat în timpul RAD își demonstrează utilitatea, folosirea sa va conduce la extinderea ariei utilizatorilor inițiali care au participat la construirea sistemului. Realizatorii trebuie să aibă în obiectiv o astfel de extensie. Scalabilitatea se referă și la echipamente; aria de întindere a sistemului, numărul, tipurile și utilizatorii rapoartelor; creșterea echipei de dezvoltare și întreținere a sistemului; instruirea utilizatorilor; securitatea.
Administrarea sistemelor. Administrarea sistemelor este aproape neglijată în timpul RAD. Dintre posibile probleme: întreținerea și reorganizarea bazelor de date, constituirea copiilor de siguranță și reconstituirea sistemului după avarii, etc., toate deosebit de relevante pentru asigurarea protecției și securității sistemului.
În pofida celor enumerate, RAD există și literatura de specialitate consemnează numeroase cazuri de utilizare eficientă a sa. De fapt, succesul RAD înseamnă succesul tuturor tehnicilor moderne folosite în analiza și proiectarea sistemelor.
I.2. STRUCTURAREA CERINȚELOR SISTEMULUI
II.2.1 Modelarea proceselor
De regulă, termenului “logică” i se pot conferii două seminificații: cea dintâi face trimitere la faptul că o acțiune se bazează pe anumite reguli de judecată, concepție, iar cea de-a doua semnificație se referă la descrierea efectuată unui fenomen, proces, obiect, etc. astfel încât ele să poată fi înțelese.
Indiferent de metodologiile folosite în realizarea unui sistem / aplicație, toate apelează la operațiunea de modelare logică a datelor și prelucrărilor sub formă de diagrame, diferențele constând doar în folosirea ,mai pronunțată a diagramelor pentru descrierea sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de date fizice și diagrame ale fluxurilor de date logice. Altele apelează la combinații de diagrame, tabele și forme descriptive.
Diagrama de context scoate în relief aria de întindere a sistemului analizat, prin specificarea elementelor din interiorul organizației și a celor externe (entități externe).
Diagrama fluxurilor de date fizice specifică persoanele și tehnologiile folosite pentru fiecare proces de transfer și transformarea datelor, acceptându-se unele intrări și descriindu-se ieșirile din procesele folosite.
Diagrama fluxurilor de date ale sistemului logic curent, independenta de tehnologie, reliefeaya funcțiile de prelucrare a datelor executate de către sistemul informațional curent.
Diagrama fluxurilor de date ale sistemului logic nou va prezenta circuitul datelor, structura lor si cerințele funcționale ale noului sistem.
Descrieri ale obiectelor DFD se regasesc în așa zisele dicționare ale proiectelor sau depozite CASE (repository).
În literatura de sprecialitare toate se regăsesc sub denumirea generică de diafragme ale fluxurilor de date.
Întrucât diagramele fluxurilor de date (DFD) au ca obiectiv urmărirea modului de transfer al datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc și modele ale proceselor de prelucrare iar operațiunea se numește modelarea proceselor.
DFD reprezintă doar una din tehnicile de analiză structurată. Ele au avut un puternic impact asupra procesului de dezvoltare a sistemelor. Un exemplu este un caz în care, pe parcursul a șase ani, între 1988 și 1994, la o organizație din SUA s-au realizat economii de 17,2 milioane de dolari la cheltuielile cu software-ul, datorită recurgerii la tehnicile structurate de analiză, prin eliminarea unor activități specifice reviziei cerințelor sistemului, ceea ce a condus la dublarea productivității sistemului.
Tehnica de redare a proceselor de prelucrare prin intermediul diafragmelor fluxurilor de date a căpătat noi accepțiuni prin încorporarea ei în instrumentele de analiză și proiectare cu ajutorul calculatorului, adică în produsele CASE.
În practică, cele mai multe produse apelează la două tehnici de redare a diafragmelor fluxurilor de date: Gane & Sarson și Yourdon & DeMarco. (Gane, C., Sarson, T. – Structured Systems Analysis: Tools and Techniques, Prentice Hall, Englewood Cliffs, New Jersey, 1979 Zourdon, E., Constantine, L.L. – Structured Design, Prentice Hall, Englewood Cliffs, New Jersez, 1979 DeMarco, T. – Structured Analzsis and Design Specification, Prentice Hall, Englewood Cliffs, New Jersez, 1979)
În continuare voi prezenta cele mai importante tehnici de redare a proceselor de prelucrare prin intermediul diafragmelor, subliniind aspectele comune dar și diferențele dintre acestea.
II.2.1.1 Tehnica Gane & Sarson pentru construirea DFD
Scopul Diafragmelor Fluxurilor de Date (DFD), pentru o anumită componentă organizatorică sau funcțională la care se referă (secție, birou, compartiment, unitate, o anumită activitate – vânzări, cumpărări, încasări, plăți) este de a scoate în relief următoarele aspecte:
sursa datelor ce urmează a fi prelucrate;
operațiunile de prelucrare prin care trec datele;
destinația datelor prelucrate;
legătura existentă între prelucrări și activitatea de stocare a datelor.
Tehinica DFD apelează la patru simboluri de bază pentru a reprezenta atât sistemele informaționale logice, cât și cele fizice, înlocuind clasicele scheme logice și pseudocodurile.
În continuare voi prezenta un exemplu pentru a reda conceptele cu care operează această tehnică. Astfel, pornind de la deviza “clientul nostru, stăpânul nostru”, voi realiza diagrama fluxului de date privind relațiile cu clienții:
Această schemă este folosită pentru a evidenția actul de vânzare-cumpărare propriu-zis, din care reiese că un oarecare client, pentru a beneficia de produsele altei firme, trebuie să lanseze o comandă, iar pentru ca vânzarea să aibă loc, în afara altor condiții, este necesară existența produselor solicitate în depozitul furnizorului.
Pentru a evidenția și modul de stingere a obligațiilor de plată din partea clientului, în vederea reîntregirii resurselor financiare ale furnizorului, putem schematiza astfel:
Schemele prezentate mai sus au un caracter general intrucât, dacă am lua în calcul toate aspectele (comenzi, livrări, încasări, reîtregirea fondurilor, etc.), schema ar căpăta o formă mai complexă pe care o voi prezenta ulterior.
Revenind la diagrama fluxurilor de date privind relațiile cu clienții, am să explic semnificația simbolurilor folosite:
Clienți este o entitate externă care constituie obiectul de studiu. Această entitate transmite comenzi de vânzare într-un flux redat prin intermediul săgeții care este insoțită de explicația respectivă.
Prelucrare comenzi (1) dă răspuns comenzii de vânzare prin apelarea la informațiile existente în fișierul PRODUSE (dreptunghiul alungit notat cu D1) și actualizează datele despre vânzări, de asemenea, memorate ăntr-un fișier distinct, VÂNZĂRI, notat cu D2. Prin separarea entităților de procesele care le leagă se asigură independența prelucrării datelor de intrare și ieșire.
Cele două diagrame prezentate mai sus pot fi contopite rezultând o nouă diagramă mai complexă pentru a evidenția procesul de prelucrare a informațiilor privind raporturile dintre furnizori și clienți și implicațiile acestora asupra întregului subsistem CLIENȚI / DECONTĂRI.
Diagrama de mai sus prezintă sfera de cuprindere a aplicației. Pentru fiecare vânzare, prelucrarea notată cu 1 actualizează stocurile de mărfuri vândute pe baza elementelor conținute de comenzile primite de la CLIENȚI. La rândul lor, datele păstrate în D2 despre VÂNZĂRI, se folosesc în prelucrările notate cu 2 și 3, pentru pregătirea documentației pentru bancă, respectiv crearea rapoartelor necesare conducerii. Procesul de prelucrare notat cu numărul 4 valorifică informațiile despre VÂNZĂRI din D2, precum și pe cele despre stocurile de mărfuri din depozit, astfel încât să se poată determina necesarul de reaprovizionat. În situația în care se impune întocmirea de noi comenzi de aprovizionare, se valorifică datele din fișierul FURNIZORI, cum ar fi: prețul, adresa furnizorilor, termenele posibile de livrare, etc.
Diagrama scoate în relief și modul de prelucrare a comenzilor de aprovizionare. Rolul esențial îl are activitatea de stocare a datelor despre CLIENȚI, în D5, COMENZI_ÎN_CURS. Prin procedura de prelucrare numărul 5 se vor actualiza informațiile din D5, odată cu efectuarea procesului de recepție a mărfurilor primite de la FURNIZORI.
Se impun câteva comentarii pe marginea pe marginea diagramei fluxurilor de date privind desfacerea și aprovizionarea cu mărfuri:
diagrama fluxului de date stabilește aria de cuprindere a sistemului luat în studiu, precum și zonele din unitate implicate în operațiunile de prelucrare a datelor;
diagrama fluxului de date nu are un caracter tehnic. Chiar și simbolurile folosite sunt ușor de înțeles și utilizat;
diagrama fluxului de date prezintă atât datele stocate în sistem, cât și procesele de prelucrare prin care trec acestea, indicând relațiile existente între date sistemului și procesele de prelucrare.
Sintaxa diagramei fluxului de date și produsele CASE
Cele mai multe produse CASE oferă utilizatorului un sistem interactiv de lucru, prin mesaje de atenționare în cazul când se încearcă includerea unei construcții eronate într-o diagramă a fluxului de date sau sistemul refuză să accepte introducerea obiectului, fie în mod online, fie atunci când se solicită raportul de analiză pentru tentativa de includere a diagramei în repository.
Reguli sintactice verificare prin software:
au toate obiectele(entități externe, procese, locuri de stocare) câte un identificator?
au toate obiectele și fluxurile de date câte un nume?
au toate procesele cel puțin câte un flux de intrare și cel puțin un flux de ieșire? Dacă nu, de ce?
fiecare flux de date are legătură cu un proces? Dacă nu, ce s-a întâmplat? Fluxurile de date care fac legătura directă între o entitate externă și un loc de stocare sau direct între entități externe, fără un proces între ele sunt incorecte.
au toate fluxurile de date sensurile marcate prin săgeată?
Reguli sintactice care nu pot fi verificate ușor prin software:
au fluxurile de date un nume semnificativ?
au toate procese din diagramă un descriptor de forma “verb+substantiv-obiect-al-prelucrării”?
locurile de stocare a datelor reprezintă obiecte, fenomene sau evenimente de interes? Dacă nu, realizatorul aplicației poate să le explice conținutul?
există locuri de stocare care să aibă doar câte o intrare și o ieșire și care sunt fișiere intermediare fizice temporare?
se menține un control minim a multiplicărilor de simboluri, astfel încât la un număr mai mare de fluxuri de date să nu se realizeze intersectări care să creeze neînțelegeri?
II.2.1.2 Tehnica Yourdon & DeMarco
Această tehnică folosește simboluri diferite de cele utilizate de tehnica Gane & Sarson și, în plus, sugerează că demersul de realizare a diagramelor unui sistem trebuie să înceapă cu o diagramă de context, prin care să fie prezentate entitățile externe, intrările și ieșirile în / din sistemul analizat
Tehnica Yourdon & DeMarco sugerează că demersul de creare a diagramelor unui sistem trebuie să înceapă cu o diagramă de context, prin care să fie prezentate entitățile externe, intrările și ieșirile în/din sistemul analizat:
Yourdon și DeMarco recomandă cu insistență ca nici o diagramă să nu conțină mai mult de șapte procese de prelucrare (cercuri). Ca atare, un sistem complex trebuie să fie reprezentat printr-un set de diagrame, și anume:
o diagramă de context;
o diagramă de nivel zero, indicând principalele subsisteme ale sistemului;
până la șapte diagrame de nivel unu, indicând principalele funcții (aplicații) ale fiecărui subsistem;
până la 49 de diagrame de nivel doi indicând detaliile fiecărei funcții / aplicații.
Se recomandă ca funcțiile (aplicațiile) să fie explodate pe această cale până ce detaliile logicii procesului sau “primitivele” pot fi scrise pe cel mult o pagină de pseudocod. În cazul sistemelor complexe, apar totuși necesare nivelurile 3 și chiar 4.
În aceste condiții, diagrama fluxului de date privind desfacerea și aprovizionarea cu mărfuri este reprezentată în felul următor:
II.2.1.3 Diferențe între metodele de modelare logică a sistemelor Gane & Sarson și Yourdon & DeMarco
Există trei diferențe foarte importante între cele două metode:
metoda folosită la descompunerea diagramelor;
modelarea sistemului curent;
relația dintre DFD și modelul datelor.
Pentru reliefarea particularităților la explozie, următoarele elemente sunt sugestive:
b) indiferent de tipul sistemului analizat, manual sau informatizat, apare o problemă comună: el va fi înlocuit de un nou sistem. Modelul logic propus poate fi conceput pe baza modelului logic curent. Pașii următori pot fi efectuați parcurgând căi diverse. Scopul lor este de a conduce la implementarea modelului logic propus pentru a se putea ajunge la proiectul noului sistem fizic. Secvențial, întregul proces poate fi redat asfel:
În timp ce Yourdon și DeMarco recomandă parcurgerea secvențială a pașilor redați în figura de mai sus, Gane și Sarson adoptă o variantă ceva mai categorică. Ei consideră că fiecare proiect trebuie analizat minuțios pentru a se stabilidacă este mai bine să se pornească de la ceea ce există, pentru crearea modelului logic propus, sau trebuie abandonat totul și conceput un model ideal.
Gane și Sarson pornesc de la întrebarea: “Ce trebuie să facă viitorul sistem?” și, din ceea ce există, încearcă să contureze modelul sistemului nou. Sintetic, DeMarco redă procesul de analiză structurată prin șapte pași, iar Gane și Sarson prin cinci pași:
II.2.1.4 Tipuri de diagrame ale fluxurilor de date
Principalele tipuri de diagrame ale fluxurilor de date sunt: diagrama de context (DC), diagrama fluxului de date fizice (DFDF) și diagrama fluxului de date logice (DFDL).
Diagrama de context este diagrama de pe nivelul cel mai de sus al sistemului informațional, prin care se descriu fluxurile datelor în și din sistem, din și spre entitățile externe sistemului analizat așa cum reiese din figura următoare:
Pe marginea figurii de mai sus se pot face următoarele comentarii privind terminologia specifică diagramelor de context, pe lângă cea deja discutată. Cercul diagramei de context definește granițele sistemului. Granița reprezintă locul de separare a sistemului studiat de mediul său extern. Mediul constă în tot ceea ce înconjoară sistemul, entitățile diagramei fiind cele mai relevante elemente pentru specificarea mediului extern. Mediul relevant este acea parte a mediului care afectează “sistemul de interes”, după cum este el definit. În figura prezentată mai sus, numai CLIENT și BANCĂ sunt relevante din tot mediul extern.
Alt concept este interfața care este definită ca un flux de legătură al sistemului cu mediul său. În figura amintită, PLATĂ și DEPUNERE sunt interfețe. De asemenea, legăturile între componentele sistemului sunt considerate tot interfețe.
Diagrama fluxului de date fizice (DFDF) este o reprezentare schematică a sistemului prin care sunt scoase în evidență entitățile interne și externe ale sistemului, precum și fluxul datelor în și din aceste entități.
O entitate internă poate fi o persoană, un loc (secție, compartiment) sau un echipament (calculator) din sistem care contribuie la transformarea datelor. Din această cauză, DFDF specifică unde, cum și de cine este realizat acest proces al sistemului. DFDF scoate în relief ce este realizat. De exemplu, în figura ce urmează apare Client Plătește la Vânzător; Vânzător Justificare-vânzări la Casier, etc. deci, putem vedea unde merg banii și cum sunt păstrate informațiile privind încasările, dar nu știm cu exactitate ceea ce face vânzătorul.
Se observă că toate cercurile au în interior câte un substantiv și că fluxurile de date poartă un nume, prin care se sugerează cum datele sunt transmise între cercuri. De exemplu, Client transmite Bani la Casierie. Similar, se poate observa că locul amplasării fișierului indică unde (contabilitate), iar numele fișierului arată cum (Jurnal-vânzări) se ține evidența vânzărilor.
Diagrama fluxului de date logice (DFDL)
Este o reprezentare simbolizată a unui sistem, prin care se evidențiază procesele sistemului, precum și intrările sau ieșirile de date în / din procese. Prin ea se reprezintă natura logică a sistemului, ce activități efectuează sistemul, fără să specifice cum, unde sau de către cine sunt executate activitățile.
Avantajul DFDL față de DFDF este acela că putem reliefa funcțiile executate de sistem. De exemplu, în figura care urmează se poate observa că etichetele de fluxurile de date descriu mai degrabă natura datelor decât cum sunt transmise acestea. Este efectuată Plata sub formă de CEC, bani lichizi, în rate? Acest lucru nu rezultă din reprezentare. Jurnal-vânzări este un registru, o cartelă sau un fișier? Nici acest lucru nu rezultă din diagramă. In schimb, printr-o DFDL sunt reprezentate activitățile sistemului, în timp ce DFDF descrie infrastructura sistemului.
Procesele din figura de mai sus sunt specificate prin verbe care descriu acțiunea de executat, și nu prin substantive, folosite în DFDF. Această figură este o redare la nivelul cel mai înalt a cercului din diagrama de context întrucât fiecărui cerc din figura diagramei fluxului de date logice i se alocă un număr urmat de un punct și de un zero (1.0, 2.0, 3.0, 4.0); de aceea un asemenea tip de diagramă este denumită de nivel zero. Chiar dacă DFDF sunt numerotate în mod asemănător, nu se va folosi și în cazul lor noțiunea de nivel zero întrucât nu mai există alte niveluri inferioare.
Când două diagrame ale fluxurilor de date – diagrama de conrext și de nivel 0 – au fluxuri de date externe echivalente, se spune despre ele că sunt diagrame ale fluxurilor de date balansate. Numai seturile de diagrame ale fluxurilor de date balansate sunt corecte (cum sunt: diagrama de context, DFDL și DFDF). Pentru obținerea figurii precedente, diagrama de context a fost explodată în componentele sale de nivel inferior. Fenomenul de descompunere sau “explodare” a DFDL se numește descompunere descendentă sau de sus în jos. Când ea se efectuează corect, conduce la un set balansat de diagrame ale fluxurilor de date.
I.2.2 Modelarea logicii proceselor
Procesele trebuie să fie astfel descrise încât să poată fi convertite în programe prin intermediul limbajelor de programare.
În faza de analiză, modelarea logicii proceselor se va derula cât mai detaliat dar operațiunea nu va respecta structura sau sintaxa unui anumit limbaj de programare: aceasta se va realiza într-o etapă următoare în proiectare.
Modelarea logicii proceselor, ca și diagramele fluxurilor de date, reprezintă o parte a subetapei de structurare a cerințelor sistemului.
Se poate spune că modelarea logică se va concretiza în următoarele elemente ale documentației: reprezentarea în engleza structurată a logicii proceselor, reprezentarea logicii proceselor prin tabele de decizii, reprezentarea logicii proceselor prin arbori de decizie, tabelul sau diagrama stărilor de tranziție.
I.2.2.1 Reprezentarea logicii proceselor prin engleza structurată
Descrierea sub diverse forme a logicii după care sunt conduse anumite procese ajută la dipășirea momentului inițial, oferit prin simpla prezență a numelui procesului în DFD, din care reieșeau fluxurile de date spre, în și din el, fără alte detalii de genul cutiilor negre.
Engleza structurată este o formă mult simplificată și modificată a limbii engleze, folosită pentru descrierea conținutului casetelor care marchează procesele (prelucrările) din diagramele fluxurilor de date. Cuvintele folosite sunt în strânsă legătură cu logica folosită în conceperea procedurilor componente ale sistemelor informaționale. Se utilizează verbe ce se pot regăsi în structura sintactică a mai multor limbaje de programare, deși engleza structurată reprezintă o formă mai accesibilă unei categorii mai mari de persoane. Dintre verbe, cele mai des întâlnite sunt: READ, WRITE, PRINT, SORT, MOVE, ADD, SUBSTRACT, MULTIPLY, DEVIDE, MERGE. Se folosesc și substantive pentru descrierea structurii datelor, cum ar fi: CLIENT_ADDRESS, NAME, etc. Nu se folosesc adjective sau adverbe. Scopul unei astfel de forme a limbii engleze este de a înlesni accesul mai multor persoane la rezultatele analizei înglobate în documentație.
Nu există o formă standard de engleză structurată, iar fiecare analist ar putea prelua o versiune proprie, deși intențiile sunt și în acest caz îndreptate spre o oarecare standardizare.
Engleza structurată poate fi folosită pentru redarea tuturor structurilor de control fundamentale ale programării structurate: secvența, selecția și iterația.
Structura secvențială nu presupune o descriere anume, ci o enumerare a fazelor, unele după altele.
Selecția sau structura condițională poate fi redată astfel:
BEGIN
IF CANTITATE este mai mică decât STOC_NORMAT
THEN GENEREAZĂ o nouă comandă
END IF
Repetiția poate lua forma DO UNTIL sau DO WHILE. Spre exemplu, DO UNTIL se reprezintă astfel:
DO
READ articole fișier STOCURI
BEGIN IF
IF CANTITATE < MINIM_COMANDĂ
THEN GENERARE comandă nouă
ELSE DO nimic
END IF
UNTIL EndOfFile
Engleza structurată este folosită ca mijloc de comunicare între analiști și utilizatori. La rândul lor, analiștii comunică cu programatorii printr+un alt limbaj special, pseudocoduri.
I.2.2.2 Modelarea logicii proceselor cu ajutorul tabelelor de decizie
Atunci când se încearcă prezentarea logicii proceselor mai complexe, engleza structurată devine greu de înțeles dar nu și incapabilă să reprezinte algoritmii respectivi. S-a constatat că atunci când apar mai mult de trei IF-uri imbricate, ele sunt greu percepute de către cei ce le analizează. În astfel de cazuri intervin tabelele de decizie.
Tabelele de decizie reprezintă forme de reprezentare tabelară a logicii unor decizii. Pentru orice situație dată, un tabel de decizie conține toate condițiile (IF-uri) care pot interveni în procesul decizional precum și variantele THEN posibile, prin specificarea acțiunilor de întreprins. Forma generală a unui tabel de decizie este prezentată în tabelul următor:
Un exemplu în care se poate folosi un tabel de decizie este cel care scoate în relief regulile de funcțoinare a conturilor de activ și pasiv prin egalități contabile fundamentale.
În ciuda utilității lor, tabelele decizionale sunt mai puțin folosite în practică. Probabil rigurozitatea lor îi descurajează pe cei mai mulți dintre potențialii utilizatori.
I.2.2.3 Modelarea logicii proceselor prin arbori decizionali
Un arbore decizional este o tehnică de reprezentare grafică a unei decizii sau a unei situații bazate pe opțiuni prin intermediul nodurilor și ramificațiilor specifice structurilor arborescente.
Ca și tabelele de decizie, arborii decizionali sunt sugestivi în “dialogul” purtat de analiști cu utilizatorii. Întrucât sunt folosiți în structurarea cerințelor, arborii decizionali au două componente principale:
Punctele de decizie (reprezentate prin noduri);
Acțiunile (reprezentate prin elipse);
În figura următoare, voi da exemplul unui model de arbore decizional.
I.2.2.4 Modelarea logicii temporale a proceselor cu ajutorul diagramelor și tabelelor stărilor de tranziție
Modelele prezentate până acum nu reușesc să surprindă impactul factorului timp asupra logicii de execuție a unor operațiuni, ceea ce le face nerelevante pentru aplicațiile online și în timp real. În astfel de cazuri se folosesc diagramele sau tabelele stărilor de tranziție, concepute pentru a completa celelalte tehnici de modelare logică.
Diagramele stărilor de tranziție reliefează modul în care procesele unei DFD și alteori chiar stări diferite în timp ale aceluiași proces sunt ordonate în timp.
Tabelele stărilor de tranziție îndeplinesc același rol doar că prezentarea este sub formă tabelară, motiv pentru care voi prezenta doar prima formă.
Astfel de forme de redare a logicii sunt foarte folosite în analiza și proiectarea orientată pe obiect, dar pot fi utile și în realizarea sistemelor orientate pe proces.
Diagrama stărilor de tranziție
O stare poate fi concepută ca un mod sau o condiție de existență a unui proces sau a altei componente a sistemului, după cum sunt determinate de circumstanțele din curente sistem.
În concepția orientată pe obiect, o stare constă în totalitatea proprietăților obiectelor care sunt statice și a valorilor acestor proprietăți care sunt dinamice.
Există simboluri speciale pentru crearea diagramelor stărilor de tranziție:
Fiecare stare este reprezentată printr-un dreptunghi;
Fiecare tranziție se redă printr-o săgeată;
Evenimentul care declanșează tranziția de la o staere la alta apare ca o etichetă atașată săgeții tranziției. Poate fi precedat de C: (condiție);
Acțiunile demarate la înregistrarea unei stări noi apar ca o listă de instrucțiuni, scrise în pseudocod sau în engleza structurată, existând posibilitatea de a fi precedate de A: (acțiuni);
Fiecare stare va fi ordonată în timp (Conger, S. – The New Software Enginering, Belmond, TA: WADSWORTH Publishing Company, 1994); a doua stare o urmează pe prima, a treia pe a doua, ș.a.m.d.
Când se construiesc diagramele stărilor de tranziție, este util să se parcurgă două căi:
se stabilesc toate stările posibile ale sistemului și se evidențiază legăturile dintre ele;
se începe cu prima stare și apoi se analizează ce stări au legătură cu ea și se continuă cu analiza conexiunilor posibile ale fiecărei stări noi cu altele.
Se poate constata că diagramele stărilor de tranziție pot fi folosite și pentru redarea selecției opțiunilor din meniuri sau pentru reflectarea navigării în sistemele online gen Internet.
Figura următoare prezintă un model de diagramă a stărilor de tranziție:
I.2.3 Modelarea conceptuală a datelor
I.2.3.1 Importanță
Modelul conceptual al datelor înseamnă o modalitate de reprezentare a datelor organizației. Rolul său este de a scoate în relief toate regulile privind identitatea și legăturile existente între date.
Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama entitate-relație (DER). O modalitate aproape identică este folosită și în analiza și proiectarea orientate pe obiect.
Modelarea datelor prin DER prezintă caracteristicile și structura datelor independent de modul în care acestea sunt memorate în calculator. Modelul se crează iterativ. De cele mai multe ori, operațiunea are loc la nivel de întreprindere, prin apelarea la o categorie foarte largă de date, neglijându-se detaliile exagerate. Doar în etapele următoare, în speță când se trece la definirea proiectului, are loc construirea unui model anume entitate-relație, prin care să fie scoasă în evidență aria de întindere aproiectului. În timpul structurării cerințelor, un model entitate-relație reprezintă cerințele conceptuale de date pentru sistemul luat în discuție. După ce sunt descrise complet intrările și ieșirile sistemului în cadrul proiectării logice, modelul conceptual al datelor, redat sub forma entitate-relație, este rafinat înainte de a fi trecut într-un format logic (de regulă un model relațional al datelor) din care se definesc bazele de date și are loc proiectarea fizică a acestora.
În timpul modelării conceptuale a datelor, se produc și se analizează 4 diagrame entitate relație:
o DER care să acopere doar datele necesare aplicației proiectului. Ea va permite stabilirea necesarului de date ale aplicației proiectului, fără să se țină seama de constrângerile sau confuziile generate de detaliile care nu sunt încă necesare;
o DER pentru aplicația ce va fi înlocuită. Diferențele dintre aceste diagrame arată ce schimbări trebuie întreprinse pentru convertirea bazei de date în noua aplicație. Nu se aplică în cazul sistemelor complet noi;
o DER care să scoată în relief întreaga bază de date din care noua aplicație își va extrage datele. Cât timp mai multe aplicații pot folosi aceeași bază de date sau câteva baze de date, această diagramă și prima evidențiază modul în care noua aplicație apelează la conținutul unor baze de date mult mai extinse;
o DER pentru întreaga bază de date din care aplicația curentă își extrage datele necesare. Ea este discutată doar pentru sistemele care există și pentru care se urmărește îmbunătățirea. Din nou, diferențele dintre diagrama precedentă și cea de față vor indica modificările majore de efectuat pentru a se putea influența noua aplicație.
I.2.3.2 Introducere în cadrul conceptual al diagramelor entitate-relație (DER)
Diagramele entitate-relație constituie unul din conceptele esențiale ale analizei și proiectării structurate. După cum reiese chiar dint cititea nnumelui diagramei, scopul ei este de a evidenția entitățile de date (obiectele despre care se solicită păstrarea datelor) și relațiile ce există între ele.
Trebuie sesizată diferența dintre diagrama fluxului e date și diagrama entitate-relație. În timp ce DFD indică atât procesele de prelucrare, cât și entitățile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER tratează doar entitățile de date. Din această cauză, DER poate fi considerată și ca diagrama modelului datelor sau diagrama conceptuală a datelor.
Întotdeauna, crearea unei DER presupune găsirea răspunsului la întrebarea: “Care sunt entitățile despre care sunt necesare datele de stocat?”. Răspunsul poate fi destul de simplu. Depinde de aria de extindere a sistemului analizat. Ele ar putea fi: CLIENT, PRODUS, SALARIAT, STOC, FURNIZOR, ș.a.
În sistemul analizat, pentru descrierea DER se apelează la simbolul dreptunghi, pentru fiecare entitate. Se recomandă ca numele entității să fie redat printr-un substantiv la singular (CLIENT, PRODUS, SALARIAT, etc.).
După ce se identifică entitățile, se continuă cu împerecherea lor, fiecare cu fiecare, pentru a descrie ce relații există între ele.
De exemplu, pentru a arăta că o anumită vânzare se referă doar la un client, deși există mult mai multe acte de vânzare, implicit mai mulți clienți, relația poate fi redată schematic asfel:
O vânzare, la rândul ei, constă din unul sau mai multe produse, dar și produsele pot constitui subiecte ale mai multor vânzări, deci între entitățile VÂNZARE și PRODUS se va folosi câte o săgeată la fiecare capăt al liniei ce leagă cele două entități. Antrenând în sfera discuțiilor și comanda de aprovizionare, COMANDĂ, și furnizorul, FURNIZOR, s-ar putea construi următoarea diagramă entitate-relație:
În lucrul cu DER, o mare importanță în activitatea de analiză a acestora o deține cunoașterea faptului că întotdeauna relațiile multe-la-multe pot fi descompuse în două relații de tipul unu-la-multe, prin aflarea entității –intersecție.
Relația dintre PRODUS și VÂNZARE, de tim multe-la-multe, în forma ei inițială, poate fi redată astfel:
Descompunerea ei în două relații de tip unu-la-multe poate fi redată sub forma:
Entitatea-intersecție este ceva ce se va impune de la sine între cele două entități, putându-se marca momentul de căutare a noii entități:
Semnul de întrebare înlocuiește răspunsul care trebuie găsit la întrebările: Ce ar putea fi asociat cu entitatea generală simplă PRODUS care să poată da naștere la o legătură de tip multe?, precum și Ce anume s-ar putea asocia entității simple VÂNZARE, printr-o legătură de tip multe, dar care să exprime relația dintre produse și vânzări?. Răspunsul este clar: un articol anume, deoarece vânzarea constă din mai multe articole vândute prin aceeași tranzacție externă. Astfel, diagrama rezultată va arăta astfel:
Relațiile unu-la-unu, de asemenea, trebuie subuse analizei pentru a constata dacă într-adevăr cele două entități simple sunt total diferite și nu pot fi combinate în nici un mod. În exemplul anterior, există doar o singură relație unu-la-unu, cea dintre PRODUS și STOC. Dacă entitatea PRODUS va prelua elementele din STOC, atunci cea de-a doua poate dispărea. Este cazul tipic al nomenclatoarelor, care pot prelua și elemente ale unor fișiere de stare.
În urma analizelor efectuate asupra diagramei entitate-relație și a modificărilor aduse, rezultă o nouă diagramă:
Analiza entitate-relație este o operațiune deosebit de importantă pentru scoaterea în relief a datelor, a structurii lor. În unele metodologii, cum ar fi ingineria informației, aceasta constituie principalul instrument analitic, în timp ce în altele analizele entitate-relație se folosesc în combinație cu analizele fluxurilor de date.
I.2.3.3 Relațiile entităților
Relațiile reprezintă liantul între componentele unei diagrame entitate-relație. O relație este o asociere între cazurile/instanțele unei sau mai multor tipuri de entități care prezintă interes pentru organizație. Ele se pot simboliza printr-un romb. De regulă, sunt redate prin verbe.
Gradul relațiilor este reprezentat printr-un număr al tipurilor de entități care participă la o relație. Cele mai întâlnite relații în modelele entitate-relație sunt:
unare (grad unu);
binare (grad doi);
ternare (grad trei).
Pot exista grade și mai mari, dar în practică acestea sunt foarte greu de întâlnit. Cele trei grade ale entităților sunt exemplificate în figura următoare:
Cardinalitatea relațiilor este dată de un număr al cazurilor/instanțelor entității B care pot sau ar putea să fie asociate cu fiecare caz al entității A, presupunând că există două tipuri de entități, A și B, între care există o linie de legătură pentru a marca relația. Cardnalitatea este sugerată prin 0 (zero), 1, M (“multe”).
I.2.3.4 Tipuri de relații
În continuare voi prezenta tipurile de relații deja amintite, cu unele completări:
a) Relația unu-la-unu (1:1)
“Fiecare BIROU este condus de un, și numai un, MANAGER”
“Fiecare MANAGER conduce un, și numai un, BIROU”
b) Relația unu-la-multe (1:M)
“Fiecare VÂNZARE implică unul sau mai multe ARTICOL(e)_VÂNDUT(e)”
“Fiecare ARTICOL_VÂNDUT face parte din numai o VÂNZARE”
c) Relația multe-la-multe (M:N)
“Fiecare FURNIZOR livrează unul sau mai multe PRODUS(e)”
“Fiecare PRODUS este livrat de unul sau mai mulți FURNIZOR(i)”
d) Relații opționale și obligatorii
Uneori, relațiile dintre entități nu-și fac simțită prezența în toate situațiile. Un exemplu elocvent ar fi cel în care un student poate lucra la un singur proiect sau la câteva, sau la nici unul și, invers, un proiect poate fi realizat de un student, de mai mulți sau de nici unul. În astfel de situații, se apelează la următoarea formă de reprezentare:
Cercul suprapus pe latura entității indică, de fapt, poziția zero (valoarea minimă poate fi zero), conferind relației caracterul opțional.
Un alt aspect se referă la caracterul obligatoriu al relațiilor. Cu alte cuvinte, o entitate poate exista fără cealaltă? Spre exemplu, nu poate exista nici o vânzare fără cel puțin un articol vândut și, invers, un articol nu poate fi vândut fără a exista un act de vânzare.
e)Relația unei entități cu ea însăși
În practică apar și situații în care o entitate este pusă în relație cu ea însăși. Un exemplu ar putea fi cel al entității ANGAJAT. Unii dintre ei dobândesc statutul de coordonatori ai activității celorlalți, situație în care se poate apela la o diagramă de genul:
“Un angajat poate fi coordonatorul unuia sau mai multor angajați”
“Oricare angajat întotdeauna raportează altui angajat”
f) Relații alternative (sau/sau)
Uneori se ivesc situații când relațiile posibile se redau alternativ: fie o variantă este de urmat, fie cealaltă.
De exemplu, o marfă destinată vânzării poate fi realizată de unitatea care o vinde sau poate fi procurată din afară. În ambele cazuri, obiectul comercializat, MARFA, care este o entitate, va fi pusă în legătură cu cele două surse posibile, PRODUCȚIA_ALTORA și PRODUCȚIA_PROPRIE, printr-un punct comun, dar cu linii de relații distincte:
“O marfă se poate asocia sau cu un producător din afară, sau cu producția unității”
“Un producător din afară poate livra mai multe mărfuri”
“O linie proprie de producție poate livra mai multe mărfuri”
I.2.3.5 Reguli economice regăsite în diagramele entitate-relație
Modelarea conceptuală a datelor este un proces pas-cu-pas pentru documentarea cerințelor informaționale, concretizată în preocuparea de regăsire a structurii datelor, dar și a regulilor prin care se oferă încredere în integritatea acestora.
Regulile economice constituie specificații/descrieri care oferă integritatea modelului logic al datelor. Există patru tipuri de bază ale regulilor economice:
Integritatea entității. Fiecare caz/instanță al/a unei entități trebuie să aibă un identificator unic (valoarea cheii primare), care nu trebuie să fie nul.
Regulile de stabilire a relațiilor dintre entități. Regulile referitoare la relațiile dintre tipurile de entități.
Domenii. Restricții privind valorile ce pot fi luate de atribute.
Declanșatori. Sunt luate în considerare alte reguli economice care protejează validitatea atributelor.
Aspectele privind regulile impuse de afacere sunt urmărite în timpul procesului de determinare a cerințelor sistemului și se păstrează în depozitul CASE, dacă se apelează la astfel de tehnici de lucru.
Capitolul II
PROIECTAREA SISTEMELOR INFORMAȚIONALE
Proiectarea logică se derulează prin intermediul a trei pași sau subfaze:
proiectarea formularelor/formatelor (pentru preluarea datelor) și a rapoartelor, prin intermediul cărora utilizatorii vor avea imaginea intrărilor și ieșirilor noului sistem;
proiectarea interfețelor și a dialogurilor, pentru evidențierea modului de comunicare a utilizatorului cu softul de sistem;
proiectarea bazelor de date logice, prin care este descrisă structura standard a bazei de date a sistemului ce va fi ușor de implementat prin multitudinea de tehnologii existente în domeniul bazelor de date.
Toate intrările și ieșirile fazei de proiectare logică vor fi prezentate ca fluxuri ale datelor între un proces manual și altul automat sau între o sursă/destinație și un proces automat din diagramele fluxurilor de date. De regulă, se poate proiecta câte un formular sau raport pentru fiecare flux de date dintre utilizator și sistem.
Totuși, punctul de plecare în modelarea logică îl constituie diagramele entitate-relație, deși, în plus, vor fi utilizate nu numai datele din acestea, ci și cele descoperite în timpul proiectării logice. Similar, din diagrama de acțiuni vor fi preluate evenimentele ce declanșează acțiunile utilizatorului, semnalate prin meniuri, butoane, comenzi date calculatorului.
II.1 Proiectarea formularelor și a rapoartelor
Datele elementare conținute de fluxurile de date înseamnă, în același timp, și conținuturile formularelor de intrare sau ale rapoartelor și răspunsurilor la întrebări. Datele formularelor sau rapoartelor pot fi date elementare ale locurilor de stocare și ale datelor din modelul entitate-relație al aplicațiilor sau pot fi calculate pe baza acestor date elementare.
Un formular poate fi un document primar sau o machetă de ecran care conține unele date predefinite, cărora li se adaugă altele ce urmează a fi completate în rubrici special rezervate.
Din punct de vedere structural, un formular este un element tipărit, cu antet și alte componente pretipărite, precum și cu spații (rubrici) pentru completarea cu date. Într-un sistem de prelucrare automată a datelor, formularul este asociat imaginii afișate pe ecran, identică formularului tipărit. Datele afișate din formulare sunt cunoscute sub numele de date constante, în timp ce elementele ce vor fi completate sunt numite date variabile. Imediat ce datele variabile au fost completate pe formular, în câmpurile corespunzătoare, formatul devine o înregistrare (articol) sau o tabelă.
Majoritatea formularelor au în structură patru elemente determinate: introducerea, instrucțiunile, partea principală (corpul) și concluziile.
Introducerea, în general, trebuie să apară la începutul formularului și să conțină titlul acestuia, numărul său și, dacă formularul trebuie distribuit altcuiva, numele și adresa organizației respective.
Instrucțiunile sunt de două feluri: ele precizează fie modul de completare a formularului, fie destinația lui după completare. Uneori, numele elementelor de completat sunt atât de clare încât nu mai necesită informații speciale pentru completare. De regulă, formularele cu un pronunțat caracter tehnic, necesită mai multe informații în partea principală sau pe verso. Instrucțiunile în legătură cu ceea ce trebuie făcut cu formularul trebuie să fie foarte clare, specificându-se pentru fiecare exemplar unde trebuie să ajungă. În proiectarea acestor formulare trebuie să se urmărească o cât mai simplă formă de realizare.
Partea principală este cea care concură la utilizarea unor formulare cât mai simple. Relațiile logice dintre căsuțe trebuie să fie grupate; căsuțele și coloanele trebuie să fie foarte clar conturate, și evident, locul unde trebuie completate, mai ales când datele din el vor fi supuse prelucrării automate.
Concluziile apar la sfârșit și se referă la înregistrarea informațiilor cu privire la dispozițiile finale și/sau la aprobările necesare în leg’turile cu operațiile consemnate, incluzând semnăturile și data. Dacă este vorba de un formular cu operațiuni financiare, el trebuie să conțină și totalul formularului.
De asemenea, la proiectarea formularelor trebuie să se mai țină seama și de alte principii. De exemplu, în funcție de importanța documentului se va alege tipul de hârtie corespunzător iar caracterele din interiorul lui vor fi tipărite în forme variate. Părțile lui trebuie să fie marcate distinct și în concordanță cu standardele existente.
Un raport este un document economic în care sunt incluse doar date predefinite, ceea ce înseamnă că poate fi numit și document pasiv, folosit în mod exclusiv pentru a fi citit sau vizualizat.
Obiectivul prezentării detaliate a ieșirilor este și acela de a determina formularul și conținutul tuturor rapoartelor imprimate, ale documentelor și ecranelor formulate de sistem. Conceperea ieșirilor se va face astfel încât să răspundă și cerințelor utilizatorilor, și celor ce se ocupă cu proiectarea.
Cele mai multe rapoarte au o formă excelentă de prezentare, când se apelează la instrumentele grafice. Cantități mari de date pot fi condensate în câteva pagini de rapoarte grafice, ce pot fi mult mai ușor interpretate decât rapoartele cu coloane. Pachetele de programe moderne au o multitudine de facilități de lucru în mod grafic.
În funcție de momentul elaborării rapoartelor, ele pot fi clasificate în patru categorii:
rapoarte programate (la termen) – au un conținut predeterminat și formatul lor este dinainte stabilit; aici se încadrează rapoartele realizate lunar pentru fiecare compartiment, analizele săptămânale ale vânzărilor, precum și dările de seamă financiar-contabile.
Analizele neprogramate cu rol special – deseori numite și rapoarte ad-hoc, nu au conținutul și forma dinainte stabilite și nu sunt realizate conform unor programări anterioare. Ele sunt elaborate ca răspuns la întrebările managerilor privind anumite probleme de planificare managerială.
Rapoartele declanșate de excepții. Au un conținut predeterminat și un format anume, dar sunt elaborate numai când sunt realizate unele condiții de excepție (depășirea costurilor, stocuri supradimensionate, etc.).
Rapoartele la cerere – au conținut și formă predetrminate dar sunt elaborate numai ca răspuns la cererea managerilor sau a altor angajați. Atât rapoartele declanșate de excepții, cât și cele la cerere explică puterea sistemelor bazate pe calculatoare de a fi deosebit de eficiente în procesul conducerii.
II.1.1 Aspecte tehnice ale proiectării formularelor și rapoartelor
Atât formularele, caât și rapoartele constituie cele mai interesante piese ale sistemului pentru utilizatorii acestuia. Proiectarea ieșirilor trebuie să se realizeze după un anumit procedeu-cadru, specific prortipizării, ca în figura de mai jos: (Naumann, J.D., Jenkens, A.M. – Prototyping: The new paradigm for systems development, 1993)
În timpul procesului de proiectare a formularelor și rapoartelor trebuie să se găsească răspunsuri la întrebările: cine, ce, când, unde, cum, conform următorului model:
Cine este beneficiarul formularului, raportului sau răspunsului la întrebări?
Ce trebuie să conțină formularul, raportul sau răspunsul la întrebări?
Când se solicită obținerea ieșirilor?
Unde să fie transmis formularul, raportul sau răspunsul la întrebări și unde să fie folosit?
Cum se vor utiliza ieșirile respective? Câte persoane le vor folosi sau le vor vedea?
II.1.2 Evaluarea satisfacției utilizării ieșirilor
Atunci când utilizatorul evaluează performanțele formularelor sau rapoartelor, operațiunea se referă la câteva aspecte esențiale și anume: viteza cu care se efectuează o activitate, precizia rezultatelor obținute, satisfacția folosirii ieșirilor respective.
Utilizatorul privește formularele și rapoartele din punctele lui de vedere, care pot fi prezentate astfel:
Stabilitate (consistență) – presupune folosirea acelorași termeni, abrevieri, formate, titluri și metode de navigare în toate ieșirile sistemului
Eficiența – formatarea trebuie să se deruleze în strânsă concordanță cu sarcinile de executat. Textele trebuie să fie aliniate, coloanele sortate, deplasarea facilă. Pe cât este posibil, ar trebui să fie evitate introducerile de date necesare obținerii ieșirilor
Comoditate – să nu se facă trimiteri la fișiere anterioare, să se folosească etichete clare, precum și factori de scală corespunzători
Format – formatul informației trebuie să se mențină pentru aceleași tipuri de date și să scoată în evidență ceea ce este important
Flexibilitate – trebuie să i se ofere utilizatorului posibilitatea de a lista în modurile dorite de el, de a opri procesul și de a naviga în locurile dorite.
În concluzie, satisfacția în utilizare s-ar putea rezuma la: timpul de învățare, viteza în execuție, rata erorilor, rezistența în timp (stabilitatea), satisfacții subiective.
II.2. Proiectarea interfețelor și a dialogurilor
Noțiunea de interfață este destul de des întâlnită în literatura informatică deși ea are și o accepțiune generală în limbajul curent, în sensul de element de legătură între două unități.
Referindu-se la software-ul de sistem, Schulteis, Sumner și Bock (Schulteis, R., Sumner, M., Bock, D. – Management information szstems: The Manager’s view, second edition Irwin, Homewood, Boston, 1992, p. 123) afirmă că “prin intermediul echipamentelor electronice de calcul și a unui timp anume destinat, software-ul sistemelor acționează ca o legătură sau o interfață între sistemul de calcul și programele de aplicații pe care utilizatorul dorește să le execute”. De cele mai multe ori, funcția de legare între ele a două componente este realizată de un subsistem special proiectat în acest scop.
Specificațiile de proiectare a interfețelor și dialogurilor se pot concretiza într-o formă similară celei descrise la proiectarea formularelor și rapoartelor, cu un element suplimentar: descrierea secvenței de derulare a dialogurilor.
Sinteza elementelor specificației de proiectare a interfețelor și dialogurilor este redată în caseta următoare:
Dialogul
Dialogul, în informatică , are aceeași semnificație ca și în accepțiunea cotidiană: conversație între doi parteneri.
Datorită importanței sale, dialogul, în multe componente informatice – cum ar fi sistemele de sprijinire a procesului decizional sau sistemele expert – , dispune de un subsistem propriu de funcționare. Subsistemul de management al dialogurilor (Zwass, V. – Management information systems, C. Brown Publishers, Dubuque, 1992) a fost redat schematic în caseta de mai sus.
Caracteristica principală a sistemelor performante în privința dialogurilor o constituie diversitatea formelor de introducere a datelor și extragerea rezultatelor. Inteligența artificială a adăugat o calitate deosebită a dialogului: utilizatorul poate să spună ceea ce dorește sau să activeze sistemul prin voce.
II.3. Proiectarea logică a bazelor de date: modelarea logică a datelor
Capitolul de față este în strânsă legătură cu modelarea conceptuală a datelor, aceasta însemnând reprezentarea modului de organizare a datelor, independent de tehnologiile specifice de prelucrare a bazelor de date, fără să se înregistreze o preocupare anume referitoare la calitatea modelelor de date.
Prin modelarea logică se urmărește atingerea a trei obiective:
Structurarea pe formantă a datelor prin procesul de normalizare;
Obținerea unui model logic al datelor în care să se poată realiza proiectul bazei de date fizice, adică modelul relațional – cel mai utilizat în prezent, deși se pot obține și moelele rețea, ierarhice sau oreientate pe obiect.
Realizarea unui model al datelor care să răspundă cerințelor actuale de date regăsite în formulare și rapoarte. Modelarea logică este un proces ascendent (bottom-up) de obținere a relațiilor din formulare și rapoarte, numirte și perspectiva sistemului prin prisma utilizatorului. Va urma o integrare a relațiilor disparate din formulare și documente într-un model logic, consolidat al datelor. De asemenea, va fi prezentat modul de transformare a modelului entitate-relație într-o formă relațională, astfel încât modelul conceptual să fie comparat cu cel logic al datelor pentru desprinderea și rezolvarea diferențelor dintre ele.
Modelarea logică a datelor descrie datele cu ajutorul unei notații speciale care corespunde unui mod de organizare a acestora de către un sistem de gestiune a bazelor de date relaționale, numit și model relațional.
Procesul de modelare logică a datelor se derulează în paralel cu celelalte activități ale proiectării logice: proiectarea formularelor și a rapoartelor și proiectarea dialogurilor și interfețelor. Modelarea logică a datelor se realizează nu numai pe baza diagramei entitate-relație, ci și pe baza machetelor, formularelor și a rapoartelor. Se efectuează analiza datelor elementare din intrările și ieșirile sistemului pentru a se desprinde legăturile dintre ele.
Procesul de modelare a datelor este complex. În fiecare etapă a ciclului de viață al sistemelor se regăsește câte o activitate specifică a datelor, conform tabelului următor:
În procesul de modelare logică există patru pași esențiali:
realizarea unui model logic al datelor din perspectiva utilizatorului (formulare și rapoarte) privind aplicația, folosindu-se principiile normalizării;
contopirea tuturor perspectivelor normalizate ale utilizatorilor într-un model logic consolidat (centralizat al datelor). Pasul mai este numit și integrarea perspectivelor;
transformarea modelului conceptual al datelor (entitate-relație), realizat fără să se țină cont de perspectiva utilizatorului, într-un set de relații normalizate;
compararea modelului logic consolidat al datelor cu modelul transformat al entității-relației și realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicației.
II.3.1 Simplificarea structurii datelor prin normalizare
În rocesul de analiză a cerințelor unui sistem, pot fi identificate și descrise punctele de vedere ale unei mulțimi de utilizatori. Deseori, numărul perspectivelor utilizatorilor despre aceeași bază de date poate fi de ordinul zecilor. Fiecare are în vedere anumite date elementare din baze. De exemplu, într-o “situație a absolvenților” sunt surprinse 8 date elementare: MATRICOLA_STUDENT, NUME_STUDENT, SPECIALIZAREA, COD_EXAMEN, TITLU_EXAMEN, NUME_EXAMINATOR, SALĂ_EXAMINATOR, NOTA. La o analiză mai atentă însă rezultă că aceste date elementare aparțin câtorva entități, cum sunt: STUDENT, CURS, EXAMINATOR.
Principala problemă a proiectării logice a bazelor de date poate fi redată astfel: dată fiind dimensiunea meta-datelor (date despre date) colectate în procesul de studiere a cerințelor sistemului, se pune problema cum ar trebui proiectat moelul conceptual al datelor pentru a reprezenta meta-datele cât mai natural și complet, în cea mai simplă formă și cu cea mai mică redundanță posibilă. Cu alte cuvinte, cum ar trebui combinate datele elementare pentru a forma relații (sau tipuri de înregistrări) care să descrie entitățile și relațiile dintre ele? În limbajul bazelor de date, cuvântul relație, înseamnă un tabel de date ceea ce duce la concluzia că bazele de date relaționale sunt clădite pe un grup de tabele legate între ele.
Scopul normalizării este să reducă complexitatea imaginilor pe care le au utilizatorii la seturi de structuri mai mici și mai stabile.
Pașii parcurși în normalizare sunt redați schematic în următoarea figură:
Prima formă normalizată
O relație este normalizată dacă conține numai valori elementare la intersecția fiecărei linii cu o coloană, deci relația normalizată nu conține grupuri care se repetă.
Pentru normalizarea unei relații care conține un singur grup ce se repetă, se extrage grupul și se vor forma două noi relații. Procesul de separare este redat în următoarea figură:
Cele două relații por fi descrise astfel:
relația STUDENT conține atribute care nu fac parte din grupul ce se repetă. Ea conține MATRICOLA_STUDENT, NUME_STUDENT și SPECIALIZAREA. Cheia primară a relației este MATRICOLA_STUDENT.
Relația EXAMEN_STUDENT conține atributele grupului care se repetă. Cheia primară este una compusă, formată din MATRICOLA_STUDENT și COD_EXAMEN. MATRICOLA_STUDENT este cheie primară în prima relație, în timp ce COD_EXAMEN este un atribut care identifică fiecare disciplină de examen din grupul repetat pentru fiecare student. Numai prin cele două atribute se poate identifica o anumită notă a unui absolvent. Cheile compuse sau concatenate sunt tipice (dar nu ca o regulă generală), ca rezultat al normalizării.
Anomalii la inserare: presupunem că dorim să inserăm noi date în relația a doua pentru un nou examen (codul și titlul). Operațiunea nu se poate rezolva până nu apare un student care să intenționeze să dea un examen, deoarece matricola student este componentă a cheii compuse. La fel s-ar întâmpla și dacă am dori să introducem și numele unui nou profesor examinator.
Anomalii la ștergere: studenții de la unele secții au posibilitatea să-și aleagă disciplinele examenului de licență. Să presupunem că o anumită disciplină, codificată DA (Dreptul afacerilor) a fost opțiunea unui singur student. Dacă studentul nu promovează, operațiunea de ștergere a acestui tuplu este firească, numai că ea va duce și la pierderea datelor despre disciplina amintită și profesorul examinator.
Anomalii la actualizare: dacă se schimbă titulatura unei discipline de examen, operațiunea va fi foarte anevoioasă deoarece trebuie căutați toți studenții care au optat pentru ea.
Anomaliile de mai sus apar deoarece unele atribute care nu sunt cheie în relație depind numai de atributul COD_EXAMEN și nu de întreaga cheie primară (MATRICOLA_STUDENT și COD_EXAMEN). Doar NOTA este un atribut ce depinde de toată cheia. Pentru cazurile cînd un atribut depinde total de cheia compusă, se spune că este total dependent de acea cheie, iar când dependența este numai în funcție de o parte a cheii compuse, se spune că acel atribut este parțial dependent de cheia primară.
A doua formă normalizată (2NF)
După cum reiese și din schema generală a normalizării, operațiunea de eliminare a unor anomalii rezultate după prima formă a normalizării, prin extragerea dependențelor funcționale parțiale, constituie obiectivul celei de-a doua forme de normalizare.
O relație este în forma a doua normalizată dacă ea se află deja în prima formă și dependențele funcționale parțiale i-au fost extrase.
Pentru transformarea unei relații cu dependențe parțiale în forma a doua normalizată, se vor crea alte două relații (din cea existentă); una cu atributele total dependente de cheia primară și cealaltă cu dependențe de anumite părți ale cheii primare.
Relația EXAMEN_STUDENT se decompune în alte două relații, astfel:
Relația INREG_NOTA, cu cheia compusă (MATRICOLA_STUDENT+COD_EXAMEN) și cu un atribut non-cheie (total dependent de cheia primară). ÎNREG_NOTA este în cea de-a treia formă normalizată (3NF).
Relația EXAMEN_PROF, cu cheia primară COD_EXAMEN, are atributele non-cheie TITLU_EXAMEN, NUME_EXAMINATOR, SALA_EXAMINATOR (toate dependente numai de COD_EXAMEN).
Se observă că anomaliile din a doua fază au fost eliminate în noile relații- în relația EXAMEN_PROF, o disciplină de examen apare o singură dată (am pornit de la premisa că un examen se dă doar cu un profesor), ceea ce duce la efectuarea, cu ușurință, a operațiunii de actualizare (să presupunem că s-a schimbat examinatorul), prin intervenția doar asupra unui tuplu. Și încă un element pozitiv: prin separarea totală a datelor de spre examene de cele despre studenți, pot fi adăugate și șterse disciplinele de examen, fără să aibă legătură cu datele despre studenți.
Deși lucrurile par a fi rezolvate, la o analiză mai atentă se poate constata că ar mai fi fost posibile unele filtre, atât timp cât în relația EXAMEN_PROF se ascunde entitatea PROFESOR. Diagrama dependențelor din relația EXAMEN_PROF este redată în figura următoare:
Se observă că fiecare din atributele non-cheie este dependent de COD_EXAMEN, dar SALA_EXAMEN depinde și de NUME_EXAMINATOR. Pentru forțarea notei, s-ar putea considera că fiecare profesor poate să examineze în propriul cabinet (unde poate fi repartizat singur), și atunci fiecărui profesor îi va fi atribuită o altă sală. Într-un astfel de caz putem spune că se înregistrează o dependență tranzitivă, ceea ce ar însemna că atributul non-cheie (SALA_EXAMINATOR) este dependent de unul sau mai multe atribute non-cheie (cum ar fi NUME_EXAMINATOR).
Dependențele tranzitive simple apar sub forma:
Când își fac apariția, dependențele tranzitive conduc la generarea anomaliilor în procesele de inserare, ștergere și actualizare, ca și în cazul celor parțiale.
Anomalii la inserare: dacă s-ar intenționa introducerea datelor despre un nou profesor în relația EXAMEN_PROF, se constată că operațiunea este realizată prin intermediul cheii primare COD_EXAMEN, deci, cât timp un profesor nu are de susținut unul dintre examenele de licență nu poate apărea în baza de date.
Anomalii la ștergere: ștergerea datelor despre o anumită disciplină conduce și la pierderea datelor despre profesorul examinator respectiv.
Anomalii la actualizare: dacă un profesor examinează studenții la mai multe discipline, el apare în mai multe tupluri, deci actualizarea ar însemna căutări multiple în bază și schimbarea datelor despre acel profesor la fiecare apariție a sa.
A treia formă normalizată (3NF)
Se poate spune despre o relație că se află în a treia formă normalizată dacă ea este în cea de-a doua formă și nu conține dependențe tranzitive.
O relație în cea de-a treia formă normalizată are relațiile de dependență simple astfel:
Extragerea dependențelor tranzitive din relația EXAMEN_PROF este prezentată în figura următoare:
Atributele non-cheie NUME_EXAMINATOR și SALA_EXAMINATOR vor constitui noua relație, PROFESOR, în care NUME_EXAMINATOR este cheie primară, considerându-se totuși că NUME_EXAMINATOR identifică în mod unic SALA_EXAMINATOR.
În relația EXAMEN, atributul NUME_EXAMINATOR este non-cheie, însă apare subliniat prin linie punctată pentru a se sugera faptul că el este cheie primară în cadrul altei relații (foreign key), PROFESOR.
După toate operațiunile efectuate până în acest moment, normalizarea este terminată. Astfel, din relația nenormalizată NOTE_ABSOLVENȚI s-au desprins următoarele relații în cea de-a treia formă normalizată: STUDENT, INREG_NOTA, EXAMEN și PROFESOR. Anomaliile descrise anterior nu-și mai pot face simțită prezența.
Dincolo de cea de-a treia formă a normalizării
Pentru produsele CASE este suficient ca relațiile să fie prezentate în cea de-a treia formă normalizată pentru a se spune că sunt concepute cu atenție și că anomaliile nu-și mai fac apariția. Cu toate acestea, cercetătorii din domeniu au descoperit că, în anumite condiții, acestea încă mai pot exista, ceea ce a condus la continuarea pașilor normalizării. Astfel, pot fi menționați pași suplimentari ai normalizării, cum ar fi: normalizarea în forma Boyce-Codd (BCNF), normalizarea în forma a patra (4NF), forma normalizată domeniu-cheie (DK/NF).
II.4. Proiectarea bazelor de date
Accepțiunea bazei de date nu este, din păcate, unanim formulată. Conceptul este asociat altuia, banca de date. Într-o definiție funcțională, baza de date ar fi văzută ca un set de fișiere intercorelate. Legăturile dintre fișiere sunt identificate și reprezentate prin intermediul legăturilor dintre relații (tabele), redate sub forma modelelor conceptuale și logice ale datelor. Ele constituie punctul de plecare în proiectarea fizică a bazelor de date, precedată de proiectarea fișierelor fizice.
Când se proiectează arhitecturile bazelor de date, trebuie să fie luate în considerare mai multe aspecte, dintre care determinantă este mărimea sistemului. De fapt, arhitecturile scot în evidență modalitățile de definire și structurare a datelor.
Selectarea arhitecturii adecvate organizației revine ca sarcină analiștilor bazelor de date, dar analistul de sistem are o contribuție importantă. Sistemele de gestiune a bazelor de date servesc operațiunii de implementare a uneia dintre cele patru arhitecturi cunoscute: ierahică, rețea, relațională și orientată-obiect.
Modelul ierarhic al bazelor de date
Modelul ierarhic al bazelor de date este unul dintre cele mai vechi modele arhitecturale ale bazelor de date și poate fi încă folosit în organizațiile mari, în care prioritară este prelucrarea unui imens volul de tranzacții. Arhitectura modelului ierarhic este prezentată în figura următoare:
Modelul rețea al bazelor de date
Acest model poate fi utilizat în situații mult mai complexe, datorită posibilității de asociere a unui număr arbitrar de fișiere, însă, ca urmare a dificultăților tehnice de folosire, doar specialiștii de înaltă clasă pot apela la un astfel de model. Modelul rețea este prezentat în figura următoare:
Modelul relațional al bazelor de date
Pentru majoritatea utilizatorilor, reprezintă unicul model utilizabil, din cauza proliferării lui îndeosebi pe platformele bazate pe PC-uri, celelalte modele fiind, practic, inexistente pentru ei.
Legăturile dintre relații se realizează prin cheile lor, în varianta cheie-primară cheie-străină, conform figurii următoare:
Modelul orientat-obiect al bazelor de date
Acest model se bazează pe procesul de încapsulare a atributelor și metodelor (funcțiilor) în structuri numite clase de obiecte. Esența modelului este redată în figura de mai jos.
Literatura efectuează chiar o ierarhizare a arhitecturilor bazelor de date (Sculteis, R., Sumner, M., Bock, D. – Management Information Systems – The Manager’ View, Secon edition, IRWIN, Homewood, 1992, p. 205), după cum urmează:
Generația I: structuri de fișiere
Generația a II-a structuri ierarhice
Generația a III-a structuri rețea
Generația a IV-a structuri relaționale
Generația a V-a structuri orientate-obiect.
Datorită unor rezultate remarcabile obținute pe plan tehnologic, au apărut concepte noi, cum sunt: baze de date distribuite, baze de date hypermedia sau mașini de baze de date.
Bazele de date distribuite, în mod firesc asociate altui concept, acela de prelucrare distribuită, sunt baze de date stocate în cel puțin două locuri diferite, în varianta în care copii ale bazei de date sau părți ale ei sunt stocate în locuri diferite, de unde se poate asigura și întreținerea ei.
Bazele de date hypermedia trateză datele prin intermediul unei rețele de noduri, legate între ele în orice mod posibil, conform doleanțelor utilizatorului. Nodurile pot conține text, grafică, sunet, imagine animată și programe executabile. Datorită flexibilității definirii nodurilor, prin utilizarea unor realizări din domeniul inteligenței artificiale, se mai numesc și baze de date inteligente.
II.5. Proiectarea securității fișierelor și bazelor de date
În faza proiectării fizice a fișierelor și bazelor de date, un aspect foarte important îl constituie controlul acestora, ceea ce înseamnă preocupări pe linia securității “averilor” informaționale. Securitatea este abordată din mai multe puncte de vedere, dar cea referitoare la fișiere presupune luarea unor măsuri pentru reconstituirea datelor pierdute sau prelucrate eronat, precum și pentru blocarea accesului neautorizat sau incomodarea până la a face imposibilă citirea datelor, prin criptare, atunci când ele sunt accesate ilegal.
Așadar, două aspecte vor fi relevante: reconstituirea datelor și criptarea lor.
II.5.1 Reconstituirea datelor
Reconstituirea datelor este des asociată cu existența fișierelor back-up, însă în practică este posibilă reconstituirea fără apelarea la acest tip de fișiere. Prima variantă, pe bază de fișier back-up, este cunoscută și sub numele de reconstituire înainte (forward recovery), iar cealaltă, fără fișier back-up, este numită reconstituire înapoi (backward recovery). Cele două variante de reconstituire sunt prezentate în figurilede mai jos.
În vederea controlării corectitudinii datelor despre tranzacții, se apelează la fișiere cu rol special care conțin un istoric, în ordine cronologică, al schimbărilor și accesărilor efectuate asupra fișierelor sau bazelor de date. Aceste fișiere se numesc probe în auditare. Ele, împreună cu alte fișiere, cum ar fi registrul tranzacțiilor, vor conține imaginea înregistrărilor înainte și după modificare, copii ale datelor despre tranzacții, precum și alte informații. Toate acestea, în mod sintetic, pot fi enumerate astfel:
elemente de identificare a tranzacției;
elemente de identificare a operatorului/utilizatorului;
valoarea tranzacției;
imaginea unui câmp înaintea efectuării unei schimbări;
imaginea câmpului după efectuarea tranzacției;
tipul operației efectuate;
data operației efectuate;
data și momentul din zi când a avut loc tranzacția;
echipamentul pe care s-a efectuat operațiunea, etc.
Proba în auditare va servi la reconstituirea fișierelor distruse, dar și la verificarea corectitudinii operațiunilor de actualizare. Operațiunea se efectuează de experți contabili specializați în sisteme informatice.
II.5.2 Criptarea datelor
Securitatea criptografierii se referă la asigurarea transformării datelor de comunicat într-o formă neinteligibilă pentru toți ceilalți receptori, exceptându-l pe cel autorizat.
Criptologia se ocupă de studierea scrierii secrete. Criptografia este știința scrierii secrete. Criptanaliza este arta obținerii semnificației scrierii secrete fără să se posede cheia folosită.
Există două feluri de scriere secretă: prin coduri și prin cifruri.
Într-un cod, un simbol sau un șir de simboluri poate avea semnificația unui mesaj complet. Într-un cifru există o corespondență biunivocă, unu-la-unu, între simbolurile mesajului original și simbolurile formei echivalente din scrierea secretă (textul criptat). Transformarea textului original în forma lui criptată se numește criptare, iar operațiunea inversă este decriptarea.
Transformările sunt controlate prin intermediul cheilor. Dacă aceeași cheie se folosește la criptare și decriptare, se spune că se apelează la cifrul simetric. În cazul opus, cifrul este asimetric.
Criptarea a devenit una dintre cele mai puternice modalități de asigurare a securității datelor. Ea poate fi realizată prin sistemul de operare sau prin sistemele de gestiune a bazelor de date, dar și prin rutine mai simple, create de către specialiștii sistemului.
Capitolul III
APLICAȚIA “CONTIUS”
Contius este un program de gestiune-contabilitate generală care permite ținerea evidenței contabile, a gestiunii, situației clienți-furnizori, a diferitor statistici pe furnizori, produs, agent, etc., a încasărilor si plăților, obținerea jurnalelor de vânzare-cumpărare, de înregistrări contabile, etc., pentru un număr nelimitat de societăți.
Programul a fost dezvoltat cu ajutorul mediului Visual C++ 6.0, sistemului de gestiune a bazelor de date MS SQL Server 2000, instrumentelor Crystal Reports 6.5 (Seagate Software), PowerAMC (Sybase) și ActiveSkin (SoftShape).
Conceput pe arhitectura client-server, programul poate rula atât local (pe un singur calculator), cât și într-o rețea de calculatoare – caz în care clienții se vor conecta la motorul SQLServer aflat pe calculatorul-server.
III.1 Instrumente folosite – scurtă descriere
Visual C++ 6.0 – considerat cel mai puternic mediu de dezvoltare a aplicațiilor pentru Windows; include suport pentru programarea COM (Component Object Model), SDK (Software Development Kit), MFC (Microsoft Foundation Classes), GUI (Graphic User Interface), DirectX, ș.a. Este disponibil în trei ediții: standard, profesională și pentru întreprinderi. Visual C++ este un membru al familiei de produse pentru dezvoltarea aplicațiilor Visual Studio 6.0, care mai include:
Visual Basic
Visual FoxPro
Visual InterDev
Visual J++
Visual SourceSafe
MSDN Library
Visual C++ folosește biblioteca MFC – o ierarhie de clase scrise în C++ care oferă programatorilor cea mai mare parte a codului necesar pentru gestionarea ferestrelor, meniurilor, casetelor de dialog și a altor resurse, executarea operațiilor input/output de bază, utilizarea colecțiilor obiectelor de date, etc.
Microsoft SQL Server 2000 – sistem de gestiune a bazelor de date relaționale ce conține un set de componente care lucrează împreună pentru a oferi posibilitatea stocării/regăsirii datelor și analizelor necesare în orice întreprindere. Dintre principalele trăsături, merită menționate:
Integrare pentru Internet: motorul SQLServer 2000 are integrat suportul pentru XML (Extensible Markup Language – un limbaj de programare hypertext utilizat pentru a descrie conținutul unui set de date și modul în care acest set de date trebuie afișat într-o pagină Web). Dispune, de asemenea de scalabilitatea și securitatea necesare manipulării datelor conținute în site-uri Web foarte complexe;
Scalabilitate și disponibilitate: motorul bazelor de date poate fi folosit pe o gamă largă de platforme, de la laptop-uri utilizând Windows 98, până la servere multiprocesor care utilizează Microsoft Windows 2000 Data Center Edition;
Baze de date la nivel de întreprindere: SQLServer 2000 protejează integritatea datelor, minimizând în același timp sarcina gestionării a sute de utilizatori care modifică, în același timp, o anumită bază de date. Interogările distribuite permit folosirea datelor din surse multiple ca și cum ar face parte dintr-o singură bază de date. Operațiile de replicare permit menținerea mai multor copii a datelor importante, asigurând sincronizarea acestora în mod automat.
Instrumente pentru extragerea și analiza datelor necesare procesărilor anlitice online, proiectarea în mediul visual a bazelor de date și analiza datelor folosind interogări bazate pe engleza structurată.
Crystal Reports 8.5 – proiectat pentru a lucra cu o gamă foarte largă de baze de date, ajută la analiza și interpretarea informațiilor importante dintr-o întreprindere. Permite crearea de rapoarte complexe ce pot fi folosite ca atare, integrate în diverse aplicații sau publicate prin intermediul Internetului. Formulele, subrapoartele, formatarea condiționată și alte asemenea instrumente sunt doar câteva din trăsăturile softului produs de Seagate Software.
PowerAMC – instrument CASE de concepere a bazelor de date ce oferă toate avantajele abordării conceperii bazelor de date din două perspective: conservarea modelelor atât la nivel conceptual, cât și fizic. Cu ajutorul PowerAMC este posibilă:
Conceperea unui sistem informațional utilizând diagrama entitate-relație denumită Modelul Conceptual al Datelor;
Generarea modelului fizic al datelor corespunzător, pentru un sistem de gestiune a bazelor de date țintă, ținând cont de caracteristicile specifice acelui SGBD;
Generarea unui script de creare a bazei de date pentru SGBD-ul țintă;
Generarea automată a declanșatorilor (triggers) referitori la integritatea referențială;
Generarea unui model fizic al datelor pornind de la o bază de date și chiar de la un script de creare a unei baze de date, ș.a.
ActiveSkin – este un control ActiveX care shimbă aspectul visual al formelor sau casetelor de dialog, oferind utilizatorilor finali un mediu de lucru mult mai tentant decât în aplicațiile Windows comune.
III.2. Tehnologii folosite
Aplicația Contius folosește, în principal, două tehnologii: una dintre ele, ADO, permite legarea sa la baza de date SQL Server iar cealaltă, ActiveX, permite folosirea unor componente ActiveX în diferite scopuri (realizarea unei interfețe tentante, folosirea suportului oferit de Crystal Reports pentru generarea de rapoarte, utilizarea tabelelor de tipul celor folosite în Access pentru afișarea datelor, etc.)
ODBC (Open Database Connectivity) a reprezentat primul pas în direcția accesului la o bază de date relațională, de către o aplicație. Odată cu dezvoltarea Internetului, dezvoltatorii de programe s-au confruntat cu dilema dezvoltării propriilor paradigme ale accesului la date, sau extinderea utilizării Interfeței pentru Programarea Aplicațiilor (API) dovedită, de altfel, incompatibilă pentru astfel de medii. ActiveX Data Objects (ADO), împreună cu OLE DB (Object Linking and Embedding Database) au rezolvat această dilemă prin oferirea unui model care lucrează cu toate sursele de date, într-o varietate de medii de dezvoltare.
ADO oferă un acces performant la date, indiferent dacă este vorba de o aplicație front-end sau un browser de Internet. ADO a fost introdus prima dată ca interfață de acces al datelor în Microsoft Internet Information Server (IIS), în momentul de față devenind interfața la nivel de aplicație a tehnologiei OLE DB.
Modelul obiectual ADO cuprinde o colecție de obiecte programabile ce pot fi folosite în Visual Basic, Visual C++, Java și orice platformă care suportă programarea COM. Modelul obiectual ADO conține șapte obiecte:
Connection
Command
Parameter
Recordset
Field
Property
Error
Și patru tipuri de colecții:
Fields
Properties
Parameters
Errors
Următoarea figură arată relațiile dintre ele:
III.3. Structura aplicației
Aplicația este compusă din două module principale, dezvoltate în același mediu (Visual C++) dar care folosesc sisteme de gestiune a bazelor de date diferite. Această modularizare are un caracter strict demonstrativ. Astfel, am dorit să arăt că două SGBD-uri diferite pot conlucra prin intermediul unei singure interfețe, mai precis a unei singure aplicații front-end.
Primul modul – modulul Contabilitate generală – reprezintă “inima” aplicației și folosește motorul SQL Server 2000. Permite ținerea evidenței contabile la un număr nelimitat de firme, indiferent de specificul activității: comerț en-gros și en-detail, producție, servicii, organizații non-profit (fundații) sau bugetari. Cel de-al doilea – modulul Personal-Salarizare – folosește o bază de date Paradox și oferă posibilitatea calculării salariilor pentru angajați cu contract de muncă – acord sau regie -, colaboratori cu convenție civilă, reprezentanțe străine (plata în valută sau lei), atât pentru societăți comerciale, cât și pentru bugetari.
În cazul primului modul, se introduc documentele de intrare și ieșire (facturi, chitanțe fiscale, avize de expediție, bonuri consum), încasările și plățile (chitanțe, ordine de plată, CEC, efecte comerciale), eventualele compensări, intrările și ieșirile de mijloace fixe.
Programul permite folosirea de discount-uri comerciale și financiare, cu agenți (pentru regim distribuție). De asemenea, se oferă utilizatorului situații centralizatoare pentru toate documentele primare, note contabile.
Rezultă:
jurnale de vanzări-cumpărări;
evidența stocurilor (mai multe gestiuni = un singur cont de gestiune sau un cont de gestiune = mai multe gestiuni).
generare și tipărire NIR-uri;
operațiuni import-export, clienți și furnizori externi; casa și banca, operațiuni în valută;
balanțele furnizorilor / clienților, fișa furnizorului /clientului, lista furnizorilor neachitați, clienților datornici;
balanța mijloacelor fixe, fișa mijlocului fix, calculul amortizării medii lunare, a valorii totale amortizate și a valorii rămase de amortizat; evidențierea modificării valorii mijlocului fix prin noi intrări; înregistrarea vânzării și ieșirii din evidență a mijlocului fix;
jurnalul de bancă și jurnalul de casă, cu regularizarea automată a plafonului de casă, tipărirea registrelor de casă și de bancă în lei sau valută;
statistici privind produsele: cantități intrate într-o anumită perioadă, de la o anumită firmă, pe un anumit carnet de facturi, dintr-o gestiune anume, adaosul comercial respectiv, TVA aferent;
note contabile automate, care pot fi transferate automat în jurnalul de înregistrări contabile;
jurnalul de înregistrări contabile (se introduc și alte note contabile pe langă înregistrările contabile efectuate automat; pentru cele des utilizate, se creează modele, care pot fi ulterior apelate (ex: pentru repartizarea profitului, impozit pe dividende);
închidere automată a conturilor de TVA, închidere automată de venituri și cheltuieli;
urmărirea mișcărilor patrimoniale în cursul unei luni sau de la începutul anului;
fișe de cont sintetice, analitice, subanalitice, pe luna curentă sau de la începutul anului;
balanța contabilă (sintetică, analitică, subanalitică) cu 4 egalități;
arhivarea exercițiilor închise, schimbarea planului de conturi;
rețetar și calcul de consum normat (pentru producție sau industrie alimentară);
bilanț (situația patrimoniului și contul de profit și pierderi), în șabloane adaptabile de utilizator;
declarații TVA și impozit pe profit, în șabloane adaptabile de utilizator.
În ceea ce privește modulul “Personal-Salarizare”, acesta permite:
crearea automată a fișelor fiscale și a tuturor situațiilor necesare raportării electronice a impozitului pe venitul global, inclusiv regularizarea anuală;
crearea fișelor fiscale în format electronic, cu salvarea lor automată pe dischetă și crearea borderoului (deci tot ceea ce este necesar raportării pentru organele fiscale);
calculul net de la brut (arătând și costul pentru firmă al angajatului respectiv);
calculul primei, în cazul în care salariul este echivalentul în lei al unei sume în valută (care poate crește lunar, datorită modificării cursului);
calculul concediului medical și al celui de odihnă;
lucrul cu sporuri (vechime, ore suplimentare, toxicitate, noapte, alte sporuri), precum și cu rețineri (rate, CAR, penalități), avansuri și avansuri în cazul concediilor de odihnă;
folosirea unor variante diverse de state de plată pentru angajați și colaboratori, state de avans și fluturași, astfel încât utilizatorul să-și poată alege varianta care i se potrivește cel mai bine;
calcularea obligațiilor firmei, atât pentru colaboratori, cât și pentru angajați;
tipărirea ordinelor de plată către buget sau pentru plata în contul angajaților (colaboratorilor);
tipărirea ordinelor de plată, a raportărilor CAS, CASS, fondului de risc, listelor de angajați;
tipărirea situației cu personalul încadrat, cu cei plecați sau proaspăt angajați.
Datorită modului diferit în care firmele calculează salariile (privind sporurile sau impozitele reținute angajatului), modulul poate fi configurat astfel încât fiecare să își poată calcula salariile conform modelului propriu.
Utilizatorul poate adapta grilele de impozitare, coeficienții de deducere personală, coeficienții pentru taxe și impozite, pentru concedii medicale, tipul de sporuri (permanent sau nu).
Modulul permite, de asemenea, arhivarea și consultarea arhivei pentru o lună anterioară. Datele pot fi salvate pe dischetă în mod automat, și ulterior restaurate.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Analiza Sistemelor Informationale. Modelarea Conceptuala a Datelor (ID: 149037)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.