Proiectare Sisteme Informatice

Partea I INTRODUCERE ÎN ANALIZA ȘI PROIECTAREA

SISTEMELOR INFORMAȚIONALE

1. Noțiuni de bază și definiții

Informatica: activitate pluridisciplinară orientată spre proiectarea și exploatarea sistemelor de prelucrare a informațiilor, în scopul eficientizării și rentabilizării activității umane. După dicționarul explicativ DEX, informatica este știința care se ocupă cu studiul prelucrării informației cu ajutorul calculatoarelor.

Sistemul: o secțiune a realității în care se identifică un ansamblu de elemente, interconectate printr-o mulțime de relații reciproce, precum și cu mediul înconjurător și care acționează în comun în vederea realizării unor obiective bine definite. Fiecare sistem are un comportament specific, determinat de natura elementelor din care este compus și de relațiile dintre ele. Un exemplu de sistem (mecanic) este cutia de viteză din compunerea automobilelor.

Sistemul informațional: o definiție sumară care “ține aproape” de definiția sistemului, ar putea prezenta sistemul informațional drept ansamblul elementelor de structură organizatorică din compunerea unei secțiuni a societății umane, împreună cu legăturile funcțional-informaționale dintre ele și cu mediul social exterior, care acționează în comun pentru îndeplinirea scopului și obiectivelor stabilite.

O definiție mai riguroasă [3] consideră sistemul informațional ca fiind un ansamblu tehnico-organizatoric de proceduri de constatare, consemnare, culegere, verificare, transmitere, stocare și prelucrare a datelor, în scopul satisfacerii cerințelor informaționale necesare conducerii procesului fundamentării și elaborării deciziilor.

Sistemul informatic se interpune între sistemul condus și sistemul de management, ca în figura de mai jos [3].

Obiectivul sistemului informațional este satisfacerea cerințelor informaționale necesare conducerii în procesul de elaborare a deciziilor.

Activitățile care se derulează în cadrul sistemului informațional sunt următoarele:

culegerea și consemnarea datelor primare de la locurile unde au loc procesele și fenomenele economice, precum și din spațiul economic extern;

verificarea, transmiterea și stocarea datelor pe diferiți purtători tehnici de informații;

prelucrarea manuală sau automată a datelor în concordanță cu cerințele conducerii;

selectarea informațiilor necesare conducerii conform principiului selecției și informării prin excepție.

Sistemul informatic constă din partea automatizată a sistemului informațional (utilizatorii implicați în automatizare și cadrul organizatoric aferent) căreia i se adaugă și alte elemente necesare pentru automatizarea obținerii informațiilor necesare conducerii în procesul de fundamentare și elaborare a deciziilor și anume : echipamente (hardware), programe (software), comunicații, o bază științifică și metodologică precum și baza informațională.

Baza științifică și metodologică constă din modele matematice ale proceselor și fenomenelor economice, metode și tehnici de realizare a sistemelor informatice.

Baza informațională se referă la datele supuse prelucrării, fluxurile informaționale, sistemele și nomenclatoarele de coduri.

Odată cu dezvoltarea cercetării operaționale, a teoriei deciziei, a Internetului și a performanțelor calculatoarelor, au apărut sisteme informatice dedicate cum ar fi sistemele suport de decizie și sistemele expert, dar și unele sisteme informatice de tip nou ca cele pentru proiectare asistată de calculator, sistemele multimedia, sistemele pentru comerțul elctronic și sistemele deschise.

Sistemele suport de decizie sunt colaboratori ai decidentului, în timp ce sistemele expert sunt sisteme de inteligență artificială și se comportă ca un expert, adică rezolvă o mare parte din procesul elaborării deciziilor, dar bineînțeles sunt avute în vedere numai deciziile referitoare la problemele pentru care sistemul expert a fost conceput.

Sistemele suport de decizie trebuie să dispună de o componentă de gestiune a modelelor, una de gestiune a datelor, una de asigurare a comunicației și interfața cu utilizatorii.

Sistemele expert trebuie să dispună de o bază de cunoștințe, o bază de fapte, un spațiu de lucru, mecanisme rezolutive (de raționament și de inferență) mecanisme explicative și interfața utilizator.

În general cei care produc soft aplicativ nu prea au de ales în ce privește tipurile de sisteme enumerate mai sus, pentru că tipul de sistem depinde de natura datelor și prelucrărilor ce se vor executa în acel sistem. Astfel dacă într-o problemă criteriile sunt preponderent cantitative, iar caracteristicile problemei se formulerază cantitativ, modelarea se face foarte bine algoritmic și deci vom alege un sistem informatic.

Dacă avem de a face cu formulări mai mult calitative decât cantitative atunci ne vom orienta asupra unui sistem suport de decizie sau a unui sistem expert, care nu exclud algorimii, dar presupun și baze de cunoștințe.

Sistemele informatice tradiționale folosesc baze de date relaționale, dar în prezent se afirmă tot mai mult sistemele orientate obiect.

Baza de date este un sistem de colecții de date între care există o interdependență logică multiplă, potrivit unor relații prestabilite cu ocazia definirii structurii datelor, destinat satisfacerii operative a celor mai diverse solicitări provenite din partea unor grupuri diferite de utilizatori. Utilizatorii bazelor de date sunt: administratorul, programatorii de aplicații și utilizatorii finali. Pentru lucrul cu baza de date ei dispun de o interfață soft, numită Sistemul de Gestiune a Bazei de Date (SGBD). Unele aplicații încă mai folosesc fișiere.

Fișierul este o colecție de date omogene din punct de vedere al naturii, conținutului informativ și a criteriilor de prelucrare, conservată pe o memorie externă, în concordanță cu restricțiile impuse de procesul de prelucrare automată a datelor, pentru satisfacerea cerințelor de informare a unuia sau mai mulți utilizatori.

Obiectul constituie componenta elementară dintr-un sistem orientat obiect.

Fiecare obiect posedă o stare, un comportament și o identitate. Starea este formată din ansamblul de valori ale atributelor sau proprietăților obiectului, comportamentul poate fi definit ca ansamblul de operații pe care le poate executa obiectul, setul de responsabilități asumate sau de servicii oferite altor obiecte, iar identitatea se referă la modul de reprezentare și de conservare a individualității fiecărui obiect, indiferent de transformările sau sau schimbările de stare prin care va trece.

Practic pentru a genera un obiect trebuie să avem definită clasa de care aparține obiectul.

Clasa seamănă foarte bine cu tabelul din bazele de date, adică putem să o descriem și apoi să generăm exemplare (instanțe) din acea clasă de obiecte numai că ea nu are numai atribute ci are și operații, adică comportament. O operație este implementată printr-o metodă.

Obiectele se interacționează prin mesaje.

In programarea cu obiecte se disting aspecte ca moștenirea, polimorfismul, abstractizarea, încapsularea, reeutilizarea și persistența.

Analistul de sisteme informatice este specialistul care concepe și realizează sisteme informatice. Această funcție poate fi ocupată de specialiști proveniți din rândul absolvenților de facultate având specializarea matematică-informatică, cibernetică economică, contabilitate și informatică de gestiune sau alte specializări asemănătoare, dar și de alți specialiști cu studii superioare cum ar fi ingineri, fizicieni, economisti, etc. care au făcut ulterior cursuri de analiști-programatori.

Se impune să remarcăm că elaborarea sistemelor informatice este un act de mare răspundere. Această afirmație este justificată de investiția relativ mare care trebuie făcută pentru a informatiza o intreprindere/instituție, de volumul mare de muncă necesar pentru realizarea sistemului informatic (de regulă de ordinul a 1-2 ani-om și chiar mai mult), de impactul social al trecerii activității pe calculator. Ca urmare, între proiectant (unitatea/societatea de informa-tică, unde sunt angajați analiștii) și beneficiar, adică intreprinderea sau instituția care va folosi sistemul informatic, se încheie un contract având ca obiect realizarea sistemului informatic.

Este de la sine înțeles că analiștii ar trebui să cunoască specificul intreprinderii/instituției în care va funcționa sistemul informatic, intreprindere care în raport cu unitatea de informatică la care lucrează analistul, este o unitate beneficiară. Cum analiștii nu pot, să cunoască specificul tuturor unităților beneficiare cu care ar putea veni în contact în decursul timpului, în echipa de realizare a sistemului informatic se cooptează și specialiști din partea unității beneficiare, care să aibă idee de ceea ce se poate face cu calculatorul, dar mai ales să știe foarte bine ce vor de la calculator, în contextul viitorului sistem informatic. Se crează deci o echipă mixtă de realizare a sistemului informatic

Este bine să se știe că orice aplicație, pe lângă faptul că rezolvă problema pentru care a fost concepută, trebuie să respecte și legislația în domeniu, astfel încât rezultatele obținute cu ea să fie recunoscute de organele de control cum ar fi garda finaciară, curtea de conturi, ș.a. Nerespectarea unor prevederi legale în vigoare, referitoare la procedura (modelul matematic și algoritmul) prin care se redactează anumite documente, competența celor care avizează și semnează astfel de documente, termenele de elaborare, numărul de exemplare, durata lor de păstrare, siguranța datelor, păstrarea secretului (dacă este cazul), etc., pe considerentul că problema a fost rezolvată pe calculator, nu absolvă pe cel în cauză, de răspundere pentru încălcarea legislației!

2. Structura sistemelor informatice

În conformitate cu abordarea funcțională, sistemele informatice sunt organizate pe subsisteme, aplicații și unități funcționale sau proceduri logice. Pentru programatori mai sunt relevante încă două nivele, inferioare unității funcționale și anume, unitatea de prelucrare sau procedura automată și modulul program . În general, subsistemul vizează o funcție a unității beneficiare sau un domeniu de activitate din unitatea în care este conceput sistemul. Aplicația vizează o activitate, iar unitatea funcțională o subactivitate sau sarcină.

Aplicația este un pachet de programe ce servește la automatizarea prelucrării datelor aferente unei activități distincte din cadrul unui domeniu de activitate (de exemplu poate exista o aplicație pentru elaborarea statelor de plată, denumită pe scurt aplicația “salarii”). Într-o aplicație pot fi implicate mai multe elemente de structură organizatorică. De exemplu în elaborarea statelor de plată este implicat nu numai biroul financiar, care este titular pentru această activitate, ci și serviciul personal, sau dacă sistemul de plată presupune pontaj, va fi implicat dispeceratul, secretariatul, etc.. Împlicarea mai multor elemente de structură organizatorică într-o aplicație complică schema funcțională a aplicației, dar de cele mai multe ori, prezența mai multor elemente este inevitabilă.

De regulă aplicațiile se derulează ciclic și pentru a fi mai ușor trecute pe calculator, ciclul lor de viață se descompune în subactivități cum ar fi preluarea datelor și actualizarea bazei de date, sau cea de elaborare liste de ieșire sau rapoarte, sau etapa de elaborare informații pentru alte aplicații, etc.

Procedura logică sau unitatea funcțională este corespondentul subactivității din cadrul unei aplicații din domeniul informatizării. Numai la acest nivel se poate face ușor, trecerea directă de la structura logică a aplicației la programe, ceea ce înseamnă că unei unități funcționale i se pot asocia din softul aplicației, una sau mai multe unități de prelucrare sau proceduri automate. Ultima situație este necesară mai ales atunci când și în cadrul unei unități de prelucrare, sunt implicate mai multe elemente de structură organizatorică.

În contextul unităților funcționale, elonale, elementele de structură organizatorică folosesc calculatorul în sesiuni de lucru la calculator când, de cele mai multe ori, nu se rulează un singur program, ci una sau mai multe proceduri automate.

Procedura automată este o secvență bine definită de programe (module program), care odată

lansată în execuție, se rulează după o schemă logică, fără întrerupere, până la sfârșit. De exemplu preluarea pe calculator, validarea și stocarea fișelor de pontaj pentru salarii poate constitui o procedură în cadrul aplicației numită salarii. Faptul că procedura se rulează întotdeauna până la sfârsit, nu înseamnă că programele care fac parte din procedură se vor rula toate de fiecare dată; rostul schemei logice care stă la baza procedurii, este tocmai acela de a decide în funcție de parametrii introduși de utilizator și de felul cum decurge rularea, care program să se ruleze și care să fie sărit, astfel încât procedura să înfăptuiască un act coerent, rațional, să permită utilizatorului să controleze situația, mai precis să înfăptuiască o etapă sau măcar acea parte dintr-o etapă din ciclul de viață al unei aplicații, care-i revine biroului sau secției din care face parte utilizatorul respectiv.

Există și proceduri manuale care deși nu fac obiectul programării, ele pregătesc prelucrarea automată a datelor, sau după caz, finalizează această acțiune. Proiectantul sistemului infor-matic, trebuie să țină seama de procedurile manuale și să facă referiri la ele în cadrul etapei de proiectare logică și fizică precum și ulterior în cadrul manualelor de utilizare și respectiv de exploatare, pentru că abia împreună cu aceste proceduri sistemul informatic este complet.

Structura sistemului informatic trebuie să fie cât mai puțin dependentă de structura organizatorică a intreprinderii/instituției pentru care s-a conceput sistemul. Acest lucru asigură sistemelor informatice o viață mai lungă, făcându-le să nu depindă de frecventele schimbări de structură organizatorică, care au loc de obicei în secțiunile sociale unde sunt implementate și care, dacă sistemul s-ar baza pe ele, ar face ca acesta să trebuiască a fi actualizat, pentru fiecare modificare de structură.

3. Concepția logică de principiu a sistemului informatic

În secțiunea 2 s-a specificat că sistemele informatice sunt structurate pe subsisteme, aplicații, unități funcționale, unități de prelucrare sau proceduri și module program. Merită remarcat că, indiferent de nivelul său, orice componentă a sistemului informatic presupune intrări, prelucrări și ieșiri, iar relațiile dintre componente se realizează prin intermediul unei baze informațio-nale, care există și în sistemul informațional, dar în condițiile informatizării, va fi reflectată în colecții omogene de date ce pot fi organizate în baze de fișiere sau date în funcție de sistemul specific de gestiune a datelor (SGF sau SGBD).

Concepția logică concretă a unui sistem informatic dat se elaborează în etapa de proiectare logică, dar este bine să știm încă de pe acum ce este o concepție logică de principiu a sistemului informatic. Un asemenea model cuprinde:

a) Intrările în sistemul informatic: sunt acele modificări ale sistemului informațional care produc schimbări în colecțiile de date, adică tranzacțiile externe. Adeseori, modificările pe care tranzacțiile externe le produc direct colecțiilor de date induc și un al doilea val de modificări ale acestora, sub forma tranzacțiilor interne. Astfel o factură ce însoțește o tranșă de materiale venite de la furnizor este o tranzacție externă, pentru că modifică soldul materialelor cuprinse în factură, dar ea induce și o modificare a soldului furnizorului respectiv, ceea ce este o tranzacție internă.

Reprezentarea schematică a concepției logice de

principiu a sistemului informatic

Tranzacțiile externe provin din exteriorul sistemului electronic de calcul, în timp ce tranzacțiile interne sunt produse de procedurile de actualizare și exploatare a colecțiilor de date. Este de datoria analistului de sisteme informatice să identifice încă din etapa de proiectare logică efectele secundare ale intrărilor în sistem și să consemneze necesitatea procedurilor care vor materializa aceste efecte asupra colecțiilor de date, adică vor efectua tranzacțiile interne ce se impun logic.

b) Prelucrările sistemului informatic: sunt efectuate de procedurile sistemului informatic și prin ele se urmărește să se realizeze actualizarea și exploatarea colecțiilor de date. Dacă baza informațională este formată din ansamblul entităților informaționale și a atributelor pe care acestea le au, colecțiile de date preiau numai mulțimea atributelor entităților din baza informațională, așa numitul nucleu de informații. Legăturile dintre entități apar atunci când ele au atribute comune. Mulțimea entităților informaționale din baza informațională trebuie să fie unică și neredundantă. Ea trebuie să asigure un fond centralizat de informații care să asigure obținerea ieșirilor solicitate de beneficiarul sistemului informatic.

c) Ieșirile sistemului informatic: sunt grupate în patru categorii:

– indicatori sintetici (ex. cifra de afaceri, profitul brut, fondul de rulment, capitalul propriu, rata rentabilității, etc.);

– liste sau situații de ieșire, care grupează indicatori sintetici sau analitici sub formă de tabel;

– grafice care redau dinamica indicatorilor sintetici sau analitici;

indicatori sintetici și analitici stocați pe suporturi magnetice care urmează a fi transmiși altor sisteme informatice;

Dată fiind complexitatea actului de elaborare a unui sistem informatic, de-a lungul timpului în acest domeniu s-au aplicat diferite concepții/paradigme și metodologii.

4. Metode de abordare a sistemelor informatice

Nu este greu de înțeles că realizarea unui sistem informatic, sau doar a unei aplicații, presupune modelarea situației reale și utilizarea modelului creat, în realitatea cu care operează calculatorul.

Modelarea este reprezentarea într-un mediu controlat, a proprietăților și/sau fenomenelor și proceselor care caracterizează un obiect sau un sistem real. Cu alte cuvinte în modelare nu există adevăr absolut; modelarea presupune abstracție și aducerea în atenție numai a unor aspecte ale realității studiate și anume acele aspecte care prezintă interes pentru modelator. Unul din mediile controlate în care se poate reproduce realitatea, deci unul în care se pot face modele, este calculatorul. Pe calculator se realizează modele informaționale.

Modelul informațional este o abstracție a unei entități și această abstracție poate fi făcută fie pentru a crea un model general (de referință) care să fie apoi folosit pentru a crea exemple concrete de sisteme informatice (cazul arhitecturilor de referință), fie pentru a crea modelul informatic al unei entități anume, deci un model de transpunere. În cele ce urmează ne vom referi exclusiv la modele de transpunere.

La crearea modelului intervine viziunea analistului despre realitatea pe care o studiază, adică paradigma. Paradigma reprezintă "ochelarii" prin care analistul vede sistemul informațional real, acela pe care vrea să-l modeleze, dar nu toate viziunile sau concepțiile analiștilor ajung să fie considerate paradigme. La începuturile existenței sistemelor informatice, atenția analiștilor a fost concentrată spre latura funcțională a activității umane studiate și cum o funcție a unui birou sau secție nu putea fi analizată și nici prelucrată în bloc, ea a fost descompusă în activități (rezultând aplicațiile informatice), activitățile au fost descompuse în subactivități (rezultând procedurile), care la rândul lor au fost descompuse în operații, cărora în calculator le corespondeau modulele program. S-a dezvoltat în aceste condiții o abordare funcțională a sistemelor informaționale.

În informatica industrială funcției îi corespunde procesul, ceea ce a dus la abordarea orientată spre proces.

Ulterior, locul fișierelor a fost luat de bazele de date și corespunzător, locul sistemelor de gestiune a fișierelor a fost luat de sistemele de gestiune a bazelor de date (SGBD).

Pe parcursul perfecționării SGBD-urilor, s-a trecut la baze de date relaționale, creându-se impresia că elementul principal pe baza căruia trebuie perfecționate SGBD-urile îl reprezintă structura datelor. Avem astfel de a face cu o abordare orientată spre date.

Când s-a pus problema aplicațiilor în timp real, factorul cel mai important se părea a fi evenimentul. A apărut astfel orientarea spre evenimente.

Structurarea programelor a evoluat și ea odată cu metodele de analiză, dar era din ce în ce mai greu de ținut pasul cu metoda de analiză, mai exact cu orientarea abordării sistemelor informatice. Preocupările analiștilor-programatori pentru a pune în concordanță structura programelor cu metoda de analiză a sugerat o nouă abordare și anume legarea evenimentelor de obiect și a programelor (numite de astă dată metode) de evenimente.

A apărut astfel orientarea pe obiecte, numai că spre deosebire de celelalte abordări, ea se extinde și în alte domenii de activitate, devenind un mod de a concepe realitatea, adică o paradigmă.

Dată fiind complexitatea sistemelor informatice ele nu se pot obține dintr-odată și nici nu se pot realiza după cum crede fiecare programator. Desigur la început așa a fost, dar pe măsură ce s-a acumulat experiență, ea a fost materializată în metodologii.

Metodologia elaborării sistemelor informatice a fost concepută inițial ca un ansamblu de principii și indicații, tehnici și metode grupate și ordonate ca să ducă la realizarea sistemului informatic. Cuvântul “metodă” folosit în această definiție nu are nimic de a face cu metoda-program asociată evenimentelor unui obiect și nici cu metoda de abordare a sistemelor informaționale. Aici prin metodă se înțelege un set de reguli aplicabile unui domeniu restrâns din cadrul unei metodologii.

In prezent metodologia este văzută ca setul finit, particular definitoriu al unei metode (metodă de abordare a sistemelor informatice), prin intermediul unui sistem coerent de formulare și/sau procese informatice, necesare pentru modelarea și formalizarea totală a unui sistem informatic.

Metodologiile evoluează odată cu tehnologia informației, dar o metodologie de realizare a sistemelor informatice trebuie să cuprindă:

– etapele/procesele de realizare a unui sistem informatic structurate în subetape , activități sarcini precum și conținutul lor;

– fluxul realizării acestor etape sau procese, subetape și activități;

– modalitatea de derulare a ciclului de viață a sistemului informatic;

– modul de abordare a sistemului;

– strategiile de lucru/metodele de realizare;

– regulile de formalizare a componentelor sistemului informatic;

– tehnicile, procedurile, instrumentele, normele și standardele utilizate;

– modalitățile de conducere a proiectului (planificare, programare, urmărire) și modul de utilizare a resurselor financiare, umane și materiale.

În legătură cu sistemele informatice se mai folosesc două noțiuni și anume ciclul de dezvoltare a sistemului informatic și ciclul de viață al dezvoltării sistemelor.

Ciclul de viață al dezvoltării sistemelor (CVDS ) se extinde pe intervalul de timp cuprins între decizia de elaborare a sistemului informatic și decizia de abandonare sau de înlocuire cu alt sistem informatic.

Ciclul de dezvoltare a sistemului informatic se extinde de la decizia de elaborare a sistemului informatic până la momentul intrării sistemului în exploatare.

Ciclul de dezvoltare a sistemului este inclus în ciclul de viață al dezvoltării sistemelor.

În tabelul de mai jos sunt prezentate trei exemple de metodologii și de etapizare ale ciclului de dezvoltare. Aceste etape, sau altele (depinde de paradigma prin care vedem sistemul informațional și de modelul ales pentru CVDS ), trebuie respectate la o scară corespunzătoare și în cazul aplicațiilor.

De altfel, este recomandabil ca și atunci când ne propunem să realizăm doar o aplicație, să facem mai întâi o analiză a întregului sistem informatic, (evident "săpând" doar atât de adânc cât este necesar pentru ca aplicația noastră să fie compatibilă cu aplicațiile existente și cu cele care vor fi realizate în viitor) și apoi să continuăm doar cu aplicația ce ne interesează.

Lista metodologiilor nu se oprește la cele trei sau patru exemple de mai sus, dar nici nu ne propunem să facem aici o trecere în revistă a tuturor metodologiilor existente până în prezent. Ceea ce ne interesează este să reținem categoriile de metode cu specificul lor, pentru ca noi să ne alegem una sau două metodologii care se pretează cel mai bine la specificul informaticii de gestiune și să le aprofundăm pentru a le folosi în activitatea noastră de viitor.

In acest sens remarcăm că după modul de abordare a sistemelor informatice există metodologii cu abordare structurată și metodologii cu abordare orientată obiecte.

Metodologiile cu abordare structurată presupun împărțirea sistemului în subsisteme pe baza funcțiilor sistemului (cazul abordării funcționale) sau în funcție de date (abordarea bazată pe date). Exemplele de metodologii de mai sus fac parte din categoria metodologiilor cu abordare structurată.

Metodologiile cu abordare orientată obiect folosesc conceptele tehnologiei orientate pe obiecte. Etapele ciclului de viață al dezvoltării orientate obiect sunt:

analiza ;

proiectarea, divizată în

proiectarea de sistem ;

proiectarea obiectelor ;

– implementarea.

Metodologiile cu abordare orientată obiect s-au dezvoltat la început cu multe incompatibilități, ceea ce a făcut ca în 1997 să apară un standard cu privire la simboluri, notații, tipuri de diagrame, tipuri de modele, etc. Acesta este cunoscut sub numele de Unified Modeling Language sau UML.

UML nu numai că a standardizat dezvoltarea de produse soft bazate pe obiecte, dar a pus bazele unui proces iterativ de dezvoltare a sistemelor informatice. Acesta se bazează pe următoarele etape:

definirea problemei;

structurarea soluției cu subetapele:

stabilirea actorilor;

stabilirea cazurlor de utilizare;

stabilirea relațiilor dintre cazurile de utilizare;

construirea diagramelor cazurilor de utilizare;

analiza sistemului care cuprinde:

identificarea cazurilor de utilizare;

diagrama cu structura domeniului claselor;

inițializarea diagramei de clase, a diagramei obiectuale, diagramele de stare sau după caz, diagramele de activitate;

pentru clasele cu comportament dinamic se construiesc diagramele de secvență și diagramele de colaborare;

construirea soluției;

proiectarea sistemului:

proiectarea arhitecturii;

proiectarea de detaliu;

implementarea sistemului.

Ulterior s-a dezvoltat un ghid practic pentru utilizarea UML, numit Rational Unified Processes sau RUP căruia i s-a asociat și un CASE (Computer Aided System Engineering) foarte cunoscut astăzi, numit Rational Rose.

Funcționalități de modelare UML ca și round-trip engineering (combinarea generării automate de cod cu reverse engineering – generare de diagrame prin analiza codului) oferă și Visual Studio prin modulul Visual Modeler.

Într-un ghid practic ca RUP utilizatorul trebuie să descrie cine, ce și cum face, întrebări cărora în RUP le corespund conceptele de rol, document și activitate.

În cazul RUP etapele ciclului de dezvoltare au o configurație mai stranie prin faptul că deși ele vizează procese, în documentație este specificat obiectul activității (de aceea în original este vorba de workflow, adică fluxul de lucru).

Aceste etape/procese sunt:

modelarea activității;

cerințe;

analiză și proiectare;

implementare;

testare;

dezvoltare;

managementul schimbării;

managementul proiectului;

mediul.

Se pleacă de la premiza că parcurgerea acestui flow se va face iterativ de mai multe ori și din puncte diferite. De asemeni se mai presupune că în cadrul fiecărei etape se pot parcurge patru faze: inițiere, elaborare, construcție și tranziție.

Ca urmare fazele și procesele de parcurs atunci când folosim un process de tip RUP se reprezintă mai ușor sub forma unei matrici conținând pe verticală procesele iar pe orizontală cele patru faze pe care le poate parcurge oricare din cele 9 procese. Primele 6 procese sunt grupate sub numele de nucleu sau procese de lucru, iar ultimele 6 constituie suportul sau procese suport. La intersecția unui proces cu fiecare din fazele prin care ar putea trece se marchează cu linie curbă situată mai sus sau mai jos față de axa rândului respectiv, ponderea fazei în cadrul procesului respectiv ca în rândul Analiză și proiectare din tabelul de mai jos (dacă în cadrul unei intersecții/casete sunt mai multe iterații linia se va diviza corespunzător):

CONCLUZII

– Sistemul informațional este un ansamblu tehnico-organizatoric de proceduri de constatare, consemnare, culegere, verificare, transmitere, stocare și prelucrare a datelor, în scopul satisfacerii cerințelor informaționale necesare conducerii procesului fundamentării și elaborării deciziilor;

– Sistemul informatic constă din partea automatizată a sistemului informațional (utilizatorii implicați în automatizare și cadrul organizatoric aferent) căreia i se adaugă și alte elemente necesare pentru automatizarea obținerii informațiilor necesare conducerii în procesul de fundamentare și elaborare a deciziilor și anume : echipamente (hardware), programe (software), comunicații, o bază științifică și metodologică precum și baza informațională;

– În afara sistemelor informatice tradiționale există și sisteme informatice dedicate cum ar fi sistemele suport de decizie și sistemele expert, dar și unele sisteme informatice de tip nou ca cele pentru proiectare asistată de calculator, sistemele multimedia, sistemele pentru comerțul elctronic și sistemele deschise;

– Sistemul informatic se elaborează pe baza unei metodologii. Există un ciclu de dezvoltare a sistemului informatic, iar metodologia de elaborare a sistemului informatic trebuie să prevadă printre altele și etapele ciclului de dezvoltare a sistemului informatic;

– Metodologia elaborării sistemelor informatice este un ansamblu de principii și indicații, tehnici și metode grupate și ordonate ca să ducă la realizarea sistemului informatic. Există metodologii structurate și metodologii cu abordare orientată obiect;

– În conformitate cu abordarea funcțională, sistemele informatice sunt organizate pe subsisteme, aplicații și unități funcționale sau proceduri logice. Pentru programatori mai sunt relevante încă două nivele, inferioare unității funcționale și anume, unitatea de prelucrare sau procedura automată și modulul program;

– Pentru automatizarea elaborării sistemelor informatice se folosesc softuri de tip CASE, cum ar fi AMC Designer (MERISE) și Easy Case (SSADM) pentru metodologii structurate sau Oracle Designer (mediu CASE integrat), Rational Rose (RUP) și Visual Modeler (Visual Basic) pentru metodologii orientate obiect .

STUDIU APROFUNDAT AL METODOLOGIILOR

DE ELABORARE A SISTEMELOR INFORMATICE

Metodologia MERISE – un exemplu de corelare a

ciclului de dezvoltare cu nivelul și cu viziunea asupra sistemului

În cursul precedent am văzut ce este ciclul de dezvoltare de sisteme și am amintit despre modelare și modelul informațional. Acum trebuie să remarcăm că nivelul de la care privim sistemul informațional diferă de la o etapă la alta a ciclului de dezvoltare de sisteme, iar modelul sistemului informațional evoluează de la o etapă la alta reflectând nivelul de la care privim sistemul informațional. Astfel, dacă ar fi să ne referim la etapele metodei Merise, ar trebui să distingem un nivel global (asociat studiului de evaluare) și apoi nivelele conceptual, organizațional, logic și fizic, cărora le vor corespunde modelele global, conceptual, organizațional, logic și respectiv modelul fizic. Această evoluție a modelulului sistemului informațional spre un model de sistem informatic este continuă și logică, în sensul că fiecare din modelele de mai sus, n-ar putea fi construit dacă nu avem definitivat modelul etapei precedente.

A ști să proiectăm sisteme informatice îndeamnă să știm CE și CUM trebuie făcut în cadrul fiecărei etape a ciclului de dezvoltare de sisteme pentru ca să obținem modelul specific acelei etape, iar răspunsul la aceste întrebări îl oferă metodologiile.

Pentru a realiza o modelare eficientă a sistemului informațional, agenții (persoanele care joacă un rol oarecare într-un proces ce trebuie modelat) ca și entitățile care operează în sistem ( de exemplu documentele de intrare), trebuie implicate în model împreună cu funcțiiile pe care le îndeplinesc, cu comportamentul lor și cu datele referitoare la ele.

Prin comportament în cazul agenților se înțelege ceea ce fac ei în anumite împrejurări în contextul funcțiilor lor, iar în cazul documentelor de intrare – se înțelege ce efecte au ele (în contextul fluxului în care sunt implicate) asupra datelor.

În ce privește datele, există date care determină starea agenților sau entităților, date de care au nevoie pentru a-și îndeplini funcțiile (respectiv procesul în care sunt implicate) și date pe care le modifică sau le produc prin activitatea lor.

Diversitatea metodelor de abordare a sistemelor informaționale are de a face și cu nevoia de a surprinde funcțiile, comportamentul și datele implicate în sistem, în sensul că unele metode surprind mai ușor funcțiile, altele redau mai ușor comportamentul, iar altele evidențiază mai bine datele. Dacă am imagina un spațiu cu cele trei dimensiuni ce caracterizează o entitate (funcția, comportamentul sau datele de care este legată), atunci poziția oricărei entități în acest spațiu va depinde de ponderea pe care o au în existența acelei entități, funcția, comportamentul și datele de care este legată.

Când analiștii încep să studieze un sistem informational, în vederea trecerii acestuia pe calculator, ei trebuie să identifice care este trăsătura dominantă a sistemului (coordonata cu valoarea cea mai mare) și să aleagă metoda de abordare, respectiv metodologia cea mai potrivită.

Odată aleasă metoda de abordare a sistemului informațional, ar trebui identificat ciclul de viață al dezvoltării sistemului (ciclul asociat metodologiei respective), așa cum apare el în literatura de specialitate și ar trebui să efectuăm operațiile specificate în cadrul metodologiei, pentru fiecare etapă.

Am precizat mai sus că de fapt în cadrul fiecărei etape, metodologia precizează CE și CUM trebuie făcut. Pentru a preciza CE trebuie făcut, în metodologie sunt enumerate obiectivele urmărite în cadrul fiecărei etape, iar pentru a preciza CUM trebuie făcut, este precizată forma sub care se consideră că se poate prezenta fiecare din aceste obiective, în cadrul documentației de fază. Uneori această formă de prezentare poate fi una grafică, dar nu una oarecare ci respectând forme și înscrisuri tipizate, prevăzute în metodologie. O astfel de formă tipizată se formalism.

Formalism, în sensul de mai sus, înseamnă un set de definiții și reguli, combinat cu un set de tipuri de diagrame și/sau de tabele. Cele mai sofisticate formalisme le conține metoda Merise, dar și diagramele de flux ale datelor (DFD) sau cele de tip entitate_relatie (DER) sunt tot niște formalisme.

Numai după ce proiectantul aplică situației concrete, oferită de sistemul analizat, formalismul specific etapei, el poate îndeplini cerințele de proiectare privind documentația de fază.

Documentația de fază are pe de o parte rolul de a valorifica constatările etapei curente pentru a putea fi folosite ca punct de plecare pentru etapa următoare, iar pe de altă parte ea are și un rol comunicativ în relația cu beneficiarul pentru că prin consensul dintre proiectant și beneficiar, proiectantul are garanția că a înțeles cerințele beneficiarului și va realiza un sistem care să satisfacă aceste cerințe. Legat de acest aspect, documentația de fază mai are și o utilitate juridică, în sensul că poate constitui baza legală pentru plata muncii efectuate de proiectant, iar în caz de litigii ulterioare între proiectant și beneficiar, documentația de fază poate constitui un factor care înclină balanța în favoarea uneia sau alteia din părți, după cum situația din teren corespunde sau nu cu ceea ce s-a aprobat de către beneficiar prin avizarea documentației de fază.

Avizarea documentației de fază are loc înainte de a se trece la faza următoare.

Revenind la ideea de a realiza sistemul informatic numai prin simpla traducere în viață a specificațiilor privind CE și CUM trebuie făcut în fiecare etapă a CVDS, trebuie spus că din nefericire, lucrurile nu sunt atât de simple și aceasta pentru că foarte rar ciclul de viață al dezvoltării sistemului informatic se derulează secvențial și o singură dată. De cele mai multe ori ciclurile se reiau din diferite puncte și uneori chiar de mai multe ori și din puncte diferite, ducînd la apariția unor modele ale ciclurilor de viață. Cu alte cuvinte ciclurile de viață diferă odată de la un mod de abordare la altul, ceea ce se concretizează printr-o anumită structură a etapelor ciclului de dezvoltare (structură materializată printr-un anume număr de etape și succesiune), dar apoi ele diferă și de la un model la altul al ciclului de dezvoltare, prin modul cum vor fi reluate și repetate anumite faze. Motivul pentru care se complică lucrurile în acest fel este acela că de cele mai multe ori, prima variantă a softului produs inițial nu este satisfăcătoare.

Cauzele acestei situații sunt multiple. Iată doar câteva dintre ele:

– pe timpul elaborării unei variante, în sistemul analizat pot să intervină schimbări de structură sau de funcționare;

– este mai greu să perfecționezi o aplicație care încă nu funcționează, aflată doar pe hârtie, decât una care a început să funcționeze; ca urmare începem cu ceva care urmează a fi perfecționat;

– când am dat primul program în funcțiune, începem să comunicăm mai bine cu beneficiarul; s-ar putea ca el să constate că n-a fost bine înțeles, sau ceea ce a cerut nu era ceea ce dorea.

Cele mai reprezentative modele ale ciclurilor de viață sunt următoarele: modelul cascadă, modelul V, modelul incremental, modelul spirală, modelul evolutiv, modelul piramidă (specific ingineriei informației orientate-obiect).

În secțiunea 2 sunt prezentate în detaliu cele mai reprezentative modele ale ciclurilor de viață.

Presupunând că am identificat elementul care va fi supus analizei (funcție, proces, date, obiecte, etc.), adică am ales orientarea și am ales și modelul ciclului de dezvoltare, deci avem o secvență clară de faze ce trebuie parcurse pentru a realiza sistemul informatic, am putea trece la îndeplinirea activităților prevăzute pentru fiecare etapă, numai că înainte de aceasta urmează să mai luăm în calcul încă un element: viziunea (view) sau aspectul pe care-l analizăm la un moment dat pentru a realiza abstractizarea impusă de modelare, adică pentru a elabora modelul informațional. Inainte de a explica ce este viziunea, merită să remarcăm că spre deosebire de alte entități cu care operăm în viața cotidiană sistemele informatice implică mai multe puncte de vedere (views). Așa de exemplu un motor poate fi privit din punct de vedere al principiului de funcționare, al componentelor sale majore, deci a subansamblelor sale și cam atât, în timp ce sistemul informatic implică și forme abstracte și mai ales forme abstracte și aceasta pentru că el nu este realitatea pură ci este o abstractizare a realității.

Viziunea este legată de faptul că sistemul informațional se va materializa sub forma a cel puțin patru aspecte diferite la care va trebui să facem referire în fiecare din etapele CVDS. Cu alte cuvinte o etapă se consideră parcursă dacă pe timpul său am făcut referirile ce se impun la următoarele aspecte:

– descrierea și definirea elementelor adiționale și auxiliare specifice etapei;

– comunicații implicate în sistem;

– datele ce se vehiculează în sistem;

– prelucrările specifice fiecărei etape;

Cu etapele ciclului de dezvoltare dispuse pe verticală și cu aspectele sau viziunile enumerate mai sus, dispuse pe orizontală (sub forma unui cap de tabel), am putea obține o matrice pe care s-o completăm cu activități sau obiective ce trebuie atinse în fiecare etapă CVDS, pentru fiecare aspect sau viziune. De regulă matricea (un rezultat al interferenței dintre etapele CVDS și viziuni) este completată de către cei care au elaborat metoda cu obiective (mai exact cu CE trebuie făcut în cadrul fiecărei etape). Partea privitoare la CUM trebuie făcut, este una descriptivă și prea voluminoasă pentru a fi inclusă în matrice. Un exemplu de astfel de model tabelar este matricea oferită de metoda Merise. Cât privește nivelul de la care privim această matrice, acesta ar putea constitui o a treia dimensiune, ceea ce ar însemna apariția unui cub! Un asemenea exemplu se întâlnește la modelul propus de CIMOSA – un cunoscut concept de arhitectură de referință. De fapt și autorii metodei Merise au introdus un CVDS pe trei dimensiuni, dar a treia dimensiune este nivelul decizional cu privire la mersul proiectului (ceea ce nu a prins la specialiști!)

În ce privește nivelul de la care se face analiza sistemului, în cadrul metodei Merise, acesta poate fi reprezentat de-a lungul axei etapelor CVDS, în sensul că un nivel va cuprinde cel puțin una din etapele CVDS, astfel că pe latura verticală a matricii putem materializa atât etapele CVDS cât și nivelul la care trebuie văzut sistemul.

Pentru ilustrarea interferenței dintre metodă, CVDS, nivel și viziune prezentăm mai jos matricea Merise completată nu cu obiective de studiat, ci cu conceptele specifice fiecărei etape, la nivelul corespunzător, pentru fiecare viziune sau aspect. Aceste tabele sunt utile numai pentru a surprinde mai ușor interferența tuturor aspectelor ce trebuie avute în vedere pe timpul proiectării sistemelor informatice, dar indicațiile metodologice concrete sunt prea voluminoase pentru a fi stocate într-o matrice.

În practică, activitățile dintr-un astfel de tabel ar trebui detaliate și comentate pe parcursul a câtorva capitole. De regulă fiecare etapă CVDS este tratată pe câte un capitol.

Cu privire la diversitatea modelelor ciclurilor de viață, trebuie să tragem următoarele concluzii:

– modelele sunt diferite, în funcție de tehnologiile folosite în procesul de realizare a sistemelor; un salt considerabil se observă în mediile orientate-obiect;

– modelele depind de mărimea proiectelor dar și de domeniile de care aparțin sistemele;

– la alegerea unui model trebuie să ținem seamă nu numai de ordinea în care se derulează etapele de elaborare a sistemului, ci și de proportia în care modelul presupune abordarea sistemului, adică pe părți sau global. Unele modele cum ar fi cel în cascadă, presupune parcurgerea tuturor etapelor la nivelul întregului sistem, în timp ce modelul evolutiv de exemplu, permite derularea marii majorități a etapelor pe părți/componente ale sistemului;

– alegerea modelului va depinde și de experiența echipei ce efectuiază proiectarea sistemului;

– cerințele funcționale își pun de asemenea, amprenta pe tipul de model; sistemul poate fi abordat în întregime sau pe componente funcționale;

– complexitatea sistemului se va reflecta în mare măsură în tipul modelului selectat.

În afară de aspectele a căror interferență în cadrul procesului de analiză și proiectare a sistemelor informatice a fost analizată mai sus, mai există și alte aspecte a căror interferență nu poate fi formalizată, dar trebuie luată în calcul de proiectanții de sisteme informatice. Este vorba de noutățile care s-au înregistrat în informatică pe planul tehnicilor de programare, a rețelelor de calculatoare și mai ales în domeniul CASE.

3. Automatizarea dezvoltării sistemelor prin instrumente CASE

Acronimul CASE vine de la de la Computer Aided System Engineering și are ca obiectiv punerea în practică a produselor- program de proiectare și realizare a softului cu ajutorul calculatorului. Instrumentele oferite de CASE (ca de exemplu EXCELERATOR, apărut pe la mijlocul anilor '80), sunt utilizabile din faza de definire a cerințelor până la întreținerea fizică a sistemului informatic, dar prioritate au analiza și proiectarea bazate pe conceptele și metodele structurate. În ultimii ani, acestora li s-au adăugat analiza, proiectarea și programarea orientată pe obiecte. Instrumentele CASE implică utilizarea calculatorului ca mijloc de susținere a activităților de planificare, definire, proiectare și realizare a softului. Ele se bazează pe logica structurată, pe descompunerea funcțională și reprezentarea prin diagrame a fluxurilor de date ale aplicațiilor.

Mijloacele CASE realizează proceduri și metode ce prezintă diferențe majore față de metodele clasice și care se constituie în performațe ale acestor produse, cum ar fi:

– prezentarea logicii de proiectare a sistemului;

– posibilități de vizualizare a datelor;

– sprijin în definirea obiectivelor;

– definirea și utilizarea unor termeni de referință;

– folosirea unui depozit partajat de date;

– ușurința efectuării unor schimbări;

– realizarea unei documentații flexibile și dinamice;

– aplicarea unor reguli de verificare a consistenței;

– folosirea reprezentărilor grafice simple;

– construirea de pseudocoduri structurate;

– sprijinirea modularizării;

– folosirea pe scară largă a prototipurilor;

– constituirea unei interfețe pentru generatoarele de coduri;

– construirea bibliotecilor de module și documente.

Pe măsura evoluției lor, sistemele CASE au devenit mai complexe, permițând ca procesele de proiectare și realizare a aplicațiilor să se desfășoare într-un mediu informatic interactiv, oferind utilizatorilor un întreg arsenal de instrumente și proceduri, prin care pot proiecta, realiza, testa, documenta, întreține/actualiza și exploata sistemul.

Utilizarea sistemelor CASE a început cu introducerea diagramelor fluxurilor de date, care fac posibilă realizarea unui model al derulării proceselor sistemului/aplicației care se proiectează. A urmat folosirea dicționarului de date ca un depozit al tuturor datelor privind sistemul sau aplicația Au apărut ecranele predefinite pentru a prezenta ce poate să obțină utilizatorul prin exploatarea sistemului. S-a apelat la facilități grafice, care pot folosi simbolurile logicii structurate și care permit proiectantului să realizeze o diagramă coerentă a fluxurilor de date.

Primele sisteme CASE erau un set de aplicați neintegrate, cu funcții distincte, fără a fi interconectate. Aceste limite au fost eliminate, în cea mai mare parte, prin generațiile actuale, care încearcă să realizeze o integrare completă și ușoară a tuturor elementelor, integrarea reprezentând de fapt, factorul cel mai imoprtant al metodologiei CASE.

CASE se bazează pe două funcții fundamentale:

– prima este bazată pe posibilitatea descompunerii de sus în jos (top-down) a sistemului informatic în procese și module distincte, fiecare având definite responsabilitățile funcționale și/sau operaționale; odată cu orientarea spre obiecte, funcțiile se înlocuiesc cu obiectele care îndeplinesc funcția, ceea ce ușurează controlul procesului;

– a doua se referă la faptul că sistemele informaționale pot fi reprezentate într-o formă grafică concisă, folosind câteva simboluri de bază

Importanța acestor funcții rezidă în posibilitatea utilizării modularității aplicațiilor, a diagramelor, obținerea unei documentații privind realizarea, evaluarea arhitecturii și utilizarea sistemului.

Pentru definirea și construirea sistemelor, produsele CASE presupun stabilirea și respectarea unei anumite discipline. Metodologia oferă o interfață între crearea și verificarea/validarea proiectului logic, dezvoltarea unei biblioteci cu documentații, care include și integrează caracteristicile proceselor și pașii de parcurs, pentru descrierea modului de lucru; oferă un model al produsului final, ce poate fi folosit în realizarea operațiilor de exploatare și întreținere a sistemului/aplicației și oferă o interfață pentru păstrarea evoluției proiectului.

Folosirea reprezentărilor grafice în logica CASE oferă posibilitatea descompunerii aplicației în mai multe componente logice.

Prin atașarea unei baze de date la elementele grafice, se va obține un depozit ce va conține pașii și funcțiile reprezentate în diagramele construite. Dacă aceste elemente sunt corect stabilite, ele vor sta la baza descrierii proceselor, ce vor constitui procedurile de prelucrare a sistemului /aplicației.

Modelarea grafică în sistemele CASE prezintă o interactivitate ridicată, permitând construirea diagramelor, deplasarea de la o diagramă la alta , modificarea, extinderea, copierea, evaluarea și descrierea elementelor unei aplicații. Modelele grafice permit conectarea fluxurilor logice între activitățile și funcțiile specifice aplicației, relații care pot fi testate și validate în mod automat.

Din punct de vedere al momentului în care a avut loc automatizarea fazelor din ciclul de viață al sistemelor, se consideră că analiza și proiectarea reprezintă faze superioare, adică au fost automatizate mai recent. Instrumentele CASE referitoare la aceste faze se numesc Upper CASE sau Front End, iar cele referitoare la fazele care au fost automatizate primele se numesc Lower CASE sau Back End.

Clasificarea instrumentelor CASE

Pentru că există instrumente CASE care nu pot fi legate de fazele ciclului de viață a dezvoltării de sisteme, cele din categoria Upper și Lower CASE sunt denumite CASE Vertical, iar celelalte se numesc CASE Orizontal

Clasificarea instrumentelor CASE este dată în tabelul de pe pagina următoare.

Caracteristicile mediilor moderne de tip CASE:

– reprezintă un set de instrumente specifice pentru realizarea sistemelor;

– diversitatea modurilor de interacțiune;

– semnificația reprezentărilor grafice;

– elemente de tip verificare și validare (V & V);

– natura bidirecțională, deplasări pe verticală în structura sistemului;

– deschiderea pentru interconectarea instrumentelor CASE;

– sprijin pentru lucru cu utilizatori multipli;

– descompunerea;

– performanțe de deplasare, pe orizontală, de la un instrument la altul;

– grade diferite de automatizare;

– integrare.

4. Câteva provocări ale tehnologiei informatice actuale

4.1 Programarea orientată pe obiecte. În cursul precedent este prezentat un scurt istoric al evoluției analizei și proiectării sistemelor prin metodologii orientate obiect, dar se cuvine o precizare: sintagma "orientare-obiect" are accepțiuni diferite în diverse discipline: una în modelarea informațiilor, alta în programare și alta în analiza și proiectarea sistemelor. Pentru a proiecta și implementa soft orientat spre obiecte trebuie cunoscută metoda de abordare specifică acestei paradigme și bineînțeles un limbaj de programare adecvat.

Cât privește utilizarea acestei orientări în analiza și proiectarea sistemelor, trebuie subliniat că actualele SGBD de tip Visual, în speță Visual Fox și Access sunt foarte ușor de manevrat, mai ales că bazele de date din aceste medii de programare se realizează sub formă de baze de date relaționale, iar utilizarea obiectelor se face foarte subtil, la nivel câmp. Obiectele intervin vizibil numai în realizarea controalelor. Totuși pentru cei care cunosc programarea pe obiecte este păcat să nu știe să folosească și proiectarea obiectuală a sistemelor informatice, mai ales că există și instrumente CASE bine puse la punct și pentru metodologiile orientate obiect (Rational Rose, Visual Modeler, etc.)

4.2 Apariția aplicațiilor și a bazelor de date multimedia, mai ales în legătură cu bazele de date distribuite sau cu comunicațiile pe WWW, este o chestiune care trebuie să ne pună în stare de veghe și dacă sistemul la care lucrăm o impune, trebuie să avem în vedere și alte aspecte cum ar fi reclamă pe Internet, utilizarea paginilor WEB, e-learning, punerea la dispoziția utilizatorilor a unui help profesionist, documentație online, ș. a.

4.3 Un element deloc lipsit de importanță este softul pe care vom realiza și pe care va fi implemetat sistemul informatic (este vorba de interfața grafică/sistem de operare și de SGBD). Poate este util de știut că în țările occidentale se lucrează mai mult sub UNIX și LYNUX și mai rar sub Windows, iar ca SGBD se folosește foarte mult – ORACLE. Pentru o aplicație care să reziste "afară", vom folosi dacă nu UNIX sau LYNUX cel puțin Windows NT.

4.4 Apariția inteligenței artificiale. Aceasta, în ciuda vălului de "elită" în care este înfășurată nu trebuie să-i alerteze prea mult pe realizatorii de sisteme informatice obișnuite pentru că acestea se pot realiza și fără inteligență artificială, dar dacă se pune problema unor aplicații menite să coordoneze procese, sau să ofere mijloace de învățare cu ajutorul calculatorului, sau să operăm activ pe Internet, atunci s-ar putea ca apelarea la inteligența artificială să fie inevitabilă. De aceea, înainte de a începe detalierea etapelor de proiectare a sistemelor informatice, vom dedica câte un curs sistemelor support de decizie și respectiv sistemelor expert.

5. Rolul sistemelor informatice în conducerea

organizațiilor economice

Remarcăm faptul că în condițiile create de Internet, sistemul informatic se detașează de intreprindere și chiar iese din cadrul ei făcând legătura directă cu băncile, cu furnizorii și oferă conducerii date despre mișcările pe care le execută concurența. Conducerea intreprinderii moderne nu se mai mulțumește cu o informare operativă ci dorește prognoze, dorește să prevadă viitoarele mișcări ale concurenței și viitoarea evoluție a pieței ținând cont de ceea ce se petrece în prezent. Deaceea chiar dacă nu proiectăm sisteme suport de decizie sistemele informatice moderne trebuie să iasă din perimetrul intreprinderii.

În [1] Dumitru Oprea vede relația sistemului informatic cu intreprinderea ca în figura de pe pagina următoare.

Date

Partea II CONCEPEREA SI REALIZAREA

SISTEMULUI INFORMATIC FINANCIAR CONTABIL

Indiferent de metoda sistemică pe care o folosim, documentația de proiectare trebuie să urmărească modelul sistemului informațional pe cele trei nivele ANSI/SPARC:

– extern (așa cum este văzut sistemul de utilizator);

– conceptual (realitatea modelată prin prisma entităților, asocierilor și prelucrărilor de date);

– intern ( așa cum este organizat fizic sistemul în calculator/calculatoare).

Din analiza situației la nivel extern se obține modelul conceptual și apoi cel logic. Între modelul conceptual și cel logic unele metode ca MERISE adaugă și modelul organizațional. Alte metode dezvoltă modelul logic direct pe nivelul organizațional, adică combină modelul organizațional cu cel logic.

Transformarea modelului logic în cel fizic se face la nivel extern.

Ca urmare, putem sintetiza legătura dintre nivelele de abstractizare și modelele datelor și prelucrărilor într-un tabel de forma

Indiferent de metoda sau metodologia de proiectare pe care o folosim, în afară de modelele datelor și prelucrărilor, documentația de proiectare trebuie să conțină și următoarele informații:

a) pentru etapa de analiză:

– obiectul de activitate al societății comerciale sau intreprinderii analizate;

– structura organizatorică (organigrama structurii organizatorice);

– obiectivele firmei, funcțiile specifice, atributele conducerii și modul în care sunt derulate activitățile ei, mediul extern în care lucrează;

– domenii de activitate, definirea subsistemelor informatice și/sau aplicațiilor;

– informațiile de care au nevoie persoanele din unitate pentru exercitarea sarcinilor ce le revin;

– legislația în vigoare specifică domeniilor de activitate din intreprindere;

– 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ă și modul în care sunt transmise și prelucrate datele;

– politicile și orientările care descriu modul în care se desfășoară activitatea unității, ținându-se cont de mediul și piața în care funcționează;

– evenimentele marcante și momentele declanșării lor, prin care se schimbă valoarea /datelor;

b) În etapa de proiectare logică:

– documentele de ieșire pe tipuri, machetele lor și cui sunt destinate;

– documentele de intrare, machetele lor, propuneri de adapatre la prelucrarea automată a datelor;

– lista unităților funcționale (procedurilor logice) împreună cu organigramele acestora;

– machetele formularelor (formatelor) folosite la prelucrarea datelor;

– macheta meniului principal și /sau diagrama arborelui meniului principal (pg. 108 din carte)

c) În etapa de proiectare fizică:

– lista unităților de prelucrare (procedurilor automate);

– diagramele de structură din care să rezulte ordinea apelării unităților de prelucrare (pg 140 carte)

– machetele casetelor de dialog specifice procedurilor impuse de siguranța și securitatea datelor;

– schemelde sistem (pg. 161 din carte)

Dacă se aplică metoda MERISE se vor derula etapele din tabelul dela pg. 16 unde sunt specificate conceptele specifice fiecărei etape divizate pe viziuni (views).

După tabel sunt specificate în sinteză piesele care trebuie să fie prezentate de proiectant în documentația fiecărei faze, dar se va ține seamă și de cerințele enumerate mai sus.

1. Modelarea globală (MG)

a) Descrieri și definiții

– studierea cadrului legislativ în care-și desfășoară activitatea unitatea studiată;

– descrierea funcțiilor/domeniilor specifice unității studiate;

– definirea activităților, subactivităților și operațiilor incluse în fiecare domeniu. În concepția Merise, o unitate este structurată pe funcții, domenii, activități, subactivități/procese, operații complexe și operații simple. De exemplu. funcția servicii financiar-bancare, domeniul credite bancare, activitatea acordare credite bancare, procesul analiza solicitării și rambursării creditelor bancare, se poate descompune în operații complexe (analiza cererii de credit, analiza deciziei de creditare pe termen scurt, înregistrarea creditelor acordate, rambursarea creditului și înregistrarea rambursării creditului), iar fiecare din aceste operații complexe se poate descompune în operații elementare, conform machetei de mai jos:

Soluția globală pentru realizarea și administrarea unui SI trebuie să țină seama de factori endogeni și exogeni în raport cu activitatea unității economice, de considerente financiare, umane, organizaționale, conjuncturale, informaționale, manageriale și ca urmare, cel puțin teoretic, ar trebui să existe și un model matematic de optimizare a acesteia.

b) Comunicațiile din SI

– descrierea sistemului de organizare: definirea de ansamblu a comunicațiilor la nivelul structurii de organizare;

– definirea soluțiilor globale și previzibile de organizare a comunicațiilor de date și de prelucrări (comunicații locale sau după caz comunicații on-line cu alte unități);

– specificarea generală a comunicațiilor viitoare (instalare de workstations sau implementarea unei rețele);

c) Viziunea asupra datelor

– definirea obiectivelor manageriale și funcționale ale sistemului (vezi pg.45);

– definirea intrărilor și ieșirilor în concordanță cu obiectivele stabilite.

Se poate întocmi un tabel cu rubricile:

activitate, obiective manageriale, obiective funcționale, ieșiri solicitate și

intrări necesare (vezi clasificarea ieșirilor la pag.50);

d) Viziunea asupra prelucrărilor

– definirea subsistemelor informatice și aplicațiilor informatice (vezi anexa 4, pg.75);

– descrierea conexiunilor dintre subsisteme /aplicații în scopul asigurării funcționalității sistemului realizat (vezi anexa 3, schema conexiunilor pg.74).

2. Modelarea conceptuală (MC)

Modelarea conceptuală se mai numește studiu de detaliu sau conceptual.

Ea prezintă specificații funcționale care să asigure acordul între cerințele utilizatorului și soluțiile ce se vor adopta. Nu face referiri la tehnică de calcul, organizarea datelor sau prelucrarea acestora. MC asigură o soluție stabilă căreia îi vor corespunde una sau mai multe soluții concrete organizaționale, logice și fizice elaborate în etapele viitoare.

a) Descrieri și definiții la nivel conceptual:

– stabilirea funcțiilor/domeniilor sau activităților informatizabile autonome; în cadrul acestora se identifică un sistem de conducere, unul informațional și unul operant;

– stabilirea intrărilor sistemului pe tipuri: off-line (documente de intrare) și on-line; se vor întocmi tabele cu documente având structura: cod document, denumire, frecvența, ce informații conține (casete de editare texte); pentru fiecare document se va întocmi macheta, precum și un tabel ale cărui coloane sunt chiar denumirile câmpurilor având specificate pe rândul următor tipul câmpului și dimensiunea;

– stabilirea ieșirilor (rapoarte, grafice, indicatori sintetici, ieșiri către alte sisteme). Pentru fiecare raport sau grafic se va prezenta macheta și dispozitivul de ieșire, iar unde este cazul și algoritmii de calcul precum și reguli de disciplină informațională concretizate în specificații legate de modul practic de utilizare a unui raport (funcția, activitatea, compartimentul beneficiar, numărul de exemplare, frecvența, termen, dispozitiv periferic de ieșire, etc.);

– sistemul de codificare (tabel cu coduri sau după caz, formule pentru coduri); coduri standard. (vezi pg.55)

b) Modelul conceptual de comunicații (MCC)

Folosește concepte specifice ca: actori, fluxuri, diagrame de flux, matrice de flux, diagramă conceptuală de flux.

Diagramele de flux materializează actorii, legați între ei cu săgeți pe care sunt trecute simbolurile documentelor, iar lângă simboluri se trece în paranteză numărul curent al operației în tabelul ce însoțește diagrama. Acest tabel conține rubricile: nr. de ordine, actorul, descrierea acțiunii acestuia (fluxului realizat), documente/situații folosite. În diagrama de flux numele actorului se trece în simboluri reprezentate prin cercuri, hexagoane sau pătrate.

Matricele de flux conțin actorii, atât pe orizontală cât și pe verticală, iar la intersecție se trec simbolurile documentelor care îi leagă ( de ex. BC bilanț contabil, sau SS situația stocurilor și cheltuielilor). Pe diagonala principală sunt marcate fluxurile interne. Celelalte sunt fluxuri externe.

Diagramele conceptuale de flux seamănă cu diagramele de flux, dar pe săgeți nu conțin simboluri de documente, ci numărul pasului din compunerea algoritmului referitor la circuitul informațional reprezentat de diagramă. Un astfel de algoritm este în fapt reflectarea unor prevederi legale sau tehnice referitoare la modul de desfășurare a activității analizate. Pasul descrie în cuvinte cine și ce trebuie să facă.

c) Modelul conceptual de prelucrare (MCP)

Se bazează pe conceptele: actori, evenimente/rezultat/mesaje, operație, sincronizare, procese, reguli de verificare, reguli de sintaxă, reguli de funcționare. Pentru fiecare concept există simboluri, iar dintr-un ansamblu de actori, evenimente/rezultat/mesaje, operație, sincronizare poate rezulta o operație complexă, care poate fi reprezentată cu un simbol general ca în figura de mai jos. Deoarece procesele sunt ansambluri structurate de operații complexe, ele pot fi reprezentate prin lanțuri formate din astfel de simboluri, pe baza faptului că rezultatele emise de la o operație vor fi evenimente de intrare pentru următoarea operație.

EVENIMENTE DE INTRARE

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

eveniment] eveniment]

[expresie

sincronizare logică]

[nume de operație complexă]

Operație – elementară – 1

OPERAȚIA .

.

Operație – elementară – N

[Ecuația de [Ecuația de

emisie R1] emisie Rn]

[nume actor [nume tip de [nume tip de [nume tip de

rezultat] rezultat] rezultat]

REZULTATE EMISE

primari (pe baza algoritmilor de calcul) și întocmirea bazei de atribute.

În continuare se întocmește matricea dependențelor și apoi se poate întocmi MCD ca în exemplul de mai jos

entități

CLIENTI tip relație CONTRACT

cheie primară 1,n încheie 1,1 cheie primară

listă atribute: valoare credit listă atribute:

de ex. adresă procent dobândă

1,n tip atribut entitate

tip relație RAMBURSĂRI

achită 1,1 număr OP# cheie primară

suma data OP tip atribut

tip atribut

cardinalitate minimă și maximă

EXEMPLU DE DIAGRAMĂ MCD

3. Modelarea organizațională (MO)

MO vizează repartiția organizațională a sistemului informațional (arhitectura și localizarea fizică a rețelei de calculatoare, soluția bazei de date) prin prisma departamentelor, serviciilor și posturilor de lucru. Nu are în vedere particularități tehnice. Trebuie să îndeplinească criterii economice, organizatorice și de ordin social.

MO răspunde la întrebările cine?, unde?, când?. Din MO trebuie să rezulte:

– organizarea previzibilă diferențiată pe departamente/servicii/posturi de lucru privite ca centre de activitate;

– circulația informațiilor între aceste centre de activitate;

– sarcinile și cronologia ce vor fi realizate la nivelul fiecărui post de lucru.

a) Modelarea organizațională a prelucrărilor (MOP)

MOP are ca sursă evenimentele și rezultatele-mesaje provenite din MCP și asigură transformarea evenimentelor în subtipuri de evenimente și a rezultatelor-mesaj în subtipuri de rezultate-mesaj. Se utilizează conceptele de post de lucru, sarcină, evenimentul și rezultatul-mesaj, sincronizarea, resursele, faza, proceduri organizaționale, reprezentare grafică a MOP, concepte adiționale și construcția MOP. Resursele se pot grupa în:

factorul uman;

resurse organizaționale: departamente, servicii sau ghișee;

resurse informatice și/sau de telecomunicații: videoterminale, imprimante, colecții de date, proceduri automate, faxuri/modemuri;

resurse de timp: termenele, succesiunea fazelor și a sarcinilor.

Sarcina este un ansamblu de activități elementare având același scop. Operației complexe din MCP îi corespunde în MOP faza. În MCP operațiile complexe se descompun în operații elementare, iar acestora le corespunde în MOP, sarcina.

Sarcinile sunt caracterizate prin: post de lucru (unde li se asociază resurse umane și informatice), grad de automatizare (manual, conversațional/interactiv și automatizat), timp de răspuns și mod de funcționare (unitar, de tip lot). Sincronizările vizează operații de tip logic cu evenimente: ex. verificare data ordin de plată + ștampilă + semnătură autorizată.

Procedura organizațională (PO) vizează un ansamblu logic și legal de evenimente tip, apelul evenimentelor inițiale ale procedurii, sincronizările și obținerea tuturor rezultatelor tip. MOP se materializează într-un tabel conținând coloanele: frecvența (Z, d, l, etc.), actori/posturi de lucru sau regrupări de actori și tipul serviciului. Cu excepția ultimei coloane și a celei dintâi, în celelalte coloane este reprezentată grafic cronologia PO, a fazelor și sarcinilor specifice, folosindu-se în acest scop simboluri de tipul celui de mai jos, care pe un rând dat se pune o singură dată, în coloana care derulează sarcina ce urmează în cadrul procedurii. Simbolurile se leagă între ele cu săgeți ce marchează continuitatea procedurii.

Dacă este cazul, acest tabel poate fi precedat de un alt tabel unde în loc de reprezentări grafice pe actori, se tratează activitatea pe faze, sarcini aferente, actor implicat, frecvență și tipul serviciilor.

b) Modelarea organizațională a comunicațiilor (MOC) trebuie să evidențieze:

– locul și rolul fiecărui actor (departament, serviciu, ghișeu, posturi de lucru) sub aspectul legăturilor informaționale;

– numărul de apariții ale fiecărui actor (de ex. un ghișeu apare în 5 exemplare identice);

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

Simbol folosit pentru reprezentarea resurselor organizatorice:

c) Modelarea organizațională a datelor (MOD). Se pleacă de la MCD și se urmărește:

– alegerea proprietăților ce vor fi memorate;

– specificarea volumului informațiilor memorate;

– repartiția organizațională a datelor prin tipuri de unități organizaționale; se specifică fiecare proprietate și entitate memorată.

MOD se definește la nivel global derivat din MCD, dar și la nivel local pentru fiecare tip de unitate organizațională. Merise oferă metode pentru calculul cardinalității medii (m) și a volumului datelor, cu care se calculează în final coeficientul de participare (P) ca raport al numărului maxim de realizări pe fiecare din cele două entități aflate în relație. Valorile simbolurilor m și P apar scrise pe liniile de legătură din diagramele de tip DER., în timp ce cardinalitățile minime și maxime apar sub aceste linii.

Dăm mai jos un exemplu de MOD la nivel global.

MOD local se poate reprezenta grafic pe cel global, delimitând zonele fiecărui compartiment beneficiar cu linii întrerupte (a se vedea cadrele punctate – pentru serv financiar și ghișeu și cele cu liniuțe pentru serviciul clientelă; al treilea, nemarcat pe desen, destinat serviciului credite, ia totul, mai puțin relația "încheie"). Se poate reprezenta și tabelar, într-un tabel cu rubricile: MOD locale, Tipuri de entități, (care este defalcat pe tipuri de entități) și Tipuri de relații (care este defalcat pe tipuri de relații). În acest tabel, dacă o entitate sau o relație aparține unui MOD local, la intersecție se pune o steluță.

BANCA CLIENȚI

1,n lucrează 1,1 1,n

cif # nr. cont cif #

denumire sold denumire

adresă adresă …

capital social 1,n

forma propr.

1,1 rambursează încheie

suma valoare contract

obiect plată 0,n 1,1 clauze

pPLĂȚI

Contract credit

nr_do #1,1 nr_co #

data_dp data_co

. . .

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

Estimarea securității datelor definește restricțiile: nici un fel de acces, creare (C), citire (R), modificare (M) și ștergere (D). Există securitate intraunități, ce definește accesibilitatea unui anumit tip de utilizator și securitate inter-unități ce definște datele specifice partajate și protejate. Unitățile organizaționale pot avea acces la datele partajabile de următoarele tipuri: creare sau ștergere, partajabile la consultare, actualizare, fără restricții de acces. Practic se definesc pentru fiecare (UO) date particulare și date protejate ca în figura de mai jos.

U01 – serv. clientelă U02 – serv. credite

D1 Dpc1 Dpc2 D2

(date (date

particulare) Da1 Da2 particulare)

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

d) Descrieri și definiții organizaționale

i. Verificarea coerenței date – prelucrări: se folosește o grilă de coerență globală prin care se poate confrunta MCD cu MOD și MOP. Practic se verifică dacă sarcinile descrise în MOP dispun de datele corecte și necesare, adică se verifică modul în care tipurile de entități și de relații din MCD sunt utilizate în funcționarea sarcinilor MOP.

O astfel de grilă este reprezentată mai jos unde, pentru acțiunile elementare utilizabile în verificarea coerenței MCD/MOD + MOP se folosesc următoarele prescurtări:

MAN – manual, CRE – creare, CIT – citire, MOD – modificare și ST – ștergere:

ii. Modelarea mesajelor. Mesajele sunt ansambluri structurate de date, formate la interfața cu evenimentele declanșate în MOD. De ex. evenimentul contract client conține odată mesajele: cif client, denumire, adresă și data cererii, dar de mai multe ori tip credit, obiect credit, valoare credit, clauze credit, termen de recuperare.

iii. Regulile de prelucrare (RP) exprimă algoritmii și condițiile utilizate în derularea sarcinilor din MOP. Ele sunt expresii aritmetice și logice integrate într-o structură de calcul asociată unei sarcini, ca în tabelul de mai jos:

4. Modelarea logică (ML)

Modelarea logică are rolul de a iniția realizarea sistemului informațional informatizat (SII) sub cele patru aspecte fundamentale folosite de către metoda MERISE: descrieri-definiții, comunicație, date și prelucrări. Modelarea logică începe să țină seama de alegerile tehnice specifice SII cum ar fi: repartiția datelor și a prelucrărilor, rolul postului de lucru, arhitectura SGBD, rolul arhitecturii client-server etc. Această modelare logică realizează concret următoarele elemente specifice:

Modelarea logică are un domeniu specific, descris sintetic în figura de mai sus. Acest tip de modelare asigură și două decizii fundamentale:

alegerea tipului de sistem electronic de calcul (SEC) folosit în codul SII;

alegerea soluției de gestiune a datelor:

– bază de date locală (BDL)

– bază de date centrală (BDC)

– soluție mixtă cu BDL și BDC

– BD gestionată prin SGBD

– BD gestionată prin EXCEL

– BD gestionată prin SGBD și EXCEL

4.1. Descrieri și definiții la nivel logic

Sistemul informațional informatizat (SII) presupune utilizarea unui sistem electronic de calcul (SEC) de mare putere și a unui sistem de gestiune a datelor (SGD) capabil să asigure toate operațiile de prelucrare specifice unui OFB. În cadrul modelării logice, se pune problema alegerii celor mai performante SEC și SGD, această alegere făcându-se în funcție de următoarele criterii:

volumul datelor de prelucrat;

tipologia prelucrărilor: centralizată și/sau distribuită;

efortul financiar implicat;

timpul de răspuns solicitat către OFB;

natura prelucrărilor specifice SII.

Alegerea unui SEC se poate baza pe trei soluții de referință:

□ Soluția cu PC-uri independente(locale) utilizate independent unele de altele, transferul de date făcându-se off-line (prin schimbul de fișiere stocate pe hard-disk sau deschete).

□ Soluția cu rețele de calculatoare (RC); această soluție cu RC poate utiliza trei tipuri de arhitectură:

▪ arhitectura de tip LAN (local area networks – rețele locale). RC de tip LAN pot fi, în principiu, de următoarele topologii: topologia stea, topologia inel, topologia magistrală (bus), topologia arbore, topologia inel dublu, topologia inel configurat ca stea, topologia plasă, topologia stea ierarhică.

▪ arhitectura de tip RC mare, diferențiată în trei topologii de referință: RC de tip WAN – wide area networks (rețele extinse); RC de tip MAN metropolitan area networks (rețele metropolitane); RC de tip GAN – global area network.

□ Soluția mixtă este bazată pe combinații de PC-uri locale și RC, astfel încât să se asigure integral prelucrările sistemului informatic.

Utilizarea acestor tipuri de RC aduc mai multe tipuri de avantaje:

avantaje strategice, ca de exemplu – reducerea costurilor privind SII datorită faptului că RC sunt flexibile, asigurând creșterea volumului și calității serviciilor;

avantaje operaționale și tactice, ca de exemplu – administrarea cât mai eficientă a programelor se realizează în special pe arhitecturile client-server, în cadrul cărora resursele logice (programeme) sunt stocate fie pe file-server, fie pe PC-ul utilizatorului;

avantajele utilizatorului, ca de exemplu – facilitarea accesului la instruire al utilizatorilor se poate realiza printr-un sistem de asistență (help) prezent în fiecare aplicție sau chiar prin lecții interactive dedicate diferitelor categorii de utilizatori.

Alegerea unui sistem de gestiune a datelor (SGD) are în vedere trei componente esențiale:

Sistemul de operare (SO), care poate fi selecționat în funcție de soluția cu PC-uri locale (de exemplu: DOS.xx, WINDOWS 3.xx etc.) sau de soluția cu RC (exemplu: NOVELL 3.xx, WINDOWS x.xx etc.).

Sistemul de gestiune a datelor (SGD) presupune trei posibilități:

– SGD bazat în exclusivitate pe un SGBD

– SGD bazat în exclusivitate pe utilizarea tabelelor electronice de calcul (spreadsheets) gestionate prin EXCEL, LOTUS, QUATTRO etc.

-SGD mixt, cu posibilitatea interconexiunii dintre un SGBD și un spreadsheet.

Alegerea tipului de BD:

■ BD ierarhică și BD de tip rețea au la bază modelul ierarhic, respectiv cel de rețea de date.

■ Modelul relațional și BD relaționale au la bază organizarea datelor sub forma unor tablouri bidimensionale denumite tabele de date sau relații.

■ BD orientate pe obiecte (BDOO) beneficiază de un model de date orientat pe obiecte ce are la bază noțiunea de entitate conceptuală, definită ca un obiect descris printr-o colecție de proprietăți.

■ BD funcționale (BDF) au la bază modelul funcțional al datelor (MFD) bazat pe utilizarea unor limbaje ce folosesc principiile programării funcționale.

■ BD deductive (BDDC) folosesc conceptul de bază de date inteligentă (BDI) deoarece se asigură o gestiune materială a datelor, pentru memorarea, accesarea și utilizarea informațiilor.

4.2. Dicționarul atributelor

Dicționarul atributelor (DA) este un instrument informatic prin intermendiul căruia se stabilesc identificatorul unic, tipul, lungimea și condițiile de validare pentru toate atributele BD. Acest DA poartă și denumirea de metabază de date.

Prin dicționarul atributelor sunt stabilite toate detaliile descriptive ale fiecărui atribut, indiferent de apartenența sa la un anume tip de entitate sau relație. Astfel, pentru fiecare atribut din nucleul atributelor se stabilesc identificatorul asociat în mod unic la nivelul întregii BD, tipul, lungimea și condițiile de validare, toate aceste elemente fiind stabilite în funcție de cerințele și restricțiile impuse de SGD (deci de către sistemul de operare și SGBD).

Elementele specifice ale dicționarului atributelor sunt următoarele:

Identificatorul atributului este un nume unic asociat acestuia, prin intermediul căruia atributul poate fi descris și manipulat la nivelul BD. Identificatorul atributului are un format liber în anumite SGBD, în timp ce în altele este supus unor restricții stricte. Principalele restricții impuse de SGBD pentru identifiactorul unui atribut sunt, în principiu, următoarele: lungimea maximă 10 caractere alfanumerice, nu poate fi un cuvânt rezervat al SGBD gazdă, nu poate conține caractere speciale (!,?,$,<,=,> etc.) cu excepția caracterului "_", denumit liniuță de subliniere (underline).

Tipul și lungimea atributului indică natura datelor stocate prin identificatorul respectiv și numărul de caractere asociate acestuia. Aceste elemente se preiau din nucleul atributelor determinat prin modelarea conceptuală.

Condițiile de validare indică restricțiile pe care trebuie să le îndeplinească valorile reale ale unui tip de atribut pentru a fi admise în BD. Aceste condiții de validare pot fi determinate în funcție de: tipul și lungimea atributului, lista valorilor reale pe care le poate lua atributul respectiv, posibilitățile de validare prescrise de SGBD.

Condițiile de validare pot fi: aplicate asupra unui tip de atribut, stabilite între atribute, determinate în raport cu o constantă, precizate printr-o listă de valori, stabilite în raport cu un algoritm de calcul, determinate ca urmare a folosirii unor funcții matematice sau financiare.

4.3. Modelul logic de comunicație (MLC)

Modelul logic de comunicație (MLC) are rolul esențial de a determina arhitectura optimă a unei rețele de calculatoare (RC) în funcție de MOC și de particularitățile modelării logice. MLC trebuie să fie în concordanță cu alegerea optimă a configurației RC determinată prin modelul matematic asociat.

MLC poate fi particularizat în funcție de următoarele elemente fundamentale:

– MLC trebuie să fie definit în raport cu modelul de referință OSI (Open System Interconection), model care are la bază principiul “divide et impera” (dezbină și stăpânește). În mod particular, acest model se numește ISO/OSI, fiind definit de către Organizația Internațională pentru Standarde (ISO). Modelul ISO/OSI este organizat pe șapte nivele (figura următoare) și are la bază următoarele principii:

– fiecare nivel este determinat de o funcție exactă;

– funcția fiecărui nivel este determinată în funcție de folosirea protocoalelor standardizate cu caracter informațional;

– fiecare nivel este adăugat atunci când se impune un nou nivel de complexitate.

– MLC poate folosi cu preponderență RC de tip LAN (local area networks – rețele locale)

MLC presupune existența unei RC de tip LAN organizată conform unei configurații specifice unui anumit tip de LAN, formată din:

– calculatoare compatibile IBM denumite generic stații de lucru (work station);

– echipamente specifice;

– elemente de conectare.

Într-o RC aceste stații sunt de două tipuri:

– un calculator ce supraveghează întreaga activitate desfășurată la nivelul RC, calculator denumit server de fișiere (file server – FS);

– calculatoare conectate la un mediu de comunicație dat, prin intermediul cărora utilizatorii au acces la FS, calculatoare denumite stații de lucru (work stations – WS).

Alegerea sistemului de operare pentru rețele de calculatoare se face în raport cu următoarele principii: tipul rețelei de calculatoare; tipul procesorului central; particularitățile de prelucrare și gestiune a datelor din SII; gradul de distribuire geografică a prelucrărilor, datelor și utlilizatorilor; natura prelucrărilor specifice noului sistem; tipologia intrărilor și ieșirilor sistemului proiectat.

Sistemele de operare (SO) pentru rețele de calculatoare se numesc network operating systems (NOS), fiind un set software ce admite, controlează și monitorizează accesul la driverele de disc magnetic, imprimantă, unități de floppz-disk, unități CD etc. prezente în arhitectura unui LAN.

NOS interceptează și utilizează toate cererile de servicii transmise către servere, fiind reprezentat de un software de natură să ofere capabilități multitasking și multiutilizator pentru o rețea de calculatoare, asigurând în plus partajarea resurselor și comunicației efective.

Menționăm că NOS determină și clasa de echipamente compatibilă cu un LAN și gestionează cererile de servicii ale tuturor utilizatorilor din rețeaua de calcul.

4.4. Modelul logic de date (MLD)

Modelul logic de date (MLD) este realizat prin conversia MCD/MOD prin intermediul următoarei succesiuni:

transformarea MCD/MOD, exprimat în formalismul entitate-relație, în MLD exprimat în formalismul logic adaptat strict unei SGBD, folosindu-se fie modelul relațional de date propus de E.F.CODD, fie modelul navigațional propus de CODASYL;

cuantificarea în modelul logic;

optimizarea generală pentru realizarea MLD optimizat, privit ca sursă de obținere a modelului fizic de date (MED), deci a schemei BD.

Particularitățile modelului relațional

Gestiunea datelor de către un SGBD se poate face prin intermediul a trei modele de date irarhic, rețea și relațional.

În comparație cu modelele ierarhic și rețea, modelul relațional prezintă, în principal, următoarele particularități:

asigură metode și tehnici eficiente de verificare a coerenței și redundanței datelor;

dispune de un suport teoretic puternic din punct de vedere matematic, suport perfecționat continuu;

asigură un grad ridicat de independență a aplicațiilor informatice în raport cu modul de reprezentare internă a datelor și metodele de acces la date;

oferă posibilitatea utilizării unor limbaje procedurale, bazate pe algebra relațională, precum și a unor limbaje neprocedurale (declarative) ce folosesc calculul relațional;

manipularea datelor se face la nivel de relație, proprietate ce asigură paralelismul și prelucrarea datelor, inclusiv posibilitatea utlizării limbajelor SQL;

asigură integritatea și confidențialitatea datelor prin intermediul unor mecanisme flexibile de specificare și manipulare a relațiilor virtuale și restricțiilor de integritate.

Modelul relațional are următoarele componente:

Structura relațională a datelor: datele sunt organizate sub forma unor tablouri bidimensionale (tabele) de date, denumite relații. Asocierile dintre relații se realizează prin intermediul atributelor de legătură, denumite concret chei primare și chei externe (CP și CE).

Elementele de algebră relațională: conțin în principal operatorii modelului relațional;

Restricțiile de integrare ale modelului relațional: definesc cerințele pe care trebuiesc să le îndeplinească datele pentru a fi coerente și corecte în raport cu realitatea pe care o reflectă.

4.5. Modelul logic de prelucrare (MLP)

Modelul logic de prelucrare (MLP) trebuie să asigure următoarele funcții:

structura sistemului în componente logice: subsisteme informatice, aplicații informatice și proceduri logice/unități logice de prelucrare;

modelarea prelucrărilor la nivel logic prin folosirea unor concepte specifice: centrul de lucru logic, mașina logică, unitatea logică de prelucrare/procedura logică, subschema logică de date etc.

Complexitatea unui sistem informatic impune structurarea acestuia în componente logice. Rezultă că modelarea logică asigură și structura logică a noului sistem, pe baza căreia, prin intermediul modelării fizice, se obține structura fizică.

Subsistemul informatic este o parte componentă a sistemului informatic prin intermediul căreia se automatizează o funcție asociată unei OFB sau unei operații decupate dintr-o funcție. Aplicația informatică este o parte componentă a unui subsistem informatic ce asigură informatizarea unei subactivități specifice. Procedura logică sau unitatea logică de prelucrare este o parte componentă a unei aplicații informatice, caracterizată prin prelucrări omogene și specifice.

Procedurile logice pot fi determinate în raport cu o serie de criterii, dintre care menționăm:

similitudinea activităților desfășurate în cadrul compartimentelor unei aplicații;

specificul prelucrărilor automate;

frecvența de prelucrare;

structura și semnificația activităților specifice unei aplicații;

interfața dintre procedurile logice.

5. Modelarea fizică

Modelarea fizică se desfășoară la nivel fizic/operațional și are în vedere specificațiile tehnice aferente unui SGBD, realizând practic conversia nivelului organizațional în nivelul fizic/operațional. Astfel, modelarea fizică abordează cele patru nivele de referință ale metodei MERISE, după cum urmează:

5.1. Descrieri și definiții

Utilizatorii SGBD

La utilizarea unei rețele de calculatoare (RC) în contextul unui SGBD deja modelat, se pune problema definirii tuturor categoriilor de utilizatori, deoarece a integra într-o RC un anumit calculator (o stație de lucru) presupune de fapt interconectarea cu alte stații de lucru și echipamente periferice, în scopul partajării resurselor fizice (memorie, periferice, mediu de comunicație etc.) a MFD și a MFP, precum și comunicarea cu alți utilizatori din RC.

În condițiile utilizării unui SGBD dezvoltat prin intermediul unei rețele locale de calculatoare (RC) și a unei baze de date distribuite (BDD), utilizatorii sunt următorii:

■ Utilizatori singulari (US): – utilizatori neinformaticieni (UN)

– utilizatorul operativ (OP)

– supervizorul (SV)

■ Utilizatori de grup (URG): – utilizatori ghișee (UG)

– utilizatori compartimente (UC)

– manageri departamente (MD)

– manager general (MG)

■ Utilizatori de sistem (USI): – administratorul BD (ABD)

– administratorul datelor (AD)

– inginerul de sistem (IS)

– inginerul instalator de rețea (IIR)

Protecția bazei de date distribuite

Problematica protecției bazei de date distribuite constă într-un set de măsuri prin care trebuie să se asigure integritatea datelor (concretizată prin corectitudinea datelor introduse și mani-pulate) precum și securitatea datelor ce blochiază accesul la BDD pentru persoanele care nu au drepturile aferente.

Protecția BDD are în vedere următoarele elemente:

■ Integritatea datelor:

– integritatea semantică;

– controlul accesului concurent la BDD;

– salvarea și restaurarea BDD.

■ Securitatea BDD:

– autorizarea și controlul accesului la date;

– criptarea și decriptarea BDD.

Integritatea semantică vizează semnificația datelor introduse, prelucrate sau furnizate ca ieșiri și are în vedere două restricții:

Restricții implicite de integritate: sunt cele relative la integritatea entității și intergitatea referențială

Restricții explicite de integritate: sunt folosite în cadrul procedurilor automate pentru a fi activate în momentul exploatării acestora sau sunt memorate în dicționarul atributelor, de unde sunt folosite automat de către SGBDR.

Salvarea și restaurarea reconstituie datele BDD într-o formă consistentă dacă au apărut anumite anomalii: funcționarea incorectă a SGBDD, defecțiuni fizice ale dispozitivelor de memorare, ale sistemului de comunicație etc.

Scopul fundamental al operațiilor de salvare/restaurare este de a asigura consistența BDD, definită prin situația în care rezultatele finale ale executării tranzacțiilor sunt corecte, nici o tranzacție nu este activată sau în lucru, iar restricțiile de integritate semantică implicite și explicite sunt realizate.

Salvarea BDD înseamnă realizarea unor copii de siguranță ale conținutului fizic al BDD, fie la nivelul fiecărei stații de lucru și al fiecărui mod de prelucrare, fie global, la nivelul întregii BDD, într-o rețea de tip LAN sau WAN.

Salvarea la nivelul global al BDD înseamnă:

salvarea schemei globale (MLD sau MFD);

salvarea schemei fragmentării (SSL sau SSF);

salvarea schemei de alocare.

Salvarea la nivelele locale ale BDD are în vedere:

salvarea fiecărei scheme locale în parte;

salvarea fiecărei BDD pentru fiecare WS (work station – stație de lucru).

Procesul de salvare este concretizat în:

copii ale BDD;

jurnale de tranzacții;

jurnale ale imaginii înregistrărilor BDD.

Restaurarea BD este procesul invers operației de salvare, prin care se asigură reconstitui-rea și punerea în funcțiune a BDD. Restaurarea BDD se poate face automat sau manual.

Restaurarea automată este asigurată de către SGBDD după oprirea și repornirea sistemului în urma apariției unei anomalii, astfel încât BDD să fie adusă într-o stare consistentă, prin derularea inversă a tranzacțiilor înregistrate și finalizate în fișierul jurnal, dar neânregistrate în BDD. Prin procesul de repornire se asigură sincronizarea BDD cu fișierul jurnal prin executarea unui punct de verificare (checkpoint). Acest proces de restaurare este dependent de frecvența punctelor de verificare, BDD putând fi restaurată rapid dacă există o frecvență mare a punctelor de verificare.

Restaurarea manuală cuprinde doi pași esențiali:

deconectarea tuturor utilizatorilor de la BDD, urmată de realizarea copiei de siguranță, după care utilizatorii sunt reconectați la RC, continuându-se lucrul cu BDD;

efectuarea copiilor de siguranță în mod dinamic, simultan cu continuarea accesului utilizatorilor la BDD, întregul proces de restaurare desfășurându-se on-line.

Securitatea BDD se asigură prin interzicerea accesului neautorizat la datele stocate prin intermediul unor măsuri de protecție umană, software, hardware etc. În continuare vom prezenta câteva măsuri de autorizare și control al accesului la date:

Izolarea sistemului central de calcul, unde accesul persoanelor să se facă prin mijloace electronice de identificare.

Stabilirea unei parole de acces și a unor coduri de identificare, pentru a se verifica dacă utilizatorul poate avea acces la BDD.

Securitatea la conectare, prin care utilizatorul își declară numele pentru a fi recunoscut de file-server.

Securitatea prin drepturi diferențiate acordate utilizatorilor are în vedere accesul utilizatorului la un anumit director de lucru. Drepturile stabilesc tipurile de operații la care utilizatorul are acces prin intermediul directorului de lucru.

Securitatea prin drepturile acordate în directoare se referă la drepturile acordate tuturor utilizatorilor pentru un director specificat.

Securitatea prin atributele fișierelor și directoarelor are în vedere evitarea modifică-rilor accidentale ale fișierelor, mai ales în situația fișierelor publice folosite de mai mulți utilizatori.

Criptarea este un proces de codificare a BDD în perioada stocării sau a manipulării, decriptarea putând fi realizată numai de utilizatorii ce dețin codul de criptare.

Procesul practic de criptare/decriptare are următoarele componente: algoritmul de criptare, cheia de criptare, algoritmul de decriptare, cheia de decriptare.

Decriptarea este procesul invers criptării, prin care datele criptate sunt readuse în formatul inițial, asigurându-se astfel regenerarea BDD în aceiași formă cu cea din momentul declanșării procesului de criptare.

5.2. Modelul fizic de comunicație (MFC)

Modelul fizic de comunicație (MFC) asigură modelarea fenomenului de comunicație la nivel operațional și are în vedere stabilirea concretă a următoarelor elemente:

□ arhitectura fizică a rețelei dedicate SGBD în raport cu modelul de referință OSI;

□ analiza nivelelor specifice modelului de referință OSI;

□ descrierea modelului de referință pentru interconectarea sistemelor deschise;

□ descrierea efectivă a MFC axat pe patru variante:

■ MFC bazat pe rețele de calculatoare de tip LAN și LAN interconectate;

■ interconectarea de rețele LAN de tip omogen;

■ interconectarea platformelor LAN eterogene multiprotocol;

■ interconectarea LAN la distanță.

Modelul fizic de comunicație (MFC) are de fapt la bază o arhitectură fizică de rețea ale cărei funcții de comunicație sunt partiționate într-o structură verticală pe nivele. Fiecare nivel realizează un subset de funcții de comunicație necesare comunicației cu un alt sistem, în vederea asigurării funcțiilor fizice ale unui SGBD. Fiecare nivel se bazează pe nivelul imediat inferior în scopul realizării unor funcții elementare și specifice; în plus, ascunde față de nivelul superior detaliile de implementare ale funcțiilor executate.

Descrierea MFC cuprinde specificarea tuturor componentelor și particularităților fizice ale RC folosite, modul de interconectare practic al calculatoarelor folosite, precizarea caracteristicilor tehnice (memorie internă, unitate centrală, tipurile, mnemonicele și capacitățile suporturilor tehnice externe, locul și rolul WS și FS, conexiunea WS – FS) prin intermediul unei scheme denumită configurația, arhitectura sau topologia RC.

Deoarece în România se folosesc cu preponderență RC de tip LAN, vom prezenta în continuare particularitățile MFC prin prisma rețelelor de tip LAN.

În aceste condiții, pentru MFC există două soluții esențiale:

MFC realizat prin RC de tip LAN;

MFC realizat prin RC de tip LAN interconectate.

Soluția cu RC de tip LAN este aplicabilă atunci când în trecerea de la MLC la MFC nu sunt necesari interconectorii de RC, iar prelucrările au caracter local. Astfel, pot fi alese RC de tip LAN cu topologie de tip star, bus sau ring.

Soluția cu RC de tip interconectat devine viabilă în situația în care SGBD proiectat are prelucrări cu caracter distribuit și sunt necesare conexiuni directe, on-line, între eventualele sedii, sucursale, filiale etc.

Această soluție poate fi aplicată în trei condiții:

interconectare de RC LAN de tip omogen;

interconectarea platformelor LAN eterogene multiprotocol;

interconectarea LAN la distanță.

5.3. Modelul fizic de date (MFD)

Modelul fizic de date (MFD) se obține prin reprezentarea MLD într-un limbaj de descriere a datelor asociat strict unui SGBD. Practic, un SGBD va utiliza acest MFD pentru ca, prin intermediul MFP, să poată asigura un ciclu coerent de prelucrare de tip local/distribuit, format în principiu din operații de creare, actualizare, exploatare, listare, reorganizare, salvare, restaurare, protecție etc.

Rezultă că un MFD este asociat unui SGBD care are următoarele obiective referitoare la date:

neredundanța datelor: acestea sunt integrate de fapt în fișiere ce conțin date distincte, reducându-se astfel problemele legate de cererile de date, actualizare și riscul de incoerență;

coerența datelor: poate fi asigurată prin expresia constrângerilor de integritate folosite de către metoda MERISE, constrângeri ce sunt de fapt folosite de către toată SGBDR;

partajarea datelor: are în vedere posibilitatea folosorii simultane a datelor fizice de către mai multe aplicații informatice prin intermediul unor mecanisme specifice la nivel de SGBD;

securitatea datelor: înseamnă protejarea acestora împotriva accesului neautorizat, nepro-fesional, în cadrul operațiilor complexe efectuate asupra BD de către SGBD.

SGBD are și o serie de obiective organizatorice, dintre care menționăm următoarele:

asigurarea unui control riguros asupra datelor;

optimizarea accesului la date;

optimizarea mediilor informatice;

rezolvarea conflictelor între diversele puncte de vedere ale utilizatorilor;

utilizarea unui administrator al datelor (AD) ce se va ocupa de semantica, valorile reale și aspectele organizatorice impuse de generarea – transmiterea – prelucrarea – distribuirea datelor;

existența unui administrator al BD (ABD), persoană ce se va ocupa de problemele tehnice ale utilizării fizice a unei BD locale (BBL) sau a uneia distribuite (BDD).

Arhitectura unui SGBDR asigură organizarea datelor stocate sub formă de tabele. În continuare, un asemenea sistem permite definirea unei scheme relaționale ce asigură conversia logic/fizic prin descrierea datelor din diferitele tabele, precum și indecșii de acces la aceste tabele. Alături de aceste tabele de date și de index există și alte structuri complementa-re prin care se asigură integral regulile de elaborare a diferitelor vederi asupra BD. Arhitectura unui SGBDR poate avea diverse componente, diferențiate în funcție de firma producătoare.

Exemplu de arhitectură de tipul SGBD SQL/DS (IBM) având următoarele componente esențiale: DSC – data system central: asigură comunicația SGBDR cu alte programe; RDS – relation data system: asigură prelucrările cererilor privind analiza, optimizarea și compilarea; DBSS – database storage system: asigură accesul de la RDS, alocă spațiul fizic necesar, asigură accesul concurent și reface BDR în caz de incident sau anomalie.

SGBD folosește următoarele limbaje:

■ Limbajul de descriere a datelor – LDD: asigură descrierea datelor într-o manieră unică și centralizată, dependentă de un standard utilizat pe scară largă de SGBDR (ACCESS, FOXPRO, PARADOX, CLIPPER, dBASE etc.). În mod curent acest LDD asigură coerența datelor sub aspectul MFD.

■ Limbajul de manipulare a datelor – LMD: asigură actualizarea și consultarea BD, inclusiv definirea și gestiunea diferitelor obiecte mai mult sau mai puțin complexe de tipul ecrane, forme, etichete, cadre etc., privite ca elemente complementare ale utilizării unei BD.

■ Limbajul de interogare a datelor – LID: reprezintă de fapt un program complementar unui SGBD prin care se propune un limbaj de interogare și de acces la BD, definit și utilizat special de către utilizatorii neinformaticieni.

Practic, SGBDR comercializate pe piață au implementat limbajul cunoscut sub acronimul SQL – structured query language, propus de către echipa de cercetare IBM.

Conversia din MLD/MOD în MFD în cadrul formalismului relațional se realizează astfel:

5.4. Modelul fizic de prelucrare (MFP)

MFP are rolul esențial de a asigura funcționalitatea SGBD la nivelul operațional folosind MFC și MFD, în scopul realizării de proceduri automate ce pot fi corelate cu procesele de prelucrare specifice noului sistem. În acest sens, procedurile automate devin elemente esențiale ale MFP prin care se asigură întreaga operaționalitate la nivel fizic.

Procedurile automate sunt caracterizate prin funcții, date de intrare/ieșire (I/E) și o logică internă de prelucrare specifică, existând o tipologie adecvată în raport cu care procedurile automate se descompun în module ce implementează funcțiile elementare de prelucrare, deduse din funcția generală specifică procedurii automate. Pentru a asigura operaționalitatea procedurilor automate, se vor defini prelucrările necesare, deduse din categoria prelucrărilor specifice aplicațiilor informatice din care fac parte respectivele proceduri automate.

Procedurile automate sunt reprezentate de o colecție de comenzi unitare scrise într-un LDD și LMD, componente ale unui SGBDR, prin care sunt definite prelucrări specifice asupra diferitelor tipuri de componente ale unei BDR (tabel, interogare, formular, raport), executate în sensul solicitat de către o sarcină preluată din MLP, în mod parametrizat și fără întreruperi de la un post de lucru; prin aceste proceduri o mulțime de date de intrare sunt transformate în date de ieșire și/sau date intermediare în raprot cu un algoritm de prelucrare sau de calcul, toate aceste elemente fiind memorate împreună sub un nume unic și o extensie specifică SGBDR.

SGBDR folosesc și alte concepte în raport cu procedurile automate:

dBASE, FOXPRO, CLIPPER folosesc conceptul de procedură;

ACCESS folosește conceptele de macroinstrucțiune și modul.

O macroinstrucțiune (pe scurt macro) este o acțiune sau un set de acțiuni folosite pentru auto-matizarea unei sarcini, în timp ce modulul este privit ca un set de declarații, comenzi și proce-

duri memorate împreună sub același nume și cu o extensie asociată.

Procedurile sunt caracterizate prin următoarele elemente:

Funcția procedurii: arată modul efectiv de prelucrare a datelor, respectiv sensul general de transformare a datelor de intrare în date de ieșire, deci procesele generale și specifice de utilizare a datelor. Pot fi de mai multe feluri: proceduri de dirijare/monitorizare, proceduri de actualizare, proceduri de calcul asupra tabelelor BD, proceduri de reorganizare a BD, proceduri de protecție și securitate a BD.

Intrările procedurii: reprezintă sursele de date pe care acestea le folosesc pentru asigurarea funcționalității lor, precum și alte elemente secundare ale structurii unei SGBD cum ar fi: tabele, formulare, interogări etc.

Ieșirile procedurii: sunt reprezentate de datele și formatele obținute ca urmare a unei proceduri și a utilizării eventual a unui algortim de prelucrare/calcul.

Logica internă de prelucrare: arată modul concret de conversie a intrărilor în folosirea unui algoritm de prelucrare (introducere de date, validare date, conversie, obținerea unor tabele fizice intermediare, obținerea unor ieșiri etc.) sau algoritm de calcul (calculul încasărilor zilnice, a plăților și a soldurilor al finalul zilei în lei sau în alte valute etc.).

Interfața dintre proceduri: arată legăturile de date și de comunicație stabilite între proceduri pe parcursul exploatării lor, astfel încât ieșirile unor proceduri să poată fi identificate, recunoscute, convertite și utilizate ca intrări într-o altă procedură prin intermediul unor structuri de date sau eventual meniuri de prelucrare.

ANEXA 1.

Detalii cu privire la obiective, iesiri, formalizarea atributelor

și documente de intrare

1. Definirea obiectivelor (se face în etapa MGD)

Obiectivele sistemului informatic reprezinta scopuri imediate si de perspectiva ale perfectionarii activitatii economice si de conducere, in vederea ridicarii nivelului de informare operativa si previzionala a structurilor organizatorice, a perfectionarii metodelor si proceselor tehnico-informationale si de conducere pentru asigurarea maximalizarii efieientei economice si a rentabilitatii unitatii beneficiare.

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

Obiectivele sistemului informatic pot fi:

generale ;

specifice.

•Obiective generale

Obiectivele generale ale unui sistem informatic vizeaza probleme cu caracter global ale conducerii unitatii comerciale si structurale specifice compartimentelor functionale, în scopul realizarii atributelor conducerii si ale functiilor unitatilor economice. in raport de aceste aspecte, obiectivele generale pot fi:

– de conducere (manageriale);

– funcționale.

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

– rentabilizarea permanenta a activitatii economice;

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

– perfectionarea activitatii de conducere în vederea asigurarii unui optim globalla nivelul întregii activitati economice;

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

– asigurarea unei coordonari a intregului sistem informational – decizional;

– utilizarea selectiva a unor informatii de exceptie (rata anuala de înnoire a mijloacelor fixe, tendintele preturilor de aprovizionare, etc.), pentru asigurarea unei gestiuni eficiente a patrimoniului net pe baza unor informatii cu caracter programatic si analitic;

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

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

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

– extinderea principiului conducerii prin exceptie si pe baza de obiective.

Obiectivele funcționale ale unui sistem informatic au în vedere informatizarea activitatilor în conformitate cu anumite functii ale unitatii economice (comerciala,· financiar-contabila si de personal), desfășurată la nivelul compartimentelor functionale. Aceste obiective sunt fundamental dependente de specificul activitatii regiilor autonome sau al societatilor comerciale si cuprind urmatoarele deziderate generale:

a) Activitatea comerciala (aprovizionare, desfacere, marketing,) desfasurata in cadrul unor compartimente corespunzatoare are în vedere elementele specifice fiecarei subactivitati din punct de vedere informatic, dupa cum urmeaza:

– Subactivitatea de aprovizionare tehnico-materială propune rezolvarea urmatoarelor aspecte specifice:

fundamentarea necesarului si a comenzilor de aprovizionat;

contractarea necesarului de aprovizionat;

urmarirea derularii contractelor de aprovizionare.

– Subactivitatea de desfacere a rezultatelor activitatii presupune:

primirea si centralizarea comenzilor de la clienti;

livrarea catre clientii interni si externi a productiei contractate;

urmarirea ritmicitatii livrarilor în scopul onorarii contractelor încheiate.

Subactivitatea de marketing presupune:

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

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

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

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

Subactivitatea financiara are în vedere:

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

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

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

efectuarea si urmarirea decontarilor cu tertii (persoane fizice sau juridice).

Subactivitatea de contabilitate la nivelul unitatii economice se structureaza în doua componente:

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

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

înregistrarea cronologica si sistematica a tuturor operatiilor economice;

prelucrarea datelor în concordanta cu principiile si metodele contabilitatii;

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

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

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

Subactivitatea de evidenta a personalului, presupune:

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

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

verificarea încadrarii personalului pe profesii, functii si locuri de activitate.

– Subactivitatea de salarizare asigura:

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

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

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

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

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

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

•Obiective specifice

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

– obiective specifice activitatii de baza;

– obiective specifice activitatii auxiliare.

Obiectivele specifice activitatii de baza urmaresc realizarea sub aspect informatic a tuturor subactivitatilor de cercetare si productie ce constituie specificul activitatii regiei autonome sau al societatii comerciale. Aceste obiective sunt diferentiate (au caracter particular), dar ele se pot incadra într-o structura fundamentala, prin intermediul careia sistemul informatic trebuie sa realizeze:

– utilizarea eficienta a capacitatilor de productie;

– introducerea de tehnologii si produse noi la nivelul tehnicii actuale;

– realizarea ritmica si de calitate a lucarilor de investitii;

– modernizarea utilajelor si a altor factori de prodctie;

– îmbunatatirea continua a calitatii productiei;

– cresterea gradului de utilizare a capacitatilor de productie;

– încadrarea consumurilor de materiale în normele tehnologice;

– utilizarea rationala a capacitatilor de depozitare a materialelor si produselor.

Obiectivele specifice activitatii auxiliare vor avea în vedere realizarea sub aspect informatic a tuturor subactivitatilor secundare, desfasurate în cadrul unitatii economice. Aceste obiective au un caracter particular, o pondere si o importanta diferentiata de la un agent economic la altul, avand ca scop rezolvarea unor aspecte specifice, cum ar fi:

– urmarirea operativa a activitatii sectoarelor auxiliare a caror activitate determina in mod direct desfasurarea activitatilor principale;

– folosirea eficienta a capacitatilor auxiliare de productie;

– robotizarea, paleatizarea si containerizarea activitatilor auxiliare din unitatea economica;

– realizarea programelor de asimilare a noilor produse si de perfectionare a tehnologiilor de fabricatie în scopul generalizarii la nivelul activitatii de baza;

– asigurarea unei colaborari si specializari ale caror rezultate urmeaza a fi incluse în sectoarele de baza ale unitatii economice.

Obiectivele generale si specifice ale unui sistem informatic, pot surprinde si alte aspecte concrete, ce decurg din:

– marimea unitatii economice;

– ponderea acesteia într-o ramura de activitate;

– gradul de specializare a activitatilor de baza si auxiliare, într-un domeniu concret al economiei de piata;

– gradul de participare al unitatii economice la derularea unor operatiuni de export-import, cooperare internationala etc., factori ce pot impune si alte tipuri de obiective, a caror nuantare va fi diferita de la o unitate economica la alta.

Obiectivele sistemului informatic trebuie sa asigure:

– utilizarea eficienta si extensiva a sistemelor electronice de ealcul si a retelei de calculatoare-teletransmisie, specifice întregului sistem informatic proiectat :

– cresterea vitezei de circulatie a informatiilor, reducerea ciclului informational si a timpului de raspuns ca urmare a realizarii noului sistem informatic.

– functionarea performanta, în conditii de fiabilitate si stabilitate în timp, a întregului ansamblu de echipamente de calcul, care trebuie sa realizeze:

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

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

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

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

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

asigurarea unei securitati si confidentialitati maxime a colectiilor de date si a utilizatorilor etc.

Abordarea integrala a obiectivelor generale si specifice permite proiectarea unui sistem informatic integrat (total) la nivelul unei unitati economice în conditii de eficienta maxima.

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

2. Iesirile sistemului informatic (se identifică în MGD și se aprofundează în MCDD)

Realizarea practica a obiectivelor sistemului informatic se caracterizeaza prin satisfacerea cerintelor informationale ale conducerii și structurilor organizatorice din unitatea beneficiara.

Iesirile sistemului informatic pot fi privite din punct de vedere:

structural;

functional;

tipologic.

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

Din punct de vedere functional, iesirile sistemului informatic concretizeaza obiectivele generale si specifice ale sistemului proiectat.

Din punct de vedere tipologic, iesirile sistemului informatic pot fi redate sub forma de:

– indicatori sintetici privind starea si rezultatele activitatii economico-financiare;

– liste/situatii de iesire care cuprind indicatorii analitici ai starii si rezultatelor activitatii economico-financiare;

– grafice care redau sub forma sinoptica starea si evolutia indicatorilor economico-financiari

– iesiri catre alte sisteme informatice, transmise în direct (off-line) prin intermediul suporturilor magnetice (disc flexibil, disc magnetic,banda magnetica etc.), sau direct (on-line) prin intermediul unei retele locale de calculatoare.

Indiferent de tipologia iesirilor sistemului informatic, acestea trebuie sa respecte cerintele si restrictiile cadrului legislativ-normativ în vigoare, pentru ca activitatea unitatii economice sa se desfasoare in coordonatele legalitatii economice.

2.1. Indicatorii economico-financiari specifici unitatii economice au rolul de a caracteriza din punct de vedere sintetic si analitic activitatea economico-financiara prin intermediul unor informatii care redau:

– patrimoniul net al regiei autonome sau a societatii comerciale prin intermediul inventarierii patrimoniului si a posturilor din bilantul contabil elaborate la finele perioadei de gestiune;

– starea si rezultatele economico-financiare ale unitatii economice pe o perioada determinata de gestiune;

– calculul si planificarea financiara a investitiilor;

– calculul si planificarea rezultatelor economico-financiare;

– calculul si previzionarea activelor circulante si surselor de finantare;

– calculul si previzionarea activitatii de trezorie.

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

Selectarea concreta a anumitor indicatori din multimea totala a acestora se poate realiza în functie de:

– Tipul unitatii economice (regii autonome, societati comerciale in: nume colectiv, comandita simpla, comandita pe actiuni, societate pe actiuni si societate cu raspundere limitata determina utilizarea nuantata a unor indicatori economico-financiari.

– Specificul activitatii de baza a unitatii economice poate determina utilizarea unor indicatori economico-financiari comuni sau specifici. De exemplu, pentru regiile autonome de extractia petrolului, natura activitatii determina utilizarea unor indicatori specifici, cum ar fi: productia marfa fabricata, productia marfa vînduta si incasata etc., în timp ce la o societate comerciala a carei activitate de baza consta în comercializarea bunurilor de consum, se vor utiliza indicatori .specifici activitatii, cum sunt: valoarea totala a vanzarilor de marfuri, cheltuieli totale cu depozitarea marfurilor, cheltuieli de reclama si publicitate etc.

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

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

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

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

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

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

Determinarea concreta a continutului, formei si a circuitului informational al situatiilor de iesire sunt realizate în functie de natura activitatii, cerintele informationale ale conducerii unitatii economice, obiectivele propuse, cadrul legislativ-normativ (legi, decrete, hotârari, norme metodologice, instructiuni, decizii interne) si cerintele specifice, unitatii beneficiare. Aceste restrictii impun un anumit continut economic al situatiilor inclusiv elementele referitoare la destinatie, utilizare, frecventa si forma concreta în care vor apare.

Listele/situatiile de iesire ce urmeaza a se obtine în cadrul unui sislem informatic pot fi structurate si utilizate în concordanta cu:

– specificul functiilor desfasurate concret în unitatea economica;

– destinatia listelor/ situatiilor de iesire;

– gradul de sintetizare a indicatorilor economico-financiari inclusi in liste/situatii;

– momentul generarii listelor/situatiilor de iesire;

– referinta în timp a acestora;

– modul de obtinere a listelor/situatiilor de iesire etc.

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

Determinarea concreta a continutului, formei si a circuitului informational specific situatiilor de iesire sunt determinate în functie de:

– natura si complexitatea activitatii desfasurate de unitatea economica;

– cerintele informationale formulate de conducerea unitatii economice beneficiare;

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

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

Structurarea situatiilor de iesire se realizeaza în functie de:

– specificul functiilor generale ale unitatii economice;

– destinatia listelor situatiilor de iesire;

– gradul de sintetizare a indicatorilor economico-financiari;

– momentul generarii situatiilor de iesire;

– modul de obtinere.

La definitivarea fiecarei liste/situatii de iesire se recomanda:

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

– indicatorii prezenti în fiecare coloana cu specificarea:

– algoritmul de calcul(daca este cazul);

– natura si lungimea maxima a fiecarui indicator;

– gradele de total si subtotal;

– numarul de exemplare, destinatia fiecarui exemplar, frecventa, termenele de obtinere.

La definitivarea continutului si formei listelor/situatiilor de iesire se recomanda sa se urmareasca o valorificare cat mai deplina a posibilitatilor de prelucrare oferite de sistemul electronic de calcul. De asemenea, se vor avea în vedere si anumite cerinte cu caracter general, cum sunt rezolvarea unor functii majore ale conducerii unitatii, existenta unei game suficiente si reprezentative de informatii, pentru a permite analiza exhaustiva a fenomenelor si proceselor economice reflectate. Aceste cerinte impun ca listele/situatiile de iesire sa fie prezentate într-o forma simpla, inteligibila de natura sa asigure si facilitatea în utilizare, ceea ce impune omiterea detaliilor nesemnificative, ce nu corespund scopului propus.

2.3. Graficele redau într-o forma sugestiva evolutia in timp a valorii indicatorilor economico-financiari continuti în listele/situatiile de iesire. Ele pot fi :

– graficele liniare redau evolutia in timp a valorilor specifice fiecarui indicator, reprezentate prin puncte amplasate la o distanta de axa orizontala, proportionala cu valorile respective. intr-un asemenea grafic se pot reprezenta maximum sase indicatori;

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

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

–

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

– graficele rotunde asigura reflectarea ponderii unor valori aferente unui indicator în cadrul unui set complet de valori, ce reprezinta valorile integrale sau totale ale indicatorului. În mod concret, graficul are forma unui cerc, iar fiecare valoare a indicatorului este reprnzentata prin intermediul unui sector de cerc si redat în unitatile procentuale.

Aceste grafice pot fi însotite de elemente complementare:

– titlul si subtitlul graficului;

– legende privind reprerentarea indicatorilor din grafic;

– grile pentru redarea graficului prin linii orizontale, verticale sau prin patrate.

– reprezentarea cromatica a graficului (alb-negru sau alte culori);

– definirea unor formate corespunzatoare pentru valorile indicatorilor (numar fix de zecimale, reprezentare eu mantisa si exponent, prin procente; format histograma – semnul “+” pentru valori pozitive si semnul “-“ pentru valori negative etc.).

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

2.4. Iesiri către alte sisteme

Sistemul informational propriu unitatii economice se afla în interconexiune cu sistemele informationale aferente altor unitati economice sau organisme guvernamentale. Aceasta caracteristica impune si necesitatea corelarii sistemului informatic specific unitatii economice benefiaiare cu alte sisteme informatice conexe. in acest sens, iesirile sistemului informatic al unitatii beneficiare pot constitui intrari în alte sisteme informatice, în timp ce iesirile altor sisteme informatice pot fi intrari în sistemul informatic propriu unitatii economice. Aceste interconditionari se pot realiza prin intermediul retelelor de calculatoare ce vor asigura conexiunea dintre bazele informationale specifice, carora le vor corespunde bazele de date asociate, între care se realizeaza schimbul efectiv de date.

Din punct de vedere tipologic, iesirile catre alte sisteme informatice pot fi:

– directe (on-line), asigurate prin intermediul transmisiilor de date între doua retele locale de calculatoare proprii agentului economic;

– indirecte (of f-line), asigurate prin transmiterea datelor într-o anumita structura, continut si un anumit suport magnetic, la anumite frecvente stabilite de comun acord.

3. Formalizarea atributelor (se aplică în MCDD)

Formalizarea atributelor are ca scop elaborarea codurilor si adaptarea documentelor de intrare la cerintele sistemului informatic.

-3.1 Codificarea atributelor

Necesitatea codificarii atributelor este impusa de cerintele de grupare si ierarhizare a atributelor care ofera multiple posibilitati de prelucrare a colectiilor de date în care va fi transpusa baza informationala. Codificarea atributelor conduce si la utilizarea intensiva a suporturilor direct adresabile si a memoriei interne, ceea ce permite optimizarea accesului la diverse valori a atributelor, concomitent cu minimalizarea timpului de prelucrare a viitoarelor colectii de date. De asemenea, codurile aferente atributelor bazei informationale pot asigura confidentialitatea si integritatea valorii atributelor, ceea ce confera colectiilor de date o anumita protectie si securitate în timpul prelucrarii.

In mod concret codificarea atributelor trebuie sa realizeze o corelatie directa între

semantica atributelor existente în baza informationala de intrare si multimea de

simboluri acordate acestora (codurile sistemului informatic) în concordanta cu cerintele

si functiile specifice codurilor. În acest sens, se urmaresc:

– cerintele si functiile codificarii;

– tipurile de coduri utilizate într-un sistem informatic;

– fazele realizarii codificarii.

a) Cerintele si functiile codificarii

Activitatea de codificare a atributelor, trebuie sa asigure o legatura între specificul unitatii economice si particularitatile bazei informationale de intrare.

Codificarea trebuie sa raspunda urmatoarelor cerinte:

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

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

Atribuirea codurilor pentru eventualele noi valori ale atributelor se poate realiza prin doua modalitati:

– acordarea de noi coduri pentru valorile atributelor ce apar ulterior alocarii initiale de coduri, în cadrul aceleiasi clase de coduri, astfel încat totalitatea codurilor utilizate la un anumit moment sa poata asigura corespondenta reala cu dinamica activitatii unitatii economice;

– folosirea unor tipuri de coduri care sa fie asociate claselor de coduri initiale, astfel încat noul cod utilizat, desi cu lungimea marita, sa caracterizeze în mod obiectiv fiecare tip de atribut.

– Comoditatea utilizarii codului se refera la facilitatea operatiilor de codificare-decodificare precum si la detectarea si corectarea erorilor.

Codurile trebuie sa fie usor de înteles si aplicat, astfel încat personulul unitatii economice beneficiare sa asimileze intr-un timp cat mai scurt noul sistem de coduri.

– Concizia codului se refera la necesitatea utilizarii unui numar cat mai mic de caractere pentru reprezentarea elementelor codificate. Aceasta asigura, pe de o parte, reducerea timpului de manipulare a codului si o crestere a conciziei de exprimare a atributelor informationale.

In vederea asigurarii acestor cerinte, codificarea atributelor o constituie atribuirea manuala sau automata, într-o forma sistematizata, a unor coduri pentru fiecare atribut component al bazei informationale.

Functiile codificarii trebuie sa permita caracterizarea directa a fiecarui tip de atribut ce va fi supus operatiei de codificare, identificarea formala a acestora, controlul valorilor posibile ale atributelor în cadrul colectiilor de date, inclusiv functia de manipulare a atributelor codificate.

Functia de caracterizare, asigura exprimarea intr-o forma concisa, unica si stabila în timp, a continutului semantic a fiecarui atribut, prin intermediul codurilor asociate acestuia. În mod concret functia de caracterizare permite utilizarea cu prioritate a codului specific atributului în locul denumirii integrale a acestuia (exemplu: în loc de Facultatea de Contabilitate și Informatică de Gestiune se poate folosi codul descriptiv FCIG).

Functia de identificare, ofera posibilitatea regasirii mai rapide a atributelor prin intermediul codurilor asociate lor, decat prin folosirea completa a semanticii atributului. Aceasta functie creeaza posibilitatea alterioara de selectare a anumitor atribute prin intermediul carora se vor identifica în mod unic anumite valori solicitate prin intermediul conceptului de cheie candidata, primara, externa etc.

Functia de control, presupune existenta unui caracter de control care se ataseaza în ultima pozitie din dreapta structurii codului pe baza caruia, prin intermediul unor metode (aritmetica sau geometrica) si algoritmi specifici, sa se poata verifica integral, corectitudinea simbolurilor care intra în structura codurilor.

Functia de manipulare a atributelor codificate, faciliteaza introducerea eficienta în memorie a acestora, reducerea timpului de preluclare, minimalizarea prelucrarilor atributului, inclusiv usurinta folosirii codului de catre compartimentele functionale implicate în realizarea sistemului informatic.

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

Simbolul este format dintr-un sir de caractere numerice alfabetice sau alfanumerice, ce pot fi interpretate de factorul uman sau de procedurile automate ale sistemului informatic. În aceasta viziune, codul este o colectie ordonata de simboluri, formate la randul lor din siruri de caractere, care asigura identificarea si utilizarea unei entitati sau a unui atribut al bazei informationale.

Codificarea atributelor este necesara deoarece asigura ca avantaje :

– înlocuirea atributelor prin coduri numerice, alfabetice si afanumerice care permite folosirea intensiva a suporturilor externe si a memoriei centrale;

– realizarea unei ierarhizari a atributelor, în functie de criteriile specifice prelucrarii, prin ordonarea acestora în raport de cerintele de selectare a atributelor din baza informationala si de obtinere a gradelor de total si subtotal pentru listele/situatiilor de iesire;

– optimizarea timpului de acces la colectiile de date în care va fi transpusa baza informationala de intrare;

– reducerea erorilor prin folosirea codurilor care înlocuiesc utilizarea explicita a valorii atributelor;

– simplitatea scrierii codurilor în comparatie cu folosirea denumirii explicite a atributelor pentru care regulile de scriere sunt complexe si greu de respectat.

In aceasta viziune, structura logica a codurilor trebuie sa asigure realizarea optima a unei corespondente biunivoce, între multimea valorilor reale ale atributelor si multimea codurilor asociate acestora, asa cum se reda în continuare:

COD atribute, entitati, situatii, documente

b) Tipuri de coduri utilizate într-un sistem informatic. Diversitatea si complexitatea continntului bazei informationale de intrare, precum si multitudinea proceselor de prelucrare a atributelor componente, au condus la aparitia unei game variate de coduri ce se pot grupa dupa mai multe criterii asa cum se reda în figura urmatoare.

Codurile elementare au rolul de a identifica un element din cadrul unei multimi de elemente. Din aceasta grupa fac parte: codurile secventiale, secventiale pe grupe, sau clase, cu semnificatia mnemonica si descriptiva.

– Codurile secventiale se formeaza prin atribuirea unui sir de caractere fiecarui element al multimii, stabilind o corespondenta (în ordine crescatoare) intre elementele acestora si, multimea numerelor naturale.

Fiecarui element supus codificarii i se asociaza un cod crescator, imediat disponibil. De exemplu, daca o persoana care lucreaza la o unitate economica are marca 1412, aceasta este precedata de persoana cu marca 1411 si urmata de persoana cu marca 1413. Acest cod devine un analitic al contului “Decontari cu salariatii”.

Codurile secventiale pot fi atribuite automat prin adaugarea valorii unu la o variabila care constituie codul secvential. Pentru a avea o lungime fixa a codului, este indicat a se stabili dimensiunea maxima a acestuia, ceea ce va asigura si estimarea dimensiunii fizice a codului.

Codurile secventiale se pot realiza în functie de un sistem de numeratie (b) si lungimea simbolului propus (n), ceea ce asigura o lungime maxima a codului (Lmax = bn). In aceasta lungime a codului se va include un numar maxim de elemente dependent de valorile lui b si n.. Spre exemplu, daca se folosesc caracterele sistemului de numeratie in baza 10, iar lungimea simbolului preconizat este de 3 caractere n=3 atunci lungimea maxima a codului este Lmax= bn = 103 =1000, ceea ce conduce la posibilitatea atribuirii unui set maxim de simboluri intre limitele 001 si 999. De mentionat, ca în mod concret nu este indicata utilizarea codului zero.

– Codurile secventiale pe grupe sau clase, se formeaza prin rezervarea unui set maxim de simboluri pentru fiecare tip de atribut omogen, caracterizat prin particularitati comune ce formeaza o grupa specifica supusa codificarii.

Grupele atribuite sunt dependente de specificul economic al atributelor si de cerintele de prelucrare omogena ale acestora, cu mentiunea ca în cadrul fiecarei grupe se vor atribui coduri secventiale pana la valoarea maxima rezervata acesteia. De exemplu în cadrul normelor metodologice privind reflectarea în contabilitate a capitalului social si a altor active si pasive din regiile autonome sau societati comerciale, planul de conturi este structurat in opt clase de conturi, în intervalul carora se folosesc coduri secventiale.

Exemplu : Clasa a 7-a ,”Conturi de venituri” cuprinde:

70 – Vanzari de produse fabricate si de marfuri.

701 – Vanzari de produse intermediare.

702 – Vanzari de produse finite, s.a.m.d.

– Codurile cu semnificatie mnemonica se formeaza fie prin consoanele unui cuvant, fie prin prescurtarea (abrevierea) denumirii atributului codificat (de exemplu OL pentru otel laminat). Acest tip de cod este foarte practic pentru prelucrarile manuale.

Codurile cu semnificatie descriptiva se formeaza prin combinarea initialelor denumirii cu particularitatile tehnico-constructive ale atributului de codificat. Acest tip de cod este utilizat în special la nomenclatoarele industriale, fiind extensibil pentru particularitatile tehnice semnificative. De exemplu, pentru codificarea conturilor analitice de materiale în cazul otelului rotund cu diametrul de 15 mm si lungimea barei de 10 m, codul atribuit este OR 15 10.

Codurile complexe contin atribute ce apartin unor multimi distincte, dar sunt folosite în comun pentru viitoarele prelucrari. in aceasta categorie se includ codurile ierarhizate juxtapuse

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

Structura concreta a acestui cod ierarhizat se determina practic în functie de doi factori:

– numarul de trepte ale codului;

– numarul maxim de aparitii ale fiecarui tip de atribut în cadrul treptelor de ierarhizare. În aceste conditii codul mentionat are urmatoarea structura: Tl, T2, T3

Codurile ierarhizate se folosesc pentru acele atribute între care exista relatii de ierarhizare, cu mentiunea ca acestea se folosesc în comun.

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

Codurile complexe se asociaza atributelor bazei informationale de intrare, în functie de relatiile de ierarhizare si numarul maxim de valori posibile pentru fiecare tip de atribut, cu mentiunea ca în situatia obtinerii unui cod cu lungime egala sau mai mare cu trei caractere, este oportuna atasarea unui alt caracter în ultima pozitie din dreapta, denumita cifra sau litera de control.

Codurile autodetectoare de erori

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

Detectarea automata a erorilor introduse se poate face prin compararea caracterului de control care însoteste codul respectiv cu caracterul de control determinat de calculator la fiecare utilizare operativa a codului.

Pentru realizarea concreta a caracterului de control se pot folosi mai multe metode de calcul dintre care mentionam:

aritmetica;

geometrica.

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

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

8 5 4 3 2 Ci

2 1 2 1 2 Pi

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

Rezultă că C = 30 – 27 = 3

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

Avantajul metodei aritmetice consta în simplitatea si acuratetea acesteia, iar dezavantajul consta în imposibilitatea sesizarii erorilor de compensare.

Metoda geometrica consta în stabilirea caracterului de control (C) prin intermediul unei cifre sau litere obtinuta ca rest al împartirii sumei produselor fiecarei cifre a codului, cu puterile crescatoare ale lui 2, la un numar sau cu numerele naturale în ordine crescatoare, par sau impar ales conventional (x), în urmatoarele faze:

– calculul sumei produselor dintre cifrele codului si ponderii:

– determinarea continutului de control :

()/X

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

8 5 4 3 2

25 24 23 22 21

(8 X 32) + (5 X 16) + (4 X 8) + (3 X 4) + (2 X 2)

256 + 80 + 32 + 12 + 4 = 384

384 : 11 = 34 rest 10

Codul în urma stabilirii cheii de control este 85432l0. Aceasta metoda asigura un grad mai ridicat de siguranta, dar se poate ajunge la o cifra de control formata din doua pozitii ceea ce conduce la o marire a lungimii codului.

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

()/23

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

8 5 4 3 2 Ci

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

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

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

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

Indiferent de modalitatea de determinare a caracterului de control, principiul de verificare al codului ramane acelasi. La fiecare citire a codului calculatorul electronic aplica algoritmul de calcul al caracterului de control si compara rezultatul obtinut cu caracterul de control introdus odata cu codul. Daca caracterul de control calculat este diferit de caracterul de control care însoteste codul, se invalideaza atributul respectiv. Posibilitatea aparitiei erorilor este generata de inversarea sau însumarea eronata a cifrelor codului, scrierea eronata a codului în documentele de intrare sau de introducere gresita de la terminal.

Coduri autocorectoare de erori

Corectarea automata a erorilor permite atat detectarea erorilor cat si rectificarea automata a acestora. in acest scop, codurile sunt aranjate sub forma matriceala, stabilindu-se pentru fiecare linie si coloana cate un caracter de control determinat prin însumarea cifrelor pe linie sau pe coloana si scazand rezultatul din ordinul zecilor imediat superior. Eventualele erori se localizeaza la intersectia liniei si coloanei ale caror caractere sunt diferite de caracterele de control initial stabilite. Abaterea dintre caracterul de control determinat pe liniile matricei in raport de cel determinat pe coloanele acesteia, constituie valoarea absoluta a erorii. In determinarea caracterelor de control pe fiecare linie (j) si coloana (i) din matricea asociata codului, se folosesc urmatoarele relatii:

Clinj = Z-

Ccoli = Z-

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

Clinie = Z – si Ccoloana = Z-

Daca Clinie = Coloana atunci caracterul de control este corect si codul este validat, iar în caz contrar (Cline Ccoloana) se stabileste dimensiunea erorii (E = Clinie _ Ccoloana), iar codul se invalideaza.

Pentru exemplificare se consideră codul 734285411936 care se aranjează sub forma unei matrice de patru linii si trei coloane asupra carora se aplica algoritmii de calcul în doua etape :

– prima etapa :

Grupul de coduri controlate dupa aceasta metoda se scrie în serie, urmat de caracterele de control pe linii, pe coloane si cel general astfel: 734 285 411 936 6542 854 3. Procedura automata de verificare a codurilor, citeste structura codului în aceasta ordine, dupa care calculeaza caracterele de control si localizeaza eroarea la intersectia liniei si coloanei pentru care caracterele de control nu corespund cu cele stabilite anterior. Valoarea care se aplică cifrei greșite pentru a genera o cifră corectă este dată de diferența dintre cifra generală de control (în cazul analizat 3) și caracterul general de control calculat de calculator.

Spre exemplificare, daca în loc de secventa 285 apare 295, atunci procedura va sesiza eroarea prin identificarea liniei , si coloanei eronate folosind acelasi algoritm de calcul;

a doua etapa :

7 3 4 6

2 9 5 4

4 1 1 4

9 3 6 2

8 4 4 4

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

Înainte de a opta pentru un sistem de codificare se cerceteaza daca exista un asemenea sistem si în ce masura poate fi utilizat. Este necesar sa se precizeze modul de atribuire practica a codurilor precum si modalitatea de control. În continuare se stabilesc procedeele de difuzare a nomenclatoarelor de coduri si modalitatile de modificare operativa a acestora, pentru a elimina codurile perimate si a permite actualizarea acestora. Înainte de a se trece la utilizarea unui sistem de coduri este necesara testarea acestora pentru a depista si înlatura eventualele erori, deoarece orice greseala de codificare are consecinte imprevizibile asupra rezultatelor prelucrarii.

Marimea erorii este data de, diferenta dintre caracterul de control stabilita initial ,si caracterul de control general calculat în timpul verificarii (3 – 4 = -1). Corectarea automata a erorilor implica utilizarea unui spatiu mare de memorie deoarece se utilizeaza matricele si tabelele de referinta necesare verificarii codului în cele doua etape. De asemenea, se ocupa mult suport tehnic deoarece alaturi de codurile propriu-zise apar si grupele de cifre de control pe linii si coloane, iar procedurile automate sunt mai complicate.

Atributele bazei informationale de intrare pot fi de tip numeric, alfabetic si alfanumeric, de lungime fixa sau variabila, ceea ce conduce la utilizarea unor coduri adecvate în realizarea sistemelor informatice. Codurile pot fi elaborate manual sau automat prin intermediul unor proceduri de generare a acestora.

Oportunitatea activitatii de codificare se poate decide în functie de:

– marimea si complexitatea continutului bazei informationale de intrare;

– tipurile de atribute existente în baza informationala de intrare si masura în care codificarea acestora conduce la performante în prelucrare si economie de suport tehnic;

– complexitatea structurii sistemului informatic;

– specificul operatiilor de prelucrare a colectiilor de date;

– solutia celui mai eficient sistem de coduri care sa permita codificarea si interpretarea facila a atributelor de catre factorul uman;

– costul stabilirii si validarii sistemelor de coduri, a decodificarii atributelor din baza informationala a elaborarii, actualizarii si întretinerii nomenclatoarelor de coduri;

– eforturi de adaptare a personalului din unitatea beneficiara la cerintele utilizarii sistemelor de coduri.

Din punct de vedere al modului de realizare, codificarea poate fi:

– cu pregatire prealabila;

– fara pregatire prealabila.

Codificarea cu pregatire prealabila solicita o analiza a ansamblului atributelor de codificat care sa preceada codificarea propriu-zisa si sa evalueze exact volumul atributelor, ierarhizate si gama de valori posibile.

Codificarea fara pregatire prealabila se realizeaza prin atribuirea de coduri pe masura aparitiei de noi valori pentru atributele introduse in sistem. Singura analiza necesara în acest caz consta în determinarea volumului maxim de atribute pentru a stabili lungimea si limitele codului.

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

c) Fazele realizarii codificarii

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

– pregatirea activitatilor de codificare;

– codificarea atributelor bazei informationale de intrare;

– întocmirea nomenclatoarelor de coduri;

– întretinerea codurilor.

1. Pregatirea activitatilor de codificare presupune analizarea continutului si structurii bazei informationale de intrare ce urmeaza a fi codificata si examinarea codurilor existente, inclusiv masura în care acestea satisfac cerintele sistemului informatic. De asemenea, se stabileste esalonarea în timp a codificarii, modul de realizare si de control si se opteaza pentru o codificare cu sau fara pregatire prealabila, manuala sau automata.

Stabilirea necesitatilor de codificare este dependenta de volumul atributelor supuse codificarii, tipul de cod utilizat, precum si de modul de realizare a acestuia. Astfel, în cazul unei codificari fara pregatire prealabila, activitatea se reduce la o analiza sumara a volumului atributelor. Daca se opteaza pentru codificarea cu pregatire prealabila este necesara ordonarea atributelor de codificat, analiza particularitatilor continutului bazei informationale de intrare si alegerea codului.

Ordonarea atributelor bazei informationale de intrare ce urmeaza a se codifica, presupune clasificarea atributelor pe nivele ierarhice in scopul definirii grupelor/claselor de codificare, inclusiv reguli de introducere a acestora în baza informationala de intrare. in fiecare grupa/clasa se vor stabili caracteristicile specifice si valorile posibile ale acestora.

Analiza particularitatilor continutului bazei informationale de intrare, urmareste evaluarea dimensiunii actuale a multimii atributelor de codificat, precum si estimarea evolutiei ulterioare. Pentru aceasta este necesar sa se precizeze responsabilitatile de gestionare a bazei informationale de intrare, modul de utilizare concreta a codurilor în documentele de intrare, frecventa de utilizare, precum si modul de acomodare a utilizatorului cu sistemul de coduri propus. Toate aceste particularitati trebuie sa fie în corelatie cu strategiile de memorare si acces ale colectiilor de date asociate bazei informationale de intrare.

Alegerea codului se va face in functie de dimensiunea , si particularitatile bazei informationate de intrare, natura, complexitatea si valorile atributelor, metoda de introducere si validare a codurilor, cerintele si restrictiile sistemului informatic proiectat, metoda de codificare, costul si timpul de realizare a activitatii de codificare

Dimensiunile si particularitatile bazei informationale de intrare determina alegerea tipurilor de coduri care sa reflecte în mod unitar continutul acesteia. Dimensiunea bazei informationale are implicatii asupra lungimii codurilor utilizate, în timp ce particularitatile acesteia influenteaza tipologia codurilor folosite. În situatia în care o baza, informationala de intrare contine atribute caracterizate printr-o subordonare a acestora, este indicat a se folosi codurile ierarhice, iar în situatia în care atributele vor fi prelucrate în functie de mai multe criterii, atunci sunt utilizate codurile juxtapuse.

Natura, complexitatea si valorile reale ale atributelor impun utilizarea unor coduri care pot servi la identificarea unica a acestora, inclusiv o buna conversie a naturii, complexitatii si valorilor reale ale atributelor. În asemenea situatii se recomanda utilizarea codurilor de tip secvential. Daca între atributele bazei informationale de intrare exista relatii de subordonare, atunci se poate opta pentru utilizarea codurilor ierarhizate. in alternativa în care se pot defini diverse proprietati ale atributelor, atunci este oportuna utilizarea codurilor juxtapuse.

In situatia realizarii de sisteme informatice în domeniul bancar sau al serviciilor este indicata utilizarea codurilor cu semnificatia mnemonica sau descriptiva, deoarece este posibila o utilizare facila a acestora.

Cerintele si restrictiile sistemului informatic proiectat reprezinta factorii de baza in alegerea codului, deoarece activitatea de codificare este subordonata functionalitatii noului sistem. Din acest punct de vedere trebuie examinate în primul rand cerintele informationale pe nivele ierarhice, deoarece acestea determina aria de utilizare a codului si gradul sau de generalitate. În cazul în care sistemul este realizat pentru diverse nivele ierarhice (unitate, subunitate etc.), codul trebuie sa asigure relatiile existente în ambele sensuri.

Metoda de codificare are în vedere realizarea codificarii cu sau fara pregatire prealabila, în mod manual sau automat. Codificarea fara pregatire prealabila prezinta avantajul realizarii acesteia cu un cost minim si într-un timp scurt, prin folosirea codurilor secventiale sau secventiale pe grupe, în timp ce codificarea cu pregatire prealabila utilizeaza coduri descriptive care solicita costuri si timp de realizare mai mari.

Costul si timpul de realizare a activitatii de codificare implica alegerea unor tipuri de coduri care necesita cheltuieli minime si un timp redus de realizare a nomenclatoarelor de coduri. in aceste conditii se recomanda utilizarea metodei de codificare automata cu pregatire prealabila, deoarece asigura costuri minime si perioade reduse de codificare.

Pe baza cerintelor prezentate, se alege tipul de cod adecvat si se stabileste structura sa în functie de volumul atributelor, evolutia acestora si numarul total de caractere necesare codificarii fiecarui atribut. Alegerea trebuie sa se faca în corelatie cu celelalte coduri folosite si cu caracteristicile întregii baze informationale pentru a realiza o uniformitate a codurilor. De asemenea, trebuie examinata posibilitatea preluarii unor sisteme de codificare existente, deoarece se realizeaza scurtarea perioadei de implementare si experimentare a sistemului , informatic proiectat.

3. 2. Codificarea atributelor bazei informationale de intrare

Consta în stabilirea codurilor corespunzatoare pentru fiecare atribut din nucleul informational. Pentru aceasta se elaboreaza un nomenclator al valorilor atributelor pe grupe omogene, cu precizarea particularitatilor si valorilor posibile ale acestora. De asemenea, se va întocmi si un nomenclator al tuturor codurilor posibile cu caracterele de control determinate.

Pentru realizarea codificarii atributelor bazei informationale de intrare la nivelul unei unitati economice se vor avea în vedere, în principiu, urmatoarele tipuri de atribute :

codurile sintetice si analitice din structura planului de conturi, cu dezvoltarea pe trepte a acestora, în functie de specificul activitatii si nevoile de informare operativa, prin folosirea unui cod ierarhizat cu urmatoarea structura:

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

codificarea compartimentelor, presupune atribuirea de coduri pentru magazii si gestiuni, precum si coduri pentru sectii, ateliere si formatii de lucru prin utilizarea unor coduri ierarhice cu urmatoarea structura :

codificarea salariatilor se poate realiza printr-un cod secvential de 4-5 cifre a carui lungime concreta este determinata de numarul mediu scriptic al salariatilor din unitate. Se recomanda ca acest cod sa nu contina si elemente privitoare la specialitate, gradatie sau clasa de incadrare, deoarece acestea sunt variabile în timp, în comparatie cu marca care ramane neschimbata pe toata durata de activitate. De asemenea, se recomanda ca marea persoanei sa nu constituie o treapta suplimentara la codurile pentru sectii, ateliere si formatii de lucru, deoarece exista posibilitatea transferarii personalului muncitor de la o structura organizatorica la alta, ceea ce va impune operatii de recodificare

codificarea clientilor si furnizorilor se realizeaza prin intermediul codului ierarhizat, care sa contina trepte referitoare la tipul acestuia (intern sau extern), locul de desfasurare a activitatii (tara sau judetul), felul unitatii economice (regie autonoma, societate comerciala), numarul de ordine.

codificarea unitatilor de masura se va realiza pe baza unui cod secvential sau o semnificatie mnemonica, ales astfel încat sa serveasca cat mai bine cerintelor, de prelucrare automata si de informare a unitatii beneficiare;

codificarea operatiilor tehnologice se realizeaza prin intermediul unui cod secvential, pe grupe cu urmatoarea structura:

3.3. Întocmirea nomenclatoarelor de coduri

Consta în elaborarea unor liste în care sunt precizate codurile si denumirea completa a atributelor la care acestea se refera. Pentru a facilita utilizarea nomenclatoarelor, se recomanda ca acestea sa fie sortate dupa codul sau denumirea atributelor. Un nomenclator de coduri va contine denumirea completa a atributelor, codul asociat, caracterul de control precum si alte informatii reteritoare la pretul unitar, unitate de masura, inclusiv trimiteri la alte clasificari sau instructiuni de completare.

3.4. Întretinerea codurilor

Consta în efectuarea adaugarii sau stergerii de atribute în vederea actualizarii nomenclatoarelor de coduri, motiv pentru care este recomandabil ca această activitate sa fie efectuata de aceeasi echipa care a conceput si realizat codificarea.

Nomenclatoarele de coduri se recomanda sa fie revizuite periodic pentru a elimina ambiguitatile si redondantele prin stergerea valorii atributelor care nu mai prezinta interes. De asemenea, nomenclatoarele de coduri vor fi actualizate atunci cand criteriile de utilizare a atributiilor se schimba, aria de cuprindere a sistemului proiectat se extinde, cand apar modificari în cadrul legislativ-normativ, etc.

4. Adaptarea documetelor primare la cerintele sistemului informatic

(se identifică în MGD și se aprofundează în MCDD)

Adaptarea documentelor primare la cerintele sistemului informatic este o faza importanta în cadrul proiectarii, deoarece în documente se consemneaza starea si dinamica fenomenelor si proceselor economice desfasurate în unitatea economica si reflectate prin intermediul sistemului informatic. Datele consemnate în documentele de intrare sunt introduse în sistemul informatic prin intermediul tranzactiilor externe efectuate asupra colectiilor de date organizate baze de date.

Obiectivul principal al acestei faze îl constituie formalizarea documentelor din punct de vedere al continutului si al formei, în asa fel încat acestea sa raspunda exigentelor specifice sistemului informatic in concordanta cu cerintele concrete ale beneficiarului.

Adaptarea documentelor primare la cerintele unui sistem informatic presupune:

– scopul adaptarii documentelor de intrare;

– tipuri de documente primare utilizate;

– modificarile de continut si format ale documentelor primare.

Scopul adaptarii documentelor primare:

– consemnarea fenomenelor si proceselor economice desfasurate in unitatea economica, în momentul si la locul producerii acestora (compartimentele functionale);

– utilizarea codurilor proiectate pentru sistemul informatic in structura informationala a documentelor primare, în vederea transpunerii exacte si corecte a acestora în colectiile de date ce vor surprinde dinamica valorii atributelor;

– caracterizarea dinamica a operatiilor economice desfasurate în unitatea beneficiara pentru crearea initiala si actualizarea periodica a colectiilor de date;

– reflectarea în componentele sistemului informatic (subsisteme, aplicatii etc.), a naturii activitatii compartimentelor functionale prin intermediul datelor consemnate în documentele de intrare.

– simplificarea si perfectionarea sistemului de evidenta prin utilizarea unui numar minim de documente de intrare, în care sa se surprinda într-o forma sintetizata starea si dinarnica utilizarii patrimoniului, în paralel cu gestiunea unor colectii de date, capabil sa reflecte dinamic aceste fenomene

Tipuri de documente de intrare.

Documentele de intrare în care se consemneaza starea si dinamica fenomenelor si proceselor economice pot fi structurate în functie de:

sfera;

frecventa de utilizare;

regimul de gestionare;

tipurile tranzactiiior externe;

formatul de prezentare, etc.

a) Sfera de utlizare a documentelor primare permite gruparea acestora în doua categorii:

– documentele primare comune, folosite pentru înregistrarea datelor privind procesele tehnico-economice din activitati desfasurate in toate tipurile de unitati economice, indiferent de domeniul de activitate (ex.: Nota de Contabilitate);

– documente de intrare specifice, folosite pentru înregistrarea datelor ce caracterizeaza anzumite procese tehnico-economice desfasurate în cadrul unor ramuri sau subramuri (exemplu: Extrasul de cont).

b) Frecventa de utilizare si ponderea informatiior fixe continute în documentele de intrare permit gruparea acestora în doua categorii:

– tiparite, caracterizate printr-o utilizare generala la nivelul tuturor unitatilor economice, ceea ce justifica din punct de vedere economic multiplicarea lor (ex.: factura fiscala).

– netiparite caracterizate printr-o utilizare speciala numai la nivelul unor anumite unitati economice.

c) Regimul de gestionare al documentelor impune gruparea acestora în doua categorii:

– cu regim uzual sunt caracterizate, printr-o folosire si o evidenta similara cu cele tiparite în vederea utilizarii generale, fara restrictii exprese din punct de vedere legal.

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

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

d) Tipul tranzactiilor externe asigura gruparea documentelor în doua categorii:

– documente care redau starea initiala a fenomenelor si proceselor economice, prin care se asigura cuantificarea elementelor patrimoniale ale unitatii economice în momentul lansarii în executie a sistemului informatic;

– documente care reflecta dinamica fenomenelor, si proceselor economice ce modifica elementele patrimoniale într-o anumita perioada de gestiune.

Documentele primare din prima categorie permit constituirea initiala a colectiilor de date în momentul lansarii în functiune a noului sistem informatic. Aceste documente surprind starea initiala a fenomenelor si proceselor economice prin intermediul valorii reale ale atributelor cu caracter conventional constant, inregistrate prin intermediul nomenclatoarelor (produse, materiale, clienti, furnizori, conturi, mijloace fixe, obiecte de inventar), cat si starea initiala a fenomenelor si proceselor economice supuse prelucrarii automate (exemplu: “Lista de inventar”).

e) Formatul de prezentare a documentelor permite gruparea acestora in trei categorii:

– documentele individuale asigura redarea denumirii si valorii atributelor prin amplasarea acestora pe întreaga suprafata in functie de suecesiunea logica a operatiei economice rezultate (ex.: chitanta, fisa personala a salariatului fisa mijlocului fix etc.);

– documentele comune reflecta denumirile si valorile atributelor prin ordonarea acestora sub forma de tabel în cadrul caruia succesiunea atributelor este determinata de relatiile de apartenenta si incluziune dintre multimile specifice ale atributelor (ex.: Nomenclatoare de produse, clienti, materiale, obiecte de inventar etc.);

– documente mixte, permit ordonarea numelui si valorii atributelor atat în format individual cat si în format comun, pentru a furniza intr-o forma eficienta, dispunerea atributelor în structura documentului de intrare (ex.: Bon de consum. Aviz de expeditie/Dispozitie de livrare, Factura fiscala etc.).

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

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

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

Modificarile de continut vizeaza:

– adaugarea în documente a rubricilor pentru coduiri în masura in care acestea nu sunt deja prevazute. in acest sens se va insista codurilor ce specifica natura operatiilor reflectate si a celor care servesc pentru identificarea si asocierea calectiilor de date (cod material, cod produs, marca, cod sectie, cod comanda etc.);

– eliminarea atributelor ce se obtin prin calcule (ex. valoarea);

– regruparea si modificarea rubricilor aferente atributelor ce vor contine date care sa se introduca în sistemul informatic în asa fel încat acesta sa se gaseasca in acelasi loc in toate documentele. Cu alte cuvinte, se pastreaza individualitatea fiecarui tip de document, dar se defineste o zona comuna identica pentru toate documentele din care se vor prelua datele pe suporturile tehnice.

Modificările de format sunt impuse de necesitatea cresterii facilitatilor de preluare directa a datelor prin intermediul videoterminalelor si vizeaza urmatoarele aspecte

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

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

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

– ordinea atributelor în cadrul documentelor trebuie sa asigure prezenta. atributelor de identificare, urmate de cele informative si terminand cu cele cantitativ-valorice;

– evidentierea zonelor care contin atribute ce se preiau în colectiile de date, prin demarcarea cu linii mai groase sau de culori diferite etc.

Ex.: din documentul primar “Bon de consum” nu se vor prelua atributele constante “pretul unitar” si “unitatea de masura”, inclusiv atributul rezultat din calcul “valoarea aferenta iesirilor” desi ele sunt consemnate în document pentru efectuarea controlului gestionar;

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

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

Anexa 3.

Schema de flux informațional pentru domeniul FINANCIAR-CONTABIL

MINISTERUL CONDUCEREA UNITÃ- PRODUCTIE

FINANȚELOR ȚII ECONOMICE

SERVICIUL COMERCIAL

FINANCIAR-

BĂNCILE CONTABIL

CERCETARE

DEZVOLTARE

PERSONAL

ADMINIS-

TRATIV

Inapoi

Anexa 4

Inapoi

Anexa 5

Modelele conceptuale de date și prelucrări, modelele logice de date pentru aplicațiile sistemului informatic financiar-contabil

Sistemul cuprinde următoarele aplicații:

Gestiunea stocurilor de materiale

Gestiunea stocurilor de mărfuri

Gestiunea stocurilor de produse finite

Aprovizionarea cu materii prime și materiale de la furnizori

Aprovizionarea cu mărfuri de la furnizori

Contractarea, livrarea produselor și încasarea sumelor facturate

Gestiunea mijloacelor fixe

Salarizare

Contabilitatea financiară

În continuare sunt prezentate modelele conceptuale de date și prelucrări, modelele logice de date pentru aceste aplicații

GESTIUNEA STOCURILOR DE MATERIALE M.C.D.

GESTIUNEA STOCURILOR DE MATERIALE MLD-relational

GESTIUNEA STOCURILOR DE MATERIALE MOO

GESTIUNEA STOCURILOR DE MĂRFURI MCD

GESTIUNEA STOCURILOR DE MARFURI MLD

GESTIUNEA STOCURILOR DE MARFURI MOO

GESTIUNEA STOCURILOR DE PRODUSE FINITE MCD

GESTIUNEA STOCURILOR DE PRODUSE FINITE MLD-relational

GESTIUNEA STOCURILOR DE PRODUSE FINITE MOO

APROVIZIONAREA CU MATERII PRIME SI MATERIALE DE LA FURNIZORI MCD

APROVIZIONAREA CU MATERII PRIME SI MATERIALE DE LA FURNIZORI MLD

APROVIZIONAREA CU MARFURI DE LA FURNIZORI

SI PLATA OBLIGATIILOR MCD

APROVIZIONAREA CU MARFURI DE LA FURNIZORI

SI PLATA OBLIGATIILOR MLD

APROVIZIONAREA CU MARFURI DE LA FURNIZORI

SI PLATA OBLIGATIILOR MOO

CONTRACTAREA, LIVRAREA SI INCASAREA PRODUSELOR M.C.D.

CONTRACTAREA, LIVRAREA SI INCASAREA PRODUSELOR MLD-relational

CONTRACTAREA, LIVRAREA SI INCASAREA PRODUSELOR MOO

GESTIUNEA MIJLOACELOR FIXE M.C.D.

GESTIUNEA MIJLOACELOR FIXE MLD

GESTIUNEA MIJLOACELOR FIXE MOO

  CONTABILITATEA FINANCIARA (modelul Entitate-Asociere) M.C.D.

CONTABILITATEA FINANCIARA M.L.D.-relational

CONTABILITATEA FINANCIARA M.O.O.

SALARIZARE MCD

SALARIZARE MLD

SALARIZARE MOO

Bibliografie

Dumitru Oprea, "Analiza și proiectarea sistemelor informaționale economice", Editura Polirom, București, 1999.

Nicolae Dumitru Davidescu, "Sisteme informatice financiar – bancare", Editura All Beck, București, 1998.

Ion Lungu, Gheorghe Sabău, ș. a., "Sisteme informatice: analiză, proiectare și implementare ", Editura Economică, București, 2003.

Gh. Popescu și Elena Popescu, “Proiectarea și programarea sistemelor informatice” ,Editura “Ovidius” University Press, Constanța, 2003.

Gh. Popescu “Laborator și ghid interactiv pentru peoiectarea și programarea sistemelor informatice de gestiune”, ,Editura “Ovidius” University Press, Constanța, 2004.