1

Cursul_III_1 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ă.

SISTEMUL CONDUS

SISTEMUL DE MANAGEMENT

Resurse - materiale - umane - energetice

Produse finite Servicii prestate

Informaţii din afara sistemului

X Y

Informaţii în afara sistemului

Sistemul informaţional Informaţii Decizii

2

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.

3

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ă.

4

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, 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

5

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ă.

DOCUMENTE DE INTRARE IN SISTEMUL INFORMATIC

BAZA INFORMAÞIONALÃ NUCLEU DE INFORMAÞII PRELUCRÃRI SGBD sau SGF COLECÞII DE DATE ORGANIZATE IN FIª IERE SAU IEª IRI INTRÃRI BAZE DE DATE TRANZACÞII EXTERNE

LISTE SITUAÞII TRANZACÞII INTERNE DE IEª IRE

OBÞINUTE DE SISTEMUL

PROCEDURI INFORMATIC CREARE EXPLOATARE

ACTUALIZARE LISTARE

MODIFICÃRI LISTE DE ERORI REGLAREA FENOMENELOR ª I PROCESELOR ECONOMICE DIN UNITATEA BENEFICIARÃ.

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.

6

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).

7

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.

8

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ă. Metoda SSADM (1982) Metoda MERISE Metoda ICI din Romania - studiul de fezabilitate; - analiza cerinţelor; - specificarea cerinţelor; - specificarea logică; - proiectare fizică (inclusiv programarea);

- studiul de evaluare; - modelarea globală; - modelarea conceptuală; - modelarea organizaţională; - logică; - fizică; - implementarea (inclusiv programarea).

- elaborarea temei de realizare; - proiectarea de ansamblu; - proiectarea de detaliu; - elaborarea programelor; - implementarea sistemului.

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;

9

- 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):

10

FAZE Procese de lucru

Iniţiere Elaborare Construcţie Tranziţie

Modelare afacere

Cerinţe Analiză şi proiectare

Implementare Testare Dezvoltare Procese suport

Managementul schimbării

Managementul proiectului

Mediul Iniţial Elab#1 Elab#2 Con1 Con3 Con3 Tran#1 Tran#2 Iteraţii 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 .

1

CURSUL_III_2 STUDIU APROFUNDAT AL METODOLOGIILOR DE ELABORARE A SISTEMELOR INFORMATICE

1. 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

2

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.

3

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.

4

Î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; Viziuni Nivele Etape

Descrieri şi definiţii auxiliare

Comunicaţie

Date

Prelucrări

Nivel global

Studiu de evaluare

DDG - obiectivele sistemului informaţional (SI) - funcţiile specifice - atributele conducerii

MGC - aspecte şi principii generale ale comunicaţiei asociate special pentru SIO, SII şi SIG

MGD -soluţii previzibile - date - cunoştinţe - organizarea posibilă - BD, BT, BC - combinaţii

MGP - tip - topologie - amplasare pentru: - prelucrări locale; - teletransmisie - reţele de calculatoare

Nivel con-cep- tual

Proiectare concep- tuală

DDC - domeniile activităţii - documente de intrare - situaţii de ieşire - indici sintetici - grafice - algoritmi -sisteme de comunicare

MCC -servicii funcţionale (actori) -fluxuri informaţionale documente, situaţii folosite

MCD - entitate/tip entitate - relaţie/tip relaţie -proprietate/tip proprietate - cardinalitate (maximă, minimă)

MCP - proces - operaţie - eveniment - sincronizare - reguli de gestiune

Nivel organi-zaţio-nal

Proiectare organiza- ţională

DDO - corelaţia date – prelucrări – comunicări - grila de coerenţă globală: MCD–MOD MCD –MOP -reguli de prelucrare -algoritm de validare

MOC -comunicaţii manuale/auto-mate/mixte comunicaţii între: - compartimente - compartimente- conducere - unitate- alte unit.

MOD - tipul proprietăţilor - număr de înregis-trări pentru entităţi şi relaţii - cardinalitate (maximă, maximă la 95%, modală, medie) - tip de acces (creare, adăugare, modificare, ştergere)

MOP - repartiţia organizatorică a proceselor de prelucr. pe: compartimente posturi de lucru sarcini/faze grad de auto- matizare (manual, automat, mixt) - mod de funcţionare

Nivel logic

Proiectare logică

DDL - dicţionarul datelor - descrierea BD/BD/BC - ordinea de prelucrare a Bd/BT

MLC -lista serviciilor implicate - corelaţia servicii - docu-mente - situaţii - organizarea generală a co-municaţiei de date şi prelucrări

MLD MLP - listă de reguli - listă module - listă comparti- mente; - listă sarcini; - listă evenimente; - listă tabele

model relaţional

spread sheet

- entitate - dependenţă funcţională - cheie primară externă

- tabelă - celulă - zonă de celulă - depen- denţă funcţională - cheie primară secundară

5

Nivel fizic

Proiectare fizică Implemen-tare

DDF - SO, SGBD, SGBT, GSE - meniuri de prelucrare - videoformate de I/E -tranzacţii de: I, E, I/E

MFC - listă echipamente - rolul şi funcţiile FS şi WS - protocoale de comunicaţie - parole de acces -drepturi de prelucr.

MFD MFP - procedură - subprocedură - model - aspect: - funcţional - semantic - timp real/diferit

BD BT - tabelă - atribut - tuplu - cardinalitate - dimens. - cheie indexar

- tabelă - celulă - tuplu - cardinalitate - dimensiune

Exploa-tare

Exploatare crt. Întreţinere Dezvoltare de noi versiuni

DDE definiţii asociate RC şi RD - elemente adiţionale pentru RC

RC/RD - topologie RC - topologie RD

BD BT BD BT

- volume alocate (C:, ………..Z:) - cataloage folosite - identificatori (*.dbf, *.xls)

- volume alocate (C:, …….Z:) - cataloage folosite - identificatori (*.prg, *.exe, *.xlm

- 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. In cursul precedent au fost enumerate căteva instrumente CASE asociate principalelor metodologii de elaborare a sistemelor informatice. Este bine ca atunci când ne hotărâm să aprofundăm o metodologie de elaborare a sistemelor informatice, să ne informăm dacă dispune de instrumente CASE şi dacă acestea sunt accesibile. Bineînţeles că orice metodologie poate fi aplicată şi fără a dispune de instrumentele CASE asociate acelei metodologii, dar dacă se poate să folosim şi instrumentele CASE ritmul de muncă va fi mult mai mare. 2. Modele reprezentative ale ciclurilor de viaţă ale dezvoltării de sisteme Modelul cascadă. Asigură trecerea de la o etapă la alta, în ordine secvenţială. Definirea cerinţelor Analiza Proiectarea Implementarea Testarea Utilizarea şi întreţinerea

6

Fazele sunt structurate pe activităţi şi subactivităţi. Punctul său slab este că se aplică la nivel sistem şi nu se poate trece la etapa următoare până ce nu au fost aduse la zi toate aplicaţiile; în practică se solicită decalaje între aplicaţii. Modelul V. Latura din stânga este cea de la modelul cascadă, iar pe cea din dreapta se realizează verificările şi validările. Ea se parcurge ascendent. Definirea cerinţelor Proiectare Testare sistem sistem Proiectare Testare subsistem subsistem (componentă) (componentă) Codificare asamblare componente Modelul incremental. Permite livrarea sistemului pe componente, dar şi global. Definirea cerinţelor şi analiza se execută totuşi la nivelul întregului sistem. Este o metodă de tip top-down, ceea ce implică cunoaşterea şi formularea cerinţelor pentru întregul sistem încă din faza encipientă de abordare a sistemului, chiar dacă ulterior se vor rezolva doar părţi din el. De regulă adăugarea unei părţi presupune testarea a tot ce este realizat până în acel moment, ceea ce poate duce la modificări multiple ale componentelor realizate printre primele. Definirea Proiectare Instalare cerinţelor componenta-1 componenta-1 Analiză Implementare Întreţinere componenta-1 componenta-1 Arhitectura --- --- sistemului Proiectare Instalare componenta-n componenta-n

Implementare Întreţinere componenta-n componenta-n

Modelul spirală. Este modelul cel mai des folosit în toate domeniile proiectării, acolo unde este vorba de obiective complexe.

Valida

7

Prototip-1 Prototip-2 Prototip-3 Prototip-4 Modelul evolutiv. Necesită efectuarea unei investigaţii iniţiale pe baza căreia să se poată elabora o strategie de descompunere a proiectului în părţi/segmente, fiecare cu o valoare deosebită pentru client. Acestea sunt sunt realizate şi livrate în mod iterativ şi contribuie la sporirea treptată a performanţelor sistemului. Se are în vedere posibilitatea aplicării unor adaptări sau modificări ulterioare. • Studiul iniţial • Integrare • Descompunere segmente în segmente Segment-1 Segment-2 • Definire cerinţe • Implementare •Definire cerinţe • Implementare • Analiză • Testare •Analiză • Testare • Proiectare • Utilizare •Proiectare • Utilizare Metoda are succes deoarece se bazează pe o arhitectură deschisă, flexibilă, elaborată prin participarea tuturor părţilor interesate, inclusiv a utilizatorilor şi a unor specialişti profesionişti. Modelul X. În partea de sus a X-ului este aplicat modelul cascadă şi V, iar în partea de jos sunt avute în vedere acţiuni de valorificare a softului creat anterior. Această preocupare este din ce în ce mai extinsă pe plan mondial şi pare foarte raţională deoarece softul prezintă o mare supleţe în ce priveşte adaptarea de la o problemă la alta. De fapt nu contează decât asemănarea structurilor, semnificaţia variabilelor fiind la libera alegere a celui care foloseşte softul. În partea de sus, modelul ia în consideraţie utilizarea unor specificaţii de sistem, a proiectului arhitectural şi de detaliu , codificarea, testarea pe componente, integrarea şi testarea sistemului. Parte inferioară a X-ului este un V întors, pentru a sugera noţiunea de gestiune

Modelul realizează validarea cât mai devreme posibil, de cât mai multe ori, prin construirea prototipurilor, ca în figura din stânga. Ţine seamă de natura iterativă a dezvoltării şi ia în consideraţie nevoia de planificare şi evaluare a riscurilor fiecărei iteraţii. Necesită profesionalism, flexibilitate în acţiune, în alocarea de fonduri şi în definirea activităţilor de intreprins.

8

patrimonială a depozitelor reutilizabile la nivel componentă, structură, domeniu şi chiar aplicaţie. Având în vedere că partea inferioară a modelului se aplică practic doar în fazele de proiectare fizică, modelul - ca şi modelul tridimensional al autorilor metodei Merise, nu este prea popular. Dealtfel metoda Merise mai prezintă un model în două dimensiuni în care pe abscisă este trecut sistemul actual şi cel viitor, iar pe ordonată sunt trecute nivelele global, conceptual, organi-zaţional, logic, fizic şi de exploatare, dar după cum s-a putut vedea, din cele prezentate în secţiu-nea 1 a acestui capitol, metoda Merise este aplicată de fapt pe un model în două dimensiuni, sub formă de matrice care este foarte riguros şi se pretează la exigenţele ingineriei softului. 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.

9

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. 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;

10

- descompunerea; - performanţe de deplasare, pe orizontală, de la un instrument la altul; - grade diferite de automatizare; - integrare. C A S E V E R T I C A L

U P P E R C A S E

- analiza cerinţelor sistemului/programului; - descrierea sistemului; - proiectarea şi modelarea funcţională şi procedurală; - modelarea datelor şi proiectarea bazei de date; - generarea de coduri.

F R O N T E N D

C A S E P R O P R I U - Z I S

L O W E R C A S E

- editoare, de regulă folosite de limbaje de programare; - instrumente de folosire a codurilor şi modulelor; - instrumente de referinţă încrucişată; - mijloace de testare; - instrumente de analiză a rezultatelor; - depanare coduri.

B A C K E N D

O C R I A Z O S N T E A L

- instrumente pentru managementul proiectelor; - mijloace de documentare; - mijloace de gestionare a configuraţiei; - instrumente de revizuire a cerinţelor.

Clasificarea instrumentelor CASE

11

4. 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.

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

5.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.) 5.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. 5.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. 5.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.

12

Date

Decizii nestructurate (neprogramate) Decizii semistructurate (semiprogramate) Decizii structurate (programate) Informaţii diverse

SISTEM DE CONDUCERE (decizional) Nivel strategic Nivel tactic Nivel operativ Marketing Personal Producţie Financiar Contabilitate

I N T R A R I

I E S I R I

SISTEME EXTERNE Mediul exterior

I N T R A R I

I E S I R I

SISTEM CONDUS

I E S I R I

Birotica+Sisteme ale grupurilor de lucruSis

teme d

e spri

jinire

a expe

rtilor

SISTEM INFORMATIONAL Sisteme de (inclusiv informatic) sprijinire a conducerii strategice

Sisteme de sprijinire a procesului decizional Sisteme de informare a conducerii operative Sisteme de prelucrare a tranzacţiilor Marketing Personal Producţie Financiar Contabilitate INTRĂRI

Rolul sistemelor informaţionale în conducerea organizaţiilor economice

I E S I R I

I N T R A R I

13

6. Concluzii 6.1 Indiferent de metodologia pe care o folosim, documentaţia de proiectare trebuie să prezinte: - obiectivele firmei, funcţiile specifice, atributele conducerii şi modul în care sunt derulate activităţile ei; organigrama structurii organizatorice; - 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; - datele (tipologia, descrierea lor, volumul, mărimea, periodicitatea, amplasarea pentru prelucrări locale, teletransmisie, reţele, etc.) vehiculate în unitate pentru fiecare loc de muncă; - când, cum, de către cine şi ce date circulă, se transformă sau se înregistrează; - ordinea de prelucrare şi dependenţa dintre datele trecute prin diverse activităţi desfăşurate; - regulile prin care se specifică modul în care sunt transmise şi prelucrate datele; - 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; Aceste informaţii vor fi prezentate iniţial pentru sistemul existent şi apoi pentru cel nou care va fi prezentat odată prin modelul său logic şi apoi prin modelul fizic. Forma de prezentare a acestor aspecte depinde de etapele prevăzute în metodologia aleasă şi de formalismele asociate fiecărei etape, dar la fiecare etapă va trebui să analizăm sau să specificăm detalii despre date, prelucrări şi comunicaţii (în sensul suportului de informaţii dintre entităţile sau actorii implicaţi în fiecare aplicaţie). 6.2 Conţinutul modelului logic şi fizic face obiectul cursurilor viitoare, dar să reţinem că modelul sistemului informatic evoluează de la o etapă la alta pornind de la ceea ce vede beneficiarul cu ochii celui care nu cunoaşte informatică, trece printr-un model abstract, independent de specificul hardului care va fi folosit pentru exploatarea sistemului – modelul logic şi se opreşte la modelul fizic unde, structura datelor, aspectul interfeţei cu utilizatorii şi programele care vor pune sistemul în mişcare depind de platforma program, de mediul de pro-gramare ales, de suporţii de informaţii, de arhitectura reţelei, care va deservi sistemul informatic. 6.3 In cele mai multe metodologii elaborarea programelor nu apare ca o fază explicită ci este inclusă în implementare, iar implementarea continuă apoi cu instruirea utilizatorilor pe baza manualului de utilizare, instalarea softului, iniţializarea bazei de date cu nomenclatoare şi alte date fixe sau semivariabile.

14

1

Cursul_III_3 DECIZII ASISTATE

I. Sisteme suport de decizie Utilizarea tot mai frecventă a sistemelor suport de decizie este favorizată de apariţia de noi tehnologii în domeniul informatic şi este impusă de volumul din ce în ce mai mare şi de diversitatea datelor ce trebuie prelucrate pentru a lua o decizie eficientă. Ele servesc la îmbunătăţirea eficacităţii procesului decizional (măsura în care decizia îşi atinge obiectivele) prin faptul că oferă managerilor o informaţie de calitate şi moduri noi de interpretare a informaţiilor. Un sistem suport de decizie (SSD) este un sistem informatic interactiv, flexibil şi adaptabil proiectat special pentru a oferi suport în soluţionarea unor probleme manageriale nestructurate sau semistructurate, cu scopul de a îmbunătăţi procesul decizional. Sistemul utilizează date interne şi externe şi modele, oferă o interfaţă simplă şi uşor de utilizat, permite decidentului să controleze procesul decizional şi oferă suport pentru toate etapele procesului decizional, care sunt următoarele:

- etapa de identificare şi formulare a problemei; - etapa de proiectare (identificare a alternativelor şi evaluarea lor) ; - etapa de alegere a soluţiei; - etapa de implementare a deciziei; - etapa de evaluare.

SSD-urile mai avansate pot oferi suport pentru decizii multiple independemte sau interdependente, pentru un singur utilizator sau pentru un grup de utilizatori. Etapele enumerate mai sus se derulează prin aplicarea diferitelor proceduri. Dacă toate etapele unei probleme sunt structurate (procedurile prin care se desfăşoară sunt standardizate, obiectivele fiecărei proceduri sunt clare, iar intrările şi ieşirile din procedură sunt clar definite), avem de a face cu o problemă structurată. Într-o decizie structurată toate sau cele mai multe dintre variabile sunt cunoscute şi pot fi complet programate. Deciziile semistructurate pot fi programate doar parţial şi în plus necesită creativitate şi intuiţie umană. În situaţiile decizionale nestructurate, obiectivele sunt greu de cuantificat iar modelul situaţiei este aproape imposibil de proiectat. SSD-urile oferă suport în soluţionarea părţilor structurabile ale deciziei. În ce priveşte părţile nestructurate ale problemei, acestea urmează să fie rezolvate fără automatizare, direct de decident, utilizând creativitatea sa. Cu toate acestea există o serie de factori care fac ca utilizarea SSD să devină din ce în ce mai stringentă. Aceştia sunt legaţi de faptul că în prezent pentru luarea deciziilor trebuie prelucrată o mare cantitate de informaţii care, de cele mai multe ori se prezintă pe formate diferite, provin de pe platforme hardware diferite şi din structuri de date diferite, ceea ce induce nevoia a numeroase aplicaţii folosite pentru extragerea, pregătirea şi agregarea datelor necesare activităţii de analiză şi raportare. Mai mult decât atât, cerinţele utilizatorilor se modifică într-o dinamică crescândă, ceea ce determină modificarea programelor de extragere a datelor sau chiar crearea de noi programe. La toate acestea se mai adaugă un alt aspect şi anume acela că pentru luarea deciziilor nu sunt relevante tranzacţiile ce fac obiectul de activitate al unei firme sau organizaţie, ci datele despre tranzacţii, adică date agregate. Pentru a se evita efectuarea tuturor prelucrărilor enumerate mai sus de fiecare dată când se pune problema elaborării unei decizii, aceste prelucrări se fac o singură dată, atunci când apar date noi, iar datele agregate în formă utilizabilă pentru prelucrările necesare elaborării de

2

decizii se depun în depozite de date. Cu alte cuvinte, datele preluate din surse eterogene sunt curăţate de părţile inutile actului decizional, filtrate şi transformate şi apoi stocate într-o structură ce este uşor de accesat şi folosit de către utilizatorii finali pentru interogare, raportare şi analiză. Avantajele SSD nu se limitează numai la utilizarea depozitului de date. SSD trebuie să acceseze şi să analizeze rapid şi eficient sursele de date interne şi externe ale organizaţiei, să genereze alternative (mai ales pentru problemele structurate) şi decizii despre criteriul de selecţie a alternativei ce va fi propusă şi să poată face previziuni despre consecinţele aplicării acelei alternative (să facă analize de tip what-if şi goal seeking, adică ce s-ar întâmpla dacă… şi respectiv ce obiective aş putea atinge dacă…). SSD-urilor nu li se poate pretinde să prezinte varianta optimă, dar folosind optimizarea sau alte modele matematice se pot identifica soluţiile potenţiale şi se pot aranja alternativele în concordanţă cu criteriile stabilite. În fine SSD-urile pot fi folosite şi în etapa de implementare a deciziei, în activităţi de comunicare a deciziei, explicare şi justificare şi chiar la evaluarea şi controlul soluţiei implementate prin monitorizare şi raportare de excepţii. SSD-urile sunt proiectate în general pentru anumite situaţii decizionale şi nu se pot generaliza. Ele îi ajută pe decidenţi, extind capacitatea lor de a lua decizii, dar nu îi înlocuiesc. Problemele rezolvate au la bază modele care fac parte integrantă din sistem. Un SSD poate fi definit ca un sistem informatic format din trei componente ce se interacţio-nează: componenta de gestiune a datelor, componenta de gestiune a modelelor şi componenta pentru asigurarea comunicaţiei. La acestea se adaugă interfaţa cu utilizatorul. a) Componenta de gestiune a datelor. În procesul decizional din afaceri, bazat mai ales pe cunoştinţe, datele sunt procesate în informaţii care sunt evaluate în raport de cunoştinţele existente sau stimulează crearea de noi cunoştinţe. Putem spune că avem de aface cu o relaţie Date-Cunoştinţe-Informaţii. Unele sisteme de luare a deciziilor se pot baza pe relaţia Cunoştinţe-Informaţii-Date. Aceasta presupune că există cunoştinţele necesare pentru a căuta informaţiile şi apoi datele. Alte sisteme de luare a deciziilor se pot baza pe relaţia Informaţii-Date-Cunoştinţe. În ultima fază a procesului decizional, informaţia este prelucrată şi se stabileşte decizia care poate lua forma de date iar manifestarea ei conduce la noi cunoştinţe ce se vor adăuga la cele existente. În cele trei tipuri de relaţii de mai sus,

- datele pot fi sub formă de: date empirice, neprocesate (brute), date valabile din experienţele anterioare, date rezultate din procesul decizional curent;

- informaţiile pot fi: interne, valabile la începutul procesului decizional, obţinute din procesarea datelor sau din alte informaţii, externe, din afara organizaţiei;

- cunoştinţele pot fi: acumulate şi valabile la începutul procesului decizional, obţinute prin transformarea datelor brute în informaţii sau prin extragerea datelor finale din informaţii, achiziţionate în timpul procesului decizional.

Datele din baza de date a SSD pot proveni din surse interne, externe şi private. Datele interne se referă la resursele organizaţiei (umane, tehnice, financiare), la procesele, evenimentele şi activităţile desfăşurate în acea organizaţie. Ele provin din sistemele tranzacţionale ale organizaţiei, în funcţie de nevoile SSD ca de exemplu: contabilitate, financiar, marketing, producţie, personal, etc. Datele provenite din surse externe se referă la mediul înconjurător (economic, natural, social), în care organizaţia îşi desfăşoară activitatea şi pot proveni din mijloace de informare în masă, opiniiale clienţilor şi partenerilor, firme de cercetare a pieţii şi previziune, Internet, etc.

3

Datele provenite din surse private (aparţinând unor angajaţi ai firmei), reguli interne folosite de decidenţi pentru evaluarea datelor sau activităţilor. Datele se caracterizează prin: structură, orizont de timp, agregare, volatilitate, dimensiune şi metadate.

- în ce priveşte structura datelor, ele pot fi stocate în baze de date relaţionale (eventual în relaţii normalizate), dar cel mai adesea în depozite de date (repozitory), sub formă de agregări ale datelor operaţionale, care au format şi structură diferită de cea a datelor din sistemele operaţionale;

- orizontul de timp se reflectă în faptul că datele din baza de date SSD sunt “fotografii” ale datelor operaţionale la anumite momente de timp, deci sunt serii de timp ale datelor operaţionale;

- agregatele facilitează efectuarea analizelor complexe; - datele operaţionale fiind date curente se volatilizează; datele din baza de date a SSD nu

sunt volatile, adică nu se mai modifică, dar lor li se adaugă alte “fotografii”. - datele operaţionale au o singură dimensiune, în timp ce datele din baza de date a SSD pot

fi corelate în diferite moduri (de ex. “ Câte produse s-au primit în trimestrul I al anului curent, de la furnizorul X?”) ;

- metadatele sunt date referitoare la date: dicţionar de date, descrieri ale tipurilor de date din baza de date, tipul surselor de date, formate de date, lungimi ale câmpurilor. Datele operaţionale pot dispune şi ele de un dicţionar al datelor dar mult mai subţire, adică conţine mai puţine elemente. Deoarece datele din baza de date a SSD provin din surse diferite şi fiecare sursă poate avea metadatele sale specifice, mai poate fi folosit şi un catalog al metadatelor.

b) Componenta de gestiune a modelelor execută încărcarea, stocare şi organizarea diferitelor modele cantitative ce oferă facilităţi analitice sistemului suport de decizie. Ea este formată din: baza de modele, sistemul de gestiune a bazei de modele, catalogul de modele, procesorul de execuţie, integrare şi comandare a modelului. - Baza de modele conţine diferite modele statistice, financiare matematice şi alte modele can-titative utilizate pentru executarea diferitelor analize. Baza de modele este ceea ce diferenţiază un SSD de alte sisteme informatice. SSD trebuie să poată executa, modifica şi controla modelele. După nivelul de conducere la care sunt folosite, modelele se clasifică în modele strategice, tactice şi operaţionale. Modelele strategice sunt în general foarte complexe, cu multe variabile, cu un orizont larg de timp (de regulă în ani), au tendinţa de a fi descriptive şi mai puţin de optimizare, folosesc mai mult date externe decât interne. Modele tactice sunt folosite în activitatea de alocare şi control a resurselor, fiecare fiind dedicat unei activităţi, orizontul de timp se întinde dela o lună la doi ani, folosesc foarte multe date interne şi mai puţin externe, pot fi atât optimizate cât şi descriptive. Modelele operaţionale sunt folosite în activităţile zilnice (controlul calităţii, planificarea producţiei), orizontul de timp este mic (o lună) şi folosesc foarte multe date interne. După aria funcţională modelele se clasifică în: financiare, modele de contabilitate, modele de control a producţiei, etc. - Sistemul de gestiune a bazei de modele este folosit pentru a gestiona baza de modele şi are următoarele funcţii: - posedă un limbaj de modelare necesar pentru crearea modelelor decizionale în concordanţă cu cerinţele utilizatorilor; - permite integrarea modelelor prin controlul odinii de execuţie a modelelor;

4

- permite utilizatorului să modifice modelele pentru a reflecta cerinţele sale; - permite utilizatorului să manipuleze modelele pentru a realiza scenarii şi analize complexe; - oferă un catalog al modelelor stocate, cu o descriere a funcţiilor lor şi a aplicaţiilor la care sunt folosite. - Catalogul de modele conţine definiţiile modelelor, descrierea funcţiilor şi a aplicaţiilor la care sunt folosite. Deoarece selecţia unui model implică experienţă din partea sistemului, la un SSD aceasta trebuie făcută de utilizator. Numai Sistemele Expert pot face selecţia de model. c) Componenta pentru asigurarea comunicaţiei vizează arhitectura SSD, problemele de securitate şi de reţea. O arhitectură SSD poate fi reprezentată pe patru nivele: - diagrama proceselor care arată fluxul proceselor din activitatea analizată; - arhitectura sistemului care se referă la componentele software; - arhitectura tehnică care se referă la hardware, protocoale şi tipul de reţea; - arhitectura de livrare a SSD-ului care pune accent pe ieşirile sistemului. O arhitectură bine definită îi ajută pe decidenţi să lucreze împreună şi creşte capacitatea echipei de a comunica cu managerii. Reţelele de calculatoare sunt elementul critic al infrastructurii informatice. Cu privire la planul de securitate, administratorii de sistem şi managerii trebuie să ţină cont de factorii următori: importanţa sistemului, valabilitatea lui şi a datelor stocate, volumul de effort cerut pentru a asigura securitatea sistemului şi modul în care planul de securitate stabilit afectează utilizatorii sistemului.

d) Interfaţa cu utilizatorul conţine următoarele componente: - limbajul de comunicare care permite intreracţiunea cu SSD, oferă suport pentru comunicare între utilizatorii sistemului; - limbajul de prezentare care permite prezentarea datelor într-o varietate de formate; de el ţin şi imprimantele, plotterele, monitoarele video şi audio şi sintetizorul de voci; serveşte pentru transmiterea informaţiilor şi comenzilor la SSD; La proiectarea interfeţei trebuie să avem în vedere factori asociaţi cu interacţiunea umană cum ar fi accesibilitatea, uşurinţa de utilizare, nivelul de îndemânare, capturarea erorilor şi raportarea lor. e) Utilizatorul Proiectarea, implementarea şi utilizarea SSD pot fi complete numai dacă se are în vedere rolul utilizatorului, care se manifestă prin îndemânarea acestuia, motivaţia sa, domeniul său de cunoştinţe, tiparele de utilizare şi rolul său în cadrul organizaţiei. Utilizatorul este definit ca persoana sau persoanele responsabile pentru furnizarea unei soluţii la problema analizată sau pentru luarea unei decizii, în contextul în care a fost construit SSD-ul. Există decidenţi care nu pun mâna pe SSD ci utilizează numai rapoartele furnizate de acesta şi decidenţi solicitanţi, care au ca intermediar un analist SSD ce utilizează sistemul. Decidenţii solicitanţi elaborează întrebări, interpretează rezultatele şi apoi iau decizii. Mai există decidenţi on-line şi decidenţi care pot construi propriile modele şi chiar simple SSD-uri. Clasificarea SSD la nivel conceptual

- SSD-uri orientate pe date; - SSD-uri orientate pe modele; - SSD-uri orientate pe cunoştinţe; - SSD-uri orientate pe documente sau sistem de gestiune a cunoştinţelor; - Sistem suport de decizie de grup sau sisteme suport de decizie orientate pe comunicaţii;

5

- SSD-uri interorganizaţionale sau intraorganizaţionale; - SSD-urispecializate (de exemplu pentru planificare bugetară, marketing, planificarea

activităţii de zbor dintr-o companie aeriană, etc.); - SSD-uri bazate pe Web (pe bază de browser folosit pentru livrarea informaţiilor

necesare procesului decizional şi pentru instrumentele suport de decizie la manageri, sau analişti);

Analiză comparativă între sistemele informatice pentru prelucrarea tranzacţiilor sau On-line transactions processing (OLTP), sisteme informatice pentru conducere sau Management informational Systems (MIS), SSD şi sisteme expert (SE).

Caracteristici OLTP MIS SSD SE Tipul aplicaţiilor

Gestiunea stocurilor, a plăţilor, a livrărilor, a comenzilor

Controlul pro-ducţiei, analiza bugetului, previziuni pe termen scurt

Evaluarea credi-telor, planificarea asigurării calităţii, planificarea proiectelor

Diagnosticare, prospecţiuni, domenii limitate

Obiectiv Prelucrarea automată a tranzacţiilor de date

Informaţii Asistarea în pro-cesul decizional, implementarea deciziilor

Înlocuieşte decidentul uman

Operaţii tipice

Actualizare Raportare Analiză (de ex. analiza multidimensională)

Descoperirea cunoştinţelor (de ex. data mining)

Posibilităţi de decizie

Deloc sau modele de decizie simple

Suport pentru rezolvarea problemelor structurate

Suport pentru probleme semistructurate

Sistemul ia decizii complexe, nestructu-rate, utilizează reguli (euristice)

Surse de date Interne Interne Interne, externe Interne, externe Nivelul de conducere

Operaţional Tactic Strategic Strategic

Peocuparea majoră

Eficienţa prelucrării datelor operaţionale

Eficienţa procesului decizional

Eficienţa procesului decizional

Eficacitatea, transfe-rul de cunoştinţe despre o anumită activitate şi oferirea de sugestii

Tipul de utilizatori

Operatori Manageri Manageri Specialişti şi manageri

Accentul pe Integritate şi consistenţa datelor

Raportare periodică, de moment şi de excepţie

Flexibilitate, suport pentru cereri ocazionale şi analize

Sfaturi şi explicaţii

Intrebări recapitulative 1. Ce este un SSD? 2. Care sunt etapele procesului decizional? 3. Care probleme pot fi considerate structurate? 4. Care sunt factorii care fac ca utilizarea SSD să devină din ce în ce mai stringentă?

6

5. Ce sunt datele agregate şi care este legătura lor cu depozitul de date? 6. Care sunt componentele unui SSD? 7. Ce tipuri de relaţii există în componenta de gestiune a datelor? 8. Sub ce formă se pot prezenta în relaţiile existente în componenta de gestiune a datelor informaţiile, datele şi cunoştinţele? 9. La ce se referă datele provenite din surse externe, cele din surse interne şi cele din surse private? 10. Prin ce se caracterizează datele din componenta de gestiune a datelor? 11. Ce sunt metadatele? 12. La ce serveşte componenta de gestiune a modelelor şi din ce se compune ea? 13. Cum se clasifică modelele după nivelul strategic la care sunt folosite? 14. Care sunt funcţiile sistemului de gestiune a bazei de modele? 15. Care sunt nivelele pe care poate fi reprezentată arhitectura unui SSD? 16. Care sunt factorii care trebuie luaţi în calcul cu privire la securitatea în sistem? 17. Care sunt componentele interfeţei cu utilizatorul? 18. Cum se clasifică SSD-urile la nivel conceptual? 19. Ce este un OLTP, un MIS şi un SE? 20. Care sunt tipurile de aplicaţii prin care se diferenţiază un OLTP, un MIS, un SSD şi un SE?

II. Sisteme expert 1. Inteligenţa artificială şi sistemele expert

Inteligenţa artificială se ocupă cu comportamentul inteligent şi mai exact cu studiul posibilităţii de emulare a acestuia la maşini, respectiv maşini de calcul. Comportament inteligent înseamnă un comportament care implică realizarea unor activităţi ce necesită calităţi intelectuale deosebite cum ar fi: posibilitate de abstractizare, flexibilitate, adaptare la situaţii noi, creativitate, etc. Informatica convenţională, bazată pe algoritmi, nu a reuşit să transfere aceste activităţi inteligente spre maşină. Inteligenţa artificială se bazează pe memorarea cunoştinţelor şi asigurarea condiţiilor de prelucrare automată a cunoştinţelor. De aceea sistemele de inteligenţă artificială se numesc sisteme bazate pe cunoştinţe sau sisteme cu bază de cunoştinţe. Ele sunt specializate în desfăşurarea diferitelor activităţi. Sistemele de inteligenţă artificială dispun nu numai de o bază de cunoştinţe ci şi de mecanisme de utilizare a acestora (cum ar fi mecanisme rezolutive, inferenţiale sau de raţionament), de o bază de fapte şi de posibilităţi de descriere a activităţilor ce trebuie să le execute (a task-urilor) cu ajutorul faptelor. Procesul seamănă cu cel pe care-l derulăm şi noi oamenii: mai întâi învăţăm, (sau acumulăm cunoştinţe) care se depun în memorie (echivalentul bazei de cunoştinţe), dar reţinem şi fapte (împrejurările în care s-au produs, ce cunoştinţe implică fiecare fapt), apoi dacă vrem să îndeplinim o sarcină, o descompunem în paşi (fapte), iar din baza de cunoştinţe extragem cunoştinţele asociate cu faptele ce trebuie derulate, adică acele cunoştinţe care răspund la întrebarea ”Cum trebuie să îndeplinim faptul X?”. Remarcăm că aceste cunoştinţe se exprimă în mod independent de modul lor de utilizare, ceea ce nu este cazul în informatica convenţională. Acolo reprezentarea cunoştinţelor este implicită şi numai modul de utilizare a acestora (algoritmul) este explicit (astfel un X folosit într-o formulă nu prezintă interes dacă reprezintă kilograme sau metri oameni sau obiecte).

7

În inteligenţa artificială, pentru că aceleaşi cunoştinţe pot fi utilizate în mod diferit cu ocazia rezolvăriii diferitelor probleme, sau chiar în rezolvarea aceleaşi probleme în împrejurări diferite, cunoştinţele sunt exprimate explicit şi relativ independent de modul de utilizare. Realizarea unui sistem de inteligenţă artificială are sarcina de a identifica (reprezenta) cunoştinţele necesare efectuării unor activităţi şi de a dota sistemul cu mecanisme care să permită aplicarea acestor cunoştinţe. Acest sistem trebuie să fie capabil ca la momentul execuţiei să ia decizii cu privire la cunoştinţele ce sunt necesare pentru îndeplinirea sarcinii, cum şi când să fie utilizate ele pentru realizarea sarcinii. Ca urmare, inteligenţa artificială trebuie să furnizeze metode şi tehnici de achiziţionare, reprezentare şi utilizare a cunoştinţelor. a) Metodele şi tehnicile de achiziţionare a cunoştinţelor precizează modul în care se construieşte baza de cunoştinţe într-un sistem de inteligenţă artificială. Acestea sunt învăţarea teoretică, învăţarea empirică şi legat de învăţarea empirică – învăţarea simbolică. La început s-a încercat învăţarea teoretică bazată pe calcul simbolic, dar rezultatele nu au fost satisfăcătoare. Ca urmare învăţarea teoretică a fost completată cu învăţarea empirică aplicată pe o bază de cunoştinţe sub forma unei reţele neurale (reţea neurală bazată pe cunoştinţe). Completarea acestei reţele cu noi cunoştinţe (instruirea) se realizează pe baza exemplelor de instruire (aplicabile acestui tip de reţea), cu ajutorul unuia dintre algoritmii de instruire a reţelelor neurale. Rezultatele instruirii se prezintă sub forma valorilor parametrilor de reţea. În cadrul învăţării simbolice, aceste valori sunt convertite în cunoştinţe reprezentate simbolic cu ajutorul unor algoritmi de extragere a cunoştinţelor din reţele neurale, şi sunt adăugate la baza de cunoştinţe (BC). În afară de metoda de învăţare prin instruire, învăţarea simbolică se mai poate derula şi prin metode şi tehnici inductive (din exemple, prin descoperire, prin observare), precum şi prin metode şi tehnici de învăţare pe de rost. b) Metodele şi tehnicile de reprezentare a cunoştinţelor definesc structurile de reprezentare a cunoştinţelor şi ele trebuie să satisfacă următoarele cerinţe: - adecvare reprezentaţională ( să poată reprezenta toate categoriile de cunoştinţe dintr-un domeniu dat); - adecvare achiziţională (să permită achiziţionarea cunoştinţelor); - adecvarea informaţională (structurile de reprezentare trebuie să permită definirea unor operatori, să fie prelucrabile); - eficacitatea inferenţială (structurile de reprezentare trebuie să permită prelucrările nu oricum ci numai în condiţii de eficienţă) . Metodele şi tehnicile de reprezentare a cunoştinţelor posedă şi nişte caracteristici şi anume:

- gradul de granularitate (nivelul de detaliere); - gradul de modularitate a structuriilor (independenţa modulelor) ; - gradul de compilare (măsura în care reprezentarea favorizează anumite scheme de

utilizare a cunoştinţelor); - gradul de nedeterminare (numărul de soluţii alternative de reprezentare din care se poate

poate face reprezentarea unei anumite piese de cunoaştere). Metodele şi tehnicile de reprezentare a cunoştinţelor pot fi:

- de tip simbolic (calculul predicatelor, regulile de producţie, cadre-frame, grafuri, etc.) ; - neural (reţele neurale) ; - genetic (cromozomi).

8

c) Metodele şi tehnicile de utilizare a cunoştinţelor depind în mod direct de cele de reprezentare. Practic, utilizarea cunoştinţelor este un proces de aplicare a unui set de operatori definiţi asupra structurilor de reprezentare a cunoştinţelor prin metode „slabe” şi metode „tari”. Ca urmare, fiecare schemă de reprezentare are corespondent în ansamblul metodelor şi tehnicilor de raţionament. Metodele şi tehnicile de raţionament se aplică într-o anume variantă (de raţionament) în condiţii de completitudine a cunoştinţelor şi certitudine şi în altă variantă în condiţii de incompletitudine şi incertitudine. Inteligenţa artificială se aplică în domenii ca prelucrarea limbajului natural, modelarea raţionamentelor, probleme de percepţie, jocuri, roboţi, sisteme expert.

2. Sisteme expert – definire şi arhitectură Sistemele expert reprezintă sisteme de inteligenţă artificială destinate rezolvării unor probleme dificile, de natură practică, la nivelul de performanţă a experţilor umani. Ele realizează o automatizare a expertizei dintr-un anumit domeniu numit domeniu de expertiză.

a) Domeniu de expertiză se caracterizează prin cunoştinţe generale, cunoştinţe de specialitate şi cunoştinţe expert. În cazul oamenilor, cunoştinţele expert se obţin de către expertul-om prin experienţă şi calităţi individuale deosebite şi ele îl deosebesc de ceilalţi specialişti în domeniu, care posedă doar cunoştinţe generale şi de specialitate. Cunoştinţele asociate domeniului de expertiză servesc la rezolvarea problemelor din acest domeniu, care ca tip sunt în general omogene şi pot fi considerate ca aparţinând unei anumite clase de probleme. Descrierea unei anumite probleme din clasa domeniului respectiv se realizează prin prezentarea stării de fapt a domeniului la un moment dat. b) Conceptele asociate expertizei într-un SE sunt legate de baza de cunoştinţe şi anume: cum este construită (achiziţionată), cum se rezolvă raţionamentul, cum se explică utilizatorului. Caracteristicile şi conceptele expertizei definesc arhitectura SE iar din ea rezultă componentele sale: - baza de cunoştinţe (cunoştinţe din domeniul de expertiză reprezentate sub forma unor structuri cum ar fi formule din calculul predicatelor, reguli de producţie, ierarhii cadre, etc.) ; - baza de fapte (conţine descrierea problemei ce trebuie rezolvată. Pentru descriere se folosesc structuri de reprezentare a faptelor, care se prezintă sub formă de triplete < obiect, atribut, valoare> sau perechi < atribut, valoare>); - mecanisme rezolutive (asigură utilizarea cunoştinţelor prin implementarea unui ansamblu de operatori definiţi pe structurile de reprezentare a cunoştinţelor); - spaţiul de lucru (ansamblul rezultatelor intermediare şi setărilor parametrilor de funcţionare ai sistemului); - interfaţa de realizare (ansamblul instrumentelor cu care este posibilă realizarea diferitelor componente ale sistemului. De ex. mecanismele de achiziţionarea automată a cunoştinţelor care permit prelucrarea on-line a surselor de cunoştinţe în scopul identificării şi exprimării cunoştinţelor); - interfaţa utilizator (asigură comunicarea între sistem şi utilizator în scopul descrierii de către utilizator a problemei şi obţinerii de la sistem a rezultatelor şi explicaţiilor referitoare la rezultate).

3. Metode de reprezentare şi utilizare a cunoştinţelor în cadrul SE

3.1 Calculul predicatelor de ordinul întâi a) Limbajul formal al calculului predicatelor

9

Acesta este un limbaj de reprezentare a cunoştinţelor (sub forma structurilor de reprezentare) dar conţine şi reguli de inferenţă şi de aceea poate fi considerat ca fiind sistemul logic al calculului cu predicate. Construcţia de bază a calculului de predicate este atomul. Construcţiile compuse se încheagă cu ajutorul conectivelor şi cuantificatorilor. Construcţiile de bază şi cele compuse sunt utilizate sub denumirea de formule. Din punct de vedere semantic, limbajul calculului predicatelor permite exprimarea cu ajutorul formulelor a adevărului sau falsităţii unor stări sau situaţii din domeniul real. Reprezentarea cunoştinţelor cu ajutorul limbajului calculului cu predicate se face în trei etape şi anume:

- se identifică propoziţiile logice (aserţiunile) din descrierea în limbaj natural a cunoştinţelor;

- cu ajutorul conectivelor logice se exprimă legăturile (asocierile) dintre propoziţiile logice;

După această etapă, prin introducerea unor variabile propoziţionale care să desemneze propoziţii logice, se obţine o reprezentare în calculul propoziţional a cunoştinţelor. - se detaliază structura fiecărei aserţiuni prin utilizarea simbolurilor din alfabet.

b) Utilizarea cunoştinţelor. Probleme ale automatizării raţionamentelor Sistemul logic al calculului cu predicate posedă o serie de reguli de inferenţă ce permit obţinerea unor noi formule bine formate pe baza celor de care se dispune iniţial (axiome). Exemple de astfel de reguli: silogismul, specializarea universală, modus ponens, modus tollens, etc. În cadrul procesului automatizării raţionamentelor prin calculul cu predicate, formulele iniţiale se numesc axiome, cele derivate sunt teoreme, iar procesul derivării lor se numeşte demonstrare automată de teoreme. În acest context, rezolvarea unei probleme presupune:

- reprezentarea cunoştinţelor sub formă de formule (axiome); - descrierea stării iniţiale a problemei sub formă de formule (axiome); - descrierea soluţiei (stării scop) sub formă de formule (teoremă); - aplicarea regulilor de inferenţă în scopul demonstrării teoremei.

Cu această ocazie pot apărea unele dificultăţi de automatizare cum ar fi: problema decidabilităţii şi problema eficienţei procedurilor de demonstrare a teoremelor. Acestea se rezolvă prin restrîngerea sistemului logic al calculului cu predicate la subsisteme logice, decidale, cum ar fi subsistemul logic bazat pe clauze HORN şi prin omogenizarea formulelor şi reducerea numărului de tipuri de reguli de inferenţă utilizate ( de exemplu limitarea numai la regulile de inferenţă a rezoluţiei). 3.2 Regulile de producţie sunt utilizate pentru exprimarea asocierilor empirice dintre descrierile de stare ale problemei şi acţiunile de intreprins în cazul în care problema se află într-o anumită stare. Ele servesc la reprezentarea cunoştinţelor de natură procedurală sub forma unor construcţii modulare de tipul

Dacă Atunci

Dintre construcţiile condiţionate numai cele definite în mod modular reprezintă o regulă de producţie. În cadrul ansamblului de reguli, numit bază de reguli, nu este definită nici o relaţie

Şablon de date sau condiţie

Prelucrări sau acţiuni sau concluzie

10

de ordine. Tratarea (executarea) activităţilor condiţionate de premize este independentă de modul de încărcare (organizare) a bazei de reguli. Sistemele de inteligenţă artificială bazate pe reguli sunt constituite din:

- baza de reguli; - ansamblul de fapte (contextual sau memoria de lucru) ce conţine descrierea problemei

de rezolvat. Un fapt este de obicei reprezentat sub formă de triplet sau pereche (vezi secţiunea 2, aliniatul b);

- interpreterul de reguli (mecanismul de raţionament pe reguli sau mecanismul de înlănţuire a regulilor).

3.3 Frame-uri şi reţele de cunoştinţe Un cadru (frame) reprezintă o unitate de informaţii care grupează un anumit număr de rubrici (sloturi). O rubrică de frame poate conţine informaţii despre obiectul prezentat cu informaţii de legătură cu alte frame-uri (reflectă o aparteneţă). De asemenea, într-o rubrică poate figura un apel la o procedură externă de calcul, caz în care se vorbeşte de ataşare procedurală. Utilizarea acestui tip de reprezentare permite regăsirea rapidă a anumitor agregate informaţionale (cum ar fi firmele aparţinând unei anumite ramuri). La fiecare rubrică sunt declarate condiţiile în care trebuie să se realizeze gestionarea valorii rubricii (faţetele de frame). Astfel pentru fiecare frame se pot declara valorile situate în alte frame-uri care trebuie modificate la schimbarea uneia dintre rubricile sale. Fiecare rubrică posedă, de asemenea, descrierea comportamentului frame-ului la citire, adăugare sau ştergere a valorii din rubrica respectivă. Frame-urile asigură o schemă simplă şi eficientă de lucru cu valorile implicite. Utilizarea frame-urilor (a raţionamentului pe bază de frame-uri) constă în modificarea din aproape în aproape a conţinutului memorat în structura de frame-uri pe baza procedurilor ataşate rubricilor. Uneori sistemele pe bază de frame-uri introduc şi reguli (în formă clasică sau simulate ca frame-uri). Pe baza reţelei de frame-uri se poate generaliza repartizarea pe bază de grafuri a cunoştinţelor sub forma reţelelor de cunoştinţe. La început, reţelele de cunoştinţe au fost utilizate în prelucrarea limbajului natural (reţele semantice) pentru a exprima dependenţele dintre conceptele desemnate în limbajul natural prin fraze. 4. Evoluţia sistemelor informatice spre sisteme expert si SSD Prelucrarea nealgoritmică, descriptivă a cunoştinţelor în cadrul sistemelor expert a avut drept consecinţă extinderea ariei de aplicare a tehnologiilor informatice.Această extindere s-a produs atât pe orizontală, spre noi domenii economico-sociale (activităţi educaţionale, juridice , politice, etc.) cât şi pe verticală, spre prelucrări şi procese informaţionale noi (cum ar fi evaluarea calitativă, raţionamentul în sens general). În consecinţă, tehnologiilor informatice actuale permit prelucrarea unui segment al deciziilor economico-sociale, în special cele de rutină, adică permit automatizarea a numeroase faze din procesul informaţional-decizional. Prelucrarea nealgoritmică a informaţiei în cadrul sistemelor expert poate oferi soluţii mai productive unor probleme abordate şi rezolvate deja în manieră convenţională (algoritmică). În domeniile în care datele şi cerinţele informaţionale se modifică frecvent, soluţiile algoritmice se adaptează cu dificultate la aceste schimbări, uneori cu preţul reproiectării şi a unor programări laborioase. Tehnologiile nealgoritmice utilizate în cadrul sistemelor expert permit o adaptare perfectă la schimbările survenite în volumul şi structura cunoştinţelor şi a cerinţelor informaţionale. Sistemele expert se adaptează foarte bine şi la situaţiile cu informaţii incomplete şi/sau imprecise. Acest lucru este posibil datorită faptului că sistemele expert permit utilizarea în cadrul raţionamentului automat a regulilor euristice, validate de practică, care concură cu succes abordarea formală . Datorită unor exprimări ale experţilor umani de forma “de obicei este

11

adevărat că”, sau “se poate spune că”, dificultăţile întânite în actul decizional se manifestă cel mai adesea în obţinerea informaţiilor de fundamentare a deciziilor şi nu în luarea deciziilor. Ca urmare sistemele expert oferă extindere în special în domeniul metodelor de obţinere a datelor şi a metodelor de analiză a acestora. Când avem de a face cu situaţii perfect cunoscute (cu informaţie completă şi precisă) este posibilă şi selectarea celei bune variante decizionale cu ajutorul sistemului expert (mai ales dacă numărul alternativelor fezabile este foarte mare). În management, sistemele expert sunt folosite din ce în ce mai mult. Aceasta pentru că în orice funcţie managerială există probleme decizionale complexe, neînţelese, dinamice, multicriteriale , ceea ce întârzie elaborarea deciziei, în timp ce presiunea în luarea deciziei este mare (pericol de pierderi semnificative, uneori dramatice). Un astfel de exemplu a fost cel al blocajului traficului pe Dunăre pe timpul interveţiei militare din fosta Jugoslavie, când transportul fluvial a fost paralizat şi ca urmare multe contracte au intrat în intârziere, mărfurile perisabile se degradau, ş.a.m.d., ca să nu mai vorbim de firmele afectate de atacul terorist de la 11 septembrie 2001. Folosirea calculatoarelor în programe complexe se extinde tot mai mult în sfera bancară. Aceste sisteme sunt utilizate pe larg pentru ierarhizarea condiţiilor şi premiselor economico-sociale ale deciziei de creditare, adică pentru formularea unui suport obiectiv, cuprinzător şi multilateral al deciziei. În marea majoritate a cazurilor decizia revine omului, dar el se bazează pe fundamente exprimate fără echivoc, de metodele specifice sistemelor expert. Intrebări recapitulative

1. Ce înseamnă un comportament inteligent? 2. Ce elemente au în compunerea lor sistemele de inteligenţă artificială? 3. Cum se mai numesc sistemele de inteligenţă artificială? 4. Care este deosebirea dintre sitemele convenţionale şi cele de inteligenţă artificială în ce priveşte modul de reprezentare şi modul de utilizare a cunoştinţelor? 5. Ce categorii de metode şi tehnici trebuie să furnizeze inteligenţa artificială? 6. Cum se construieşte baza de cunoştinţe într-un sistem de inteligenţă artificială? 7. Care este rolul reţelei neurale bazată pe cunoştinţe în construcţia bazei de cunoştinţe? 8. Ce rol joacă algoritmii de extragere a cunoştinţelor din reţele neurale? 9. Ce definesc metodele şi tehnicile de reprezentare a cunoştinţelor? 10. Care sunt cerinţele pe care metodele şi tehnicile de reprezentare a cunoştinţelor trebuie să

le satisfacă? 11. Care sunt caracteristicile metodelor şi tehnicilor de reprezentare a cunoştinţelor? 12. Cum se clasifică metodele şi tehnicile de reprezentare a cunoştinţelor? 13. Ce reprezintă sistemele expert în cadrul sistemelor de inteligenţă artificială? 14. Ce sunt domeniile de expertiză şi care sunt categoriile de cunoştinţe incluse în aceste

domenii? 15. Prin ce se defineşte arhitectura sistemelor expert şi care sunt componentele sale? 16. In ce constă sistemul logic al calculului cu predicate? 17. Cum se asamblează construcţiile compuse în cadrul calculului cu predicate? 18. Ce permite din punct de vedere semantic limbajul calculului predicatelor? 19. Care sunt etapele reprezentării cunoştinţelor cu ajutorul limbajului calculului cu

predicate? 20. Ce presupune rezolvarea unei probleme în cadrul procesului automatizării raţionamentelor

prin calculul cu predicate? 21. Din ce sunt constituite sistemele de inteligenţă artificială bazate pe reguli?

12

22. Care este categoria de reguli care permit SE să facă faţă unor situaţii cu informaţii incomplete şi/sau imprecise?

23. Care sunt categoriile de metode cu care SE s-au extins în domeniul automatizării raţionamentelor?

1

CURSUL_III_4

ANALIZA SISTEMELOR INFORMAŢIONALE

1. Analiza sistemelor informaţionale prin metoda MERISE Metoda Merise este una din cele mai elaborate şi mai riguroase metode de abordare a sistemului informaţional şi în plus, dispune şi de programul AMC* Designer specializat în generarea automată a arhitecturii unui sistem informaţional financiar-bancar. În cazul proiectării prin metoda Merise , ciclul de viaţă cuprinde: studiul de evaluare, modelarea globală, conceptuală, organizaţională, logică, fizică şi în final, implementarea , exploatarea şi întreţinerea sistemului . În cadrul fiecărei etape, în metoda Merise se au în vedere patru viziuni (puncte de vedere din care este văzut sistemul) ale sistemului informatic şi anume: descrieri şi definiţii, comunicaţie, date şi prelucrări. Ele străbat proiectul sistemului, la fel cum cele patru fire din compunerea unui cablu de curent trifazic, pot fi găsite oriunde pe lungimea cablului. Cu alte cuvinte, la orice nivel vrem să analizăm sistemul, aceste elemente trebuie luate în calcul. Dezavantajul acestei metode constă în aceea că implică o formalizare destul de complexă, care în cazul aplicaţiilor sau sistemelor informatice mai simple, mai ales dacă nu dispunem de programul AMC* Designer, nu este justificată. De aceea în secţiunea 2 vom relua etapa de analiză şi vom arăta cum se poate face analiza prin metoda fluxurilor de date, iar restul etapelor de realizare a sistemelor informatice vor fi comentate în capitolele următoare numai pe exemplul metodei fluxurilor de date. În acest capitol prezentăm metoda Merise pentru a face cunoscută existenţa ei celor interesaţi în sisteme informatice financiar-bancare, dar şi pentru a aprofunda ideea că problemele legate de comunicaţii şi de modelarea orgnizaţională trebuie să fie luate în calcul şi în celelalte metode, chiar dacă metodologia lor nu prevede explicit acest lucru. Complexitatea formalizării utilizate în metoda Merise este aproape inevitabilă în cazurile în care avem de a face cu posturi de lucru multiple, când trebuie să existe sincronizări ale acţiunilor unor actori, când se urmăresc timpi de răspuns, sau aspecte speciale legate de securitatea datelor, aşa cum este cazul sistemelor informatice financiar-bancare şi nu numai. 1.1 Modelarea globală (MG) a) Descrieri şi definiţii - studierea cadrului legislativ în care-şi desfăşoară activitatea unitatea studiată; - descrierea funcţiilor/domeniilor specifice unităţii studiate;

2

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

Operaţii Complexe Elementare

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

3

prelucrarea acestora. MC asigură o soluţie stabilă căreia îi vor corespunde una sau mai multe soluţii concrete organizaţionale, logice şi fizice elaborate în etapele viitoare. a) Descrieri şi definiţii la nivel conceptual: - stabilirea funcţiilor/domeniilor sau activităţilor informatizabile autonome; în cadrul acestora se identifică un sistem de conducere, unul informaţional şi unul operant; - stabilirea intrărilor sistemului pe tipuri: off-line (documente de intrare) şi on-line; se vor întocmi tabele cu documente având structura: cod document, denumire, frecvenţa, ce informaţii conţine (casete de editare texte); pentru fiecare document se va întocmi macheta, precum şi un tabel ale cărui coloane sunt chiar denumirile câmpurilor având specificate pe rândul următor tipul câmpului şi dimensiunea; - stabilirea ieşirilor (rapoarte, grafice, indicatori sintetici, ieşiri către alte sisteme). Pentru fiecare raport sau grafic se va prezenta macheta şi dispozitivul de ieşire, iar unde este cazul şi algoritmii de calcul precum şi reguli de disciplină informaţională concretizate în specificaţii legate de modul practic de utilizare a unui raport (funcţia, activitatea, compartimentul beneficiar, numărul de exemplare, frecvenţa, termen, dispozitiv periferic de ieşire, etc.); - sistemul de codificare (tabel cu coduri sau după caz, formule pentru coduri); coduri standard. b) Modelul conceptual de comunicaţii (MCC) Foloseşte concepte specifice ca: actori, fluxuri, diagrame de flux, matrice de flux, diagramă conceptuală de flux. Diagramele de flux materializează actorii, legaţi între ei cu săgeţi pe care sunt trecute simbolurile documentelor, iar lângă simboluri se trece în paranteză numărul curent al operaţiei în tabelul ce însoţeşte diagrama. Acest tabel conţine rubricile: nr. de ordine, actorul, descrierea acţiunii acestuia (fluxului realizat), documente/situaţii folosite. În diagrama de flux numele actorului se trece în simboluri reprezentate prin cercuri, hexagoane sau pătrate. Matricele de flux conţin actorii, atât pe orizontală cât şi pe verticală, iar la intersecţie se trec simbolurile documentelor care îi leagă ( de ex. BC bilanţ contabil, sau SS situaţia stocurilor şi cheltuielilor). Pe diagonala principală sunt marcate fluxurile interne. Celelalte sunt fluxuri externe. Diagramele conceptuale de flux seamănă cu diagramele de flux, dar pe săgeţi nu conţin simboluri de documente, ci numărul pasului din compunerea algoritmului referitor la circuitul informaţional reprezentat de diagramă. Un astfel de algoritm este în fapt reflectarea unor prevederi legale sau tehnice referitoare la modul de desfăşurare a activităţii analizate. Pasul descrie în cuvinte cine şi ce trebuie să facă. c) Modelul conceptual de prelucrare (MCP) Se bazează pe conceptele: actori, evenimente/rezultat/mesaje, operaţie, sincronizare, procese, reguli de verificare, reguli de sintaxă, reguli de funcţionare. Pentru fiecare concept există simboluri, iar dintr-un ansamblu de actori, evenimente/rezultat/mesaje, operaţie, sincronizare poate rezulta o operaţie complexă, care poate fi reprezentată cu un

4

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

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

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

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

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

5

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

6

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:

Sectorul Număr tip apariţii resurse: RU/RI/RC/RT faza: frecvenţa

sarcina 1 sarcina 2

Tipul

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

[condiţie logică] [nume fază] sarcini [descriere] [condiţie de emisie]

7

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.

8

U01 – serv. clientelă U02 – serv. credite

D1 Dpc1 Dpc2 D2 (date (date particulare) Da1 Da2 particulare) Modalităţile de acces se pot reprezenta şi tabular ca în tabelul următor:

Tipuri de entităţi şi relaţii

Unităţi organizaţionale Clienţi Credite Financiar

BANCA lucrează CLIENŢI încheie CONTRACTE PLĂŢI rambursează

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

R R R C R D C R D R R

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

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:

MOP sarcini

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

verificare cerere credit

CRE CRE CRE

Admitere cerere credit

CIT CIT

Încheiere contract credit

CIT CIT CRE CIT CRE

Rsmbursare credit

CIT CIT CIT CRE CIT CIT CRE

Urmărirea rambursării creditelor

CIT MOD ST

CIT MOD ST

CIT MOD ST

CIT MOD ST

MOD ST

CIT (MOD) (ST)

CIT (MOD) (ST)

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

9

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

Structura RP Structurile de control utilizabile în RP

variabile: proprietăţile/atributele externe

bloc (secvenţial)

constante: proprietăţile/atributele cu valori fixe

alternativă

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

repetitivă

operastori relaţionali: SI, SAU, NU.

EXEMPLU DE DOCUMENTATIE PENTRU ETAPELE MODELARE GLOBALĂ, CONCEPTUALĂ SI ORGANIZATIONALĂ

ÎN CAZUL UNEI CASE DE SCHIMB VALUTAR [2] 1. Modelarea globală a) Descrieri si definitii (se fac referiri la următoarele aspecte):

– activitatea de schimb valutar: mecanismul convertibilitătii, formarea cursului de schimb valutar, tipologia cotării, stabilirea cursului valutar, definitia pietei valutare, operatii efectuate pe piata valutară;

– politica valutară în Romania; – organizarea, functionarea si rolul caselor de schimb valutar.

b) Comunicatiile din sistemul caselor de schimb valutar (cu băncile, iar în cazul societătilor cu mai multe puncte de schimb (PSV), între aceste puncte de schimb): definirea comunicatiilor la nivelul structurii organizatorice a societătii, definirea solutiilor globale si previzibile de organizare a comunicatiilor de date si de prelucrări, specificarea generală a comunicatiilor viitoare (posturi de lucru sau retea de calculatoare)

c) Viziunea asupra datelor: - definirea obiectivelor manageriale si functionale ale sistemului (vezi pg. 72); - definirea intrărilor si iesirilor în concordantă cu obiectivele stabilite.

Tipul obiectivelor Intrări necesare Iesiri solicitate Manageriale Raport selectiv

Registru de casă Raport BNR Totaluri miscări

Functionale Buletin de cumpărare Buletin de vânzare

Jurnal cumpărări Jurnal vânzări

10

Buletin de miscare (intrări, iesiri, sold initial)

Borderou cumpărări Borderou vânzări Registru de casă Raport BNR Totaluri miscări

d) Viziunea asupra prelucrărilor - definirea subsistemelor informatice si aplicaţiilor informatice (în acest exemplu nu este cazul, fiind o singură aplicatie); - descrierea conexiunilor dintre subsisteme /aplicaţii în scopul asigurării funcţionalităţii sistemului realizat (nu este cazul).

2. Modelarea conceptuală a) Descrieri si definitii:

- stabilirea funcţiilor/domeniilor sau activităţilor informatizabile autonome; în cadrul acestora se identifică un sistem de conducere, unul informaţional si unul operant (la o CSV nu este cazul);

- tipuri de iesiri: rapoarte, grafice, indicatori. Rapoarte:

t Denumire raport

Frecventa

Descrierea raportului

JCV Jurnal cumpărare valută

zilnic Prezintă nr. BSV, codul valutei suma încasată, comisionul, c/v lei, c/v lei BNR si suma plătită

JVV Jurnal vânzări valută

zilnic Se completează după modelul de mai sus

BC Borderou cumpărări

Se completează după modelul de mai sus

BV Borderou vânzări

zilnic Se completează după modelul de mai sus

RBNR Raport BNR lunar Se completează după modelul de mai sus TM Total miscări lunar Se completează după modelul de mai sus RC Registru de

casă zilnic Se completează după modelul de mai sus

În continuare se prezintă structura informaţională a fiecăruia dintre

rapoartele din tabelul de mai sus. De exemplu:

11

CSV………. Cod: JCV PSV……….

Jurnal CUMPĂRĂRI VALUTĂ în perioada de la D,8 la D,8

Nr. BSV

DATA

OP.

COD VALUTĂ

CURS

ÎNCASAT

Y.COM

COMI-SION

C/V

LEI

C/V LEI BNR

PLĂTIT

C,10

D,8

C,3 N,4

N,6 N,6,2

N,6 N,10

N,10

N,10

TOTAL GENERAL N,8 *N,12

*N,12

*N,12

Graficele

Cod si tip Denumire Frecventa Axa OX Axa OY 2D 3D G1- bare Evolutia cumpărării L/A Lunile anului Valori în valută da da G2- bare Evolutia vânzării L/A Lunile anului Valori în valută da da

În continuare, pentru fiecare grafic în parte, se dau imagini capturate ale graficelor

Indicatorii sintetici: cifra de afaceri, cea mai eficientă valută (cele mai mari venituri), profit din operatiile de schimb valutar, rentabilitatea medie, ecartul mediu, cel mai mare ecart, cel mai mic ecart, cea mai tranzactionată valută, cea mai putin profitabilă valută. - intrările: buletinul de schimb valutar, borderou de cumpărare (BC), borderou

de vânzare (BV). Pentru fiecare document se precizează când se emite, în câte exemplare, cum se folosesc exemplarele. Se precizează cum vin aceste documente în sprijinul iesirilor (de exemplu se evidentiază faptul că ele ne permit să generăm situaţia cumpărărilor si vânzărilor de valută pe zile si pe valute, fisa tranzactiilor valutare pe fiecare valută în parte, evidenţiindu-se soldul zilnic al valutei respective). În continuare se dau machetele documentelor de intrare, cum ar fi cea a buletinului de schimb valutar.

- sistemul de codificare. Exemplu:

Tipul actului de identitate Buletin Adeverinta de

identitate Pasaport turistic

Pasaport de serviciu

Pasaport străin

BI AI PT PS XX

Pentru ţări se foloseşte codificarea pentru circulaţia rutieră. Urmează un tabel cu simbolurile valutelor având câmpurile simbolul valutei şi denumirea valutei.

12

b) Modelul conceptual de comunicatii (MCC) este realizat pe baza următorilor

actori si fluxuri informationale: Nr. Ordine al operatiei

Actor sursă

Actor destinatie Document/ situatie

Descriere flux

1 PSV CSV BMITPSV Transferul sumelor în valută între PSV si CSV 2 CSV BNR BMITB Transfer valută între BNR si CSV 3 CSV BNR TXC Verificarea soldului în valută … … … … … 17 CSV BNR BMETB Depunerea sumelor în valută la BNR

MCC aferent CSV este materializat prin tabelul de mai sus si prin următoarea diagramă de flux:

BMECH(8) BC(7), BV(7) Persoană fizică Bi(6),A(6),PT(6) BOC(14), BOV(14) (română/străină) PS(6), XX(6) JCV(9), JVV(9) RZT(14) BC(12), BV(13) RC(14) BMITPSV(1) BMSI(5) BC(7) BV(7) BMSI(4) BNR CSV RZT(13) JCV(9), JVV(10) BC(11), BV(12) RC(13), RBNR(14) TM(15), BOC(15) BOV(15)

Notatii folosite: BI – buletin de identitate BMETB – buletin miscare iesiri transfer bancă BC – borderou cumpărări AI – adeverintă de identitate BMETPSV – buletin miscare iesiri transfer PSV BV – borderou vânzări PT – pasaport turistic BMECH – buletin miscare iesiri cheltuieli RC – registru de casă PS – pasaport de serviciu BMEAE - buletin miscare iesiri alte iesiri RBNR – raport către BNR ……………………………………………………………………………………………………………… MBSI – buletin miscare sold initial RZT – registru zilnic de tranzactii valutare BOV – borderou vânzări

BMITB(2) EXC(3) RBNR(16)

PSU

13

Să observăm că 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ă nr. crt. al operaţiei în tabelul ce însoţeşte diagrama. Numele actorului se trece în simboluri reprezentate prin cercuri, hexagoane sau pătrate. c) Modelul conceptual de date (MCD)

MCD asigură determinarea tipurilor de atribute, entităti, relatii, chei primare si cardinalitatea. Pentru aceasta se pleacă de la analiza semantică a atributelor întâlnite în documentele primare si de la operanzii implicati in algoritmul de calcul al diferitelor operatii si se întocmeste baza de atribute (un tabel de forma celui de mai jos):

Tipuri de atribute Tipuri de entităti

Tipul de atribut

t,l C c Intrări Iesiri BC BV BMX JCV JVV BC BV RC RB

NR TM Cli

enti Valute

Tran-zactii

Miscări valute

Cod PSV C,5 * * * Serie BSV C,5 * * * * Număr BSV C,10 * * * * * * # Observatie: In cazul casei de schimb valutar (SCV) acest tabel contine cca 50 de atribute (rânduri) din care aici mai dăm pe ultimul Alte iesiri N,12,2 * *

În continuare se întocmeste matricea dependetelor (dependenţa între două atribute înseamnă că valorii unuia dintre ele îi corespund una sau mai multe valori ale altui atribut; de exemplu unui nr_fact îi corespunde data_fact). Aceasta conţine atributele provenite din documentele de intrare, atât pe verticală cât şi pe orizontală (doar că pe orizontală nu se mai scrie numele atributului, ci nr. crt. din prima coloană), iar la intersecţia a două atribute, dacă între ele există dependenţă funcţională se trece o stelută. În cazul CSV, aici sunt incluse cca 20 de atribute:

1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

1 Cod PSV

2 Serie BSV

3 Număr BSV

* * # * * * 6

… … 20

Pe baza documentelor întocmite mai sus, putem elabora MCD, care poate fi reprezentat grafic sau tabular:

14

Grafic CLIENTI TRANZACTII VALUTE Număr AI 0,n realizează 1,1 nr. BSV 1,1 foloseste 1,n Serie A serie BSV curs cumpărare

cod valută

Nume persoană data operatiei curs vânzare Tara % comision Organ emitent Data emiterii 1,1 actualizare 1,n Tabular

Descriere MCD Descrierea tipurilor de entităti Descrierea tipurilor de relatiiâ*

Tip entitate Tip proprietate Tip relatie Tip proprietate identificator Tip, lungime r R identificator Tip, lungime Cardinalitate colectie Clienti CLIENTI

număr AI,N,7 tip AI, C,2 seria AI, C,2 nume pers., C,40 tara, C,20 organ emitent AI, C,40 data emiterii AI, D,8

10 1000 Realizează - 0,n 1,1

CLIENTI TRANZ

Foloseste - 1,1 1,n

TRANZ VALUTE

Tranzactii CSV TRANZ

nr. BSV, C, 10 serie BSV,C,5 data operatiei, D,8 suma încasată, N,6 suma vândută, N,6

10 1000 Actualizare - 1,1 1,n

MISC- VALUTE VALUTE

Valute VALUTE

Cod valută, C,3 Curs cump, N,4 Curs vânz, N,4 % comision, N,6,2

38 38

Miscări valute MISC

Nr. Doc Descrierea operatiei, C, 40 Sold initial, N,12,2

12 12

*) Relaţia reprezintă corespondeţele de aceeasi natură care apar între o realizare din prima entitate si una sau mai multe realizări apartinând celeilate entităţi. Astfel un client realizează una sau mai multe tranzactii. Relaţia se poate crea pe mai mult de două entităti, dar si pe o singură entitate (relatie reflexivă). Colecţia este lista de entităţi care participă la o relaţie. Uneori relaţiile au propriile lor atribute. Acestea sunt independente de apartanenţa relaţiei la la o colecţie.

VÂNZÃRI Suma

CUMPÃRÃRI Suma

MISCÃRI VALUTE nr.document

15

De exemplu relaţia BANCĂ-CLIENT , exprimată prin verbul Lucrează, poate avea ca atribute data începerii cooperării (între bancă si client).

d) Modelul conceptual de prelucrare (MCP) Procesele derulate la nivel conceptual sunt următoarele:

1. Transfer sume valută între PSV si CSV; 2. Intrarea sumelor în valută prin transfer de la bancă; 3. Cumpărare/vânzare de valută; 4. Raportări lunare către BNr.

În continuare este prezentat un exemplu de înlănţuire a două procese ( PERSOANĂ FIZICĂ PSV BI AI PT PS XX f g h i j k f∨g∨h∨i∨j∧k

3. CUMPĂRARE/VÂNZARE VALUTĂ - înregistrarea cumpărărilor de valută în BC - înregistrarea vânzărilor de valută în BV - înregistrarea cheltuielilor PSV

OK OK

l n p b BOC JCV m BC RC RZT BOV JVV BV l m p b l∧m∧p∧b

4. RAPORTĂRI LIVRARE CĂTRE BNR - calculul totalului mişcărilor în valută;

la nivelulCSV - elaborarea RBNR OK OK r s TM RBNR BNR

cumpărare-vânzare valută şi raportări livrare către BNR), iar pe pagina următoare un exemplu de reprezentare a unui proces izolat (transferul sume valută PSV-CSV ) .

BMECH

16

PSV BMITPSV a 1. TRANSFER SUME VALUTĂ PSV-CSV

verificarea sumelor transmise între PSV si CSV. OK OK RZT

3. Modelarea organizaţională

Deoarece modelarea organizaţională vizează repartiţia organizaţională a sistemului informaţional (arhitectura si localizarea fizică a reţelei de calculatoare, soluţia bazei de date) văzută prin prisma departamentelor, serviciilor si posturilor de lucru şi în cazul unei case de schimb valutar, organizarea este prea simplă pentru a aplica modelul organizaţional, considerăm suficiente detaliile prezentate în secţiunea 1.3 în legătură cu acest tip de modelare.

Deatalii despre definirea obiectivelor sistemului informatic Observaţie: Obiectivele de mai jos sunt formulate la modul general, ca un ghid pentru definirea obiectivelor concrete ale unei firme date, dar în documentaţia de fază ele trebuie adaptate la specificul fiecărei firme si enunţate în forma cea mai adecvată. a) obiective generale: - de conducere: - rentabilizarea permanentă a activităţii economice;

- realizarea globală si structurală a indicatorilor economico-financiari, calculul si planificarea rezultatelor, planificarea financiară a investiţiilor, previzionarea activelor circulante, si a surselor de finanţare, previziunea activităţii de trezorerie, inclusiv utilizarea bugetului general al unităţii economice; - perfecţionarea activităţii de conducere în vederea asigurării unui optim global la nivelul întregii activităţi economice; - fundamentarea deciziilor de conducere tactică, strategică si operativă pe baza informaţiilor obţinute ca urmare a prelucrărilor sistemului informativ;

17

- asigurarea unei coordonări a întregului sistem informaţional-decizional; - utilizarea selectivă a unor informaţii de excepţie (rata anuală de înnoire a mijloacelor fixe, tendinţele preţurilor de aprovizionare, etc.), pentru asigurarea unei gestiuni eficiente a patrimoniului net pe baza unor informaţii cu caracter programatic si analitic; - degrevarea conducerii de procesele decizionale de rutină, formalizarea prin noul sistem a informaţiilor sintetice necesare derulării relaţiilor informaţionale cu organismele de stat si cu alte regii autonome sau societăţi comerciale; - furnizarea într-o formă adecvată, eficientă si facilă a informaţiilor globale necesare conducerii unităţii economice, sub forma unor indicatori globali, situaţii cu caracter sintetic, grafice, etc. care trebuie să conţină date relevante, prin intermediul afisării la videoterminal; - cresterea calităţii procesului decizional prin abordarea sistemică a activităţii unităţii economice si utilizarea modelării matematice, adaptate sistemelor electronice de calcul; - extinderea principiului conducerii prin excepţie si pe bază de obiective.

- obiective funcţionale pentru: - activitatea comercială; - aprovizionare tehnico-materială; - desfacere a produselor/rezultatelor activităţii; - marketing ; - activitatea financiar-contabilă:

- subactivitatea financiară (impozite, buget, relaţii bănesti, decontări);

- contabilitate: - contabilitate financiară (sintetică); - contabilitate si gestiunea (analitică); - control financiar; - activitatea de personal: - evidenţa personalului; - salarizare; - perfecţionarea calificării personalului. b) obiective specifice: - obiectivele specifice activităţii de bază. Ele trebuie să urmărească:

- utilizarea eficientă a capacităţilor de producţie; - introducerea de tehnologii si produse noi la nivelul tehnicii actuale; - realizarea ritmică si de calitate a lucrărilor de investiţii; - modernizarea utilajelor si a altor factori de producţie; - îmbunătăţirea continuă a calităţii producţei;

18

- cresterea gradului de utilizare a capacităţilor de producţie; - încadrarea consumurilor de materiale în normele tehnologice; - utilizarea raţională a capacităţilor de depozitare, a materialelor si produselor.

- obiectivele specifice activităţii auxiliare: au un caracter particular, o pondere şi o importanţă diferenţiată de la un agent economic la altul.

Bibliografie

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

19

2. Analiza sistemelor informaţionale prin metoda fluxurilor de date

2.1. Introducere Inainte de a începe prezentarea activităţilor ce se desfăşoară în etapa de analiză prin metoda fluxurilor de date, se impune a se preciza faptul că, în cazul acestor metode, analiza sistemului informaţional este precedată de o etapă de microanaliză, inspirată de gestiunea proiectelor în general, care presupune identificarea şi selectarea proiectului urmată de o iniţiere şi planificare a proiectului. Este un fel de studiu de fezabilitate. Considerând că această etapă este necesară numai în cazul proiectelor de mare anvergură sau că, în orice caz ea este atributul celor însărcinaţi să selecteze proiecte, în calitate de executanţi ai proiectului vom începe direct cu analiza sistemului informaţional. Pentru a face legătura între metoda fluxurilor de date şi metoda Merise, reamintim că în cadrul metodei Merise, în locul analizei se efectuează un studiu de evaluare, urmat de modelarea globală, modelarea conceptuală şi modelarea organizaţională. În metoda fluxurilor de date - orientată spre proces, analiza conţine trei subetape şi anume: determinarea cerinţelor, structurarea cerinţelor şi generarea şi alegerea variantelor de proiectare. Pentru a media diferenţa dintre cele două metode reprezentative, considerăm că nu subetapele şi denumirea lor contează ci faptul că înainte de a se ajunge la etapa proiectare logică, care este prevăzută în ambele metode, există anumite activităţi obligatorii de parcurs. Dacă aceste activităţi sunt efectuate, în ambele metode urmează etapele proiectare logică, proiectare fizică şi implementare, apoi exploatare, întreţinere şi dezvoltare. Totuşi, în ciuda denumirilor comune, a acestor etape, conţinutul lor nu corespunde întru totul de la o metodă la alta. Mai remarcăm că metoda fluxurilor de date nu este sistematizată printr-o matrice aşa cum este metoda Merise ci vizează în principal doar datele şi prelucrările; nu face explicit referiri la modelarea organizaţională şi nici la comunicaţii decât într-un capitol special dedicat bazelor de date distribuite. 2. 2. Determinarea cerinţelor Revenind acum la etapa de analiză, subetapa de Determinare a cerinţelor se poate parcurge prin metode tradiţionale sau prin metode moderne cum ar fi sesiunile JAD (Joint Application Design), sisteme de sprijinire a grupurilor de lucru, prototipizare şi RAD (Rapid Application Development). Remarcăm că aplicarea metodelor moderne specificate mai sus nu se opreşte la a determina şi structura cerinţele, ci merge mai departe, uneori reluându-se pe etape mai avansate până la definitivarea proiectării şi implementării. De aceea, aceste metode vor fi dezvoltate după subetapa de structurare a cerinţelor. Indiferent de metoda aleasă, pe timpul analizei analistul trebuie să aibă anumite trăsături distincte cum ar fi: tupeu, imparţialitate, anticonservatorism, să fie atent la detalii, adaptabilitate şi tact.

20

Rezultatul activităţii de colectare a informaţiilor se concretizează în diferite forme cum ar fi: copii ale interviurilor, însemnări efectuate în timpul observării şi analizei documentelor, interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru, etc., precum şi rezultate ale prelucrărilor pe calculator, cum ar fi prototipurile. Indiferent de forma de prezentare a informaţiilor culese de analist, din acestea trebuie să reiasă: - obiectivele firmei, funcţiile specifice, atributele conducerii şi modul în care sunt derulate activităţile ei; organigrama structurii organizatorice; - 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; - datele (tipologia, descrierea lor, volumul, mărimea, periodicitatea, amplasarea pentru prelucrări locale, teletransmisie, reţele, etc.) vehiculate în unitate pentru fiecare loc de muncă; - când, cum, de către cine şi ce date circulă, se transformă sau se înregistrează; - ordinea de prelucrare şi dependenţa dintre datele trecute prin diverse activităţi desfăşurate; - regulile prin care se specifică modul în care sunt transmise şi prelucrate datele; - 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; Analiza va începe cu pregătirea condiţiilor necesare analizei sistemului informaţional, constituirea colectivului pentru analiza sistemului informaţional şi elaborarea programului de realizare a analizei. Metodele tradiţionale de determinare a cerinţelor sistemului sunt: - observarea directă a activităţilor desfăşurate; - studierea documentaţiei existente (rapoarte, politici existente, regulamente, direcţiile spre care se îndreaptă prelucrarea datelor); - participarea la executarea activităţilor din sistemul informaţional pentru a observa personalul în momente bine definite, modul în care foloseşte informaţiile pentru exercitarea sarcinilor de serviciu; - anchete realizate prin chestionare; - interviul; - intervevierea grupurilor de oameni cu interese comune.

21

2.3. Structurarea cerinţelor Aceasta vizează: - modelarea proceselor (modelarea logică grafică a fluxurilor de date şi prelucrărilor cu ajutorul diagramelor fluxurilor de date (DFD)); - modelarea logicii proceselor (cu ajutorul englezei structurate, cu tabele de decizie, cu arbori decizionali) care include şi modelarea logicii temporale a proceselor (cu ajutorul diagramelor şi tabelelor stărilor de tranziţie) şi în fine, - modelarea conceptuală a datelor (diagramele entitate-relaţie). După structurarea cerinţelor urmează selectarea celei mai bune variante strategice de proiectare - a treia sub etapă a etapei de analiză. a) Modelarea proceselor constă în reprezentarea prin DFD (modele ale procesului de prelucrare) a modului de transfer a datelor între procesele de prelucrare. Nu interesează în acest context logica internă a prelucrărilor. Aceasta face obiectul modelării logicii proceselor. Există mai multe tehnici de redare a diagramelor fluxurilor de date, dar două sunt mai reprezentative şi anume Gane & Garson şi Yourdon & DeMarco. Scopul diagramelor fluxurilor de date (DFD) pentru o anumită componentă organizatorică sau funcţională, este de a scoate în relief următoarele aspecte: - sursa datelor de prelucrat; - operaţiunile de prelucrare prin care trec datele; - destinaţia datelor prelucrate; - legătura existentă între prelucrări şi activitatea de stocare a datelor. Se tinde ca simbolurile folosite pentru aceste diagrame să fie folosite atât pentru a reprezenta sisteme informaţionale logice, cât şi sistemele fizice, înlocuind astfel schemele logice. Această tendinţă nu este prea inspirată deoarece schemele logice sunt mai sugestive decât o diagramă. Cu această observaţie, în rest diagramele sunt net superioare. Dăm mai jos lista simbolurilor utilizate în cele două tehnici de modelare a DFD. Pe săgeţile de flux se specifică un nume care provine de la structurile de date care circulă pe flux. În dreptunghiul neînchis se specifică locul de stocare a datelor. Pentru a evita încărcarea diagramei cu prea multe linii, când este nevoie, simbolul respectiv se poate reeedita în locul potrivit. În aceste situaţii, copiile unui simbol se numerotează pe simbol. Obiect Simbolul

Gane & Sarson Simbolul Yourdon & DeMarco

Entitate externă Pătrat îngroşat

Pătrat simplu

22

Flux de date Săgeată

Săgeată care poate lua diverse forme

Loc de stocare Dreptunghi neînchis la dreapta

Linii paralele

Proces (prelucrare)

Dreptunghi cu colţuri rotunjite

Cerc

Ca exemplu de DFD, prezentăm Desfacerea şi Aprovizionarea cu mărfuri [1] (iniţial prin prisma tehnicii Gane & Sarson şi apoi prin cea a tehnicii Yourdon & DeMarco). Ca şi schemele logice, DFD se pot întocmi la nivel global, urmând ca unele procese să fie detaliate separat sau se pot întocmi de la început la nivel detaliat. În funcţie de scopul şi de subetapa pentru care se întocmesc, DFD pot fi de mai multe tipuri: - diagramă de context cu care începe analiza şi care scoate în relief aria de cuprindere a sistemului analizat. Acest lucru se face prin specificarea elementelor din interiorul organizaţiei şi a celor externe (relativ externe, adică faţă de structura pe care o analizăm); - diagrame ale fluxurilor de date ale sistemului fizic curent folosite pentru specificarea persoanelor şi tehnologiilor folosite pentru fiecare proces de transfer şi transformare a datelor; - diagrame ale fluxurilor de date ale sistemului logic curent folosite pentru a reliefa funcţiile de prelucrare a datelor, executate de către sistemul informaţional curent, independent de tehnologie; - diagrame ale fluxurilor de date ale sistemului logic nou folosite pentru a prezenta circuitul datelor, structura lor şi cerinţele funcţionale ale noului sistem; - descrieri ale obiectelor DFD, care se găsesc în dicţionarele proiectelor, iar în cazul CASE, în depozite sau repository.

23

D1 PRODUSE D3 STOCURI D4 FURNIZORI Date despre Cantităţi Siuaţie Preţuri, alte produse vândute stocuri date furnizor 1 4 C Comenzi Prelucrare Stabilire cant. Comenzi F CLIENŢI vânzare vânzări de reaprov. şi aprovizionare FURNIZORI furnizor Date vânzări Date Date comenzi vânzări aprovizionare D2 VÂNZĂRI D5 COMENZI_ÎN_CURS Sume Date Cantităţi Comenzi încasate vânzări acceptate restante 2 3 5 Pregătire Generare Recepţionare Informaţii documentaţie rapoarte Suplimentare loturi loturi bancă pentru vânzări stocuri aprovizionare depuneri Documente Date decontare vânzări B M BANCĂ MANAGEMENT

Diagrama fluxului de date privind desfacerea şi aprovizionarea cu mărfuri după metoda Gane & Sarson

În general analiza începe cu o diagramă de context, care ulterior va fi descompusă prin detalierea procesului ce face obiectul acestei diagrame (de ex. procesul de încasare). Metodele Gane & Garson şi Yourdon & DeMarco diferă între ele atât în ce priveşte lista simbolurilor folosite (aşa cum se poate vedea din tabelul cu simboluri), cât şi în ce priveşte următoarele aspecte: - metoda folosită la descompunerea diagramelor; - modelarea sistemului curent (diferenţa se poate vedea pe pagina următoare în tabelul cu paşii necesari pentru realizarea analizei structurate);

24

- relaţia dintre diagrama fluxului de date şi modelul datelor. Acesta vizează modalitatea de descriere a structurii documentelor (cum ar fi o factură), ale căror nume apar pe săgeţile din DFD.

PRODUSE STOCURI FURNIZORI Date despre Cantităţi Siuaţie Preţuri, alte produse vândute stocuri date furnizor 1 4 C Comenzi Prelucrare Stabilire cant. Comenzi F CLIENŢI vânzare vânzări de reaprov. şi aprovizionare FURNIZORI furnizor Date vânzări Date Date comenzi vânzări aprovizionare VÂNZĂRI COMENZI_ÎN_CURS Sume Date Cantităţi Comenzi încasate vânzări acceptate restante 2 3 5 Pregătire Generare Informaţii documentaţie rapoarte Suplimentare Recepţionare loturi bancă pentru vânzări stocuri loturi aprovizionare depuneri Documente Date decontare vânzări B M BANCĂ MANAGEMENT Diagrama fluxurilor de date poate fi utilizată în două moduri: pentru documentarea unui sistem existent sau pentru schiţarea unuia în curs de proiectare. Ea începe cu un text prin care de regulă se descriu simbolurile de utilizat în funcţie de metoda de reprezentare aleasă. După redactarea textului urmează crearea unui tabel de entităţi şi activităţi sau lista intrărilor/ieşirilor din/spre entităţile externe. Acesta va duce la pregătirea mai rapidă şi sigură a DFD şi a schemei logice de sistem (ultima fiind legată de modelarea logicii sistemelor). În final se desenează DFD.

Diagrama fluxului de date privind desfacerea şi aprovizionarea cu mărfuri după metoda Yourton & DeMarco

25

Metodele Gane & Garson şi Yourdon & DeMarco precizează foarte bine paşii ce trebuie parcurşi pentru a realiza o analiză structurată (în cazul de faţă – pe fluxuri). Astfel , DeMarco propune 7 paşi iar Gane & Garson propun 5 paşi pe care îi reprezentăm în tabelul de mai jos: În varianta DeMarco În varianta Gane & Sarson Pas 1. Construirea modelului fizic curent Pas 2. Construirea modelului logic curent pe baza modelului fizic anterior Pas 3. - Construirea modelului logic al noului sistem ; - Crearea unei specificaţii struc-turate constând din DFD, dicţionar de date şi specificaţii ale proceselor

Pas 1. Construirea modelului logic curent Pas 2. - Construirea modelului logic al noului sistem - Crearea unei specificaţii struc-turate constând din DFD, dicţionar de date şi specificaţii ale proceselor - Construirea unui model al datelor logice, prin exprimarea conţinutului datelor stocate în cea de-a treia formă normalizată

Pas 4. Crearea unei familii de modele fizice noi Pas 5. Costul realizării şi timpul estimat pentru fiecare model Pas 6. Selectarea unui model Pas 7. Gruparea specificaţiilor pe subsisteme

Pas 3. Proiectarea unei baze de date fizice Pas 4. Crearea unui model fizic al sistemului Pas 5. Gruparea specificaţiilor pe subsisteme

În afară de aspectele tehnice ce privesc modul de construire a DFD, există şi unele cerinţe logice referitoare la DFD, cum ar fi: completitudinea (de exemplu să nu existe fluxuri care nu duc nicăieri sau procese fără ieşiri, etc), consistenţa (compatibilitatea între reprezentări la nivele diferite), reprezentarea timpului (prin periodicităţi, termene, simultaneităţi, etc.), dezvoltarea iterativă, primitivele DFD (diagramele care după opinia proiectantului nu mai necesită a fi descompuse). Aşa cum s-a putut deduce din cele de mai sus, subetapa de modelare a proceselor nu se limitează numai la elaborarea DFD. b) Modelarea logicii proceselor. Deoarece DFD nu reliefează şi logica internă a proceselor, este nevoie să se recurgă la alte tehnici care să descrie logica proceselor într-o manieră care să permită conversia ei în programe prin intermediul limbajelor de programare. Modelarea logică se va concretiza în următoarele elemente ale documentaţiei: - reprezentarea în engleza structurată a logicii proceselor: se folosesc secvenţe de verbe care sunt folosite şi în limbajele de programare ca READ, WRITE, PRINT, SORT, MOVE, ADD, SUBSTRACT, MULTIPLY, DIVIDE, MERGE, combinate cu substantive

26

ca ADRESA_CLIENT, NUME, PATRON, toate axate pe structurile de control ale programării cum ar fi:IF, DO_UNTIL, DO_WHILE, CASE. De exemplu: DO READ Articole fişier STOCURI

BEGIN IF IF CANT<MINIM_COMANDĂ THEN GENERATE comandă nouă ELSE DO nimic END IF

UNTIL End-Of-File - reprezentarea logicii proceselor prin tabele de decizie: la mai mult de trei IF-uri imbricate, engleza structurată devine greoaie. În acest caz se recurge la tabele de decizie. Tabelele de decizie trebuie să conţină toate variantele posibil de luat în calcul pentru orice condiţie sau factor ce influenţează decizia, iar rezultatele se specifică pentru fiecare combinaţie de variante. Teoretic, tabelul ar trebui să coţină condiţiile enumerate - pe verticală, iar pe orizontală să aibă atâtea coloane câte combinaţii sunt posibile. Aşa de exemplu, pentru 3 condiţii fiecare cu răspuns posibil DA sau NU, ar trebui să existe 23

- reprezentarea logicii proceselor prin arbori de decizie: arborii de decizie sunt o reprezentare grafică a tabelelor de decizie; se reprezintă sub formă de evantai soluţiile posibile la primul criteriu, apoi pentru fiecare variantă posibilă la primul criteriu, se adaugă câte un evantai cu soluţiile posibile la al doilea criteriu. Procedura continuă prin adăugarea la fiecare vârf al arborelui a câte unui evantai cu soluţiile posibile la următorul criteriu. În final, pe fiecare terminal al arborelui, în funcţie de combinaţia de răspunsuri la fiecare criteriu realizată pe ramura care duce la terminal, se va specifica o decizie. De exemplu, în combinaţia de conturi activ/pasiv cu sporire/reducere se vor lua deciziile se debitează (pentru combinaţia activ cu sporire şi respectiv pasiv cu reducere) sau se creditează (pentru combinaţia activ cu reducere şi respectiv pasiv cu sporire).

coloane. Practic unele din acestea pot fi eliminate dacă se pot anticipa combinaţiile care, în contextul dat al problemei nu au sens.

- tabelul sau diagrama stărilor de tranziţie se foloseşte pentru a surprinde factorul timp. În cazul obiectelor starea constă în totalitatea proprietăţilor obiectului, combinată cu valoarea acestora . În cadrul acestor diagrame există simboluri speciale pentru stare (un dreptunghi), tranziţie (o săgeată), evenimentul/condiţia care declanşează tranziţia de la o stare la alta (o etichetă ataşată săgeţii de tranziţie, precedată de litera C, adică o condiţie), pentru acţiunile demarate la înregistrarea unei stări (listă de instrucţiuni scrise în pseudocod sau engleză structurată, precedate de regulă de litera A, adică acţiune). Prezentăm mai jos un exemplu de diagramă de stare [1] pentru prelucrarea liniilor dintr-o comandă şi calculul în final al totalului pe comandă.

27

1. ASTEPTARE PENTRU O C3: Linie eronată NOUĂ LINIE DIN COMANDĂ A: Semnalare LINIE ERONATĂ

C1: Linie completă C2: Linie validă A: Trecere în VALIDARE LINIE A: Deplasare pe LINIE NOUĂ 2. VALIDARE LINIE din COMANDĂ C4: Utilizatorul selectează "COMPLETĂ" A: Stabileşte TOTAL pe COMANDĂ C5:TOTAL COMANDĂ A; Trecere la CONFIRMARE 3. TOTALIZARE COMANDĂ Pentru construirea diagramelor de stare există două căi: - se stabilesc toate stările posibile ale sistemului şi se evidenţiază legăturile dintre ele; - se începe cu prima stare şi apoi se analizează ce stări au legătură cu ea şi se continuă analiza conexiunilor posibile ale fiecărei stări noi cu altele. O stare poate fi legată de una sau mai multe stări (dreptunghiuri). În construirea diagramelor de stare se recomandă: - să se ia în consideraţie reacţiilor sistemului la evenimente neprevăzute; - să se verifice dacă: - au fost surprinse toate stările; - toate stările sunt realizabile; - se poate ieşi din toate stările cu excepţia celei finale;

- răspunsurile sistemului sunt cele corespunzătoare pentru toate evenimentele posibile. Într-un tabel de stări de tranziţie fiecare linie reprezintă o stare şi fiecare coloană reprezintă un eveniment posibil. Casetele aflate la intersecţia dintre o linie şi o coloană se vor completa după caz cu: - numărul noii stări; - remarca "eveniment ignorat"; - "imposibil". Se recomandă folosirea împreună a tabelelor şi a diagramelor de tranziţie.

28

c) Modelarea conceptuală a datelor Dată fiind importanţa datelor din sistem, centrul de greutate s-a mutat cu timpul de pe procese, pe date, dar cum nici procesul nu poate fi ignorat şi mai ales evenimentul care declanşează procesele, se pare că soluţia cea mai apropiată de realitate o reprezintă obiectele. Indiferent de metoda de abordare aleasă, analiza datelor trebuie să se facă înainte de proiectarea programelor, iar proiectarea datelor trebuie să se facă la nivel de intreprindere, chiar dacă pentru moment se întenţionează o automatizare parţială a prelucrării datelor. Preocupările noastre în legătură cu datele trebuie să se manifeste pe două direcţii: 1) asigurarea datelor necesare şi relevante şi 2) folosirea lor pe toate direcţiile (pentru obţinerea de documente, rapoarte, pentru analize de tip Ce facem dacă, pentru sprijin decizional, căutări de informaţii, control şi auditare întreprindere). Structura logică a datelor trebuie să fie independentă de modul cum sunt folosite, de structura lor fizică şi de distribuţia lor. Aceste cerinţe ale ingineriei informaţiei ca şi altele, pe care nu le-am amintit aici sunt respectate în metoda Merise prin modul cum a fost conceput ciclul de viaţă al acestei metode, a cărui etapă de analiză ( prezentă prin modelare globală, conceptuală şi organizaţională) a fost analizată în capitolul precedent. Datele se reprezintă în etapa de analiză la nivel conceptual, adică sub formă de entităţi, cu atributele care le caracterizează, iar relaţiile dintre ele sunt reprezentate prin intermediul diagramelor entitate-relaţie (DER). Trebuie subliniat că termenul entitate-relaţie vine de la Entity_Relationship şi trebuie interpretat ca legătură între entităţi şi nu, cum greşit s-ar putea interpreta ca legătură dintre entitate şi relaţie (relation) în sens de tabel. Modelul se crează iterativ, pornind de la nivel intreprindere. Pe timpul modelării conceptuale a datelor se produc şi se analizează cel puţin două diagrame DER (de relaţii între entităţi): - una privitoare la datele necesare aplicaţiei; - una pentru întreaga bază de date din care aplicaţia curentă îşi extrage datele necesare. Dacă aplicaţia se construieşte pe o variantă existentă, atunci mai trebuie o diagramă pentru aplicaţia ce va fi înlocuită, iar diagrama la nivelul întregii baze de date se va referi la baza de date existentă. Pentru a construi diagramele DER, trebuie mai întâi să identificăm entităţile folosite în sistemul informaţional analizat şi atributele lor, iar apoi să identificăm relaţiile dintre entităţi. Această acţiune începe cu analiza listei documentelor de intrare şi de ieşire, din care se extrag operanzii primari (pe baza algoritmilor de calcul) şi continuă cu întocmirea bazei de atribute – un tabel cu o structură ca următoarea: Nr. crt.

Tipuri atribute Intrări Ieşiri Tipuri de entităţi şi algoritmi de calcul

Den. atribut

Tip, lungime

Cp D1 … D9 S1 S2 … S13 E1 E2 … E13

29

La intersecţia atributului cu o entitate, dacă este atribut al entităţii respective se trece o steluţă. În acest tabel Cp înseamnă cheie primară . În continuare se întocmeşte matricea dependenţelor (un tabel cu toate atributele dispuse pe verticală, iar pe orizontală numai numărul curent al fiecărui atribut, iar la intersecţie se marchează legăturile dintre atribute cu steluţe) şi apoi se pot întocmi diagramele de tip DER. În final se poate întocmi modelul conceptual al datelor - un tabel cu structura de mai jos, unde unei entităţi din prima coloană îi pot corespunde în coloanele următoare mai multe rânduri; de fapt, trebuie enumerate toate atributele entităţii. În exemplul de mai jos se văd atributele entităţii clienţi (identificatorul - CLIENTI şi apoi proprietăţile: nr. ID, tipul ID, seria, numele clientului, ţara, organ emitent, data emiterii; la fiecare proprietate se specifică denumirea proprietăţii, natură, lungime): Descrierea tipurilor de entităţi Descrierea tipurilor de relaţii Tip entitate Tip proprietate Tip relaţie Tip propriet. Cardina

-litate Colecţie

Identificator Den., natură, lungime

Identificator Den., natură, lungime

clienti CLIENTI

Nr. ID, N,7 Tip ID, C,2 seria ID, C,2 nume client, C,40 ţara, C,20 organ emit C,40 data emit D,8

realizează - 0,n 1,1

CLIENTI TRANZ

foloseşte - 1,1 1,n

TRANZ VALUTE

În diagramele DER entităţile sunt reprezentate prin dreptunghiuri, iar numele lor este bine să fie dat la singular (CLIENT, PRODUS, SALARIAT, STOC, FURNIZOR, FACTURĂ, etc.). După ce se identifică entităţile se continuă cu împerecherea lor. Trebuie ţinut seamă de faptul că întotdeauna relaţiile de tip multe-la-multe se pot descompune în două relaţii de tipul unu-la multe. Pentru aceasta se va apela la o entitate cum ar fi linie_factură, adică la entităţi care să ducă la individualizarea entităţilor implicate iniţial în relaţii de tip multe-la-multe. Nu facem aici referiri la instanţe, atribute, chei, cardinalitate, etc. deoarece acestea fac obiectul disciplinei Baze de date, dar vom preciza doar că există şi entităţi care se nasc din relaţii dintre două entităţi, fără a cădea în poziţia de entităţi nepurtătoare de informaţii; este cazul entităţilor gerundive (asociative), cum ar fi entitatea PROMOVARE care se naşte din relaţia STUDENT-CURS şi are atributul Data_promovării. Astfel de entităţi se marchează cu un romb introdus într-un dreptunghi ca în figura de pe pagina următoare. Exemplu: Data_promovării STUDENT PROMOVARE CURS

30

Cerculeţul din entităţile STUDENT şi CURS arată faptul că relaţia dintre aceste entităţi este opţională, adică se admite şi valoarea NULL. De exemplu studentul nu a promovat cursul şi nu se poate pune acolo o dată a promovării. Reciproca acestei situaţii o reprezintă relaţia obligatorie, aceea în care o entitate nu poate exista cu o valoare nulă la atributul care face legătura cu altă entitate. De exemplu nu putem avea o realizare la entitatea vânzări care în câmpul cod_obiect să ia valoarea NULL. În acest caz, la reprezentarea entităţilor se folosesc cerculeţe umplute cu negru. Mai există relaţii alternative şi relaţia unei entităţi cu ea însăşi (self Joint); de exemplu o marfă (MARFA) este provenită din PRODUCŢIE PROPRIE sau de la un producător extern (ALTUL). Reprezentarea acestei relaţii se face astfel: ALTUL MARFA PRODUCŢIE PROPRIE O relaţie cu ea însăşi poate prezenta entitatea ANGAJAT pentru a consemna numele şefului, care evident este şi el un angajat. Aceste relaţii se reprezintă astfel:

ANGAJAT raportează la

Dacă nişte entităţi sunt de fapt subdiviziuni ale unei entităţi, atunci ele sunt subtipuri ale entităţii devenite astfel supertip. Astfel de situaţii se pot repre- zenta ca mai jos: STUDENT BURSIER NEBURSIER CU_TAXĂ ABSOLVENT

Relaţia dintre entităţi se poate scrie pe săgeata de legătură sub forma unei acţiuni sau în cazul celeilate entităţi, sub forma pasivă a unui verb: de exemplu pentru relaţia FURNIZOR – PRODUS se poate folosi oferă şi respectiv este cumpărat de la. În notaţia Chen se foloseşte un singur verb inclus într-un romb:

FURNIZOR livrează PRODUS O alternativa la relaţia 1 la M este săgeata cu un capăt simplu şi unul dublu:

coordonato

M

31

CALCULATOR

Cumpărare Sesiune_ lucru Intreţinere Reparaţii periodică Casare 2.4 Definirea documentaţiei analizei sistemului informaţional Schematic, structura acestei documentaţii, precum şi corelaţia dintre componentele sale este dată pe pagina următoare. Această documentaţie, pe lângă faptul că prezintă rezultatele analizei efectuate şi datele referitoare la volumul prelucrărilor ce au loc în sistemul informaţional analizat, trebuie să permită formularea de aprecieri critice şi să furnizeze etapei de proiectare generală unele elemente cantitative şi calitative necesare conceperii ansamblului noului sistem. Dăm în continuare câteva explicaţii referitoare la principalele blocuri din această schemă. 2.4.1 Studiul componentelor sistemului informaţional existent Acest studiu vizează: - studiul structurii organizatorice; - studiul activităţilor ce se desfăşoară în sistemul informaţional existent, în special cele prin care se realizează: - previziunea; - cercetarea ştiinţifică şi dezvoltarea tehnologică; - introducerea progresului tehnic; - investiţiile; - programarea, lansarea şi urmărirea producţiei; - întreţinerea şi repararea mijloacelor fixe;

- gospodărirea resurselor materiale, a mijloacelor fixe şi aprovizionarea tehnico-materială;

- controlul tehnic de calitate; - comerţul interior şi exterior;

Diagramele istoricului vieţii, sunt diagrame care pot reflecta operaţii de modificare, înserare sau ştergere a unei realizări dintr-o entitate. Ele folosesc pătrate pentru inserare, cercuri pentru modificare şi triunghiuri pentru ştergere, ca în exemplul alăturat referitor la entitatea CALCULATOR.

32

CADRUL LEGISLATIV ORGANIGRAMA NORMATIV CARE STRUCTURII REGLEMENTEAZĂ ORGANIZATORICE ACTIVITATEA UNITĂŢII STUDIATE. ACTIVITĂŢI ŞI MIJLOACE DE CALCUL

SISTEMUL DE DOCU- ORGANIGRAMA MENTE UTILIZAT FLUXULUI ÎN UNITATEA INFORMATIONAL BENEFICIARĂ DESCRIEREA DOCUMENTELOR DESCRIEREA CODURILOR UTILIZATE.

EVALUAREA CRITICĂ VARIANTE DE A SISTEMULUI REALIZARE A

INFORMATIONAL SISTEMULUI INFORMATIC.

- transportul intern (uzinal);

- activitatea financiar-contabilă; - problemele de personal; - studiul deciziilor economico-financiare;

- DESCRIEREA CODURILOR UTILIZATE - BAZA DE ATRIBUTE - MATRICEA DEPENDENŢELOR - MODELUL CONCEPTUAL AL DATELOR, DFD ªI DER.

33

- studiul dotării cu tehnică de calcul; - studiul fluxurilor informaţionale; - studiul volumului datelor din sistemul informaţional; - descrierea codurilor utilizate; - studiul costurilor de funcţionare a sistemului informaţional. 2.4.2 Reguli pentru întocmirea schemelor de flux informaţional Aceste reguli pot fi urmărite mai uşor pe exemplul de schemă de flux de pe pagina următoare. Ele sunt următoarele: - o schemă nu tratează toate fluxurile informaţionale în detaliu, ci numai principalele fluxuri specifice ale subdomeniului analizat; - conducerea unităţii este întotdeauna poziţionată în dreptunghiul de deasupra dreptunghiului central din schema de flux informaţional; - dreptunghiul din centrul schemei conţine compartimentul (direcţia/serviciul) care, prin funcţiunile îndeplinite este cel mai implicat în subdomeniul de activitate; - în partea stângă a schemei sunt evidenţiaţi agenţii externi unităţii, cu care compartimentul respectiv are conexiuni informaţionale – primire sau furnizare de informaţii – sub diferite forme (documente, mesaje, etc.); - în partea dreaptă sunt evidenţiate compartimentele din unitatea economică cu care compartimentul cooperează în cadrul subdomeniului analizat prin primirea/furnizarea de informaţii pe diferiţi suporţi informaţionali; - fluxurile informaţionale sunt notate prin mnemonice şi linii de legătură; - intrările în compartimentul central sunt precizate prin mnemonicele poziţionate deasupra liniei de legătură şi alipite furnizorului de la care provin; - ieşirile din compartimentul central sunt precizate prin mnemonicele poziţionate sub linia de legătură şi alipite agentului/compartimentului de destinaţie; - sub compartimentul din centrul schemei sunt menţionate principalele sale funcţiuni şi colecţii de date necesare pentru realizarea acestor funcţiuni; - în subsolul schemei, în legendă, sunt precizate semnificaţiile mnemonicelor. Se recomandă ca mnemonicele să fie scrise în ordine alfabetică, pentru o identificare rapidă a documentelor specificate în schemele de flux informaţional ale intreprinderii.

34

Schema de flux informaţional pentru domeniul FINANCIAR-CONTABIL MINISTERUL CONDUCEREA UNITĂ- PRODUCŢIE FINANŢELOR ŢII ECONOMICE SERVICIUL COMERCIAL FINANCIAR- BĂNCILE CONTABIL CERCETARE DEZVOLTARE PERSONAL ADMINIS-

TRATIV

CMG, BM SPS, INS

FA, FD FSP, BAM SPS PI API, SPS FP, ECM SPS

FUNCŢIUNI

- elaborarea bugetului de venituri şi cheltuieli; - calculul statelor de plată; - întocmirea fişelor postcalcul; - calcul indicatori; - evidenţă contracte-comenzi;

COLECŢII DE DATE: - comenzi/contracte; - state de plată; - fişe de post calcul; - evidenţă facturi; - nomenclator beneficiari/furnizori; - conturi.

LEGENDĂ: ADP - aprobări dispoziţii de plată; ARF - aprobări pentru alocare resurse financiare; API - aprobări proiecte investiţii; BM - bonuri de materiale; BAM - balanţa analitică a valorii mate- rialelor dintr-o anumită perioadă; CMG - calcul manoperă globală; CC - comenzi/contracte; DP - dispoziţii de plată; DD - dispoziţii decizii; ECM - evidenţă certificate medicale; ESB - estimări de buget; INS - indicatori sintetici; FA - fişe de urmărire operativă a apro- vizionării; FD - fişe de urmărire operativă a des- facerii; FCT - facturi înregistrate; FP - fişă personal; FSP - fişă de stabilire a preţului pentru produse finite şi semifabricate; FPC - fişă de postcalcul; LAN - legi şi acte normative; PI - proiecte investiţii; SPS - state de plată salariaţi; SI/SE - situaţii intrări/ieşiri de materiale/produse într-o perioadă; SRT - somări pentru nerespectarea termenului de plată.

35

2.4.3 Evaluarea critică a sistemului informaţional existent Aceasta presupune: - evaluarea critică a obiectivelor pe care conducerea actuală le impune sistemului informaţional existent pentru ca acesta să o ajute în îndeplinirea prerogativelor sale:

- modul de interconectare a sistemului informaţional la cerinţele econo- miei de piaţă; - lărgirea competenţelor şi a delegărilor de atribuţii pe toate treptele acti-vităţii de conducere;

- încadrarea în prevederile legislaţiei economico-financiare; - evaluarea critică a mijloacelor tehnice de calcul; - evaluarea critică a personalului folosit; - evaluarea critică a costurilor ocazionate de funcţionarea sistemului infor-maţional . 2.4.4 Elaborarea variantelor de realizare a sistemului informatic Se parcurg următoarele faze: a) Stabilirea funcţiilor, cerinţelor şi restricţiilor viitorului sistem informatic; b) Definirea soluţiei globale de principiu pentru prelucrarea automată a datelor. Se studiază soluţiile tehnice de principiu referitoare la: - posibilităţile financiare ale agentului economic de a dispune de echipamente de culegere, transmitere şi prelucrarea datelor (proprietate proprie sau închiriere); - felul calculatoarelor (mari, medii, mini sau P.C.) şi modul lor de exploatare (independente sau în reţea); - tipuri de sisteme de operare; - felul produselor program folosite (specifice sau generalizabile); - suporturi de date folosite (benzi magnetice, discuri magnetice, terminale video, introducerea datelor şi redarea rezultatelor prelucrării prin viu grai, afişarea rezultatelor la imprimantă sau pe ecran, etc.); - modul de organizare a datelor (fişiere clasice independente, fişiere integrate, baze de date comune gestionate cu SGBD, baze de date distribuite local sau la distanţă, baze de cunoştinţe, etc.); - tipuri de prelucrare a datelor (în loturi, interactivă, centralizată fără teleprelucrare, centralizată cu teleprelucrare distribuită local sau la distanţă); c) Evaluarea costurilor fiecărei variante de realizare a noului sistem: - costul proiectării şi realizării sistemului informatic, plus costul exploatării curente; - evaluarea efectelor economice rezultate ca urmare a aplicării fiecărei variante; - evaluarea modificărilor organizatorice în unitatea studiată; - evaluarea posibilităţilor de realizare a fiecărei variante; - evaluarea termenelor de realizare.

36

2.5 Metode moderne de determinare a cerinţelor sistemului [1] 2.5.1 Joint Application Design (JAD) Ideea principală JAD o constituie punerea laolaltă a tuturor forţelor interesate în dezvoltarea sistemelor: utilizatorii-cheie, managerii şi analiştii de sisteme implicaţi în analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel grup, dar sesiunile JAD urmează o anumită secvenţă de derulare a activităţilor pe baza unor roluri bine definite. Ele se desfăşoară în locuri diferite de cele unde lucrează personalul antrenat în ele, pentru a-l rupe de sarcinile curente. Participanţii la sesiunile JAD sunt : - Conducătorul sesiunii JAD (leader-ul), un bun specialist în analiza sistemelor şi în managementul grupurilor. El stabileşte şi urmăreşte respectarea agendei de lucru, adoptând o poziţie neutră şi rezolvând eventualele conflicte şi dezacorduri, stimulând în acelaşi timp emiterea tuturor ideilor posibile; - Utilizatorii, cei care cunosc foarte bine sistemul informaţional al intreprinderii; - Managerii, de regulă şefii de compartimente sau domenii de activitate, care cunosc direcţiile de dezvoltare, elementele de motivare şi sunt implicaţi direct în determinarea cerinţelor sistemului; - Sponsorul. El participă doar la şedinţele unde se discută proporţia investiţiei; - Analistul de sistem. El/ei trebuie să vină la şedinţe cu un set de notiţe despre sistemul discutat, să afle cât mai multe lucruri de la utilizatori şi manageri şi să-şi revizuiască pe această bază notiţele; ei nu trebuie să-şi exprime punctul de vedere; Pe parcursul şedinţelor ei trebuie să fie capabili să prezinte machetele de ecran ale sistemului curent, a rapoartelor şi procedurilor de obţinere a lor în sistemul curent şi în final să prezinte sinteza problemelor discutate. Mai trebuie să răspundă la întrebările apărute în timpul sesiunii şi să prezinte machetele rapoartelor, formularelor şi ecranelor viitorului sistem; trebuie să răspundă la întrebările utilizatorilor şi managerilor pe această temă şi să consemneze părerile formulate despre sistemul propus. - Scribul, persoana care va nota totul în timpul sesiunilor JAD, prin intermediul unui calculator sau laptop. Se pot folosi procesoare de texte sau o serie de instrumente CASE speciale; - Informaticienii. În afară de analiştii de sisteme, participă programatori, analiştii de baze de date, planificatorii de sisteme informaţionale, precum şi personalul implicat în alte operaţiuni de prelucrare a datelor. Ei vin să afle părerile utilizatorilor şi managerilor şi dacă este cazul, să ajute la definitivarea studiului de fezabilitate tehnică. Sesiumile JAD se ţin, de regulă, în săli speciale sub formă de potcoavă. Este bine să se dispună acolo de mijloace de reprezentare la dimensiuni mari cum ar fi flip-chart sau table albe (eventual magnetice sau electronice), ce pot fi scanate sau filmate cu camere digitale şi tipărite la imprimantă sau reproiectate pe videoproiectoare, pentru a permite revenirea asupra unor momente ale discuţiei sau modificarea unor soluţii.

37

Când sesiunea JAD este încheiată, analiştii vor fi în posesia unui set de documente referitoare la activităţile din sistemul curent care au legătură cu studiul noului sistem. Acest set trebuie să ofere o imagine asupra a ceea ce există în unitate şi mai ales asupra a ceea ce se intenţionează a se realiza. În perioada cât se ţine sesiunea JAD (între 4 ore şi o săpămână), se pot organiza întâlniri informale, în special la sfârşitul zilei, pentru a se comenta rezultatele înregistrate. După terminarea sesiunii JAD, leaderul va prezenta un raport final care va fi înaintat tuturor participanţilor. 2.5.2 Sistemele de sprijinire a grupurilor Unul din dezavantajele sesiunilor JAD îl constituie numărul mare de participanţi şi de aici, diversitatea părerilor afişate într-un timp limitat. În pofida timpului limitat acordat unei persoane, unii ar putea încerca să domine şedinţa în timp ce alţii nu vor apuca să spună nimic sau vor evita să vorbească pentru a nu-şi contrazice şefii. Sistemele de sprijinire a grupurilor vin să remedieze aceste inconveniente. În cadrul acestor sisteme, pentru a-i acorda fiecărui membru al grupului şansa de a-şi exprima părerea, el este solicitat să introducă în calculator, sub anonimat, tot ceea ce crede despre problema discutată. O alternativă la această metodă este culegerea opiniilor nu de la câte un singur expert, ci de la grupuri de experţi. Rezultatele acestei metode au fost excelente. 2.5.3 Prototipizarea şi determinarea cerinţelor sistemului Prototipizarea este un proces iterativ prin care analiştii şi utilizatorii pun în discuţie o versiune rudimentară a unui sistem informaţional, care va fi într-o continuă schimbare, în funcţie de reacţia utilizatorilor. Prototipizarea conduce la renunţarea la ciclul de viaţă al dezvoltării sistemelor sau la creşterea rolului său. Pentru culegerea informaţiilor despre cerinţele utilizatorilor încă se apelează la interviuri, dar operaţiunea va fi mai simplă şi va solicita un timp mai scurt. Se creează imediat un prototip care va fi văzut şi testat de utilizator, acesta având posibilitatea să precizeze ce ar mai dori, dar exprimându-se direct, cu ajutorul specialiştilor, în structura şi aspectul prototipului. Prototipizarea este facilitată de câteva limbaje sau produse program din generaţia a patra, inclusiv de CASE. Etapele prototipizării pot fi exprimate grafic ca în figura următoare [1]:

38

Prototipizarea are şi câteva deficienţe cum ar fi: - tendinţa de evitare a unui cadru formal de elaborare a documentaţiei privind cerinţele sistemului, ceea ce va îngreuia mai târziu orice control; - fiind conceput în colaborare cu un grup nesemnificativ de utilizatori, există riscul să fie respins ulterior de viitorii utilizatori; - fiind conceput izolat, este posibil să se întâmpine greutăţi la integrarea lui în sistemul existent; - există riscul să fie omise aspecte esenţiale, cum ar fi securitatea informaţiilor, controlul datelor introduse, standardizarea la nivel sistem şi altele. Prototipizarea nu este recomandată în cazul sistemelor mari sau al celor complexe şi nici pentru aplicaţiile contabile din domeniile standard, cum sunt creanţe, plăţi sau gestiune stocuri.

Identificarea cerinţelor principale

ale utilizatorului Realizarea rapidă a unui prototip Prototipul este încredinţat utilizatorului în vederea testării Obţinerea reacţiilor utilizatorului Modificarea prototipului, dacă este cazul În caz de Prototip abandonat: Dezvoltare în continuare a prototipului:

se continuă cu paşii: - trecerea la realizarea sistemului pe baza metodologiei - completarea lui; ciclului de viaţă al acestora - documentare - renunţarea la prototip - ataşarea la sistemul existent

39

2.5.4 Rapid Application Development (RAD) este o metodologie de realizare a sistemelor informatice care promite sisteme mai bune, mai ieftine şi realizate rapid. RAD foloseşte doar patru etape din ciclul de viaţă al sistemelor şi anume: planificarea cerinţelor, proiectul utilizatorului, construirea şi fasonarea sistemului (cutover). De fapt, proiectul utilizatorului combină analiza cu proiectarea logică şi fizică din CVDS. Diferenţa majoră între RAD şi JAD constă în faptul că prototipul devine elementul fundamental al noului sistem - ecranele afişate în timpul prototipizării devin ecrane ale sistemului şi nu modele ale unui sistem posibil. Suportul central este oferit de instrumente integrate CASE, în care sunt incluse şi generatoarele de coduri ale programelor. Este de asemenea încurajată în JAD reutilizarea unor componente. Reuşita acestei metode depinde de instrumentele folosite, personalul de care dispunem, managementul şi de felul concret în care se aplică metodologia. În cazul sistemelor vechi, mari, RAD se va aplica iniţial pe un proiect pilot pentru a demonstra viabilitatealui. Cu timpul celula celor implicaţi în acest proces va creşte, adăugându-se noi persoane şi proiecte până când RAD devine calea dominantă de realizare a sistemului informaţional. RAD începe cu etapa planificarea cerinţelor, când se derulează tradiţionalele activităţi de identificare şi selecţie a proiectelor, precum şi activităţi de analiză. Acordul privind forma viitorului sistem este dat de utilizatori şi analişti. În timpul proiectului utilizatorului, utilizatorul final şi informaticienii vor participa la ateliere de lucru JAD, în care cei selectaţi apelează la mijloacele de lucru CASE pentru obţinerea rapidă a prototipului proiectului sistemului. Clientul poate interveni oricând este necesar, pentru a-şi reformula cerinţele. Cu acestă metodă timpul de elaborare şi dare în funcţiune a unui proiect scade de la cca 18-24 luni, la 3-6 luni. Într-o primă etapă, eforturile utilizatorului se concentrează spre zona datelor, dar pentru aceasta trebuie ca informaticienii să dispună de interfeţe cu utilizatorul, care să-i permită acestuia să se concentreze asupra operaţiunilor de adăugare, modificare, ştergere sau interogare a datelor. Pentru ca utilizatorii să se poată concentra asupra datelor, trebuie ca modelele conceptuale ale datelor, generate în primele sesiuni JAD să se axeze pe semnificaţia şi structura datelor necesare sistemului. Următoarele sesiuni vor urmări modul în care datele necesare sunt utilizate, astfel încât să permită îndeplinirea funcţiilor aplicaţiei. Ulterior, în cadrul sesiunilor JAD se vor rezolva şi cerinţele impuse de nevoia de compatibilitate a aplicaţiei cu alte compartimente. Pentru aceste funcţii complexe vor fi dezvoltate modele ale logicii prelucrărilor sau proceselor decizionale. Prin ele se va arăta modul în care datele sunt supuse unor transformări logice, declanşate de anumite evenimente, astfel încât funcţiile să poată fi realizate. Modelele proceselor pot fi dezvoltate prin engleza structurată, diagrame ale stărilor de tranziţie sau prin alte tehnici de modelare logică. În etapa de construcţie, aceeaşi specialişti în informatică (autori ai proiectului) vor genera codurile produsului folosind instrumente CASE de acest gen, iar dacă va fi necesar - şi manuale de codificare. În această fază este vorba de asamblarea unor componente

40

realizate anterior, prin interfeţe interne care să efectueze legăturile dintre ele. Componentele nerealizabile cu instrumente automate trebuie să fie create de către membrii echipei. Utilizatorii finali participă şi în faza de construcţie, validând ecrane şi rapoarte şi confirmând alte aspecte referitoare la proiectul aplicaţiei în lucru. Membrii echipei efectuează şi lucrări de altă natură ca manuale pentru utilizatori, materiale help şi de instruire. Pentru sisteme mai mici, etapa de construcţie poate fi cumulată cu proiectul utilizatorului. Etapa de fasonare înseamnă distribuirea produsului către utilizatorul final. Cum metodologia RAD este extrem de rapidă, planificarea fasonării (implementării) trebuie să înceapă mai devreme. Ea constă în testare, instruirea utilizatorilor, urmărirea eventualelor schimbări organizaţionale, execuţia în paralel a vechiului şi noului sistem. După acestă etapă sistemul trece în regimul procesului normal de întreţinere. Avantajele RAD: - reducerea timpului de realizare a sistemelor informaţionale de 3-4 ori; - diminuarea riscului nereuşitei şi calitatea sporită a sistemului, derivate din implicarea personală a utilizatorilor şi din numeroasele teste efectuate; - sistemul răspunde de regulă, mai bine cerinţelor utilizatorilor. Dezavantajele RAD: - posibilitatea neglijării aspectelor funcţionale şi estetice ale formularelor; - o oarecare superficialitate în respectarea standardelor de programare şi a celor privitoare la documentaţie, provenite din faptul că denumirile datelor au rămas cele din etapele timpurii, ceea ce îngreuiază implementarea; - metoda îngreuiază refolosirea modulelor, în sensul că din grabă analiştii preferă să facă alte module decât să caute dacă printre modulele disponibile nu cumva există unele posibil a fi folosite pentru ce le trebuie lor; - de regulă când un sistem informatic este acceptat, odată cu trecerea timpului creşte aria şi numărul utilizatorilor, cresc pretenţiile asupra performanţelor echipamentului dar şi asupra numărului şi tipurilor de rapoarte, se extinde echipa de dezvoltare, se diversifică aspectele legate de întreţinerea sistemului şi de securitatea datelor, ori în cazul RAD aceste aspecte sunt neglijate. - serioase lacune în ce priveşte administrarea sistemului şi anume în întreţinerea şi reorganizarea bazelor de date, constituirea copiilor de siguranţă şi reconstituirea sistemului după avarii, ş.a. În pofida acestor reproşuri, RAD a înregistrat numeroase cazuri de utilizare eficientă. Bibliografie Dumitru Oprea, "Analiza şi proiectarea sistemelor informaţionale economice", Editura Polirom, Bucureşti, 1999.

1

Cursul_III_5

PROIECTAREA LOGICÃ A SISTEMELOR INFORMATICE Există trei variante de abordare a proiectării logice: - ieşiri - intrări; - intrări - ieşiri;

- mixtă. Indiferent de varianta de abordare, proiectarea logică trebuie să asigure: - fundamentarea ştiinţifică a obiectivelor noului sistem;

- definitivarea conţinutului informaţional al ieşirilor sistemului în concordanţă cu obiectivele stabilite; - determinarea bazei informaţionale necesară satisfacerii eficiente a obiectivelor propuse; - formalizarea atributelor de intrare pentru adaptarea acestora la cerinţele de prelucrare automată ale noului sistem (vezi secţiunea 7); - structurarea sistemului informatic în subsisteme şi aplicaţii în scopul realizării eşalonate a acestuia.

Proiectarea logică începe cu definirea obiectivelor sistemului informatic şi se încheie cu proiectarea structurală şi funcţională a sistemului informatic. Între aceste repere, proiectarea logică se desfăşoară pe parcursul a trei subfaze sau paşi: - proiectarea formularelor/formatelor (folosite la preluarea datelor) şi proiectarea rapoartelor (folosite pentru extragerea şi punerea în pagină sau pe ecran a datelor cuprinse în rapoarte); - proiectarea interfeţelor şi a dialogurilor (folosite la comunicarea utilizatorului cu programul activ); - proiectarea bazelor de date (modelul logic/relaţional al datelor) În general se pleacă de la diagramele entitate-relaţie, la care se vor adăuga datele descoperite în timpul proiectării logice. În această acţiune trebuie să luăm în consideraţie evenimentele din diagramele de acţiuni, ce declanşează acţiunile utilizatorului. Să reţinem că subfazele enumerate mai sus nu se parcurg secvenţial şi o singură dată ci avem de a face cu un proces în spirală, care se repetă până ce toate prelucrările îşi găsesc locul cuvenit. La sfârşitul acestei faze vom şti precis tipul de sistem electronic de calcul folosit în sistemul informatic, precum şi soluţia de gestiune a datelor (BD locală, centrală, sau mixtă, gestionată prin SGBD sau EXCEL, etc.) 1. Definirea obiectivelor sistemului informatic a) obiective generale: - de conducere: - rentabilizarea permanentă a activităţii economice;

- realizarea globală şi structurală a indicatorilor economico-financiari, calculul şi planificarea rezultatelor, planificarea financiară a investiţiilor, previzionarea activelor circulante, şi a surselor de finanţare, previziunea activităţii de trezorerie, inclusiv utilizarea bugetului general al unităţii economice; - perfecţionarea activităţii de conducere în vederea asigurării unui optim global la nivelul întregii activităţi economice; - fundamentarea deciziilor de conducere tactică, strategică şi

2

operativă pe baza informaţiilor obţinute ca urmare a prelucrărilor sistemului informativ; - asigurarea unei coordonări a întregului sistem informaţional-decizional; - utilizarea selectivă a unor informaţii de excepţie (rata anuală de înnoire a mijloacelor fixe, tendinţele preţurilor de aprovizionare, etc.), pentru asigurarea unei gestiuni eficiente a patrimoniului net pe baza unor informaţii cu caracter programatic şi analitic; - degrevarea conducerii de procesele decizionale de rutină, formalizarea prin noul sistem a informaţiilor sintetice necesare derulării relaţiilor informaţionale cu organismele de stat şi cu alte regii autonome sau societăţi comerciale; - furnizarea într-o formă adecvată, eficientă şi facilă a informaţiilor globale necesare conducerii unităţii economice, sub forma unor indicatori globali, situaţii cu caracter sintetic, grafice, etc. care trebuie să conţină date relevante, prin intermediul afişării la videoterminal; - creşterea calităţii procesului decizional prin abordarea sistemică a activităţii unităţii economice şi utilizarea modelării matematice, adaptate sistemelor electronice de calcul; - extinderea principiului conducerii prin excepţie şi pe bază de obiective.

- obiective funcţionale pentru: - activitatea comercială; - aprovizionare tehnico-materială; - desfacere a produselor/rezultatelor activităţii; - marketing ; -activitatea financiar-contabilă:

- subactivitatea financiară (impozite, buget, relaţii băneşti, decontări);

- contabilitate: - contabilitate financiară (sintetică); - contabilitate şi gestiunea (analitică); - control financiar; - activitatea de personal: - evidenţa personalului; - salarizare; - perfecţionarea calificării personalului. b) obiective specifice: - obiectivele specifice activităţii de bază. Ele trebuie să urmărească:

- utilizarea eficientă a capacităţilor de producţie; - introducerea de tehnologii şi produse noi la nivelul tehnicii actuale; - realizarea ritmică şi de calitate a lucrărilor de investiţii; - modernizarea utilajelor şi a altor factori de producţie; - îmbunătăţirea continuă a calităţii producţei; - creşterea gradului de utilizare a capacităţilor de producţie; - încadrarea consumurilor de materiale în normele tehnologice; - utilizarea raţională a capacităţilor de depozitare, a materialelor şi produselor.

- obiectivele specifice activităţii auxiliare: au un caracter particular, o pondere şi o importanţă diferenţiată de la un agent economic la altul.

3

2. Proiectarea formularelor/formatelor şi a rapoartelor Să observăm că deocamdată ne referim la formulare sau rapoarte existente în sistemul manual sau la machete de ecran. a) Formularele au în structură patru elemente: introducerea, instrucţiunile, partea principală şi concluziile. - introducerea conţine titlul, numărul formularului, numele şi adresa destinatarului; - instrucţiunile vizează modul de completare a formularului şi destinaţia lui după completare; - partea principală conţine viitoarele căsuţe de text, deocamdată doar în machetă, grupate logic după înţeles, după momentul sau locul completării datelor; - concluziile apar la sfârşit şi se referă la înregistrarea informaţiilor cu privire la dispoziţiile finale şi/sau aprobările necesare în legătură cu operaţiile consemnate, incluzând semnăturile şi data. Pe formularele cu operaţiuni financiare va fi marcat locul totalului formularului. Alte elemente de luat în calcul la proiectarea unui formular: tipul de hârtie, formele şi culorile caracterelor folosite în diferite zone ale formularului care trebuie concepute conform standardelor în vigoare, adresa care să fie vizibilă şi prin fereastra plicului. b) Rapoartele conţin doar date predefinite şi ca urmare pot fi considerate documente pasive. Pentru rapoarte se întocmesc modele demonstrative care trebuie să fie acceptate de beneficiar. Pentru rapoartele care ies la imprimantă este bine să se întocmească macheta imprimantei ( un formular cu 50 de linii şi 150 de coloane). Este bine să aibă pondere rapoartele grafice. În raport cu timpul rapoartele se clasifică în rapoarte programate (la termen), analize neprogramate ( rapoarte ad-hoc elaborate la întrebările managerilor), rapoarte declanşate de excepţii (au conţinut predeterminat, dar se elaborează în situaţii de excepţie: depăşiri de costuri, stocuri supradimensionate, etc.) şi rapoarte la cerere (acestea au conţinut predeterminat, dar se elaborează numai la cererea managerilor). Atât machetele formularelor cât şi cele ale rapoartelor pot fi făcute cu un editor de texte, cu o aplicaţie pentru grafică pe calculator, sau cu un program de calcul tabelar. 2.1 Specificaţie de proiectare Subfaza proiectarea formularelor/formatelor şi proiectarea rapoartelor se va încheia cu câte o specificaţie de proiectare structurată pe trei părţi: prezentarea descriptivă a ieşirii, un model al proiectului şi testarea şi evaluarea comportamentului în utilizare. Un model de specificaţie ar putea fi cel de pe pagina următoare. 2.2 Caracteristicile datelor conţinute în formate/formulare sau rapoarte. Aceste caracteristici se completează prin răspunsul la întrebarea asociată fiecărei caracteristici după cum urmează: - Tipul datei: este cel mai indicat pentru atingerea scopului propus? - Corectitudine/Precizie: datele folosite sunt suficient de precise? - Actualitatea: datele necesare se obţin la timp? - Orizontul de timp: datele aparţin orizontului de timp adecvat? - Nivelul de sintetizare: datele sunt prea sintetice sau prea detaliate? - Completitudine: datele sunt insuficiente sau excesive? - Accesibilitate: datele sunt accesibile? - Sursa: sursa este sigură? - Relevanţa/valoarea: datele vor influienţa deciziile? Beneficiile vor depăşi costurile? Forma de prezentare a datelor: date formatate, text, imagini, audio, video, hypertext. Mai trebuie precizat care date sunt interne şi care sunt externe, care se obţin on-line şi care pe

4

Help

Detalii cont Alt cont Listare Ecran precedent Ecran urmãtor

INFORMAÞII

INFORMAÞII CONT

hârtie, care se prelucrează on-line şi care se prelucrează pe loturi (documentele se acumulează şi se prelucrează la comandă ). a) Prezentarea descriptivă Formular

: Situaţia contului CLIENTI Utilizatori

: Persoanele care urmăresc contul CLIENTI

Rol

: Prezentarea informaţiilor despre clienţi: adresa, situaţia la zi a contului Sistem

: Novell Network, Microsoft Windows

Mediu de lucru

: Mediul unui birou standard

b) Modelul proiectului S.C. LEBÃDA s.r.l. SITUATIA CONTULUI CLIENTI Pagina 1 din 2

I. Data: 30–Martie-02 Cod client: 1234 Nume client: Dobrogea S.R.L. Adresa: Vârfu cu Dor, 45 Localitate: Constanţa Judeţ: Constanţa Þara: Romania Cod poştal: 8700

Vânzări la zi: 25.000.000,00 Incasări la zi: 15.000.000,00 Limita credit: 10.000.000,00 Procent reducere: 2,00 Sold la zi: 18,000,000,00

Starea: Activ

c) Testarea şi evaluarea comportamentului la utilizare Gradul de percepţie a utilizatorilor (cca. 12 utilizatori): Consistenţă ( de la 1 – consistent, la 5 – inconsistent): 1.25 Suficienţă (de la 1 – suficient, la 5 – insuficient): 1.12 Precizie (de la 1 – precis, la 5 – imprecis) 1.20

Exemplu de specificaţie de proiectare

Recomandări generale de formatare a ieşirilor - să aibă o introducere (partea de titlu) sugestivă: - prezentarea foarte clară a numelui formularului în partea superioară a paginii, central; - evidenţierea numărului şi datei; - dacă trebuie distribuit în alte locuri, care sunt acestea? - specificarea datei de emitere a ieşirii care poate să coincidă sau nu, cu data întocmirii; - dacă este cazul se va consemna ora ieşirii.

5

- informaţiile din instrucţiuni: - regulile de completare să fie clare; - să se specifice etapa ce urmează după editare;

- să se evite comentariile lungi, folosind în schimb rubrici cu nume sugestive; - să se consemneze destinaţia fiecărui exemplar al documentului/ra-portului tipărit;

- informaţiile să fie oferite fără informări manuale. - partea principală (corpul ieşirii): - să se facă o prezentare echilibrată evitându-se încărcările; - folosirea corectă a spaţierilor şi marginilor; - etichetarea corectă a rubricilor; - gruparea logică a rubricilor; - scoaterea în relief a zonelor ce marchează o altă rubrică; - accentuarea prin linii sau culori a zonelor-cheie. - Concluziile (finalul ieşirii): - să fie plasate la sfârşitul paginii; - să fie alocat suficient spaţiu pentru semnături;

- aici se vor prezenta ultimele indicaţii (cele privind regimul de lucru cu documentul/raportul); - totalurile vor fi puternic accentuate.

- Deplasarea lejeră prin document (navigarea): - de indicat în faza de editare, cum se pot efectua deplasările înainte/înapoi;

- de arătat locul unde se află utilizatorul (ex. pag. 4 din 12); - de specificat cum se poate efectua ieşirea din regimul de editare;

- în cazul în care sunt mai multe pagini, semnalarea clară a ultimei pagini; - tratarea ecranului după acelaşi regim cu documentul original (clasificarea informaţiilor d.p.d.v. a secretului şi a accesului la ele); - protejarea împotriva pierderii, modificării, sustragerii ilegale sau din greşeală a informaţiilor.

2.3 Scoaterea în evidenţă a informaţiilor - Forme de marcare a anumitor informaţii sau grupuri de informaţii aflate în interdependenţă, a totalurilor, etc: - marcaj clipitor/intermitent (blink); - marcaj sonor; - intensităţi diferite de culoare; - culori diferite (dar nu papagal!); - diferenţieri prin dimensiuni variate ale caracterelor; - diferenţieri prin fonturi; - video invers; - casete cu date grupate; - subliniere; - caractere majuscule; - tipărirea informaţiilor nestandard cu caractere diferite de celelalte. - Împrejurări ce necesită scoaterea în evidenţă a unor informaţii: - introducerea unor date eronate sau apariţia unor rezultate eronate;

- neîncadrarea datelor în anumite limite, sau starea de inoperativitate a unor echipamente; - intrarea operării într-un regim anormal: se impune semnalarea prin comenzi, cuvinte cheie, mesaje; - necesitatea afişării sau tipăririi unor rubrici de subtotal sau total, sau a unor rubrici în care se aşteaptă afişarea unei valori.

6

- existenţa în pagină a unor zone comune. - Probleme ce apar în legătură cu folosirea culorilor:

- anumite suprapuneri de culori duc la culori "spălăcite" sau culori "fantomă". - rezoluţia este diferită de la un mediu de lucru la altul; - fidelitatea culorii diferă de la un mediu la altul; tipărirea sau conversia pe alt echipament ar putea crea probleme; - culorile obosesc ochii, varianta alb-negru este mai odihnitoare, dar nu şi mai plăcută.

2.4 Recomandări privitoare la texte: - caracterele: se recomandă folosirea literelor mari şi mici, inclusiv respectarea regulilor de punctuaţie; - spaţierea: dacă este posibil, este de dorit folosirea dublei spaţieri. Dacă nu, se recomandă plasarea unei linii cu spaţii între paragrafe; - alinierea : se recomandă alinierea textului la stânga, iar la nevoie partea dreaptă poate rămâne la stilul versurilor; - liniuţa de unire: nu se recomandă ca textele de pe ecrane să conţină cuvinte despărţite în silabe de pe un rând pe altul; - abrevierile: sunt permise numai pentru cuvintele care au o recunoaştere generală. 2.5 Recomandări privitoare la tabele: Folosirea unor nume semnificative: - toate coloanele şi rândurile să aibă nume (etichete) cât mai relevante; - numele respective vor fi scoase în evidenţă faţă de celelalte prin tehnicile corespunzătoare, descrise anterior; - reafişarea numelor coloanelor sau rândurilor când datele depăşesc limitele unei pagini; - evitarea numelor lungi, a ambiguităţilor generate de sensul cuvintelor folosite; - pe cât posibil, de renunţat la despărţirea în silabe; - centrarea în cele mai multe cazuri a numelor coloanelor şi alinerea la stânga a numelor rândurilor.

Formatarea coloanelor, a rândurilor şi a textului - sortarea într-o ordine logică a datelor prezentate, după una sau două chei ascendent sau descendent; - folosirea unei linii cu spaţii după fiecare cinci rânduri atunci când există prea multe coloane; - informaţiile similare afişate în mai multe coloane trebuie să fie sortate pe verticală, întrucât ordinea lor se urmăreşte pe coloană, deci de sus în jos şi nu de la stânga la dreapta - pe linie; - între coloane să existe cel puţin două spaţii ; - de lăsat loc suficient pe rapoartele tipărite care să-i permită utilizatorului să introducă diverse adnotări; - de folosit acelaşi gen de caractere, cu excepţia cazurilor care trebuie să fie scoase în evidenţă; - de evitat excesele de fonturi fanteziste, greu de citit.

Formatarea datelor de tip numeric, alfabetic sau alfanumeric - datele numerice trebuie să fie aliniate la dreapta şi/sau pe marca zecimală, coloanele fiind astfel uşor de citit; - datele de tip text vor fi aliniate la stânga; - se recomandă folosirea liniilor scurte de text, de regulă de 30-40 de caractere, pentru o parcurgere uşoară prin citire ( ca în cazul ziarelor); - de evitat blocurile mari cu date alfanumerice; în astfel de cazuri trebuie găsite criterii de descompunere a lor în grupuri mai mici, mai uşor de citit, deci şi mai inteligibile, care să nu aibă mai mult de 3-4 caractere, gen numere auto sau de telefon

7

Elementele de bază ale unui tabel - numărul tabelului: se va atribui consecutiv, în ordinea apariţiei, pe parcursul întregului raport, sub forma numerelor arabe. Numărul se va scrie la marginea din stânga, apelând la metoda numerelor duble ( de ex. 2.3) numai în rapoartele lungi care conţin mai multe capitole, fără a se pune punct după ultimul grup de numere. Numărul şi titlul se vor plasa deasupra tabelului, iar elementele suplimentare, în zona imediat următoare sub tabel; - titlul tabelului: va fi scris la marginea stângă, la două rânduri sub număr. Prima literă a titlului şi substantivele proprii se scriu cu literă mare, celelalte se scriu cu literă mică. Dacă necesită a doua linie, ea va începe tot de la stânga, la două rânduri. Nu se pune punct după titlu. - liniile tabelului: în general tabelele au trei linii orizontale şi nici una verticală! Ultima linie va delimita conţinutul tabelului de elementele suplimentare cum ar fi sursa tabelului şi notele explicative; - alte elemente ale unui tabel: titlul cotorului, titlul coloanelor, titlul coloanelor multiple, titlul liniei, subtitlul, sursa şi notele explicative. Poziţia lor în tabel este dată în macheta următoare: (1) Numărul tabelului (2) Titlul tabelului (3) Linie____________________________________________________________ (6) Titlul coloanelor multiple (4) Titlul cotorului (5) Titlul coloanei Titlul coloanei (7) Titlul liniei (8) Subtitlu Date Date Subtitlu Date Date Titlul liniei Date Date (3) Linie____________________________________________________________ (9) Sursa: (10) Note explicative 2.6 Utilizarea graficelor în rapoarte Argumente ce pledează în favoarea graficelor în comparaţie cu tabelele: - un desen este mai sugestiv decât 1000 de cuvinte; - se prezintă o sinteză riguroasă a datelor; - marcarea celor mai importante elemente; - excepţiile sunt uşor de sesizat; - evidenţiază eventualele corelaţii dintre elemente; - se poate aprecia tendinţa în timp; - se pot efectua comparaţii multiple rapide; - se oferă şansa efectuării de prognoze; - cantităţile mari de date valorice pot fi vizualizate mai simplu cu ajutorul unui grafic. Tipuri de grafice: histogramă, histogramă cumulată, linie, diagramă de structură (Pie). Datele pot să aparţină fie unei serii discrete (de ex. populaţiile diferitelor oraşe), fie unei serii continue (date care se schimbă în timp , de ex. evoluţia populaţiei unui oraş). Totuşi, atunci când ne interesează valori individuale, tabelele sunt de neînlocuit. 2.7 Criteriile utilizatorilor de apreciere a formularelor/formatelor - stabilitatea: folosirea aceloraşi termeni, abrevieri, formate, titluri şi metode de navigare în toate ieşirile sistemului; - eficienţa: formatarea trebuie să se deruleze în strânsă concordanţă cu sarcinile de executat. Textele trebuie să fie aliniate, coloanele sortate, deplasarea să fie uşor de realizat. Pentru a

8

formula cererile de ieşire este de dorit ca pe cât este posibil să fie necesare cât mai puţine date; - comoditatea: să nu se facă trimiteri la afişări anterioare, să se folosească etichete clare, precum şi factori de scală corespunzători; - Formatul: pentru aceleaşi tipuri de informaţii, este bine să se menţină acelaşi format; de asemeni să se scoată în evidenţă ceea ce este important. Printre caracterele tipărite este bine să fie prezente la locul cuvenit, semnele monetare, mărcile zecimale, separatorii ordinelor de mărime şi semnele +, _, %, etc. - flexibilitatea: trebuie să i se ofere utilizatorului posibilitatea de a lista în modurile dorite de el, de a opri procesul şi de a naviga în locurile dorite. Satisfacţia utilizatorilor se poate rezuma la : timpul de învăţare (acomodare), viteza de execuţie, rata erorilor, persistenţa în timp (stabilitatea), satisfacţii subiective. 3. Proiectarea interfeţelor şi a dialogurilor 3.1 Rolul interfeţelor şi al dialogurilor 3.1.1 Interfeţe În Computer Technology interfaţa este definită ca un echipament sau un program conceput pentru a comunica informaţii de la un sistem de echipamente electronice sau programe la altul. În ce priveşte interfaţa utilizatorului care face obiectul acestei etape CVDS, ea este definită ca o combinaţie a mijloacelor prin care un utilizator interacţionează cu un sistem electronic de calcul. In prezent interfeţele sunt toate grafice (Graphical User Interface - GUI). Cea mai populară este cea reprezentată de Windows prin meniuri, pictograme şi mouse, dar mai există interfeţe pentru calculatoarele dotate cu creioane optice, interfeţe pentru preluarea/redarea vocii şi interfeţe multimedia, care asigură acces la text, sunet şi imagine. 3.1.2 Dialogul Dialogul este conversaţie între doi parteneri. Dialogurile se pot purta pentru simpla cooperare dintre utilizator şi calculator, dar ele fac parte şi din procesul decizional. Un sistem de sprijinire a procesului decizional are următoarele componente: managementul datelor, managementul modelelor şi managementul dialogurilor. Acesta din urmă poate fi redat schematic astfel: Module de intrare bazate pe:

• Limbaje de acţiune - tastatură - mouse - cititor optic - creion optic, etc, • Limbaje de comandă • Subset al limbajului natural • Specificaţii ale asistenţei

prin meniuri • Specificaţii de ecrane (pentru completarea spaţiilor

din rubrici) • Interfeţe tip pictograme • Activare voce

CLIENTI Numãr AI

• Afiºare tip VDT (Video Display Terminal)

• Generarea de rapoarte • Afiºarea graficã,

inclusiv color ºi tridimensional

• Desene cu plotere • Frestre multiple º.a.

9

3.2 Metode şi echipamente folosite în dialogul om-calculator 3.2.1 Metode de interacţiune - Interacţiunea prin limbaj. Se bazează pe utilizarea comenzilor. Există comenzi sintactice şi comenzi secvenţiale. Comenzile se mai pot clasifica în comenzi mnemonice şi comenzi_taste. - interacţiunea prin meniuri; se folosesc: - liste simple;

- zone cu comenzi şi linii meniu (meniuri pop-up sau drop-down); - meniuri prin imagini (pictograme).

- interacţiunea prin limbaj natural. Se află în stadiu encipient. 3.2.2 Selectarea echipamentelor necesare interacţiunii cu sistemul Se folosesc: tastatură (Keyboard), Mouse, Joystick, Trackball, Touch Screen, Light Pen, Graphics Tablet şi Voice. 3.3 Proiectarea interfeţelor 3.3.1 Proiectarea machetelor Se recomandă parcurgerea paşilor de mai jos: Paşii anteriori conceperii Paşii conceperii Paşii post-concepere Stabilirea Determinarea scopului operaţiunilor de: (Ce mesaj - completare trebuie să - citire şi acţiune transmită?) - citire şi Schiţarea reamintire documentului - aflarea de - selectarea informaţii unui conţinut Definirea Definirea adecvat motivaţiei (De beneficiarilor - organizarea ce este nevoie (Cine va folosi lui pentru a fi de acel documentul folosit mai document?) De ce îi este uşor necesar?) Determinarea - scriere clară restricţiilor - folosirea impuse de: graficii pentru - sistem clarificarea - modul de mesajelor de folosire de transmis - modul de distribuire. Machetele trebuie concepute astfel încât deplasarea pe ecran să se facă de la stânga la dreapta şi de sus în jos. La completarea formularului nu sunt permise salturile . 3.3.2 Criteriile de evaluare a performanţelor interfeţelor din programele de introducere a datelor - deplasarea pe ecran/formular sau chiar în cadrul câmpului: la câmpul următor, la precedent, la primul, la ultimul, eventual la oricare alt câmp; - posibilităţi de editare; ştergerea unui caracter, cuvânt, rubrici/casete, linii, coloane, grup de caractere/casete; ştergerea tuturor datelor din formular, adăugarea de noi caractere, înserarea de caractere. - facilităţi de ieşire; salvarea ultimului ecran în baza de date, trecerea la alt ecran/formular, confirmarea salvării sau trecerea la alt formular, ieşire temporară din mediu de lucru ajutător (vizualizare ceas, folosire calculator de buzunar, etc.) - oferirea de help: despre orice câmp, despre întregul formular, despre alte elemente (vezi capitolul XII); - posibilităţi de control a accesului; restricţionarea accesului utilizatorilor, identificarea şi autentificarea utilizatorilor, autorizarea unor categorii de utilizatori la anumite tipuri de date,

D O C U M E N T

Revizuire corectare

Evaluare (Rãspunde documentul scopului pentru care a fost

10

criptarea datelor secrete, crearea nivelurilor de parole pentru acces ierarhizat la bazele de date, autentificarea utilizatorilor în timpul sesiunii după criterii aleatoare, păstrarea datelor despre utilizatorii aplicaţiei pentru reconstituirea unor prelucrări sau accese la date, interzicerea modificărilor/ştergerilor înregistrărilor anterioare care au un regim special. - facilităţi oferite la introducerea datelor; să nu se ceară date uşor de calculat cu datele existente, folosirea valorilor implicite, specificarea clară a UM, scoaterea în evidenţă a modului de introducere a datelor numerice de excepţie (în milioane lei, în miliarde, etc.), trecerea automată la câmpul următor când s-a introdus un număr de caractere, specificarea conţinutului casetei (sub forma: titlu de linie, titlu dedesubt, titlu încasetat, caractere delimitatoare, bifare de casete de validare, oferirea de exemple cum ar fi Data: ZZ/LL/AA), alinierea automată a datelor introduse, oferirea de help în context (vezi capitolul XII), controlul tipului de caractere introduse; - tehnici de validare a datelor; testarea dacă datele sunt de tipul care se cere, testarea combinată a datelor din mai multe câmpuri (de ex. preţuri mari combinate cu cantităţi mici, etc), verificare dacă datele sunt cele asteptate ( de ex. suma achitată este egală cu cota primă?), testarea lipsei datelor în unele câmpuri (Required), verificarea încadrării unor date în anumite şabloane (input mask), verificarea încadrării valorilor în anumite intervale, limitarea valorii maxime a unor date, utilizarea cifrei de control (vezi secţiunea 7.1), verificarea numărului de caractere introduse, verificarea existenţei valorilor introduse în cadrul unei liste cu valori admise (de ex. combobox). 3.4 Proiectarea dialogurilor Este procesul prin care sunt proiectate toate secvenţele folosite de utilizator pentru a comunica cu un sistem informatic. În această etapă analistul şi proiectantul trebuie să selecteze cele mai potrivite metode şi echipamente, să prezinte condiţiile în care se pot afişa informaţiile precum şi condiţiile în care informaţiile se pot obţine de la utilizator. Operaţiunea se efectuează în trei etape: - proiectarea secvenţei de derulare a dialogurilor; - construirea prototipului; - evaluarea comportamentului în utilizare. La elaborarea dialogurilor trebuie să se ţină cont de următoarele reguli: - uniformitatea dialogurilor sub aspectul derulării acţiunilor, a utilizării tastelor, şi a terminologiei (operaţiunile identice să aibă aceleaşi denumiri pe ecrane diferite, iar locul lor de amplasare să fie acelaşi); - comenzile să fie scurte, să se folosească short keys; - feed-back-ul: fiecare operaţiune după terminare să facă cunoscut faptul că s-a terminat şi eventual care este rezultatul; nu se oferă direct cadrul pentru următoarea operaţiune; - marcarea sfârşitului: ultima secvenţă de ecrane să indice faptul că nu mai există alte ecrane; - rezolvarea erorilor: erorile trebuie să fie detectate şi afişate; se va sugera modul de rezolvare; se vor accepta forme multiple de răspuns (ca d, D, Da, etc); - operaţiunea inversă: de exemplu la ştergere să se poată reveni asupra ştergerii; datele nu trebuie şterse fără confirmare. Inregistrarea trebuie mai întâi afişată şi numai după aceea să poată fi ştearsă. - controlul: dialogul trebuie să-i dea utilizatorului convingerea că deţine controlul asupra sistemului; - uşurinţa lucrului cu sistemul: se vor folosi cele mai simple forme de introducere a datelor şi de navigare pe ecran. 3.4.1 Proiectarea secvenţei dialogurilor La proiectarea secvenţei dialogurilor, chiar dacă nu folosim metoda Merise, este bine să avem în faţă un tabel asemănător celui cu modelarea organizaţională a prelucrărilor (MOP) şi eventual reprezentarea grafică a MOP, pe baza cărora putem întocmi un tabel cu activităţile ce

11

trebuie desfăşurate de actori în cadrul sistemului informatic. În acest tabel, pentru fiecare activitate vom specifica fazele, acţiunile, actorii, frecvenţele de prelucrare şi tipurile de prelucrări anticipate (automate – A sau manuale – M). În acest tabel, unde pentru o activitate corespund mai multe faze şi acţiuni (separate între ele cu linii orizontale), liniile orizontale nu pleacă din prima coloană, cu excepţia celor care urmează la sfârşitul prezentării unei activităţi. Indiferent dacă întocmim un tabel de forma celui de mai sus, sau beneficiem de alte forme de prezentare a informaţiilor cum ar fi modelarea logică a prelucrărilor (MLP) din Metoda Merise, important este ca la începerea proiectării dialogurilor să ştim clar ce trebuie să se execute la nivelul fiecărui agent, iar dacă este cazul, să cunoaştem şi condiţiile de sincronizare ce trebuie să existe între diferiţi agenţi. Numai cu aceste elemente la dispoziţie, putem începe proiectarea secvenţei dialogurilor. Dialogurile se pot derula prin intermediul meniurilor, dar şi al formularelor, care pe de o parte sunt cele care realizează dialogul propriu-zis sau părţi din el, iar pe de altă parte, ele pot apela alte formulare, uneori chiar sub influienţa unor criterii ce se aplică rezultatelor dialogului curent. In ce priveste meniurile, mai ales cele care la rândul lor apelează alte meniuri, ele se pot reprezenta cu ajutorul unor diagrame de forma celei de mai jos: START M01 Ctrl+End MENIU PRINCIPAL F9 F1 F2 F5 P01 M02 P02 P03 ADAUG_STUDENT MENIU_INTEROGARE MODIFIC_STUDENT ªTERG_STUDENT F1 F2 F3 P04 P05

REVENIRE INTEROGARE DUPÃ INTEROGARE DUPÃ (la meniul principal) NUME_STUDENT MATRICOL_STUDENT În această diagramă cu M s-au notat meniurile, cu F sau notat formularele şi cu P – procesele (procedurile). Trecerea de la un meniu la altul poate fi redată şi sub forma unei scheme de forma celei de mai jos: MENIU PRINCIPAL ADAUG_STUDENT MODIFIC_STUDENT ªTERG_STUDENT QUIT MENIU_INTEROGARE INTEROGARE DUPÃ NUME_STUDENT INTEROGARE DUPÃ MATRICOL_STUDENT În cazul dialogului multi-ecran intervin trei părţi: operatorul, sistemul şi o altă persoană care contactează direct sau telefonic operatorul.

QUIT (Pãrãsire meniu)

12

Dialogul purtat duce la ramificarea proceselor, deci şi a structurii de folosire a meniurilor, ceea ce concură la planificarea şi controlarea tuturor scenariilor posibile. Scenariile pot fi redate în două variante: pe coloane multiple şi scenarii-joc. În varianta coloane multiple se poate folosi o structură tabelară de genul: condiţii/evenimente externe, acţiunea operatorului, afişările din sistem, acţiunea sistemului. Scenariile-joc au în structură text/condiţii logice, actorii, acţiunile. 3.4.2 Construirea prototipului şi evaluarea comportamentului în utilizare Construirea prototipului dialogului şi evaluarea comportamentului în utilizare sunt în general activităţi opţionale. Pentru aceasta se pot folosi produse CASE sau facilităţile oferite de diferite medii de dezvoltare care dispun de wizard-uri, designere, builders, etc. cu care se pot face prototipuri sumare de formulare, rapoarte sau ferestre, dar cu care se poate testa apoi logica dialogului. Pe timpul acestor testări trebuie avute în vedere şi unele cerinţe mai deosebite care ţin de profesionalismul programatorului cum ar fi posibilitatea folosirii regimului de lucru cu "Cut and Paste", setarea imprimantei, proiectarea formularelor de tip Top-Level, proiectarea meniurilor şi a formularelor capabile să ruleze într-un formular de tip Top-Level, folosirea comenzilor spre alte aplicaţii sau sub Windows (API, DLL, etc), dar şi o categorie de cerinţe care derivă din nevoia de a folosi cât mai eficient resursele de care dispunem. Câteva din aceste cerinţe sunt următoarele: - dacă folosim opţiunea File, aceasta să fie prima; - Edit, să fie a doua; - Window este penultima; - Help este ultima; - o săgeată plasată în dreapta unei opţiuni ( ), indică faptul că urmează un submeniu; - trebuie să marcăm cumva elementele selectate sau activate (de exemplu bifate în stânga numelui); - trei puncte (…) plasate în dreapta unei opţiuni, semnifică faptul că urmează un meniu pop-up, sau chiar o fereastră de dialog; - afişarea pe prima linie a unui text comentariu, referitor la poziţia pe care se află prompterul; - evidenţierea poziţiilor ce mai pot fi activate faţă de celelalte care nu pot fi folosite (de exemplu folosirea unor culori accentuate pe butoanele ce mai pot fi activate şi a unor culori şterse pentru butoanele dezactivate). Ferestrele sau ecranele ce se folosesc în aplicaţii trebuie să aibă unele trăsături specifice cum ar fi: - modalitatea (să ceară decizia utilizatorului cu privire la modul prin care doreşte să înfăptuiască o acţiune; de exemplu dacă vrea să iasă dintr-o fereastră, să specifice cum: prin Cancel, prin Save, prin Ok, etc). - redimensionarea; - să fie mobile (să poată fi mutate dintr-un loc în altul) ; - să accepte maximizarea şi minimizarea; - să accepte opţiuni de meniu sistem pentru acţiuni cum ar fi salvarea sau copierea datelor. Trecerea de la o aplicaţie la alta, selectarea anumitor funcţii, înseamnă multe comutări între ele, ceea ce face necesară utilizarea diagramelor stărilor de tranziţie, descrise la etapa de analiză. 4. Proiectarea logică a bazelor de date: modelarea logică a datelor În această secţiune se are în vedere: - definirea locului modelării logice a datelor;

13

Pagina 1 Situaþia comenzilor în curs

31/03/2001 COD PRODUS CANTITÃÞI DE LIVRAT A1111 0

- simplificarea datelor prin normalizare; - transformarea diagramelor entitate-relaţie în relaţii; 4.1 Locul modelării logice a datelor în ciclul de viaţă al sistemelor Activităţile legate de modelarea logică a datelor sunt o continuare a modelării conceptuale a datelor efectuată în etapa de analiză. Ele pleacă de la diagramele entitate-relaţie şi tind spre descrierea structurii datelor din baza de date fizice, descriere bazată pe modelul relaţional. Modelarea logică a datelor se realizează nu numai pe baza diagramei entitate-relaţie ci şi pe baza machetei formularelor şi a rapoartelor. În procesul de modelare logică a datelor există patru paşi: a) Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare şi rapoarte) privind aplicaţia, folosindu-se principiile normalizării. De exemplu, dacă utilizatorul solicită rapoartele "Cel mai bun client al produsului X (ecran)" şi "Situaţia comenzilor în curs (raport)", dispunând de macheta lor, şi analizând aceste machete, noi putem desprinde imediat din analiza ecranului, existenţa următoarelor relaţii:

CLIENT (COD_CLIENTCOMANDA (

, NUME) NR_COMANDA, COD_CLIENT

PRODUS (, DATA_COMANDA)

COD_PRODUSLINIE_COMANDA (

) şi NR_COMANDA, COD_PRODUS

iar din analiza raportului existenţa următoarelor entităţi: , CANTITATE_COMANDATA),

PRODUS (COD_PRODUSCOMANDA (

) NR_COMANDA

LINIE_COMANDA (, DATA_COMANDA)

NR_COMANDA, COD_PRODUSLIVRARE(

, CANTITATE_COMANDATÃ) COD_PRODUS, NR_FACTURA,

FACTURA( CANTITATE_LIVRATA)

NR_FACTURAb) Contopirea tuturor perspectivelor normalizate ale utilizatorilor într-un model logic consolidat (centralizat) al datelor. Pasul mai este numit şi integrarea perspectivelor.

, DATA_FACTURA).

În exemplul de mai sus, aceasta presupune să rezulte următoarele relaţii: CLIENT (COD_CLIENTPRODUS (

, NUME) COD_PRODUS

FACTURA( )

NR_FACTURACOMANDA (

, DATA_FACTURA) NR_COMANDA, COD_CLIENT

LINIE_COMANDA (, DATA_COMANDA)

NR_COMANDA, COD_PRODUSLIVRARE(

, CANTITATE_COMANDATA) COD_PRODUS, NR_FACTURA,

c) Transformarea modelului conceptual al datelor (entitate-relaţie), realizat fără să se ţină cont de perspectiva utilizatorului, într-un set de relaţii normalizate.

CANTITATE_LIVRATA)

Cel mai bun client al produsului

Introduceþi codul produsului: P1122 Data de început: 10/10/00 Data de sfârºit: 31/12/00

14

COD_CLIENT NUME_CLIENT ADRESA NR_FACTURA CLIENT FACTURA Lansează Facturare CANTIT. LIVRATÃ COMANDA LIVRARE CANTITATE-COMANDATÃ LINIE_COMANDÃ PRODUS COD_PRODUS DENUMIRE Diagrama entitate-relaţie pentru exemplul de mai sus, realizată în etapa de analiză, mai exact în subetapa de modelare conceptuală este cea de mai sus. Din analiza acestei diagrame se desprind următoarele relaţii: CLIENT (COD_CLIENTPRODUS (

, NUME, ADRESA) COD_PRODUS

COMANDA (, DENUMIRE)

NR_COMANDA,COD_CLIENTLINIE_COMANDA (

) NR_COMANDA, COD_PRODUS

FACTURA( , CANTITATE_COMANDATA)

NR_FACTURA, NR_COMANDALIVRARE(

) NR_FACTURA , COD_PRODUS

d) Compararea modelului logic consolidat al datelor cu modelul transformat al entităţii-relaţie şi realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicaţiei, după cum urmează:

, CANTITATE_LIVRATA)

CLIENT (COD_CLIENTPRODUS (COD_PRODUS, DENUMIRE)

, NUME, ADRESA)

COMANDA (NR_COMANDA,COD_CLIENTLINIE_COMANDA (

) NR_COMANDA, COD_PRODUS

FACTURA( , CANTITATE_COMANDATA)

NR_FACTURA, NR_COMANDALIVRARE(

) NR_FACTURA , COD_PRODUS

Rezultatul modelării logice a datelor îl constituie relaţiile normalizate rezultate din acest din urmă pas al procesului, precum şi actualizarea depozitului (repository) sau a dicţionarului proiectului. În această fază cerinţele structurate de date se materializează în relaţii şi nu în entităţi. Din cauza normalizării nu este necesară o corespondenţă de unu-la-unu între entităţi şi relaţii.

, CANTITATE_LIVRATA)

4.2 Simplificarea structurii datelor prin normalizare Normalizarea bazelor relaţionale (eliminarea redundanţelor şi a anomaliilor de stocaj) înseamnă obţinerea de relaţii "atomice", fără a pierde nimic din informaţii. După normalizare,

NR_COMANDÃ

15

urmează optimizarea schemei interne, constând în eventuale denormalizări (join-uri

Practic normalizarea înseamnă să eliminăm "dependenţele funcţionale" folosind scheme de modelare care pot fi:

) şi apoi se alege: modul de organizare a tabelelor, metode de acces, cheile de indexare.

- schema de descompunere entităţi; - schema sintezei atributelor. Dependenţele funcţionale se referă la legăturile dintre atribute şi pot fi: - reflexive (ciclice); - tranzitive; - de creştere. Dependenţele funcţionale mai pot fi parţiale sau totale, precum şi multiple. Normalizarea se face în 5 trepte (forme): - 1NF: impune ca fiecare celulă a tabelului să conţină o singură valoare nedecompozabilă: dacă există caracteristici compuse (de ex. adresă = localit. + adresă), atunci vor rezulta mai multe caracteristici, dacă există mai multe caracteristici care fiecare în parte ar putea fi valori ale unui câmp, vor rezulta mai multe tupluri. - 2NF: impune să fie îndeplinit 1NF + fiecare caracteristică non-cheie să fie dependentă de o cheie primară; dacă există câmpuri ce nu depind de toată cheia primară, ele vor fi plasate separat într-un nou tabel a cărui cheie primară va fi doar partea de care câmpurile în cauză depindeau şi în vechiul tabel. Se elimină astfel dependenţele parţiale. - 3NF: impune 2NF + să nu existe dependenţe funcţionale tranzitive între caracteristicile non-cheie. Tranzitivă înseamnă că un câmp (caracteristică) X depinde de Y şi acesta depinde de Z, dar X depinde direct de Z. În acest caz vom mai iniţia un tabel având cheie primară pe Y, iar în acest tabel X va fi un câmp non-cheie. Y va rămâne şi în vechiul tabel, ca un câmp non-cheie. Ceva intermediar între nivelul 4 şi 5 de normalizare este NF Boyce Codd (BCNF); acesta pretinde 3NF + pentru orice dependenţă totală X-- A, rezultă că X este o cheie a lui R (tabelul în discuţie). - 4NF: impune BCNF + fiecare dependenţă multiplă devine o dependenţă funcţională; - 5NF: impune 4NF + şi nu are dependenţă ciclică (joints) sau dacă există, să fie implicată printr-o cheie secundară. 4.3 Transformarea diagramelor entitate-relaţie în relaţii Întregul proces se derulează în patru paşi: - Reprezentarea entităţilor. Fiecare tip de entitate din diagrama entitate-relaţie este reprezentată ca o relaţie în modelul relaţional al datelor. Identificatorul tipului de entitate devine cheie primară a relaţiei iar celelalte atribute ale tipului entităţii devin atribute non-cheie ale relaţiei. Exemplu: Entitatea angajat prezentă în DER sub forma Nume Marca

Angajat Adresă

va fi descrisă ca relaţie astfel: ANGAJAT (MARCA

, NUME, ADRESA), sau tabular:

II. ANGAJAT MARCA NUME ADRESA

1 Ionescu Adrian str. Vasile Pârvan, nr. 23, Mangalia

16

- Reprezentarea legăturilor. Fiecare legătură din diagrama entitate-relaţie trebuie să fie reprezentată în modelul relaţional al datelor. Reprezentarea legăturii se face în funcţie de natura ei. Astfel, uneori se poate constitui o relaţie prin includerea cheii primare a unei relaţii ca o cheie străină/externă în altă relaţie. De exemplu la prima vedere cineva ar putea prezenta o comandă de carte ca o entitate cu atributele nr_comandă, data_comandă şi dată_restituire. Dar la o analiză mai atentă se poate observa că entitatea ar trebui să mai aibă un atribut şi anume număr_matricol, care este de fapt cheia primară a entităţii student şi ca urmare s-au creat premisele unei legături între relaţia student şi comandă_carte. Alteori, se poate crea o relaţie separată pentru reprezentarea legăturii (cazul LINIE_COMANDÃ). - Normalizarea relaţiilor. Relaţiile create în paşii precedenţi pot conţine redundanţe nedorite şi vor constitui surse de apariţie a anomaliilor în timpul actualizării. Normalizarea va conduce la o bună structurare a relaţiilor. - Fuziunea relaţiilor. În timpul modelării logice a datelor s-au creat diferite relaţii, atât pe baza normalizării ascendente a perspectivelor utilizatorilor, cât şi a transformării uneia sau a mai multor diagrame entitate-relaţie în seturi de relaţii. În structura acestor seturi de relaţii pot exista unele relaţii redundante cum ar fi existenţa a două sau mai multe relaţii care descriu acelaşi tip de entitate, ce ar trebui să fuzioneze şi să se renormalizeze pentru extragerea eventualelor redundanţe. 5. Proiectarea structurală şi funcţională a sistemului informatic Până la această fază, nu s-au făcut referiri în cadrul proiectării generale a sistemului informatic, la structurarea sa pe subsisteme, aplicaţii, unităţi funcţionale, etc. şi nici la elementele de structură organizatorică implicate într-o aplicaţie sau alta. Acum este momentul să apropiem concepţia sistemului informatic de structura organizatorică a unităţii beneficiare şi de felul cum sunt realizate concret funcţiile acesteia prin intermediul atribuţiunilor funcţionale ale elementelor din structura organizatorică. Această acţiune implică pe de o parte structurarea sistemului informatic în subsisteme, aplicaţii, unităţi funcţionale sau proceduri logice şi unităţi de prelucrare sau proceduri automate, iar pe de altă parte asigurarea funcţionalităţii sistemului proiectat. Unitatea funcţională este o parte componentă a unei aplicaţii, reprezentată de un grup omogen şi specific de prelucrări, interconectate funcţional şi aplicate unei subfaze informaţionale omogene. Reamintim că procesele se descompun astfel: d.p.d.v.conceptual d.p.d.v. organizaţional - operaţii complexe; - faze; - operaţii elementare; - sarcini Unitatea funcţională sau unitatea logică de prelucrare rezultă din descompunerea sarcinilor şi contribuie la îndeplinirea operaţiilor. Cu alte cuvinte sarcinilor li se pot ataşa unităţi funcţionale, entităţi, posturi de lucru, iar acestora li se pot ataşa resurse 5.1. Structurarea sistemului, subsistemelor şi unităţilor funcţionale. Sistemele informatice la nivelul unităţilor beneficiare pot fi : - sisteme informatice independente, neconectate cu alte sisteme; - sisteme informatice distribuite total sau parţial; mixte. Structurarea sistemelor informatice se face mai uşor, dacă se coboară până la nivel unitate funcţională şi acolo se face legătura cu elementele de structură organizatorică (posturile de lucru). Structurarea pe unităţi funcţionale se face ţinând cont de următoarele criterii: - omogenitatea activităţilor, combinată cu compartimentele funcţionale

17

implicate în sistemul proiect; - ciclurile de funcţionare ale sistemului informatic; după acest criteriu se pot distinge trei tipuri de unităţi funcţionale: - pentru crearea iniţială şi actualizarea colecţiilor de date - pentru exploatarea colecţiilor de date şi obţinerea ieşirilor; - pentru realizarea de interfeţe cu alte sisteme informatice. - aspecte legate de relaţia sistemului cu mediul exterior. Se are în vedere adaptarea sistemului la schimbările de mediu, precum şi contracararea efectelor mediului exterior asupra siguranţei şi securităţii datelor din sistem. Acestea necesită unităţi funcţionale :

- pentru reorganizarea structurii conceptuale a bazei de date; - pentru securitatea/protecţia B.D;

- frecvenţele sau termenele de realizare ale prelucrărilor automate specifice noului sistem (rezultă unităţi funcţionale pentru prelucrări operative, la anumite termene şi cu prelucrări aleatoare). Criteriile de mai sus pot fi folosite corelat sau independent astfel încât numărul componentelor să fie optim, iar funcţionalitatea sistemului să fie maximă. 5.2 Asigurarea funcţionalităţii sistemului proiectat vizează definirea organizarii prelucrărilor şi a fluxurilor informaţionale între compartimentele implicate în noul sistem şi acest lucru se poate face mai uşor pornind de la elementele structurale ale unităţii funcţionale (intrări-prelucrări-ieşiri). Definirea elementelor structurale ale fiecărei unităţi funcţionale se face în următoarea succesiune: a) Ordonarea listelor/situaţiilor de ieşire în funcţie de compartimentele beneficiare, frecvenţele şi termenele de realizare ale acestora într-un tabel cu rubricile: Ieşirile sistemului Volum Compartimente

beneficiare Frecvenţa şi termenul

Dispozitiv de obţinere Cod Denumire

b) Verificarea structurii bazei informaţionale în funcţie de documentele de intrare utilizate pentru introducerea atributelor specifice acestora, conform unui tabel cu structura: Entităţile bazei informaţionale Documente de

intrare folosite Elemente de legătură Denumire Identificator

c) Verificarea corespondenţelor dintre structura bazei informaţionale şi listele/situaţiile de ieşire obţinute prin intermediul algoritmilor de calcul, conform unui tabel cu structura:

Structura bazei informaţionale de intrare

Ieşirile sistemului S1 S2 S3 S4 S5 … Sn

d) Ordonarea documentelor de intrare în funcţie de compartimente, frecvenţe şi termene de utilizare pentru crearea şi actualizarea colecţiilor de date; se întocmeşte un tabel cu structura:

Documente de intrare

Volum Comparti- ment emitent

Frec- venţa

Dispozitiv de preluare

Struc-tura B.I.

Cod Denumire

e) Definirea structurii unităţii funcţionale presupune precizarea intrărilor, prelucrărilor şi ieşirilor specifice. Pentru fiecare unitate funcţională se stabileşte criteriul sau criteriile utilizate pentru definirea sa, frecvenţa de apelare, interfaţa cu alte unităţi funcţionale şi fluxurile de prelucrare specifice: Se întocmeşte un tabel Format A4 (Landscape) cu structura de pe pagina următoare, unde prelucrările (P) sunt defalcate pe atâtea coloane câte entităţi informaţionale (EI) există în sistem. În acest tabel se are în vedere că:

18

- intrările sunt făcute pe baza documentelor de intrare folosite pentru constituirea şi actualizarea entităţilor bazei informaţionale;

- prelucrările sunt asigurate prin intermediul entităţilor bazei informaţionale care vor fi, actualizate sau exploatate în vederea obţinerii rezultatelor solicitate;

- ieşirile sunt formate fie din entităţile bazei informaţionale pentru prelucrări ulterioare, fie din listele/situaţiile de ieşire solicitate de beneficiarul sistemului, inclusiv listele de tranzacţii externe; Tabelul este intitulat “Structura generală a unităţii funcţionale” şi macheta lui este următoarea: Unităţi funcţionale proiectate

Intrări P Ieşiri EI

Cod

ul U

F

Crit

erii

de d

efin

ire a

UF

Frec

venţ

a de

util

izar

e

Inte

rfaţ

a cu

alte

UF

Flux

urile

de

prel

ucra

re

Cod

ul d

ocum

entu

lui d

e in

trare

Den

umire

a do

cum

entu

lui d

e in

trare

Com

parti

men

tul e

mite

nt

Frec

venţ

a de

tran

smite

re

E1

En

Cod

ul

Den

umire

a

Com

parti

men

tul b

enef

icia

r Fr

ecve

nţa

de tr

ansm

itere

Dis

pozi

tiv p

erife

ric d

e ob

ţiner

e

0 1 2 3 4 5 6 7 8 9 22 23 24 25 26 27

U.F

. 1

Cic

luril

e de

func

ţiona

re

(Cre

are-

actu

aliz

are

B. I

.)

U.F

. 2

Cic

luril

e de

func

ţiona

re

(Exp

loat

are

lista

re B

.I.)

Folosind datele completate în tabelul de mai sus, se poate întocmi organigrama unităţii funcţionale. Se întocmeşte cîte o organigramă pentru fiecare unitate funcţională. Elementul de bază al organigramei este un dreptunghi aflat în centrul foii. Dreptunghiul conţine date despre unitatea funcţională respectivă (codul unităţii funcţionale, criterii, frecvenţă, entităţile implicate în unitatea funcţională şi codul fluxului prin care sunt implicate). Pe laterală, ca nişte sateliţi sunt prevăzute alte dreptunghiuri (câte unul pentru fiecare element organizatoric (serviciu, conducerea unităţii, etc.) implicat în unitatea funcţională) legate de cel central prin săgeţi de tip fulger (rupte) pe care sunt înscrise codurile fluxurilor ce leagă cele două

19

dreptunghiuri (cel lateral cu cel central), iar în fiecare dreptunghi este trecut: denumire serviciu, codurile documentelor de intrare sau ieşire implicate în fluxul dintre cele două dreptunghiuri, eventual operaţiile ce le execută serviciul respectiv asupra documentelor (de ex. verificare, sau modificare, analiză sau decizie, etc.). Când s-au completat toate cele 5 tabele descrise mai sus de la literele a la e şi câte o organigramă pentru fiecare unitate funcţională, putem spune că s-a completat organigrama sistemului informatic. 6. Documentaţia etapei de proiectare logică a) Descrieri si definitii (se fac referiri la următoarele aspecte): 1. Intocmirea dictionarului atributelor (un tabel de forma următoare) Nr. crt.

Denumire Identificator Tip, lungime

Conditii de validare

1 Numărul ordinului NR_ORDIN N,8 NR_ORDIN>0 Observatie: la nr. crt. 1 tabelul de mai sus contine si un exemplu. b) Modelul logic de comunicatie (MLC) 2. Precizări referitoare la reteaua de calculatoare (dacă este cazul): topologie, configuratie, soft utilizat, etc. c) Modelul logic de date (MLD) 3. Transformarea diagramelor entitate-relatie în relatii (pct. 1 din Anexă) 4. Ordinea de prelucrare a bazei de date si ordinea de obtinere a rapoartelor (pct. 2 din Anexă) d) Modelul logic al prelucrărilor (MLP) 5. Structurarea sistemului, subsistemelor si unitatilor functionale (valabil numai la sisteme informatice). 6. Modelul logic al prelucrărilor, un tabel cu structura: activitatea, faze, actiuni (sarcini), actor, frecventa (Z, d, l, etc.) si tipul activitătii (A – automat, sau M – manual). Astfel unei activităti A, pot să-i corespundă de ex. 4 faze (A1, A2, A3 si A4) . În acest tabel fiecare fază va ocupa un rând, dar fără a diviza prin linii orizontale si coloana atribuită activitătii A. Cu alte cuvinte coloana întâia continuă nedivizată până ce se trece la activitatea B, s.a.m.d. Pentru fiecare fază coloana Actiuni, poate cuprinde (una sub alta, cu linioară) mai multe actiuni. MLP-ul se poate reprezenta si grafic. În MLP-ul casei de schimb valutar de la punctul 3, MLP-ul este reprezentat grafic. Pentru aceasta se pleacă de la MOP (vezi lucrarea de laborator precedentă) folosindu-se în continuare simbolul grafic destinat reprezentării activitătilor, dar sarcinile nu mai apar una sub alta ci sunt deplasate pe orizontală, în dreptul actorului care trebuie să le execute. 7. În continuare, în documentatie vor fi incluse machetele documentelor de intrare, (dacă au fost reproiectate) organigrama unitătilor functionale (dacă au fost identificate mai multe unităti functionale), machetele formularelor si rapoartelor, eventual a meniurilor (toate asamblate în asa fel încât să se constituie în dialoguri si interfete, specifice fiecărui actor din institutia beneficiară pe care v-ati ales-o pentru proiectul de an) precum si un tabel cu algoritmii folositi în diferite calcule. Indicatii metodologice 1. Transformarea diagramelor entitate-relatie în relatii Întregul proces se derulează în patru pasi: a) Reprezentarea entitătilor. Fiecare tip de entitate din diagrama entitate-relatie este reprezen-tată ca o relatie în modelul relational al datelor. Identificatorul tipului de entitate devine cheie primară a relatiei iar celelalte atribute ale tipului entitătii devin atribute non-cheie ale relatiei. Exemplu: Entitatea angajat prezentă în DER sub forma

20

Nume Marca

Angajat Adresă

va fi descrisă ca relatie astfel: ANGAJAT (MARCARelatia poate fi descrisă si tabelar.

, NUME, ADRESA),

De exemplu III. ANGAJAT

MARCA NUME ADRESA 1 Ionescu Adrian str. Vasile Pârvan, nr. 23, Mangalia

b) Reprezentarea legăturilor. Fiecare legătură din diagrama entitate-relatie trebuie să fie reprezentată în modelul relational al datelor. Reprezentarea legăturii se face în functie de natura ei. Astfel, uneori se poate constitui o relatie prin includerea cheii primare a unei relatii ca o cheie străină/externă în altă relatie. De exemplu la prima vedere cineva ar putea prezenta o comandă de carte ca o entitate cu atributele nr_comandă, data_comandă si dată_restituire. Dar la o analiză mai atentă se poate observa că entitatea ar trebui să mai aibă un atribut si anume număr_matricol, care este de fapt cheia primară a entitătii student si ca urmare s-au creat premisele unei legături între relatia student si comandă_carte. Alteori, se poate crea o relatie separată pentru reprezentarea legăturii (cazul LINIE_COMANDÃ). c) Normalizarea relatiilor. Relatiile create în pasii precedenti pot contine redundante nedorite si vor constitui surse de aparitie a anomaliilor în timpul actualizării. Normalizarea va conduce la o bună structurare a relatiilor. Normalizarea bazelor relationale (eliminarea redundantelor si a anomaliilor de stocaj) înseamnă obtinerea de relatii "atomice", fără a pierde nimic din informatii. După normalizare, urmează optimizarea schemei interne, constând în eventuale denormalizări (join-uri

Practic normalizarea înseamnă să eliminăm "dependentele functionale" folosind scheme de modelare care pot fi:

) si apoi se alege: modul de organizare a tabelelor, metode de acces, cheile de indexare.

- schema de descompunere entităti; - schema sintezei atributelor. Dependentele functionale se referă la legăturile dintre atribute si pot fi: - reflexive (ciclice); - tranzitive; - de crestere. Dependentele functionale mai pot fi partiale sau totale, precum si multiple. Normalizarea se face în 5 trepte (forme): - 1NF: impune ca fiecare celulă a tabelului să contină o singură valoare nedecompozabilă: dacă există caracteristici compuse (de ex. adresă = localit. + adresă), atunci vor rezulta mai multe caracteristici, dacă există mai multe caracteristici care fiecare în parte ar putea fi valori ale unui câmp, vor rezulta mai multe tupluri. - 2NF: impune să fie îndeplinit 1NF + fiecare caracteristică non-cheie să fie dependentă de o cheie primară; dacă există câmpuri ce nu depind de toată cheia primară, ele vor fi plasate separat într-un nou tabel a cărui cheie primară va fi doar partea de care câmpurile în cauză depindeau si în vechiul tabel. Se elimină astfel dependentele partiale. - 3NF: impune 2NF + să nu existe dependente functionale tranzitive între caracteristicile non-cheie. Tranzitivă înseamnă că un câmp (caracteristică) X depinde de Y si acesta depinde de Z, dar X depinde direct de Z. În acest caz vom mai initia un tabel având cheie primară pe Y, iar în acest tabel X va fi un câmp non-cheie. Y va rămâne si în vechiul tabel, ca un câmp non-cheie.

21

Ceva intermediar între nivelul 4 si 5 de normalizare este NF Boyce Codd (BCNF); acesta impune 3NF + pentru orice dependentă totală X-- A, rezultă că X este o cheie alui R (tabelul în discutie). - 4NF: impune BCNF + fiecare dependentă multiplă devine o dependentă functională;

1. - 5NF: impune 4NF + si nu are dependentă ciclică (joints) sau dacă există, să fie implicată printr-o cheie secundară.

d) Fuziunea relatiilor. În timpul modelării logice a datelor s-au creat diferite relatii, atât pe baza normalizării ascendente a perspectivelor utilizatorilor, cât si a transformării uneia sau a mai multor diagrame entitate-relatie în seturi de relatii. În structura acestor seturi de relatii pot exista unele relatii redundante cum ar fi existenta a două sau mai multe relatii care descriu acelasi tip de entitate, ce ar trebui să fuzioneze si să se renormalizeze pentru extragerea eventualelor redundante. 2. Ordinea de prelucrare a bazei de date se poate reprezenta printr-un tabel având struc-tura de mai jos: Nr. crt. Den..rel

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

1. CLIENTI 1 1 unde cifrele de la intersectia unei relatii din prima coloană cu numărul altei relatii dispus pe orizontală în linia a doua, indică ponderile entitătii din prima coloană în raport cu celelalte entităti. Ponderea ia valoarea 1 dacă participarea entitătii din linia a doua în dependenta functională cu entitatea din coloana întâia este obligatorie si ia valoarea 0 dacă participarea entitătii din linia a doua în dependenta functională cu entitatea din coloana întâia este optională. În tabelul de mai sus, la intersectia entitătii CLIENTI cu cea de a patra entitate, găsim 1, ceea ce înseamnă că unei realizări din entitatea 1 trebuie neapărat să-i corespundă o realizare în entitatea 4, dar unei realizări din entitatea 4 poate să nu-i corespundă nici o relizare în entitatea 1. Concret, în cazul în care coloana 4 s-ar referi la entitatea TRANZACTII, fraza precedentă trebuie înteleasă că o tranzactie nu trebuie neapărat să aibă un client, dar dacă în entitatea CLIENTI există o realizare, deci există un client, acela neapărat trebuie să se refere la o tranzactie. În continuare, se face suma pe linie si apoi se decide ordinea de prelucrare pentru entitătile care au cea mai mică sumă; astfel suma ponderilor pentru entitatea Clienti este 1. Fiind cea mai mică din această coloană, o desemnează pe prima entitate ca făcând obiectul actualizării si pentru aceasta s-a conceput procedura P1. - ulterior entitătile care fac obiectul actualizării cu procedura P1 (ar fi putut fi si altele cu aceeasi sumă ca entitatea Clienti), se exclud din calculul sumei si se recalculează suma, urmând a se lua în calcul suma cea mai mică; se obtin astfel entitătile ce vor fi actualizate cu procedura P2 (în exemplul de mai sus intră entitatea 7). - se repetă pasul precedent până ce se stabileste ordinea de prelucrare pentru toate entitătile. Coloanele rezultate în zona "Ordinea de actualizare a bazei de date", desemnează procedurile ce se disting pentru actualizarea bazei de date. Astfel în exemplul de mai sus, se distinge o procedură P1 care va actualiza entitatea 1, una P2 care va actualiza entitatea 7, P3 pentru entitătile 2, 3, 4, 5, 6 si 9 si P4 pentru entitătile 5 si 8. Exemplul este fictiv si nu trebuie căutată compatibilitatea solutiei. In mod asemănător cu ordinea de actualizare a bazei de date, se mai stabileste si ordinea de obtinere a rapoartelor, care poate apare în tabelul de mai sus, ca o altă coloană în continuarea celei de actualizare a bazei de date.

22

3. Modelarea logică pentru o casă de schimb valutar

a) Dictionarul atributelor Dictionarul atributelor stabileste identificatorii si conditiile de validare pentru fiecare tip de atribut. Acest dictionar al atributelor, pentru casa de schimb valutar poate fi redactat astfel:

Denumire atribut Identificator Tip, lungime Conditii de validare cod PSV COD PSV C,5 COD PSV<>”” nume persoană NUME C,40 NUME<>”” tara TARA C,20 TARA<>”” tip AI TIP_AI C,2 TIP_AI={PT,AI,BI,PS,XX} serie AI SERIE_AI C,2 SERIE_AI<>”” Nr. AI NR_AI N,7 NR_AI>0 and NR_AI<9(7) … … … … Data operatiei DATA_OP D,8 DTOC(DATA_OP)>=”01-01-01” and

DTOC(DATA_OP)=<”31-12-01” Nr. doc. Miscare NR_DOC C,10 NR_DOC<>”” descr. op. miscare DESCR C,40 DESCR<>”” sold initial SOLD_I N,10 SOLD_I<>0 and SOLD_I=<9(10) b) Modelul logic de comunicatie (MLC) Pentru casa de schimb valutar MLC este bazat pe câte un calculator cu structură de workstation, pentru fiecare PSV:

PSV PC- AT(WS)

c) Modelul logic de date Se referă în principal la transformarea MCD (modelul entitate-relatie) în relatii. Cuvintele relatie si relatii nu au acelasi înteles. Modelul entitate-relatie este de fapt modelul entitate-legătură, în timp ce relatia în care se transformă acest model în cadrul modelului logic, nu este o legătură ci este echivalentul entitătii în algebra relatională. Acolo se operează cu relatii în sensul de tabel bidimensional format din rânduri (linii) numite tupluri si coloane numite domenii. Pentru casa de schimb valutar, MLD arată astfel:

1 0

1

0

0 1 Pentru determinarea ordinii de actualizare a bazei de date si a secventei de obtinere a iesirilor din cadrul aplicatiei Casa de schimb valutar vom folosi tabelul de mai jos:

CLIENTI Numãr AI ………….

TRANZ Numãr AI Cod_valutã Numãr_BSV

VALUTE Cod_valutã

MISC Nr_document Cod_valutã

23

1. 2. 3. 4. Ordinea de actualizare a BD Ordinea de listare

2 1,3,4 BC BV RC JCV JVV RBNR TM

1. CLIENTI - 1 1 1 1 2 3 4 5 6 7 2. VALUTE - 0 0 0 - 3. TRANZ 0 1 - 1 1 4. MISC. 1 - 1 1 Din acest tabel se vede că ordinea de actualizare a BD este VALUTE, CLIENTI, TRANZ, MISC, iar cea de obtinere a rapoartelor de iesire este BC, BV, RC, JCV, JVV, RBNR, TM.

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

în faze iar operatiile elementare sunt transformate în sarcini: - FREC- VENTA

BANCA PSV CSV TIP A/M

AL

BMITB

EXC

BMITPSV BMSI

BMITPSV a a 1. TRANSFER SUME VALUTÃ PSV-CSV - verificarea sumelor transmise între PSV si CSV. OK OK

b RZT d c c∨d

2. INTRÃRI VALUTE TRANSFER BANCÃ - verificarea sumelor primite de la bancă - actualizarea

OK OK e b BMSI RZT

M

M

24

FREC- VENTA

PERSOANÃ FIZICÃ

PSV CSV TIP A/M

Z

L

BI

AI

PT

PS

XX

BMECH

j i h g f f∨g∨h∨i∨j∧k

3. CUMPÃRARE/VÂNZARE VALUTÃ - înregistrarea cumpărărilor de valută în BC - înregistrarea vânzărilor de valută în BV - înregistrarea cheltuielilor PSV

OK OK l m n v s BC JCV BOC RC o p t BV JVV BOV RZT n o s t n∧o∧s∧t 4. RAPORTÃRI LIVRARE CÃTRE BNR - calculul totalului miscărilor în valută; la nivelulCSV - elaborarea RBNR OK OK RBNR TM

A

A

k

1

Cursul_III_6

PROIECTAREA FIZICÃ A SISTEMELOR INFORMATICE Proiectarea fizică se desfăşoară pe parcursul a trei subfaze sau paşi: - proiectarea fişierelor fizice şi a bazelor de date: aceasta vizează descrierea modului în care vor fi stocate şi accesate în/din memoriile secundare şi cum se va asigura controlul lor pentru a se oferi o securitate maximă; - proiectarea structurii sistemului şi a programelor: sunt descrise programele şi modulele acestora urmărindu-se ca ele să fie în concordanţă cu diagramele fluxurilor de date şi cu celelalte piese ale documentaţiei realizate în etapele anterioare; - proiectarea strategiilor de prelucrare distribuită: modalităţile în care utilizatorul poate să dispună de date şi facilităţi de prelucrare distribuite în reţea. În legătură cu proiectarea fizică, trebuie avut în vedere că, dacă în fazele precedente s-au căutat răspunsuri la întrebarea "Ce trebuie să facem?" acum trebuie să răspundem la întrebarea "Cum vom face ce ne-am propus în etapele anterioare?". Fiind ultima fază înainte de implementare, proiectarea fizică este ultima şansă de punere de acord a soluţiilor noastre cu cerinţele utilizatorului dar şi cu realitatea în care va funcţiona sistemul. 1. Proiectarea fişierelor fizice şi a bazelor de date 1.1 Aspecte generale ale proiectării fişierelor fizice şi a bazelor de date Proiectarea fişierelor fizice şi a bazelor de date trebuie să asigure trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor. Proiectantul trebuie să aibă în vedere că proiectarea fizică trebuie să se materializeze în specificaţii tehnice ce vor fi folosite ulterior de pogramatori şi alţi specialişti implicaţi în construirea sistemului, adică la crearea fişierelor, definirea modurilor de organizare acestora, precum şi a bazelor de date. Proiectarea fizică a fişierelor şi a bazelor de date are două obiective: - transpunerea relaţiilor dintr-un model de reprezentare logică a datelor într-un proiect tehnic. Mai exact, se vor stabili:

- formatele sub care vor fi reprezentate atributele; - modul de grupare a atributelor din una sau mai multe relaţii în una sau mai multe înregistrări fizice; - alegerea modului de organizare a fiecărui fişier cu înregistrări; - proiectarea metodelor de accesare a datelor din unul sau mai multe fişiere;

- selectarea tehnologiilor folosite pentru stocarea datelor. Tehnologiile se referă la diverse funcţii ale sistemului de operare (numite metode de acces) şi sisteme de gestiune a bazelor de date. Fiecare tehnologie va fi specifică unei anumite arhitecturi a sistemului. Pentru realizarea acestor obiective, se pleacă de la următoarele informaţii: - relaţiile normalizate, inclusiv dimensiunea bazei de date; - definirea fiecărui atribut; - specificarea momentului şi a locului utilizării datelor: introducerea, resta-urarea, ştergerea, actualizarea (inclusiv frecvenţa operaţiilor); - timpul preconizat pentru obţinerea răspunsurilor; - descrieri ale tehnologiilor folosite pentru crearea fişierelor şi a bazelor de date.

2

Cele două obiectivele, se vor materializa pe baza informaţiilor de mai sus, în următoarele decizii ale analistului de sistem: - selectarea formatului de stocare (tipul datei) pentru fiecare atribut al modelului logic al datelor şi precizarea tuturor proprietăţilor specifice tipului de date ales (format, input mask, validation rule, default value, etc.); - stabilirea structurii înregistrărilor/datelor stocate (gruparea atributelor din modelul logic al datelor în înregistrări fizice); - stabilirea organizării fişierelor (modul de plasare a înregistrărilor înrudite în memoria secundară - discuri, benzi magnetice) astfel încât înregistrările individuale sau grupate să poată fi stocate, restaurate şi actualizate rapid; tot acum se stabileşte modul de protecţie a informaţiilor şi a reconstituirii lor după anumite incidente; - selectarea suportului datelor, care deşi este menţionat ultimul, este corelat şi influienţează hotărâtor, structurile de stocare a datelor precum şi organizarea fişierelor. În cazul SGBD aceasta presupune selectarea opţiunilor pentru accesul secvenţial sau prin chei, precum şi implementarea legăturilor/asocierilor dintre entităţi şi relaţii . Structura primară cea mai utilizată în prezent, se bazează pe indecşi construiţi prin chei primare şi chei secundare. Aceste decizii, se vor materializa în specificaţii care aşa cum s-a menţionat mai sus, vor fi utilizate de programatorii sau analiştii bazelor de date pentru definirea formatului şi structurii datelor stocate în memoria secundară. Ele se pot păstra în depozitul CASE sau manualul dicţionarului proiectului, dar determină şi completarea dicţionarului proiectului, în timpul proiectării fizice a fişierelor şi bazelor de date, cu unele elemente reprezentative cum ar fi: - proprietăţile câmpului: nume, tip dată, UM (unitatea de măsură), codul (regula de codificare), reguli de validare (de asigurare a integrităţii datelor), controlul întreţinerii ( de ex. nu se poate schimba un număr de factură validat), Null, for-mula în cazul câmpurilor calculate (ex. valoare=pret*cantitate), cifra de control, integritate referenţială, cine este autorizat să introducă, să valideze, să actualizeze data şi cine o poate consulta; - proprietăţile înregistrării: lista câmpurilor unei înregistrări, date structurale necesare interpretării formatului înregistrării (pointeri sau alte elemente ale câmpurilor de lungime variabilă), durata de păstrare a datelor; - proprietăţile fişierului: nume şi amplasare, înregistrări ce vor fi stocate în fişier, cheia primară, indecşi, factorul de blocaj, păstrare şi copii de siguranţă, organizarea fişierelor, modalitatea de auditare şi de criptare; - proprietăţi ale bazelor de date: fisiere ce fac parte din baza de date, arhitectura ( tipul structurii bazei de date d. p.d.v. al s.g.b.d. ce poate să o gestioneze: de ex. un s.g.b.d. relaţional), relaţii (mecanismele utilizate pentru punerea laolaltă a fişierelor: de ex. tipul pointerilor folosiţi pentru legarea înregistrărilor din fişiere diferite în cadrul unei baze de date reţea sau ierarhică). 1.2 Proiectarea câmpurilor De regulă fiecare atribut al modelului logic al datelor va fi reprezentat ca unul sau mai multe câmpuri (de ex. NUME_PERS poate fi reprezentat prin NUME, INIÞIALÃ şi PRENUME). Analistul trebuie să specifice proprietăţile câmpurilor enumerate mai sus, ca elemente de completare a dicţionarului proiectului.

3

1.3 Proiectarea înregistrărilor fizice În cadrul acestei acţiuni se urmăreşte printre altele, şi utilizarea raţională a suporturilor magnetice, care se concretizează în aspecte cum ar fi factorul de blocaj sau partiţionarea înregistrărilor. Factorul de blocaj ţine de faptul că în general calculatoarele, prin sistemele lor de operare, citesc cantităţi fixe de informaţii, care constituie un fel "de pat al lui Procust" pentru înregistrările fizice. Mai exact, în cazul discurilor cantitatea fixă posibil a fi citită/scrisă la o comandă de citire/scriere, se numeşte pagină, iar în cazul benzilor magnetice se numeşte bloc de înregistrări. Ideal ar fi ca dimensiunea acestor capacităţi împărţită la lungimea unui articol, să dea un rest cât mai mic, dacă se poate să fie zero. În practică dimensiunea articolului depinde de nevoile logice de organizare a datelor în tabele şi rareori se poate potrivi cu acest criteriu de optimizare. Factorul de blocaj este raportul dintre lungimea utilă a blocului de înregistrări şi lungimea fizică a acestuia. Ideea se poate extinde şi la pagini. Oricum, cu cât articolul este mai lung, cu atât este posibil ca factorul de blocaj să fie mai mic. Articolele lungi mai prezintă un dezavantaj: ele pot încetini inutil citirile şi scrierile în cazul în care într-o prelucrare nu avem nevoie decât de câteva câmpuri din tabelul sau fişierul supus prelucrării. Pentru a evita astfel de situaţii, se foloseşte partiţionarea înregistrărilor. Aceasta este operaţiunea prin care înregistrările fizice sunt descompuse în două sau mai multe segmente fizice, pe criterii de legături de afinitate între unele câmpuri, cu scopul creşterii operaţiunilor de prelucrare. De regulă înregistrările fizice sunt descompuse într-un segment primar care conţine câmpuri necesare în cele mai multe tranzacţii şi un segment secundar care conţine câmpurile solicitate mai rar. Astfel înregistrarea logică CLIENT, poate fi descompusă într-un segment primar format din cod_client, limita-creditare, sold_curent şi unul secundar format din: adresa_client, localitatea, judeţul, ţara, cod_poştal, statut_client. Separarea înregistrărilor fizice se poate face şi pe criterii de apartenenţă la anumite compartimente ale unităţii ( de ex. contabilitate, marketing, proiectare, etc.). Este de remarcat faptul că partiţionarea duce la denormalizare, adică la încălcarea structurii înregistrării logice aflată la cea de a treia formă de normalizare. Practic denormalizarea conduce la două stări contradictorii: - anularea efectelor benefice ale normalizării; - optimizarea procesului de prelucrare. Este de datoria analistului-programator să găsească soluţia de compromis cea mai avantajoasă. 1.3.1 Înregistrări cu câmpuri de lungime fixă şi variabilă Cu înregistrările formate din câmpuri de lungime fixă este foarte uşor de lucrat: atât înregistrările cât şi câmpurile se găsesc foarte uşor. În cazul câmpurilor de lungime variabilă (cazul memo), lucrurile sunt mai complicate. Unele SGBD, între care şi FoxPro, Paradox, dBASE descompun relaţiile obţinute în proiectarea logică în două părţi: una care să reunească toate câmpurile de lungime fixă şi alta care să cuprindă câmpurile de lungime variabilă. 1.4 Proiectarea fişierelor fizice 1.4.1 Tipuri de fişiere În funcţie de gradul de menţinere în timp a datelor stocate în fişiere, ele se clasifică în: - fişiere permanente (de ex. nomenclatoarele) - fişiere de stare (de ex. stocurile, soldurile, etc; - fişiere variabile (temporare sau de conjunctură): de ex impuse de legislaţia în vigoare, cum ar fi ştatele de plată - pentru a permite calculul pensiilor, sau fişiere necesare pentru reconstituirea datelor după anumite incidente; - fişiere-tabel: tabel cu medicamente compensate, tabel cu dobânzi, cu procentele de impozit, tabele statistice, etc.

4

- fişiere index; - fişiere istoric (de ex. fişierul vânzărilor ce va fi folosit pentru determinarea trend-ului); - fişiere back-up (copii ale unor fişiere permanenete sau ale altor fişiere, folosite pentru reconstituirea evidenţei); - fişiere cu suspendări. Conţin înregistrări care au fost identificate ca eronate sau cu un statut incert. De exemplu, când s-au efectuat tranzacţii şi nu există înregistrarea corespunzătoare în fişierul permanent, stocuri omise sau determinate prea târziu. Aceste fişiere necesită mare atenţie. - fişiere de raportare. - baza de date (în sensul ei cel mai clar, o colecţie de date integrate într-un număr de fişiere, memorate astfel încât să faciliteze atât actualizarea rapidă a datelor cât şi accesul la ele. 1.4.2 Metode de prelucrare a fişierelor - prelucrare pe loturi (batch processing); - prelucrarea on-line (individual, de îndată ce apar informaţiile, prelucrarea efectuându-se în punctul de origine a informaţiilor). Aceasta poate fi de două feluri: - actualizare on-line (prelucrări de tranzacţii); - prelucrare de tip întrebare/răspuns (consultări ale fişierelor principale în vederea efectuării unei tranzacţii (de ex. consultarea contractelor sau a altor condiţii impuse pentru declanşarea unei tranzacţii). 1.4.3 Caracteristicile fişierelor fizice - suportul de înregistrare; - indicile de activitate: Ia= - volatilitatea, o măsură a frecvenţei adăugirilor, ştergerilor şi a altor operaţiuni necesare pentru un fişier permanent, într-o anumită perioadă de timp:

Volatilitatea fişierelor= - accesibilitatea se referă la uşurinţa cu care înregistrările pot fi regăsite. Ea depinde de suportul de informaţii şi de echipamentele utilizate, dar şi de modul de codificare, de indexare şi de modul de realizare a referinţelor încrucişate, de la o înregistrare la alta. Proiectantul mai trebuie să elaboreze un program al tipurilor de înregistrări stocate şi acesta trebuie să conţină două elemente:

- perioada de timp după care înregistrările pot fi trecute din categoria active la categoria celor inactive;

- perioada de timp după care fiecare tip de înregistrare poate fi sigur distrusă. Înregistrările inactive trebuie stocate pe suporturi ieftine, într-un loc diferit de prelucrarea datelor. Unele companii au înfiinţat funcţia de Records management , într-un departament separat care se ocupă de:

- crearea formularelor care se folosesc pentru culegerea şi memorarea datelor; - prelucrarea , stocarea reconstituirea înregistrărilor;

- reţinerea înregistrărilor inactive; - renunţarea la înregistrările învechite.

În unele unităţi aceste sarcini sunt preluate de serviciul de birotică sau de către administraţia birourilor.

Numãr de articole din fiºierul permanent referite la o întreþinere

Numãrul total al operaþiilor relative la fiºier U it t d ti t d d ( i

5

1.4.4 Organizarea fişierelor şi accesarea înregistrărilor a) Principalele moduri de organizare a fişierelor: - organizare secvenţială; - organizare secvenţial indexată (organizare secvenţială pe baza unei chei primare) - organizare relativă, o formă de organizare directă bazată pe valoarea înregistării relative (un număr care indică poziţia relativă a înregistrării faţă de începutul fişierului); - organizare selectivă, a doua formă de organizare directă, bazată pe o adresare specială: aceasta se bazează pe o cheie relativă ce se obţine printr-un calcul de randomizare, pornind dela valoarea cheii primare. b) Moduri de acces a înregistrărilor: - accesul secvenţial; - accesul aleator. Organizarea fişierelor se stabileşte odată cu crearea fişierului şi numai în cazuri foarte rare se modifică. 1.5 Proiectarea securităţii fişierelor şi bazelor de date Securitatea fişierelor şi bazelor de date vizează securitatea averii informaţionale, adică posibilitatea reconstituirii datelor pierdute sau prelucrate eronat, blocarea accesului neautorizat sau măcar incomodarea până la a face imposibilă citirea datelor prin criptare, atunci când ele sunt accesate ilegal. 1.5.1 Reconstituirea datelor De cele mai multe ori ne duce cu gândul la fişiere de tip back-up (reconstituire înainte), dar se poate face şi fără acest tip de fişiere (reconstituire înapoi). Reconstituirea înapoi constă în reluarea efectului invers al tranzacţiilor până la ultima tranzacţie eronată continuată cu corectarea erorilor. Pentru controlul corectitudinii datelor despre tranzacţii se aplelează la fişiere care reflectă istoricul schimbărilor şi accesărilor efectuate asupra fişierelor şi bazelor de date, numite probe în auditare. Ele, împreună cu registrul tranzacţiilor, conţin imaginea înregistrărilor înainte şi după modificare, copii ale datelor despre tranzacţii, şi alte informaţii. Toate acestea pot fi enumerate sintetic astfel: - elemente de identificare a tranzacţiei; - elemente de identificare a operatorului/utilizatorului; - valoarea tranzacţiei; - imaginea unui câmp înaintea efectuării unei schimbări; - tipul operaţiei efectuate; - data şi momentul din zi când a avut loc tranzacţia; - codul sau numele programatorului care a declanşat tranzacţia; - echipamentul cu care s-a efectuat operaţiunea, ş.a. 1.5.2 Criptarea datelor presupune transformarea datelor de comunicat, într-o formă neinteligibilă pentru oricare receptor, cu excepţia celui autorizat. Criptarea se poate face prin coduri sau prin cifruri. Codurile sunt mesaje numerotate sau însoţite de un identificator. În procesul de comunicaţie se transmite numai numărul sau identificatorul, iar destinatarul consultă lista cu semnificaţia codului. Cifru presupune existenţa unor chei care, odată puse în funcţiune, asigură la criptare, conversia fiecărui simbol din mesajul în clar, într-un corespondent din mesajul cifrat. Procesul este reversibil la decriptare. Dacă se foloseşte aceeaşi cheie la criptare şi decriptare avem de a face cu un cifru simetric, altfel cu un cifru asimetric.

6

Cifrurile se pot aplica supra simbolurilor întregului mesaj sau ale unor grupuri din el, în mod continuu. În acest caz se numesc cifruri în flux continuu, dar există şi cifruri bloc, acelea care se aplică numai asupra unui grup de simboluri. Există trei feluri de cifrări: camuflajul, transpoziţia şi substituţia. Camuflajul presupune ca mesajul să nu fie observabil, adică să fie ascuns într-un mesaj banal, dar credibil. Transpoziţia presupune utilizarea unui şablon atât la criptare cât şi la decriptare. Pe timpul transportului, mesajul este un fel de puzzle. Dacă este posibil, este bine ca transpoziţia să fie îmbinată cu camuflajul, adică textul criptat să arate paşnic, să nu sfideze, pentru că atunci ar atrage atenţia şi poate şi interesul unora de a sparge codul. Substituţia presupune înlocuirea literelor după reguli bine stabilite, cu alte litere sau cifre . 1.6 Proiectarea bazelor de date este precedată după cum s-a putut vedea în secţiunile anterioare, de proiectarea fişierelor fizice, dar în practică activitatea se desfăşoară în spirală. Când se proiectează arhitecturile bazelor de date, trebuie să fie luate în consideraţie mai multe aspecte, dar determinant este mărimea sistemului. Există patru tipuri de arhitecturi: ierarhică, reţea, relaţională şi orientată-obiect. (Vezi cap. II, secţiunea 2). În cele ce urmează avem în vedere arhitectura relaţională şi faptul că la sfârşitul acestei etape trebuie să avem definită structura generală, din punct de vedere fizic, a bazei de date relaţionale. La această descriere se poate ajunge prin două metode: a) Metoda sintetică vizează entităţile (tabelele) atributele lor şi corespondenţele dintre entităţi. După această metodă entităţile se clasifică în:

sintetică şi analitică.

- nuclee (cu existenţă independentă; ex. SECT, ATEL, MAT, BEN); - intermediare (rezultă din prelucrările altor entităţi; sunt de manevră); - de stare (reţin date sintetice provenite din prelucrările datelor stocate în entităţile de tip nucleu, intermediar sau chiar de stare). Fazele descrierii structurii generale a bazei de date relaţionale: - atribuirea specificatorului entităţii: dispozivul, directorul unde va fi stocată entitatea, extensia acesteia (ex. DBF); - descrierea atributelor specifice entităţii (NUM (numărul de ordine al atributului în cadrul entităţii) , FIELD NAME, FIELD TYPE, WIDTH, DEC INDEX (cheia de indexare), cond. de validare ; - descrierea corespondenţelor dintre entităţi (determinarea entităţii de legătură, cheia externă şi cardinalitatea); - caracteristici fizice şi de acces (se are în vedere definirea organizării entităţilor de tip index, cheile de indexare, numărul maxim de înregistrări şi lungimea maximă a unei înregistrări); cheile de indexare pot fi primare sau secundare. Acestea din urmă îndeplinesc şi ele condiţiile de cheie primară, dar nu au fost ele desemnate drept cheie primară. b) Metoda analitică se aplică atunci când există o bază de date relaţională deja proiectată, iar structura sa trebuie optimizată: ea se aplică atunci când în baza de date au rămas de verificat numai depenţele funcţionale de forma C→A unde C reprezintă cheia primară, iar A orice alt atribut din entitate. Indiferent de metoda aplicată, rezultatul descrierii structurii generale a bazei de date relaţionale este acela că pentru fiecare relaţie se va întocmi un tabel ca cel de pe pagina următoare, care este un exemplu de descriere a relaţiei B.D. “RULAJE PRECEDENTE” . Un astfel de tabel se poate construi numai pe baza organigramei sistemului informatic, a dicţionarului atributelor şi a tabelului numit baza de atribute, toate elaborate în faza de

7

proiectare logică. In plus, se va ţine seamă de restricţiile impuse de sistemul de operare şi de restricţiile de integritate.

Descrierea bazei de date DESCRIEREA ENTITÃÞII

Nume entitate Specificator Rulaje precedente Peri-

feric Identificator Extensie Securitate

RULΦ dbf sgbdr Fox STRUCTURA ÎNREGISTRÃRII

Nr. nivel

Identi-ficator atribut

Tip, lungime

Mod repre-zentare

Lo FA Antetul atributului

Condiţii de validare

02 COD-CONT

N,3 D 3 Z3 ‘COD’/’CONT’ COD CONT >100

02 DEN-CONT

C,20 D 20 X2O

‘DEN’/’CONT’ #b

02 SOLD-DB

N,8 D 5 Z8 ‘SOLD INIÞIAL’/’OB’

≥0

02 SOLD-CR

N,8 D 5 Z8 ‘SOLD INIÞIAL’/’CR’

≥0

CARACTERISTICI FIZICE ªI DE ACCES Orga- ni-

CHEI DE INDEXARE Nr. maxim

Lungi-me

Tip în- reg.

F.B. Număr blocuri virtualitate

zare

Identi ficato-ri

Restricţii înreg.

maximă în- reg.

Prima-ră

Cod-cont

No dup. No change

Ini-ţial

extensie

Secvenţial indexat

Secun-dară

Den-cont

No dup. No change

50 40 F

RESTRICÞII DE INTEGRITATE NUME FIªIER CHEIE EXTERNÃ CARDINALITATE MAT. COD-CONT 1-n PROD COD-CONT 1-n INTRÃRI COD-CONT 1-n IEªIRI COD-CONT 1-n LIVRÃRI COD-CONT 1-n

2. Proiectarea programelor şi a procedurilor 2.1 Aspecte generale ale proiectării programelor şi proceselor În cazul sistemelor mari se face distincţie între proiectantul de soft şi programator. Primul defineşte şi structurează componentele în aşa fel încât să formeze un tot unitar, un proiect soft operaţional. El trebuie să grupeze funcţiile ce trebuie interconectate şi să descrie modalităţile de realizare a legăturilor. Al doilea, trebuie să transpună proiectul soft în realitate. El îşi propune, ca prin intermediul programelor să controleze intrările, prelucrările, stocările şi ieşirile din sistem. Softul are două componente: instrucţiunile (statements) şi modulele. Modulele se pot grupa pentru a forma programele. Programele trebuie să ţină seamă şi de modul în care calculatorul rezolvă accesul mai multor programe la resursele sale. Aceste modalităţi de administare a

8

resurselor calculatorului au evoluat de la prelucrări în batch, la multiprogramare şi apoi la multiprogramare-multicalculator. Acum se folosesc şi calculatoare având unităţi centrale cu mai multe procesoare şi evident, cu posibilitatea prelucrării concomitente a mai multor programe. Au apărut reţelele de teletransmisie şi teleprelucrare a datelor şi sisteme interactive, iar legat de aceasta şi limbaje de programare conversaţionale. Există mai multe clasificări ale programelor, dar una ar fi aceea care împarte programele în : - programe S realizate pe baza unei specificaţii şi care dau soluţia problemei; - peograme P, care acceptă anumite incertitudini, folosesc anumite criterii arbitrare şi aproximează lumea reală; - programe E, care automatizează o anumită activitate umană sau socială. Ele sunt strâns legate de mediu şi ca urmare sunt cele mai dispuse la modificări. Programele trebuie să posede eficienţă, fiabilitate, flexibilitate, inteligibilitate şi alte calităţi, dar pentru aceasta ele trebuie să respecte anumite principii: - Principilu conformării (să fie elaborate în conformitate cu cerinţele utilizatorului); - Principiul completitudinii (să realizeze descrierea completă a obiectivelor programului pe toate nivelurile ierarhice de descompunere); - Principiul abstractizării (funcţia programului se realizează ţinând cont de elementele esenţiale şi făcând abstracţie de detaliile nesemnificative); - Principiul modularizării (programele se descompun în subdiviziuni logice – module) Tehnici de programare care s-au conturat până în prezent: - Programarea clasică (fără intenţii de structurare). În acest context se pot omite sau plasa eronat operaţii în cadrul schemei logice, se face apel la instrucţiuni de salt, schema logică este artizanală şi greu de înţeles, implică mult timp pentru depanare. - Programarea modulară: descompunerea programului încă din faza de proiectare în module uşor de întrebuinţat: se poate realiza descendent (top-down) sau ascendent (bottom-up). Se desfăşoară pe trei etape: - modularizarea funcţională;

- modularizarea structurală (vizează structurarea datelor); - modularizarea procedurală (vizează ordinea de execuţie a programelor).

Programarea modulară permite organizarea raţională a activităţii de programare, prin standardizarea unor grupuri de operaţii, creşterea randamentului calculatorului prin economisirea memoriei centrale şi mai permite uşurarea activităţii de depanare şi actualizare a programelor. - Programarea structurată. Se consideră că aceasta oferă o rezolvare standardizată şi structurată, în mod unitar a a programelor, reprezentând o ridicare a activtăţii de programare la nivelul activităţii industriale, fundamentată pe o metodologie ştiinţifică. Unii specialişti consideră însă că programarea structurată este ceva incomplet dacă nu se precizează şi contextul în care este abordată problema ( de exemplu top_down sau bottom-up). În plus, i se impută oarecare lipsă de rigoare precum şi unele contradicţii în formalizarea ei. De exemplu, îi lipsesc criteriile de identificare a elementelor terminale şi deci se confruntă cu imposibilitatea deducerii unui criteriu de finitudine a aplicării ei. 2.1.1 Atributele modulelor Se consideră că modulele au următoarele carcteristici: - sunt formate dintr-un grup de instrucţiuni contigue d.p.d.v. fizic şi sunt executate ca o unitate distinctă; - au începuturi şi sfârşituri bine definite; - de regulă au doar un punct de intrare şi unul de ieşire; - poate fi referit printr-un cod mnemonic sau printr-un nume atribuit de proiectant; - sunt identificabile prin termeni standard ai programării cum ar fi: procedură, subprograme, etc.

9

Un modul are trei atribute de bază: funcţia, logica şi interfeţele. Funcţia constă în transformarea datelor prin procesul de execuţie a modulului. La nivele superioare funcţia se referă la problema de rezolvat, iar la nivele mai inferioare funcţia decade spre specificarea prelucrărilor. În diagramele de structură ale proiectelor soft, un modul este reprezentat printr-un dreptunghi ce poartă denumirea funcţiei îndeplinite. În acest moment nu se acordă atenţie modului de execuţie cu calculatorul, adică implementării funcţiei. În denumirea funcţiilor trebuie evitate conjuncţiile deoarece prezenţa lor ne duce cu gândul la posibilitatea descompunerii modulului în mai multe module. Logica modulului descrie prelucrările care au loc în interiorul acestuia. Dacă funcţia modulului îl vede pe acesta ca pe o cutie neagră, logica modulului îl vede ca pe o cutie albă. Prelucrările se pot descrie sub diverse forme (scheme logice, pseudocod, tabele de decizie, arbori de decizie sau combinaţii), dar toate se referă la algoritmii de prelucrare. Paşii algoritmului se vor transforma în instrucţiuni de programare. Interfeţele sunt conexiuni sau cuplaje între module. Acestea se realizează pe două planuri: - cel al transferării controlului de la un modul la altul; - cel al transmiterii datelor de la un modul la altul. De fapt eficienţa cu care se transferă controlul şi metoda de transmitere a datelor determină eficienţa proiectelor soft. 2.1.2 Structurile de control ale programelor În compunerea schemei logice a modulelor sau programelor, întră trei tipuri de structuri de control: secvenţa (structura secvenţială), selecţia (structura alternativă) şi iteraţia sau repetiţia (structura repetitivă – condiţionată anterior, posterior sau la sfârşit). Aceste structuri pot fi formate din instrucţiuni sau din module şi mai precis din blocuri standard, care vor fi definite puţin mai jos. În elaborarea programelor structurate este necesar să se respecte o serie de restricţii şi anume: - fiecare element (secvenţa, iteraţia,sau selecţia) are un punct de intrare; - fiecare element are un punct unic de ieşire; - elementul de iteraţie permite şi o execuţie cu factor de repetiţie zero, adică excluderea elementului respectiv din execuţie. Fiecare element care respectă restricţiile de mai sus defineşte un bloc standard. De aceea în schema de mai jos folosim blocuri standard. De altfel orice combinaţie de blocuri standard, care respectă restricţiile de mai sus defineşte un bloc standard. Un exemplu de schemă de control a unui program, folosită în proiectul soft, este schema structurii alternative de mai jos: Nu Da C Bloc-2 Bloc-1

Nu insistãm pe celelalte structuri, deoarece ele sunt studiate în cadrul disciplinelor ce vizeazã limbaje de programare. Mai important este sã vedem acum deosebirea dintre o schemã logicã (flow chart) ºi o schemã de struc-turã (structure chart). Dacã sche-ma logicã prezintã

10

2.2 Diagramele de structură În raport cu DFD şi DER, diagramele de structură sunt o replică a acestora la nivelul sistemului, exprimată prin intermediul programelor sau modulelor. Practic prin diagrama de structură, este descrisă arhitectura fizică a modulelor sistemului. Ea scoate în evidenţă într-o formă grafică, modul în care părţile sistemului sau ale programului sunt legate între ele, sub aspectul transmiterii controlului de la una la alta sau a transferului de date. De regulă se foloseşte structura arborescentă inversă. Se poate spune că diagrama de structură redefineşte fluxurile şi prelucrările de date din DFD, convertindu-le în structura componentelor sistemului, prin care să se respecte anumite principii ale proiectării programelor. Diagramele de structură se folosesc şi pentru a arăta structura internă a programelor scrise în limbajele de generaţia treia şi parţial din generaţia patra. Structura programelor scrise în limbaje de programare mai noi, orientate-obiect sau orientate-eveniment, este redată prin întermediul diagramelor stărilor de tranziţie sau pseudocod. Pentru a ilustra modul cum se concepe o diagramă de structură, vom porni tot de la un pseudocod, cum ar fi următorul:

PRELUCRARE_TRANZACTII DO INCEPUT WHILE EXISTA-INCÃ-TRANZACTII DO TRANZACTIE RETURNAND MATERIAL_TRANZ DO VALIDARE_TRANZ TRANSMITAND

MATERIAL_TRANZ RETURNAND BUNA_SAU_REA IF BUNA_SAU_REA ESTE REA DO CORECTARE_TRANZ TRANSMITAND TRANZ_REA RETURNAND TRANZ_OK END IF DO PRELUCRARE_TRANZ_BUNA TRANSMITAND TRANZ_OK RETURNAND REZULTAT DO SCRIE_REZULTAT END LOOP DO SFARSIT Convertită într-o diagramă de structură, prin notaţia Yourdon & Constantine, procedura de mai sus va arăta ca în figura de pe pagina următoare. În această figură, secvenţele în care sunt plasate modulele în pagină, nu au legătură cu ordinea în care acestea vor fi apelate, dar dacă ar coincide, schema ar fi mai uşor de înţeles prin citire de la stânga la dreapta. Parametrii plasaţi de-alungul săgeţilor mari şi care reprezintă date elementare sau structuri de date, sunt scoşi în relief prin săgeţi mai mici, terminate cu un cerculeţ neumplut, în timp ce parametrii care simbolizează semnale de control (de ex. Buna_sau_rea ) sunt reprezentaţi prin cerculeţe umplute la punctul terminal al săgeţilor mici. O structură repetitivă (buclă) este marcată printr-o buclă plasată peste săgeţile ce reprezintă modulele apelate în ciclul respectiv.

11

ma- te- rial_ tranz

Buna_ sau_

tranz-

tranz_

tranz rial_ te

t r a n z_

r e z u l t

PRELUCRARE_ TRANZACTII INCEPUT SFARSIT TRANZACTIE SCRIE_REZULTAT VALIDARE-TRANZ CORECTARE_TRANZ PRELUCRARE- TRANZ_BUNA Apelarea condiţionată (exemplu CORECTARE_TRANZ) este reprezentată printr-un romb mic. Mai usor de realizat pare să fie sistemul Michael Jackson de elaborare a diagramelor de structură, a cărui variantă pentru pseudocodul de mai sus este următoarea: PRELUCRARE_ TRANZACTII PRELUCRARE * INCEPUT TRANZACTII_IN_ SFÂRSIT BUCLÃ o TRANZACTIE VALIDARE_TRANZ CORECTARE_TRANZ PRELUCRARE_ SCRIE_ TRANZ_BUNÃ REZULT În această variantă se folosesc tehnici speciale pentru indicarea repetiţiei şi a elementelor opţionale, dar nu mai apar parametrii dintre module. Modulele care fac parte dintr-o structură repetitivă sunt marcate cu o steluţă, iar cele opţionale, ca efect a unei selecţii, sunt notate cu un cerculeţ în interiorul lor. 2.3 Strategii de proiectare a softului În decursul timpului s-au putut identifica trei strategii de proiectare a softului: - descompunerea funcţională; - strategia centrată pe tranzacţii; - strategia centrată pe transformări. Dintre acestea, descompunerea funcţională care aparţine anilor '70, nu prea mai este luată în consideraţie. Motivul este acela că strategii informatizării văd sistemul prin prisma funcţiilor intreprinderii, pe care le descompun în subfuncţii înrudite, operaţionale, dar informaticienii care sunt legaţi de condiţiile concrete de realizarea a sistemului fizic, văd structura sistemului prin prisma resurselor fizice ale acestuia, adică legat de echipamente şi de potenţele limitate ale acestora şi în consecinţă ei descompun sistemul proiectat după criterii fizice. Ca urmare a celor

12

de mai sus, s-a ales un reper mai uşor accesibil ambelor categorii de persoane implicate în elaborarea sistemului informatic şi anume transformările la care sunt supuse datele. Această orientare a dus la analiza transformărilor. 2.3.1 Analiza transformărilor Metoda este orientată spre fluxul datelor şi încearcă să ofere modalităţi de identificare şi organizare a funcţiilor programelor, care să se apropie mai mult de modelul de structurare a problemei. De fapt, ea este o încercare de schimbare a mentalităţii programatorilor prin aceea că le oferă acestora o altă cale de prestare a activităţii lor. Analiza transformărilor apelează la DFD, pentru modelarea problemei şi pentru a face structura ei cât mai inteligibilă. În acest fel, activitatea de proiectare transferă modelul economic într-o organizare ierarhică a modulelor softului, care să nu se depărteze de primul. Esenţa acestei metode poate fi ilustrată, pornind de la o diagramă abstractă a fluxurilor de date, prin care se modelează o parte a sistemului ce va fi implementat ca un program executabil: În practică diagrame de acest fel vom avea la dispoziţie numai după determinarea unităţilor de prelucrare (secţiunea 4.1) când le vom folosi la proiectarea de detaliu a unităţilor de prelucrare (secţiunea 4.2) LS2 A B F D E C G

LS1 H În această diagramă fiecare cerculeţ reprezintă câte o transformare a datelor din fluxul sistemului, iar LS1 şi LS2 sunt locuri de stocare, cum ar fi fişiere. Proiectul bazat pe fluxul descris prin această DFD, va începe prin identificarea modulului de nivel superior (notat EXEMPLU ABSTRACT) şi care reprezintă funcţia programului în întregimea lui. În continuare se urmăreşte identificarea pe DFD a ramurilor importante de prelucrare a sistemului, urmând ca lor să li se asocieze module de control în diagrama de structură a sistemului. Aceste ramuri sunt în general de trei tipuri: aferente (intrările programului), centrale şi eferente (cele care defluiază dintr-un punct central spre altele periferice, cuprind toate transferurile datelor de ieşire nestructurate, neformatate, produse de sistem, care trec printr-o serie de transformări în vederea obţinerii ieşirilor fizice). Ramurile aferente transformă intrările fizice în intrări logice, pregătite pentru exercitarea funcţiilor principale de prelucrare ale organizaţiei. Un exemplu de transformări aferente ar putea fi introducerea datelor, validarea, sortarea şi alte prelucrări ce premerg constituirea datelor într-o înregistrare care este bună să intre în ramura centrală. Ramura centrală de transformare poate să nu fie unică. Ea constă în tot ce rămâne după identificarea ramurilor aferente şi eferente. În cadrul acestei ramuri, fluxurile datelor de intrare sunt transformate în fluxuri de ieşire.

b i d g e h c j

13

EXEMPLU ABSTRACT Ramuri aferente Ramuri eferente Obţinere Obţinere Creare Plasare Plasare d e g,h g h De regulă modulele aferente sau de intrare din diagrama de structură, sunt poziţionate în stânga şi sub superiorii lor, cele eferente în dreapta şi sub superiorii lor, iar cele de transformare sunt poziţionate între cele aferente şi eferente. În diagrama de structură a programului, ramurile aferente, eferente şi centrale ale fluxurilor de date, ar putea arăta ca în figura de mai sus. În această diagramă avem câte un modul de control pentru fiecare ramură aferentă, fiecare ramură eferentă şi pentru fiecare transformare centrală. Dacă ar fi fost un caz mai complicat ar fi trebuit să avem câte un modul de control pentru fiecare grup logic de transformări. Dacă diagrama de structură a fluxului prezentat mai sus, prin DFD s-ar opri la acest nivel, ea ar fi una superficială. În realitate, ea trebuie dezvoltată pe nivelele inferioare. Practic, după.ce s-a realizat structura de nivel superior a sistemului, se continuă cu procese iterative, de tip Top_down, pentru fiecare ramură a diagramei de structură. Fiecare cerculeţ următor al diagramei fluxurilor de date devine baza următorului set de module la nivel inferior al diagramei de structură. Procesul încetează la nivelul cel mai de jos al ramurii respective, adică acolo unde pot fi identificate intrările (pentru ramurile aferente) şi ieşirile (pentru ramurile eferente). Astfel pentru ramura iniţiată de modulul Obţinere d, fluxul de date d este generat de procesul B, care la rândul său foloseşte ca intrare fluxul de date b. Ca urmare, Obţinere d poate fi descompus în două procese: unul de transformare a lui b în d (marcat pe DFD de transformarea B) şi celălalt de obţinere a intrării b în procesul de transformare (B). Ca urmare a acestui raţionament, ramura iniţiată cu modulul Obţinere d, va evolua astfel:

Ramura transformãrii

MODULE DE CONTROL PENTRU FIECARE RAMURÃ DE PROGRAM

14

a

EXEMPLU ABSTRACT Se vede cum modulul Obţinere d recepţionează un d prin apelarea modulului B, dar la apelarea lui B, el

d trebuie să-i transmită acestuia pe b, or ca să aibă un b, Obţinere trebuie să apeleze modulul Obţinere b. d Observăm din DFD că Obţinere b ca să obţină b, ar d trebui să apeleze modulul A, dar nu-l poate apela pe A dacă nu-i poate oferi un a şi pentru aceasta trebuie să apeleze Obţinere a. Toată această înlănţuire de b b d evenimente, face necesar să-i adăugăm modulului următoarea secvenţă Obţinere b Obţinere a Modulul Obţinere e va avea o structură asemănătoare cu cea a modului Obţinere d, doar că în loc de b şi respectiv B, acolo vor fi implicaţi c şi C, iar în ce priveşte al doilea nivel, reprezentat în cazul lui Obţinere d prin a şi respectiv A, un asemenea nivel nu mai este necesar, deoarece transformarea C esete prima pe această ramură, nu ca B care era precedată de A. În ce priveşte ramurile eferente, cum ar fi cea iniţiată de modulul Plasare h va avea în prima treaptă următoarea dezvoltare: EXEMPLU ABSTRACT h Plasare h h j j G Să remarcăm că această diagramă va fi modificată prin apelare la unele criterii de evaluare, ce vor fi prezentate spre sfârşitul acestei secţiuni. Pentru reprezentarea în diagrama de structură a ramurilor transformării centrale, s-a plecat de la ideea că pentru fiecare cerc din mijlocul diagramei fluxului de date trebuie definit câte un modul separat. De cele mai multe ori, ramurile transformării centrale sunt descompuse după aceleaşi reguli ca ale descompunerii funcţionale. Aici se pune problema stabilirii unor criterii după care

B

A

Plasare

Ulterior, ca ºi ramura iniþiatã de modulul Obþinere d, ramura Plasare h va fi dez-voltatã ºi pe nivelul al doilea pentru a-l plasa pe j lui H, iar acesta îl va produce pe k, ce va face obiectul modulului Plasare k Aplicând raþionamente

15

să putem şti când am ajuns la un nivel acceptabil pentru a opri descompunerea . Se spune că descompunerea este completă atunci când: - nu mai există subactivităţi identificabile care să poată fi adăugate nivelurilor inferioare; - există posibilitatea folosirii unei rutine sau a unei biblioteci standard pentru realizarea funcţiilor conţinute de un modul identificat de proiectant; - modulele sunt atât de mici, încât au atins un nivel la care criteriile cuplării, coeziunii şi dimensionării (care vor fi descrise în continuarea acestei secţiuni), ar putea fi încălcate prin continuarea partiţionării.

16

EXEMPLU ABSTRACT

d h e d,e g,h g Obţinere Obţinere Creare Plasare Plasare d e g,h g h b d c e d,e g,h g h b e f f i i i j j Obţinere B Obţinere C D E F Plasare G Plasare b c i j a b j a k k Obţinere Plasare a k k

Prima formă a diagramei de structură bazată pe analiza transformărilor

A H

17

2.3.2 Analiza tranzacţiilor (operaţiunilor) Tranzacţiile au intrat în atenţia proiectanţilor de soft pentru că în unele domenii de activitate cum ar fi cel bancar, operaţiile sunt mai la îndemâna beneficiarului decât transformările, iar d.p.d.v al proiectanţilor de soft ele sunt avantajoase pentru că în practică, multe operaţii prezintă asemănări în prelucrare şi dacă procesul este analizat pe baza tranzacţiilor, se identifică posibilităţi de refolosire a unor module program în prelucrarea mai multor tranzacţii ceea ce reduce volumul de muncă necesară pentru scrierea programelor. Diagrama de structură a unui proiect centrat pe tranzacţii arată în principiu ca cea de mai jos:

Centrul de tranzacţie Proces tip 1 Proces tip 2 Proces tip 3 Structura A Structura B Structura C Structura D Structura E a procesului a procesului a procesului a procesului a procesului Proces detaliat Proces detaliat Proces detaliat 1 2 3 În această diagramă modulul superior evidenţiază rolul tranzacţiei, iar rombul simbolizează posibilitatea exprimării opţiunii pentru unul dintre modulele situate pe nivelul următor (cel al proceselor). La acest nivel, fiecare modul de prelucrare "cunoaşte" detaliile intime ale unei tranzacţii (ce date foloseşte, care sunt paşii de prelucrare) dar nu ţine cont de celelalte tranzacţii. De acest lucru se ţine cont începând cu nivelul următor, când sunt efectuate prelucrările reale ale tranzacţiilor şi unde încep să se caute asemănări, între tranzacţii, în vederea elaborării unor module comune, eventual poliforme. În varianta centrată pe tranzacţii, DFD corespunzătoarea diagramei de structură, trebuie să indice punctele de ramificare paralelă a fluxurilor de date ce vor trata fiecare tip de tranzacţie. Ca urmare, o secvenţă de diagramă a fluxurilor de date va arăta ca cea de pe pagina următoare: Proces tip 1 Tip 1 Tranzacţii Tip 2 Proces tip 2 Tip 3 Proces

tip 3

18

Modelul de trecere de la diagrama fluxurilor de date la diagrama de structură este similar celui folosit în analiza transformărilor. Este de datoria proiectantului să recunoască situaţiile în care intervin tranzacţii multiple, precum şi componentele inerente unei prelucrări logice dintr-o situaţie dată din unitatea studiată. În ce priveşte tranzacţiile comune, cele mai reprezentative exemple sunt cele legate de actualizarea fişierelor, introducerea datelor on-line, programele orientate pe meniuri, ş.a. Astfel programele de actualizare se pot materializa în una din următoarele variante: - o tranzacţie de adăugare de noi înregistrări în fişier; - o tranzacţie de modificare a valorilor din anumite câmpuri ale înregistrării; - o tranzacţie de ştergere a unor înregistrări. Ca urmare, un singur flux de intrare, va fi transferat pe una dintre cele trei rutine, în funcţie de tipul tranzacţiei. 2.3.3 Recomandări pentru proiectarea programului Putem concluziona de pe acum că se disting cel puţin trei metode de proiectare a programelor: cele structurate pe funcţiile intreprinderii, cele structurate pe transformări şi cele structurate pe tranzacţii. La acestea se mai poate adăuga o metodă orientată spre date şi mai exact spre structura datelor de ieşire ale programelor care se presupune că trebuie să reflecte structura datelor organizaţiei. Totuşi metoda nu este răspândită, aşa că ne vom concentra atenţia supra primelor trei. Indiferent de metoda de proiectare a programelor folosită, softul de aplicaţii trebuie să urmărească atingerea unor performanţe cum ar fi: - funcţionare corectă; - să respecte specificaţiile de realizare; - să fie sigur, mentenabil, uşor de folosit, de implementat şi de testat; - să folosească eficient resursele sistemului informatic; - să respecte planificările calendaristice şi bugetare; - să fie uşor adaptabil diverselor medii de operare şi programare. Tot indiferent de metoda de proiectare a programelor folosită, se consideră că în elaborarea programelor ar trebui parcurşi, în principiu, paşii următori: - realizarea unei prime structuri pe componente a programelor, printr-o schemă logică de sistem, pe baza diagramei fluxurilor de date, prin apelarea la unităţile de prelucrare (proceduri); - examinarea parţială a DFD asociate fiecărui program al schemei logice a sistemului; - pentru fluxurile mari de date, se va aplica analiza transformărilor, ca un prim pas al descompunerii programului în rutinele sale principale de prelucrare; - pentru programele ce nu se pretează partiţionării corecte prin metodele tranzacţiilor şi transformărilor, se începe cu descompunerea funcţională; - de la caz la caz, se va continua cu descompunerea programelor după principiile analizelor funcţionale, ale transformărilor sau ale tranzacţiilor. Se va trece apoi la utilizarea structurilor de control fundamentale ale programării, pentru realizarea sistemului; - după ce s-a realizat proiectul se va trece la aplicarea criteriilor de evaluare a obiectivelor proiectului ( a întregii structuri), criterii de care ne vom ocupa în continuare. Dacă după aplicarea acestor criterii mai este cazul, se va efectua ultima restructurare a sistemului. 2.3.4 Evaluarea obiectivelor proiectelor software Evaluarea calităţii proiectului soft se referă atât la caracteristicile externe cât şi la cele interne ale modulelor, surprinse prin criteriile (conceptele) de cuplare şi coeziune. a) Cuplarea este măsura gradului în care modulele programelor sunt interconectate. Pentru uşurinţa implementării şi întreţinerii, se recomandă ca gradul cuplării să fie redus. Există cinci tipuri de cuplări:

19

- prin date elementare. Cuplările datelor elementare din module, conectate printr-un control activ, înseamnă doar transferarea datelor elementare necesare. - prin date grupate. Presupune transferarea datelor grupate sub formă de structuri de date sau chiar înregistrări întregi, ceea ce implică riscul ca nu toate informaţiile transmise să fie şi necesare ; - cuplare prin informaţii de control: aceasta presupune să se transmită de la un modul la altul şi coordonatele prelucrării, de ex. modulul precedent să transmită modului următor dacă a fost constatată o eroare şi dacă da ce eroare anume, pentru ca modulul următor să ştie ce mesaj de eroare să dea. Desigur în acest caz modulele devin dependente unele de altele; - cuplare comună, când două sau mai multe module accesează în comun aceleaşi date elementare aflate într-un loc comun, cunoscut şi ca bloc de date. Interdependenţa între module este în acest caz destul de mare; - cuplare prin conţinut. Cea mai de nedorit formă de cuplare: ea duce la implicarea directă a unui modul în intimitatea prelucrărilor altui modul. De ex. un modul poate să schimbe datele altuia, sau şi mai grav chiar să schimbe instrucţiunile acestuia. b) Coeziunea este măsura legăturilor interne dintre componentele de prelucrare sau instrucţiuni, la nivelul unui modul. Altfel spus, se urmăreşte modul în care instrucţiunile dintr-un modul sunt folosite pentru realizarea aceleiaşi funcţiuni. Gradul de coeziune ar trebui să fie cât mai ridicat. Există şapte niveluri ale coeziunii. În ordinea descrescătoare a coeziunii, aceste nivele sunt: funcţional, secvenţial, comunicaţional, procedural, temporal, logic şi coincidental. - coeziune funcţională, presupune ca modulul cu un nume cât mai sugestiv în ce priveşte funcţia sa, să se comporte ca o cutie neagră. Adică se cunoaşte cu precizie de ce date are nevoie, cum trebuie să fie ele structurate şi se cunoaşte şi ce rezultă. Modulul poate fi folosit fără a se cunoaşte prelucrările sale interne. - coeziunea secvenţială, presupune ca modulul să realizeze funcţii multiple de prelucrare asupra aceloraşi structuri de date. De ex. calculează media studentului, calculează nivelul anului de studii şi aplică criteriul de eligibilitate pentru bursă. - coeziune comunicaţională: se întâlneşte la modulele ce realizează funcţii multiple de prelucrare ce presupun acelaşi set de date de intrare şi de ieşire. În diagrama fluxurilor de date, această coeziune este reprezentată sub forma unor funcţii simultane de prelucrare. De ex. un modul care verifică datele ce lipsesc dintr-o tranzacţie, afişează tranzacţia pe ecran şi realizează o copie a acesteia într-un fişier. Cu alte cuvinte modulul realizează mai multe funcţii pe aceeaşi structură de date - coeziune procedurală: modulul conţine elemente grupate pe baza fluxurilor de control din cadrul programului, adică funcţii independente, reunite doar pentru a asigura transferul controlului de la o funcţie internă la alta. Cazul modulelor ce conţin blocurile standard de control: secvenţa, repetiţia şi selecţia. De exemplu un modul ştie să facă actualizare sub cele trei forme: adăugare, ştergere sau modificare şi în funcţie de codul operaţiunii pe care-l primeşte, va transmite controlul unuia din cele trei module de care dispune. - coeziune temporală: se referă la module dependente de timp, cum ar fi deschidere fişier, initializare variabile, citirea primei înregistrări - module care trebuie executate toate, fără intercalarea altor module între ele, de fiecare dată, pe măsura executării programului. - coeziune logică: se realizează prin includerea elementelor unui modul într-o categorie generală cum ar fi de intrare-ieşire, de corectare a erorilor, rutine de editare, etc. dar în realitate fiecare din elementele sale are funcţii distincte. Coeziunea logică poate fi evitată printr-o descompunere completă a programului. Uneori ea este folosită intenţionat pentru a evita unele probleme de proiectare legate de realizarea legăturilor cu mediul extern, cu hardwar-ul sau softwar-ul, respectiv includerea funcţiilor de intrare-ieşire într-un singur modul.

20

coeziunea coincidentală presupune existenţa unui număr redus de legături sau a nici unei legături între elementele unui modul. De ex. din motive de utilizare eficientă a memoriei,

- proiectantul pentru a evita redondanţa în codificare a lăsat un singur modul capabil să facă o anumită operaţie, dar nu ştie care este structura problemei asupra căreia se va executa modulul. Ulterior, dacă sunt necesare modificări asupra proceselor de prelucrare, va fi greu de găsit setul de instrucţiuni corespondent funcţiilor incluse într-un astfel de modul. Un modul care are o coeziune coincidentală nu funcţionează ca o cutie neagră, pentru că proiectantul trebuie să cunoască detaliile interne de funcţionare a unui modul pentru a putea proiecta componentele cu care se află în legătură.

3. Proiectarea sistemelor distribuite 3.1 Aspecte generale privind sistemele de prelucrare distribuită a datelor Un sistem de prelucrare distributiă a datelor presupune existenţa a două sau mai multe sisteme independente de prelucrare a datelor, numite noduri, având putere proprie locală de prelucrare şi stocare, interconectate într-o configuraţie de reţea. Într-un astfel de mediu cooperează trei componente tehnologice distincte: prelucrarea datelor, comunicarea datelor şi reţeaua de calculatoare. Sistemul de prelucrare distribuită a datelor trebuie să dispună de un sistem de prelucrare automată a datelor caracterizat de: - posibilitatea prelucrării independente; - o configuraţie de reţea; - posibilitatea transferurilor de date folosind sisteme de comunicaţie partajate; - un obiectiv comun de realizat. 3.2 Stabilirea obiectivelor şi selecţia sistemelor de prelucrare distribuită a datelor 3.2.1. Obiectivele proiectului trebuie să fie enunţate în scrisoarea de intenţie a echipei manageriale a beneficiarului. ele pot fi clasificate în obiective financiare şi funcţionale. D.p.d.v financiar se urmăreşte maximul de profit cu minimum de cheltuieli, iar d.p.d.v. funcţional, scopul este acela de realiza un sistem cât mai eficient, deci cu rezultate cât mai bune. În ciuda faptului că obiectivele financiare sunt cuantificabile, iar cele funcţionale nu, efectele avantajelor necuantificabile se regăsesc în situaţia contului Profit şi Pierdere a firmei. 3.2.2 Costurile sistemului de prelucrare distribuită a datelor În cazul sistemelor mari de prelucrare distribuită a datelor (p.d.d.) trebuie luate în calcul atât costul d.p.d.v al utilizatorului, cât şi costul d.p.d.v al companiei care prestează serviciul. În aceste cazuri se descompun sistemele în module mai mici, bine definite, în care să se poată controla necesarul de echipament şi de software pentru subsistemele de p.d.d. şi pentru comunicarea lor. În continuare costul fiecărui modul, va fi descompus în costuri iniţiale şi costuri funcţionale sau operaţionale, sau de exploatare. a) Costurile iniţiale. În cazul sistemului de comunicaţie a datelor se pleacă de la costul închirierii sau luării în leasing a componentelor necesare atingerii obiectivelor. La acesta se adaugă costul fiecărui loc de muncă, cheltuielile de întreţinere şi menţinere în stare funcţională a fiecărui echipament. Mai trebuie avute în vedere costurile procesoarelor (calculatoarelor), perifericelor, costurile cablării şi costurile softului. b) Costurile operaţionale. Acestea pot fi împărţite în: - costurile distribuirii datelor; - costurile cu personalul; - costurile funcţionării echipmentelor din sala calculatoarelor (dacă este cazul); - costurile întreţinerii sistemului.

21

3.2.3 Performanţele sistemului. Sunt apreciate prin prisma productivităţii şi eficienţei sistemului şi sunt o funcţie a: timpului de răspuns, randamentului, calităţii serviciilor oferite utilizatorilor şi a nivelului serviciilor. Calitatea serviciilor vizează siguranţa sistemului, fidelitatea sistemului, integrarea sistemului ( la nivel nod şi la nivel subsisteme de comunicaţie), controlul şi acceptabilitatea. 3.2.4 Criterii de selecţie a sistemului de prelucrare distribuită a datelor. Sistemul propus trebuie să fie fezabil d.p.d.v tehnic şi eficient d.p.d.v al costurilor de prelucrarea automată a datelor şi a comunicaţiilor din sistem. Performanţele sistemului mai sunt influienţate şi de alţi factori cum ar fi: timpul de răspuns, randamentul, disponibilitatea, siguranţa ş.a. Principale criterii de selecţie rămân totuşi timpul de răspuns, costul şi securitatea. Timpul de răspuns depinde de întârzierile produse în componentele aflate la distanţă, întârzieri ale liniei de transmisie şi întârzieri la centrul de prelucrare a datelor. În ce priveşte securitatea datelor, se au în vedere ameninţările şi măsurile de protecţie. Amenintările pot proveni din partea componentelor sistemului, a personalului neloial al firmei, slăbiciunea procedurilor de protecţie şi de penetrarea reţelei de comunicaţie (prin ascultarea firelor sau prin captarea radiaţiilor semnalelor transmise). Măsurile de protecţie vizează securitatea fizică, securitatea personalului, criptarea informaţiilor importante, studierea tehnicilor specializate ale intruşilor, suprimarea radiaţiilor compromitătoare, securitatea liniilor de comunicaţie şi securitatea sistemelor de prelucrare automată a datelor. (Vezi [15] "Firewalls...") 3.3 Metodologia proiectării sistemelor de p.d.d Aceasta are două componente majore: - proiectarea nodurilor sistemului, care continuă cu proiectarea propriilor sisteme de prelucrare automată a datelor ; - proiectarea reţelei de comunicaţie a datelor (proiectarea fiecărei legături de date şi a schemei de ansamblu a întregii reţele cu topologia adecvată) 3.3.1 Proiectarea nodurilor sistemelor de p.d.d. - identificarea nodurilor; - identificarea cerinţelor aplicaţiilor locale sau la distanţă a datelor locale şi globale, a modurilor de prelucrare şi a utilizatorilor sistemului de la fiecare nod; - identificarea cerinţelor locale de comunicare a datelor; - selectarea echipamentelor de prelucrare ale nodurilor; se va ţine seamă de configuraţia sistemului şi de caracteristicile tehnice ale transmisiilor. Acestea din urmă sunt următoarele: - modul de transmitere (semi-duplex, full-duplex); - tehnica transmisiilor (asincronă, sincronă);

- viteza de transmisie; - codul transmisiei (ASCII sau EBCDIC); - formatul de transmisie a mesajului (caracter-cu-caracter, linie-cu-linie, bloc-cu-bloc); - protocolul de comunicaţie(ASCII, BSC, SDLC, altele); - tipul legăturii fizice (punct-la-punct sau multipunct); - tipul microprocesoarelor folosite(Intel, Motorola ş.a).

Selectarea sistemelor vizează selectarea terminalelor, a calculatorului, a unităţilor de memorie externă, a echipamentelor de intrare/ieşire. 3.3.2 Echipamentele de transmisie a datelor către noduri. - selectarea procesorului de comunicaţii (un echipament special al unei reţele folosit pentru separarea funcţiilor fizice şi logice ale reţelei de aplicaţiile utilizatorului); - selectarea modemului;

22

- selectarea multiplexoarelor; 3.3.3. Proiectarea subsistemului de comunicaţie - proiectarea liniilor de date (constituirea fizică a liniilor de date, selectarea protocoalelor de linie); - proiectul reţelei; - proiectul topologiei reţelei; - selecţia componentelor de comunicaţie; - interfaţarea (inter-reţele şi intra-reţele). 3.3.4 Elemente de proiectare a reţelelor De regulă arhitectura unei reţele trebuie să răspundă cerinţelor de interconectibilitate completă pentru toate resursele sistemului, prin apelare la protocoale şi componente soft adecvate. a) Tehnici de concepere a arhitecturii reţelelor. Aceste tehnici vizează structura şi protocoalele sistemului. Se folosesc următoarele tehnici: - stratificarea şi modularizarea . În faza de implementare, fiecare strat va fi tratat independent. - abstractizarea stratului: se crează un nivel de abstractizare în fiecare strat al reţelei - mecanismul funcţional: o funcţie specifică dintr-o aplicaţie dată, sau una de folosire a sistemului, să fie mutată la nivelul utilizatorului; - protocoale în protocoale (imbricarea protocoalelor): protocoalele sunt structurate unul în interiorul altuia ; - strat în strat: se concep straturi/niveluri ale arhitecturii reţelei şi protocoalelor corespunzătoare concepute cu substraturi sau subseturi; - folosirea resurselor: sunt avute în vedere resursele sistemului şi modulele funcţionale de comunicare şi identificare. Ca urmare, fiecare sistem sau subsistem al reţelei ştie dacă poate să transmită sau nu o anumită informaţie către altă componentă din reţeaua sistemului; - metoda sistemelor integrate: trebuie să avem imaginea funcţionării de ansamblu a sistemului, în aşa fel încât toate nodurile să funcţioneze în cadrul unei structuri date, iar arhitectura să le trateze fie ca procesoare inteligente locale, fie ca nişte comutatoare b) Criterii de selecţie a reţelei. Trebuie să coreleze cerinţele utilizatorilor cu cerinţele reţelei şi se materializează prin găsirea protocoalelor, a cerinţelor părţii de legătură cu alte reţele, a vitezei de transmisie, a protejării împotriva erorilor, etc 3.3.5 Proiectarea topologiei reţelei. Aceasta afectează în mod direct costul ei de funcţionare. La proiectarea topologiei reţelei sunt necesare sinteza traficului de date şi sinteza reţelei. a) Sinteza traficului de date, presupune colectarea informaţiilor necesare estimării gradului de încărcare a traficului de date al sistemului. Ulterior acesta va fi transformat astfel încât să poată fi utilizat în procesul de sinteză al reţelei. b) Sinteza reţelei. Reţeaua este alcătuită din noduri şi linii de legătură. Nodurile pot fi finale sau centrale. Legăturile dintre centre se numesc intermachine trunk (IMT) iar cele care duc spre nodurile finale linii de acces (acccess line). Sinteza reţelei vizează costurile reţelei, optimizarea costurilor, dar se materializează în numărul de centre ale reţelei, plasamentul acestora, alocarea fiecărui nod final la un centru şi structura ierarhică a căilor pe care circulă fluxul de date ale traficului 3.3.6 Selectarea posibilităţii de comunicaţie vizează selectarea posibilităţii de comunicaţie (analogice sau digitale, comutate sau închiriate, terestre sau prin satelit, etc.) selectarea unităţii publice de telecomunicaţii (selectarea companiei) sau selectarea liniilor private. 3.3.7 Aspecte ale proiectării reţelelor locale: - controlul reţelei (flexibilitatea reconfigurării, urmărirea stării reţelei, detectarea căderilor şi izolarea lor, managementul reţelei);

23

- performanţele reţelei: siguranţa, disponibilitatea şi funcţionalitatea (cauzele defecţiunilor, punctele sensibile ale reţelelor, metode de control ale defecţiunilor reţelei). - copiile de siguranţă; - sisteme de arhivare a datelor. 3.3.8 Interconectări de reţele. Mare atenţie trebuie acordată incompatibilităţilor generate de nestandardizarea echipamentelor şi protocoalelor din domeniile comunicării şi prelucrării datelor. Acestea pot genera probleme intrareţea şi probleme interreţea. - interfaţarea în reţea presupune conexiunea între echipamente şi acordul echipamentelor ce trebuie să comunice printr-un protocol comun de comunicaţie. - interfaţarea interreţele; se disting două situaţii:

- reţele ce au aceleaşi protocoale interne şi cerinţe identice de interfaţare (reţele omogene); - reţele ce au protocoale interne diferite şi cerinţe de interfaţare diferite (reţele neomogene).

Un caz de reţele neomogene dar şi de lungă distanţă este interconectarea LAN-uri cu reţele pe distanţă lungă. Acestea se vor aborda prin prisma accesului la reţea, a folosirii serviciilor reţelei şi a folosirii funcţiilor protocoalelor. 3.4 Particularităţile sistemelor file-server şi client/server 3.4.1 Arhitectura file-server presupune mai multe staţii de lucru şi un server în care se vor afla bazele de date şi aplicaţiile folosite în comun de celelalte calculatoare, toate legate într-o reţea locală. Toate operaţiunile asupra datelor se efectuează la staţiile de lucru, care lansează serverului cereri de date. Serverul este văzut de staţiile de lucru ca un hard disc suplimentar; în plus el oferă resurse suplimentare (unităţi de discuri, imprimante, etc.) şi aplicaţii de comunicare (de ex. Poşta electronică). Dacă se foloseşte un SGBD, fiecare staţie poate folosi programele de aplicaţii SGBD ca şi cum i-ar aparţine. Pentru aceasta trebuie să existe mai multe copii ale bazei de date şi acestea pot fi exploatate concurenţial de staţiile de lucru. Pentru o prelucrare de date staţia îşi trage fişierul de care are nevoie de pe hardul serverului si-l foloseşte pe hardul său. Softul de pe file_server crează cozi de aşteptare a cererilor. Controalele pe linia securităţii, precum şi blocarea fişierelor sau a înregistrărilor, sunt efectuate prin PC-uri, ceea ce conduce la un proces complex de dezvoltare a aplicaţiilor multi-server. Utilizarea reţelelor locale bazate pe file_server sunt limitate de: - un transfer excesiv de date; - nevoia utilizării unor staţii de lucru foarte puternice; - descentralizarea controlului datelor. 3.4.2 Arhitectura client/server este o îmbunătăţire esenţială a sistemelor bazate pe reţele locale. Aici prelucrările din aplicaţii sunt împărţite între client şi server. Clientul rezolvă problema administrării interfeţei-utilizator şi prezentarea datelor, iar serverul stochează datele şi dă acces interogărilor primite. Acum serverul nu mai dă tot fişierul ci numai partea selectată prin interogarea transmisă de client. Mai mult decât atât, uneori serverul lansează pe client şi programul necesar pentru a executa o anumită operaţie. Cu alte cuvinte a scăzut volumul datelor transferate, dar a apărut şi un transfer de soft. Toate operaţiunile de restaurare a datelor, de securitate şi de gestionare a accesului concurenţial sunt centralizate la server. În cazul SGBD, funcţiile centrale sunt numite DataBase-Engine sau Back-end, iar cele bazate pe client se numesc Front_end. Serverul trebuie să fie mult mai puternic decât în cazul arhitecturii file-server. Un avantaj al arhitecturii bazate pe client/server constă în posibilitatea decuplării mediului clientului de cel serverului. Astfel un client poate folosi Quattro Pro, Foxpro, dBase IV sau orice alt limbaj de generaţia patra, care are o interfaţă a programului de aplicaţii (API) pentru motorul bazelor de date. Cele mai populare medii API utilizate în prezent sunt:

24

SQL Link (pentru Paradox), DataEase SQL (pentru limbajul DataEase), @SQL (Add-In) din LOTUS, Q+E (Add-In) din Excel , SQL Windows, Power Builder, Object/l, s.a. 3.5 Administrarea datelor în sistemele distribuite. Când staţiile sunt dispersate geografic, bazele de date pot fi stocate pe un calculator central, dar acum se folosesc baze de date distribuite pe o reţea de calculatoare locale. Punctele de lucru pot fi dispersate la nivelul unei clădiri sau la nivelul întregii planete. De fapt este vorba de o singură bază de date dispersată fizic pe calculatoarele reţelei locale. Apare astfel conceptul de transparenţă a amplasării (location transparency) în sensul că un utilizator care are o cerere de date nu trebuie să ştie în ce loc se află acele date. 3.5.1 Opţiuni de distribuire a bazelor de date. Există patru strategii principale de distribuire a bazelor de date: - replicarea (reproducerea sau copierea) datelor; presupune păstrarea a câte unei copii la fiecare nod al reţelei - partiţionarea (separarea) orizontală; unele linii ale tabelei sunt plasate într-un nod, altele în locuri diferite; - partiţionarea (separarea) verticală; presupune transfer de coloane (de câmpuri) pe principii relaţionale; - combinaţii ale primelor trei forme. 3.6 Soluţii de proiectare a sistemelor distribuite Există tendinţa trecerii spre sisteme cu date şi prelucrări distribuite; Forme avansate ale arhitecturii client/server pleacă de la existenţa a trei componente (funcţii) esenţiale ale oricărui sistem informaţional: managementul datelor, prezentarea datelor şi analiza datelor. Diferitele forme de arhitecturi distribuie funcţiile de mai sus fie numai clientului, fie numai serverului, fie amândorora. Ca urmare s-au conturat 6 variante de arhitecturi client/server: - prezentare distribuită; (reformatare date la utilizator) - prezentare la distanţă; (date formatate pe comandă la server) - managementul datelor la distanţă; (datele primare de pe server sunt restaurate şi analizate) - funcţie distribuită; (datele primare selective de pe server sunt restaurate şi analizate pe server şi apoi transmise staţiei) - baza de date distribuită; (datele restaurate sunt analizate atât la server cât şi la client) - prelucrarea distribuită. (datele sunt restaurate de pe server pentru analiză, apoi transmise clientului pentru analiză şi prezentări).

a) Descrieri si definitii (se fac referiri la următoarele aspecte): 4. Documentaţia fazei de proiectare fizică

- proiectarea strategiilor de prelucrare distribuită: modalitătile în care utilizatorul poate să dispună de date si facilităti de prelucrare distribuite în retea. În detaliu aceste modalităti vor fi prezentate în MFC (punctul b) - proiectarea fisierelor fizice si a bazelor de date: aceasta vizează descrierea modului în care datele vor fi stocate si accesate în/din memoriile secundare si cum se va asigura controlul lor pentru a se oferi o securitate maximă. Concret solutia va fi dezvoltată la punctul c (MFD). - proiectarea structurii sistemului si a programelor: sunt descrise programele si modulele acestora urmărindu-se ca ele să fie în concordantă cu diagramele fluxurilor de date sau cu MLP (depinde de metoda de abordare a sistemelor informationale folosită) si cu celelalte piese ale documentatiei realizate în etapele anterioare;

25

În legătură cu proiectarea fizică trebuie avut în vedere că dacă în fazele precedente s-au căutat răspunsuri la întrebarea "Ce trebuie să facem?" acum trebuie să răspundem la întrebarea "Cum vom face ce ne-am propus în etapele anterioare?". Fiind ultima fază înainte de implementare, proiectarea fizică este ultima sansă de punere de acord a solutiilor noastre cu cerintele utilizatorului dar si cu realitatea în care va functiona sistemul. b) Modelul fizic de comunicatie (MFC) Generarea concretă a unui model fizic de comunicatie (MFC) presupune realizarea în principiu a următoarelor elemente specifice:

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

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

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

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

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

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

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

1. ENTITATEA Relatia fizică Valute C:\Exchange\valute.dbf 2. ACCESUL ªI SPATIUL FIZIC

Indexare Spatiul fizic ocupat chei Fisier index RCS R Total octeti CP CS

COD_V -

Valute.ndx -

18 1000

3. CONSTRÂNGERI STRUCTURALE REFERENTIALE INTERRELATII identificator relatie CP CE TRANZ Nr_bsv Cod_v MISC Nr_doc Cod_v 4. STRUCTURA ÎNREGISTRÃRII Nr. Identificator Tip, lungime Conditii de validare

26

1 2 3 4

COD_V CURS_CUMP CURS_V PROC_C

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

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

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

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

Tip Denumire Identificator I Buletin de cumpărare BC Asigură introducerea datelor

aferente cumpărărilor de valută

19

- se include macheta fiecărui formular specificat în tabelul de mai sus. Meniuri de prelucrare

Se face precizarea că meniul principal de prelucrare pentru aplicatia … este format din următoarele optiuni si suboptiuni descrise în ordinea utilizării acestora: (urmează un tabel cu structura celui de mai jos, exemplificat pe începutul tabelului specific unei case de schimb valutar): Optiunea Suboptiunea Nivel Descriere Figura PSV - 1 Crearea, schimbarea si eliminarea PSV 1 PSV schimbare 2 Schimbarea PSV activ 2

PSV creare 2 Crearea unui PSV nou 3 PSV eliminare 2 Stergerea unui PSV 4

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

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

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

Lungimea si lătimea hârtiei folosite

Culori 2 Parametrizarea culorilor pentru ecran si date Semnal sonor Stabilirea frecventei si duratei semnalului sonor

Fisiere - 1 Descrierea atributelor bazei de date Fig. 11 Devize 2 Declararea devizelor (valutelor): cod, denumire,

contul Casa în valută 5314, precum si: data cursu-lui, cursul BNR, curs cumpărare, curs vânzare, etc.

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

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

27

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

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

C:\SICSV

CLIENTI.dbf

MISC.ntx MISC.dbf

TRANZIT.ntx TRANZIT.dbf VALUTE.ntx VALUTE.dbf CLIENTI.ntx

BC.lbx BV.lbx BMITB.lbx BMITPSV.lbx BMIAI.lbx BMETB.lbx BMETPSV.lbx BMEAE.lbx BMESI.lbx CON:vdfi, vdfe C:\SICSV.prg C:\SICSV\CLIENTI.dbf C:\SICSV\ CLIENTI.ntx C:\SICSV\VALUTE.dbf C:\SICSV\VALUTE.ntx C:\SICSV\TRANZ dbf C:\SICSV\TRANZ.ntx C:\SICSV\MISC.dbf C:\SICSV\MISC.ntx

Introducere si validare tranzactii valutare. Listarea Iesirilor SICSV Configurare BD

În continuare se mai specifică: - ordinea de apelare a optiunilor meniului principal care este urmatoareA

4 PSV

5 CONFIGURARE

1 FISIERE/BD

2 BULETINE

3 LISTARI

8 REVENIRE DOS

- configuratia minimă a calculatorului pe care urmează a se instala aplicatia; - comenzi prin care se face instalarea si comenzi de lansare a aplicatiei în

exploatare. Dacă sunt necesare anumite comenzi ce trebuie să fie prevăzute în fisiere CONFIG.SYS, se vor specifica si acelea.

LPT1:

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

JCV.frx JVV.frx RS.frx BC.frx BV.frx RBNR.frx RM.frx

6 UTILITARE 7 INTRETINERE

1

Cursul_III_7 Implementarea sistemelor informatice.

Manuale ce trebuie să însoţescă un produs soft 1. Implementarea. Etapa de implementare finalizează activitatea de proiectare şi realizare a sistemului informatic, având ca obiectiv testarea funcţionării noului sistem informatic în condiţii concrete şi cu date reale, pentru aducerea acestuia la stadiul de exploatare efectivă. În cadrul acestei etape se testează, se verifică şi se asimilează de către beneficiar toate soluţiile stabilite în etapele anterioare şi se validează rezultatele obţinute. Implementarea începe în momentul în care toate componentele sistemului informatic au fost testate individual şi permit asamblarea lor la nivelul fiecărei unităţi funcţionale. Aceste componente înglobează atât unităţile de prelucrare prin intermediul cărora are loc realizarea efectivă a funcţionalităţii sistemului informatic cât şi procedurile manuale folosite pentru pregătirea şi testarea documentelor în vederea prelucrării. Legat de testarea procedurilor manuale are loc efectuarea corecţiilor, interpretarea şi utilizarea rezultatelor. Implementarea se încheie cu punerea în funcţiune a sistemului proiectat şi cu acceptarea de către beneficiar a raportului de implementare. Activitatea de implementare presupune anumite particularităţi în funcţie de modul în care a fost conceput sistemul informatic : - cu produse program specifice beneficiarului; - cu produse program generalizate; - mixte. Varianta de implementare cu produse program specifice beneficiarului presupune parcurgerea următoarelor faze: - asigurarea condiţiilor de implemetare; - executarea procedurilor de conversie necesare în cazul în care unităţile de prelucrare existente vor fi executate de un alt sistem de calcul decât cel pentru care au fost concepute iniţial; - funcţionarea experimentală a sistemului proiectat ; - verificarea performanţelor sistemului informatic proiectat; - elaborarea raportului de implementare-exploatare; - elaborarea documentaţiei de utilizare a sistemului informatic proiectat; - omologarea sistemului informatic proiectat. Implementarea sistemului informatic necesită: - însuşirea manualului de utilizare sau după caz, a celui de exploatare şi mai ales aplicarea prevederilor acestora în practică, de către fiecare, în părţile ce-l privesc; - identificarea de către conducerea unităţii beneficiare a acţiunilor ce trebuiesc desfăşurate în vederea implementării şi pe timpul implementării şi anume: - procurarea de documente primare (formulare) noi; - efectuarea codificărilor sau conversia unor coduri ce urmează a fi adaptate; - iniţializarea şi finalizarea demersurilor necesare pentru conectări la reţelele impuse de noul sistem; - asigurarea fondurilor necesare;

2

- numirea administratorului bazei de date şi după caz a administratorului de reţea care să asigure: - elaborarea planului de implementare; - instalarea softului necesar exploatării sistemului informatic (soft de reţea, soft de bază, soft aplicativ, etc.); - iniţializarea sistemului cu numele şi datele personalului care va avea acces la calculator, stabilirea drepturilor şi îndatoririlor pe care le are fiecare utilizator în activitatea de exploatare a sistemului informatic, încărcarea parolelor pe nivele, aplicaţii, proceduri; - încărcarea bazei de date a sistemului informatic cu date reale şi trecerea la desfăşurarea activităţilor informaţionale pe baza noilor documente primare; - funcţionarea experimentală a sistemului proiectat (aceasta se poate derula simultan cu toate subsistemele şi unităţile funcţionale, în serie sau combinat (tactica simultană cu tactica în serie)); - procurarea materialelor consumabile necesare şi a pieselor de schimb şi/sau încheierea contractelor de service. Se recomandă ca vechiul mod de lucru să se menţină în paralel cu cel nou pe o durată de 1-3 luni, în funcţie de complexitatea sistemului şi de gradul de încredere în noul sistem, până când există convingerea că utilizatorii sunt stăpâni pe situaţie şi că noul sistem funcţionează corect şi prezintă siguranţă în funcţionare. 2. Manuale ce trebuie să însoţească o aplicaţie sau un sistem informatic 2.1 Manualul de prezentare Este un document care vizează aspectul promoţional al proiectului informatic şi are sens numai pentru sistemele informatice bazate pe produse program generalizate. Ca urmare va conţine următoarele: - destinaţie; - funcţiuni; - cerinţe hard şi soft impuse pentru implementarea sistemului; - avantaje şi performanţe; - condiţii de livrare; - perspective; - eventual costuri, facilităţi oferite cumpărătorilor. 2.2 Manualul de utilizare Manualul de utilizare se adresează în primul rând personalului cu funcţii de conducere, spre deosebire de manualul de exploatare care se adresează personalului care operează efectiv calculatorul. Prin specificul P.C.urilor

2.2.1 Prezentarea sistemului:

, adeseori beneficiarii rapoartelor obţinute de la calculator preferă să opereze ei calculatorul şi atunci se elaborează un singur manual care tratează atât documentele ce se obţin de la calculator, privite prin prisma managerului instituţiei, cât şi modul de întreţinere şi exploatare a bazei de date, privit prin prisma operatorului de calculator. În concluzie manualul de utilizare trebuie să conţină:

- cărui tip de intreprindere sau instituţie este dedicat. Gradul de generalitate; - ce se poate obţine prin implementarea şi exploatarea sistemului; - cadrul general organizatoric şi juridic în care trebuie să funcţioneze sistemul. Limite si restricţii de funcţionare;

3

- cerinţe impuse de sistem privind sistemul/sistemele de operare, tipul de reţea pe care poate fi implementat (dacă este cazul), configuraţia calculatoarelor şi liniilor de comunicaţie incluse în sistem; - modul de livrare: kitul- condiţii de procurare/înregistrare/difuzare, etc.

de instalare, chei de protecţie la copiere, etc.;

2.2.2 Instrucţiuni pentru administratorul bazei de date şi al reţelei de calculatoare: - lista subsistemelor şi aplicaţiilor precum şi amplasarea/distribui- rea lor şi a bazelor de date aferente pe diferite posturi de lucru; - macheta meniurilor asociate subsistemelor şi aplicaţiilor; - concepţia asamblării programelor în sistem, dependenţa sau independenţa lor de anumite s.g.b.d., utilitare, sisteme de operare, tipuri de reţele de calculatoare, etc. - instrucţiuni de instalare a sistemului, de asigurare a siguranţei şi securitatăţii informaţiilor; - lista mesajelor de eroare la instalare şi soluţii de remediere a incidentelor posibile. Restul informaţiilor din manualul de utilizare pot fi livrate utilizatorilor sistemului sub formă de extrase, conţinând numai părţile ce-i privesc, dar în întregul său manualul de utilizare trebuie să conţină: 2.2.3 Proceduri manuale de codificare a datelor de intrare (în cazul utilizării codificării automate se întocmeşte o documentaţie completă a aplicaţiei respective, la care se face referire în manualul de utilizare); - structura codurilor pentru fiecare mulţime de date, metode de validare; - graficul de implementare a codificării, modul de întreţinere a codificării, responsabilităţi; - liste de coduri, cifre de control; legătura cu alte sisteme de codificare (la nivel naţional, departamental, etc.); 2.2.4 Proceduri manuale de colectare şi transmitere a datelor de intrare: - documente de intrare; - instrucţiuni de completare documente/formulare cu date de intrare; - exemple de completare; - verificări/validări manuale, chei de control; - instrucţiuni: fluxuri de circulaţie, responsabilităţi, termene de completare şi transmitere a documentelor/formularelor cu date de intrare; - instrucţiuni de stocare/arhivare, termene de păstrare, difuzare, distrugere; - instrucţiuni de utilizare a echipamentelor terminale, destinate introducerii datelor de intrare (tipuri de tranzacţii, coduri, mesaje de eroare) . 2.2.5 Proceduri de colectare/validare date de intrare: - macheta meniului din care se poate apela procedura şi macheta ferestrei de dialog/ecranului prin care se pot transmite datele de intrare cerute de procedură; - instrucţiuni privind modul de folosire a ferestrei de dialog/ecranului prin care se comunică cu procedura; - modul de interpretare a mesajelor de eroare sau a listelor de erori şi de control primite de la calculator; evidenţa acestora pe destinatari (dacă este cazul); - modul de corectare a erorilor, conform mesajelor; - modul de transmitere a corecţiilor (responsabilităţi, termene, formă, destinaţie); - proceduri de control şi corecţie a datelor introduse de la echipamentele terminale;

4

2.2.6 Proceduri de utilizare şi interpretare a ieşirilor: - rapoarte de ieşire (liste şi machete); - opţiunile meniu prin care se lansează procedura de generare a fiecărui raport de ieşire, macheta ferestrei de dialog/ecranului prin care se introduc datele cerute de această procedură; - instrucţiuni privitoare la modul cum se vor completa câmpurile din fereastra de dialog/ecranul afişat de procedura de generare a raportului; - instrucţiuni de interpretare şi verificare; - fluxuri de circulaţie a rapoartelor de ieşire, responsabilităţi, termene, periodicitate; - modul de difuzare, arhivare, perioada de păstrare, distrugere a rapoartelor de ieşire. 2.2.7 Proceduri speciale de conversie: (valabile numai în perioada implementării): - listă proceduri manuale şi automate de conversie; - descriere proceduri (inclusiv aliniatele 2, 3 si 4 de la punctul 2.2.6, dar referitor la procedurile de conversie); - termene de execuţie, valabilitate. 2.3 Manualul de exploatare Acesta se adresează în principal administratorilor de reţea şi/sau de bază de date şi îşi are rostul numai în cazul sistemelor informatice care conţin reţele de calculatoare sau echipamente mai deosebite pentru a căror exploatare este necesar personal cu calificare specială. Ca principiu, în acest manual vor fi tratate, pe lângă informaţiile din manualul de utilizare şi aspecte referitoare la softul de bază şi de reţea, la kitul de instalare şi la măsurile ce vizează siguranţa şi securitatea informaţiilor. Vor fi tratate posibilele incidente şi modul lor de remediere, eventuale incompatibilităţi între componentele softului de bază şi de reţea şi modul de rezolvare. Eventual un capitol de trouble shooting. Se mai pot face referiri la lucrări de întreţinere, reparaţii, upgrade, revizii, etc.

1

Cursul_III_8

Elaborarea registrelor contabile ºi a documentelor de sintezã Concepþia de rezolvare a aplicaþiei

I. Destinaþia aplicaþiei Aplicaþia “Elaborarea registrelor contabile ºi a documentelor de sintezã” este destinatã sã rezolve pe calculator toate problemele legate de contabilitatea financiarã a unei societãþi comerciale. II. Funcþiile aplicaþiei Aplicaþia trebuie sã permitã: - implementarea ei pe calculator ºi deschiderea exerciþiului

financiar în orice lunã din anul calendaristic curent; - încheierea anului financiar ºi deschiderea noului an

financiar; - adãugarea de noi conturi, oricând în interiorul unui

exerciþiu financiar; - þinerea la zi în calculator, a unei tranºe curente cu

tranzacþiile efectuate dupã ultima încheiere de lunã; - simularea încheierii de lunã pe baza tranºei curente ºi

elaborarea unor documente simulate cum ar fi registru jurnal, fiºele conturilor, cartea mare ºah, balanþa sinteticã ºi ba- lanþa analiticã, cu posibilitatea ca în cazul depistãrii de cãtre utilizator a unor incompatibilitãþi sau inadvertenþe, acesta sã poatã aduce tranºei curente corecþiile ce se impun fãrã a apela la operaþiuni de stornare;

- validarea tranºei curente, elaborarea în formã definitivã a documentelor de la aliniatul precedent, tipãrirea lor la imprimantã ºi arhivarea lor conform prevederilor legale în vigoare;

- deschiderea unei noi tranºe curente; - închiderea anului financiar, elaborarea documentelor de

sintezã ºi raportare, precum ºi deschiderea (iniþializarea) noului an financiar.

III. Cerinþe impuse aplicaþiei Aplicaþia va dispune de un meniu care sã sugereze utilizatorului principalele momente din derularea contabilitãþii financiare manuale, astfel încât acesta sã se simtã cât mai confortabil cu aplicaþia care þine contabilitatea pe calculator. În principiu, aplicaþia nu trebuie sã vinã cu îngrãdiri în ce priveºte activitatea contabilã ci dimpotrivã, trebuie sã aducã înlesniri, sã efectuieze ºi operaþiuni la care utilizatorul nu putea aspira în regim manual, cum ar fi elaborarea de grafice, extrase din tabele dupã criterii formulate ad-hoc sau calculul

2

unor indicatori sintetici greu de obþinut în varianta manualã a contabilitãþii. Alte precizãri: - se recomandã ca simbolurile conturilor sã fie declarate de tip text(7); - matricile în care sunt stocate conturile corespondente sã

poatã stoca cel puþin 27 de conturi corespondente pentru fiecare cont sintetic ( a se vedea mai jos macheta tabelului Matrice_debit).

- în cazul în care se impune validarea tranºei curente ºi elaborarea documentelor în formã definitivã, înainte de încheierea lunii curente, utilizatorul va putea reveni ulterior, la situaþia de dinaintea validãrii tranºei ºi va putea continua completarea tranºei pânã la sfârºitul lunii curente, pentru a putea efectua o încheiere normalã de lunã.

- soluþia adoptatã va trebui sã permitã încheierea anului financiar ºi resetarea bazei de date

pentru începerea noului an financiar.

4

IV. Soluþia propusã de proiectant (variantã) 1. Meniul principal

1. AGENDÃ 2. CONFIGURARE 3. TRANZACÞII 4. PRELUCRÃRI - Societatea; - Terþi; - Carnete CEC

Intrare in contabilitate Revenire in Access Exerciþiu; Plan de Conturi; Grupe de Conturi; Jurnale Valori Implicite; Conturi TVA; Opþiuni.

- Editare Transã; - Simulare Efect Transã; - Vizualizare Efect - Efect pe Conturi - Transã nouã.

Validare Tranºã; Verificare Bancarã; Operaþii Periodice; Inchidere TVA; Pregatire balanta; Pregatire bilant; Pregatire profit si pierdere Stornare.

5. RAPOARTE 6. GRAFICE 7. EDITARE 8. IEªIRE

Fiºe conturi; Carte Mare debit; Carte Mare credit; Balanþa (sinteticã/analiticã) Bilant; Profit si pierdere; Jurnale; Scadenþe; Urmãrire Clienþi; Borderouri Bancã;

Formulare Raport: - Situaþia

Patrimoniului;

- Rezultate Financiare;

- Declaraþia de impozit Jurnale Comerciale cu TVA; TVA Impozite; Decont TVA.

Evoluþia unui Cont; Repartiþia unei Clase; Evoluþie Cheltuieli/Venituri; Pregãtirea Cumulilor Grafici.

Cut; Copy:; Paste

Observatie: În tabelul de mai sus, opþiunile scrise cu bold sunt deja date în funcþiune. Celelalte sunt în studiu; probabil la multe dintre ele se va renunþa.

5

2. Principalele tabele necesare aplicaþiei

- Planconturi - Funcþionare_cont_d

ebit; - Funcþionare_cont_c

redit; - Extras_

funcþionare_ debit;

- Extras_ funcþionare_credit;

- Matrice_debit; - Matrice credit;

- Solduri_sintetice_credit;

- Extras_sintetice_debit;

- Extras_sintetice_credit

- Matrice_rulaj_debit;

- Matrice_rulaj_credit;

- Impact_rulaj_sold;

- Evoluþie_sold_co

- Rulaje sintetice1;

- Soldrad1 si 2;

- Soldcont_analitic;

- Stuctura_bilant;

- Solduri_bilant;

- Solduri_subclase;

St t

6

Tabelul matrice_rulaj_debit conþine 27 de locatii pentru rulajele a maximum 27 de conturi corespondente. Unele conturi sintetice au mai mult de 27 de conturi sintetice, dar nu toate sunt folosite intr-o societate. De aceea este de datoria utilizatorului sã facã uz de câmpul starea contului din tabelele de functionare conturi, câmp care dispune de un combobox cu optiunile folosit si blocat ºi sã blocheze conturile nefolosite de el. Tabelul Matrice_rulaj_debit se încheie cu douã câmpuri care nu au fost prinse în capture: rulajtotal ºi data. Tabelul Sah_debit are si el spatiu pentru 27 conturi corespondente. Tabelele Structura_bilant ºi Structura_profit au spatiu pentru 25 de conturi ce se pot însuma pe un rand ºi se încheie cu câmpurile Nr_conturi_pe_rând. Contul de profit si pierdere are tabele similare cu cele ale bilantului.

7

Sã remarcãm cã în afarã de tabelele corespunzãtoare registrelor contabile ºi documentelor de sintezã mai existã ºi alte tabele cãrora probabil un începãtor nu le-ar duce lipsa! Acestea sunt tabele de manevrã, adicã tabele cu ajutorul cãrora trecem de la un stadiu la altul al prelucrãrii datelor pânã ce obþinem unul sau mai multe tabele de forma de care avem nevoie pentru a redacta rapoarte (documente contabile). De exemplu, pentru a ºti care sunt conturile ale cãror tranzacþii trebuie luate în consideraþie la calculul soldului unui cont sintetic de activ, am conceput tabelul Matrice debit care pe un articol, conþine codul unui cont sintetic urmat de simbolurile conturilor corespondente ( de aici si numele de matrice-debit, dar tabelul se putea numi oricum. Important este sã ºtim ce vrem sã facem cu el ºi de aici rezultã ºi structura pe care i-o vom da tabelului). Dispunând de acest tabel ºi de ultima tranºã de tranzacþii (tabelul Adaos_jurnal), putem parcurge secvenþial tabelul Matrice debit ºi pentru fiecare cont sintetic din articolul curent parcurgem secvenþial tabelul Adaos_jurnal. La fiecare articol din Adaos_jurnal ne întrebãm dacã contul sãu este egal cu contul sintetic al cãrui sold îl calculãm ºi dacã da, verificãm dacã contul corespondent (cont de credit) al articolului curent din Adaos_jurnal se aflã printre conturile corespondente specificate în articolul curent din Matrice debit. Dacã da, valoarea acelei tranzacþii va fi adunatã la soldul contului sintetic curent.

3. Fluxul soldurilor În afarã de informaþiile specifice unui plan de conturi, tabelul Planconturi mai conþine soldurile ºi rulajele fiecãrui cont pe ultima lunã (tranºã). Aceleaºi informaþii, dar pe întreaga perioada scursã de la începutul anului pânã în prezent, se aflã stocatã în tabelul Solduri.

8

În timpul anului financiar, mai exact la sfârºit de lunã, pentru a opera tranzacþiile din ultima tranºã, soldurile din luna precedentã sunt preluate din tabelul Planconturi de interogarea Extrag_solduri ºi depuse în tabelul Sold_conturi. In acel tabel, ele sunt actualizate pentru fiecare articol din transa nouã de cãtre programul Impact_sold ºi rãmân acolo pânã la rula-rea programului Transfer_sold_plan, când se întorc înapoi în PlanConturi împreunã cu rulajele curente ºi cu soldul unic actualizat pentru ultima tranºã (însoþit dupã caz de simbolul D sau C). Dupã trimiterea lor spre tabelul Planconturi, acelaºi program lanseazã subrutina Creare_rulaj_total, care scoate un extras pe ultima lunã din “Solduri” sub numele de “Extras_din Solduri” ºi pe acest extras, aduce din PlanConturi rulajul curent. Cu rulajul curent ºi cu rulajul total de luna trecutã din extras, calculeazã rulajul total la zi, pe care-l depune în “ Extras_din Solduri”. În final, prin intermediul macroului si interogãrii Transfer_Sinteza_Transei, aduce în tabelul Solduri noul extras, adicã noile solduri, rulajele curente si rulajele totale pe luna încheiata. Ele sosesc aici prin Append, astfel cã din tabelul Solduri se poate vedea evoluþia soldurilor, a rulajelor curente ºi a rulajelor totale de la începutul anului pânã la ultima tranºã validatã. La iniþializarea exerciþiului financiar, soldurile se trec în Planconturi si ajung in Solduri folosind macroul Transfer_sold_solduri. In plus, pentru conturile sintetice, se mai trec în Planconturi ºi soldurile iniþiale (cele de la sfârºitul anului trecut sau dupã caz cele de la începutul exerciþiului financiar). Chiar dacã sunt aceleaºi cu soldurile din rubricile sold_debit respectiv sold_credit, ele se mai trec odatã în rubricile tip_sold_initial ºi sold_initial, pentru cã aici ele rãmân tot timpul anului ºi vor fi folosite pentru a fi puse în prima linie din fisa Carte mare sah a contului sintetic. Soldurile din rubricile sold_debit ºi sold_credit sunt solduri lunare. (Aceastã fazã – adicã iniþializarea exerciþiului financiar - va fi prezentatã în detaliu într-un alt curs, dupã elaborarea bilantului ºi a rapoartelor de sintezã). În ce priveºte rulajele se poate deduce din cele de mai sus cã rulajele curente se calculeazã împreunã cu soldurile curente, în subrutina Transfer_sold_plan ºi se depun în PlanConturi. Rulajele totale se calculeazã în subrutina Creare_rulaj_Total, iar restul câmpurilor necesare pentru actualizarea tabelului “ Extras_din Solduri” sunt preluate de aceeaºi subrutinã din PlanConturi. La terminarea rulãrii subrutinei Creare_rulaj_Total, tabelul “ Extras_din Solduri” este gata pentru a fi adãugat la tabelul Solduri. Transferul se face cu macroul Transfer_Sinteza_Transei din subrutina Transfer_sold_plan.

9

4. Evoluþia unei tranºe

Tranºa se construieºte în tabelul Adaos_jurnal. O tranºã nouã începe cu alegerea opþiunii Transã nouã din meniul Tranzacþii, ale cãrui opþiuni se pot vedea în figura din stânga. La alegerea acestei opþiuni tabelul Adaos_jurnal este golit de

tranzacþii, iar butonul Validare_tranºã care la ultima sa apãsare s-a autoblocat, devine din nou activ. Pânã la validare, tranºa trebuie simulatã, pentru a vedea efectele sale asupra conturilor care au tranzacþii. Simularea este obligatorie pentru cã dacã transa este validatã, o parte din prelucrãrile fãcute pe timpul simulãrii rãmân definitive ºi pe baza lor se vor obþine documentele definitive de contabilitate (fisa contului, cartea mare sah, balanta, etc.) Dintre efectele simulãrii remarcãm descompunerea tranzacþiilor în douã rânduri fiecare cu structurã asemãnãtoare fiºei cont, dar pãstrând ordinea operaþiilor din transã ºi alt efect, gruparea tranzacþiilor pe coduri, pentru a vedea mai uºor evoluþia soldurilor (sumelor) conturilor afectate de tranzacþii. Efectele sunt create de subprogramul Impact_sold (din modulul Impact-direct), la apãsare butonului Simulare Efect Tranºã din meniul Tranzacþii. Acest modul creazã tabelul Impact_rulaj_sold ºi în final printr-o interogare, creazã tabelul "Evolutie_sold_cont". Efectele simulãrii pot fi vizualizate la apãsarea butoanelor Vizualizare efect ºi Efect pe Conturi, dar înainte de aceasta programul Impact_sold continuã cu rularea subrutinei “Transfer_sold_plan”din modulul “Valid” care face actualizarea datelor din tabelul Plan Conturi ºi anume: calculul rulajelor curente din ultima tranºã, a soldurilor ºi a rulajelor totale la zi (folosind în acest scop sumele din tabelul “Sold_conturi”, soldurile de luna trecutã ºi rulajele totale de luna trecutã din tabelul Planconturi). În continuare se mai produc automat urmãtoarele evenimente: – Rularea subrutinei “Creare_rulaj_total” care creazã tabelul Extras_din _ Solduri, face transferul rulajelor curente din tabelul Planconturi în tabelul Extras_din _Solduri ºi calculeazã celelalte câmpuri din tabelul Extras_din _Solduri; – Alipirea tabelului Extras_din _Solduri (conþinând soldurile, rulajele curente ºi rulajele totale la zi), la tabelul Solduri, (interogarea “Transfer_Sinteza_Transei” prin macroul cu acelaºi nume, lansat din subrutina “Transfer_sold_plan”din modulul “Valid” ); – Append fiºier Adaos_jurnal la Registru_jurnal (interogarea Append_Adaos , prin macroul cu acelasi nume, lansat din subrutina “Transfer_sold_plan”); – Append Evolutie_sold_conturi la Fisa_cont ºi apoi ordonarea tranzacþiilor din acest fiºier dupã conturi, iar în cadrul contului, dupã nr. crt. din registrul Jurnal, ceea ce se

10

realizeazã printr-un index compus din cod ºi nr.crt (interogarea Append_miscari_fisa lansatã de macroul Adaug_misc_fisa prin subrutina“Transfer_sold_plan”); – Crearea tabeleleor “Matrice_rulaj_debit” ºi “Matrice_rulaj_credit” care conþin rulajele totale pentru conturile corespondente ale fiecarui cont sintetic. Aceastã acþiune este dusã la bun sfârºit de subrutina “Rulaj_coresp_debit” ºi respectiv “ Rulaj_coresp_debit” care are ca principala destinatie crearea unui extras din fisierul ”Sold_sintetic_debit” ºi respectiv “Sold_sintetic_credit” . In actuala versiune “matrice_rulaj_debit” ºi “matrice_rulaj_debit” nu se arhiveaza nicãieri pentru cã ele se creazã ad_hoc, din “Adaos_ jurnal” folosindu-se “Matrice_debit” si respectiv credit. Subrutina “Rulaj_coresp_debit” lansata din modulul “Validare” o apeleaza pe “ Rulaj_coresp_credit” si apoi ele sunt urmate de macrourile care adaugã noul “Extras_sintetic_debit” respectiv credit la “Solduri_sintetice_debit”, respectiv credit. Urmeazã rutina “Combin_sintetice” care produce tabelul “Balanta” si apoi crearea tabelelor “sah_debit ” ºi “sah_credit”, create cu programele care poartã chiar numele tabelului . Aceste tabele conþin principala parte din datele unei fise carte mare sah, pentru fiecare cont sintetic în parte (datele sunt ordonate pe conturi sintetice). Dacã toate operaþiunile de mai sus, s-au încheiat cu succes, putem folosi opþiunile Vizualizare efect ºi Efect pe Conturi din meniul Tranzacþii. Dupã aceastã enumerare de prelucrãri cititorul s-ar putea întreba cum ar fi putut el, fãrã experienþã, sã-ºi fi imaginat din proprie iniþiativã o asemenea secvenþã complicatã de prelucrãri. Secretul constã în a pleca de la tabelele ce reprezintã registrul jurnal ºi a ajunge la documentele de sfârºit de lunã (fiºa contului, carte mare ºah, balanþã). Peste aceastã secvenþã de prelucrãri vom suprapune principalele momente din viaþa aplicaþiei, reflectate deja în meniul de mai sus ºi necesitatea ca în final tabelul pe care se va construi raportul de obþinere a fiecãrui document sã aibã o structurã cât mai apropiatã de cea a documentului pe care vrem sã-l obþinem. Acest deziderat se va putea urmãri în continuare în descrierea modului referitor la felul în care s-a conceput obþinerea documentelor lunare. Sã remarcãm cã în cele ce urmeazã nu vom vedea noi prelucrãri, dar vom vedea care din etapele prelucrãrii enumerate mai sus, este menitã sã netezeazscã drumul spre un document sau altul. Înainte de aceasta mai trebuie remarcat cã organizarea secvenþei prelucrãrilor care trebuie fãcute pentru a ajunge de la transa curentã la documentele lunare ºi ulterior la bilanþul anual, mai trebuie sã þinã seama de o cerinþã specificatã la început ºi anume aceea cã dupã fiecare simulare, dacã este cazul, sã

11

ne putem întoarce la situaþia de dinainte de simulare ºi sã continuãm editarea tranºei curente. Aceastã cerinþã impune ca sã lucrãm cu mai multe copii ale fiºierelor de bazã ( registrul jurnal, planul de conturi – partea care conþine rulaje si solduri, tabelul solduri, solduri sintetice, etc.) Un efect asemãnãtor asupra secvenþei de prelucrãri va avea ºi necesitatea de resetare a aplicaþiei, dupã încheierea anului financiar. In solutia pe care o prezentam aici problema aceasta s-a rezolvat prin faptul cã programul atasat opþiunii Simulare transã incepe cu restaurarea fisierelor de baza (de referintã). Acestea poartã numele fisierelor enumerate mai sus, dar au si o extensie sub forma _ini. Când facem validarea transei, fisierele sub numele fãrã extensie (fisierele de lucru) sunt salvate peste cele cu extensie, astfel cã începând cu urmãtoarea rulare fostele fisiere de lucru devin fisiere de bazã (de referintã). Pentru orice eventualitate, înainte de a salva fisierele de lucru peste cele de referintã, fiºierele de referinþã sunt salvate peste fisierele de siguranþã care au extensia _prec. De fapt, acesta este singurul lucru ce se petrece atunci când facem validarea tranºei. Sã vedem în continuare cum secvenþa de prelucrãri descrisã mai sus, “pregãteºte terenul “ pentru fiecare situaþie lunarã. În cadrul orelor de laborator aceastã secvenþã va fi prezenatã progresiv ºi va fi realizatã efectiv de studenþi pe baza schemelor de sistem de la sfârºitul acestei lecþii. 5. Situaþiile lunare Programele, tabelele, interogãrile, macrourile ºi rapoartele care concurã la scoaterea fiecãrei situaþii lunare au fost încorporate în proceduri care se lanseazã automat la alegerea opþiunii corespunzãtoatre din meniul Rapoarte dupã cum urmeazã:

- pentru Cartea mare ºah, se folosesc douã tabele cu structurã identicã, valabilã în principiu pe tot timpul anului (matrice_debit ºi matrice_credit . Deosebirea dintre ele se referã la conþinut; mai exact unul este pentru debitare ºi celãlalt pentru creditare. Aceste tabele conþin conturile cu care se debiteazã ºi respectiv se crediteazã conturile sintetice. Ele se actualizeazã la începutul anului financiar din opþiunea meniului Configurare, numitã Plan de Conturi care lanseazã subrutinele Genmat_debit ºi respectiv Genmat_credit . Acestea lucreazã astfel: pentru fiecare cont din PlanConturi se verificã prin tabelul Funct_cont_debit respectiv Funct_cont_credit, dacã acel cod este implicat în relaþii cu alte conturi ºi dacã da, toate conturile cu care acesta are relatii, sunt descãrcate într_un singur articol, din tabelul numit matrice_debit ºi respectiv matrice_credit. Trecerea de la Funct_cont_debit respectiv Funct_cont_credit la tabelul matrice se face printr-un tabel de tranzitie (extras_debit ºi respectiv extras_credit) care se editeaza

12

pentru fiecare cont sintetic in parte, prin intermediul unei interogãri, al cãrei cod SQL este incorporat in subrutina genmat_debit ºi respectiv genmat_credit din modulul Carte_sah. Inainte de a fi actualizate, tabelele de tranziþie trebuie sterse , pentru cã actualizarea lor se face prin Append. ªtergerea se face cu interogãrile ºi respectiv macrourile Sterg_extras_debit ºi Sterg_extras_credit. Si matrice_debit ºi credit trebuie sterse înainte de actualizare, deoarece ele se creazã cu AddNew, pe versiunea veche. Pentru aceasta existã interogãrile ºi respectiv macrourile Sterg_matrice_debit ºi respectiv ºterg_matrice_credit. Lunar, la Simulare tranºã, se construieºte câte o matrice cu rulajele totale pe debit (“Matrice_rulaj_debit”) ºi respectiv pe credit (“Matrice_rulaj_credit” ) ale conturilor corespondente. Concret, fiecare articol dintr-o astfel de matrice, conþine rulajele totale ale unui cont sintetic., urmat de rulajele totale care îl compun, adicã de rulajele totale ale conturilor corespondente. Aceste matrici sunt produse de programul “Rulaj_coresp_debit” respectiv credit. Tot cu ocazia validãrii tranºei, se creazã tabelele sah_debit ºi sah_credit, folosindu-se în acest scop subrutinele care le poartã numele. O astfel de subrutinã se bazeazã în principal pe tabelele matrice debit respectiv matrice_credit pe care le va parcurge secvenþial. Pentru fiecare articol curent din matrice debit respectiv matrice_credit se va parcurge secvenþial ultima transã (tabelul Adaos_jurnal) ºi anume: pentru fiecare articol din ultima tranºã, rutina verificã dacã contul_debitor, respectiv cel creditor, se aflã printre codurile-relatie ale codului sintetic curent din tabelul din matrice debit respectiv matrice_credit ºi dacã da, articolului respectiv i se construieºte o copie în tabelul sah_debit, respectiv sah_credit. In aceastã copie valoare este poziþionat îndreptul contului-relaþie la care se referã. Când tranºa a fost parcursã în întregime, se trece la

urmãtorul articol din tabelul matrice. Subrutinele sah_debit ºi sah_credit încep prin a sterge continutul tabelelor sah_debit ºi respectiv sah_credit; pentru aceasta s-au prevãzut interogãrile ºi macrourile numite sterg_sah_debit ºi respectiv sterg_sah_credit. Tabelul sah_debit, respectiv sah_credit este sortat pe coduri sintetice, iar în cadrul codului pe nr.crt din registru jurnal.

Tabelul sah_debit, respectiv sah_credit se apropie mult de imaginea unei fise Carte Mare ªah, doar cã pentru codurile relaþie ale contului sintetic conþine obligatoriu 27 de coloane ceea ce necesitã unele adaptãri ale acestor tabele, astfel ca fisa carte mare sah sã poatã fi editatã pe o coalã A4 orizontalã (landscape). De aceea activitatea

13

calculatorului la faza Simulare tranºã se opreºte aici. Ulterior, dacã se preconizeazã generarea unor fise carte mare ºah dupã tabelele sah_debit, respectiv sah_credit, se va apela la opþiunea Carte mare din meniul Rapoarte. Aici utilizatorul are posibilitatea sã precizeze dacã fisele carte mare ºah sunt pentru debit sau pentru credit, ce paginã din fisa se doreste, dacã pagina va fi vizualizatã sau tipãritã. Coresopunzãtor opþiunilor alese, în continuare

se va lansa în execuþie o interogare sah_debit_i_j, respectiv sah_credit_i_j care pregãteºte terenul pentru lansarea raportului Fisa_sah_debit, respectiv Fisa_sah_credit. In aceste denumiri, i ºi j reprezintã numãrul de ordine al contului corespondent cu care începe ºi respectiv cu care se terminã fisa respectivã. Aceastã interogare ataºeazã la fiecare articol din tabelul sah_debit, respectiv sah_credit, câteva coloane din

Planul de conturi (cod_cont, denumire cont ºi sold_sintetic), codurile conturilor corespondente asociate fiecãrui cont sintetic – din tabelul matrice debit respectiv matrice_credit (pentru a fi folosite ca denumire de coloanã în tabelul fisei) ºi rulajele totale ale conturilor sintetice ºi ale conturilor corespondente (preluate din “Matrice_rulaj_debit” respectiv “Matrice_rulaj_credit”) pentru a completa ultimul rând din fisã. Acesta urmeazã dupã cel din subsolul contului sintetic curent, calculat cu funcþia SUM. Din aceastã interogare, când se elaboreazã raportul pentru fisa Carte Mare ªah cu wizard-ul, în fereastra acestuia se vor prelua doar câmpurile specificate în imaginea din stânga, plus câmpul “numar_coduri_cumulate”, care este folosit în prima coloanã (cea pentru primele 6 conturi):

- Pentru conturile sintetice se poate folosi raportul Fisa_conturilor_din_evolutie care se bazeazã pe interogarea “Evoluþie_PlanConturi” . Aceasta pe lângã câmpurile din Evoluþie_sold_cont, mai aduce din planul de conturi câmpurile Cod_cont, Den_cont, Sold_debit, Sold_credit, TipSold, Sold, Tip_sold_init ºi Sold_init, iar din Sold_conturi aduce câmpurile Sold_debit ºi Sold_credit care de fapt sunt sume debit, respectiv sume credit - Pentru Fisele conturilor desfãºurate pe conturi analitice, lucrurile sunt mai complicate. Pentru aceste conturi a fost introdus tabelul “Conturi_radacina” cu câmpurile rãdãcina, nr-nivele_sub_cont ºi Nr_cifre_la_nivelul2. Acest tabel se creazã la implementare, odatã cu PlanConturi, matricile_debit ºi credit si cu Functionare_cont_debit, respectiv credit. Se poate deduce din structura tabelului “Conturi_radacina” cã se pot defini si rãdãcini cu douã nivele: un cont rãdãcinã de trei cifre la care se poate

14

adãuga a o a doua rãdãcinã formatã dintr-o cifrã sau douã, dupã care urmeaza încã douã cifre pentru identificarea conturilor legate de nivelul doi. De exemplu codul 401 clienti poate fi divizat pe judete sau pe tipuri de produse pe care clientii le cumpãrã ºi vom avea astfel contul 40101, 40102, 40103, s.a.m.d.

Individualizarea clienþilor din fiecare categorie de mai sus, se va face atribuidu-le conturi ca 4010101, 4010102, respectiv 4010201, 4010202, s.a.m.d. Evident conturile cu 7 cifre vor fi luate în calcul rulajelor si soldurilor conturilor cu 5 cifre, adicã a conturilor 40101, 40102, 40103, s.a.m.d. Conturile care apartin nivelului al doilea vor avea 7 cifre (5 ale radacinii si douã care fac distincþie între codurile aparþinând aceleiaºi rãdãcini de 5 cifre). Bineînteles cã se pot folosi si rãdãcini cu un singur nivel, (de 3 sau 4 cifre) urmat de douã, trei sau patru cifre care fac distincþie între codurile aparþinând aceleiaºi rãdãcini. Rulajul contului 401 în cazul în care se folosesc douã nivele, presupune calculul rulajelor conturilor apartinând fiecãrei rãdãcini de nivel doi, adunarea rulajelelor conturilor care aparþin aceleaºi rãdãcini de nivel doi, de exemplu a celor care aparþin contului 40101 ºi în final, adunarea rulajelor tuturor rãdãcinilor de nivel doi apartinând rãdãcinii 401, adicã rulajele conturilor 40101, 40102, 40103, s.a.m.d. Pentru codurile cu rãdãcini pe douã nivele, rãdãcina de nivel 2 poate avea una sau doua cifre, lucru ce trebuie specificat în coloana Nr_cifre_la_nivelul2. Când simulãm o transã ºi facem pregãtirile necesare pentru a obþine printre altele ºi fisele conturilor analitice, deoarece aceste fiºe necesitã cunoaºterea soldului precedent, vom face un extras din planul de conturi cu denumirea contului, soldurile din luna precedentã ºi cu spaþiu pentru a stoca acolo si soldul actual al soldurilor analitice. Acest lucru îl realizãm cu interogarea "Make_soldrad1" care creazã tabelul “soldrad1”. Ulterior , în programul “solduri_noi_pentru_fise” acest tabel este multiplicat în alte douã exemplare (“soldrad2” ºi "soldcont_analitic") ce vor fi folosite împreunã cu originalul, la elaborarea rapoartelor “fise_cu_1nivel” si “fise_cu_2nivele”, bazate pe interogãri ce le poartã numele. Deocamdatã în continuarea acþiunii de pregatire pentru a obþine rapoartele, respectiv fisele analitice, folosim un program ( numit separ_analitice) care preia toate înregistrãrile din tabelul Evoluþie_sold_cont, derivat din Adaos_jurnal ºi verificã dacã primele trei caractere ale contului fiecãrei tranzacþii sunt prezente în tabelul “Conturi_radacina” . Dacã da, programul genereazã numai pentru tranzacþiile aparþinând acestor conturi, un tabel numit "evol_rad_cont". În acest tabel apar douã coloane distincte: una cu contul radacinã de nivel 1 si dacã este cazul, a doua cu contul rãdãcinã de nivel doi precedat de rãdãcina de nivel 1, în total 5 cifre). De exemplu pentru

15

contul 4010102 vom avea în prima coloanã 401, în a doua 40101 ºi în a treia va apare codul contului, adicã 4010102. În acest fel articolele din tabelul "evol_rad_cont" pot fi grupate în rapoarte, pe nivele: radacina1, radacina2 ºi în final pe coduri analitice, unde vor fi enumerate tranzacþiile individuale ale contului analitic. S-a pregãtit astfel terenul pentru elaborarea fiselor analitice, dar înainte de aceasta trebuie sã facem calculul rulajelor ºi a soldurilor conturilor rãdãcinã, care normal, n-ar trebui sã aibã tranzacþii direct pe ele ci numai prin intermediul conturilor legate de nivelul 2 (în cazul rãdãcinilor cu douã nivele) sau a celor legate de nivelul 1 (când rãdãcinile sunt concepute pe un singur nivel). Pentru calculul rulajelor pe douã nivele ºi respectiv pe un nivel vom folosi trei interogãri : "Rulaje pe conturi intermediare" care creazã tabelul rulaje analitice1 (pe conturi analitice ºi pe rãdãcini de nivel 2) ºi "Rulaje pe conturi sintetice2" care foloseºte tabelul "rulaje analitice1" pentru a crea tabelul "rulaje analitice2" care contine rulajele rãdãcinilor de nivel 1. A treia interogare "Rulaje pe conturi sintetice2" creazã direct rulajele rãdãcinilor cu un singur nivel în tabelul "rulaje sintetice1”. Acum putem folosi aceste rulaje pentru actualizarea în planul de conturi, cu ajutorul programului Act_date_PlanConturi, a datelor privitoare la conturile sintetice care existã prin intermediul conturilor analitice. Înainte de actualizare însã, în acelaºi program, vom combina cele trei tabele cu solduri ale conturilor analitice în unul singur (numit rulaje sintetice1). Pentru aceasta vom folosi interogãrile "combin_analitice2_cu_sintetice1" ºi "combin_sintetice1_cu_analitice1" Dupã actualizarea datelor din articolele din Planul de Conturi ce implicã conturi analitice, folosim programul Solduri_noi_pt_fise care stocheazã noile rulaje din PlanConturi în tabelul “soldrad1” ºi apoi îl multiplicã pe acesta în alte douã exemplare numite “soldrad2” ºi "soldcont_analitic". Aceste tabele vor fi folosite de interogãrile “fise_cu_1nivel” si “fise_cu_2nivele”, care vor fi folosite de rapoartele cu acelaºi nume pentru elaborarea fiselor analitice. Motivul pentru care ne trebuie trei tabele cu solduri vechi ºi noi este acela cã dacã tabelul este grupat pe trei nivele (de exemplu radacina1 – rad1, radacina2 –rad2 ºi cont analitic), nu putem sa-i asociem fiecãrui nivel soldul de care are nevoie, decât dacã dispune în interogare de un tabel numai al lui. Aceastã problemã meritã studiatã pe calculator! Dupã elaborarea celor trei tabele cu solduri vechi ºi noi, putem considera cã avem tot ce ne trebuie pentru a obþine fisele analitice. Lista programelor care se ruleazã în cadrul operaþiunii de simulare continuã cu programele amintite mai sus când s-a prezentat procedura de obþinere a cartii mare sah , dar si cu programele specificate mai jos unde vom prezenta procedura pentru obþinerea balanþei.

16

Când se terminã rularea tuturor acestor programe, vom selecta meniul Rapoarte si de acolo putem selecta oricare dintre opþiunile fisa Cont, carte mare sah sau bilant. Dupã aceastã plictisitoare descriere a procedurii credem cã apare evident rolul schemelor logice de sistem. De aceea la sfârºitul acestui material vom ataºa ºi schemele logice ale fiecãrei proceduri. Remarcãm totuºi cã ele nu pot elimina aceastã descriere decât atunci când programatorul este suficient de experimentat ca sã deducã din schemã nu numai operaþiile ºi secvenþa lor, dar ºi justificarea (motivarea) fiecãrei faze din cadrul procedurii.

- - Pentru Balanþã sinteticã se foloseºte interogarea un program (din modulul Pregatim_Balanta) numit Pregatire_balanta care creaza tabelul Balanta_tabel. Pe acest tabel se aplicã interogarea cu parametru numitã Balanþãa sinteticã care este apoi apelatã de raportul cu acelaºi nume. Tabelul Balanta_tabel se creaza din meniul Prelucrãri, opþiunea Pregatire balanta iar in meniul Rapoarte trebuie doar sã alegem opþiunea Balanta si apoi vizualizare sau tipãrire. În ambele cazuri utilizatorul este solicitat sã spunã între ce grupe de coduri se va elabora raportul. Pentru un raport complet trebuie sã specificãm intervalul 10-99 (99 fiind de fapt rândul de Total General.)

6. Elaborarea bilantului si a documentelor anexã la bilant Din analiza machetelor acestor documente, se poate vedea cã datele pentru aceste documente sunt disponibile în tabelul PlanConturi, actualizat cu ultima tranºã din anul care s-a încheiat. Totuºi dat fiind conþinutul complex al acestor documente ele nu pot fi obþinute cu o interogare privitoare la PlanConturi, ci va trebui sã concepem o procedurã logicã mai complexã. În aceastã procedurã, piesa cea mai importantã este un tabel numit Structura_bilant ce va conþine câte un articol pentru fiecare rând din document. Pentru actualizarea tabelului Structura_bilant acestuia i se va asocia un formular. Macheta tabelului Structura_bilant este urmãtoarea: Nr_rand

Denumire categorie

Continut

Tip sold

Cont1 Cont2

… Nr conturi pe rand

1

Imobilizari necorp

sold 1

201 203 -2081

5

Unde: - Denumire categorie se refera la categorii de activ sau de pasiv (de ex. Imobilizari necorporale); - Continut se referã la conþinutul câmpurilor cont1, cont2, s.a.m.d. pânã la cont 20, care reprezintã locul de unde luãm informaþiile pentru a fi prelucrate: acesta poate fi un cont cu semn, sau un rând din bilanþ ( a se vedea indicaþiile cu privire la conturi din macheta bilantului). De ex. pentru linia I. ACTIVE IMOBILIZATE _ TOTAL se face referire la

17

rândurile 1-3 a cãror conþinut se adunã pentru a se obþine totalul; - Tip sold poate lua valoarea 1 dacã soldul este pe debit ºi 2 dacã este pe credit. Din macheta bilanþului se poate constata cã din tabelul Structura_bilanþ nu va participa în raportul numit Bilant, decât coloanele Denumire categorie ºi Nr_rand. Restul informaþiilor sunt folosite pentru a calcula soldurile ce vor fi stocate pe fiecare rând, din coloanele Inceputul anuluiºi Sfârºitul anului. Pentru calculul soldurilor se disting douã situaþii: solduri ale conturilor prevãzute în planul de conturi ºi solduri ale unor subclase de conturi (de ex .20), care nu sunt disponibile direct în planul de conturi, ci trebuie folosit un program special care sã selecteze din planul de conturi conturile care apartin unei subclase si sã le adune pentru a obþine soldul subclasei. Iniþial soldurile subclaselor se depoziteazã într-un tabel numit Solduri_subclase, având macheta de mai jos: Subclasa

Sold_debit_initial

Sold_debit_initial

Sold_debit_inicheiat

Sold_credit_incheiat

Dupã calculul soldurilor subclaselor, se poate trece la calculul soldurilor pentru coloanele Precedent ºi Încheiat. Acestea vor fi stocate în tabelul Solduri_bilant. Acest tabel conþine câmpurile: Nr_rand, Sold_initial ºi Sold_inchiat. Pentru completarea acestui tabel se aduc solduri din Planul de conturi (în cazul conturilor) sau din tabelul Solduri_subclase (în cazul subclaseor), dupã cum în tabelul structura_bilant este specificat un cont sau o subclasã. Dacã in tabelul Structura_bilant, la continut este specificat rand, atunci se cauta în tabelul Solduri_bilant, la rândul specificat înacelasi tabel.. Înainte de a asambla nr-rand, denumire categorie, solduri_subclase, solduri_bilant ºi solduri de pe alte rânduri care participã la calculul totalurilor, mai trebuie actualizatã în tabelul Societatea, data la care s-a fãcut validarea ultimei transe pe anul încheiat. Aceasta se ia din tabelul Solduri ºi va apare sub titlul bilantului. Dupã aceea se va rula interogarea Asamblez_tabel_bilant care ia date din tabelele Structura_bilant , Solduri_bilant ºi Societatea. Ultimele douã tabele sunt legate direct de tabelul Structura_bilant prin câmpul Nr_rand. Interogarea va produce un tabel cu aspect foarte apropiat de cel al formatului cerut pentru bilant. Pe acest tabel se poate rula raportul Bilantul, care este folosit pentru a vizualiza si pentru a tipãri bilantul. Dacã este cazul, operaþiunile de mai sus, pot fi precedate de actualizarea structurii bilantului ºi a datelor din tabelul Societatea (altele decât data validãrii transei) care sunt folosite pentru antetul bilantului. Lansarea procedurii logice de mai sus se face din submeniul Prelucrãri, prin opþiunea Pregatire bilant, care oferã un submeniu cu opþiunile Actualizare structura bilant, Actualizare antet bilant ºi

18

Elaborare bilant. Ultima opþiune lanseazã automat, unul dupã altul programele Actualiz_sold_subclase, Actualiz_sold_bilant, Actualiz_datei_ultimei_transe ºi interogarea Asamblez_tabel_bilant. Vizualizarea sau tipãrirea bilantului se poate face din submeniul Rapoarte/Bilant cu opþiunile Vizualizare ºi Tipãrire. 7. Soluþii pentru situaþii speciale apãrute pe timpul

exploatarii aplicaþiei 7.1 Implementarea aplicaþiei Implementarea presupune parcurgerea urmatorilor pasi:

- actualizarea planului de conturi: programul vine cu planul de conturi complet, dar la implementare se vor ºterge din el toate conturile care nu se folosesc. În acest scop se va folosi opþiunea Plan Conturi/actualizare din meniul Configurare. Pentru conturile ramase, acolo se vor completa ºi datele iniþiale: sold iniþial, total suma, sold_precedent, etc (conform machetei tabelului Planconturi prezentatã în secþiunea 2). Dupã ieºirea din formularul Plan Conturi, acesta atrage dupã sine formularul Funcþionare_cont_debit, care la rândul sãu aduce în atenþie formularul Funcþionare_cont_credit. In aceste tabele se aflã toate combinaþiile legale posibile între un cont sintetic si conturile sale corespondente ºi în dreptul fiecãrei combinaþii existã un câmp cu starea acelei combinaþii. Starea poate fi folosit sau blocat. Pentru combinaþiile pe care nu le folosim vom alege opþiunea blocat.

- resetarea tabelului Solduri ( prin rularea interogãrii Transfer_sold);

- stabilirea conturilor sintetice care se desfãºoarã pe nivelul doi ºi a conturilor care se desfãºoarã pe conturi analitice. Pentru fiecare cont analitic se va stabili pe câte nivele se desfãºoarã, câte cifre se adaugã la rãdãcina iniþialã pentru a se genera un nou cont analitic. În acest scop se va completa formularul Conturi_radacinã (detalii despre conturi analitice se gasesc la aliniatul Fisele conturilor desfãºurate pe conturi analitice din secþiunea 5, iar macheta tabelului se gãseºte în secþiunea 2), comun atât pentru conturile sintetice care se desfãºoarã pe nivelul doi cât ºi pentru conturile care se desfãºoarã pe conturi analitice. La stabilirea acestor conturi se va þine seamã de particularitãþile celor douã categorii de conturi menþionate în tabelul urmãtor, unde rubricile Funcþionare cod ºi Tranzacþii se referã la participarea codului în tabelele referitoare la funcþionarea conturilor ºi respectiv în registrul jurnal în tranzacþii, iar celelalte rubrici specificã dacã contul (rãdãcina) poate

19

fi inclus în documente de contabilitate cum ar fi fisa contului, carte mare sah ºi balanta.

- actualizarea tabelelor Matrice_debit ºi Matrice_credit cu ajutorul subrutinelor Genmat_debit ºi Genmat_debit din modulul Carte_sah

- actualizarea tabelelor Solduri_sintetice_debit ºi Solduri_sintetice_credit: pentru aceasta se vor rula subrutinele Setare_sintetice_debit ºi Setare_sintetice_debit din modulul Sintetice ( se va prevedea o opþiune de meniu pentru aceastã operaþiune);

- copierea fiºierelor de lucru create mai sus în fisiere de referinþã ºi în fiºiere de siguranþã;

Tipuri de Rãdãcinã

Funcþionare cod

Tranzacþii

Fisa contului

Fisa cont analitic

Balanta sinteticã

Fisa carte mare sah

Rad.

Sub-niv.

Rad.

Sub-niv.

Rad.

Sub-niv.

Rad Sub-niv.

Rad.

Sub-niv.

Rad.

Sub-niv.

Desfãºurate pe subnivele sintetice

Nu Da Nu Da Nu Da Da Nu * Da Da Nu Da

Desfãºurate pe subnivele analitice

Da Nu Nu Da Nu Da Da Nu Da Da Da Nu

7.2 Introducerea unui cont nou în timpul anului financiar.

(Stergerea unui cont nu este permisã) Simularea transei care conþine unul sau mai multe conturi noi se va desfãºura în bune condiþiuni numai dacã vom efectua urmãtoarele operaþii:

- se va parcurge primul aliniat de la punctul 7.1 ºi apoi se va deschide formularul Solduri_sintetice_debit ºi ulterior Solduri_sintetice_credit, unde se vor introduce manual datele despre combinaþiile noului cont.

- dacã este vorba de un cont care se desfãºoarã pe nivelul doi sau unul care se desfãºoarã pe conturi analitice, vom parcurge aliniatul 3 de la punctul 7.1

- vom copia fiºierele de lucru modificate mai sus în fisiere de referinþã. Cele de siguranþã mai rãmân. Ele vor fi înlocuite automat la urmãtoarea validare a tranºei, dar pânã atunci, dacã ne rãsgândim în privinþa noului cont vom restaura aceste fiºiere.

7.3 Inchiderea anului financiar ºi deschiderea altuia nou a) Inchiderea presupune urmãtoarele operatii: - validarea transei (aceastã operaþiune salveaza fisierele de lucru în fiºirele de referinþã, blocheaza opþiunea Simulare tranºã care va fi deblocatã numai la alegerea opþiunii Tranºã nouã când se va goli ºi tabelul Adaos_jurnal). - tipãrirea în prealabil a tuturor documentelor necesar a fi arhivate conform legii. În continuare se vor crea copii-arhivã

20

ale fiºierelor de referintã. Copiile-arhivã sunt fiºiere cu extensia _arh; b) Deschiderea noului exerciþiu financiar presupune: - modificarea tabelului PlanConturi cu datele ce se cer pentru începerea exerciþiului financiar ( de exemplu soldurile iniþiale vor lua valorile soldurilor curente din tabelul PlanConturi_ini, soldurile init vor fi adaptate valorilor soldului initial actualizat, soldurile curente rãmân în PlanConturi cum sunt, rulajele devin zero, sumele totale devin egale cu soldurile curente, rulajele totale se fac zero, soldurile precedente nu conteazã cu ce valoare rãmân pentru cã ele înainte de actualizarea soldului curent la viitoarea simulare, vor primi valoarea soldului curent); - dacã avem de introdus conturi noi, putem s-o facem acum, completându-le toate datele iniþiale în concordanþã cu cerinþele exprimate în aliniatul precedent , dar adãugând ºi modificãrile ce se impun în tabelele de funcþionare conturi. - efectuarea operaþiilor prevazute mai sus la aliniatele 2-5 de la punctul 7.1 (implementarea). Observaþie: Pentru toate cele 4 situaþii speciale descrise mai sus (7.1, 7.2, 7.3a ºi 7.3b) se vor prevedea opþiuni în meniul Configurare astfel:

- pentru implementare, opþiunea implementare; - pentru introducerea de cont nou, opþiunea cont nou; - pentru 7.3a ºi 7.3b se va introduce meniul Exerciþiu cu

douã opþiuni: inchidere si redeschidere. Schema procedurii logice ce se ruleazã la alegerea opþiunii Simulare transã:

Consolã (monitor) Simulare_efect_tranºã

opþiune din meniul

TRANSA Macroul Resetare_Impact Sold_conturi Sterge_sold_conturi: intrg-delete

PlanConturi Extrag_sold: intrg-append Sold_conturi Impact_rulaj_sold Sterge_impact: intrg-delete

21

Adaos_jurnal Impact_sold: subprg Sold_conturi

Macroul Resetare_efect Impact_rulaj_sold Evolutie_sold_cont Sterge_evolutie: intrg-delete Impact_rulaj_sold Efect_sold_cont: intrg-append Evolutie_sold_cont

22

Procedura logicã contiunã cu schema urmãtoare unde blocurile haºurate pregãtesc datele pentru obþinerea fiºelor conturilor analitice. Subroutine Transfer_Sold_Plan Intrg: make table

Planconturi Make-soldrad1 Soldrad1 Subroutine

Sold_conturi Transfer_Sold_Plan Planconturi Subroutine Separ_analitice Macro Intrg: delete

Evol_rad_cont Golesc_evol_rad_cont Macro Intrg: append

Evolutie_sold_cont Split_simbol_conturi Evol_rad_cont Subroutine

Conturi_radacina Separ_analitice Evol_rad_cont Evol_rad_cont Intrg: select Rulaje pe conturi analitice

Conturi_radacina

Intrg: make table Rulaje pe conturi intermediare Rulaje analitice1 Intrg: make table Rulaje analitice1 Rulaje pe conturi sintetice2 Rulaje analitice2 Evol_rad_cont Intrg: select

23

Rulaje pe conturi analitice1

Conturi_radacina Intrg: make table Rulaje pe conturi sintetice1 Rulaje sintetice1 1 1 Subroutine Act_date_planconturi

Intrg: append Rulaje analitice2 Combin_analitice2_cu_sintetice1 Rulaje sintetice1

Intrg: append Rulaje analitice1 Combin_ sintetice1_cu_ analitice1 Rulaje sintetice1

Subroutine Planconturi Rulaje sintetice1 Act_date_planconturi Sold_conturi

Subroutine Solduri_noi_pt_fise

Subroutine Planconturi Solduri_noi_pt_fise Soldrad1 Soldrad1 Docmd.CopyObject Soldrad2 Soldrad1 Docmd.CopyObject Soldcont_analitic

24

Subroutine Creare_rulaj_total Solduri Querydef: QdefTemp Extras_din_solduri Subroutine PlanConturi Creare_rulaj_total Extras_din_solduri Macro Extras_din_Sold Transfer_sinteza_transei Solduri Macro Adaos_jurnal Append_adaos Registru_jurnal Macro Evolutie_sold_cont Adaug_misc_fisa Fisa_cont 2

2 Subroutine Rulaj_coresp_debit Macro Matrice_rulaj_debit Golesc_ rulaj_debit Macro Extras_sintetice_debit Golesc_ extras_sintetice_debit

Solduri_sintetice_debit Querydef: QdefTemp Extras_sintetice_debit Matrice_debit

25

Sah_debit

3

Rulaj_coresp_debit Matrice_rulaj_debit

(cu rulaje curente)

Adaos_jurnal Matrice_debit Extras_sintetice_debit Rulaj_coresp_debit Matrice_rulaj_debit Matrice_rulaj_debit (cu rulaje curente) (cu rulaje totale)

Apeleazã Subroutine Rulaj_coresp_credit

Subroutine Rulaj_coresp_credit

Macro Matrice_rulaj_credit Golesc_ rulaj_credit Macro Extras_sintetice_credit Golesc_ extras_sintetice_credit

Solduri_sintetice_credit Querydef: QdefTemp Extras_sintetice_credit Matrice_credit

Rulaj_coresp_credit Matrice_rulaj_credit

(cu rulaje curente)

Adaos_jurnal

Matrice_credit Extras_sintetice_credit Rulaj_coresp_credit

Matrice_rulaj_credit Matrice_rulaj_credit (cu rulaje curente) (cu rulaje totale) Macro

3

26

Extras_sintetice_debit Adaug_extras_sintetice_debit Sold_sintetice_debit

Macro

Extras_sintetice_credit Adaug_extras_sintetice_credit Sold_sintetice_credit

subroutine Matrice_debit Adaos_jurnal subroutine Matrice_credit Adaos_jurnal

Schema procedurii logice utilizate pentru a elabora bilantul Structura bilant Formular actualizare Societatea Formular actualizare Subprg Planconturi Actualiz_sold_subclase Solduri_subclase

Planconturi Subprg Solduri_subclase Actualiz_sold_bilant

Solduri_bilant Structura_bilant Subprg Solduri Actualiz_datei_ultimei_transe

Societatea

Structura_bilant Intrg: make-table Solduri_bilant Asamblez_tabel_bilant Tabelul_bilant Societatea Raport Tabelul_bilant Bilantul Bilantul

27

1

Cursul_III_9 Tehnica elaborării fişei contului

1. Pentru a elabora fişa contului a cărei machetă este dată mai jos, dispunem de tabelul Evoluţie_sold_cont, din imaginea alăturată, creat cu ocazia simulării tranşei Totuşi acest tabel nu ne oferă toate infor-maţiile cerute de Fisa Contului. Lipsesc cele marcate în macheta Fisei Contului cu roşu. În macheta interogării se vede de unde am adus acele informaţii, iar în macheta formularului se vede cum le- am folosit. Să remarcăm că unele informaţii, cum ar fi

tipul soldului şi soldul contului, au fost legate de cont şi dacă le-am fi lăsat în banda Details, ele ar fi apărut pe fiecare rând, dar plasându-le în banda Cod_cont Footer, ele au apărut în exemplul de fisă cont o singură dată (vezi exemplul de fisă din ultima imagine de dinaintea secţiunii balanta sintetică) , în căsuţele marcate pe macheta fisei contului cu steluţă. Acelasi lucru s-a petrecut si cu sold_debit şi sold_credit din tabelul Sold_conturi, care de fapt sunt sume şi nu rulaje, pentru că iniţial pe locul lor a fost trecut soldul de luna trecută şi la el s-au adăugat valorile aduse de fiecare tranzacţie. Câmpul soldul initial a fost adus şi el tot pentru o singură apariţie şi anume cea din prima linie, unde se cere soldul iniţial. ___________________ FISA DE CONT (Unitatea) (Denumire cont)

Simbl. cont Pag 1011 1

Data Document Explicatii Simbol cont corespondent

DEBIT (valoare)

CREDIT (valoare)

D/C SOLD Fel Nr.

An 2001 Sold initial (redeschidere) TOTAL RULAJ TOTAL SUME/SOLD * * Macheta interogării:

Continuare interogare:

2

Continuare interogare:

Macheta raportului care va produce fisa contului

3

Exemplu de fişă cont obţinută cu raportul a cărui machetă este dată mai sus:

Structura de principiu a unui proiect de curs la disciplina

“Proiectare sisteme informatice”

I. Introducere Când beneficiarul unei aplicaţii de informatică se hotăreşte să informatizeze o parte din activitatea sa, el nu-şi propune să schimbe esenţa problemei, ci vrea numai să automatizeze prelucrările pe care problema respectivă le implică. De aceea noi trebuie să ne însuşim foarte bine activitatea ce face obiectul automatizării, să o modelăm sub forma obiectelor cu care se lucrează în informatică, să scriem programele capabile să facă prelucrările pe care beneficiarul vrea să le automatizeze şi pentru că acesta nu cunoaşte modelul nostru din calculator, trebuie să-i oferim un meniu cu opţiuni familiare beneficiarului, dar care să-i permită acestuia să apeleze programele şi deci să-şi rezolve problema pe care a dorit să o automatizeze. Acest aspect al informatizării seamănă foarte mult cu operarea unui televizor. Acolo utilizatorul dispune de o telecomandă prin care declanşează nişte procese, el nu ştie ce se petrece fizic în televizor, dar ştie ce vrea să vadă sau să audă de la acest dispozitiv. Din cele de mai sus, rezultă că după primirea temei de la beneficiar, analistul cere informaţii suplimentare de la utilizator, dar le traduce în mediul de lucru al calculatorului. Când este bine edificat asupra problemei, el se separă de beneficiar, se scufundă în realitatea virtuală a mediului de programare şi se mai întoarce înapoi după ce a terminat programarea, a proiectat şi elaborat meniul aplicaţiei şi a scris manualul de utilizare al acesteia. Un proiect de informatică trebuie să reflecte toate fazele acestui proces. Ele sunt de fapt etapele ciclui de viaţă ale sistemului informatic (CVDS), care au făcut obiectul teoriei predate la cursul de Proiectare sisteme informatice în semestrul întâi. Înainte de a derula acest paralelism între proiect şi metodologia de elaborare a sistemelor informatice (în cazul nostru metodologia specifică metodei Merise), se impune să remarcăm că proiectul trebuie să conţină în plus, un capitol de prezentare a aplicaţiei, iar în locul etapei de implementare, va conţine manualul de utilizare. Aceasta deoarece programele vor fi prezentate în anexă la sfârşitul proiectului, pentru a nu întrerupe fluxul prezentării proiectului într-o manieră cât mai apropiată de cea în care beneficiarul percepe problema propusă spre

4

informatizare. Prezentăm în continuare paralelismul ce trebuie să existe între CVDS şi structura de principiu a proiectului.

Etape CVDS Secţiuni ale proiectului 1 Prezentarea aplicaţiei Ana- liza

Modelare globală 2

Analiza aplicaţiei sau a sistemului informaţional studiat.

Modelare conceptuală Modelare organizaţională

Proiectarea logică 3 Proiectarea logică Proiectarea fizică 4 Proiectarea fizică Implementare 5 Manualul de utilizare Exploatare şi întreţinere 6 Anexa cu programele sursă Se impune să mai observăm că această structură este concepută pentru un caz general (inclusiv pentru un proiect de licenţă), dar având în vedere faptul că în contabilitate algoritmul de prelucrare a datelor este foarte bine pus la punct, chiar este legiferat, detalierea secţiunilor acestei structuri, cu excepţia celor care se referă la prezentarea domeniului de activitate ce urmează a fi informatizat (în cazul de faţă contabilitatea financiară), rămâne la latitudinea autorului proiectului. Principalul criteriu de notare a proiectului este funcţionarea sa pe calculator şi modul cum a fost susţinut de autor.

II. Structura proiectului 1. Prezentarea aplicaţiei. 1.1 Titlul aplicaţiei: de exemplu Elaborarea registrelor contabile şi a documentelor de sinteză. 1.2 Destinaţia aplicaţiei informatice. 1.3 Funcţiunile aplicaţiei informatice. 1.4 Cerinţe impuse aplicaţiei. 1.5 Societatea, intreprinderea sau instituţia unde s-a făcut studiul de caz. 2. Analiza sistemului informaţional studiat. 2.1 Descrieri şi definiţii (Conform legii contabilităţii nr. 82/91 sau următoarea lege aflată în vigoare. Multe răspunsuri se găsesc în bibliografie, poziţia 2); - Contabilitatea: definiţie; - Patrimoniul: formele de existenţă a bunurilor materiale; - Valorile bunurilor materiale, capitalul fix şi circulant, utilizările şi resursele; - Categoriile de active; - Cheltuielile: etape de derulare şi clasificarea cheltuielilor; - Veniturile: etape de derulare şi clasificarea veniturilor; - Formula de bază a rezultatului exerciţiului financiar; - Sistemul informaţional contabil: definiţie şi elemente componenete; - Documentele contabile: funcţii şi clasificare; - Rectificarea greşelilor în documente; - Verificările documentelor justificative: ce se urmăreşte în această activitate; - Arhivarea documentelor justificative; - Forme de contabilitate şi documente specifice fiecărei forme; - Documentele de sinteză şi raportare: enumerare; - Evaluarea patrimoniului:

- Etalonul bănesc: costuri şi preţuri, tarifele şi valorile; - Contul şi dubla înregistrare

A se vedea cursul_III_3+4

5

- Regulile de funcţionare a contului; - Regulile generale de funcţionare pentru conturi active şi conturi pasive; - Conturi bifuncţionale; - Dubla înregistare _ principiul de bază al contabilităţii:

- Analiza contabilă; - Formula contabilă; - Corectarea formulelor contabile greşite: formule de stornare;

- Scurtă prezentare a unităţii în care s-a desfăşurat studiul de caz: - Obiectul de activitate; - Organigrama structurii organizatorice; - Elemente ce decurg din legislaţia în vigoare (în special cea pe domeniul

contabilităţii) specifice unităţii studiate; - Principalii indicatori sintetici ai unităţii studiate: cifra de afaceri, profitul

brut, fondul de rulment, capitalul propriu, rata rentabiltăţii, etc.; - Descrierea funcţiilor/domeniilor specifice unităţii studiate; - Definirea subsistemelor informatice şi aplicaţiilor informatice

2.2 Comunicaţiile aplicaţiei: cu băncile, cu clienţii şi cu furnizorii: - dacă aceste comunicaţii sunt locale sau on_line; - dacă necesită instalare de workstation sau implementarea unei reţele; - descrierea conexiunilor aplicaţiei cu celelalte subsisteme/aplicaţii. 2.3 Viziunea asupra datelor:

- Definirea obiectivelor aplicaţiei: - Ce asigură contabilitatea conform legii contabilităţii nr. 82/91;

- Principii si convenţii contabile; - Funcţiile contabilităţii;

- Definirea intrărilor si iesirilor aplicaţiei în concordantă cu obiectivele stabilite. Se pot întocmi tabele de forma următoare:

Rapoarte: Cod raport Denumire raport Frecventa Descrierea raportului

Tabelul va fi urmat de machetele registrului jurnal, fisei contului, cărţii mari şah, balanţei şi bilantului precum şi de machetele contului de rezultate, denumit şi contul de profit şi pierdere, de macheta anexei la bilanţ (cuprinzând formularele cu repartizarea profitului, situaţia stocurilor şi a producţiei în curs de execuţie, situaţia creanţelor şi a datoriilor, situaţia plăţilor restante, situaţia activelor imobilizate, impozitele şi taxele datorate şi vărsate şi alte informaţii legate de activitatea unităţii, exprimate sintetic), iar dacă este cazul, şi de macheta raportului de gestiune. Grafice:

Cod si tip Denumire Frecventa Axa OX Axa OY 2D 3D Exemple de grafice: Evoluţia unui cont, repartiţia unei clase, evoluţie cheltuieli/venituri, pregătirea cumulilor grafici.

Indicatorii sintetici ca de exemplu: cifra de afaceri, profitul brut, fondul de rulment, capitalul propriu, rata rentabiltăţii, etc.; - Sistemul de codificare:

- Sistemul de conturi: conţinut şi clasificarea conturilor; - Planul de conturi.

2.4 Modelul conceptual de comunicaţii materializat prin tabelul de mai jos şi prin diagramă de flux.

Nr. Ordine al operatiei

Actor sursă

Actor destinatie Document/ situatie

Descriere flux

6

( A se vedea LabIII3.doc secţiunea 3.2 – modelarea conceptuală, aliniatul b)

2.5 Modelul conceptual de date (MCD) - baza de atribute (un tabel de forma celui de mai jos, unde atributul primeşte în C o steluţă dacă este calculat si în c - dacă este codificat):

Tipuri de atribute Tipuri de entităti Tipul de atribut

Tip, Lungime

C c Intrări Iesiri

I1 … Im E1 E2 … En Ent1 Ent2 … Entk

( a se vedea LabIII3.doc secţiunea 3.2 – modelarea conceptuală, aliniatul c) - matricea dependeţelor (dependenţa între două atribute înseamnă că valorii unuia dintre ele îi corespund una sau mai multe valori ale altui atribut; de exemplu unui nr_fact îi corespunde data_fact).

Aceasta conţine atributele provenite din documentele de intrare, atât pe verticală cât şi pe orizontală (doar că pe orizontală nu se mai scrie numele atributului, ci nr. crt. din prima coloană), iar la intersecţia a două atribute, dacă între ele există dependenţă funcţională se trece o steluţă. - MCD grafic sau tabelar. Pentru varianta tabelară se poate folosi un tabel de

forma următoare: Descriere MCD

Descrierea tipurilor de entităti Descrierea tipurilor de relatiiâ*

Tip entitate Tip proprietate Tip relatie Tip proprietate identificator Tip, lungime r R identificator Tip, lungime Cardinalitate colectie

( pentru modelul grafic a se vedea LabIII3.doc secţiunea 3.2 – modelarea conceptuală, aliniatul c). r=dimensiunea în octeţi a articolului iar R=nr max. de articole în tabel. 2.6 Modelul conceptual al prelucrărilor: pentru aplicaţia Elaborarea registrelor

contabile şi a documentelor de sinteză este facultativ. Acesta începe prin inventarierea procesele derulate la nivel conceptual şi apoi pentru fiecare proces mai complicat se va întocmi câte o schemă ca în modelul prezentat în LabIII3.doc secţiunea 3.2 – modelarea conceptuală, aliniatul d. 2.7 Modelarea organizaţională (MO), în cazul aplicaţiilor de contabiltate este

facultativă, deoarece numărul actorilor este mic, iar fluxul prelucrării datelor este impus prin logica actului de contabilitate.

3. Proiectarea logică a aplicaţiei. 3.1 Dicţionarul atributelor Dicţionarul atributelor stabileşte identificatorii şi condiţiile de validare pentru fiecare tip de atribut. Se poate folosi un tabel ca cel de mai jos: Denumire atribut Identificator Tip, lungime Conditii de validare

3.2 Modelul logic de date. Dăm mai jos un exemplu orientativ

1 0

0

1

1 0

CLIENTI Numãr AI ………….

TRANZ Numãr AI Cod_valutã Numãr_BSV

VALUTE Cod_valutã

MISC Nr_document Cod_valutã

Cifrele dispuse pe sãgeþile de legãturã între entitãþi semnificã deþinãtoarea cheii primare (cifra 1) ºi

7

3.3 Modelul logic al prelucrărilor: pentru aplicaţia Elaborarea registrelor contabile şi a documentelor de sinteză este facultativ. Pentru cazuri mai complicate se poate lua ca model diagrama din labIII4.doc, secţiunea 4, aliniatul d. 4. Proiectarea fizică a aplicaţiei. 4.1 Modelul fizic de date are rolul de a evidenţia următoarele elemente:

- specificatorul asociat relaţiei la nivel fizic (denumire tabel/relaţie în viziunea beneficiarului şi denumire tabel ca fişier, de ex. C:\SICSV\valute dbf);

- structura înregistrării; - accesul şi spaţiul fizic specific relaţiei; - constrângerile structurale referenţiale interrelaţii;

Tabelul următor este un exemplu de descriere a relaţiei “VALUTE”:

MFD 1. ENTITATEA Relaţia fizică Valute C:\Exchange\valute.dbf 2. ACCESUL I SPAÞIUL FIZIC

Indexare Spaţiul fizic ocupat chei Fişier index RCS R Total octeţi CP CS

COD_V -

Valute.ndx -

18 1000

3. CONSTRÂNGERI STRUCTURALE REFERENÞIALE INTERRELAÞII identificator relaţie CP CE TRANZ Nr_bsv Cod_v MISC Nr_doc Cod_v 4. STRUCTURA ÎNREGISTRÃRII Nr. Identificator Tip, lungime Condiţii de validare 1 2 3 4

COD_V CURS_CUMP CURS_V PROC_C

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

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

Se va întocmi câte un tabel ca cel de mai sus, pentru fiecare entitate. În cazul aplicaţiei Elaborarea registrelor contabile şi a documentelor de sinteză tabelul se poate înlocui cu o imagine capturată a fiecărui tabel luată din Design Mode. 4.2 Videoformatele de I/E: Se întocmeşte o listă cu videoformatele (formularele) după modelul următor:

Videoformatul Descriere Figura Tip Denumire Identificator Se include macheta fiecărui formular specificat în tabelul de mai sus. 4.3 Meniuri de prelucrare Se face precizarea că meniul principal de prelucrare pentru aplicaţia … este format din următoarele opţiuni şi subopţiuni descrise în ordinea utilizării acestora: (urmează un tabel cu structura celui de mai jos). Optiunea Subopţiunea Nivel Descriere Figura În continuare în documentaţie vor fi incluse machetele submeniurilor ce apar la alegerea unei opţiuni de meniu şi dacă este cazul se coboară în jos pe arborele meniului până la ultimul nivel 4.4 Modelul fizic al prelucrărilor (MFP) are rolul de a ilustra identificatorii

procedurilor, schemele de sistem, intrările, ieşirile şi funcţiile asociate acestora. Pentru aceasta se întocmeşte un tabel ca cel de mai jos:

8

Identificator Schema de sistem I/E Functii Un exemplu de astfel de tabel se poate vedea în LabIII6.doc, aliniatul d. 5. Manualul de utilizare (spre sfârşitul semestrului va fi un curs despre structura

manualului de utilizare). 6. Anexe:

- lista programelor sursă; - discheta cu programe bune de copiat în calculator şi de lansat în

execuţie. Observaţie: Proiectul va fi prezentat individual de fiecare student, în ultimele trei lucrări de laborator. Prin felul cum va exploata programul şi cum va răspunde la întrebările privind modul cum a fost conceput proiectul, studentul trebuie să demonstreze că este autorul proiectului pe care-l prezintă.

Bibliografie 1. Nicolae Dumitru Davidescu “Sisteme informatice financiar_bancare”, Editura All Beck, Bucureşti, 1998. 2. Gheorghe Dumitru “Bazele contabilităţii”, Editura Dobrogea, Constanţa , 2001 3. Gheorghe Popescu şi Elena Popescu, “ Elaborarea sistemelor informatice”, Editura “Ovidius” University Press, Constanţa, 2001. 4. Dumitru Oprea, "Analiza şi proiectarea sistemelor informaţionale economice", Editura Polirom, Bucureşti, 1999. 5. Pavel Năstase s.a. , “Baze de date Microsoft Access 2000”, editura Teora,

Bucureşti, 2000. 6. Gheorghe Popescu, cursuri, lucrări de laborator şi fişierul Notelab2.doc pe

dischetă.

1

Cursul_III_10 TEHNICA ELABORĂRII BALANÞEI SINTETICE Balanþa de verificare sinteticã are macheta urmãtoare:

Societatea BALANTA DE VERIFICARE PENTRU CONTURILE SINTETICE LA 31.12. 2001

Director, Contabil sef, Întocmit, Pentru Balanþa sinteticã nu se poate folosi o interogare pe tabelele existente din cauza unor conturi (cum ar fi cele analitice sau cele sintetice de rang II) ale cãror tranzacþii trebuie sã figureze în balanþã, dar valorile acestor tranzacþii nu participã la calculul totalului de grupã, deoarece ele au fost deja incluse în soldurile ºi respectiv rulajele conturilor de rang superior (adicã în contul sintetic desfãºurat pe conturi analitice , respectiv în conturi sintetice de rang I – cazul contului 442, desfãºurate pe conturi sintetice de rang II, de ex. 4424).

- Deaceea pentru Balanþa sinteticã se foloseºte un program (din modulul Pregatim_Balanta) numit Pregatire_balanta care creaza tabelul Balanta_tabel. Pe acest tabel se aplicã interogarea cu parametru numitã Balanþa sinteticã care este apoi apelatã de raportul cu acelaºi nume. Tabelul Balanta_tabel se obtine din tabelul Planconturi dupã ce acesta a fost actualizat complet pentru luna care s-a încheiat. La dezvoltarea acestui tabel se mai folosesc tabelele Conturi_radacina ºi Grupuri de conturi ale cãror machete sunt date mai jos.. Acesta din urma contine toate grupele de conturi asa cum sunt ele date în documentatia cu privire la planul de conturi în vigoare. Tabelul Balanta_tabel se creaza din meniul Prelucrãri, opþiunea Pregatire balanta iar in meniul Rapoarte trebuie doar sã alegem opþiunea Balanta si apoi vizualizare sau tipãrire. În ambele cazuri utilizatorul este solicitat sã spunã între ce grupe de coduri se va elabora raportul. Pentru un raport complet trebuie sã specificãm intervalul 10-99 (99 fiind de fapt rândul de Total General.)

CLA-SA

Grupa conturi

Con-tul

DENUMIRE CONT

SOLD PRECEDENT RULAJ LUNA TOTAL SUME SOLD FINAL DEBIT

CREDIT DEBIT CREDIT DEBIT CREDIT DEBIT CREDIT

TOTAL

2

Schema logicã a programului Pregatire_balanta este urmãtoarea:

3

Start

Initializam totalurile generale pentru solduri si rulaje

Initializam totalurile grupei curente de conturi Initializam codul grupei curente de coduri (grupacrt)

Pentru fiecare articol din Planconturi

Verificãm dacã grupa sa de conturi apartine la grupacrt

Da

Transferãm articolul in balanta_tabel

Verificãm dacã simbolul contului are mai mult de 4 caractere

Da

În tabelul Balanta-tabel se introduce rândul de total pe grupã de conturi. Initializãm grupa curentã cu noua valoare

Se actualizeazã totalurile gene-rale cu totalurile grupei

Verificam dacã primele 3 caractere din simbolul contului se gasesc printre conturile radacina

Da

Nu

Se actualizeazã totalurile grupei curente cu datele

Nu

S-a terminat explorarea tabelului PlanuluiConturi?

Nu

In tabelul balanta_tabel se adauga articolul cu total general

Stop

4

Lista programului Pregatire_balanta este urmãtoarea: ‘ Programul parcurge secvential tabelul plan conturi si ia de acolo fiecare articol si il trece in tabelul balanta_tabel, cumulând în acelasi timp valorile articolului la totalul grupei de conturi si la cel al clasei de conturi de care apartine. Sub pregatire_balanta() Dim mesaj As String Dim data_balanta As Date Dim denumirea_societatii As String Dim grupacrt As String Dim clasacrt As String Dim Sum_sold_initial_debit As Currency Dim Sum_sold_initial_credit As Currency Dim sum_sold_prec_debit As Currency Dim sum_sold_prec_credit As Currency Dim sum_rulaj_debit As Currency Dim sum_rulaj_credit As Currency Dim sum_total_suma_debit As Currency Dim sum_total_suma_credit As Currency Dim sum_Sold_debit As Currency Dim sum_Sold_credit As Currency Dim TSum_sold_initial_debit As Currency Dim TSum_sold_initial_credit As Currency Dim Tsum_sold_prec_debit As Currency Dim Tsum_sold_prec_credit As Currency Dim Tsum_rulaj_debit As Currency Dim Tsum_rulaj_credit As Currency Dim Tsum_total_suma_debit As Currency Dim Tsum_total_suma_credit As Currency Dim Tsum_Sold_debit As Currency Dim Tsum_Sold_credit As Currency Dim rad1 As String Set dbscontabil = CurrentDb Set rstPlancont = dbscontabil.OpenRecordset("Planconturi", dbOpenTable) Set rstbalanta = dbscontabil.OpenRecordset("Balanta_tabel", dbOpenTable) Set rstradacini = dbscontabil.OpenRecordset("conturi_radacina", dbOpenTable) Set rstgrupe = dbscontabil.OpenRecordset("grupuri_de_coduri", dbOpenTable) rstgrupe.Index = "codul_grupei" rstradacini.Index = "index1"

5

DoCmd.OpenQuery "golesc_balanta_tabel" mesaj = "Introduceti data pentru balanta sub forma ZZ.LL.AA" data_balanta = InputBox(mesaj) mesaj = "Introduceti denumirea societatii" denumirea_societatii = InputBox(mesaj) ‘ rstPlancont.Index = "nr_cont" rstradacini.Index = "radacina" TSum_sold_initial_debit = 0 TSum_sold_initial_credit = 0 Tsum_sold_prec_debit = 0 Tsum_sold_prec_credit = 0 Tsum_rulaj_debit = 0 Tsum_rulaj_credit = 0 Tsum_total_suma_debit = 0 Tsum_total_suma_credit = 0 Tsum_Sold_debit = 0 Tsum_Sold_credit = 0 rstPlancont.MoveFirst grupacrt = Left(rstPlancont!cod_cont, 2) clasacrt = rstPlancont!clasa ‘ Se initeazã totalurile pentru grupa de conturi Sum_sold_initial_debit = 0 Sum_sold_initial_credit = 0 sum_sold_prec_debit = 0 sum_sold_prec_credit = 0 sum_rulaj_debit = 0 sum_rulaj_credit = 0 sum_total_suma_debit = 0 sum_total_suma_credit = 0 sum_Sold_debit = 0 sum_Sold_credit = 0 Do While rstPlancont.EOF = False If Left(rstPlancont!cod_cont, 2) <> grupacrt Then ‘ Dacã în tabelul PlanConturi s-a trecut la o noua grupã de conturi, atunci ‘ în tabelul Balanta-tabel se introduce rândul de total pe grupã de conturi With rstbalanta .AddNew !cod_cont = "TOTAL" !clasa = clasacrt rstgrupe.MoveFirst rstgrupe.Seek "=", grupacrt If rstgrupe.NoMatch = False Then !den_cont = rstgrupe!den_grupa !Sold_initial_debit = Sum_sold_initial_debit !Sold_initial_credit = Sum_sold_initial_credit

6

!sold_prec_debit = sum_sold_prec_debit !sold_prec_credit = sum_sold_prec_credit !Rulaj_debit = sum_rulaj_debit !Rulaj_credit = sum_rulaj_credit !total_suma_debit = sum_total_suma_debit !total_suma_credit = sum_total_suma_credit !Sold_debit = sum_Sold_debit !Sold_credit = sum_Sold_credit !grupa = grupacrt !Denumire_societate = denumirea_societatii !Data_balantei = data_balanta End If .Update End With

‘ Se actualizeazã totalurile generale pt. grupa care s-a incheiat TSum_sold_initial_debit = TSum_sold_initial_debit + Sum_sold_initial_debit TSum_sold_initial_credit = TSum_sold_initial_credit + Sum_sold_initial_credit Tsum_sold_prec_debit = Tsum_sold_prec_debit + sum_sold_prec_debit Tsum_sold_prec_credit = Tsum_sold_prec_credit + sum_sold_prec_credit Tsum_rulaj_debit = Tsum_rulaj_debit + sum_rulaj_debit Tsum_rulaj_credit = Tsum_rulaj_credit + sum_rulaj_credit Tsum_total_suma_debit = Tsum_total_suma_debit + sum_total_suma_debit Tsum_total_suma_credit = Tsum_total_suma_credit + sum_total_suma_credit Tsum_Sold_debit = Tsum_Sold_debit + sum_Sold_debit Tsum_Sold_credit = Tsum_Sold_credit + sum_Sold_credit ‘ se iniþializeazã grupa urmãtoare ºi clasa (pentru clase nu se fac totaluri) grupacrt = Left(rstPlancont!cod_cont, 2) clasacrt = rstPlancont!clasa ‘ºi se dã cursorul cu un articol înapoi (pentru cã acum programul se duce la ‘sfârsitul buclei ºi acolo automat se trece la articolul urmãtor) ºi se iniþializeazã totalurile noii grupe de conturi rstPlancont.Move -1 Sum_sold_initial_credit = 0 Sum_sold_initial_credit = 0 sum_sold_prec_debit = 0 sum_sold_prec_credit = 0 sum_rulaj_debit = 0 sum_rulaj_credit = 0

7

sum_total_suma_debit = 0 sum_total_suma_credit = 0 sum_Sold_debit = 0 sum_Sold_credit = 0

Else ‘ Dacã grupa de conturi continua, transferãm articolul in balanta tabel

With rstbalanta .AddNew !cod_cont = rstPlancont!cod_cont !clasa = rstPlancont!clasa !Sold_initial_debit = rstPlancont!Sold_initial_debit !Sold_initial_credit = rstPlancont!Sold_initial_credit !den_cont = rstPlancont!den_cont !sold_prec_debit = rstPlancont!sold_prec_debit !sold_prec_credit = rstPlancont!sold_prec_credit !Rulaj_debit = rstPlancont!Rulaj_debit !Rulaj_credit = rstPlancont!Rulaj_credit !total_suma_debit = rstPlancont!total_suma_debit !total_suma_credit = rstPlancont!total_suma_credit !Sold_debit = rstPlancont!Sold_debit !Sold_credit = rstPlancont!Sold_credit !grupa = Left(rstPlancont!cod_cont, 2) !Denumire_societate = denumirea_societatii !Data_balantei = data_balanta .Update End With ‘ Acum verificãm dacã articolul crt. Participã la totalul grupei:

If Len(rstPlancont!cod_cont) > 4 Then ‘ Dacã avem de a face cu un cont analitic el nu contrinuie la cresterea totalului clasei deoarece el este inclus in soldurile si rulajele contului sintetic de care apartine GoTo nosum Else ‘ Dacã un cont are 4 caractere atunci extragem primele 3 si vedem daca sunt suficiente pentru un cod de cont rad1 = Left(rstPlancont!cod_cont, 3) rstradacini.MoveFirst rstradacini.Seek "=", rad1 If rstradacini.NoMatch = False Then ‘ Dacã da, si lungimea contului curent este de 4 caractere, inseamnã cã avem de a face cu un cont sinteic de rang 2 si nici acestea nu participã la totalul grupei de conturi

8

If Len(rstPlancont!cod_cont) = 4 Then GoTo nosum End If End If End If

‘ Conturile care nu sunt analitice sau conturi sintetice de rang 2, participã la totalul grupei de conturi With rstPlancont Sum_sold_initial_debit = Sum_sold_initial_debit + !Sold_initial_debit Sum_sold_initial_credit = Sum_sold_initial_credit + !Sold_initial_credit sum_sold_prec_debit = sum_sold_prec_debit + !sold_prec_debit sum_sold_prec_credit = sum_sold_prec_credit + !sold_prec_credit sum_rulaj_debit = sum_rulaj_debit + !Rulaj_debit sum_rulaj_credit = sum_rulaj_credit + !Rulaj_credit sum_total_suma_debit = sum_total_suma_debit + !total_suma_debit sum_total_suma_credit = sum_total_suma_credit + !total_suma_credit sum_Sold_debit = sum_Sold_debit + !Sold_debit sum_Sold_credit = sum_Sold_credit + !Sold_credit End With

End If nosum: rstPlancont.MoveNext Loop 'Adaugam un articol cu totalul ultimei grupe: With rstbalanta .AddNew !cod_cont = "TOTAL" !clasa = clasacrt rstgrupe.MoveFirst rstgrupe.Seek "=", grupacrt If rstgrupe.NoMatch = False Then !den_cont = rstgrupe!den_grupa !Sold_initial_debit = Sum_sold_initial_debit !Sold_initial_credit = Sum_sold_initial_credit !sold_prec_debit = sum_sold_prec_debit !sold_prec_credit = sum_sold_prec_credit !Rulaj_debit = sum_rulaj_debit !Rulaj_credit = sum_rulaj_credit !total_suma_debit = sum_total_suma_debit !total_suma_credit = sum_total_suma_credit

9

!Sold_debit = sum_Sold_debit !Sold_credit = sum_Sold_credit !grupa = grupacrt !Denumire_societate = denumirea_societatii !Data_balantei = data_balanta End If .Update End With ' Totalul ultimei grupe il adaugam si la total general: TSum_sold_initial_debit = TSum_sold_initial_debit + Sum_sold_initial_debit TSum_sold_initial_credit = TSum_sold_initial_credit + Sum_sold_initial_credit Tsum_sold_prec_debit = Tsum_sold_prec_debit + sum_sold_prec_debit Tsum_sold_prec_credit = Tsum_sold_prec_credit + sum_sold_prec_credit Tsum_rulaj_debit = Tsum_rulaj_debit + sum_rulaj_debit Tsum_rulaj_credit = Tsum_rulaj_credit + sum_rulaj_credit Tsum_total_suma_debit = Tsum_total_suma_debit + sum_total_suma_debit Tsum_total_suma_credit = Tsum_total_suma_credit + sum_total_suma_credit Tsum_Sold_debit = Tsum_Sold_debit + sum_Sold_debit Tsum_Sold_credit = Tsum_Sold_credit + sum_Sold_credit '&&&&&&&&&&&&&&&&&&&&& With rstbalanta .AddNew !cod_cont = " " !clasa = " " !den_cont = " TOTAL GENERAL" !Sold_initial_debit = TSum_sold_initial_debit !Sold_initial_credit = TSum_sold_initial_credit !sold_prec_debit = Tsum_sold_prec_debit !sold_prec_credit = Tsum_sold_prec_credit !Rulaj_debit = Tsum_rulaj_debit !Rulaj_credit = Tsum_rulaj_credit !total_suma_debit = Tsum_total_suma_debit !total_suma_credit = Tsum_total_suma_credit !Sold_debit = Tsum_Sold_debit !Sold_credit = Tsum_Sold_credit !grupa = "99" !Denumire_societate = denumirea_societatii !Data_balantei = data_balanta .Update End With MsgBox "Am terminat pregatirile pentru balanta" rstPlancont.Close

10

rstbalanta.Close rstradacini.Close rstgrupe.Close dbscontabil.Close End Sub Structura tabeleleor Conturi_radacina si Grupuri_de_coduri

Structura tabelului Balanta_tabel

Macheta interogarii Balanta sintetica

Macheta raportului Balanta Sintetica

11

1

Cursul_III_11 ELABORAREA FIŞEI CARTE MARE ŞAH (DEBIT RESPECTIV CREDIT) Macheta fişei carte mare sah, care se întocmeşte pentru fiecare cont sintetic, separat pe debit şi separat pe credit, arată în principiu ca în tabelul de mai jos, numai că numărul conturilor coresponedente fiind foarte mare (adeseori peste 20), este neceasr ca tabelul să fie editat pe mai multe pagini, fiecare pagină conţinând grupe de câte 6-7 conturi Cu alte cuvinte tabelul se rupe pe verticală, având grijă ca pe fiecare foaie de continuare să fie prezente primele trei coloane de pe prima foaie, urmate de conturile care nu au încăput pe foile precedente. CARTEA MARE (SAH) Denumirea contului

Simbol cont Debit Pagina Credit

Nr. din Registrul jurnal

Data Operaţiei 200_

Suma

Conturi corespondente

Suma Rulaje cumulate Din analiza machetei de mai sus se poate deduce că pentru obţinerea unor tabele apropiate de structura fişei carte mare şah (să le spunem de aici încolo sah_debit şi respectiv sah_credit) ar trebui să dispunem de conturile corespondente fiecărui cont sintetic, informaţie care în baza noastră de date, se găseşte în tabelul Functionare cont_debit, respectiv credit. În continuare, când vrem să obţinem fişa unui cont sintetic, ( de exemplu pe debit) trebuie să parcurgem secvenţial tabelul Adaos_jurnal, să verificăm dacă tranzacţia analizată din acest tabel, are în câmpul cont_debitor contul pentru care întocmim fişa şi dacă celălalt cont (contul_creditor), se află printre conturile corespondente, adică printre conturile cu care se debitează contul pentru care întocmim fişa. Dacă răspunsul este afirmativ la cele două criterii enumerate mai sus, tranzacţia va fi selectată pentru a fi inclusă în tabelul sah_debit, numai că acest tabel (ca de altfel şi sah_credit), are o particularitate: el nu are pentru câmpul valoare o singură coloană cum are tabelul Ados_jurnal, ci pentru valoare are atâtea coloane câte conturi corespondente are contul pentru care întocmim fişa. De exemplu dacă în conformitate cu regulile de funcţionare a contului 371 el se debitează cu 14 conturi, zona “Conturi corespondente” din macheta de mai sus şi în mod similar şi zona “Conturi corespondente” din tabelul sah_debit respectiv sah_credit va dispune de 14 coloane, iar valoarea luată din tabelul Adaos_jurnal va fi plasată în dreptul contului corespondent care în tabelul Adaos_jurnal se află în coloana cont_creditor. De exemplu, dacă într-un un articol din Adaos_jurnal la contul_debitor se află 371 şi la cont_ creditor se găseşte 301, iar în lista conturilor cu care 371 se debitează, contul 301 este pe locul 2, atunci valoarea din Adaos_jurnal, va fi depusă în zona “Conturi corespondente”, în coloana doua, rezervată contului 301. Cu alte cuvinte, tabelele sah_debit şi respectiv sah_credit, au în zona “Conturi corespondente” o structură variabilă (în sensul că denumirile coloanelor din aceste zone diferă de la un cont sintetic la altul atât ca număr cât şi ca denumire). Problema care se pune este cum să construim aceste tabele? Răspunsul este că putem păstra o denumire generică comună, de exemplu cont1, cont2, … , dar având grijă ca pe fiecare rând din acest tabel, coloanele să corespundă

2

Sah_debit Sah_debit

Sah_credit Sah_credit

ordinii în care sunt enumerate conturile corespondente pentru contul sintetic la care se referă acel rând, fără să ne intereseze ce conturi corespondente cad în acea coloană în celelate rânduri. De exemplu am văzut mai sus că un articol aparţinând contului sintetic 371 dacă la cont_creditor are valorea 301, valoarea din acel articol se va depune în tabelul sah_debit în coloana doua (pentru că în lista conturilor cu care 371 se debitează, contul 301 este pe poziţia doua). Acum, trecând la contul sintetic 381, care se debitează cu 401, 408, 542, dacă parcurgând tabelul Adaos jurnal, la un moment dat găsim o tranzacţie care în câmpul cod_debitor conţine 381, valoarea din Adaos_jurnal, nu o vom pune în coloana doua decât dacă în Adaos_jurnal, în câmpul cont_creditor este trecut contul 408, pentru că pe linia contului 381, el ocupă coloana doua. Cu alte cuvinte în tabelul ªah debit, semnificaţia coloanei a doua din zona “Conturi corespondente”, ca de altfel şi a tuturor celorlalte coloane din această zonă, diferă de la un articol la altul, în funcţie de contul sintetic căruia i se asociază articolul, numai că în faza actuală, în lista unui cont sintetic dat, noi nu ştim ce poziţie ocupă un cont corespondent sau altul. Macheta tabelului Funcţionare cont_debit de exemplu este una foarte simplă: cont şi cont relaţie, dar această machetă nu ne ajută în rezolvarea problemei formulate mai sus. De aceea tabelele Funcţionare cont_debit, respectiv Funcţionare cont_credit au fost transformate în alte două tabele numite Matrice_debit, respectiv Matrice_credit. Machetele acestor tabele sunt de forma următoare: Cod_cont_sintetic, nr_coduri_cumulate, cont1, cont 2…cont20. Se deduce de aici că fiecare cont sintetic ocupă în această matrice un singur rând, ca în exemplul de mai jos, unde din cele 14 conturi corespondente contului 371 nu apar decât primele 8, dar în tabel există şi restul până la 14, ultimele două fiind 607 şi 771.

Programele care generează aceste tabele sunt Genmat_debit, respectiv Genmat_credit. De exemplu programul Genmat_debit funcţionează astfel: parcurge secvential tabelul PlanConturi si pentru fiecare cont din acest tabel verifică dacă este prezent printre codurile sintetice din tabelul "funct_cont_debit". Dacă da, se extrag din tabelul "funct_cont_debit" toate conturile ce se refera la codul cu care am venit din PlanConturi si se depun in tabelul "extras_debit". In continuare tabelul "extras_debit" este stocat sub forma unui singur articol în tabelul "matrice_debit". Acest program se rulează o singură dată, la începutul exerciţiului financiar şi ori de câte ori se introduce un cont nou în planul de conturi. Dacă cineva s-ar întreba de ce am mai creat tabelele Funcţionare cont_debit şi Funcţionare cont_credit dacă ele trebuie înlocuite cu tabelele Matrice_debit, respectiv Matrice_credit răspunsul este că tabelele Matrice_debit şi Matrice_credit ar fi foarte greu de completat de utilizator. Dispunând de tabelele Matrice_debit şi Matrice_credit, procedura logică de obţinere a tabelelor Sah_debit şi Şah_credit este următoarea (Să remarcăm că noi nu generăm aceste tabele pentru fiecare fisă carte mare şah, ci generăm un tabel Şah_debit şi unul Şah_credit pentru toate conturile sintetice şi când se cere fişa Carte mare şah a unui cont, doar selectăm din tabelul corespunzător, articolele care se referă la contul respectiv) subroutine Matrice_debit Adaos_jurnal

subroutine Matrice_credit

Adaos_jurnal

3

Din cele prezentate până aici, nu am făcut decât să formulăm problema pe care trebuie să o rezolve programul Sah_Debit, dar în mod similar se poate formula şi problema pentru programul Sah_Credit. Discutând pe machete de tabele, problema pe care trebuie s-o rezolve programul Sah_Debit, se poate reformula astfel: Cu datele din tabelul Adaos jurnal şi cu ajutorul tabelului Matrice_debit, trebuie să completăm tabelul Sah_Debit, care are structura de mai jos (în realitate, între câmpul Cont_sintetic şi primul câmp din zona Conturi Corespondente mai există patru câmpuri, dar pentru moment, ele nu prezită interes aşa că au fost omise): Cont sintetic

Conturi Corespondente Cont1 Cont2 Cont3 … Cont19 Cont20

unde Cont1, Cont2, …, Cont20, are semnificaţia luată din tabelul Matrice Debit, de pe rândul rezervat contului sintetic specificat în prima coloană a tabelului Sah_Debit. Este ca şi cum peste zona cu numele cont1, cont2, …, cont20, din tabelul de mai sus, am pune o grilă conţinând conturile corespondente contului sintetic specificat în prima coloană. De exemplu pentru contul sintetic 371, parcurgând tabelul Adaos_jurnal, s-ar putea să avem de completat în tabelul Sah_Debit, câteva rânduri consecutive, bazate pe următoarea structură a zonei Conturi Corespondente: Cont sintetic

Conturi Corespondente 300 301 321 … 607 771

Să observăm că din tabelul Matrice_debit rezultă câte conturi corespondente are contul sintetic 371, adică 14 şi de aceea ne-am limitat la a completa pe primul rând doar 14 conturi (celelalte nu ne interesează). Având această situaţie, dacă în tabelul Adaos_jurnal am fi întâlnit un articol având cont_debit 371 , cont_sintetic 301 şi valoare – de exemplu 10.000.000, tabelul de mai sus s-ar fi completat astfel: Cont sintetic

Conturi Corespondente 300 301 321 … 607 771

371 10000000 După ce vom parcurge odată tot tabelul Adaos_jurnal pentru contul 371, îl vom parcurge încă odată pentru fiecare cont sintetic şi când vom ajunge la contul sintetic 381, tabelul nostru va trebui văzut ca în tabelul următor (cu observaţia că articolele stocate în tabel până la intrarea în vigoare a grilei contului 381 se referă la capul de tabel care era în vigoare când au fost create. De exemplul suma de 10.000.000 de pe lina contului 371 se referă totuşi la contul 301 şi nu la 408 cum se vede acum în acest tabel)

Cont sintetic

Conturi corespondente 401 408 542

371 10.000.000 … … … … … … …

Acum dacă în tabelul Adaos_jurnal am găsit un articol având cont_debit 381, cont_credit 408 şi la valoare are 500.000, cele 500.000 se vor referi la capul de tabel care este în vigoare acum, adică la contul 408 şi nu la 301.

Cont sintetic

Conturi corespondente 401 408 542

371 10.000.000 … … … … … … … 381 5.00.000

4

Este ca şi cum în zona “Conturi corespondente”, tabelul Sah_debit ar avea capul de tabel variabil şi pentru a citi corect tabelul trebuie mai întâi să venim cu grila care era activă când s-a creat articolul care ne interesează. Grila nu este altceva decât rândul corespondent contului sintetic, din tabelul Matrice_debit! Dacă acum ne este clar CE trebuie să facă programul Sah_debit, să vedem CUM va arăta acest program. Pentru aceasta este suficient să întocmim pseudocodul acestui program, aşa cum apare în schema de mai sus.

Do While Not rstmatrice.EOF For i = 1 To 20 Next i Do While Not rstAdaos.EOF If rstAdaos!cont_debitor = crtcont Then . For i = 0 To 19 If rstAdaos!cont_creditor = grila(i) Then With rstsah_debit .AddNew Acum valoarea se va depune exact pe poziţia unde s-a depistat în vectorul grila contul corespondent egal cu contul creditor al articolului curent din Adaos_jurnal. .Fields(i + 5) = rstAdaos!valoare Actualizăm rulajul contului corespondent aflat pe poziţie de cont_creditor: rulaje(i) = rulaje(i) + rstAdaos!valoare .Update End With De îndată ce i-am găsit poziţia contului_creditor în vectorul grila, abandonăm ciclările cu Exit For: Exit For End If Next i End If rstAdaos.MoveNext Loop

Dacă articolul curent din Matrice_debit nu a avut nici o tranzactie atunci If sumasintetic = 0 Then With rstsah_debit .AddNew !cont_sintetic = crtcont !Nr_coduri_cumulate = Nrconturi !nr_crt = 0 !data_inreg = Date !suma = sumasintetic For i = 0 To 19 .Fields(i + 5) = rulaje(i) Next i

Dacã cont_debitor din Adaos_jurnal se refera la contul_sintetic din Matrice_debit atunci

In tabelul sah_debit adãugãm un articol nou Pe care-l completãm cu date din Adaos jurnal

Instalam grila si vectorul Rulaje

In pseudocod nu se trec detalii. De exemplu în fata instructiunii Do While Not rstAdaos.EOF nu mai scriem rstAdaos.MoveFirst. Aceasta se va scrie în program, aici urmãrim esentialul

Intr-un pseudocod respectarea regulilor de sintaxã nu este obligatorie. De exemplu puteam scrie doar cã în noul articol (vezi secventa AddNew-Update din stânga) se completeazã câmpurile noului articol cu date dupã cum urmeazã: cont_sintetic cu crtcont, Nr_coduri_cumulate cu Nrconturi, nr_crt = 0, data_inreg = Date si suma = sumasintetic Bucla For, fiind mai usor de scris decât de descris se va scrie asa cum este scrisã în program; depinde de preferintele celui care trebuie sã scrie programul!

Update End With End If rstmatrice.Move Loop

5

În continuare trebuie să formulăm câte o interogare cu parametru pentru fiecare din tabelele sah_debit şi sah_credit (parametru fiind codul contului pentru care dorim fisa carte mare sah). De fapt nu vom formula câte o interogare, ci câte trei pentru că aşa cum am specificat la început, o fişă carte mare sah trebuie ruptă, în trei fise complementare. De exemplu pentru tabelul Sah_debit, prima interogare va include contul sintetic, denumirea, soldul_debit şi soldul _initial _debit din tabelul PlanConturi, nr_crt, data_înreg, suma şi primele 6 câmpuri din zona “Conturi corespondente” din tabelul Sah_debit, primele 6 câmpuri din tabelul Matrice_debit şi primele 6 câmpuri din zona “Conturi corespondente” din tabelul Matrice_rulaj_debit Acesta din urmă va furniza informaţiile pentru rândul Rulaje cumulate care se află sub rândul Suma. ( a se vedea macheta tabelului de la începutul acestui curs). Câmpurile provenite din tabelul Matrice_debit şi din PlanConturi ca si cele provenite din Matrice_rulaj_debit nu vor fi lăsate în banda Details, ci vor fi mutate cu mouse-ul pentru ca să dea coloanelor din zona “Conturi corespondente” denumirile care le reprezintă, adică conturile corespondente contului sintetic la care se referă fisa carte mare sah debit şi pentru a completa unele informaţii din antetul fişei. Iată cum din nou se pune grila pentru descifrarea conţinutului tabelului Şah_debit. Din conţinutul interogării descris mai sus, rezultă că pentru a rula acea intrerogare mai avem nevoie şi de tabelul Matrice_rulaj_debit şi respectiv de Matrice_rulaj_credit. De fapt, în secvenţa de programe care se rulează la rularea procedurii Simulare tranşă programul Rulaj_debit, respectiv Rulaj_credit se rulează imediat înaintea programelor Sah_debit, respectiv Sah_credit. În continuare pe fiecare din aceste interogări se vor crea rapoarte. Începând cu a doua interogare, câmpul Suma lipseşte şi în locul lui va mai trece un cont corespondent, astfel că o fişă va conţine câte 7 conturi corespondente. În meniu, va trebui să avem opţiuni pentru fişe debit şi fişe credit şi apoi pentru fiecare din cele trei fragmente în care se poate diviza o fişă carte mare şah.

Inainte de a proiecta interogările şi rapoartele necesare pentru obţinerea fişei carte mare şah, să facem precizările necesare pentru scrierea programelor Rulaj_debit, respectiv Rulaj_credit. Vom pleca de la macheta tabelului Matrice_rulaj_debit, a cărui machetă este dată mai jos:

Macheta continua până la rulajcont27 (deci tabelul este conceput pentru 27 de conturi corespondente) iar la sfârşit mai are două câmpuri: rulaj_total şi data, care este data curentă din momentul rulării programului Rulaj_debit. Câmpul Rulaj_total este rulajul contului sintetic specificat în prima coloană şi reprezintă suma rulajelor asociate conturilor corespondente conturilor sintetice specificate în tabelul Matrice_debit, a cărui machetă rezultă din exemplul de articol de mai jos. Ca şi în tabelul Matrice_debit şi în tabelul Matrice_rulaj_debit, un cont

sintetic ocupă un singur articol. Programul Rulaj_debit reactualizează tabelul Matrice_rulaj_debit care conţine rulajul cumulat pentru fiecare cont corespondent a fiecărui cont sintetic. Reactualizarea este necesară pentru tranzacţiile sosite cu ultima transă. De aceea acest program se rulează după ce s-a rulat programul Impact_sold şi

6

după actualizarea tabelului PlanConturi care conţine şi rulajele cumulate ale fiecărui cont. În tabelul PlanConturi rulajele cumulate se găsesc sub denumirea de rulaj_total_debit. Considerând executată actualizarea tabelului PlanConturi putem trece la scrierea programului Rulaj_debit. Pentru aceasta: - golim tabelul Matrice_rulaj_debit de conţinut (rulând o interogare de tip delete) - pentru fiecare articol din Matrice_debit, generăm un vector de 27 de conturi numit

coresp şi unul de 27 de rulaje cumulate (pentru conturile corespondente ale contului sintetic curent) numit rulaje; mai initializăm o variabilă, numită rulajtotal unde vom cumula toate rulajele totale ale conturilor corespondente contului sintetic a cărui rând din Matrice_debit este în prelucrare.

- pentru fiecare articol din Matrice_debit, se descarcă conturile corespondente în vectorul de conturi şi apoi parcurgând secvential acest vector se verifică dacă contul corespondent curent din el se găseşte în tabelul Planconturi. Dacă nu se găseşte dăm un mesaj de forma “Codul … nu se găseşte în Planconturi” şi trecem la contul sintetic următor. Dacă da, se ia rulajul total_debit de acolo şi se depune în vectorul rulaje, în poziţia corespunzătoare contului corespondent curent care tocmai a fost găsit în PlanConturi. În acelaşi timp rulajul total_debit se adună la rulajtotal. Când tot vectorul Coresp a fost explorat, în tabelul Matrice_rulaj_debit adăugăm un articol nou în care completăm câmpurile cod_cont_sintetic, .Nr_coduri_cumulate cu valorile luate din tabelul Matrice_debit, rulaj_total cu rulajtotal şi data zilei (data curentă). In continuare, în acelaşi articol completăm rulajele totale preluate din vectorul rulaje. Acum se poate trece la următorul articol din tabelul Matrice_debit. Când acest tabel s-a terminat, tabelul Matrice_rulaj_debit poate fi folosit în interogarea care va sta la baza raportului ce va genera Cartea mare sah_debit. Schema logică a programului Rualj_debit este dată pe pagina următoare.

7

În continuare sunt prezentate machetele interogărilor şi rapoartelor necesare pentru obţinerea fişei carte mare şah.

altminteri

Instalãm coresp si vectorul rulaje

Pentru fiecare articol din Matrice debit

Dacã Se gãseste cu Seek in tabelul PlanConturi

Pentru fiecare cont coresp. din Coresp

Dacã tot vectorul coresp a fost confruntat cu tabelul PlanConturi

In tabelul Matrice_rulaj_debit adãugãm un articol nou cu datele de la inceputul si sfãrsitul articolului din matrice_debit, iar la mijloc vom depune rulajele totale ale fiecãrui cont corespondent aflate pentru moment in vectorul rulaje .

Start

End

atunci

atunci

altminteri

In vectorul rulaje aducem rulajul sau total din PlanConturi

S-a terminat Matrice debit?

Nu

Da

Dam un mesaj cu faptul cã exista un cont corespon- dent care nu figureaza in Planul de conturi

8

9

Anexa Lista comentata a programului Sah_debit: În zona instrucţiunilor declarative va trebui să aibă declarat un vector ( de exemplu grila) în care să depunem conturile corespondente ale contului sintetic curent (contul din Matrice_debit). Dacă pe timpul prelucrării tranzacţiilor ce se referă la contul sintetic curent am vrea să stocăm într-un vector suma valorilor asociate fiecărui cont corespondent, am putea folosi un alt vector (rulaje) care, când se trece la un nou cont sintetic trebuie zerorizat. Dim grila(20) As String Dim rulaje(20) As String Dacă grila ar fi fost o matrice de 100 de rânduri atunci s-ar fi declarat grila(20,100). În cazul nostru nu a fost nevoie de o matrice, pentru că fiecare articol din tabelul Matrice_debit poate fi considerat un rând dintr-o matrice. De aceea tabelul se numeşte Matrice_debit, respectiv Matrice_credit. Când ne referim la un element al unei matrici trebuie să indicăm linia şi coloana pe care se află acel element, sub forma a două numere. De exemplu grila (5,25) ar însemna al 25-lea element din linia 5-a. Am mai declarat variabila i ca index curent pentru vectorul grila şi sumasintetic unde vom ţine la zi suma valorilor acumulate de contul sintetic curent: Dim i As Integer Dim sumasintetic As Currency Golim tabelul Sah_debit de conţinutul rămas de luna trecută: DoCmd.RunMacro "sterg_sah_debit" Atribuim valori obiectelor DAO cu care vom lucra în acest program: Set dbscontabil = OpenDatabase("C:\anuIIIfc\Contab97.mdb") Set rstAdaos = dbscontabil.OpenRecordset("Adaos_jurnal", dbOpenTable) Set rstmatrice = dbscontabil.OpenRecordset("matrice_debit", dbOpenTable) Set rstsah_debit = dbscontabil.OpenRecordset("sah_debit", dbOpenTable) Începem navigaţia secvenţială prin tabelul matrice_debit: rstmatrice.MoveFirst Do While Not rstmatrice.EOF

10

Din articolul curent din Matrice_debit preluăm primele două câmpuri în nişte variabile cu denumiri mai scurte (şi acestea trebuiau declarate la începutul programului, dar aici rândurile respective nu figurează): crtcont = rstmatrice!cod_cont_sintetic Nrconturi = rstmatrice!Nr_coduri_cumulate Iniţializăm suma valorilor ce se vor acumula pe timpul prelucrării tranzacţiilor specifice contului sintetic curent: sumasintetic = 0 Acum descărcăm conturile corespondente contului sintetic curent în vectorul grila şi iniţializăm sumele valorilor conturilor corespondente cu zero: For i = 1 To 20 Să observăm mai jos, că în Access ne putem adresa unui câmp şi fără să-i folosim numele ci doar poziţia sa în colecţia Fields (colecţia de câmpuri) a recordset-ului de care aparţine (noi acum lucrăm în recordset_ul rstmatrice şi acolo zona conturilor corespondente începe cu câmpul al treilea, primele două câmpuri fiind ocupate de contul sintetic si de nr. de conturi cu care se debitează). Avem în vedere că numărătoarea în arrays şi în colecţia Fields se face de la 0. In rstmatrice primul câmp care conţine conturi corespondente este al treilea, adică Fields(2). Mai jos folosim indicile i-1 pentru că am început bucla de la 1 în timp ce numărătoarea elementelor într-un vector începe de la zero: grila(i - 1) = rstmatrice.Fields(i + 1) rulaje(i - 1) = 0 Next i Pentru fiecare cont sintetic parcurgem odată tot tabelul Adaos_jurnal: rstAdaos.MoveFirst Do While Not rstAdaos.EOF Verificăm dacă articolul curent din Adaos_jurnal (aici rstAdaos) are legătură cu contul sintetic curent din tabelul Matrice_debit, adică cu crtcont . Pentru aceasta verificăm dacă la cont_debitor conţine crtcont: If rstAdaos!cont_debitor = crtcont Then Constatăm la ce poziţie se găseşte contul_creditor în grilă ca să ştim în ce coloană din zona conturilor corespondente vom stoca valoarea cu care vine tranzacţia curentă din Adaos_jurnal. For i = 0 To 19 If rstAdaos!cont_creditor = grila(i) Then With rstsah_debit .AddNew !cont_sintetic = crtcont !Nr_coduri_cumulate = Nrconturi !nr_crt = rstAdaos!nr_crt !data_inreg = rstAdaos!data_inreg !suma = rstAdaos!valoare sumasintetic = sumasintetic + rstAdaos!valoare Acum valoarea se va depune exact pe poziţia unde s-a depistat în vectorul grila contul corespondent egal cu contul creditor al articolului curent din Adaos_jurnal, numai că trebuie să ţinem seamă de macheta tabelului Sah_debit care este următoarea:

(noi acum lucrăm în recordset_ul rstsah_debit – a se vedea instrucţiunea With aflată în vigoare în această zonă de program).

11

Se vede că aici zona conturilor corespondente începe abia din câmpul al şaselea, adică are un decalaj de 5 câmpuri faţă de vectorul grila care conţine primul cont corespondent chiar în poziţia zero. Prin instrucţiunea următoare, noi punem grila (la figurat, evident) ca să putem scrie tabelul sah_debit, exact în coloana care trebuie! .Fields(i + 5) = rstAdaos!valoare Actualizăm rulajul contului corespondent aflat pe poziţie de cont_creditor: rulaje(i) = rulaje(i) + rstAdaos!valoare .Update End With Să observăm că bucla după i a fost dimensionată pe valoarea maximă adică pe 20 de ciclări ( de la 0 la 19), dar de îndată ce i-am găsit poziţia contului_creditor în vectorul grila, abandonăm ciclările cu Exit For: Exit For End If Next i End If În tabelul Adaos_jurnal se trece la articolul următor: rstAdaos.MoveNext Loop Acum pentru conturile sintetice care nu au avut tranzactii în luna care s-a încheiat, creem un articol cu statistica contului sintetic: specificăm rulajul total si care este rulajul pe conturi corespondente contului sintetic curent (evident toate vor fi zero); If sumasintetic = 0 Then With rstsah_debit .AddNew !cont_sintetic = crtcont !Nr_coduri_cumulate = Nrconturi !nr_crt = 0 !data_inreg = Date !suma = sumasintetic For i = 0 To 19 .Fields(i + 5) = rulaje(i) Next i .Update End With End If În tabelul Matrice_debit se trece la articolul următor, adică vom colecta tranzacţiile pentru următorul cont sintetic: rstmatrice.MoveNext Loop Lista programului rulaj_debit:

Sub NoName() Dim dbscontabil As Database Dim coresp(20) As String Dim rulaje(20) As Currency Dim i, nrconturi As Integer Dim crtcont As String Dim crtcont_sintetic As String Dim rulajtotal As Currency

12

DoCmd.OpenQuery "golesc_rulaj_debit" Set dbscontabil = OpenDatabase("C:\anuIIIfc\Contab97.mdb") Set rstplancont = dbscontabil.OpenRecordset("PlanConturi", dbOpenTable) Set rstmatrice = dbscontabil.OpenRecordset("matrice_debit", dbOpenTable) Set rstrulaj_debit = dbscontabil.OpenRecordset("matrice_rulaj_debit", dbOpenTable) rstplancont.Index = "nr_cont" rstmatrice.MoveFirst Do While Not rstmatrice.EOF crtcont_sintetic = rstmatrice!cod_cont_sintetic nrconturi = rstmatrice!Nr_coduri_cumulate - 1 rulajtotal = 0 For i = 0 To nrconturi coresp(i) = rstmatrice.Fields(i + 2) Next i For i = 0 To nrconturi crtcont = coresp(i) rstplancont.Seek "=", crtcont If Not rstplancont.NoMatch Then rulaje(i) = rstplancont!Rulaj_total_debit rulajtotal = rulajtotal + rulaje(i) Else MsgBox crtcont & " " & coresp(i) MsgBox "Contul " & crtcont & " nu figureaza in Planul de conturi" End If Next i With rstrulaj_debit .AddNew .cod_cont_sintetic = crtcont_sintetic .Nr_coduri_cumulate = nrconturi + 1 .rulaj_total = rulajtotal .data = Date For i = 0 To nrconturi .Fields(i + 2) = rulaje(i) Next i .Update End With rstmatrice.MoveNext Loop rstplancont.Close rstmatrice.Close rstrulaj_debit.Close dbscontabil.Close End Sub

13

Dãm mai jos şi schema logicã pentru programul Sah_debit pentru comparaţie cu pseudocodul prezentat mai sus.

altminteri

altminteri

Instalam grila si vectorul rulaje

Pentru fiecare articol din Matrice debit

Dacã cont_debitor din Adaos_jurnal se refera la contul_sintetic din Matrice debit

Dacã Cont_debitor si-a gasit locul in grila

Pentru fiecare articol din Adaos jurnal

Dacã articolul curent din Matrice_debit nu a avut nici o tranzactie (sumasintetic=0)

In tabelul Sah_debit adãugãm un articol nou cu datele contului sintetic curent, dar cu toate rulajele=0

Start

End

atunci

atunci

atunci

altminteri In tabelul Sah_debit adãugãm un articol nou cu datele din , Adaos_jurnal, dar cu valoare plasat pe pozitia coresp. contului_creditor în grilã. Actualizam si rulajul total.

S-a terminat Adaos jurnal?

S-a terminat Matrice-debit?

Nu

Nu

Da

Da

1

Cursul_III_12

Fisele conturilor desfăşurate pe conturi analitice Macheta fisei pentru un cont sintetic cu două nivele arată în principiu astfel: Unitatea…………………. Fisa Contului Simbol cont Pag (Denumire cont-radacină) Contul Nr crt. Data înreg. Documentul Explicaţii Cont corespondent Debit Credit

Sold iniţial cont radacină …… …… Cont1 de nivel 1 Denumire cont1 analitic de nivel 1 Sold iniţial la nivel 1 …… …… Cont1 de nivel 2 Denumire cont1 analitic de nivel 2 Sold iniţial la nivel 2 …… …… Tranzacţii ale cont1 de nivel 2 …… ….. …… ………….. ……….. ….. …… …… …… ….. …… ………….. ……….. ….. …… …… Total rulaje cont1 nivel 2 …… …… Sold nou la cont1 de nivel 2 …… …… Cont2 de nivel 2 Denumire cont2 analitic de nivel 2 Sold iniţial la nivel 2 …… …… Tranzacţii ale cont2 de nivel 2 …… ….. …… ………….. ……….. ….. …… …… …… ….. …… ………….. ……….. ….. …… …… Total rulaje cont2 nivel 2 …… …… Sold nou la cont2 de nivel 2 …… …… ………………………date despre celelate conturi de nivel 2 ale contului 1 de nivel 1………………… Total rulaje cont1 nivel 1 …… …… Sold nou la cont1 de nivel 1 …… …… Cont2 de nivel 1 Denumire cont1 analitic de nivel 1 Sold iniţial la nivel 1 …… …… Cont1 de nivel 2 Denumire cont1 analitic de nivel 2 Sold iniţial la nivel 2 …… …… Tranzacţii ale cont1 de nivel 2 …… ….. …… ………….. ……….. ….. …… …… …… ….. …… ………….. ……….. ….. …… …… Total rulaje cont1 nivel 2 …… …… Sold nou la cont1 de nivel 2 …… …… Cont2 de nivel 2 Denumire cont2 analitic de nivel 2 Sold iniţial la nivel 2 …… …… Tranzacţii ale cont2 de nivel 2 …… ….. …… ………….. ……….. ….. …… …… …… ….. …… ………….. ……….. ….. …… …… Total rulaje cont2 nivel 2 …… …… Sold nou la cont2 de nivel 2 …… …… …………………… date despre celelate conturi de nivel 2 ale contului 2 de nivel 1 ……………… Total rulaje cont2 nivel 1 …… …… Sold nou la cont2 de nivel 1 …… …… ………………… date despre celelate conturi de nivel 1 ale contului radacina ………………… ……………………………………………………………………………………………………………

Total rulaje cont radacină …… …… Sold nou la cont rădăcină …… …… Fişele cu un singur nivel sunt mai simple şi se deduc uşor din macheta de mai sus, dacă eliminăm conturile de nivel 2 şi ataşăm tranzacţiile direct conturilor de nivel 1. Din analiza machetei de mai sus se deduce uşor că dacă am avea un tabel cu tranzacţiile conturilor analitice cum este tabelul Evolutie_sold_cont, care în plus, să

2

mai conţină un câmp cu radacina1 şi un câmp cu radacina 2 am fi foarte aproape de punctul de elabora fisele conturilor analitice. Poate ne-ar mai trebui să stim pe câte nivele este desfăşurat fiecare cont şi câte cifre are fiecare radăcină (ceea ce ar face necesară prezenţa în interogare şi a tabelului Conturi_radacină a cărui machetă este dată mai jos) şi ne-ar mai trebui informatii despre soldurile precedente şi curente ale conturilor pentru care dorim să întocmim fisa analitică, informatii pe care le putem stoca într-un tabele separat cum este Soldrad1 (prezentat după Conturi-radacina).

Macheta tabelului Conturi-radacina ar putea fi următoarea: În exemplul de mai sus radacina 401 va forma radacina de nivel 2 cu două cifre. Acest tabel se crează la implementare, odată cu PlanConturi, matricile_debit şi credit si cu Functionare_cont_debit, respectiv credit. Se poate deduce din structura tabelului “Conturi_radacina” că se pot defini si rădăcini cu două nivele: un cont rădăcină de trei sau patru cifre la care se poate adăuga o a doua rădăcină formată dintr-o cifră sau două, după care urmeaza încă două cifre pentru identificarea conturilor legate de nivelul doi. De exemplu codul 401 clienti poate fi divizat pe judete sau pe tipuri de produse pe care clientii le cumpără şi vom avea astfel contul 40101, 40102, 40103, s.a.m.d. Individualizarea clienţilor din fiecare categorie de mai sus, se va face atribuindu-le conturi ca 4010101, 4010102, respectiv 4010201, 4010202, s.a.m.d. Evident conturile cu 7 cifre vor fi luate în calcul rulajelor si soldurilor conturilor cu 5 cifre, adică a conturilor 40101, 40102, 40103, s.a.m.d. Conturile care aparţin nivelului al doilea vor avea 7 cifre (5 ale radacinii si două care fac distincţie între codurile aparţinând aceleiaşi rădăcini de 5 cifre). Bineînteles că se pot folosi si rădăcini cu un singur nivel, (de 3 sau 4 cifre) urmat de două, trei sau patru cifre care fac distincţie între codurile aparţinând aceleiaşi rădăcini. În ce priveste tabelul Soldrad1, el are o machetă foarte simplă:

Problema este că noi nu cunoastem soldurile cerute de acest tabel. Este adevărat că avem calculate soldurile pentru conturile analitice de pe ultimul nivel, dar pentru conturile desfăşurate pe mai multe nivele nu stim aceste solduri, aşa că trebuie să facem tot posibilul ca înainte de a concepe interogarea care să asambleze datele pentru fisa coturilor analitice să avem completat tabelul soldrad1, care diferă de la o tranşă la alta. Tabelul Conturi rădăcina a fost creat la inceputul exercitiului financiar. Pentru a elabora conceptia de calcul a fişelor conturilor desfăşurate pe conturi analitice vom porni de la macheta fisei de cont de mai sus şi vom grupa informaţiile pe trei categorii:

solduri precedente ale conturilor radacină (ce vor fi folosite pentru calculul soldului nou), solduri si rulaje pe conturi analitice şi solduri si rulaje centralizate pe conturi rădăcina. În tabelul de mai jos vom specifica demersurile pe care le vom face pe cele trei categorii de informaţii necesare pentru a obţine o fisă de cont sintetic desfăşurat pe conturi analitice, indicând şi ordinea cronologică a acestor demersuri. Abordare descrisă în continuare pentru fişa conturilor sintetice desfăşurate pe conturi analitice se poate aplica şi în cazul conturilor sintetice desfăşurate pe conturi sintetice de nivel II şi presupune ca în planul conturi să figureze şi conturile sintetice desfăşutate pe conturi analitice, dar şi conturile sintetice desfăşurate pe conturi

3

sintetice de nivel II. Evident aceste conturi nu vor fi implicate în tranzacţii, dar în planul de conturi noi păstrăm informaţii (solduri şi rulaje pe ultima lună) la nivel cont, indiferent dacă în tranzacţii este implicat direct sau prin alte conturi. Toate demersurile din tabelul care urmează se petrec în calculator în momentul simulării transei. Atunci se fac toate calculele necesare pentru generarea rapoartelor (în sensul de documente finale de ieşire), urmând ca la selectarea de către utilizator a unei opţiuni de vizualizare sau de tipărire un anumit raport, să nu se ruleze decât raportul (în sensul de program Access de punere în pagină a unor date) care generează documentul solicitat. Solduri precedente pentru rădăcini şi conturi analitice

Solduri şi rulaje pe conturi analitice

Solduri şi rulaje centrali-zate pe conturi desfăşurate

Intrg: Make_soldrad1 Sub: Separ_analitice

Intrg: Rulaje pe conturi analitice Intrg: Rulaje pe conturi intermediare Intrg: Rulaje pe conturi sintetice2 (cu 2 nivele) Intrg: Rulaje pe conturi Analitice1 Intrg: Rulaje pe conturi Sintetice1 (cu un nivel) Sub: Act_date_planconturi Sub: Solduri_noi_pt_fise

Intrg: Fise_cu_1nivel şi intrg fise_cu_2nivele pe care se vor crea rapoartele pentru elaborarea fişelor conturilor sintetice desfăşurate pe conturi analitice Dăm în continuare câteva detalii despre subprogramele şi interogările din tabelul de mai sus, iar pentru a uşura percepţia întregii abordări vom continua cu o schemă logică a prelucrărilor specificate în tabel. Rulajul unui cont în care se folosesc două nivele, presupune calculul rulajelor conturilor apartinând fiecărei rădăcini de nivel doi, adunarea rulajelelor conturilor care aparţin aceleaşi rădăcini de nivel doi, de exemplu a celor care aparţin contului 40101 şi în final, adunarea rulajelor tuturor rădăcinilor de nivel doi apartinând rădăcinii 401, adică rulajele conturilor 40101, 40102, 40103, s.a.m.d. Pentru codurile cu rădăcini pe două nivele, rădăcina de nivel 2 poate avea una sau doua cifre, lucru ce trebuie specificat în coloana Nr_cifre_la_nivelul2. Când simulăm o transă şi facem pregătirile necesare pentru a obţine printre altele şi fisele conturilor analitice, deoarece aceste fişe necesită cunoaşterea soldului precedent, vom face un extras din planul de conturi (cu denumirea contului, soldurile din luna precedentă şi cu spaţiu pentru a stoca acolo si soldul actual al soldurilor analitice) înainte de a pierde rulajele pe luna trecută, adică înainte de rularea programului Transfer_sold_plan care aduce în planul de conturi soldurile obţinute din transa actuală. Acest lucru îl realizăm cu interogarea "Make_soldrad1" care crează tabelul “soldrad1”. Ulterior , în programul “solduri_noi_pentru_fise” acest tabel este multiplicat în alte două exemplare (“soldrad2” şi "soldcont_analitic") ce vor fi folosite împreună cu originalul, la elaborarea rapoartelor “fise_cu_1nivel” si “fise_cu_2nivele”, bazate pe

4

interogări ce le poartă numele. Deocamdată în continuarea acţiunii de pregătire pentru a obţine rapoartele, respectiv fişele analitice, folosim un program ( numit separ_analitice) care preia toate înregistrările din tabelul Evoluţie_sold_cont, derivat din Adaos_jurnal şi verifică dacă primele trei caractere ale contului fiecărei tranzacţii sunt prezente în tabelul “Conturi_radacina” . Dacă da, programul generează numai pentru tranzacţiile aparţinând acestor conturi, un tabel numit "evol_rad_cont".

În acest tabel apar două coloane distincte: una cu contul radacină de nivel 1 si dacă este cazul, a doua cu contul rădăcină de nivel doi precedat de rădăcina de nivel 1, în total 5 cifre). De exemplu pentru contul 4010102 vom avea în prima coloană 401, în a doua 40101 şi în a treia (care in tabel este prima) va apare codul contului, adică 4010102. În acest fel articolele din tabelul "evol_rad_cont" pot fi grupate în rapoarte, pe nivele: radacina1, radacina2 şi în final pe conturi analitice, unde vor fi enumerate tranzacţiile individuale ale contului analitic. S-a pregătit astfel terenul pentru elaborarea fiselor analitice, dar înainte de aceasta trebuie să facem calculul rulajelor şi a soldurilor conturilor rădăcină, care normal, n-ar trebui să aibă tranzacţii direct pe ele ci numai prin intermediul conturilor legate de nivelul 2 (în cazul rădăcinilor cu două nivele) sau a celor legate de nivelul 1 (când rădăcinile sunt concepute pe un singur nivel). Pentru calculul rulajelor pe două nivele şi respectiv pe un nivel vom folosi trei interogări : "Rulaje pe conturi intermediare" care crează tabelul rulaje analitice1 (pe conturi analitice şi pe rădăcini de nivel 2) şi "Rulaje pe conturi sintetice2" care foloseşte tabelul "rulaje analitice1" pentru a crea tabelul "rulaje analitice2" care contine rulajele rădăcinilor de nivel 1. A treia interogare "Rulaje pe conturi sintetice2" crează direct rulajele rădăcinilor cu un singur nivel în tabelul "rulaje sintetice1”. Acum putem folosi aceste rulaje pentru actualizarea în planul de conturi, cu ajutorul programului Act_date_PlanConturi, a datelor privitoare la conturile sintetice care există prin intermediul conturilor analitice. Înainte de actualizare însă, în acelaşi program, vom combina cele trei tabele cu solduri ale conturilor analitice în unul singur (numit rulaje sintetice1). Pentru aceasta vom folosi interogările "combin_analitice2_cu_sintetice1" şi "combin_sintetice1_cu_analitice1"

După actualizarea datelor din articolele din Planul de Conturi ce implică conturi analitice, folosim programul Solduri_noi_pt_fise care stochează noile rulaje din PlanConturi în tabelul “soldrad1” şi apoi îl multiplică pe acesta în alte două exemplare numite “soldrad2” şi "soldcont_analitic". Aceste tabele vor fi folosite de interogările “fise_cu_1nivel” si “fise_cu_2nivele”, care vor fi folosite de rapoartele cu acelaşi nume pentru elaborarea fiselor analitice. Motivul pentru care ne trebuie trei tabele cu solduri vechi şi noi este acela că dacă tabelul este grupat pe trei nivele (de exemplu radacina1 – rad1, radacina2 –rad2 şi cont analitic), nu putem sa-i asociem fiecărui nivel soldul de care are nevoie, decât

5

dacă dispune în interogare de un tabel numai al lui. Această problemă este reluată după prezentarea machetei interogării care generează datele pentru raport, adică pentru fisele cu un nivel şi respectiv cu două nivele. După elaborarea celor trei tabele cu solduri vechi şi noi, putem considera că avem tot ce ne trebuie pentru a obţine fisele analitice. Schema procedurii logice descrisă mai sus este dată pe pagina următoare, dar din operaţiile care figurează în schemă numai cele care sunt haşurate cu gri se referă strict la pregătirea datelor pentru fişele conturilor analitice. Celelate operaţii nu sunt necesare numai pentru fisa contului analitic; ele s-ar fi derulat oricum pentru că ţin de actualizarea soldurilor şi rulajelor pentru transa care tocmai s-a încheiat, dar sunt trecute în schemă pentru a marca ordinea corectă a derulării operaţiilor.

6

Subroutine Transfer_Sold_Plan Intrg: make table Planconturi Make-soldrad1 Soldrad1 Subroutine Sold_conturi Transfer_Sold_Plan Planconturi Subroutine Separ_analitice Macro Intrg: delete Evol_rad_cont Golesc_evol_rad_cont Macro Intrg: append Evolutie_sold_cont Split_simbol_conturi Evol_rad_cont Subroutine Conturi_radacina Separ_analitice Evol_rad_cont Evol_rad_cont Intrg: select Rulaje pe conturi analitice Conturi_radacina Intrg:make table Rulaje pe conturi intermediare Rulaje analitice1 Intrg: make table. Rulaje analitice1 Rulaje pe conturi sintetice2 Rulaje analitice2 Evol_rad_cont Intrg: select Rulaje pe conturi analitice1

Conturi_radacina. Intrg: make table Rulaje pe conturi sintetice1 Rulaje sintetice1

1

7

1 Subroutine Act_date_planconturi Intrg: append

Rulaje analitice2 Combin_analitice2_cu_sintetice1 Rulaje sintetice1 Intrg: append

Rulaje analitice1 Combin_ sintetice1_cu_ analitice1 Rulaje sintetice1

Subroutine Rulaje sintetice1 Act_date_planconturi Planconturi

Subroutine Solduri_noi_pt_fise Subroutine Planconturi Solduri_noi_pt_fise Soldrad1 Soldrad1 Docmd.CopyObject Soldrad2 Soldrad1 Docmd.CopyObject Soldcont_analitic Câteva comentarii despre interogările şi subprogramele prezentate mai sus:

- Interogarea Make_soldrad1 de tip Make table creaza tabelul Soldrad1 cu câmpurile cod_cont, den_cont, Sold_debit, Sold_credit, sold_debit_nou, sold_credit_nou, toate aduse din PlanConturi, mai puţin sold_debit_nou şi sold_credit_nou care sunt expresii iniţializate cu 0 şi vor fi completate mai târziu de subrutina Solduri_noi_pt_fise.

- Interogarea “Golesc_evol_rad_cont” este o interogare de tip Delete. - Interogarea “Split_simbol_conturi” de tip Append aduce conţinutul tabelului

evolutie_sold_cont şi încă două câmpuri noi (rad1 şi rad2 iniţializate cu blanc şi instalate imediat după câmpul cont), în tabelul evol_rad_cont. Tabelul este ordonat după cont.

- Subrutina Separ_analitice lansează interogarea “Golesc_evol_rad_cont” şi “Split_simbol_conturi” şi apoi şterge articolele care se refera la conturi ce nu au conturi analitice se sterg. Articolele ramase se completează cu valori în câmpurile rad1 si dacă este cazul si rad2. Acesta poate conţine 4, 5 sau 6 caractere după cum este specificat în tabelul "conturi_radacina". Practic programul funcţionează astfel: după lansarea în execuţie a celor două interogări şi după atribuirea de valori celor două recordset-uri (reprezentând tabelele evol_rad_cont, şi conturi_radacina) programul indexează tabelul (recordset-ul) conturi_radacina după chieia primară (câmpul radacina) şi apoi începe explorarea secvenţială a tabelului evol_rad_cont. Pentru fiecare articol, extrage o rădăcină (constând din 3 caractere) din cont şi dacă nu o găseşte declarată în conturi_radacina, lungeşte rădăcina la 4 caractere şi mai încearcă odată în conturi_radacina. Dacă nici de această dată nu gaseşte

8

rădăcina astfel obţinută ca fiind printre cele prevăzute în conturi_radacina sterge articolul respectiv din evol_rad_cont. Dacă articolul curent din evol_rad_cont a rămas neşters, atunci variabila radacina este depusă în câmpul rad1 şi dacă în tabelul conturi_radacina, câmpul Nr_nivele_sub_cont este egal cu 2, atunci calculează şi rad2. Pentru aceasta se valua din cont (din articolul curent apartinând tabelului evol_rad_cont), un string de lungime egală cu cea a valorii din câmpul rad1 + unul sau două caractere (depinde ce scrie în câmpul nr_cifre_la_nivel2). Programul se opreşte după ce a parcurs tot tabelul evol_rad_cont care în acest moment deţine foarte clar reţeaua de conturi analitice şi sintetice precum şi tranzacţiile efectuate pe nivelele cele mai de jos, adică pe nivelul format baza rădăcinilor de nivel 2. Calculul rulajelor pentru conturile sintetice desfăşurate pe două nivele de conturi analitice începe cu interogarea “Rulaje pe conturi analitice”.

- Interogarea “Rulaje pe conturi analitice” de tip select însumează valorile tranzacţiilor efectuate pe conturile situate pe radacini de nivelul 2 şi se bazează pe corespondenţa (relaţia) dintre câmpul radacina din tabelul Conturi_radacină şi câmpul rad1 din tabelul evol_rad_cont. Din articolele care în tabelul Conturi_radacina au în câmpul nr_nivele_sub_cont valoarea 2, sunt selectate câmpurile: radacina din Conturi_radacină , rad2, cont, Sum(Valoare_cont_debit) sub numele de SumOfValoare_cont_debit şi Sum(Valoare_cont_credit) sub numele SumOfValoare_cont_credit din tabelul evol_rad_cont. Gruparea articolelor selectate se face după radacina, rad2, cont şi nr_nivele_sub_cont.

- Interogarea “Rulaje pe conturi intermediare” de tip Make Table, se bazează pe interogarea “Rulaje pe conturi analitice”, dar merge mai departe însumând sumele produse de această interogare pe rădăcini de nivel 1. Tabelul rezultat se numeşte Rulaje analitice1.

- Interogarea “Rulaje pe conturi sintetice2” de tip Make Table, însumează sumele

conturilor rădăcină de nivel 2, produse de interogarea “Rulaje pe conturi intermediare” , pe conturi rădăcină de nivel 1. Practic produce tabelul Rulaje analitice2, care reprezintă rulajele conturilor sintetice desfăşurate pe două nivele de conturi analitice.

Pentru calculul rulajelor conturilor sintetice desfăşurate pe un singur nivel se foloseşte interogarea “Rulaje pe conturi analitice”. - interogarea “Rulaje pe conturi analitice”de tip select însumează valorile

tranzacţiilor efectuate pe conturile situate pe radacini de nivelul 1 şi se bazează pe corespondenţa (relaţia) dintre câmpul radacina din tabelul Conturi_radacină şi câmpul rad1 din tabelul evol_rad_cont. Din articolele care în tabelul Conturi_radacina au în câmpul nr_nivele_sub_cont valoarea 1, sunt selectate câmpurile: radacina din Conturi_radacină , cont, Sum(Valoare_cont_debit) sub numele de SumOfValoare_cont_debit şi Sum(Valoare_cont_credit) sub numele

9

SumOfValoare_cont_credit din tabelul evol_rad_cont. Gruparea articolelor selectate se face după radacina, cont şi nr_nivele_sub_cont.

- Interogarea “Rulaje pe conturi sintetice1” de tip Make Table, produce tabelul

“Rulaje sintetice 1” care conţine rulajele conturilor sintetice desfăşurate pe un singur nivel de conturi analitice . Interogarea se bazează pe interogarea “Rulaje pe conturi analitice1”, dar merge mai departe însumând sumele produse de această interogare pe rădăcini de nivel 1. Gruparea articolelor se face pe radacini.

Cele trei tabele cu rulaje (Rulaje analitice1, Rulaje analitice2 şi Rulaje sintetice1) sunt concatenate cu interogările Combin_analitice2_cu_sintetice1 şi Combin_ sintetice1_cu_ analitice1, într-un singur tabel cu rulaje numit Rulaje sintetice1. Practic tabelele Rulaje Analitice2 şi Rulaje Analitice1 sunt adăugate la sfârşitul tabelului Rulaje Sintetice1. Acum prin intermediul subrutinei Act_date_Planconturi, rulajele conturilor analitice din tabelul Rualeje sintetice 1 vor fi depuse în tabelul Planconturi la fie la conturile sintetice desfăşurate pe conturi analitice de nivel 1, fie la conturile analitice de nivel 1 care la rândul lor sunt desfăşurate pe conturi analitice de nivel 2. Conturile analitice de nivel 2, fiind prezente explicit în tranzacţii, au rulajele completate încă de la rulare asubrutinei Transfer_Sold_Plan. Cu subrutina Act_date_Planconturi pot fi actualizate şi rulajele conturilor sintetice care sunt desfăşurate pe nivelul 2 de conturi sintetice. Deoarece Planul de conturi dispune acum de toate rulajele si soldurile, inclusiv cele aduse de subrutina Act_date_Planconturi, putem completa tabelul Soldrad1, care la generare a primit două coloane goale: sold_debit_nou şi sold_credit_nou. Urmează multiplicarea tabelului Soldrad1 în încă două exemplare: soldrad2 şi sold_cont_analitic. În fine dispunem de cele trei tabele de care avem nevoie în înterogarea fise_cu_2_nivele care asamblează datele pentru fisa conturilor sintetice desfărate pe conturi analitice: Conturi_radacina, Evol_rad_cont şi Soldrad1, care din motivele explicate mai sus, mai trebuie triplat de Soldrad1 şi Soldcont_analitic.

Interogarea Fisa_2nivele_1cod pe care se va construi raportul cu acelaşi nume, se bazează pe interogarea Fisa_cu_doua_nivele a cărei machetă este dată mai sus. Aici se pun condiţiile cu privire la contul a cărui fişă se doreşte, precum şi condiţiile asupra numărului de nivele ale contului analitic. Ca urmare, în interogarea Fisa_2nivele_1cod, a cărei machetă se poate vedea pe pagina următoare, se pune numai problema asamblării datelor provenite din cele 4 tabele care concură la elaborarea raportului Fisa_2nivele_1cod. În macheta interogãrii Fise_2nivele_1cod de pe pagina urmãtoare se observã cã

10

în tabelul Evol_rad_cont de cont Soldcont_analitic se

leagã de sold, tabelul soldrad1 de rad1 ºi tabelul soldrad2 de rad2. În interogarea fise_cu_1_nivel a cărei macheta este dată mai jos, tabelul soldrad2 nu există deoarece el este folosit doar pentru conturi analitice de nivel 2, ceea ce face ca în cazul fiselor cu un singur nivel el să nu fie necesar.

11

Pentru conturi analitice cu două nivele (fără a nominaliza un cod, deci pentru toate codurile analitice) se va folosi interogarea fise_cu_2_nivele, care se plasează direct pe cele 8 tabele de care are nevoie şi care se văd în imaginea de mai jos.

Pentru fişe individuale cu un nivel se foloseşte interogarea fisa_cu_un_nivel, asemănătoare cu fisa_cu_două_nivele, doar că ea nu conţine cîmpul rad2, iar la nr_nivele_sub_cont pune condiţia să fie egal cu 1. Pe această interogare se grefează interogarea fisa_1nivel_1cod, care seamănă cu fişa_2nivele_1cod, doar că nu mai conţine câmpul rad2. Pentru toate fişele cu un nivel se foloseşte interogarea fise_cu_1nivel, asemănătoare cu fise_cu_2_nivele, doar că nu mai conţine cîmpul rad2, iar condiţia pentru cîmpul nr_nivele_sub_cont este să fie 1. Raportul care va genera fisa conturi analitice va fi creat cu wizardul si va fi structurat pe două grupe: rad1 si rad2. Informatiile despre contul sintetic nu vor dispune în raport de header şi footer, dar pot fi plasate manual în mod design în antetul raportului şi respectiv în subsolul raportului. Dăm mai jos macheta raportului pentru două nivele.

12

Raportul care va genera fisa conturi analitice va fi creat cu wizardul si va fi structurat

13

pe două grupe: rad1 si rad2. Informatiile despre contul sintetic nu vor dispune în raport de header şi footer, dar pot fi plasate manual în mod design în antetul raportului şi respectiv în subsolul raportului. Dăm mai jos macheta raportului pentru două nivele. Partea din stânga a fost divizată în două imagini, iar partea din dreapta, nemaifiind necesar titlul, a încăput într-o singură imagine. Din ultima imagine se poate vedea cum la sumele de rulaje la nivelul 2 s-au luat sume din tabelul soldcont_analitic, la nivelul1 s-au luat sume din soldrad2, iar la nivel cont sintetic s-au luat sumele din tabelul soldrad1, ceea ce a fost posibil numai datorită modului cum au fost legate aceste tabele (în interogare) de rad2, rad1 sau de cont. Explicaţia constă în faptul că orice rând din tabelul Evol_rad_cont dispune de trei coloane fiecare cu valori diferite: una pentru cont, una pentru rad1 şi alta pentru rad2. Aceste valori provin din cele trei tabele gemene, dar fiecare este luată din articole diferite. Pentru un articol din tabelul evol_rad_cont, respectiv pentru un rând din fisa analitică, numai una din aceste valori este relevantă. Astfel pentru un sold de cont de nivel 2, va fi relevantă valorea asociată acelui cont, luată din Soldrad2, pentru un sold de cont de nivel 1 va fi relevantă valoarea asociată acelui cont dar luată din tabelul Soldrad1, iar pentru un cont sintetic va fi relevantă valoarea de pe coloana provenită din tabelul Soldcont_analitic (pentru că el este legat în interogare de câmpul cont). Dacă nu foloseam aceste trei tabele gemene, ar fi însemnat ca un tabel (de ex. Solrad1) să aibă legături din acelaşi câmp cu trei câmpuri din tabelul Evol_rad_cont, ceea ce ar fi fost imposibil.

1

Cursul_III_13 TEHNICA ELABORĂRII BILANÞULUI ANUAL Machetele bilanþului ºi a contului de profit ºi pierderi (incomplete, dar suficient de dezvoltate pentru a înþelege soluþia ce o vom propune în continuare), sunt date mai jos: Judeþul_________ Forma de proprietate_________ Unitatea _________ Activitatea preponderentã Adresa _____________ (Denumire grupã CAEN) Telefonul ___________ _________________________ Nr. din registrul Cod grupã CAEN __________ comerþului ________ Codul fiscal _______________ BILANÞ Încheiat la 31.XII.2001 Mii lei

ACTIV Nr. rd.

Sold la: Începutul anului

Sfârºitul anului

A B 1 2

ACTIVE IMOBILIZATE

IMOBILIZÃRI NECORPORALE Cheltuieli de constituire ºi de cercetare-dezvoltare (ct. 201+203-2081-2083-290)

01 - 1.000

Alte imobilizãri (ct. 205+207-2805-2807-2808-290)

02 - 2.000

03 TOTAL (rd. 01 la 03) 04 - 3.000 IMOBILIZÃRI CORPORALE Terenuri (ct. 211-2810-291)

05

TOTAL (rd. 05 la 10) 11 IMOBILIZÃRI FINANCIARE – TOTAL (CT. 261+262+263+267-269*-269*

12

)

I. ACTIVE IMOBILIZATE - TOTAL (rd. 04+11+12)

13

STOCURI

14

*) Conturi de repartizat dupã natura elementelor respective ADMINISTRATOR, ÎNTOCMIT,

CONTUL DE PROFIT ªI PIERDERE

Încheiat la 31.XII.2001 (se completeazã cumulat de la începutul anului)

10

2

- mii lei -

Denumirea indicatorilor Nr. rd.

Exerciþiu financiar Precedent Încheiat

A B 1 2

VENITURI DIN

EXPLOATARE

Venituri din vânzarea mãrfurilor (ct. 707)

01 - -

Producþia vândutã (ct. 701+702+703+704+705+706+708)

02 26.000 37.450

Cifra de afaceri (rd. 01+02) 03 26.000 37.450 Venituri din producþia stocatã (ct. 711)

Solduri creditoare

04 11.000 5.000

Solduri debitoare

05 - -

I. VENITURI DIN EXPLOATARE (rd. 03+04+05+06+08 la 10)

11

Cheltuiel

i pt.

exploatar

Cheltuieli …

12

ADMINISTRATOR, ÎNTOCMIT, Din machetele de mai sus, se vede cã datele pentru aceste documente sunt disponibile în tabelul PlanConturi, actualizat cu ultima tranºã din anul care s-a încheiat. Totuºi dat fiind conþinutul complex al acestor documente ele nu pot fi obþinute cu o interogare privitoare la PlanConturi, ci va trebui sã concepem o procedurã logicã mai complexã. În aceastã procedurã, piesa cea mai importantã este un tabel numit Structura_bilant ce va conþine câte un articol pentru fiecare rând din document. Pentru actualizarea tabelului Structura_bilant acestuia i se va asocia un formular. Macheta tabelului Structura_bilant este urmãtoarea: Nr_rand

Denumire categorie

Continut

Tip sold

Cont1 Cont2

… Nr conturi pe rand

1

Imobilizari necorp

sold 1

201 203 -2081

5

Unde: - Denumire categorie se refera la categorii de activ sau de pasiv (de ex. Imobilizari necorporale); - Continut se referã la conþinutul câmpurilor cont1, cont2, s.a.m.d. pânã la cont 20, care reprezintã locul de unde luãm informaþiile pentru a fi prelucrate: acesta poate fi un cont cu semn, sau un rând din bilanþ ( a se vedea indicaþiile cu privire la conturi din macheta bilantului). De ex. pentru linia I. ACTIVE IMOBILIZATE _ TOTAL se face referire la rândurile 1-3 a cãror conþinut se adunã pentru a se obþine totalul;

20

3

- Tip sold poate lua valoarea 1 dacã soldul este pe debit ºi 2 dacã este pe credit. Din macheta de mai sus se vede cã în bilanþ, din tabelul Structura_bilanþ, nu va participa decât coloanele Denumire categorie ºi Nr_rand. Restul informaþiilor sunt folosite pentru a calcula soldurile ce vor fi stocate pe fiecare rând, din coloanele Precedent ºi Încheiat. Pentru calculul soldurilor se disting douã situaþii: solduri ale conturilor prevãzute în planul de conturi ºi solduri ale unor subclase de conturi (de ex .20), care nu sunt disponibile direct în planul de conturi, ci trebuie folosit un program special care sã selecteze din planul de conturi conturile care apartin unei subclase si sã le adune pentru a obþine soldul subclasei. Iniþial soldurile subclaselor se depoziteazã într-un tabel numit Solduri_subclase, având macheta de mai jos: Subclasa

Sold_debit_initial

Sold_debit_initial

Sold_debit_inicheiat

Sold_credit_incheiat

Dupã calculul soldurilor subclaselor, se poate trece la calculul soldurilor pentru coloanele Precedent ºi Încheiat. Acestea vor fi stocate în tabelul Solduri_bilant. Acest tabel conþine câmpurile: Nr_rand, Sold_initial ºi Sold_inchiat. Pentru completarea acestui tabel se aduc solduri din Planul de conturi (în cazul conturilor) sau din tabelul Solduri_subclase (în cazul subclaseor), dupã cum în tabelul structura_bilant este specificat un cont sau o subclasã. Dacãin tabelul Structura_bilant, la continut este specificat rand, atunci se cauta în tabelul Solduri_bilant, la rândul specificat înacelasi tabel.. Înainte de a asambla nr-rand, denumire categorie, solduri_subclase, solduri_bilant ºi solduri de pe alte rânduri care participã la calculul totalurilor, mai trebuie actualizatã în tabelul Societatea, data la care s-a fãcut validarea ultimei transe pe anul încheiat. Aceasta se ia din tabelul Solduri ºi va apare sub titlul bilantului. Dupã aceea se va rula interogarea Asamblez_tabel_bilant care ia date din tabelele Structura_bilant , Solduri_bilant ºi Societatea. Ultimele douã tabele sunt legate direct de tabelul Structura_bilant prin câmpul Nr_rand. Interogarea va produce un tabel cu aspect foarte apropiat de cel al formatului cerut pentru bilant. Pe acest tabel se poate rula raportul Bilantul, care este folosit pentru a vizualiza si pentru a tipãri bilantul. Dacã este cazul, operaþiunile de mai sus, pot fi precedate de actualizarea structurii bilantului ºi a datelor din tabelul Societatea (altele decât data validãrii transei) care sunt folosite pentru antetul bilantului. Schema procedurii logice utilizate pentru a elabora bilantul este urmãtoarea:

4

Structura bilant Formular actualizare Societatea Formular actualizare Subprg Planconturi Actualiz_sold_subclase Solduri_subclase

Planconturi Subprg Solduri_subclase Actualiz_sold_bilant

Solduri_bilant Structura_bilant Subprg Solduri Actualiz_datei_ultimei_transe

Societatea

Structura_bilant Intrg: make-table Solduri_bilant Asamblez_tabel_bilant Tabelul_bilant Societatea Raport Tabelul_bilant Bilantul Bilantul Lansarea procedurii logice de mai sus se face din submeniul Prelucrãri, prin opþiunea Pregatire bilant, care oferã un submeniu cu opþiunile Actualizare structura bilant, Actualizare antet bilant ºi Elaborare bilant. Ultima opþiune lanseazã automat, unul dupã altul programele Actualiz_sold_subclase, Actualiz_sold_bilant, Actualiz_datei_ultimei_transe ºi interogarea Asamblez_tabel_bilant. Vizualizarea sau tipãrirea bilantului se poate face din submeniul Rapoarte/Bilant cu opþiunile Vizualizare ºi Tipãrire.

5

Structura bilant

nr_rand denumire continut tip_sold cont1 cont2 cont3 cont4 cont5 cont6 cont7 cont8 cont9 cont10 cont11 cont12 cont13 cont14 cont15 cont16 cont17 cont18 cont19 cont20 cont21 cont22 cont23 cont24 cont25 Nr_contur 1 IMOBILIZ

CONT 1 201 203 -2801 -2803 -290 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 2 Alte

CONT 1 205 207 208 -2805 -2807 -2808 -290 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 3 Imobilizari

CONT 1 230 -293 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 4 TOTAL

RAND 1 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3

5 IMOBILIZ

CONT 1 211 -2810 -291 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 6 Cladiri

CONT 1 2121 -2811 -291 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 7 Constructii

CONT 1 2122 -2812 -291 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 8 Masini si

CONT 1 2123 2125 -2813 -2815 -291 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 9 Alte

CONT 1 2124 2126 2127 2128 -2814 -2816 -2817 -2818 -291 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 10 Imobilizari

CONT 1 231 -293 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 11 TOTAL

RAND 1 5 6 7 8 9 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6

12 IMOBILIZ

CONT 1 261 -269 -296 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 13 Alte titluri

CONT 1 262 263 -269 -296 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 14 Creante

CONT 1 267 -296 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 15 TOTAL

RAND 1 12 13 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3

16 ACTIVE

RAND 1 4 11 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 17 STOCURI

CONT 1 300 301 308 321 323 -322 328 351 352 354 356 357 358 -390 -391 -392 -395 0 0 0 0 0 0 0 0 17 18 Productia

CONT 1 331 332 -393 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 19 Produse

CONT 1 341 345 346 348 -394 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 20 Animale

CONT 1 361 368 396 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 21 Marfuri

CONT 1 371 378 -397 381 388 -398 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 22 TOTAL

RAND 1 17 18 19 20 21 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5

23 ALTE

CONT 1 409 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 24 Clienti si

CONT 1 411 413 416 418 -491 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 25 Alte

CONT 1 425 4282 4382 441 4424 4428 445 446 447 4482 4484 451 4581 461 481 482 -495 -496 0 0 0 0 0 0 0 18 26 Decontari

CONT 1 456 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 27 Titluri de

CONT 1 502 503 505 506 508 -590 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6

6

28 Conturi la

CONT 1 511 512 5187 531 532 541 542 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 29 TOTAL

RAND 1 23 24 25 26 27 28 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6

30 ACTIVE

RAND 1 22 23 24 25 26 27 28 29 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 31 CONTURI

CONT 1 471 473 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 32 Diferente

CONT 1 476 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 33 CONTURI

RAND 1 31 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 34 PRIME

CONT 1 169 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 35 TOTAL

RAND 1 16 30 33 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 36 *****

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 40 Capital

CONT 2 101 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 41 din

CONT 2 1012 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 42 Contul

CONT 2 108 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 43 (108) sold

CONT 1 108 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

44 Prime

CONT 2 104 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 45 Diferente

CONT 2 105 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 46 Rezerve

CONT 2 106 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

47 Rezultat

CONT 2 107 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 48 ( 107 )

CONT 1 107 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 49 Rezultatul

CONT 2 121 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 50 Pierdere

CONT 1 121 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

51 Repartizar

CONT 2 129 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 52 Fonduri

CONT 2 111 112 118 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 53 Repartizari

CONT 2 119 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 54 Subventii

CONT 2 131 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 55 Provizioan

CONT 2 141 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 56 CAPITAL

RAND 2 40 42 43 44 45 46 47 -48 49 -50 -51 52 -53 54 55 0 0 0 0 0 0 0 0 0 0 15 57 Provizioan

CONT 2 1511 1512 1518 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 58 Provizioan

CONT 2 1513 1514 1518 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 59 PROVIZIO

RAND 2 57 58 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 60 Imprumutu

CONT 2 161 162 166 167 168 512 5186 519 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8

7

61 Furnizori

CONT 2 401 403 404 405 408 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 62 Clienti

CONT 2 419 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 63 Alte datorii

CONT 2 421 423 424 426 427 4281 431 437 4381 441 4423 4428 444 446 447 4481 4483 451 455 457 4582 462 509 481 482 25 64 DATORII

RAND 2 60 61 62 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 65 CONTURI

CONT 2 472 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 66 Diferente

CONT 2 477 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 67 CONTURI

RAND 2 65 66 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 68 TOTAL

RAND 2 56 59 64 67 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 Structura profit

nr_rand denumire continut tip_sold cont1 cont2 cont3 cont4 cont5 cont6 cont7 cont8 cont9 cont10 cont11 cont12 cont1

cont14 cont15 cont16 cont17 cont18 cont19 cont20 cont21 cont22 c

c

c

N

1 Vanzari de marfuri (707) CONT 2 707 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 2 Productie vanduta (701+702+703+704+705+706+708) CONT 2 701 702 703 704 705 706 708 0 0 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 0 7 3 Cifra de afaceri (rd.1+2) RAND 2 1 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 4 Productia stocata (711) Sold creditor CONT 2 711 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 5 (711)Sold debitor CONT 1 711 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 6 Productia imobilizata (721+722) CONT 2 721 722 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 2 7 Productia exercitiului (rd.2+4-5+6) RAND 1 2 4 -5 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 8 Subventii din exploatare (741) CONT 2 741 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 9 Alte venituri din exploatare (754+758) CONT 2 754 758 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 2

10 Venituri din provizioane privind exploatarea (781) CONT 2 781 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 11 VENITURI DIN EXPLOATARE TOTAL (rd.3+4+5+6+8la10) RAND 2 3 4 5 6 8 9 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 12 Costul marfurilor vandute (607) CONT 1 607 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 13 Materii prime si materiale consumabile (600+601) CONT 1 600 601 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 2 14 Combustibil, energie si apa (605) CONT 1 605 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 15 Alte cheltuieli materiale (602+603+604+606+608) CONT 1 602 603 604 606 608 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 0 5 16 Cheltuieli materiale total (rd.13la15) RAND 1 13 14 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 17 Lucrari si servicii executate de terti

CONT 1 611 612 613 614 621 622 623 624 625 626 627 628 12 0 0 0 0 0 0 0 0 0 0 0 0 1

18 Impozite ,taxe si varsaminte asimilate (631+635) CONT 2 631 635 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 2

8

19 Salarii personal (641) CONT 1 641 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 20 Asigurari si protectie sociala (645) CONT 1 645 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 21 Cheltuieli cu personalul total (rd.19+20) RAND 1 19 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 22 Alte cheltuieli de exploatare (654+658) CONT 1 654 658 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 2 23 Amortizari si provizioane (681) CONT 1 681 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 24 CHELTUIELI PENTRU EXPLOATARE TOTAL (rd.12+16+17+18+21+22+23) RAND 1 12 16 17 18 21 22 23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 25 REZULTATUL DIN EXPLOATARE PROFIT (rd.11-24) RAND 2 11 -24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 26 PIERDERE (rd.24-11) RAND 1 24 -11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 27 Titluri si creante imobilizate (761+762+763) CONT 2 761 762 763 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 3 28 Titluri de plasament (764) CONT 2 764 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 29 Diferente de curs valutar (765) CONT 2 765 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 30 Alte venituri financiare (766+767+768) CONT 2 766 767 768 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 3 31 Provizioane ( 786) CONT 2 786 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 32 VENITURI FINANCIARE TOTAL (rd.27la31) RAND 2 27 28 29 30 31 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 33 Creante imobilizate (663) CONT 1 663 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 34 Titluri de plasament (664) CONT 1 664 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 35 Diferente de curs valutar (665) CONT 1 665 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 36 Alte cheltuieli financiare (666+667+668) CONT 1 666 667 668 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 3 37 Amortizari si provizioane (686) CONT 1 686 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 38 CHELTUIELI FINANCIARE TOTAL (rd.33la37) RAND 1 33 34 35 36 37 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 39 REZULTZTUL FINANCIAR PROFIT (rd.32-38) RAND 2 32 -38 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 40 PIERDERE (rd.38-32) RAND 1 38 -32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 41 REZULTTUL CURENT AL EXERCITIULUI PROFIT (rd.11+32-24-38) RAND 1 11 32 -24 -38 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 42 PIERDERE (rd.24+38-11-32) RAND 2 24 38 -11 -32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 43 Operatii de gestiune (771) CONT 2 771 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 44 Operatii de capital (772) CONT 2 772 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 45 Provizioane (787) CONT 2 787 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 46 VENITURI EXCEPTIONALE TOTAL (rd.43la45) RAND 2 43 44 45 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 47 Operatii de gestiune (671) CONT 1 671 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 48 Operatii de capital (672) CONT 1 672 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1

9

49 Amortizari si provizioane (687) CONT 1 687 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 50 CHELTUIELI EXCEPTIONALE TOTAL (rd.47la49) RAND 1 47 48 49 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 51 REZULTATUL EXCEPTIONAL AL EXERCITIULUI PROFIT (rd.46-50) RAND 2 46 -50 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 52 PIERDERE (rd.50-46) RAND 1 50 -46 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 53 IMPOZIT PE PROFIT (691) CONT 1 691 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 54 REZULTATUL EXERCITIULUI PROFIT (rd.11+32+46-24-38-50-53) RAND 2 11 32 46 -24 -38 -50 -53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 55 PIERDERE (rd.24+38+50+53-11-32-46) RAND 1 24 38 50 53 -11 -32 -46 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7

1

Cursul_III_14

Administrarea sistemului de securitate a unei baze de date

I. Overview of Access security

There are different strategies for controlling the level of access to your Microsoft Access database and its objects. These strategies are briefly described below and are roughly arranged from least to most secure.

Encryption/decryption The simplest method of protection is to encrypt the database. Encrypting a database compacts the database file and makes it indecipherable by a utility program or word processor. Encrypting an unsecured database has no effect because anybody can open the database and gain full access to all objects in the database. Encryption is particularly useful when you transmit a database electronically, or when your store it on floppy disk, tape, or compact disc.

Before you can encrypt or decrypt a Microsoft Access database, you must be either the owner of the database or, if the database is secured, a member of the Admins group of the workgroup information file that contains the accounts used to secure the database. You must also be able to open the database in exclusive mode, which means you must have Open/Run and Open Exclusive permissions.

Decrypting a database reverses the encryption.

Show or hide objects in the Database window Another method of protecting the objects in your database from casual users is to hide the objects in the Database window. This method of protection is the least secure because it is relatively simple to show any hidden objects.

Using startup options You use the startup options to specify settings such as a startup form, which opens automatically when your database opens, and your database application title and icon. You can also hide the Database window, and set your own switchboard form. In a new database, the startup properties do not exist until a user makes a change to the default settings in the Startup dialog box.

With a password Another simple method of providing security is to set a password for opening the Microsoft Access database. Once a password is set, a dialog box that requests the password will be displayed whenever the database is opened. Only users who type the correct password will be allowed to open the database. This method is secure (Microsoft Access encrypts the password so that it can't be accessed by reading the database file directly), but it only applies to opening a database. Once a database is open, all its objects are available to the user (unless other types of security have already been defined, as described later in this topic). For a database that is shared

2

among a small group of users or on a single computer, setting a password is often all that is required.

Do not use a database password if you will be replicating a database. Replicated databases can't be synchronized if database passwords are defined.

With user-level security The most flexible and extensive method of securing a database is called user-level security. With user-level security, you can establish different levels of access to sensitive data and objects in your database. To use a database secured with user-level security, users type a password when they start Microsoft Access. Access reads a workgroup information file, where each user is identified by a unique identification code. The level of access and the objects that a user has access to are established based on this identification code and password.

Although setting up user-level security on most databases can be a daunting task, the User-Level Security Wizard makes it easy to quickly secure your Access database in a one-step process. Furthermore, by implementing common security schemes, the User-Level Security Wizard minimizes and may even eliminate the need to use the Security command from the Tools menu.

After running the User-Level Security Wizard, you can create your own groups of users and assign or remove permissions for various users or group of users for a database and its existing tables, queries, forms, reports, and macros. You can also set the default permissions that Microsoft Access assigns for any new tables, queries, forms, reports, and macros that are created in a database. Permissions are granted to groups and users to regulate how they are allowed to work with each table, query, form, report, and macro in a database.

Preventing users from replicating a database, setting passwords, or setting startup options

In a multiuser environment, there are many situations where you might need to protect your database. You might want to prevent users from replicating a database. Replicating a database allows a user to make a copy of a shared database and also adds fields and makes other changes to the current database. You might want to prevent users from setting a database password, because if they do, no other user will be able open the database without providing that password. You might also want to keep users from changing startup properties that specify features such as custom menus, custom toolbars, or the startup form.

If a shared database doesn't have user-level security defined, you can't prevent a user from making any of these changes. When user-level security is defined, a user or group must have Administer permission for the database to replicate a database, set a database password, or change its startup properties. Only members of the Admins group of the current workgroup have Administer permission.

If a user or group currently has Administer permission for a database, removing that permission will prevent the user or group from making any of these changes. If you need to allow a user or group to perform any of these tasks, you can assign the

3

Administer permission to that user or group. You can't control access to these three tasks independently.

Securing Microsoft Visual Basic for Applications (VBA) Code

There are two different ways you can protect Microsoft Visual Basic for Applications (VBA) code in standard modules and class modules (such as code behind forms and reports).

You can secure your code with a password, which you enter once per session. The password prevents unauthorized users from editing, cutting, pasting, copying, exporting, and deleting VBA code.

When your VBA code is error-free and working correctly, you can remove it from your database by saving it as an MDE file. This protects the intellectual property of your code, and prevents modifications to the design of forms, reports, and modules in your database.

Securing data access pages Data access pages are HTML pages that contain references to the data in a Microsoft Access file. However, the data access pages aren't actually stored in the Access file; they are stored as HTML files either in the local file system, in a folder on a network share, or on an HTTP server. For this reason, Microsoft Access has no control over the security of data access page files. To protect the data access page, you must secure its link and HTML file by using the file system security of the computer where you have stored these files. To protect the data accessed by the page, you must either secure the database that the page is connected to or configure Microsoft Internet Explorer security settings to prevent unauthorized access.

II. About user-level security

Microsoft Access user-level security is very similar to the security mechanisms seen on server or mainframe systems. By using passwords and permissions, you can allow or restrict the access of individuals, or groups of individuals, to the objects in your database. Security accounts define the users and groups of users allowed access to the objects in your database. This information, known as a workgroup, is stored in a workgroup information file.

About user-level security The most flexible and extensive method of securing a database is called user-level security. The two main reasons to use user-level security are to:

Prevent users from inadvertently breaking an application by changing tables, queries, forms, reports, and macros on which the application depends.

Protect sensitive data in the database.

Under user-level security, users type a password when they start Microsoft Access. Access then goes out and reads a workgroup information file, where each user is identified by a unique identification code. Within the workgroup information file,

4

users are identified as authorized individual users, and as members of specific groups, by their personal ID and password. Microsoft Access provides two default groups: administrators (named the Admins group) and users (named the Users group), but you can define additional groups.

Although setting up user-level security on most databases can be a daunting task, the User-Level Security Wizard makes it easy to quickly secure your Access database in a one-step process. Furthermore, by implementing common security schemes, the User-Level Security Wizard may even eliminate the need to use the Security command on the Tools menu.

The User-Level Security Wizard will help you to assign permissions and create user and group accounts. However, after running the wizard, you can manually assign, modify, or remove permissions for user and group accounts in your workgroup for a database and its existing tables, queries, forms, reports, and macros. You can also set the default permissions that Microsoft Access assigns for any new tables, queries, forms, reports, and macros that are created in a database.

Permissions are granted to groups and users to regulate how they are allowed to work with each table, query, form, report, and macro in a database. For example, members of the Users group might be allowed to view, enter, or modify data in a Customers table but not to change the design of that table. Members of the Users group might be allowed to only view data in a table containing order data but be totally denied any access to a Payroll table. Members of the Admins group have full permissions on all of a database's tables, queries, forms, reports, and macros. You can have more detailed control by creating your own group accounts, assigning appropriate permissions to those groups, and then adding users to those groups.

If you only need an administrators group and users group for your security purposes, you don't need to create additional groups; you can use the default Admins and Users groups. In this case, you only need to assign the appropriate permissions to the default Users group, and add any additional administrators to the default Admins group. Any new users you add are automatically added to the Users group. Typical permissions for the Users group might include Read Data and Update Data for tables and queries, and Open/Run for forms and reports.

If you need more detailed control of different groups of users, you can create your own groups, assign different sets of permissions to those groups, and then add users to the appropriate groups. To simplify the management of permissions, it is recommended that you only assign permissions to groups (not users), and then add users to the appropriate groups.

For example, you could secure an Orders database by creating a Managers group for managers, a Sales Reps group for sales representatives, and a Staff group for staff employees. You can assign the least restrictive set of permissions to the Managers group, a more restrictive set of permissions to the Sales Reps group, and the most restrictive set of permissions to the Staff group. When you create a user account for a new employee, you add that account to the appropriate group. The employee then has the permissions associated with that group.

About workgroups and workgroup information files

5

A Microsoft Access workgroup is a group of users in a multiuser environment who share data. If user-level security is defined, the members of a workgroup are recorded in user and group accounts that are stored in a Microsoft Access workgroup information file. Users' passwords are also stored in the workgroup information file. These security accounts can then be assigned permissions for databases and their tables, queries, forms, reports, and macros. The permissions themselves are stored in the secure database.

The first time a user runs Microsoft Access after Microsoft Office setup, Access will automatically create a Microsoft Access workgroup information file that is identified by the name and organization information that the user specifies. The relative location of this workgroup information file is then added to the following registry keys:

HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Access\Jet\4.0\Engines\SystemDB

and

HKEY_USERS\.DEFAULT\Software\Microsoft\Office\10.0\Access\Jet\4.0\Engines\SystemDB

Subsequent users will inherit the default workgroup file path from the HKEY_USERS registry key. Because this information is often easy to determine, it's possible for unauthorized users to create another version of this workgroup information file and consequently assume the irrevocable permissions of an administrator account (a member of the Admins group) in the workgroup defined by that workgroup information file. To prevent this, create a new workgroup information file, and specify a workgroup ID (WID). Only someone who knows the WID will be able to create a copy of the workgroup information file.

Any user and group accounts or passwords that you create are saved in this workgroup information file unless the user joins a different workgroup using the Workgroup Administrator.

Note In Access 2002, the Workgroup Administrator can now be run from the Security submenu on the Tools menu.

Be sure to write down your exact name, organization, and workgroup ID — including whether letters are uppercase or lowercase (for all three entries) — and keep them in a secure place. If you have to re-create the workgroup information file, you must supply exactly the same name, organization, and workgroup ID. If you forget or lose these entries, you can't recover them and might lose access to your databases.

About how permissions work and who can assign them There are two types of permissions: explicit and implicit. Explicit permissions are those permissions that are granted directly to a user account; no other users are affected. Implicit permissions are those permissions that are granted to a group account. Adding a user to that group grants the group's permissions to that user; removing a user from the group takes away the group's permissions from that user.

When a user attempts to perform an operation on a secured database object, that user's set of permissions are based on the intersection of that user's explicit and implicit

6

permissions. A user's security level is always the least restrictive of that user's explicit permissions and the permissions of any and all groups to which that user belongs. For this reason, the least complicated way to administer a workgroup is to create new groups and assign permissions to the groups, rather than to individual users. Then you can change individual users' permissions by adding or removing them from groups. Also, if you need to grant new permissions, you can grant them to all members of a group in a single operation.

Permissions can be changed for a database object by:

Members of the Admins group of the workgroup information file in use when the database was created.

The owner of the object.

Any user who has Administer permission for the object.

Even though users might not be able to currently perform an action, they might be able to grant themselves permissions to perform the action. This is true if a user is a member of the Admins group, or if a user is the owner of an object.

The user who creates a table, query, form, report, or macro is the owner of that object. Additionally, the group of users that can change permissions in the database can also change the ownership of these objects, or they can re-create these objects, which is another way to change ownership of the objects. To re-create an object, you can make a copy of the object, or import it or export it to another database. This is the easiest way to transfer the ownership of objects, including the database itself.

Note Copying, importing, or exporting doesn't change the ownership of a query that has its RunPermissions property set to Owner's. You can change ownership of a query only if its RunPermissions property is set to User's.

About organizing security accounts A Microsoft Access workgroup information file contains the following predefined accounts.

Account Function

Admin The default user account. This account is exactly the same for every copy of Microsoft Access and other applications that can use the Microsoft Jet database engine, such as Microsoft Visual Basic for Applications (VBA) and Microsoft Excel.

Admins The administrator's group account. This account is unique to each workgroup information file. By default, the Admin user is in the Admins group. There must be at least one user in the Admins group at all times.

Users The group account comprising all user accounts. Microsoft Access automatically adds user accounts to the Users group when a member of the Admins group creates them. This account is the same for any workgroup

7

information file, but it contains only user accounts created by members of the Admins group of that workgroup. By default, this account has full permissions on all newly-created objects. The only way to remove a user account from the Users group is for a member of the Admins group to delete that user.

In effect, security in Microsoft Access is always "on." Until you activate the logon procedure for a workgroup, Microsoft Access invisibly logs on all users at startup by using the default Admin user account with a blank password. Behind the scenes, Microsoft Access uses the Admin account as the administrator account for the workgroup, as well as the owner of any databases and tables, queries, forms, reports, and macros created.

Administrators and owners are important because they have permissions that can't be taken away:

Administrators (members of the Admins group) can always get full permissions for objects created in the workgroup.

An account that owns a table, query, form, report, or macro can always get full permissions for that object.

An account that owns a database can always open the database.

Because the Admin user account is exactly the same for every copy of Microsoft Access, the first steps in securing your database are to define administrator and owner user accounts (or use a single user account as both the administrator and owner account), and then to remove the Admin user account from the Admins group. Otherwise, anyone with a copy of Microsoft Access can log on to your workgroup by using the Admin account and have full permissions for the workgroup's tables, queries, forms, reports, and macros.

You can assign as many user accounts as you want to the Admins group, but only one user account can own the database itself — the user account that is active when the database is created, or when ownership is transferred by creating a new database and importing all of a database's objects into it. However, group accounts can own tables, queries, forms, reports, and macros within a database.

Considerations when organizing security accounts: Only user accounts can log on to Microsoft Access; you can't log on by using a group account.

The accounts that you create for users of the database must be stored in the workgroup information file that those users will join when they use the database. If you're using a different file to create the database, change the file before creating the accounts.

Make sure to create a unique password for your administrator and user accounts. A user who can log on by using the administrator account can always get full permissions for any tables, queries, forms, reports, and macros created in the

8

workgroup. A user who can log on using an owner account can always get full permissions for those objects owned by that user.

After you create user and group accounts, you can view and print the relationships between them. Microsoft Access prints a report of the accounts in the workgroup, showing the groups to which each user belongs and the users that belong to each group.

Note If you are using a workgroup information file created with Microsoft Access version 2.0, you must be logged on as a member of the Admins group to print user and group information. If the workgroup information file was created with Microsoft Access version 7.0 or later, all users in the workgroup can print user and group information.

Secure an Access database and its objects with user-level security

User-level security is the most flexible and extensive method of securing your Microsoft Access database. You can set up security on your database to require users to log on to get into the database or not.

Secure a database by using the User-Level Security Wizard With the User-Level Security Wizard, you can apply user-level security with a comprehensive security scheme and encrypt your Microsoft Access database.

Open the database that you want to secure.

On the Tools menu, click Security, and then click User-Level Security Wizard.

Follow the directions in the wizard dialog boxes.

Notes

The User-Level Security Wizard creates a back-up copy of the current Access database with the same name and a .bak extension, and then secures the selected objects in the current database.

If your current Access database protects Microsoft Visual Basic for Applications (VBA) code with a password, the wizard prompts you for the password, which you must enter or the wizard doesn't complete successfully.

Any passwords that you create through the wizard are printed in the User-Level Security Wizard report when you finish using the wizard. You should keep this report in a secure location. You can use this report to re-create your workgroup file.

Secure a database without requiring users to log on If you want to secure some parts of a database, such as the design of certain objects, but you do not care about establishing different levels of access for different groups of users, you may want to consider securing an application without requiring users to log on. This does not remove user-level security but essentially disables it for all but specific objects.

Secure your database by using the User-Level Security Wizard.

9

How? With the User-Level Security Wizard, you can apply user-level security with a comprehensive security scheme and encrypt your Microsoft Access database.

Open the database that you want to secure.

On the Tools menu, click Security, and then click User-Level Security Wizard.

Follow the directions in the wizard dialog boxes.

Notes

The User-Level Security Wizard creates a back-up copy of the current Access database with the same name and a .bak extension, and then secures the selected objects in the current database.

If your current Access database protects Microsoft Visual Basic for Applications (VBA) code with a password, the wizard prompts you for the password, which you must enter or the wizard doesn't complete successfully.

Any passwords that you create through the wizard are printed in the User-Level Security Wizard report when you finish using the wizard. You should keep this report in a secure location. You can use this report to re-create your workgroup file.

For each table, query, form, report, and macro you want to be available to users, grant the appropriate permissions to the Admin user account.

How? Open the database.

The workgroup information file in use when you log on must contain the user or group accounts that you want to assign permissions for at this time; however, you can assign permissions to groups and add users to those groups later.

On the Tools menu, point to Security, and then click User And Group Permissions.

On the Permissions tab, click Users or Groups, and then in the User/Group Name box, click the user or group that you want to assign permissions to.

Click the type of object in the Object Type box, and then click the name of the object to assign permissions for in the Object Name box. Select multiple objects in the Object Name box by dragging through the objects you want to select, or by holding down CTRL and clicking the objects you want.

Note Hidden objects aren't displayed in the Object Name box unless you select Hidden objects on the View tab of the Options dialog box (Tools menu).

Under Permissions, select the permissions you want to assign, or clear the permissions you want to remove for the group or user, and then click Apply. Repeat steps 4 and 5 to assign or remove permissions for additional objects for the current user or group.

10

Repeat steps 3 through 5 for any additional users or groups.

Notes

Some permissions automatically imply the selection of others. For example, the Modify Data permission for a table automatically implies the Read Data and Read Design permissions because you need these to modify the data in a table. Modify Design and Read Data imply Read Design. For macros, Read Design implies Open/Run.

When you edit an object and save it, it retains its assigned permissions. However, if an object is saved with a new name, it is now a new object, and so has the default permissions defined for that object type rather than the permissions of the original object.

Turn off the Logon dialog box.

How? If you don't need to establish different levels of permissions for different groups of users, you can have Microsoft Access automatically log users on as the Admin user in the Users group with the permissions specified for that group. Users will not be required to enter their user name and password in the Logon dialog box when they open the database. Using this method, you can secure any or all of the objects in a database. However, each user will have the same set of permissions. This does not remove user-level security from the database.

Join the workgroup that has the logon procedure that you want to deactivate.

How? Important If you are setting up user-level security and need to make sure that your workgroup and its permissions can't be duplicated, you should make sure the workgroup information file that defines the workgroup you're joining has been created with a unique workgroup ID (WID). If such a workgroup information file doesn't exist, you should create one.

Start Microsoft Access.

On the Tools menu, point to Security, and then click Workgroup Administrator.

In the Workgroup Administrator dialog box, click Join.

Type the path and name of the workgroup information file that defines the Microsoft Access workgroup you want to join, and then click OK, or click Browse and then use the Select Workgroup Information File dialog box to locate the workgroup information file.

The next time you start Microsoft Access, it uses the user and group accounts and passwords stored in the workgroup information file for the workgroup you joined.

On the Tools menu, point to Security, and then click User And Group Accounts.

Click the Users tab.

11

In the Name box, select Admin from the list, and then click Clear Password.

The next time any member of the workgroup that you joined in step 1 starts Microsoft Access and opens a database, it will no longer display the Logon dialog box.

Remove user-level security

Start Microsoft Access.

Open the database that was secured with user-level security.

Log on as a workgroup administrator (a member of the Admins group).

Give the Users group full permissions on all tables, queries, forms, reports, and macros in the database.

How?

Open the database.

The workgroup information file in use when you log on must contain the user or group accounts that you want to assign permissions for at this time; however, you can assign permissions to groups and add users to those groups later.

On the Tools menu, point to Security, and then click User And Group Permissions.

On the Permissions tab, click Users or Groups, and then in the User/Group Name box, click the user or group that you want to assign permissions to.

Click the type of object in the Object Type box, and then click the name of the object to assign permissions for in the Object Name box. Select multiple objects in the Object Name box by dragging through the objects you want to select, or by holding down CTRL and clicking the objects you want.

Note Hidden objects aren't displayed in the Object Name box unless you select Hidden objects on the View tab of the Options dialog box (Tools menu).

Under Permissions, select the permissions you want to assign, or clear the permissions you want to remove for the group or user, and then click Apply. Repeat steps 4 and 5 to assign or remove permissions for additional objects for the current user or group.

Repeat steps 3 through 5 for any additional users or groups.

Notes

Some permissions automatically imply the selection of others. For example, the Modify Data permission for a table automatically implies the Read Data and Read Design permissions because you need these to modify the data in a table. Modify Design and Read Data imply Read Design. For macros, Read Design implies Open/Run.

When you edit an object and save it, it retains its assigned permissions. However, if an object is saved with a new name, it is now a new object, and so has the default

12

permissions defined for that object type rather than the permissions of the original object.

Exit and restart Microsoft Access and then log on as Admin.

Create a new blank database, and leave it open.

Import all the objects from the original database into the new database.

How?

Open the database or switch to the Database window for the open database.

On the File menu, point to Get External Data, and then click Import.

In the Files Of Type box, make sure Microsoft Access (*.mdb; *.adp; *.mda; *.mde; *.ade) is selected.

Click the arrow to the right of the Look In box, select the drive and folder where the Microsoft Access database (.mdb) or Microsoft Access project (.adp) that you want to import from is located, and then double-click the database's icon.

In the Import Objects dialog box, click the tab for the kind of object that you want to import, and then click each object that you want to import, or click Select All to import all objects of the desired type. Repeat this step for each kind of object that you want to import.

To import just the tables' definitions (not the data that they contain), click Options, and then under Import Tables, click Definition Only.

To import select queries as tables (for example, to create a read-only database), click Options, and then under Import Queries, click As Tables. Action queries import as queries no matter how this option is set.

To include relationships, custom menus and toolbars, or import/export specifications (Access database only), click Options, and then, under Import, select the items you want included. Microsoft Access won't import a toolbar, menu bar, or shortcut menu if it has the same name as one in the Access file that you're importing to.

If users will be using the current workgroup information file when they open the database, clear the password for Admin to turn off the Logon dialog box for the current workgroup. This is not necessary if users will be using the default workgroup information file created when they install Microsoft Access.

The new database is now completely unsecured. The workgroup information file that was current when the new database was created in step 6 defines the Admins group for the new database.

III. About distributing a secure application

A secure application depends on users having access to both an application database where permissions are stored, and a workgroup where user and group accounts and passwords are stored. Depending on how the application is to be used, you can make the application and workgroup available to users in a variety of ways.

13

Copy the application files and the workgroup information file that defines the workgroup to a network server location

Using the Workgroup Administrator, users can join the workgroup by specifying the network server path to the workgroup information file, and then run the application directly from the server location. You might want to prevent users from opening the application with exclusive access by removing Open Exclusive permissions for the database from the Users group.

Give each user a copy of the application files and the workgroup information file that defines the workgroup

Using the Workgroup Administrator, users can join the workgroup by specifying the path to the workgroup information file on their computer, and then running their copies of the application on their computers. However, if you have to update the application, its data, or the workgroup information file, you'll have to give each user copies of all updated files.

As an alternative, you might want to split the application into a data database placed on a network server and an application database containing all other database objects placed on each user's computer — a database configuration typically known as a front-end/back-end application. Typically, in this configuration, you want to keep the workgroup information file on the server as well. Then if you have to update the application, you only have to give users updated versions of the application database file.

Give users in different Microsoft Access workgroups access to the application by creating the same group in each workgroup You can create a group account in each workgroup with an identical name and personal ID (PID), and then add users in each workgroup to that group. For example, a user working on a network on a Microsoft Access workgroup in Honolulu can use an application created for a Microsoft Access workgroup in Melbourne if that user is a member of a group account that was created with an identical name and PID on both workgroups.

IV. About securing a replicated database

To secure a replicated database, you can set user permissions on replicated database objects. These permissions will not interfere with synchronization of the database. However, you can't use a password to protect your replicated database. A password-protected database can't be made replicable, nor can a password be assigned to a replicated database.

You can also keep a replica in an unshared directory and use indirect synchronization (through Microsoft Replication Manager). If direct synchronization is required, set the permissions on the server where the replicas reside so that only specific users can access them. Do not put replicas on read-only servers, because synchronizations with other replica set members will not occur.

14

V. Secure a Microsoft Access project

Unlike a Microsoft Access database, you can't secure forms, reports, or macros in an Microsoft Access project (.adp) by using user-level security. To secure form and report objects, you can hide the objects in the Database window or set startup options. To secure access to the design of forms and reports in an Access project file, you can either set startup options or save your Access project file as an .ade file. To secure access to macros in an Access project file, use startup options. You can secure a data access page by using file or folder security for your operating system. You can also secure your Visual Basic for Applications (VBA) code by converting your Access project file to an .ade file or by setting a password. And finally, if your Access project is connected to a Microsoft SQL Server 6.5 (or later) database with SQL Server security implemented, then you can change the logon password from within Access.

Show or hide database objects in the Database window

Specify whether a database object is hidden or visible

Under Objects in the Database window, click the type of database object whose properties you want to change.

Click Properties on the toolbar.

Select or clear the Hidden check box.

Note In a Microsoft Access project, you cannot change the properties of a table, query, or database diagram because these objects reside in the Microsoft SQL Server database. However, you can change the properties of a form, report, macro, or module, because these objects reside in the Access project itself, not in the Microsoft SQL Server database. You can also change the properties of a data access page.

Show or hide objects defined as hidden by default

If you need to work with objects that are defined as hidden without changing their status as hidden, you can display them in the Database window.

On the Tools menu, click Options.

Click the View tab.

Under Show, select or clear the Hidden objects check box. Microsoft Access displays hidden objects with dimmed icons to distinguish them from objects that aren't defined as hidden.

Show or hide system objects by default

Microsoft Access automatically creates system objects when you create a new database.

On the Tools menu, click Options.

15

Click the View tab.

Under Show, select or clear the System objects check box.

Use startup options

You can use startup options to specify, for example, what form to display, whether toolbars can be customized, and whether shortcut menus are available in your Microsoft Access file. You can also use a special macro named AutoExec to carry out an action or series of actions when your database first opens. When you open a database, Microsoft Access looks for a macro with this name and, if it finds one, runs it automatically.

Set startup options

On the Tools menu, click Startup.

Select the options or enter the settings you want to use.

For information about a specific item in the dialog box, click the question mark at the top of the dialog box, and then click the item.

Create a macro that runs when an Access file first opens

Create a macro containing the actions you want to run when you open the database.

Save the macro with the name AutoExec.

The next time you open the database, Microsoft Access runs this macro automatically.

Note If you don't want to run the AutoExec macro when you open the database, hold down the SHIFT key when the database opens.

Secure data access pages

Data access pages are Hypertext Markup Language (HTML) files that reference the data in a database. The data access pages aren't actually stored in the Microsoft Access file. For this reason, Access has no control over the security of the data access page files. To secure a data access page that is stored on a local or network file system, assuming you have the appropriate permissions, you can use the following procedure.

Note To secure data access page files that are stored on an HTTP server, you must use the security features available on the server itself.

Open Windows Explorer or My Computer.

Locate the folder where the data access page's HTML file is located. By default, the file will be located in the same directory as your Access database.

Right-click the data access page (.htm) file or the folder containing the file, click Properties on the shortcut menu, and then select the Read-only check box.

16

Secure Visual Basic for Applications code

You can protect the Visual Basic for Applications (VBA) code in your Microsoft Access project (.adp) by using a password or by saving a copy of your file as an .ade file. Saving your .adp file as an .ade file is more secure than password protecting your code. However, there are some limitations in using an .ade file.

Protect Visual Basic for Applications code with a password

To prevent someone from viewing or making changes to your Microsoft Visual Basic for Applications (VBA) code, you can protect the code by requiring a password.

Open the Microsoft Access project (.adp) file or Microsoft Access database (.mdb) file that has the VBA code you want to protect.

In the Database window, point to Macro on the Tools menu, and then click Visual Basic Editor.

Tip

You can also press ALT+F11.

In the Microsoft Visual Basic Editor, click <Access database or Access project name> Project Properties on the Tools menu.

On the Protection tab, select the Lock project for viewing check box. If you set a password but don't select Lock project for viewing, the code can be viewed and edited by anyone, but the Project Properties dialog box is protected.

In the Password box, type your password.

Guidelines for passwords

User names can range from 1 to 20 characters, and can include letters, accented characters, numbers, spaces, and symbols, with the following exceptions:

The characters " \ [ ] : | < > + = ; , . ? *

Leading spaces

Control characters (ASCII 10 through ASCII 31)

Note Passwords are case-sensitive.

In the Confirm password box, confirm your password by typing the password again, and then click OK.

The password is now set. The next time you or any other user opens the database, a dialog box will be displayed that requests a password.

Important If you forget your password, it can't be recovered, and you won't be able to view or edit the VBA code.

17

Make an ADE file

Cautions

Be sure to save a copy of your original Microsoft Access project (.adp) file.

You can't modify the design of forms, reports, or modules in an Access project file saved as an .ade file. If you need to change the design of these objects, you must do so in the original Access project file and then resave the Access project file as an .ade file.

You can't create an .ade file in Access 2002 from an Access project file created in an earlier version. You can only save an .ade file from an Access project file from the same version of Access.

You also won't be able to convert an Access project file saved as an .ade file in future versions of Microsoft Access. You will be able to run the .ade file in a later version of Access.

Close the Access project file. If you are working in a multiuser environment, make sure that all other users have closed the Access project file.

On the Tools menu, click Database Utilities, and then click Make ADE File.

In the Database To Save As ADE dialog box, specify the Access project file you want to save as an .ade file, and then click Make ADE.

In the Save ADE As dialog box, specify a name, drive, and folder for the Access project.

Change the password of your Access project

If your Microsoft Access project (.adp) is connected to a Microsoft SQL Server 6.5 (or later) database with SQL Server security implemented, then you can change the logon password from within Access.

Open an Access project file or switch to the Database window for the open project.

On the Tools menu, point to Security, and then click Set Login Password.

In the Old Password box, type the current password.

In the New Password box, type your password.

See Guidelines for passwords above

In the Verify box, confirm your password by typing the password again, and then click OK.

The password is now changed and Access resets the .adp connection with the new password information. The next time you or any other user opens the project, a dialog box will be displayed that requests the new password.

18

Important If you lose or forget your password, it can't be recovered, and you won't be able to open your project.

VI. About ADE files

If your Microsoft Access project (.adp) file contains Visual Basic for Applications (VBA) code, saving your Access project as an .ade file compiles all modules, removes all editable source code, and compacts the destination Access project file. Your VBA code will continue to run, but it cannot be viewed or edited.

Your Access project file will continue to function normally — you can still update data and run reports. Additionally, the size of your Access project will be reduced due to the removal of the code, so memory usage is optimized, which will improve performance.

Saving your Access project file as an .ade file prevents the following actions:

Viewing, modifying, or creating forms, reports, or modules in Design view.

Adding, deleting, or changing references to object libraries or databases.

Changing code — an .ade file contains no source code.

Importing or exporting forms, reports, or modules. However, tables, data access pages, views, stored procedures, database diagrams, and macros can be imported from or exported to non-.ade Access projects.

Considerations if you need to modify the design of forms, reports, or modules

Be sure to save a copy of your original Access project file. If you need to modify the design of forms, reports, or modules in an Access project file that you have saved as an .ade file, you must modify the original Access project, and then resave it as an .ade file.

You won't be able to open, convert, or run code in an Access 2002 .ade file in future versions of Access. The only way to convert an Access 2002 .ade file to a future version will be to open the original Access project that the .ade file was created from, convert it to the later version of Access, and then save the converted Access project file as an .ade file.

Considerations before saving your Access project file as an .ade file

Some restrictions may prevent you from saving your Access project file as an .ade file:

You must have password access to the VBA code if a password is defined.

If your Access project references another Access project or add-in, you must save all Access projects and add-ins in the chain of references as .ade or .mde files.

19

About references and .ade files

If you try to create an .ade file from an Access project file or an add-in that references another Access project or add-in, Access displays an error message and doesn't let you complete the operation. To save an Access project that references another Access project as an .ade file, you must save all projects in the chain of references as .ade or .mde files, starting from the first project referenced. After saving the first project as an .ade or .mde file, you must then update the reference in the next project to point to the new file before saving it as an .ade file, and so on.

For example, if Project1.adp references Project2.adp, which references Project3.mda, you would proceed as follows:

Save Project3.mda as Project3.mde.

Open Project 2.adp and change its reference to point to the new Project3.mde.

Save Project2.adp as Project2.ade.

Open Project1.adp and change its reference to point to the new Project2.ade.

Save Project1.adp as Project1.ade.

VII. Selecting the type of security validation used when logging on to SQL Server

From a Microsoft Access project (.adp) file, you can administer basic security tasks by using the Database Security command to add, edit, or delete server logins, database users, and database roles.

Note You must have SQL Server installed on the same computer as the Access project for these commands to work.

SQL Server provides two security methods for validating logins to the SQL Server database:

SQL Server security, which uses SQL Server user names and passwords.

Windows NT integrated security, which uses Windows NT account user names. In this case, Windows NT authenticates a user when they log on, and SQL Server accepts Windows NT authentication.

To select the type of security validation used, do one of the following:

Use SQL Server security

Select the Use a specific username and password checkbox on the Connection tab of the Data Link Properties dialog box.

Do one of the following:

Clear the Allow saving of password check box to require users to log on to the SQL Server database each time they open the Access project.

20

Select the Allow saving of password check box if you want to create an application that doesn't require a user to repeatedly log in to the SQL Server database.

Use Windows NT authentication to connect an SQL Server database

Select the Use Windows NT Integrated Security checkbox on the Connection tab of the Data Link Properties dialog box.

You don't need to provide a password because SQL Server uses your network login identity.

Enable or disable the System Administration (SA) user name in an Access project

Note The hyperlinks in this topic goes to the Web. You can switch back to Help at any time.

Enable the SA user name

If your Microsoft Access project is connected to a locally installed SQL Server 7.0 (or later) database or a Microsoft SQL Server 2000 Desktop Engine (formerly called MSDE) with Microsoft Windows NT Authentication implemented, you can enable the system administrator (SA) user name with a blank password so that other users can access the application. Enabling the SA user name will also allow the System Administrator to change the SA password for additional security.

Note In order for the Enable system administrator (SA) user name check box to be enabled, the following must be true:

The Access project must be connected to a SQL Server 7.0 (or later) database or a Microsoft SQL Server 2000 Desktop Engine (formerly called MSDE).

The SQL Server database must be running on a Windows NT platform.

The SQL Server must be running on the same computer as the Access project.

The current Windows NT user must be an Administrator for the computer.

The current SQL Server user must be a member of the System Administrator role.

Open an Access project file or switch to the Database window for the open project.

On the View menu, click Server Properties.

Select the Enable system administrator (SA) user name check box.

Click OK in the message box.

When this option is selected, the following actions take place.

The Access project is disconnected from the SQL Server database. This closes all open designers (such as the View Designer). See the Microsoft Developers Network Web site for more information on designers.

21

The login mode is changed to mixed mode security (both SQL Server security and Windows NT Authentication are implemented).

Access stops and starts the database service.

The connection to the Access project is changed to use the SA user name with no password.

The Access project is then reconnected to the database.

Notes

It is strongly recommended that the SA password be changed by using the Set Login Password command (on the Tools menu, point to Security).

If a connection to the Access project fails, a standard SQL Server login dialog box is displayed so that the user name or password can be corrected.

Disable the SA user name

Open a Microsoft Access project file or switch to the Database window for the open project.

On the View menu, click Server Properties.

Clear the Enable system administrator (SA) user name check box.

When this option is cleared, the following actions take place.

The Access project is disconnected from the SQL Server database which closes all open designers (such as the View Designer). See the Microsoft Developers Network Web site for more information on designers.

The login mode is changed to Microsoft Windows NT Authentication only.

Access stops and starts the database service.

The connection to the Access project is changed to use Trusted Security. See the Microsoft Developers Network Web site for more information on Trusted Security.

The Access project is then reconnected to the database.

1

Cursul_III_18 Metode de proiectare orientate obiect – POO: modelarea obiectualã, staticã, dinamicã ºi funcþionalã 1. Introducere Sistemele informatice, ca ºi subsistemele ºi aplicaþiile care le compun, se concretizeazã în final, atunci când sunt distribuite utilizatorilor, în niºte produse program. Acestea au un pronunþat caracter abstract ºi în ciuda faptului cã atunci când sunt puse în funcþiune îi permit utilizatorului sã recunoascã multe aspecte din practica derulãrii manuale a aplicaþiei sau sistemului, în calculator ele existã sub forme total diferite de ceea ce îºi închipuie utilizatorul. Avem în vedere tabelele, interogãrile, rapoartele, formularele, modulele program, macrourile, meniurile, etc. care sunt de fapt niºte fiºiere; dacã nu ele sunt fisiere, mãcar baza de date în care sunt constituite este reprezentatã printr-un fiºier (acest lucru depinde de SGBD-ul folosit). Rezultã foarte clar de aici cã analistul programator trebuie sã vadã activitatea de informatizat prin douã prisme total diferite: cea a utilizatorului, care ºtie cum funcþioneazã aplicaþia în practicã ºi cea a programatorului, care ºtie cu ce noþiuni poate opera în programare. Se ºtie cã activitãþile desfãºurate de analistul programator de la analiza domeniului de activitate ce trebuie informatizat ºi pânã la darea în funcþiune a produsului program se pot constitui într-un proces, aºa numitul proces software. Acest proces are o etapizare (mai modern – un ciclu de viaþã) care depinde de metoda de abordare aleasã de analist. Mai cunoscutã este abordarea funcþionalã, abordarea orientatã spre proces, abordarea orientatã spre date, apoi cea spre evenimente ºi orientarea pe obiecte. Atunci când pentru realizarea produsului program folosim un mediu de programare bazat pe obiecte, cum este cazul Access sau Visual FoxPro, orientarea pe obiecte (OO), are un mare avantaj ºi anume acela cã obiectele pot fi folosite atât în modelarea activitãþilor umane cât ºi în realizarea produsului program. Cu alte cuvinte în modelarea pe obiecte nu mai existã acea conversie, adeseori foarte dificilã, de la modelul logic la modelul conceptual, de la modelul conceptual la cel logic ºi în final de la modelul logic la cel fizic. Întrebarea care se pune în continuare este cum am putea aborda orientat pe obiecte un sistem sau o aplicaþie informaticã?

2

Rãspunsul ar putea începe de la faptul cã trebuie sã dispunem de un SGBD bazat pe obiecte ºi ulterior sã cãutãm sã aplicãm filozofia care a stat la baza programãrii acelui SGBD ºi în analiza domeniului de activitate pe care vrem sã-l trecem pe calculator. Cum aceste SGBD au fost realizate prin programare orientatã pe obiecte _ POO, aceasta presupune sã ºtim cum se abordeazã realitatea în cadrul POO. Iatã deci motivul care a inspirat tema acestui curs. În POO lumea realã este de la început perceputã prin prisma obiectelor deºi nu este deloc lipsit de importanþã sã precizãm cã pe timpul modelãrii ºi apoi a proiectãrii existã ºi aici o oarecare nuanþare a obiectelor, deci o oarecare evoluþie a lor, dar aceasta este mai uºor de suportat de analistul programator decât în cazul celorlalte metode de abordare. POO mai are un mare avantaj: acesta se manifestã în programare ºi constã în faptul cã multe entitãþi din lumea realã, în ciuda faptului cã sunt foarte diferite ca înþeles ºi substanþã, în calculator pot fi modelate cu acelaºi tip de obiect (sau clasã de obiecte). Aceastã constatare face posibilã o mare economie de timp ºi de efort pentru realizarea produsului soft - lucru ce va fi înþeles mai târziu când vom analiza îndeaproape modul concret de programare în POO. Deocamdatã ne mulþumim sã precizãm cã în POO un obiect modeleazã o entitate din lumea realã sau imaginarã. Gãsirea obiectelor ºi a comportamentului lor constituie obiectivele principale ale analizei ºi proiectãrii orientate spre obiecte. În prima etapã obiectele sunt lucruri reale având o delimitare clarã. Fiecare obiect este unic. Fiecare obiect posedã propriul lui set de caracteristici unice. Respectând aceste aspecte, este uºor în etapa doua, sã-i asociem fiecãrui obiect real, un obiect abstract, adicã un obiect software ºi sã trecem în lumea proiectului fizic. Trebuie spus cã deºi studiul obiectelor se pierde în negura timpului spre Platon ºi Aristotel, odatã cu apariþia orientãrii spre obiecte în programare, ideea s-a dovedit foarte atractivã ºi pentru alte domenii de activitate astfel cã a apãrut o paradigmã a orientãrii spre obiecte. Conform acestei paradigme obiectul (obiectul software) este o entitate abstractã care executã anumite acþiuni la cerere. El este caracterizat de o stare, de un comportament bine definit si de identitate. Exemple de obiecte:

- în cazul interfeþelor de programare a aplicaþiilor: o resursã a sistemului de operare, materializatã printr-o structurã internã a acestuia cum ar fi: fir, fiºier, pictogramã, cursor, sau

3

orice unitate de informaþie la care un subiect doreºte acces; - în cazul reþelelor: o resursã care nu conþine alte resurse, de ex. conectarea la obiect; - în cazul mecanismelor de tip OLE: orice poate fi ataºat sau mânuit de o aplicaþie: text, tabel, imagine graficã, sunet, videoclip, etc.

Softul în concepþia OO este o colecþie de obiecte care au structuri de date ºi comportãri. Pentru a proiecta ºi implementa soft orientat spre obiecte trebuie cunoscutã metoda de abordare specificã acestei paradigme ºi bineînþeles un limbaj de programare adecvat. Cele mai populare limbaje orientate spre obiecte sunt Smalltalk ºi C++, la care se pot adãuga limbajele specifice bazelor de date relaþionale. Cu aceste limbaje se creazã clase (de obiecte), iar obiectele reprezintã concretizarea unei clase. O clasã se poate concretiza (instanþia) în mai multe obiecte. În afarã de "orientare-obiect" mai existã sintagma “bazat pe obiecte”. Programarea care se face în cadrul SGBD Access sau Visual FoxPro, de cãtre analistul programator care nu a abordat sistemul prin orientare pe obiecte este bazatã pe obiecte. Adicã analiza ºi modelarea se face prin metode clasice iar generarea produsului program se face cu ajutorul unor medii de programare în care existã definite clase ºi programatorul doar le instanþeazã, adicã le “dã fiinþã”. Astfel de clase existã în mediile de programare bazate pe obiect sub forma tabelelor, interogãrilor, formularelor, rapoartelor, DAO s.a.m.d. Prin analogie, putem spune cã la o fabricã de automobile clasa este marca ºi modelul automobilului, materializatã prin proiectul automobilului, tehnologia de fabricaþie ºi linia tehnologicã de producþie a acelui automobil. Dacã în acel moment se construieºte automobilul cu seria X, acela este o instanþã a (clasei) automobilului pe care-l produce acea fabricã. Programatorul care creazã obiecte în cadrul mediului de programare Access nu creazã clase ci instanþeazã niºte clase, adicã pe baza claselor disponibile în biblioteca acestui mediu de programare, creazã niºte obiecte. Spre deosebire de Access, în visual FoxPro programatorul poate sã ºi creeze clase. ªi în Access se poate face ceva în materie de obiecte ºi anume se pot crea proprietãþi ale unor obiecte existente, dar nu se pot crea clase noi. 2. Fundamentele orientãrii spre obiecte Identitatea este unicul cod care permite distingerea unui obiect faþã de altul. Aceasta este implementatã software ca un identificator (ID) de tip read_only.

4

Starea reprezintã setul de date care conþin informaþii cu privire la obiect. Starea se materializeazã în memorie prin structura esenþialã a obiectului ºi valorile sale curente. Un exemplu simplu de clasã de obiecte ar fi punctul în 2D, a cãrei structurã se materializeazã prin locul rezervat pentru valoarea ordonatei ºi abscisei. Dacã în cadrul acestei clase am declarat punctul A acesta devine o instanþã a clasei punct în 2D. Dacã am mai declarat un punct B, acesta este o altã instanþã a clasei punct în 2D. Când datele privitoare la un punct, în cazul de faþã coordonatele lui, sunt completate cu valori, de exemplu completãm pentru punctul A abscisa egalã cu 2 ºi ordonata egalã cu 3, atunci obiectul A a cãpãtat o stare. Nu este nici o problemã dacã la un moment dat punctul A se suprapune cu B, adicã dacã ºi B ar avea aceeaºi stare cu A. Cu alte cuvinte când douã obiecte au aceeºi stare, ele nu se dezintegreaza ci îºi pãstreazã identitatea, (contiunã sã existe ca obiecte separate) ºi oricând îºi pot schimba starea în direcþii diferite. Comportamentul unui obiect corespunde serviciilor pe care acesta le oferã clienþilor sãi. Comportamentul este concretizat prin modul în care obiectul reacþioneazã la evenimentele cauzate de sursele externe ºi prin modul în care interacþioneazã cu alte obiecte. Determinarea comportamentului unui obiect depinde în mod hotãrâtor de contextul în care se desfãºoarã scenariul. Astfel dacã într-un mediu de graficã vectorialã vom înzestra punctul numai cu proprietatea de a urma mouse-ul pentru a modifica forma unei curbe ºi cu proprietatea de a þine aproape de punctul care este tras cu mouse-ul (în cazul în care nu el este cel tras cu mouse-ul), într-un mediu destinat proiectãrii la scarã cum este CAD, punctul va oferi mai multe servicii cum ar fi: aflarea distanþei dintre douã puncte, returnarea coordonatelor sale, furnizarea reprezentãrii polare a poziþiei sale, etc. Comportamentul este corespunzãtor mesajelor pe care clientul i le transmite obiectului. Termenul client este legat de clasã. O clasã este o implementare, adicã o definire de obiecte, care poate fi instanþiatã în vederea creãrii de multiple obiecte având acelaºi comportament. Un obiect este o instanþã a unei clase. Existã clase server, care oferã serviciile sale altor clase ºi clase client, care utilizeazã serviciile altor clase. Astfel un obiect din clasa punct îºi poate oferi serviciile sale unui obiect din clasa segment. De exemplu punctul participã la calculul lungimii segmentului în care el este implicat. Clasa punct este în acest fel

5

clasã server faþã de clasa segment, care este o clasã client. Sã remarcãm cã o clasã poate juca rolul de client pentru o clasã, dar în acelasi timp, poate constitui clasã server pentru o altã clasã. De exemplu clasa segment ar putea fi clasã server pentru un poligon cãruia dorim sã-i calculãm perimetrul. Definim interfaþa unei clase ca fiind implementarea întregului sãu comportament. Interfaþa corespunde metodelor care pot fi utilizate de un client al clasei. Mesajele clientului constã de fapt în apelarea de metode ale clasei server. Interfaþa unei clase poate conþine elemente publice ºi/sau elemente private. Încapsularea ºi ascunderea informaþiei Starea obiectului este o caracteristicã staticã, în timp ce comportamentul este o caracteristicã dinamicã. Ca sã foloseascã un obiect, clientul trebuie sã ºtie cum sã apeleze metodele acestuia, dar nu are nevoie sã ºtie ºi starea obiectului. De aceea stãrile obiectelor nu sunt accesibile utilizatorilor, adicã sunt încapsulate. Incapsularea este importantã pentru cã permite producãtorilor de soft sã-ºi pãstreze secretul structurii programelor pe care le produc. Încapsularea se poate extinde ºi asupra modulelor, sistemelor, interfeþelor. În acest caz avem de aface cu ascunderea informaþiei. Mesaje ºi metode Comportamentul unui obiect corespunde cu setul de mesaje care-i pot fi transmise. Obiectele comunicã prin intermediul acestor mesaje. Metodele sunt segmente de cod (scris într-un limbaj de programare orientat spre obiecte) care implementeazã mesajele. Cu alte cuvinte fiecãrui mesaj trebuie sã-i corespundã o metodã. Metodele au acces la starea obiectului, atât cât este strict necesar ca sã-ºi ducã misiunea la bun sfârºit. Dupã influienþa lor asupra stãrii obiectului, metodele se împart în: - Constructori (metode care genereazã o nouã instanþã a unei clase date); - Destructori (metode care eliminã din memorie un obiect

aparþinând clasei la care se referã distructorul); - Selectori (metode care invocã obiecte, dar nu modificã

starea lor); - Modificatori (acestea modificã starea obiectului) Instanþa clasei ºi proprietãþile clasei Din cele prezentate mai sus în legãturã cu starea obiectelor ºi a claselor putem deduce cã starea unui obiect este echivalentã cu atributele sale ºi cu valorile acestora. În cazul clasei aceste atribute pot fi de douã tipuri: de instanþiere ºi atribute de clasã.

6

Este clar cã atributele de instanþiere trebuie sã defineascã identitatea unui obiect din clasa respectivã ºi aceste atribute trebuie sã aibã valori specifice unui obiect. De exemplu clasa Sportivi va trebui pentru a genera un sportiv, sã ne permitã sã-i precizãm numele sau codul_personal, în timp ce atributele de clasã trebuie sã reliefeze ceea ce este caracteristic clasei. De exemplu disciplina sportivã practicatã. O metodã de instanþiere este aplicatã unui singur obiect. Orice clasã trebuie sã dispunã de o metodã de instanþiere ( cum ar fi constructorul) ºi trebuie sã accepte un mesaj prin care i se cere sã aplice metoda ei de instanþiere. Categorii de obiecte Pe timpul perioadei de analizã este bine sã putem identifica categoria de obiecte ce se preteazã a fi folositã pentru a modela diferite tipuri de entitãþi ºi concepte. În acest scop se folosesc urmãtoarele categforii de obiecte: - tangibile (apar sub forma substantivelor din lumea realã: pompã, maºinã, carte); - incidente (sau evenimente: accidente, plãþi, zboruri,

clic, apariþii, etc); - interacþiuni (seamãnã cu relaþiile din diagramele

entitate_relaþie: rezervarea biletelor, înscrieri, operaþii medicale, etc).;

- specificaþii (metadate sau date ce descriu date: model de maºinã, catalog, etc.);

- intangibile (se referã la entitãþi conceptuale: intersecþii, conturi, poziþii, etc.);

- roluri (modeleazã organizãrile de personal: client, cititor, angajat, pacient, etc.);

Pentru a uºura generarea claselor se folosesc aºa numitele tipuri abstracte de date sau TAD Acestea conþin o încapsulare de date ºi operaþiile asupra acestora. Unele limbaje ca Modula-2 ºi Ada implemnteazã TAD-uri în timp ce Simula, Eiffel ºi C++ se bazeazã pe implementarea de TAD_uri. Un TAD constã din douã pãrþi: specificarea sintacticã ºi setul de axiome. Specificarea sintacticã conþine informaþii despre nume, domenii ºi spaþii ale valorilor ataºate tipului , în timp ce axiomele definesc sensul operaþiilor prin enunþarea relaþiilor dintre ele. Specializarea, generalizarea ºi moºtenirea Acestea sunt concepte intercorelate des utilizate în dezvoltãrile de soft orientate spre obiecte .

7

Specializarea ºi generalizarea Specializarea ne permite sã derivãm clase care preiau toate proprietãþile unei clase date (clasã de bazã) , dar care mai conþin ºi stãri ºi operaþii specifice. Între clasa de origine ºi specializarea ei (subclasa sau clasa derivatã) apare o relaþie de moºtenire. Pentru a specifica aceastã moºtenire (faptul cã specializarea conþine toate proprietãþile clasei din care derivã) se foloseºte cuvântul ESTE. Astfel pentru a specifica faptul cã un cititor este un fel de persoanã, vom spune cã “un cititor ESTE o persoanã”. Analog putem spune cã: Un delfin ESTE un mamifer; Un proiect intern ESTE un proiect; Un triunghi ESTE un poligon, s.a.m.d. Generalizarea este opusã specializãrii: adicã dacã B este o specializare a lui A, atunci A este o generalizare a lui B. În ce priveºte moºtenirea, existã douã forme de moºtenire: moºtenirea simplã – când o clasã are o singurã clasã de bazã ºi moºtenirea multiplã - când o clasã poate avea douã sau mai multe clase de bazã. În 95% dintre cazuri moºtenirea multiplã, deºi existã, nu este necesarã ºi trebuie evitatã pentru cã ne complicã programele. Agregarea apare atunci când un obiect conþine în structura sa mai multe obiecte componenet. De exemplu un poligon presupune o listã de puncte, data calendaristicã presupune specificarea zi, lunã, an, s.a.m.d. Aºa cum relaþia de moºtenire se poate reprezenta prin cuvântul ESTE, relaþia de agregare se poate reprezenta prin expresia PARTE A. Existã agregate fixe (cu structurã fixã cum este data), agregate variabile (de ex. stivã, liste, cozi, etc.) ºi agregate recursive (când starea unui agregat poate conþine componente de acelaºi tip: de exemplu clasa articoleleor publicate într-o revistã cu articolele din alte reviste la care se face referire în articolele primei reviste. Expresia PARTE A poate însemna dupã caz: componentã_întreg, material_obiect, porþiune_obiect, loc_arie, membru_mulþime, membru_parteneriat. Polimorfism Polimorfismul în general înseamnã mai multe forme sub care se poate prezenta ceva plecând dela aceeºi structurã (cazul cristalelor polimorfe), dar în informaticã înseamnã cã obiecte diferite pot înþelege în felul lor aceeaºi informaþie. De exemplu Design mode va duce la lansarea ferestrei de declarare a câmpurilor unui tabel, dar în cazul interogarii va duce la deschiderea grilei, în cazul formularelor la deschiderea ferestrei cu benzi, º.a.m.d.

8

În programare, polimorfismul trebuie nuanþat cu ºi mai multã grijã. Astfel existã polimorfism parametric (de exemplu o funcþie – în sensul de subprogram - poate fi aplicatã uniform unui spectru de tipuri; astfel funcþia LEN poate calcula dimensiunea pentru o listã de elemente de un tip arbitrar), polimorfism de incluziune, polimorfism ad-hoc, polimorfism universal. Polimorfismul ad-hoc se poate întâlni sub forma redefinirii ºi sub forma coerciþiei (de exemplu o funcþie aºteaptã un argument de tip Double ºi primeºte unul de tip Integer. Dacã funcþia stie sã converteascã automat argumentul de tip Integer în Double, ea dã dovadã de polimorfism ad-hoc). 3. Procesul software orientat spre obiecte