CATEGORII DOCUMENTE |
CONCEPEREA SI REALIZAREA UNUI SISTEM INFORMATIC (eventual FINANCIAR BANCAR)
Indiferent de metoda sistemica pe care o folosim, documentatia de proiectare trebuie sa urmareasca modelul sistemului informational pe cele trei nivele ANSI/SPARC:
- extern (asa cum este vazut sistemul de utilizator);
- conceptual (realitatea modelata prin prisma entitatilor, asocierilor si prelucrarilor de date);
- intern ( asa cum este organizat fizic sistemul in calculator/calculatoare).
Din analiza situatiei la nivel extern se obtine modelul conceptual si apoi cel logic. Intre modelul conceptual si cel logic unele metode ca MERISE adauga si modelul organizational. Alte metode dezvolta modelul logic direct pe nivelul organizational, adica combina modelul organizational cu cel logic.
Indiferent de metoda sau metodologia de proiectare pe care o folosim, in afara de modelele datelor si prelucrarilor, documentatia de proiectare trebuie sa contina si urmatoarele informatii:
a) pentru etapa de analiza
- obiectul de activitate al societatii comerciale sau intreprinderii analizate;
- structura organizatorica (organigrama structurii organizatorice);
- obiectivele firmei, functiile specifice, atributele conducerii si modul in care sunt derulate activitatile ei, mediul extern in care lucreaza;
- domenii de activitate, definirea subsistemelor informatice si/sau aplicatiilor;
- informatiile de care au nevoie persoanele din unitate pentru exercitarea sarcinilor ce le revin;
- legislatia in vigoare specifica domeniilor de activitate din intreprindere;
- cand, cum, de catre cine si ce date circula, se transforma sau se inregistreaza;
- ordinea de prelucrare si dependenta dintre datele trecute prin diverse activitati desfasurate;
- regulile prin care se specifica si modul in care sunt transmise si prelucrate datele;
- politicile si orientarile care descriu modul in care se desfasoara activitatea unitatii, tinandu-se cont de mediul si piata in care functioneaza;
- evenimentele marcante si momentele declansarii lor, prin care se schimba valoarea datelor;
b) In etapa de proiectare logica:
- documentele de iesire pe tipuri, machetele lor si cui sunt destinate;
documentele de intrare, machetele lor, propuneri de adapatre la prelucrarea automata a datelor;
- lista unitatilor functionale (procedurilor logice) impreuna cu organigramele acestora;
- machetele formularelor (formatelor) folosite la prelucrarea datelor;
- macheta meniului principal si/sau diagrama arborelui meniului principal (pg. 108 din carte)
c) In etapa de proiectare fizica:
- lista unitatilor de prelucrare (procedurilor automate);
- diagramele de structura din care sa rezulte ordinea apelarii unitatilor de prelucrare (pg 140 carte)
machetele casetelor de dialog specifice procedurilor impuse de siguranta si securitatea datelor;
- schemele de sistem (pg. 161 din carte)
Daca se aplica metoda MERISE se vor derula etapele din tabelul de la pg. 15 unde sunt specificate conceptele specifice fiecarei etape divizate pe viziuni (views).
Pentru detalierea conceptelor specifice fiecarei etape din tabel, in continuare se fac referiri la fiecare etapa a metodei Merise (exemple de aplicare a acestei teorii se pot vedea in lucrarile de laborator 9-11 din "Laborator si ghid interactiv pentru proiectarea sistemelor informatice" unde se prezinta cazul unei case de schimb valutar):
Modelarea globala (MG)
a) Descrieri si definitii
- studierea cadrului legislativ in care-si desfasoara activitatea unitatea studiata;
- descrierea functiilor/domeniilor specifice unitatii studiate;
- definirea activitatilor, subactivitatilor si operatiilor incluse in fiecare domeniu. In conceptia Merise, o unitate este structurata pe functii, domenii, activitati, subactivitati/procese, operatii complexe si operatii simple. De exemplu functia servicii financiar-bancare, domeniul credite bancare, activitatea acordare credite bancare, procesul analiza solicitarii si rambursarii creditelor bancare, se poate descompune in operatii complexe (analiza cererii de credit, analiza deciziei de creditare pe termen scurt, inregistrarea creditelor acordate, rambursarea creditului si inregistrarea rambursarii creditului), iar fiecare din aceste operatii complexe se poate descompune in operatii elementare, conform machetei de mai jos:
Functia Domeniul Activitatea Procesul |
Operatii |
|
Complexe |
Elementare |
Solutia globala pentru realizarea si administrarea unui SI trebuie sa tina seama de factori endogeni si exogeni in raport cu activitatea unitatii economice, de considerente financiare, umane, organizationale, conjuncturale, informationale, manageriale si ca urmare, cel putin teoretic, ar trebui sa existe si un model matematic de optimizare a acesteia.
b) Comunicatiile din SI
- descrierea sistemului de organizare: definirea de ansamblu a comunicatiilor la nivelul structurii de organizare;
- definirea solutiilor globale si previzibile de organizare a comunicatiilor de date si de prelucrari (comunicatii locale sau dupa caz comunicatii on-line cu alte unitati);
- specificarea generala a comunicatiilor viitoare (instalare de workstations sau implementarea unei retele);
c) Viziunea asupra datelor
- definirea obiectivelor manageriale si functionale ale sistemului (vezi pg.54);
- definirea intrarilor si iesirilor in concordanta cu obiectivele stabilite.
Se poate intocmi un tabel cu rubricile:
activitate, obiective manageriale, obiective functionale, iesiri solicitate si
intrari necesare (vezi clasificarea iesirilor la pag. 59)
d) Viziunea asupra prelucrarilor
- definirea subsistemelor informatice si aplicatiilor informatice (vezi pg.10);
- descrierea conexiunilor dintre subsisteme /aplicatii in scopul asigurarii functionalitatii sistemului realizat (vezi, pg.9).
Modelarea conceptuala (MC)
Modelarea conceptuala se mai numeste studiu de detaliu sau conceptual.
Ea prezinta specificatii functionale care sa asigure acordul intre cerintele utilizatorului si solutiile ce se vor adopta. Nu face referiri la tehnica de calcul, organizarea datelor sau prelucrarea acestora. MC asigura o solutie stabila careia ii vor corespunde una sau mai multe solutii concrete organizationale, logice si fizice elaborate in etapele viitoare.
a) Descrieri si definitii la nivel conceptual
- stabilirea functiilor/domeniilor sau activitatilor informatizabile autonome; in cadrul acestora se identifica un sistem de conducere, unul informational si unul operant;
- stabilirea intrarilor sistemului pe tipuri: off-line (documente de intrare) si on-line; se vor intocmi tabele cu documente avand structura: cod document, denumire, frecventa, ce informatii contine (casete de editare texte); pentru fiecare document se va intocmi macheta, precum si un tabel ale carui coloane sunt chiar denumirile campurilor avand specificate pe randul urmator tipul campului si dimensiunea;
- stabilirea iesirilor (rapoarte, grafice, indicatori sintetici, iesiri catre alte sisteme). Pentru fiecare raport sau grafic se va prezenta macheta si dispozitivul de iesire, iar unde este cazul si algoritmii de calcul precum si reguli de disciplina informationala concretizate in specificatii legate de modul practic de utilizare a unui raport (functia, activitatea, compartimentul beneficiar, numarul de exemplare, frecventa, termen, dispozitiv periferic de iesire, etc.);
- sistemul de codificare (tabel cu coduri sau dupa caz, formule pentru coduri); coduri standard. (vezi pg. 64)
b) Modelul conceptual de comunicatii (MCC)
Foloseste concepte specifice ca: actori, fluxuri, diagrame de flux, matrice de flux, diagrama conceptuala de flux.
Diagramele de flux materializeaza actorii, legati intre ei cu sageti pe care sunt trecute simbolurile documentelor, iar langa simboluri se trece in paranteza numarul curent al operatiei in tabelul ce insoteste diagrama. Acest tabel contine rubricile: nr. de ordine, actorul, descrierea actiunii acestuia (fluxului realizat), documente/situatii folosite. In diagrama de flux numele actorului se trece in simboluri reprezentate prin cercuri, hexagoane sau patrate.
Matricele de flux contin actorii, atat pe orizontala cat si pe verticala, iar la intersectie se trec simbolurile documentelor care ii leaga ( de ex. BC bilant contabil, sau SS situatia stocurilor si cheltuielilor). Pe diagonala principala sunt marcate fluxurile interne. Celelalte sunt fluxuri externe.
Diagramele conceptuale de flux seamana cu diagramele de flux, dar pe sageti nu contin simboluri de documente, ci numarul pasului din compunerea algoritmului referitor la circuitul informational reprezentat de diagrama. Un astfel de algoritm este in fapt reflectarea unor prevederi legale sau tehnice referitoare la modul de desfasurare a activitatii analizate. Pasul descrie in cuvinte cine si ce trebuie sa faca.
c) Modelul conceptual de prelucrare (MCP)
Se bazeaza pe conceptele: actori, evenimente/rezultat/mesaje, operatie, sincronizare, procese, reguli de verificare, reguli de sintaxa, reguli de functionare. Pentru fiecare concept exista simboluri, iar dintr-un ansamblu de actori, evenimente/rezultat/mesaje, operatie, sincronizare poate rezulta o operatie complexa, care poate fi reprezentata cu un simbol general ca in figura de mai jos. Deoarece procesele sunt ansambluri structurate de operatii complexe, ele pot fi reprezentate prin lanturi formate din astfel de simboluri, pe baza faptului ca rezultatele emise de la o operatie vor fi evenimente de intrare pentru urmatoarea operatie.
EVENIMENTE DE INTRARE
[nume actor] [ nume tip de [nume tip de
eveniment] eveniment]
[expresie
sincronizare logica]
[nume de operatie complexa]
Operatie - elementara - 1
OPERATIA .
.
Operatie - elementara - N
[Ecuatia de [Ecuatia 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) si intocmirea bazei de atribute.
In continuare se intocmeste matricea dependentelor si apoi se poate intocmi MCD ca in exemplul de mai jos (vezi Concepte de baza pag.11)
MCD se aseamana cu diagramele entitate-relatie (vezi figura alatu-rata ) si sunt
insotite de regula, de un tabel de descriere a MCD cu o rubrica numita
Descrierea tipurilor de entitati si alta Descrierea tipurilor de relatii;
prima este divizata in Tipul de entitate si Tipul de proprietate, natura,
lungime, iar a doua in Tipul de relatie, Cardinalitate si Colectia. Vezi
reguli referitoare la MCD, dependente functionale si normalizarea (pag.31).
Practic MCP se va intocmi dupa MCD.
entitati
CLIENTI tip relatie CONTRACT
cheie primara 1,n incheie 1,1 cheie primara
lista atribute: valoare credit lista atribute:
de ex. adresa procent dobanda
1,n tip atribut entitate
tip relatie RAMBURSARI
achita 1,1 numar OP# cheie primara
suma data OP tip atribut
tip atribut
cardinalitate minima si maxima
EXEMPLU DE DIAGRAMA MCD
Modelarea organizationala (MO)
MO vizeaza repartitia organizationala a sistemului informational (arhitectura si localizarea fizica a retelei de calculatoare, solutia bazei de date) prin prisma departamentelor, serviciilor si posturilor de lucru. Nu are in vedere particularitati tehnice. Trebuie sa indeplineasca criterii economice, organizatorice si de ordin social.
MO raspunde la intrebarile cine?, unde?, cand?. Din MO trebuie sa rezulte:
- organizarea previzibila diferentiata pe departamente/servicii/posturi de lucru privite ca centre de activitate;
- circulatia informatiilor intre aceste centre de activitate;
- sarcinile si cronologia ce vor fi realizate la nivelul fiecarui post de lucru.
a) Modelarea organizationala a prelucrarilor (MOP)
MOP are ca sursa evenimentele si rezultatele-mesaje provenite din MCP si asigura transformarea evenimentelor in subtipuri de evenimente si a rezultatelor-mesaj in subtipuri de rezultate-mesaj. Se utilizeaza conceptele de post de lucru, sarcina, evenimentul si rezultatul-mesaj, sincronizarea, resursele, faza, proceduri organizationale, reprezentare grafica a MOP, concepte aditionale si constructia MOP. Resursele se pot grupa in:
factorul uman;
resurse organizationale: departamente, servicii sau ghisee;
resurse informatice si/sau de telecomunicatii: videoterminale, imprimante, colectii de date, proceduri automate, faxuri/modemuri;
resurse de timp: termenele, succesiunea fazelor si a sarcinilor.
Sarcina este un ansamblu de activitati elementare avand acelasi scop. Operatiei complexe din MCP ii corespunde in MOP faza. In MCP operatiile complexe se descompun in operatii elementare, iar acestora le corespunde in MOP, sarcina.
Sarcinile sunt caracterizate prin: post de lucru (unde li se asociaza resurse umane si informatice), grad de automatizare (manual, conversational/interactiv si automatizat), timp de raspuns si mod de functionare (unitar, de tip lot). Sincronizarile vizeaza operatii de tip logic cu evenimente: ex. verificare data ordin de plata + stampila + semnatura autorizata.
Procedura organizationala (PO) vizeaza un ansamblu logic si legal de evenimente tip, apelul evenimentelor initiale ale procedurii, sincronizarile si obtinerea tuturor rezultatelor tip. MOP se materializeaza intr-un tabel continand coloanele: frecventa (Z, d, l, etc.), actori/posturi de lucru sau regrupari de actori si tipul serviciului. Cu exceptia ultimei coloane si a celei dintai, in celelalte coloane este reprezentata grafic cronologia PO, a fazelor si sarcinilor specifice, folosindu-se in acest scop simboluri de tipul celui de mai jos, care pe un rand dat se pune o singura data, in coloana care deruleaza sarcina ce urmeaza in cadrul procedurii. Simbolurile se leaga intre ele cu sageti ce marcheaza continuitatea procedurii.
Daca este cazul, acest tabel poate fi precedat de un alt tabel unde in loc de reprezentari grafice pe actori, se trateaza activitatea pe faze, sarcini aferente, actor implicat, frecventa si tipul serviciilor.
b) Modelarea organizationala a comunicatiilor (MOC) trebuie sa evidentieze:
- locul si rolul fiecarui actor (departament, serviciu, ghiseu, posturi de lucru) sub aspectul legaturilor informationale;
- numarul de aparitii ale fiecarui actor (de ex. un ghiseu apare in 5 exemplare identice);
- resursele necesare fiecarui actor (umane, informatice, linii de comunicatie, timp, secventa si resurse organizatorice: tip actor, numar maxim de aparitii, resursele utilizate, fazele si sarcinile realizate de el). Initial se intocmeste un tabel cu rubricile: numar curent, tip actor, descriere actor (ex. agent economic, ghiseu, clientela, contabilitate clienti), faze realizate (ex. distribuire extrase cont), sarcini (ex. verificare sold curent pe cod client), frecventa (A, L, Z, etc.), tipul fazei. In final MOC rezulta prin inlantiurea simbolurilor de tipul celui de mai jos (si care seamana cu un tabel), completat cate unul pentru fiecare actor, evidentiindu-se legaturile dintre actori cu sageti, eventual de tip frant ( ).
Simbol folosit pentru reprezentarea resurselor organizatorice:
Sectorul Numar tip aparitii |
||
resurse: RU/RI/RC/RT |
||
faza: frecventa |
sarcina 1 sarcina 2 |
Tipul |
c) Modelarea organizationala a datelor (MOD) Se pleaca de la MCD si se urmareste:
- alegerea proprietatilor ce vor fi memorate;
- specificarea volumului informatiilor memorate;
- repartitia organizationala a datelor prin tipuri de unitati organizationale; se specifica fiecare proprietate si entitate memorata.
MOD se defineste la nivel global derivat din MCD, dar si la nivel local pentru fiecare tip de unitate organizationala. Merise ofera metode pentru calculul cardinalitatii medii (m) si a volumului datelor, cu care se calculeaza in final coeficientul de participare (P) ca raport al numarului maxim de realizari pe fiecare din cele doua entitati aflate in relatie. Valorile simbolurilor m si P apar scrise pe liniile de legatura din diagramele de tip DER., in timp ce cardinalitatile minime si maxime apar sub aceste linii.
Dam mai jos un exemplu de MOD la nivel global.
MOD local se poate reprezenta grafic pe cel global, delimitand zonele fiecarui compartiment beneficiar cu linii intrerupte (a se vedea cadrele punctate - pentru serv financiar si ghiseu si cele cu liniute pentru serviciul clientela; al treilea, nemarcat pe desen, destinat serviciului credite, ia totul, mai putin relatia 'incheie'). Se poate reprezenta si tabelar, intr-un tabel cu rubricile: MOD locale, Tipuri de entitati, (care este defalcat pe tipuri de entitati) si Tipuri de relatii (care este defalcat pe tipuri de relatii). In acest tabel, daca o entitate sau o relatie apartine unui MOD local, la intersectie se pune o steluta.
BANCA CLIENTI
1,n lucreaza 1,1 1,n
cif # nr. cont cif #
denumire sold denumire
adresa adresa .
capital social 1,n
forma propr.
1,1 ramburseaza incheie
suma valoare contract
obiect plata 0,n 1,1 clauze
pPLATI
Contract credit
nr_do #1,1 nr_co #
data_dp data_co
. . .
Pentru exemplul de mai sus, tabelul va contine in prima coloana cate un rand pentru MOD local serviciul clientela, MOD local serviciul credite si MOD local serviciul financiar si ghiseu. Coloana a doua va fi defalcata pe rubricile Banca, Clienti, Contracte si Plati, iar coloana a treia va fi defalcata pe lucreaza, ramburseaza si incheie. Toate relatiile MOD locale sunt definite in functie de tipurile de entitati, proprietati si relatii din MOD global, de structura informationala a iesirilor sistemului si de compartimentele beneficiare ale acestor iesiri. Dupa elaborarea MOD global, aceste elemente sunt amplasate intr-un tabel cu campurile: tip atribut, MOD global divizat in entitati si relatii implicate in MOD global, iesiri + compartimente. Ultima coloana din acest tabel este divizata pe iesiri, sub care se specifica serviciul care beneficiaza de iesirea respectiva. Daca un atribut se regaseste intr-o coloana, atunci intersectia acelui atribut cu coloana respectiva se marcheaza cu steluta.
Estimarea securitatii datelor defineste restrictiile: nici un fel de acces, creare (C), citire (R), modificare (M) si stergere (D). Exista securitate intraunitati, ce defineste accesibilitatea unui anumit tip de utilizator si securitate inter-unitati ce definste datele specifice partajate si protejate. Unitatile organizationale pot avea acces la datele partajabile de urmatoarele tipuri: creare sau stergere, partajabile la consultare, actualizare, fara restrictii de acces. Practic se definesc pentru fiecare (UO) date particulare si date protejate ca in figura de mai jos.
U0 - serv. clientela U - serv. credite
D1 Dpc1 Dpc2 D
(date (date
particulare) Da Da particulare)
Modalitatile de acces se pot reprezenta si tabular ca in tabelul urmator:
Tipuri de entitati si relatii |
Unitati organizationale |
||
Clienti |
Credite |
Financiar |
|
BANCA lucreaza CLIENTI incheie CONTRACTE PLATI ramburseaza |
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 si definitii organizationale
i. Verificarea coerentei date - prelucrari: se foloseste o grila de coerenta globala prin care se poate confrunta MCD cu MOD si MOP. Practic se verifica daca sarcinile descrise in MOP dispun de datele corecte si necesare, adica se verifica modul in care tipurile de entitati si de relatii din MCD sunt utilizate in functionarea sarcinilor MOP.
O astfel de grila este reprezentata mai jos unde, pentru actiunile elementare utilizabile in verificarea coerentei MCD/MOD + MOP se folosesc urmatoarele prescurtari:
MAN - manual, CRE - creare, CIT - citire, MOD - modificare si ST - stergere:
MOP sarcini |
MCD + MOD - tipuri de entitati + relatii |
||||||
tipuri de entitati |
tipuri de relatii |
||||||
Banca |
Clienti |
Contr |
Plati |
lucreaza |
ramburseaza |
inbcheie |
|
verificare cerere credit |
CRE |
CRE |
CRE | ||||
Admitere cerere credit |
CIT |
CIT | |||||
Incheiere contract credit |
CIT |
CIT |
CRE |
CIT |
CRE | ||
Rsmbursare credit |
CIT |
CIT |
CIT |
CRE |
CIT |
CIT |
CRE |
Urmarirea rambursarii 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 interfata cu evenimentele declansate in MOD. De ex. evenimentul contract client contine odata mesajele: cif client, denumire, adresa si data cererii, dar de mai multe ori tip credit, obiect credit, valoare credit, clauze credit, termen de recuperare.
iii. Regulile de prelucrare (RP) exprima algoritmii si conditiile utilizate in derularea sarcinilor din MOP. Ele sunt expresii aritmetice si logice integrate intr-o structura de calcul asociata unei sarcini, ca in tabelul de mai jos:
Structura RP |
Structurile de control utilizabile in RP |
variabile: proprietatile/atributele externe |
bloc (secvential) |
constante: proprietatile/atributele cu valori fixe |
alternativa |
operatori aritmetici: =,<>,=>,=<, >,< |
repetitiva |
operastori relationali: SI, SAU, NU. |
4. Documentatia etapei de modelare logica
Modelarea logica are rolul de a initia realizarea sistemului informational informatizat (SII) sub cele patru aspecte fundamentale folosite de catre metoda MERISE: descrieri-definitii, comunicatie, date si prelucrari. Modelarea logica incepe sa tina seama de alegerile tehnice specifice SII cum ar fi: repartitia datelor si a prelucrarilor, rolul postului de lucreu, arhitectura SGBD, rolul arhitecturii client-server etc. Aceasta modelare logica realizeaza concret urmatoarele elemente specifice:
Descriere |
Comunicatie |
Date |
Prelucrari |
■alegerea solutiei tehnice ■dictionarul atributelor ■ordinea de actualizare BD/BT ■descrierea BD/BT |
MLC - modelul logic de comunicatie |
MLD - modelul logic de date |
MLP - modelul logic de prelucrare |
Modelarea logica are un domeniu specific, descris sintetic in figura de mai sus. Acest tip de modelare asigura si doua decizii fundamentale:
alegerea tipului de sistem electronic de calcul (SEC) folosit in codul SII;
alegerea solutiei de gestiune a datelor:
- baza de date locala (BDL)
- baza de date centrala (BDC)
- solutie mixta cu BDL si BDC
- BD gestionata prin SGBD
- BD gestionata prin EXCEL
- BD gestionata prin SGBD si EXCEL
4.1. Descrieri si definitii la nivel logic
Sistemul informational informatizat (SII) presupune utilizarea unui sistem electronic de calcul (SEC) de mare putere si a unui sistem de gestiune a datelor (SGD) capabil sa asigure toate operatiile de prelucrare specifice unui OFB. In cadrul modelarii logice, se pune problema alegerii celor mai performante SEC si SGD, aceasta alegere facandu-se in functie de urmatoarele criterii:
volumul datelor de prelucrat;
tipologia prelucrarilor: centralizata si/sau distribuita;
efortul financiar implicat;
timpul de raspuns solicitat catre OFB;
natura prelucrarilor specifice SII.
Alegerea unui SEC se poate baza pe trei solutii de referinta:
□ Solutia cu PC-uri independente(locale) utilizate independent unele de altele, transferul de date facandu-se off-line (prin schimbul de fisiere stocate pe hard-disk sau deschete).
□ Solutia cu retele de calculatoare (RC); aceasta solutie cu RC poate utiliza trei tipuri de arhitectura:
▪ arhitectura de tip LAN (local area networks - retele locale). RC de tip LAN pot fi, in principiu, de urmatoarele topologii: topologia stea, topologia inel, topologia magistrala (bus), topologia arbore, topologia inel dublu, topologia inel configurat ca stea, topologia plasa, topologia stea ierarhica.
▪ arhitectura de tip RC mare, diferentiata in trei topologii de referinta: RC de tip WAN - wide area networks (retele extinse); RC de tip MAN metropolitan area networks (retele metropolitane); RC de tip GAN - global area network.
□ Solutia mixta este bazata pe combinatii de PC-uri locale si RC, astfel incat sa se asigure integral prelucrarile sistemului informatic.
Utilizarea acestor tipuri de RC aduc mai multe tipuri de avantaje:
a) avantaje strategice, ca de exemplu - reducerea costurilor privind SII datorita faptului ca RC sunt flexibile, asigurand cresterea volumului si calitatii serviciilor;
b) avantaje operationale si tactice, ca de exemplu - administrarea cat mai eficienta a programelor se realizeaza in special pe arhitecturile client-server, in cadrul carora resursele logice (programeme) sunt stocate fie pe file-server, fie pe PC-ul utilizatorului;
c) avantajele utilizatorului, ca de exemplu - facilitarea accesului la instruire al utilizatorilor se poate realiza printr-un sistem de asistenta (help) prezent in fiecare aplictie sau chiar prin lectii interactive dedicate diferitelor categorii de utilizatori.
Alegerea unui sistem de gestiune a datelor (SGD) are in vedere trei componente esentiale:
a) Sistemul de operare (SO), care poate fi selectionat in functie de solutia cu PC-uri locale (de exemplu: DOS.xx, WINDOWS xx etc.) sau de solutia cu RC (exemplu: NOVELL xx, WINDOWS x.xx etc.).
b) Sistemul de gestiune a datelor (SGD) presupune trei posibilitati:
-SGD bazat in exclusivitate pe un SGBD
-SGD bazat in exclusivitate pe utilizarea tabelelor electronice de calcul (spreadsheets) gestionate prin EXCEL, LOTUS, QUATTRO etc.
-SGD mixt, cu posibilitatea interconexiunii dintre un SGBD si un spreadsheet.
c) Alegerea tipului de BD:
■ BD ierarhica si BD de tip retea au la baza modelul ierarhic, respectiv cel de retea de date.
■ Modelul relational si BD relationale au la baza organizarea datelor sub forma unor tablouri bidimensionale denumite tabele de date sau relatii.
■ BD orientate pe obiecte (BDOO) beneficiaza de un model de date orientat pe obiecte ce are la baza notiunea de entitate conceptuala, definita ca un obiect descris printr-o colectie de proprietati.
■ BD functionale (BDF) au la baza modelul functional al datelor (MFD) bazat pe utilizarea unor limbaje ce folosesc principiile programarii functionale.
■ BD deductive (BDDC) folosesc conceptul de baza de date inteligenta (BDI) deoarece se asigura o gestiune materiala a datelor, pentru memorarea, accesarea si utilizarea informatiilor.
4.2. Dictionarul atributelor
Dictionarul atributelor (DA) este un instrument informatic prin intermendiul caruia se stabilesc identificatorul unic, tipul, lungimea si conditiile de validare pentru toate atributele BD. Acest DA poarta si denumirea de metabaza de date.
Prin dictionarul atributelor sunt stabilite toate detaliile descriptive ale fiecarui atribut, indiferent de apartenenta sa la un anume tip de entitate sau relatie. Astfel, pentru fiecare atribut din nucleul atributelor se stabilesc identificatorul asociat in mod unic la nivelul intregii BD, tipul, lungimea si conditiile de validare, toate aceste elemente fiind stabilite in functie de cerintele si restrictiile impuse de SGD (deci de catre sistemul de operare si SGBD).
Elementele specifice ale dictionarului atributelor sunt urmatoarele:
a) Identificatorul atributului este un nume unic asociat acestuia, prin intermediul caruia atributul poate fi descris si manipulat la nivelul BD. Identificatorul atributului are un format liber in anumite SGBD, in timp ce in altele este supus unor restrictii stricte. Principalele restrictii impuse de SGBD pentru identifiactorul unui atribut sunt, in principiu, urmatoarele: lungimea maxima 10 caractere alfanumerice, nu poate fi un cuvant rezervat al SGBD gazda, nu poate contine caractere speciale (!,?,$,<,=,> etc.) cu exceptia caracterului '_', denumit liniuta de subliniere (underline).
b) Tipul si lungimea atributului indica natura datelor stocate prin identificatorul respectiv si numarul de caractere asociate acestuia. Aceste elemente se preiau din nucleul atributelor determinat prin modelarea conceptuala.
c) Conditiile de validare indica restrictiile pe care trebuie sa le indeplineasca valorile reale ale unui tip de atribut pentru a fi admise in BD. Aceste conditii de validare pot fi determinate in functie de: tipul si lungimea atributului, lista valorilor reale pe care le poate lua atributul respectiv, posibilitatile de validare prescrise de SGBD.
Conditiile de validare pot fi: aplicate asupra unui tip de atribut, stabilite intre atribute, determinate in raport cu o constanta, precizate printr-o lista de valori, stabilite in raport cu un algoritm de calcul, determinate ca urmare a folosirii unor functii matematice sau financiare.
4. Modelul logic de comunicatie (MLC)
Modelul logic de comunicatie (MLC) are rolul esential de a determina arhitectura optima a unei retele de calculatoare (RC) in functie de MOC si de particularitatile modelarii logice. MLC trebuie sa fie in concordanta cu alegerea optima a configuratiei RC determinata prin modelul matematic asociat.
MLC poate fi particularizat in functie de urmatoarele elemente fundamentale:
- MLC trebuie sa fie definit in raport cu modelul de referinta OSI (Open System Interconection), model care are la baza principiul "divide et impera" (dezbina si stapaneste). In mod particular, acest model se numeste ISO/OSI, fiind definit de catre Organizatia Internationala pentru Standarde (ISO). Modelul ISO/OSI este organizat pe sapte nivele (figura urmatoare) si are la baza urmatoarele principii:
- fiecare nivel este determinat de o functie exacta;
- functia fiecarui nivel este determinata in functie de folosirea protocoalelor standardizate cu caracter informational;
- fiecare nivel este adaugat atunci cand se impune un nou nivel de complexitate.
7 6 5 4 3 2 1
- MLC poate folosi
cu preponderenta RC de tip LAN (local area networks - retele locale)
Nivelul
Modelul ISO/OSI pentru RC |
Prezentare
Sesiune
Transport
Retea
Legatura de date
Fizic
MLC presupune existenta unei RC de tip LAN organizata conform unei configuratii specifice unui anumit tip de LAN, formata din:
- calculatoare compatibile IBM denumite generic statii de lucru (work station);
- echipamente specifice;
- elemente de conectare.
Intr-o RC aceste statii sunt de doua tipuri:
- un calculator ce supravegheaza intreaga activitate desfasurata la nivelul RC, calculator denumit server de fisiere (file server - FS);
- calculatoare conectate la un mediu de comunicatie dat, prin intermediul carora utilizatorii au acces la FS, calculatoare denumite statii de lucru (work stations - WS).
Alegerea sistemului de operare pentru retele de calculatoare se face in raport cu urmatoarele principii: tipul retelei de calculatoare; tipul procesorului central; particularitatile de prelucrare si gestiune a datelor din SII; gradul de distribuire geografica a prelucrarilor, datelor si utlilizatorilor; natura prelucrarilor specifice noului sistem; tipologia intrarilor si iesirilor sistemului proiectat.
Sistemele de operare (SO) pentru retele de calculatoare se numesc network operating systems (NOS), fiind un set software ce admite, controleaza si monitorizeaza accesul la driverele de disc magnetic, imprimanta, unitati de floppz-disk, unitati CD etc. prezente in arhitectura unui LAN.
NOS intercepteaza si utilizeaza toate cererile de servicii transmise catre servere, fiind reprezentat de un software de natura sa ofere capabilitati multitasking si multiutilizator pentru o retea de calculatoare, asigurand in plus partajarea resurselor si comunicatiei efective.
Mentionam ca NOS determina si clasa de echipamente compatibila cu un LAN si gestioneaza cererile de servicii ale tuturor utilizatorilor din reteaua de calcul.
4.4. Modelul logic de date (MLD)
Modelul logic de date (MLD) este realizat prin conversia MCD/MOD prin intermediul urmatoarei succesiuni:
transformarea MCD/MOD, exprimat in formalismul entitate-relatie, in MLD exprimat in formalismul logic adaptat strict unei SGBD, folosindu-se fie modelul relational de date propus de E.F.CODD, fie modelul navigational propus de CODASYL;
cuantificarea in modelul logic;
optimizarea generala pentru realizarea MLD optimizat, privit ca sursa de obtinere a modelului fizic de date (MED), deci a schemei BD.
Particularitatile modelului relational
Gestiunea datelor de catre un SGBD se poate face prin intermediul a trei modele de date irarhic, retea si relational.
In comparatie cu modelele ierarhic si retea, modelul relational prezinta, in principal, urmatoarele particularitati:
asigura metode si tehnici eficiente de verificare a coerentei si redundantei datelor;
dispune de un suport teoretic puternic din punct de vedere matematic, suport perfectionat continuu;
asigura un grad ridicat de independenta a aplicatiilor informatice in raport cu modul de reprezentare interna a datelor si metodele de acces la date;
ofera posibilitatea utilizarii unor limbaje procedurale, bazate pe algebra relationala, precum si a unor limbaje neprocedurale (declarative) ce folosesc calculul relational;
manipularea datelor se face la nivel de relatie, proprietate ce asigura paralelismul si prelucrarea datelor, inclusiv posibilitatea utlizarii limbajelor SQL;
asigura integritatea si confidentialitatea datelor prin intermediul unor mecanisme flexibile de specificare si manipulare a relatiilor virtuale si restrictiilor de integritate.
Modelul relational are urmatoarele componente:
a) Structura relationala a datelor: datele sunt organizate sub forma unor tablouri bidimensionale (tabele) de date, denumite relatii. Asocierile dintre relatii se realizeaza prin intermediul atributelor de legatura, denumite concret chei primare si chei externe (CP si CE).
b) Elementele de algebra relationala: contin in principal operatorii modelului relational;
c) Restrictiile de integrare ale modelului relational: definesc cerintele pe care trebuiesc sa le indeplineasca datele pentru a fi coerente si corecte in raport cu realitatea pe care o reflecta.
4.5. Modelul logic de prelucrare (MLP)
Modelul logic de prelucrare (MLP) trebuie sa asigure urmatoarele functii:
structura sistemului in componente logice: subsisteme informatice, aplicatii informatice si proceduri logice/unitati logice de prelucrare;
modelarea prelucrarilor la nivel logic prin folosirea unor concepte specifice: centrul de lucru logic, masina logica, unitatea logica de prelucrare/procedura logica, subschema logica de date etc.
Complexitatea unui sistem informatic impune structurarea acestuia in componente logice. Rezulta ca modelarea logica asigura si structura logica a noului sistem, pe baza careia, prin intermediul modelarii fizice, se obtine structura fizica.
Subsistemul informatic este o parte componenta a sistemului informatic prin intermediul careia se automatizeaza o functie asociata unei OFB sau unei operatii decupate dintr-o functie. Aplicatia informatica este o parte componenta a unui subsistem informatic ce asigura informatizarea unei subactivitati specifice. Procedura logica sau unitatea logica de prelucrare este o parte componenta a unei aplicatii informatice, caracterizata prin prelucrari omogene si specifice.
Procedurile logice pot fi determinate in raport cu o serie de criterii, dintre care mentionam:
similitudinea activitatilor desfasurate in cadrul compartimentelor unei aplicatii;
specificul prelucrarilor automate;
frecventa de prelucrare;
structura si semnificatia activitatilor specifice unei aplicatii;
interfata dintre procedurile logice.
5. Modelarea fizica
Modelarea fizica se desfasoara la nivel fizic/operational si are in vedere specificatiile tehnice aferente unui SGBD, realizand practic conversia nivelului organizational in nivelul fizic/operational. Astfel, modelarea fizica abordeaza cele patru nivele de referinta ale metodei MERISE, dupa cum urmeaza:
Descrieri si definitii |
Comunicatie |
Date |
Prelucrari |
▪ utilizatorii SGBD ▪ protectia BDD - integritate - securitate |
▪ MFC - modelul fizic de comunicatie bazat pe: - RC LAN - RC LAN interconectate - RC LAN omogene - RC LAN eterogene multiprotocol - RC LAN la distanta |
▪ MFD - modelul fizic de date in contextul MR - MFD asociat BDL - MFD asociat BDD ▪ Caracteristicile BDD ▪ Modelarea schemei globale ▪ Modelarea fragmentarii ▪ Alocarea pe statiile de lucru ▪ Cererile distribuite si administrarea catalogului BDD ▪ Realizarea videoformatelor de I/E |
▪ MFP - modelul fizic de prelucrare ▪ definirea procedurilor automate (PA) ▪ elementele caracteristice ale PA ▪ criteriile pentru determinarea PA ▪ arhitectura PA ▪ modulele operationale ▪ comunicatia intre PA si module ▪ definirea meniurilor de prelucrare ▪ infrastructura PA: - scrierea PA - determinarea intrarilor - introducerea si validarea datelor - prelucrarea BD - relatiile intermediare - modelarea iesirilor specifice |
5.1. Descrieri si definitii
a) Utilizatorii SGBD
La utilizarea unei retele de calculatoare (RC) in contextul unui SGBD deja modelat, se pune problema definirii tuturor categoriilor de utilizatori, deoarece a integra intr-o RC un anumit calculator (o statie de lucru) presupune de fapt interconectarea cu alte statii de lucru si echipamente periferice, in scopul partajarii resurselor fizice (memorie, periferice, mediu de comunicatie etc.) a MFD si a MFP, precum si comunicarea cu alti utilizatori din RC.
In conditiile utilizarii unui SGBD dezvoltat prin intermediul unei retele locale de calculatoare (RC) si a unei baze de date distribuite (BDD), utilizatorii sunt urmatorii:
■ Utilizatori singulari (US): - utilizatori neinformaticieni (UN)
- utilizatorul operativ (OP)
- supervizorul (SV)
■ Utilizatori de grup (URG): - utilizatori ghisee (UG)
- utilizatori compartimente (UC)
- manageri departamente (MD)
- manager general (MG)
■ Utilizatori de sistem (USI): - administratorul BD (ABD)
- administratorul datelor (AD)
- inginerul de sistem (IS)
- inginerul instalator de retea (IIR)
b) Protectia bazei de date distribuite
Problematica protectiei bazei de date distribuite consta intr-un set de masuri prin care trebuie sa se asigure integritatea datelor (concretizata prin corectitudinea datelor introduse si mani-pulate) precum si securitatea datelor ce blochiaza accesul la BDD pentru persoanele care nu au drepturile aferente.
Protectia BDD are in vedere urmatoarele elemente:
■ Integritatea datelor:
- integritatea semantica;
- controlul accesului concurent la BDD;
- salvarea si restaurarea BDD.
■ Securitatea BDD:
- autorizarea si controlul accesului la date;
- criptarea si decriptarea BDD.
Integritatea semantica vizeaza semnificatia datelor introduse, prelucrate sau furnizate ca iesiri si are in vedere doua restrictii:
a) Restrictii implicite de integritate: sunt cele relative la integritatea entitatii si intergitatea referentiala
b) Restrictii explicite de integritate: sunt folosite in cadrul procedurilor automate pentru a fi activate in momentul exploatarii acestora sau sunt memorate in dictionarul atributelor, de unde sunt folosite automat de catre SGBDR.
Salvarea si restaurarea reconstituie datele BDD intr-o forma consistenta daca au aparut anumite anomalii: functionarea incorecta a SGBDD, defectiuni fizice ale dispozitivelor de memorare, ale sistemului de comunicatie etc.
Scopul fundamental al operatiilor de salvare/restaurare este de a asigura consistenta BDD, definita prin situatia in care rezultatele finale ale executarii tranzactiilor sunt corecte, nici o tranzactie nu este activata sau in lucru, iar restrictiile de integritate semantica implicite si explicite sunt realizate.
Salvarea BDD inseamna realizarea unor copii de siguranta ale continutului fizic al BDD, fie la nivelul fiecarei statii de lucru si al fiecarui mod de prelucrare, fie global, la nivelul intregii BDD, intr-o retea de tip LAN sau WAN.
Salvarea la nivelul global al BDD inseamna:
salvarea schemei globale (MLD sau MFD);
salvarea schemei fragmentarii (SSL sau SSF);
salvarea schemei de alocare.
Salvarea la nivelele locale ale BDD are in vedere:
salvarea fiecarei scheme locale in parte;
salvarea fiecarei BDD pentru fiecare WS (work station - statie de lucru).
Procesul de salvare este concretizat in:
copii ale BDD;
jurnale de tranzactii;
jurnale ale imaginii inregistrarilor BDD.
Restaurarea BD este procesul invers operatiei de salvare, prin care se asigura reconstitui-rea si punerea in functiune a BDD. Restaurarea BDD se poate face automat sau manual.
Restaurarea automata este asigurata de catre SGBDD dupa oprirea si repornirea sistemului in urma aparitiei unei anomalii, astfel incat BDD sa fie adusa intr-o stare consistenta, prin derularea inversa a tranzactiilor inregistrate si finalizate in fisierul jurnal, dar neanregistrate in BDD. Prin procesul de repornire se asigura sincronizarea BDD cu fisierul jurnal prin executarea unui punct de verificare (checkpoint). Acest proces de restaurare este dependent de frecventa punctelor de verificare, BDD putand fi restaurata rapid daca exista o frecventa mare a punctelor de verificare.
Restaurarea manuala cuprinde doi pasi esentiali:
deconectarea tuturor utilizatorilor de la BDD, urmata de realizarea copiei de siguranta, dupa care utilizatorii sunt reconectati la RC, continuandu-se lucrul cu BDD;
efectuarea copiilor de siguranta in mod dinamic, simultan cu continuarea accesului utilizatorilor la BDD, intregul proces de restaurare desfasurandu-se on-line.
Securitatea BDD se asigura prin interzicerea accesului neautorizat la datele stocate prin intermediul unor masuri de protectie umana, software, hardware etc. In continuare vom prezenta cateva masuri de autorizare si control al accesului la date:
a) Izolarea sistemului central de calcul, unde accesul persoanelor sa se faca prin mijloace electronice de identificare.
b) Stabilirea unei parole de acces si a unor coduri de identificare, pentru a se verifica daca utilizatorul poate avea acces la BDD.
c) Securitatea la conectare, prin care utilizatorul isi declara numele pentru a fi recunoscut de file-server.
d) Securitatea prin drepturi diferentiate acordate utilizatorilor are in vedere accesul utilizatorului la un anumit director de lucru. Drepturile stabilesc tipurile de operatii la care utilizatorul are acces prin intermediul directorului de lucru.
e) Securitatea prin drepturile acordate in directoare se refera la drepturile acordate tuturor utilizatorilor pentru un director specificat.
f) Securitatea prin atributele fisierelor si directoarelor are in vedere evitarea modifica-rilor accidentale ale fisierelor, mai ales in situatia fisierelor publice folosite de mai multi utilizatori.
Criptarea este un proces de codificare a BDD in perioada stocarii sau a manipularii, decriptarea putand fi realizata numai de utilizatorii ce detin codul de criptare.
Procesul practic de criptare/decriptare are urmatoarele componente: algoritmul de criptare, cheia de criptare, algoritmul de decriptare, cheia de decriptare.
Decriptarea este procesul invers criptarii, prin care datele criptate sunt readuse in formatul initial, asigurandu-se astfel regenerarea BDD in aceiasi forma cu cea din momentul declansarii procesului de criptare.
5.2. Modelul fizic de comunicatie (MFC)
Modelul fizic de comunicatie (MFC) asigura modelarea fenomenului de comunicatie la nivel operational si are in vedere stabilirea concreta a urmatoarelor elemente:
□ arhitectura fizica a retelei dedicate SGBD in raport cu modelul de referinta OSI;
□ analiza nivelelor specifice modelului de referinta OSI;
□ descrierea modelului de referinta pentru interconectarea sistemelor deschise;
□ descrierea efectiva a MFC axat pe patru variante:
■ MFC bazat pe retele de calculatoare de tip LAN si LAN interconectate;
■ interconectarea de retele LAN de tip omogen;
■ interconectarea platformelor LAN eterogene multiprotocol;
■ interconectarea LAN la distanta.
Modelul fizic de comunicatie (MFC) are de fapt la baza o arhitectura fizica de retea ale carei functii de comunicatie sunt partitionate intr-o structura verticala pe nivele. Fiecare nivel realizeaza un subset de functii de comunicatie necesare comunicatiei cu un alt sistem, in vederea asigurarii functiilor fizice ale unui SGBD. Fiecare nivel se bazeaza pe nivelul imediat inferior in scopul realizarii unor functii elementare si specifice; in plus, ascunde fata de nivelul superior detaliile de implementare ale functiilor executate.
Descrierea MFC cuprinde specificarea tuturor componentelor si particularitatilor fizice ale RC folosite, modul de interconectare practic al calculatoarelor folosite, precizarea caracteristicilor tehnice (memorie interna, unitate centrala, tipurile, mnemonicele si capacitatile suporturilor tehnice externe, locul si rolul WS si FS, conexiunea WS - FS) prin intermediul unei scheme denumita configuratia, arhitectura sau topologia RC.
Deoarece in Romania se folosesc cu preponderenta RC de tip LAN, vom prezenta in continuare particularitatile MFC prin prisma retelelor de tip LAN.
In aceste conditii, pentru MFC exista doua solutii esentiale:
MFC realizat prin RC de tip LAN;
MFC realizat prin RC de tip LAN interconectate.
Solutia cu RC de tip LAN este aplicabila atunci cand in trecerea de la MLC la MFC nu sunt necesari interconectorii de RC, iar prelucrarile au caracter local. Astfel, pot fi alese RC de tip LAN cu topologie de tip star, bus sau ring.
Solutia cu RC de tip interconectat devine viabila in situatia in care SGBD proiectat are prelucrari cu caracter distribuit si sunt necesare conexiuni directe, on-line, intre eventualele sedii, sucursale, filiale etc.
Aceasta solutie poate fi aplicata in trei conditii:
interconectare de RC LAN de tip omogen;
interconectarea platformelor LAN eterogene multiprotocol;
interconectarea LAN la distanta.
5. Modelul fizic de date (MFD)
Modelul fizic de date (MFD) se obtine prin reprezentarea MLD intr-un limbaj de descriere a datelor asociat strict unui SGBD. Practic, un SGBD va utiliza acest MFD pentru ca, prin intermediul MFP, sa poata asigura un ciclu coerent de prelucrare de tip local/distribuit, format in principiu din operatii de creare, actualizare, exploatare, listare, reorganizare, salvare, restaurare, protectie etc.
Rezulta ca un MFD este asociat unui SGBD care are urmatoarele obiective referitoare la date:
neredundanta datelor: acestea sunt integrate de fapt in fisiere ce contin date distincte, reducandu-se astfel problemele legate de cererile de date, actualizare si riscul de incoerenta;
coerenta datelor: poate fi asigurata prin expresia constrangerilor de integritate folosite de catre metoda MERISE, constrangeri ce sunt de fapt folosite de catre toata SGBDR;
partajarea datelor: are in vedere posibilitatea folosorii simultane a datelor fizice de catre mai multe aplicatii informatice prin intermediul unor mecanisme specifice la nivel de SGBD;
securitatea datelor: inseamna protejarea acestora impotriva accesului neautorizat, nepro-fesional, in cadrul operatiilor complexe efectuate asupra BD de catre SGBD.
SGBD are si o serie de obiective organizatorice, dintre care mentionam urmatoarele:
asigurarea unui control riguros asupra datelor;
optimizarea accesului la date;
optimizarea mediilor informatice;
rezolvarea conflictelor intre diversele puncte de vedere ale utilizatorilor;
utilizarea unui administrator al datelor (AD) ce se va ocupa de semantica, valorile reale si aspectele organizatorice impuse de generarea - transmiterea - prelucrarea - distribuirea datelor;
existenta unui administrator al BD (ABD), persoana ce se va ocupa de problemele tehnice ale utilizarii fizice a unei BD locale (BBL) sau a uneia distribuite (BDD).
Arhitectura unui SGBDR asigura organizarea datelor stocate sub forma de tabele. In continuare, un asemenea sistem permite definirea unei scheme relationale ce asigura conversia logic/fizic prin descrierea datelor din diferitele tabele, precum si indecsii de acces la aceste tabele. Alaturi de aceste tabele de date si de index exista si alte structuri complementa-re prin care se asigura integral regulile de elaborare a diferitelor vederi asupra BD. Arhitectura unui SGBDR poate avea diverse componente, diferentiate in functie de firma producatoare.
Exemplu de arhitectura de tipul SGBD SQL/DS (IBM) avand urmatoarele componente esentiale: DSC - data system central: asigura comunicatia SGBDR cu alte programe; RDS - relation data system: asigura prelucrarile cererilor privind analiza, optimizarea si compilarea; DBSS - database storage system: asigura accesul de la RDS, aloca spatiul fizic necesar, asigura accesul concurent si reface BDR in caz de incident sau anomalie.
SGBD foloseste urmatoarele limbaje:
■ Limbajul de descriere a datelor - LDD: asigura descrierea datelor intr-o maniera unica si centralizata, dependenta de un standard utilizat pe scara larga de SGBDR (ACCESS, FOXPRO, PARADOX, CLIPPER, dBASE etc.). In mod curent acest LDD asigura coerenta datelor sub aspectul MFD.
■ Limbajul de manipulare a datelor - LMD: asigura actualizarea si consultarea BD, inclusiv definirea si gestiunea diferitelor obiecte mai mult sau mai putin complexe de tipul ecrane, forme, etichete, cadre etc., privite ca elemente complementare ale utilizarii unei BD.
■ Limbajul de interogare a datelor - LID: reprezinta de fapt un program complementar unui SGBD prin care se propune un limbaj de interogare si de acces la BD, definit si utilizat special de catre utilizatorii neinformaticieni.
Practic, SGBDR comercializate pe piata au implementat limbajul cunoscut sub acronimul SQL - structured query language, propus de catre echipa de cercetare IBM.
Conversia din MLD/MOD in MFD in cadrul formalismului relational se realizeaza astfel:
MLD/MOD |
MFD |
■ relatia/tabelul ■ atributul ■ tip ■ lungime ■ cheie primara ■ cheie secundara ■ cheie externa ■ dependente functionale intre relatii/tabele |
■ relatie/baza de date/fisier/tabel ■ nume camp ■ tip ■ lungime ■ index ■ [index] ■ [index] ■ jonctiune (join)/view |
5.4. Modelul fizic de prelucrare (MFP)
MFP are rolul esential de a asigura functionalitatea SGBD la nivelul operational folosind MFC si MFD, in scopul realizarii de proceduri automate ce pot fi corelate cu procesele de prelucrare specifice noului sistem. In acest sens, procedurile automate devin elemente esentiale ale MFP prin care se asigura intreaga operationalitate la nivel fizic.
Procedurile automate sunt caracterizate prin functii, date de intrare/iesire (I/E) si o logica interna de prelucrare specifica, existand o tipologie adecvata in raport cu care procedurile automate se descompun in module ce implementeaza functiile elementare de prelucrare, deduse din functia generala specifica procedurii automate. Pentru a asigura operationalitatea procedurilor automate, se vor defini prelucrarile necesare, deduse din categoria prelucrarilor specifice aplicatiilor informatice din care fac parte respectivele proceduri automate.
Procedurile automate sunt reprezentate de o colectie de comenzi unitare scrise intr-un LDD si LMD, componente ale unui SGBDR, prin care sunt definite prelucrari specifice asupra diferitelor tipuri de componente ale unei BDR (tabel, interogare, formular, raport), executate in sensul solicitat de catre o sarcina preluata din MLP, in mod parametrizat si fara intreruperi de la un post de lucru; prin aceste proceduri o multime de date de intrare sunt transformate in date de iesire si/sau date intermediare in raprot cu un algoritm de prelucrare sau de calcul, toate aceste elemente fiind memorate impreuna sub un nume unic si o extensie specifica SGBDR.
SGBDR folosesc si alte concepte in raport cu procedurile automate:
dBASE, FOXPRO, CLIPPER folosesc conceptul de procedura;
ACCESS foloseste conceptele de macroinstructiune si modul.
O macroinstructiune (pe scurt macro) este o actiune sau un set de actiuni folosite pentru auto-matizarea unei sarcini, in timp ce modulul este privit ca un set de declaratii, comenzi si proce-
duri memorate impreuna sub acelasi nume si cu o extensie asociata.
Procedurile sunt caracterizate prin urmatoarele elemente:
Functia procedurii: arata modul efectiv de prelucrare a datelor, respectiv sensul general de transformare a datelor de intrare in date de iesire, deci procesele generale si specifice de utilizare a datelor. Pot fi de mai multe feluri: proceduri de dirijare/monitorizare, proceduri de actualizare, proceduri de calcul asupra tabelelor BD, proceduri de reorganizare a BD, proceduri de protectie si securitate a BD.
Intrarile procedurii: reprezinta sursele de date pe care acestea le folosesc pentru asigurarea functionalitatii lor, precum si alte elemente secundare ale structurii unei SGBD cum ar fi: tabele, formulare, interogari etc.
Iesirile procedurii: sunt reprezentate de datele si formatele obtinute ca urmare a unei proceduri si a utilizarii eventual a unui algortim de prelucrare/calcul.
Logica interna de prelucrare: arata modul concret de conversie a intrarilor in folosirea unui algoritm de prelucrare (introducere de date, validare date, conversie, obtinerea unor tabele fizice intermediare, obtinerea unor iesiri etc.) sau algoritm de calcul (calculul incasarilor zilnice, a platilor si a soldurilor al finalul zilei in lei sau in alte valute etc.).
Interfata dintre proceduri: arata legaturile de date si de comunicatie stabilite intre proceduri pe parcursul exploatarii lor, astfel incat iesirile unor proceduri sa poata fi identificate, recunoscute, convertite si utilizate ca intrari intr-o alta procedura prin intermediul unor structuri de date sau eventual meniuri de prelucrare.
ANEXA 1
Detalii cu privire la obiective, iesiri, formalizarea atributelor
si documente de intrare
1. Definirea obiectivelor (se face in etapa MGD)
Obiectivele sistemului informatic reprezinta scopuri imediate si de perspectiva ale perfectionarii activitatii economice si de conducere, in vederea ridicarii nivelului de informare operativa si previzionala a structurilor organizatorice, a perfectionarii metodelor si proceselor tehnico-informationale si de conducere pentru asigurarea maximalizarii efieientei economice si a rentabilitatii unitatii beneficiare.
Obiectivele sistemului informatic presupun abordarea si rezolvarea informatica a unor probleme cu caracter sintetic si analitic, intr-o maniera sistemica, pentru asigurarea scopurilor propuse. Aceste obiective sunt diferentiate in functie de nivelele micro, mezo si macroeconomice avand caracteristici generale si specifice, subordonate cadrului legislativ-normativ, dotarii cu tehnica de calcul si cerintelor dezvoltarii economice, imediate si de perspectiva, a unitatii beneficiare.
Obiectivele sistemului informatic pot fi:
generale ;
specifice.
.Obiective generale
Obiectivele generale ale unui sistem informatic vizeaza probleme cu caracter global ale conducerii unitatii comerciale si structurale specifice compartimentelor functionale, in scopul realizarii atributelor conducerii si ale functiilor unitatilor economice. in raport de aceste aspecte, obiectivele generale pot fi:
- de conducere (manageriale);
- functionale.
Obiectivele de conducere urmaresc aspecte globale de conducere ale unitatii economice, si au in vedere urmatoarele probleme :
- rentabilizarea permanenta a activitatii economice;
- realizarea globala si structurala a indicatorilor economico- financiari (cifra de afaceri, valoarea adaugata, profitul brut si net, capitalul propriu, capacitatea de plata, rata rentabilitatii, eficienta utilizarii fondurilor fixe etc.), calculul si planificarea rezultatelor' planificarea financiara a investitiilor, previzionarea activelor circulante si a surselor de finantare, previzionarea activitatii de trezorerie, inclusiv utilizarea bugetului general al unitatii economice.
- perfectionarea activitatii de conducere in vederea asigurarii unui optim globalla nivelul intregii activitati economice;
- fundamentarea deciziilor de conducere tactica, strategica si operativa pe baza informatiilor obtinute ca urmare a prelucrarilor sistemului informativ;
- asigurarea unei coordonari a intregului sistem informational - decizional;
- utilizarea selectiva a unor informatii de exceptie (rata anuala de innoire a mijloacelor fixe, tendintele preturilor de aprovizionare, etc.), pentru asigurarea unei gestiuni eficiente a patrimoniului net pe baza unor informatii cu caracter programatic si analitic;
- degrevarea conducerii de procesele decizionale de rutina, formalizarea prin noul sistem a informatiilor sintetice necesare derularii relatiilor informationale cu organismele de stat si cu alte regii autonome sau societati comerciale;
- furnizarea intr-o forma adecvata, eficienta si facila a informatiilor globale necesare conducerii unitatii economice, sub forma unor indicatori globali, situatii cu caracter sintetic, grafice, etc., care trebuie sa contina date relevante, prin intermediul afisarii la videoterminal;
- cresterea calitatii procesului decizional prin abordarea sistemica a activitatii unitatii economice si utilizarea modelarii matematice, adoptate sistemelor electronice de calcule;
- extinderea principiului conducerii prin exceptie si pe baza de obiective.
Obiectivele functionale ale unui sistem informatic au in vedere informatizarea activitatilor in conformitate cu anumite functii ale unitatii economice (comerciala, financiar-contabila si de personal), desfasurata la nivelul compartimentelor functionale. Aceste obiective sunt fundamental dependente de specificul activitatii regiilor autonome sau al societatilor comerciale si cuprind urmatoarele deziderate generale:
a) Activitatea comerciala (aprovizionare, desfacere, marketing,) desfasurata in cadrul unor compartimente corespunzatoare are in vedere elementele specifice fiecarei subactivitati din punct de vedere informatic, dupa cum urmeaza:
- Subactivitatea de aprovizionare tehnico-materiala propune rezolvarea urmatoarelor aspecte specifice:
Ø fundamentarea necesarului si a comenzilor de aprovizionat;
Ø contractarea necesarului de aprovizionat;
Ø urmarirea derularii contractelor de aprovizionare.
- Subactivitatea de desfacere a rezultatelor activitatii presupune:
Ø primirea si centralizarea comenzilor de la clienti;
Ø livrarea catre clientii interni si externi a productiei contractate;
Ø urmarirea ritmicitatii livrarilor in scopul onorarii contractelor incheiate.
Subactivitatea de marketing presupune:
Ø
studierea
caracteristicilor tehnico-economice, inclusiv a tehnicilor de comercializare a
produselor concurente, furnizate de alte societati comerciale din
Ø studierea caracteristicilor specifice ale pietelor de desfacere in vederea realizarii relatiilor valutar-financiare si de distribuire a produselor proprii;
Ø
cooperarea
cu alte societati comerciale din
b) Activitatea financiar-contabila (financiar, contabilitate, control financiar) desfasurata in cadrul compartimentelor specifice presupune rezolvarea din punct de vedere informatic a unor elemente specifice, dupa cum urmeaza :
Subactivitatea financiara are in vedere:
Ø Calculul si decontarea tuturor categoriilor de impozite (impozitul pe salariu, impozitul pe circulatia marfurilor sau impozitul pe valoarea adaugata, impozitul pe profit);
Ø elaborarea bugetului general al unitatii economice pe an financiar, cu defalcare pe subunitati;
Ø derularea relatiilor banesti cu bugetul statului, bancile comerciale interne, si externe, inclusiv cu alti agenti economici din tara sau strainatate;
Ø efectuarea si urmarirea decontarilor cu tertii (persoane fizice sau juridice).
Subactivitatea de contabilitate la nivelul unitatii economice se structureaza in doua componente:
Contabilitatea financiara (sintetica) concretizata in urmarirea existentului si miscarii elementelor patrimoniale (imobilizari, stocuri, creante si datorii, mijloace financiare, capital privit sub forma de fonduri, rezerve si finantari, credite, cheltuieli si venituri).
Contabilitatea de gestiune (analitica) poate fi organizata fie prin detalierea conturilor de evidenta a elementelor patrimoniale privite la nivelul contabilitatii financiare (grupele I-VIII), fie prin utilizarea unor conturi de gestiune interna care se organizeaza in functie de necesitatile de informare si conducere ale unitatii economice. Aceasta detaliere urmareste reflectarea stocurilor, veniturilor, cheltuielilor si rezultatelor pe intervalul de gestiune al unitatii economice. Din cele prezentate rezulta ca intreaga activitate de contabilitate asigura:
inregistrarea cronologica si sistematica a tuturor operatiilor economice;
prelucrarea datelor in concordanta cu principiile si metodele contabilitatii;
sintetizarea intregii activitati financiar-contabile prin intermediul instrumentelor de baza ale contabilitatii (balanta si bilantul contabil).
Subactivitatea de control financiar la nivelul unitatii economice urmareste analiza si controlul gestiunii patrimoniului regiei autonome sau soeietatii comerciale prin instrumente proprii in scopul prevenirii si sesizarii incalcarii normelor legale de utilizare a resurselor umane, materiale si banesti.
c) Activitatea de personal (evidenta personalului, salarizare, perfectionarea calificarii salariatilor) desfasurata in cadrul unor compartimente adecvate, cu o pondere dependenta direct de specificul regiei autonome sau societatii comerciale, are in vedere rezolvarea sub aspect informatic a problemelor impuse de existenta, miscarea si scolarizarea personalului angajat, inclusiv aspectele specifice salarizarii,dupa cum urmeaza:
Subactivitatea de evidenta a personalului, presupune:
Ø evidenta existentului si a miscarii de personal pe profesii, functii, nivele de calificare, etc., pe diferite intervale de timp;
Ø atestarea pe profesii, functii si locuri de munca a salariatilor in raport de evolutia specificului activitatii;
Ø verificarea incadrarii personalului pe profesii, functii si locuri de activitate.
- Subactivitatea de salarizare asigura:
Ø evidenta timpului lucrat si nelucrat de salariati; calculul lunar al drepturilor banesti in raport de activitatea depusa;
Ø evidentierea eventualelor imputatii sau popriri pentru rezultatele necorespunzatoare ale activitatii depuse, inclusiv determinarea impozitului pe salariu si alte categorii de retineri.
Subactivitatea de perfectionare a calificarii personalului are o pondere diferentiata in functie de sectoarele de activitate, caracterizate printr-o dinamica accentuata a tehnologiilor utilizate, motiv pentru care se urmareste realizarea sub raport informatic a urmatoarelor cerinte:
Ø analiza raportului dintre nivelul de calificare mediu al personalului angajat si nivelul cerut de tehnologiile de productie utilizate;
Ø urmarirea activitati de scolarizare si de atestare profesionala, dupa finalizarea cursurilor de pregatire;
Ø stabilirea prioritatilor in angajarea a noi categorii de salariati, astfel incat activitatea unitatii economice sa se desfasoare, la cel mai inalt grad de tehnicitate.
.Obiective specifice
Obiectivele specifice ale unui sistem informatic urmaresc rezolvarea unor probleme dependente strict de activitatea de baza (productie, comert, servicii etc.) si de cea auxiliara, in raport de functiile de cercetare si productie. Acestea au un caracter propriu si dependent de rolul unitatii economice in meeanismul economiei de piata. Privite sub acest aspect, obiectivele specifice ule unui sistem informatic pot fi structurate in :
- obiective specifice activitatii de baza;
- obiective specifice activitatii auxiliare.
Obiectivele specifice activitatii de baza urmaresc realizarea sub aspect informatic a tuturor subactivitatilor de cercetare si productie ce constituie specificul activitatii regiei autonome sau al societatii comerciale. Aceste obiective sunt diferentiate (au caracter particular), dar ele se pot incadra intr-o structura fundamentala, prin intermediul careia sistemul informatic trebuie sa realizeze:
- utilizarea eficienta a capacitatilor de productie;
- introducerea de tehnologii si produse noi la nivelul tehnicii actuale;
- realizarea ritmica si de calitate a lucarilor de investitii;
- modernizarea utilajelor si a altor factori de prodctie;
- imbunatatirea continua a calitatii productiei;
- cresterea gradului de utilizare a capacitatilor de productie;
- incadrarea consumurilor de materiale in normele tehnologice;
- utilizarea rationala a capacitatilor de depozitare a materialelor si produselor.
Obiectivele specifice activitatii auxiliare vor avea in vedere realizarea sub aspect informatic a tuturor subactivitatilor secundare, desfasurate in cadrul unitatii economice. Aceste obiective au un caracter particular, o pondere si o importanta diferentiata de la un agent economic la altul, avand ca scop rezolvarea unor aspecte specifice, cum ar fi:
- urmarirea operativa a activitatii sectoarelor auxiliare a caror activitate determina in mod direct desfasurarea activitatilor principale;
- folosirea eficienta a capacitatilor auxiliare de productie;
- robotizarea, paleatizarea si containerizarea activitatilor auxiliare din unitatea economica;
- realizarea programelor de asimilare a noilor produse si de perfectionare a tehnologiilor de fabricatie in scopul generalizarii la nivelul activitatii de baza;
- asigurarea unei colaborari si specializari ale caror rezultate urmeaza a fi incluse in sectoarele de baza ale unitatii economice.
Obiectivele generale si specifice ale unui sistem informatic, pot surprinde si alte aspecte concrete, ce decurg din:
- marimea unitatii economice;
- ponderea acesteia intr-o ramura de activitate;
- gradul de specializare a activitatilor de baza si auxiliare, intr-un domeniu concret al economiei de piata;
- gradul de participare al unitatii economice la derularea unor operatiuni de export-import, cooperare internationala etc., factori ce pot impune si alte tipuri de obiective, a caror nuantare va fi diferita de la o unitate economica la alta.
Obiectivele sistemului informatic trebuie sa asigure:
- utilizarea eficienta si extensiva a sistemelor electronice de ealcul si a retelei de calculatoare-teletransmisie, specifice intregului sistem informatic proiectat :
- cresterea vitezei de circulatie a informatiilor, reducerea ciclului informational si a timpului de raspuns ca urmare a realizarii noului sistem informatic.
- functionarea performanta, in conditii de fiabilitate si stabilitate in timp, a intregului ansamblu de echipamente de calcul, care trebuie sa realizeze:
Abordarea integrala a obiectivelor generale si specifice permite proiectarea unui sistem informatic integrat (total) la nivelul unei unitati economice in conditii de eficienta maxima.
Obiectivele sistemului informatic urmeaza a fi concretizate in iesirile specifice ale acestuia: indicatori economico-financiari, liste/situatii de iesire, grafice, iesiri catre alte sisteme.
2. Iesirile sistemului informatic (se identifica in MGD si se aprofundeaza in MCDD)
Realizarea practica a obiectivelor sistemului informatic se caracterizeaza prin satisfacerea cerintelor informationale ale conducerii si structurilor organizatorice din unitatea beneficiara.
Iesirile sistemului informatic pot fi privite din punct de vedere:
structural;
functional;
tipologic.
Din punct de vedere structural, iesirile sistemului informatic reprezinta a treia componenta din triada ce caracterizeaza structura generala a oricarui tip de sistem: Intrari - Prelucrari - Iesiri.
Din punct de vedere functional, iesirile sistemului informatic concretizeaza obiectivele generale si specifice ale sistemului proiectat.
Din punct de vedere tipologic, iesirile sistemului informatic pot fi redate sub forma de:
- indicatori sintetici privind starea si rezultatele activitatii economico-financiare;
- liste/situatii de iesire care cuprind indicatorii analitici ai starii si rezultatelor activitatii economico-financiare;
- grafice care redau sub forma sinoptica starea si evolutia indicatorilor economico-financiari
- iesiri catre alte sisteme informatice, transmise in direct (off-line) prin intermediul suporturilor magnetice (disc flexibil, disc magnetic,banda magnetica etc.), sau direct (on-line) prin intermediul unei retele locale de calculatoare.
Indiferent de tipologia iesirilor sistemului informatic, acestea trebuie sa respecte cerintele si restrictiile cadrului legislativ-normativ in vigoare, pentru ca activitatea unitatii economice sa se desfasoare in coordonatele legalitatii economice.
2.1. Indicatorii economico-financiari specifici unitatii economice au rolul de a caracteriza din punct de vedere sintetic si analitic activitatea economico-financiara prin intermediul unor informatii care redau:
- patrimoniul net al regiei autonome sau a societatii comerciale prin intermediul inventarierii patrimoniului si a posturilor din bilantul contabil elaborate la finele perioadei de gestiune;
- starea si rezultatele economico-financiare ale unitatii economice pe o perioada determinata de gestiune;
- calculul si planificarea financiara a investitiilor;
- calculul si planificarea rezultatelor economico-financiare;
- calculul si previzionarea activelor circulante si surselor de finantare;
- calculul si previzionarea activitatii de trezorie.
Acesti indicatori au rolul de a concretiza obiectivele generale de conducere si functionale ale unitatii economice, motiv pentru care ei pot constitui rezultatul prelucrarii unui sistem informatic proiectat.
Selectarea concreta a anumitor indicatori din multimea totala a acestora se poate realiza in functie de:
- Tipul unitatii economice (regii autonome, societati comerciale in: nume colectiv, comandita simpla, comandita pe actiuni, societate pe actiuni si societate cu raspundere limitata determina utilizarea nuantata a unor indicatori economico-financiari.
- Specificul activitatii de baza a unitatii economice poate determina utilizarea unor indicatori economico-financiari comuni sau specifici. De exemplu, pentru regiile autonome de extractia petrolului, natura activitatii determina utilizarea unor indicatori specifici, cum ar fi: productia marfa fabricata, productia marfa vinduta si incasata etc., in timp ce la o societate comerciala a carei activitate de baza consta in comercializarea bunurilor de consum, se vor utiliza indicatori .specifici activitatii, cum sunt: valoarea totala a vanzarilor de marfuri, cheltuieli totale cu depozitarea marfurilor, cheltuieli de reclama si publicitate etc.
Mentionam ca ambele categorii de unitati economice mentionate, pot utiliza indicatori economico-financiari comuni, cum ar fi: cifra de afaeeri, capitalul propriu, profitul total realizat, profitul net, profitul folosit pentru autofinantare, capacitatea de plata, rata rentabilitatii, rentabilitatea capitalului etc.
- Complexitatea si volumul activitatii unitatii economice poate impune selectarea anumitor indicatori care sa ofere informatii sintetice sau analitice raportate direct la arrumite aspecte concrete din activitatea unitatii economice.
- Gradul de dispersare a activitatii unitatii economice poate determina utilizarea unor indicatori specifici pe subunitati si in dinamica, astfel incat la nivelul global al unitatii economice, conducerea acesteia sa cunoasca operativ rezultatele intregii activitati economico-financiare.
2.2. Listele/situatiile de iesire reflecta cerintele informationale ale conducerii unitatii economice sau compartimentelor functionale in cadrul obiectivelor generale ale sistemului informatic.
Listele/situatiile de iesire contin un sistem de indicatori economico-financiari, sintetici sau analitici grupati intr-o forma care sa asigure materializarea integrala a obiectivelor propuse.
Listele sau situatiile de iesire trebuie sa reflecte, prin continutul lor, starea si dinamica fenomenelor si proceselor economice care fac obiectul de prelucrare a datelor din sistemul proiectat. Natura prelucrarilor sistemului informatic are un caracter specific in functie de natura activitatii unitatii economice si impune o anumita structurare a indicatorilor economico-financiari in cadrul listelor/situatiilor de iesire.
Determinarea concreta a continutului, formei si a circuitului informational al situatiilor de iesire sunt realizate in functie de natura activitatii, cerintele informationale ale conducerii unitatii economice, obiectivele propuse, cadrul legislativ-normativ (legi, decrete, hotarari, norme metodologice, instructiuni, decizii interne) si cerintele specifice, unitatii beneficiare. Aceste restrictii impun un anumit continut economic al situatiilor inclusiv elementele referitoare la destinatie, utilizare, frecventa si forma concreta in care vor apare.
Listele/situatiile de iesire ce urmeaza a se obtine in cadrul unui sislem informatic pot fi structurate si utilizate in concordanta cu:
- specificul functiilor desfasurate concret in unitatea economica;
- destinatia listelor/ situatiilor de iesire;
- gradul de sintetizare a indicatorilor economico-financiari inclusi in liste/situatii;
- momentul generarii listelor/situatiilor de iesire;
- referinta in timp a acestora;
- modul de obtinere a listelor/situatiilor de iesire etc.
Listele/situatiile de iesire trebuie sa reflecte, prin continutul lor, starea si dinamica fenomenelor si proceselor economice desfasurate efectiv in cadrul unitatii economice beneficiare. Natura prelucrarilor sistemului informatic are un caracter specific determinat de natura activitatii unitatii economice, element care impune o anumita structurare a indicatorilor economico-financiari in cadrul listelor/situatiilor de iesire.
Determinarea concreta a continutului, formei si a circuitului informational specific situatiilor de iesire sunt determinate in functie de:
- natura si complexitatea activitatii desfasurate de unitatea economica;
- cerintele informationale formulate de conducerea unitatii economice beneficiare;
- cerintele informationale formulate de compartimentele functionale implicate in functionarea sistemului informatic;
Continutul informational al listelor/situatiilor de iesire determina modul concret de structurare si ordonare a indicatorilor economico-financiari in raport cu cerintele legislative in vigoare. Aceste restrictii impun un anumit continut concret al listelor/situatiilor de iesire, inclusiv elementele referitoare la circuitul informational al acestora in cadrul unitatii economice benefïciare.
Structurarea situatiilor de iesire se realizeaza in functie de:
- specificul functiilor generale ale unitatii economice;
- destinatia listelor situatiilor de iesire;
- gradul de sintetizare a indicatorilor economico-financiari;
- momentul generarii situatiilor de iesire;
- modul de obtinere.
La definitivarea fiecarei liste/situatii de iesire se recomanda:
- titlul situatiei, care va reda intr-o forma sintetica continutul informational al acesteia si perioada sa de referinta;
- indicatorii prezenti in fiecare coloana cu specificarea:
- algoritmul de calcul(daca este cazul);
- natura si lungimea maxima a fiecarui indicator;
- gradele de total si subtotal;
- numarul de exemplare, destinatia fiecarui exemplar, frecventa, termenele de obtinere.
La definitivarea continutului si formei listelor/situatiilor de iesire se recomanda sa se urmareasca o valorificare cat mai deplina a posibilitatilor de prelucrare oferite de sistemul electronic de calcul. De asemenea, se vor avea in vedere si anumite cerinte cu caracter general, cum sunt rezolvarea unor functii majore ale conducerii unitatii, existenta unei game suficiente si reprezentative de informatii, pentru a permite analiza exhaustiva a fenomenelor si proceselor economice reflectate. Aceste cerinte impun ca listele/situatiile de iesire sa fie prezentate intr-o forma simpla, inteligibila de natura sa asigure si facilitatea in utilizare, ceea ce impune omiterea detaliilor nesemnificative, ce nu corespund scopului propus.
2. Graficele redau intr-o forma sugestiva evolutia in timp a valorii indicatorilor economico-financiari continuti in listele/situatiile de iesire. Ele pot fi :
- graficele liniare redau evolutia in timp a valorilor specifice fiecarui indicator, reprezentate prin puncte amplasate la o distanta de axa orizontala, proportionala cu valorile respective. intr-un asemenea grafic se pot reprezenta maximum sase indicatori;
- graficele de tip bare arata diferentele dintre valorile indicatorilor, prin intermediul unor zone verticale ale caror dimensiuni sunt proportiona-le cu valorile reale ale indicatorilor;
- graficele de tip xy reprezinta relatia dintre valorile indicatorilor. in zona x se va reda setul de valori pentru axa orizontala, iar in zona Y se vor reflecta valorile ce sugereaza relatia dintre indicatorii prezentati;
- graficele stive specifica valorile indicatorilor prin intermediul unor zone verticale suprapuse, ale caror dimensiuni sunt proportionale cu valorile reale prezentate prin grafic;
- graficele rotunde asigura reflectarea ponderii unor valori aferente unui indicator in cadrul unui set complet de valori, ce reprezinta valorile integrale sau totale ale indicatorului. In mod concret, graficul are forma unui cerc, iar fiecare valoare a indicatorului este reprnzentata prin intermediul unui sector de cerc si redat in unitatile procentuale.
Aceste grafice pot fi insotite de elemente complementare:
- titlul si subtitlul graficului;
- legende privind reprerentarea indicatorilor din grafic;
- grile pentru redarea graficului prin linii orizontale, verticale sau prin patrate.
- reprezentarea cromatica a graficului (alb-negru sau alte culori);
- definirea unor formate corespunzatoare pentru valorile indicatorilor (numar fix de zecimale, reprezentare eu mantisa si exponent, prin procente; format histograma - semnul "+" pentru valori pozitive si semnul "-" pentru valori negative etc.).
Graficele pot fi obtinute in cadrul unui sistem informatic prin prelucrarea colectiilor de date, care conduc la obtinerea unor liste/situatii sub forma de tabele, ce pot fi reprezentate in continuare sub forma de grafice prin intermediul unor produse de programare specializate (LOTUS 1-2-3, TBL, QUATTRO,EXCEL,ACCESS etc.).
2.4. Iesiri catre alte sisteme
Sistemul informational propriu unitatii economice se afla in interconexiune cu sistemele informationale aferente altor unitati economice sau organisme guvernamentale. Aceasta caracteristica impune si necesitatea corelarii sistemului informatic specific unitatii economice benefiaiare cu alte sisteme informatice conexe. in acest sens, iesirile sistemului informatic al unitatii beneficiare pot constitui intrari in alte sisteme informatice, in timp ce iesirile altor sisteme informatice pot fi intrari in sistemul informatic propriu unitatii economice. Aceste interconditionari se pot realiza prin intermediul retelelor de calculatoare ce vor asigura conexiunea dintre bazele informationale specifice, carora le vor corespunde bazele de date asociate, intre care se realizeaza schimbul efectiv de date.
Din punct de vedere tipologic, iesirile catre alte sisteme informatice pot fi:
- directe (on-line), asigurate prin intermediul transmisiilor de date intre doua retele locale de calculatoare proprii agentului economic;
- indirecte (of f-line), asigurate prin transmiterea datelor intr-o anumita structura, continut si un anumit suport magnetic, la anumite frecvente stabilite de comun acord.
Formalizarea atributelor (se aplica in MCDD)
Formalizarea atributelor are ca scop elaborarea codurilor si adaptarea documentelor de intrare la cerintele sistemului informatic.
-1 Codificarea atributelor
Necesitatea codificarii atributelor este impusa de cerintele de grupare si ierarhizare a atributelor care ofera multiple posibilitati de prelucrare a colectiilor de date in care va fi transpusa baza informationala. Codificarea atributelor conduce si la utilizarea intensiva a suporturilor direct adresabile si a memoriei interne, ceea ce permite optimizarea accesului la diverse valori a atributelor, concomitent cu minimalizarea timpului de prelucrare a viitoarelor colectii de date. De asemenea, codurile aferente atributelor bazei informationale pot asigura confidentialitatea si integritatea valorii atributelor, ceea ce confera colectiilor de date o anumita protectie si securitate in timpul prelucrarii.
In mod concret codificarea atributelor trebuie sa realizeze o corelatie directa intre
semantica atributelor existente in baza informationala de intrare si multimea de
simboluri acordate acestora (codurile sistemului informatic) in concordanta cu cerintele
si functiile specifice codurilor. In acest sens, se urmaresc:
- cerintele si functiile codificarii;
- tipurile de coduri utilizate intr-un sistem informatic;
- fazele realizarii codificarii.
a) Cerintele si functiile codificarii
Activitatea de codificare a atributelor, trebuie sa asigure o legatura intre specificul unitatii economice si particularitatile bazei informationale de intrare.
Codificarea trebuie sa raspunda urmatoarelor cerinte:
- Unicitatea codului, presupune existenta unui singur simbol pentru un atribut al bazei informationale de intrare (corespondenta biunivoca), prin asigurarea unei valori unice pentru fiecare tip de atribut proprietate care trebuie asigurata la nivelul intregului sistem informatic.
- Stabilitatea si supletea in timp a codului, exprima necesitatea utilizarii unui tip de cod pe toata perioada de existenta a bazei informationale, inclusiv adaptarea extensiilor de volum ale valorilor atributelor codificate la dinamica valorilor bazei informationale. Extinderea poate afecta fie numarul de valori atribuite in momentul generarii codului, fie numarul de pozitii maxim reprezentate in interiorul fiecarui interval din structura codului.
Atribuirea codurilor pentru eventualele noi valori ale atributelor se poate realiza prin doua modalitati:
- acordarea de noi coduri pentru valorile atributelor ce apar ulterior alocarii initiale de coduri, in cadrul aceleiasi clase de coduri, astfel incat totalitatea codurilor utilizate la un anumit moment sa poata asigura corespondenta reala cu dinamica activitatii unitatii economice;
- folosirea unor tipuri de coduri care sa fie asociate claselor de coduri initiale, astfel incat noul cod utilizat, desi cu lungimea marita, sa caracterizeze in mod obiectiv fiecare tip de atribut.
- Comoditatea utilizarii codului se refera la facilitatea operatiilor de codificare-decodificare precum si la detectarea si corectarea erorilor.
Codurile trebuie sa fie usor de inteles si aplicat, astfel incat personulul unitatii economice beneficiare sa asimileze intr-un timp cat mai scurt noul sistem de coduri.
- Concizia codului se refera la necesitatea utilizarii unui numar cat mai mic de caractere pentru reprezentarea elementelor codificate. Aceasta asigura, pe de o parte, reducerea timpului de manipulare a codului si o crestere a conciziei de exprimare a atributelor informationale.
In vederea asigurarii acestor cerinte, codificarea atributelor o constituie atribuirea manuala sau automata, intr-o forma sistematizata, a unor coduri pentru fiecare atribut component al bazei informationale.
Functiile codificarii trebuie sa permita caracterizarea directa a fiecarui tip de atribut ce va fi supus operatiei de codificare, identificarea formala a acestora, controlul valorilor posibile ale atributelor in cadrul colectiilor de date, inclusiv functia de manipulare a atributelor codificate.
Functia de caracterizare, asigura exprimarea intr-o forma concisa, unica si stabila in timp, a continutului semantic a fiecarui atribut, prin intermediul codurilor asociate acestuia. In mod concret functia de caracterizare permite utilizarea cu prioritate a codului specific atributului in locul denumirii integrale a acestuia (exemplu: in loc de Facultatea de Contabilitate si Informatica de Gestiune se poate folosi codul descriptiv FCIG).
Functia de identificare, ofera posibilitatea regasirii mai rapide a atributelor prin intermediul codurilor asociate lor, decat prin folosirea completa a semanticii atributului. Aceasta functie creeaza posibilitatea alterioara de selectare a anumitor atribute prin intermediul carora se vor identifica in mod unic anumite valori solicitate prin intermediul conceptului de cheie candidata, primara, externa etc.
Functia de control, presupune existenta unui caracter de control care se ataseaza in ultima pozitie din dreapta structurii codului pe baza caruia, prin intermediul unor metode (aritmetica sau geometrica) si algoritmi specifici, sa se poata verifica integral, corectitudinea simbolurilor care intra in structura codurilor.
Functia de manipulare a atributelor codificate, faciliteaza introducerea eficienta in memorie a acestora, reducerea timpului de preluclare, minimalizarea prelucrarilor atributului, inclusiv usurinta folosirii codului de catre compartimentele functionale implicate in realizarea sistemului informatic.
In vederea realizarii cerintelor si functiilor codificarii, conceptul de cod presupune utilizarea unor simboluri acordate atributelor bazei informationale de intrare. La randul sau simbolul este prezentat de un sir de caractere, care permite exprimarea intr-o forma conventionala a unui element din ansamhlu de atribute codificate.
Simbolul este format dintr-un sir de caractere numerice alfabetice sau alfanumerice, ce pot fi interpretate de factorul uman sau de procedurile automate ale sistemului informatic. In aceasta viziune, codul este o colectie ordonata de simboluri, formate la randul lor din siruri de caractere, care asigura identificarea si utilizarea unei entitati sau a unui atribut al bazei informationale.
Codificarea atributelor este necesara deoarece asigura ca avantaje :
- inlocuirea atributelor prin coduri numerice, alfabetice si afanumerice care permite folosirea intensiva a suporturilor externe si a memoriei centrale;
- realizarea unei ierarhizari a atributelor, in functie de criteriile specifice prelucrarii, prin ordonarea acestora in raport de cerintele de selectare a atributelor din baza informationala si de obtinere a gradelor de total si subtotal pentru listele/situatiilor de iesire;
- optimizarea timpului de acces la colectiile de date in care va fi transpusa baza informationala de intrare;
- reducerea erorilor prin folosirea codurilor care inlocuiesc utilizarea explicita a valorii atributelor;
- simplitatea scrierii codurilor in comparatie cu folosirea denumirii explicite a atributelor pentru care regulile de scriere sunt complexe si greu de respectat.
In aceasta viziune, structura logica a codurilor trebuie sa asigure realizarea optima a unei corespondente biunivoce, intre multimea valorilor reale ale atributelor si multimea codurilor asociate acestora, asa cum se reda in continuare:
COD Û atribute, entitati, situatii, documente
b) Tipuri de coduri utilizate intr-un sistem informatic. Diversitatea si complexitatea continntului bazei informationale de intrare, precum si multitudinea proceselor de prelucrare a atributelor componente, au condus la aparitia unei game variate de coduri ce se pot grupa dupa mai multe criterii asa cum se reda in figura urmatoare.
Codurile elementare au rolul de a identifica un element din cadrul unei multimi de elemente. Din aceasta grupa fac parte: codurile secventiale, secventiale pe grupe, sau clase, cu semnificatia mnemonica si descriptiva.
- Codurile secventiale se formeaza prin atribuirea unui sir de caractere fiecarui element al multimii, stabilind o corespondenta (in ordine crescatoare) intre elementele acestora si, multimea numerelor naturale.
Fiecarui element supus codificarii i se asociaza un cod crescator, imediat disponibil. De exemplu, daca o persoana care lucreaza la o unitate economica are marca 1412, aceasta este precedata de persoana cu marca 1411 si urmata de persoana cu marca 141 Acest cod devine un analitic al contului "Decontari cu salariatii".
Codurile secventiale pot fi atribuite automat prin adaugarea valorii unu la o variabila care constituie codul secvential. Pentru a avea o lungime fixa a codului, este indicat a se stabili dimensiunea maxima a acestuia, ceea ce va asigura si estimarea dimensiunii fizice a codului.
Codurile secventiale se pot realiza in functie de un sistem de numeratie (b) si lungimea simbolului propus (n), ceea ce asigura o lungime maxima a codului (Lmax = bn). In aceasta lungime a codului se va include un numar maxim de elemente dependent de valorile lui b si n.. Spre exemplu, daca se folosesc caracterele sistemului de numeratie in baza 10, iar lungimea simbolului preconizat este de 3 caractere n=3 atunci lungimea maxima a codului este Lmax= bn = 103 =1000, ceea ce conduce la posibilitatea atribuirii unui set maxim de simboluri intre limitele 001 si 999. De mentionat, ca in mod concret nu este indicata utilizarea codului zero.
- Codurile secventiale pe grupe sau clase, se formeaza prin rezervarea unui set maxim de simboluri pentru fiecare tip de atribut omogen, caracterizat prin particularitati comune ce formeaza o grupa specifica supusa codificarii.
Grupele atribuite sunt dependente de specificul economic al atributelor si de cerintele de prelucrare omogena ale acestora, cu mentiunea ca in cadrul fiecarei grupe se vor atribui coduri secventiale pana la valoarea maxima rezervata acesteia. De exemplu in cadrul normelor metodologice privind reflectarea in contabilitate a capitalului social si a altor active si pasive din regiile autonome sau societati comerciale, planul de conturi este structurat in opt clase de conturi, in intervalul carora se folosesc coduri secventiale.
Exemplu : Clasa a 7-a ,"Conturi de venituri" cuprinde:
70 - Vanzari de produse fabricate si de marfuri.
701 - Vanzari de produse intermediare.
702 - Vanzari de produse finite, s.a.m.d.
- Codurile cu semnificatie mnemonica se formeaza fie prin consoanele unui cuvant, fie prin prescurtarea (abrevierea) denumirii atributului codificat (de exemplu OL pentru otel laminat). Acest tip de cod este foarte practic pentru prelucrarile manuale.
Codurile cu semnificatie descriptiva se formeaza prin combinarea initialelor denumirii cu particularitatile tehnico-constructive ale atributului de codificat. Acest tip de cod este utilizat in special la nomenclatoarele industriale, fiind extensibil pentru particularitatile tehnice semnificative. De exemplu, pentru codificarea conturilor analitice de materiale in cazul otelului rotund cu diametrul de 15 mm si lungimea barei de 10 m, codul atribuit este OR 15 10.
Codurile complexe contin atribute ce apartin unor multimi distincte, dar sunt folosite in comun pentru viitoarele prelucrari. in aceasta categorie se includ codurile ierarhizate juxtapuse
- Codurile ierarhizate contin atribute intre care exista relatii de incluziune astfel incat acestea sa poata fi reprezentate prin intermediul unei structuri arborescente. De exemplu, in cadrul unei unitati economice producatoare de aparatura electronica se fabrica mai multe grupe de produse (televizoare, aparate radio, casetofoane, videocasetofoane, etc.), in cadrul carora productia est.e diversificata pe subgrupe (televizoare alb-negru, color etc.) si tipuri de produse (Telecolor, Elcrom, Cromatic etc.), asa cum se reda in figura urmatoare.
Structura concreta a acestui cod ierarhizat se determina practic in functie de doi factori:
- numarul de trepte ale codului;
- numarul maxim de aparitii ale fiecarui tip de atribut in cadrul treptelor de ierarhizare. In aceste conditii codul mentionat are urmatoarea structura: Tl, T2, T3
Codurile ierarhizate se folosesc pentru acele atribute intre care exista relatii de ierarhizare, cu mentiunea ca acestea se folosesc in comun.
Codurile juxtapuse se realizeaza prin concatenarea codurilor ierarhizate sau a codurilor elementare in vederea utilizarii grupate sau individuale a atributelor codificate, in raport de cerintele statice sau dinamice de prelucrare. De exemplu, pentru codificarea personalului unei unitati economice, se poate realiza un cod juxtapus rezultat din concatenarea valorilor distincte ale atributelor (cod sectie, cod atelier, cod echipa si marca) asa cum rezulta in continuare.
Codurile complexe se asociaza atributelor bazei informationale de intrare, in functie de relatiile de ierarhizare si numarul maxim de valori posibile pentru fiecare tip de atribut, cu mentiunea ca in situatia obtinerii unui cod cu lungime egala sau mai mare cu trei caractere, este oportuna atasarea unui alt caracter in ultima pozitie din dreapta, denumita cifra sau litera de control.
Codurile autodetectoare de erori
Acest caracter de control va face parte din structura codului si va avea aceeasi valoare atata timp cat valorile atributelor componente nu se schimba. De asemenea, acest caracter de control poate asigura fie detectarea automata a eventualelor erori introduse, fie si corectarea automata a acestora.
Detectarea automata a erorilor introduse se poate face prin compararea caracterului de control care insoteste codul respectiv cu caracterul de control determinat de calculator la fiecare utilizare operativa a codului.
Pentru realizarea concreta a caracterului de control se pot folosi mai multe metode de calcul dintre care mentionam:
aritmetica;
geometrica.
Metoda aritmetica consta in stabilirea caracterului de control (C) prin intermediul unei cifre obtinuta pe baza sumei produselor rezultate din inmultirea fiecarei cifre a codului (Ci) cu anumite valori conventional alese, denumite ponderi (Pi) ale codului, ce urmeaza a fi scazuta din cifra zecilor imediat superioara (Z), astfel:
Spre exemplu, folosind ca ponderi valorile alternative 2 si l, caracterul de control pentru codul 85432, se va calcula in felul urmator :
8 5 4 3 2 Ci
2 1 2 1 2 Pi
= (1+6) + 5 + 8 + 3 + 4 = 27 iar Z=30
Rezulta ca C = 30 - 27 = 3
In situatia in care produsul dintre cifra codului si ponderea corespunzatoare depaseste valoarea noua atunci acest produs se va lua in calcul ca suma cifrelor care-1 compun (exemplu 8 X 2 = 16 rezulta 1+ 6). Codul initial 85432 in urma stabilirii caracterului de control devine 85432
Avantajul metodei aritmetice consta in simplitatea si acuratetea acesteia, iar dezavantajul consta in imposibilitatea sesizarii erorilor de compensare.
Metoda geometrica consta in stabilirea caracterului de control (C) prin intermediul unei cifre sau litere obtinuta ca rest al impartirii sumei produselor fiecarei cifre a codului, cu puterile crescatoare ale lui 2, la un numar sau cu numerele naturale in ordine crescatoare, par sau impar ales conventional (x), in urmatoarele faze:
- calculul sumei produselor dintre cifrele codului si ponderii:
- determinarea continutului de control :
()/X
Marimea numarului par sau impar ales conventional (X) determina numarul de cifre si valoarea maxima a caracterului de control. Spre exemplu, pentru acelasi cod (85432) caracterul de control va fi calculat in felul urmator:
8 5 4 3 2
25 24 23 22 21
(8 X 32) + (5 X 16) + (4 X 8) + (3 X 4) + (2 X 2)
256 + 80 + 32 + 12 + 4 = 384
384 : 11 = 34 rest 10
Codul in urma stabilirii cheii de control este 85432l0. Aceasta metoda asigura un grad mai ridicat de siguranta, dar se poate ajunge la o cifra de control formata din doua pozitii ceea ce conduce la o marire a lungimii codului.
Pentru a evita marirea lungimii codului si pentru a limita posibilitatea aparitiei erorilor de compensatie, se poate folosi o varianta a metodei geometrice caracterizata prin faptul ca numarul impar ales este 23 (cel mai mare numar natural asociat literelor alfabetului englez), iar caracterul de control este o litera ce se determina prin transformarea restului obtinut prin aplicarea algoritmului metodei geometrice in litera din alfabetul englez care are numarul natural corespunzator valorii restului. In acest caz algoritmul metodei este urmatorul:
()/23
De exemplu, pentru codul 85432 utilizat si la celelalte metode, litera de control se determina astfel:
8 5 4 3 2 Ci
5 4 3 2 1 Pi (unde Pi este ales ca fiind egal cu i).
40 + 20 + 12 + 6 + 2 = 80 =
80 : 23 = 3 rest 11, echivalentul literei cu numarul de ordine 11 din alfabetul englez, este litera K. Codul, in urma stabilirii literei de control este 85432K.
Metodele aritmetica si geometrica pot fi utilizate in corespondenta si cu alti algoritmi de calcul, cu pastrarea principiilor de determinare a caracterului de control si de asigurare operativa a controlabilitatii codului asociat unui atribut.
Indiferent de modalitatea de determinare a caracterului de control, principiul de verificare al codului ramane acelasi. La fiecare citire a codului calculatorul electronic aplica algoritmul de calcul al caracterului de control si compara rezultatul obtinut cu caracterul de control introdus odata cu codul. Daca caracterul de control calculat este diferit de caracterul de control care insoteste codul, se invalideaza atributul respectiv. Posibilitatea aparitiei erorilor este generata de inversarea sau insumarea eronata a cifrelor codului, scrierea eronata a codului in documentele de intrare sau de introducere gresita de la terminal.
Coduri autocorectoare de erori
Corectarea automata a erorilor permite atat detectarea erorilor cat si rectificarea automata a acestora. in acest scop, codurile sunt aranjate sub forma matriceala, stabilindu-se pentru fiecare linie si coloana cate un caracter de control determinat prin insumarea cifrelor pe linie sau pe coloana si scazand rezultatul din ordinul zecilor imediat superior. Eventualele erori se localizeaza la intersectia liniei si coloanei ale caror caractere sunt diferite de caracterele de control initial stabilite. Abaterea dintre caracterul de control determinat pe liniile matricei in raport de cel determinat pe coloanele acesteia, constituie valoarea absoluta a erorii. In determinarea caracterelor de control pe fiecare linie (j) si coloana (i) din matricea asociata codului, se folosesc urmatoarele relatii:
Clinj = Z-
Ccoli = Z-
iar caracterul general aferent liniei si coloanei din matrice se stabileste astfel :
Clinie = Z - si Ccoloana = Z-
Daca Clinie = Coloana atunci caracterul de control este corect si codul este validat, iar in caz contrar (Cline Ccoloana) se stabileste dimensiunea erorii (E = Clinie _ Ccoloana), iar codul se invalideaza.
Pentru exemplificare se considera codul 734285411936 care se aranjeaza sub forma unei matrice de patru linii si trei coloane asupra carora se aplica algoritmii de calcul in doua etape :
- prima etapa :
Grupul de coduri controlate dupa aceasta metoda se scrie in serie, urmat de caracterele de control pe linii, pe coloane si cel general astfel: 734 285 411 936 6542 854 Procedura automata de verificare a codurilor, citeste structura codului in aceasta ordine, dupa care calculeaza caracterele de control si localizeaza eroarea la intersectia liniei si coloanei
pentru care caracterele de control nu corespund cu cele stabilite anterior. Valoarea care se aplica cifrei gresite pentru a genera o cifra corecta este data de diferenta dintre cifra generala de control (in cazul analizat 3) si caracterul general de control calculat de calculator.
Spre exemplificare, daca in loc de secventa 285 apare 295, atunci procedura va sesiza eroarea prin identificarea liniei , si coloanei eronate folosind acelasi algoritm de calcul;
a doua etapa :
7 3 4 6
2 9 5 4
4 1 1 4
9 3 6 2
8 4 4 4
Pentru a realiza o codificare a nomenclatoarelor care sa satisfaca cerintele prezentate, este necesar ca responsabilitatea acestei munci sa fie incredintata unei persoane cu functie de raspundere in cadrul unitatii economice, care sa asigure generalizarea unor coduri eficiente si sa evite proliferarea unor coduri particulare. in acest scop se procedeaza la inventarierea tuturor atributelor care compun baza informationala de intrare, precum si tipurile de prelucrari aferente.
Inainte de a opta pentru un sistem de codificare se cerceteaza daca exista un asemenea sistem si in ce masura poate fi utilizat. Este necesar sa se precizeze modul de atribuire practica a codurilor precum si modalitatea de control. In continuare se stabilesc procedeele de difuzare a nomenclatoarelor de coduri si modalitatile de modificare operativa a acestora, pentru a elimina codurile perimate si a permite actualizarea acestora. Inainte de a se trece la utilizarea unui sistem de coduri este necesara testarea acestora pentru a depista si inlatura eventualele erori, deoarece orice greseala de codificare are consecinte imprevizibile asupra rezultatelor prelucrarii.
Marimea erorii este data de, diferenta dintre caracterul de control stabilita initial ,si caracterul de control general calculat in timpul verificarii (3 - 4 = -1). Corectarea automata a erorilor implica utilizarea unui spatiu mare de memorie deoarece se utilizeaza matricele si tabelele de referinta necesare verificarii codului in cele doua etape. De asemenea, se ocupa mult suport tehnic deoarece alaturi de codurile propriu-zise apar si grupele de cifre de control pe linii si coloane, iar procedurile automate sunt mai complicate.
Atributele bazei informationale de intrare pot fi de tip numeric, alfabetic si alfanumeric, de lungime fixa sau variabila, ceea ce conduce la utilizarea unor coduri adecvate in realizarea sistemelor informatice. Codurile pot fi elaborate manual sau automat prin intermediul unor proceduri de generare a acestora.
Oportunitatea activitatii de codificare se poate decide in functie de:
- marimea si complexitatea continutului bazei informationale de intrare;
- tipurile de atribute existente in baza informationala de intrare si masura in care codificarea acestora conduce la performante in prelucrare si economie de suport tehnic;
- complexitatea structurii sistemului informatic;
- specificul operatiilor de prelucrare a colectiilor de date;
- solutia celui mai eficient sistem de coduri care sa permita codificarea si interpretarea facila a atributelor de catre factorul uman;
- costul stabilirii si validarii sistemelor de coduri, a decodificarii atributelor din baza informationala a elaborarii, actualizarii si intretinerii nomenclatoarelor de coduri;
- eforturi de adaptare a personalului din unitatea beneficiara la cerintele utilizarii sistemelor de coduri.
Din punct de vedere al modului de realizare, codificarea poate fi:
- cu pregatire prealabila;
- fara pregatire prealabila.
Codificarea cu pregatire prealabila solicita o analiza a ansamblului atributelor de codificat care sa preceada codificarea propriu-zisa si sa evalueze exact volumul atributelor, ierarhizate si gama de valori posibile.
Codificarea fara pregatire prealabila se realizeaza prin atribuirea de coduri pe masura aparitiei de noi valori pentru atributele introduse in sistem. Singura analiza necesara in acest caz consta in determinarea volumului maxim de atribute pentru a stabili lungimea si limitele codului.
Atribuirea codurilor poate fi realizata manual sau automat. Codificarea manuala este utilizata pentru orice tip de cod, in timp ce codificarea automata se aplica numai, la codurile simple pentru care se poate defini, un algoritm de atribuire programabil pe calculator. De asemenea, aceasta modalitate de codificare solicita standardizarea denumirii atributelor codificate si eventual redactarea unor programe sau rutine de recunoastere. Codificarea automata ofera in comparatie cu cea manuala o serie de avantaje automate a caracterului de control si cresterea preciziei in elaborarea nomenclatoarelor de coduri.
c) Fazele realizarii codificarii
Fazele realizarii codificarii sunt dependente de specificul sistemului informatic, marimea unitatii economice, dimensiunea bazei informationale de intrare si tipologia codurilor utilizate, elemente care presupun abordarea codificarii in urmatoarea succesiune:
- pregatirea activitatilor de codificare;
- codificarea atributelor bazei informationale de intrare;
- intocmirea nomenclatoarelor de coduri;
- intretinerea codurilor.
1. Pregatirea activitatilor de codificare presupune analizarea continutului si structurii bazei informationale de intrare ce urmeaza a fi codificata si examinarea codurilor existente, inclusiv masura in care acestea satisfac cerintele sistemului informatic. De asemenea, se stabileste esalonarea in timp a codificarii, modul de realizare si de control si se opteaza pentru o codificare cu sau fara pregatire prealabila, manuala sau automata.
Stabilirea necesitatilor de codificare este dependenta de volumul atributelor supuse codificarii, tipul de cod utilizat, precum si de modul de realizare a acestuia. Astfel, in cazul unei codificari fara pregatire prealabila, activitatea se reduce la o analiza sumara a volumului atributelor. Daca se opteaza pentru codificarea cu pregatire prealabila este necesara ordonarea atributelor de codificat, analiza particularitatilor continutului bazei informationale de intrare si alegerea codului
Ordonarea atributelor bazei informationale de intrare ce urmeaza a se codifica, presupune clasificarea atributelor pe nivele ierarhice in scopul definirii grupelor/claselor de codificare, inclusiv reguli de introducere a acestora in baza informationala de intrare. in fiecare grupa/clasa se vor stabili caracteristicile specifice si valorile posibile ale acestora.
Analiza particularitatilor continutului bazei informationale de intrare, urmareste evaluarea dimensiunii actuale a multimii atributelor de codificat, precum si estimarea evolutiei ulterioare. Pentru aceasta este necesar sa se precizeze responsabilitatile de gestionare a bazei informationale de intrare, modul de utilizare concreta a codurilor in documentele de intrare, frecventa de utilizare, precum si modul de acomodare a utilizatorului cu sistemul de coduri propus. Toate aceste particularitati trebuie sa fie in corelatie cu strategiile de memorare si acces ale colectiilor de date asociate bazei informationale de intrare.
Alegerea codului se va face in functie de dimensiunea , si particularitatile bazei informationate de intrare, natura, complexitatea si valorile atributelor, metoda de introducere si validare a codurilor, cerintele si restrictiile sistemului informatic proiectat, metoda de codificare, costul si timpul de realizare a activitatii de codificare
Dimensiunile si particularitatile bazei informationale de intrare determina alegerea tipurilor de coduri care sa reflecte in mod unitar continutul acesteia. Dimensiunea bazei informationale are implicatii asupra lungimii codurilor utilizate, in timp ce particularitatile acesteia influenteaza tipologia codurilor folosite. In situatia in care o baza, informationala de intrare contine atribute caracterizate printr-o subordonare a acestora, este indicat a se folosi codurile ierarhice, iar in situatia in care atributele vor fi prelucrate in functie de mai multe criterii, atunci sunt utilizate codurile juxtapuse.
Natura, complexitatea si valorile reale ale atributelor impun utilizarea unor coduri care pot servi la identificarea unica a acestora, inclusiv o buna conversie a naturii, complexitatii si valorilor reale ale atributelor. In asemenea situatii se recomanda utilizarea codurilor de tip secvential. Daca intre atributele bazei informationale de intrare exista relatii de subordonare, atunci se poate opta pentru utilizarea codurilor ierarhizate. in alternativa in care se pot defini diverse proprietati ale atributelor, atunci este oportuna utilizarea codurilor juxtapuse.
In situatia realizarii de sisteme informatice in domeniul bancar sau al serviciilor este indicata utilizarea codurilor cu semnificatia mnemonica sau descriptiva, deoarece este posibila o utilizare facila a acestora.
Cerintele si restrictiile sistemului informatic proiectat reprezinta factorii de baza in alegerea codului, deoarece activitatea de codificare este subordonata functionalitatii noului sistem. Din acest punct de vedere trebuie examinate in primul rand cerintele informationale pe nivele ierarhice, deoarece acestea determina aria de utilizare a codului si gradul sau de generalitate. In cazul in care sistemul este realizat pentru diverse nivele ierarhice (unitate, subunitate etc.), codul trebuie sa asigure relatiile existente in ambele sensuri.
Metoda de codificare are in vedere realizarea codificarii cu sau fara pregatire prealabila, in mod manual sau automat. Codificarea fara pregatire prealabila prezinta avantajul realizarii acesteia cu un cost minim si intr-un timp scurt, prin folosirea codurilor secventiale sau secventiale pe grupe, in timp ce codificarea cu pregatire prealabila utilizeaza coduri descriptive care solicita costuri si timp de realizare mai mari.
Costul si timpul de realizare a activitatii de codificare implica alegerea unor tipuri de coduri care necesita cheltuieli minime si un timp redus de realizare a nomenclatoarelor de coduri. in aceste conditii se recomanda utilizarea metodei de codificare automata cu pregatire prealabila, deoarece asigura costuri minime si perioade reduse de codificare.
Pe baza cerintelor prezentate, se alege tipul de cod adecvat si se stabileste structura sa in functie de volumul atributelor, evolutia acestora si numarul total de caractere necesare codificarii fiecarui atribut. Alegerea trebuie sa se faca in corelatie cu celelalte coduri folosite si cu caracteristicile intregii baze informationale pentru a realiza o uniformitate a codurilor. De asemenea, trebuie examinata posibilitatea preluarii unor sisteme de codificare existente, deoarece se realizeaza scurtarea perioadei de implementare si experimentare a sistemului , informatic proiectat.
2. Codificarea atributelor bazei informationale de intrare
Consta in stabilirea codurilor corespunzatoare pentru fiecare atribut din nucleul informational. Pentru aceasta se elaboreaza un nomenclator al valorilor atributelor pe grupe omogene, cu precizarea particularitatilor si valorilor posibile ale acestora. De asemenea, se va intocmi si un nomenclator al tuturor codurilor posibile cu caracterele de control determinate.
Pentru realizarea codificarii atributelor bazei informationale de intrare la nivelul unei unitati economice se vor avea in vedere, in principiu, urmatoarele tipuri de atribute :
codurile sintetice si analitice din structura planului de conturi, cu dezvoltarea pe trepte a acestora, in functie de specificul activitatii si nevoile de informare operativa, prin folosirea unui cod ierarhizat cu urmatoarea structura:
codificarea materialelor, produselor sau reperelor se va face prin intermediul unui cod ierarhizat, care sa permita atat identificarea variantelor tipologice de materiale sau produse, inclusiv stabilirea unei ierarhizari impusa de prelucrarile operative. In stabilirea ierarhizarii codului pe nivele trebuie sa se tina seama si de cerintele de detaliere ale caracteristicilor tehnologice pentru materiale, produse si repere, prin folosirea unui cod ierarhizat cu urmatorea structura
codificarea compartimentelor, presupune atribuirea de coduri pentru magazii si gestiuni, precum si coduri pentru sectii, ateliere si formatii de lucru prin utilizarea unor coduri ierarhice cu urmatoarea structura :
codificarea salariatilor se poate realiza printr-un cod secvential de 4-5 cifre a carui lungime concreta este determinata de numarul mediu scriptic al salariatilor din unitate. Se recomanda ca acest cod sa nu contina si elemente privitoare la specialitate, gradatie sau clasa de incadrare, deoarece acestea sunt variabile in timp, in comparatie cu marca care ramane neschimbata pe toata durata de activitate. De asemenea, se recomanda ca marea persoanei sa nu constituie o treapta suplimentara la codurile pentru sectii, ateliere si formatii de lucru, deoarece exista posibilitatea transferarii personalului muncitor de la o structura organizatorica la alta, ceea ce va impune operatii de recodificare
codificarea clientilor si furnizorilor se realizeaza prin intermediul codului ierarhizat, care sa contina trepte referitoare la tipul acestuia (intern sau extern), locul de desfasurare a activitatii (tara sau judetul), felul unitatii economice (regie autonoma, societate comerciala), numarul de ordine.
codificarea unitatilor de masura se va realiza pe baza unui cod secvential sau o semnificatie mnemonica, ales astfel incat sa serveasca cat mai bine cerintelor, de prelucrare automata si de informare a unitatii beneficiare;
codificarea operatiilor tehnologice se realizeaza prin intermediul unui cod secvential, pe grupe cu urmatoarea structura:
Intocmirea nomenclatoarelor de coduri
Consta in elaborarea unor liste in care sunt precizate codurile si denumirea completa a atributelor la care acestea se refera. Pentru a facilita utilizarea nomenclatoarelor, se recomanda ca acestea sa fie sortate dupa codul sau denumirea atributelor. Un nomenclator de coduri va contine denumirea completa a atributelor, codul asociat, caracterul de control precum si alte informatii reteritoare la pretul unitar, unitate de masura, inclusiv trimiteri la alte clasificari sau instructiuni de completare.
Intretinerea codurilor
Consta in efectuarea adaugarii sau stergerii de atribute in vederea actualizarii nomenclatoarelor de coduri, motiv pentru care este recomandabil ca aceasta activitate sa fie efectuata de aceeasi echipa care a conceput si realizat codificarea.
Nomenclatoarele de coduri se recomanda sa fie revizuite periodic pentru a elimina ambiguitatile si redondantele prin stergerea valorii atributelor care nu mai prezinta interes. De asemenea, nomenclatoarele de coduri vor fi actualizate atunci cand criteriile de utilizare a atributiilor se schimba, aria de cuprindere a sistemului proiectat se extinde, cand apar modificari in cadrul legislativ-normativ, etc.
4. Adaptarea documetelor primare la cerintele sistemului informatic
(se identifica in MGD si se aprofundeaza in MCDD)
Adaptarea documentelor primare la cerintele sistemului informatic este o faza importanta in cadrul proiectarii, deoarece in documente se consemneaza starea si dinamica fenomenelor si proceselor economice desfasurate in unitatea economica si reflectate prin intermediul sistemului informatic. Datele consemnate in documentele de intrare sunt introduse in sistemul informatic prin intermediul tranzactiilor externe efectuate asupra colectiilor de date organizate baze de date.
Obiectivul principal al acestei faze il constituie formalizarea documentelor din punct de vedere al continutului si al formei, in asa fel incat acestea sa raspunda exigentelor specifice sistemului informatic in concordanta cu cerintele concrete ale beneficiarului.
Adaptarea documentelor primare la cerintele unui sistem informatic presupune:
- scopul adaptarii documentelor de intrare;
- tipuri de documente primare utilizate;
- modificarile de continut si format ale documentelor primare.
Scopul adaptarii documentelor primare:
- consemnarea fenomenelor si proceselor economice desfasurate in unitatea economica, in momentul si la locul producerii acestora (compartimentele functionale);
- utilizarea codurilor proiectate pentru sistemul informatic in structura informationala a documentelor primare, in vederea transpunerii exacte si corecte a acestora in colectiile de date ce vor surprinde dinamica valorii atributelor;
- caracterizarea dinamica a operatiilor economice desfasurate in unitatea beneficiara pentru crearea initiala si actualizarea periodica a colectiilor de date;
- reflectarea in componentele sistemului informatic (subsisteme, aplicatii etc.), a naturii activitatii compartimentelor functionale prin intermediul datelor consemnate in documentele de intrare.
- simplificarea si perfectionarea sistemului de evidenta prin utilizarea unui numar minim de documente de intrare, in care sa se surprinda intr-o forma sintetizata starea si dinarnica utilizarii patrimoniului, in paralel cu gestiunea unor colectii de date, capabil sa reflecte dinamic aceste fenomene
Tipuri de documente de intrare.
Documentele de intrare in care se consemneaza starea si dinamica fenomenelor si proceselor economice pot fi structurate in functie de:
sfera;
frecventa de utilizare;
regimul de gestionare;
tipurile tranzactiiior externe;
formatul de prezentare, etc.
a) Sfera de utlizare a documentelor primare permite gruparea acestora in doua categorii:
- documentele primare comune, folosite pentru inregistrarea datelor privind procesele tehnico-economice din activitati desfasurate in toate tipurile de unitati economice, indiferent de domeniul de activitate (ex.: Nota de Contabilitate);
- documente de intrare specifice, folosite pentru inregistrarea datelor ce caracterizeaza anzumite procese tehnico-economice desfasurate in cadrul unor ramuri sau subramuri (exemplu: Extrasul de cont).
b) Frecventa de utilizare si ponderea informatiior fixe continute in documentele de intrare permit gruparea acestora in doua categorii:
- tiparite, caracterizate printr-o utilizare generala la nivelul tuturor unitatilor economice, ceea ce justifica din punct de vedere economic multiplicarea lor (ex.: factura fiscala).
- netiparite caracterizate printr-o utilizare speciala numai la nivelul unor anumite unitati economice.
c) Regimul de gestionare al documentelor impune gruparea acestora in doua categorii:
- cu regim uzual sunt caracterizate, printr-o folosire si o evidenta similara cu cele tiparite in vederea utilizarii generale, fara restrictii exprese din punct de vedere legal.
- cu regim special, a caror gestionare, folosire si evidenta sunt impuse de reglementarile in vigoare, cu precizarea ca in continutul lor este tiparita mentiunea 'Regim special'
(ex.: formularul cu codul 14-3-1 'Chitanta Fiscala").
d) Tipul tranzactiilor externe asigura gruparea documentelor in doua categorii:
- documente care redau starea initiala a fenomenelor si proceselor economice, prin care se asigura cuantificarea elementelor patrimoniale ale unitatii economice in momentul lansarii in executie a sistemului informatic;
- documente care reflecta dinamica fenomenelor, si proceselor economice ce modifica elementele patrimoniale intr-o anumita perioada de gestiune.
Documentele primare din prima categorie permit constituirea initiala a colectiilor de date in momentul lansarii in functiune a noului sistem informatic. Aceste documente surprind starea initiala a fenomenelor si proceselor economice prin intermediul valorii reale ale atributelor cu caracter conventional constant, inregistrate prin intermediul nomenclatoarelor (produse, materiale, clienti, furnizori, conturi, mijloace fixe, obiecte de inventar), cat si starea initiala a fenomenelor si proceselor economice supuse prelucrarii automate (exemplu: "Lista de inventar").
e) Formatul de prezentare a documentelor permite gruparea acestora in trei categorii:
- documentele individuale asigura redarea denumirii si valorii atributelor prin amplasarea acestora pe intreaga suprafata in functie de suecesiunea logica a operatiei economice rezultate (ex.: chitanta, fisa personala a salariatului fisa mijlocului fix etc.);
- documentele comune reflecta denumirile si valorile atributelor prin ordonarea acestora sub forma de tabel in cadrul caruia succesiunea atributelor este determinata de relatiile de apartenenta si incluziune dintre multimile specifice ale atributelor (ex.: Nomenclatoare de produse, clienti, materiale, obiecte de inventar etc.);
- documente mixte, permit ordonarea numelui si valorii atributelor atat in format individual cat si in format comun, pentru a furniza intr-o forma eficienta, dispunerea atributelor in structura documentului de intrare (ex.: Bon de consum. Aviz de expeditie/Dispozitie de livrare, Factura fiscala etc.).
Documentele primare prezentate constiuie sursa principala a tranzactiilor externe utilizate intr-un sistem informatic pentru gestiunea colectiilor de date, cat si sursa secundara pentru generarea tranzactiilor interne in cadrul nucleului sistemului informatic.
Astfel, utilizarea acestor doua categorii de documente trebuie sa asigure adaugarea de noi atribute ca urmare a operatiilor economice care reflecta miscarea elementelor patrimoniale, inserarea de noi atribute in scopul evidentierii noilor operatii economice, modificarea si stergerea de atribute impuse de dinamica elementelor patrimoniale, precum si necesitatea punerii de acord a colectiilor de date cu realitatea economica din unitatea beneficiara.
Documentele primare dostinate creerii si actualizarii colectiilor de date, in conditiile in care nu corespund integral din punct de vedere al cotinutului si al formei cu restrictiile impuse de sistemul proiectat si structura bazei de date de intrare, vor fi modificate in vederea realizarii acestor deziderate.
Modificarile de continut vizeaza:
- adaugarea in documente a rubricilor pentru coduiri in masura in care acestea nu sunt deja prevazute. in acest sens se va insista codurilor ce specifica natura operatiilor reflectate si a celor care servesc pentru identificarea si asocierea calectiilor de date (cod material, cod produs, marca, cod sectie, cod comanda etc.);
- eliminarea atributelor ce se obtin prin calcule (ex. valoarea);
- regruparea si modificarea rubricilor aferente atributelor ce vor contine date care sa se introduca in sistemul informatic in asa fel incat acesta sa se gaseasca in acelasi loc in toate documentele. Cu alte cuvinte, se pastreaza individualitatea fiecarui tip de document, dar se defineste o zona comuna identica pentru toate documentele din care se vor prelua datele pe suporturile tehnice.
Modificarile de format sunt impuse de necesitatea cresterii facilitatilor de preluare directa a datelor prin intermediul videoterminalelor si vizeaza urmatoarele aspecte
- gruparea in cadrul documentului a tuturor atributelor care urmeaza a fi introduse de la videoterminal, in asa fel incat rubricile corespunzatoare sa nu fie dispersate pe intreaga suprafata a documentului;
- evitarea intercalarii atributelor ce se preiau in colectiile de date cu atributele care au caracter constant sau rezulta din calcul.
- evidentierea in cadrul documentului a numarului maxim de caractere speciflcate pentru fiecare atribut, inclusiv precizarea pozitiei punctului zecimal;
- ordinea atributelor in cadrul documentelor trebuie sa asigure prezenta. atributelor de identificare, urmate de cele informative si terminand cu cele cantitativ-valorice;
- evidentierea zonelor care contin atribute ce se preiau in colectiile de date, prin demarcarea cu linii mai groase sau de culori diferite etc.
Ex.: din documentul primar "Bon de consum" nu se vor prelua atributele constante "pretul unitar" si "unitatea de masura", inclusiv atributul rezultat din calcul "valoarea aferenta iesirilor" desi ele sunt consemnate in document pentru efectuarea controlului gestionar;
Toate modificarile si adaptarile enuntate se fac in asa fel incat documentele primare sa satisfaca in totalitate atat cerintele de evidenta, cat si cele de prelucrare automata a datelor, cu mentiunea ca rezultatele acestor modificari sunt supuse spre aprobarea organelor de conducere ale unitatii economice beneficiare sau a organelor centrale de sinteza.
Alaturi de definitivarea continutului si formatului se impune si stabilirea regulilor de completare si utilizare a documentelor primare, precizarea numarului de exemplare si a circuitului fiecarui exemplar, stabilirea frecventei si termenelor de introducere a datelor in colectiile de date. De asemenea, se precizeaza responsabilitatile pentru completare si verificare, vizele sau semnaturile care valideaza continutul documentelor primare, inclusiv persoanele imputernicite in acest sens. Aceste specificatii sunt folosite pentru proiectarea noilor circuite informationale in noul sistem, cat, si in manualul de utilizare definitivat in etapa de implementare.
Anexa 2.
Anexa
Schema de flux informational pentru domeniul FINANCIAR-CONTABIL
FINANTELOR TII ECONOMICE
SERVICIUL COMERCIAL
FINANCIAR-
BANCILE CONTABIL
CERCETARE
DEZVOLTARE
PERSONAL
ADMINIS-
TRATIV
Inapoi
Anexa 4
Inapoi
ANEXA 5
Exemplu de documentatie de proiectare: casa de schimb valutar
1. Modelarea globala
a) Descrieri si definitii (se fac referiri la urmatoarele aspecte):
activitatea de schimb valutar: mecanismul convertibilitatii, formarea cursului de schimb valutar, tipologia cotarii, stabilirea cursului valutar, definitia pietei valutare, operatii efectuate pe piata valutara;
politica valutara in
organizarea, functionarea si rolul caselor de schimb valutar.
b) Comunicatiile din sistemul caselor de schimb valutar (cu bancile, iar in cazul societatilor cu mai multe puncte de schimb (PSV), intre aceste puncte de schimb): definirea comunicatiilor la nivelul structurii organizatorice a societatii, definirea solutiilor globale si previzibile de organizare a comunicatiilor de date si de prelucrari, specificarea generala a comunicatiilor viitoare (posturi de lucru sau retea de calculatoare)
c) Viziunea asupra datelor:
- definirea obiectivelor manageriale si functionale ale sistemului (vezi anexa);
- definirea intrarilor si iesirilor in concordanta cu obiectivele stabilite.
Tipul obiectivelor |
Intrari necesare |
Iesiri solicitate |
Manageriale |
Raport selectiv Registru de casa Raport BNR Totaluri miscari |
|
Functionale |
Buletin de cumparare Buletin de vanzare Buletin de miscare (intrari, iesiri, sold initial) |
Jurnal cumparari Jurnal vanzari Borderou cumparari Borderou vanzari Registru de casa Raport BNR Totaluri miscari |
d) Viziunea asupra prelucrarilor
- definirea subsistemelor informatice si aplicatiilor informatice (in acest exemplu nu este cazul, fiind o singura aplicatie);
- descrierea conexiunilor dintre subsisteme /aplicatii in scopul asigurarii functionalitatii sistemului realizat (nu este cazul).
2. Modelarea conceptuala
a) Descrieri si definitii:
- stabilirea functiilor/domeniilor sau activitatilor informatizabile autonome; in cadrul acestora se identifica un sistem de conducere, unul informational si unul operant (la o CSV nu este cazul);
- tipuri de iesiri: rapoarte, grafice, indicatori.
Rapoarte:
Cod raport |
Denumire raport |
Frecventa |
Descrierea raportului |
JCV |
Jurnal cumparare valuta |
zilnic |
Prezinta nr. BSV, codul valutei suma incasata, comisionul, c/v lei, c/v lei BNR si suma platita |
JVV |
Jurnal vanzari valuta |
zilnic |
Se completeaza dupa modelul de mai sus |
BC |
Borderou cumparari |
Se completeaza dupa modelul de mai sus |
|
BV |
Borderou vanzari |
zilnic |
Se completeaza dupa modelul de mai sus |
RBNR |
Raport BNR |
lunar |
Se completeaza dupa modelul de mai sus |
TM |
Total miscari |
lunar |
Se completeaza dupa modelul de mai sus |
RC |
Registru de casa |
zilnic |
Se completeaza dupa modelul de mai sus |
In continuare se prezinta structura informationala a fiecaruia dintre rapoartele din tabelul de mai sus. De exemplu:
CSV.... Cod: JCV
PSV....
Jurnal CUMPARARI VALUTA
in perioada de la D,8 la D,8
Nr. BSV |
DATA OP. |
COD VALUTA |
CURS |
INCASAT |
Y.COM |
COMI-SION |
C/V LEI |
C/V LEI BNR |
PLATIT |
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 |
Cod si tip |
Denumire |
Frecventa |
Axa OX |
Axa OY |
2D |
3D |
G1- bare |
Evolutia cumpararii |
L/A |
Lunile anului |
Valori in valuta |
da |
da |
G2- bare |
Evolutia vanzarii |
L/A |
Lunile anului |
Valori in valuta |
da |
da |
Acum, pentru fiecare grafic in parte, se dau imagini capturate ale graficelor.
intrarile: buletinul de schimb valutar, borderou de cumparare (BC), borderou de vanzare (BV). Pentru fiecare document se precizeaza cand se emite, in cate exemplare, cum se folosesc exemplarele. Se precizeaza cum vin aceste documente in sprijinul iesirilor (de exemplu se evidentiaza faptul ca ele ne permit sa generam situatia cumpararilor si vanzarilor de valuta pe zile si pe valute, fisa tranzactiilor valutare pe fiecare valuta in parte, evidentiindu-se soldul zilnic al valutei respective).
In 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 strain |
BI |
AI |
PT |
PS |
XX |
Pentru tari se foloseste codificarea pentru circulatia rutiera.
Urmeaza un tabel cu simbolurile valutelor avand campurile simbolul valutei si denumirea valutei.
b) Modelul conceptual de comunicatii (MCC) este realizat pe baza urmatorilor actori si fluxuri informationale:
Nr. Ordine al operatiei |
Actor sursa |
Actor destinatie |
Document/ situatie |
Descriere flux |
PSV |
CSV |
BMITPSV |
Transferul sumelor in valuta intre PSV si CSV |
|
CSV |
BNR |
BMITB |
Transfer valuta intre BNR si CSV |
|
CSV |
BNR |
TXC |
Verificarea soldului in valuta |
|
CSV |
BNR |
BMETB |
Depunerea sumelor in valuta la BNR |
MCC aferent CSV este materializat prin tabelul de mai sus si prin urmatoarea diagrama de flux:
BMECH(8)
BC(7), BV(7)
Persoana fizica Bi(6),A(6),PT(6) BOC(14), BOV(14)
(romana/straina) 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 banca BC - borderou cumparari
AI
- adeverinta de identitate BMETPSV -
buletin miscare iesiri transfer
PT - pasaport turistic BMECH - buletin miscare iesiri cheltuieli RC - registru de casa
PS - pasaport de serviciu BMEAE - buletin miscare iesiri alte iesiri RBNR - raport catre BNR
MBSI - buletin miscare sold initial RZT - registru zilnic de tranzactii valutare BOV - borderou vanzari
Sa observam ca Diagramele de flux materializeaza actorii, legati intre ei cu sageti, pe care sunt trecute simbolurile documentelor, iar langa simboluri, se trece in paranteza nr. crt. al operatiei in tabelul ce insoteste diagrama.
Numele actorului se trece in simboluri reprezentate prin cercuri, hexagoane sau patrate.
c) Modelul conceptual de date (MCD)
MCD asigura determinarea tipurilor de atribute, entitati, relatii, chei primare si cardinalitatea. Pentru aceasta se pleaca de la analiza semantica a atributelor intalnite in documentele primare si de la operanzii implicati in algoritmul de calcul al diferitelor operatii si se intocmeste baza de atribute (un tabel de forma celui de mai jos):
Tipuri de atribute |
Tipuri de entitati |
|||||||||||||||||
Tipul de atribut |
t,l |
C |
c |
Intrari |
Iesiri |
|||||||||||||
BC |
BV |
BMX |
JCV |
JVV |
BC |
BV |
RC |
RBNR |
TM |
Clienti |
Valute |
Tran-zactii |
Miscari valute |
|||||
Cod PSV |
C,5 | |||||||||||||||||
Serie BSV |
C,5 | |||||||||||||||||
Numar BSV |
C,10 | |||||||||||||||||
Observatie: In cazul casei de schimb valutar (SCV) acest tabel contine cca 50 de atribute (randuri) din care aici mai dam pe ultimul |
||||||||||||||||||
Alte iesiri |
N,12,2 | |||||||||||||||||
In continuare se intocmeste matricea dependetelor (dependenta intre doua atribute inseamna ca valorii unuia dintre ele ii corespund una sau mai multe valori ale altui atribut; de exemplu unui nr_fact ii corespunde data_fact).
Aceasta contine atributele provenite din documentele de intrare, atat pe verticala cat si pe orizontala (doar ca pe orizontala nu se mai scrie numele atributului, ci nr. crt. din prima coloana), iar la intersectia a doua atribute, daca intre ele exista dependenta functionala se trece o steluta. In cazul CSV, aici sunt incluse cca 20 de atribute:
Cod PSV | ||||||||||||||||||||||
Serie BSV | ||||||||||||||||||||||
Numar BSV | ||||||||||||||||||||||
Pe baza documentelor intocmite mai sus, putem elabora MCD, care poate fi reprezentat grafic ca in schema de mai jos, sau tabular:
CLIENTI TRANZACTII VALUTE
Numar AI 0,n realizeaza 1,1 nr. BSV 1,1 foloseste 1,n cod valuta
Serie A serie BSV curs cumparare
Nume persoana data operatiei curs vanzare
Organ emitent
Data emiterii
1,1 actualizare 1,n
Descriere MCD |
|||||||
Descrierea tipurilor de entitati |
Descrierea tipurilor de relatiia* |
||||||
Tip entitate |
Tip proprietate |
Tip relatie |
Tip proprietate | ||||
identificator |
Tip, lungime |
r |
R |
identificator |
Tip, lungime |
Cardinalitate |
colectie |
Clienti CLIENTI |
numar 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 |
Realizeaza |
0,n |
CLIENTI TRANZ |
|||
Foloseste |
1,n |
TRANZ VALUTE |
|||||
Tranzactii CSV TRANZ |
nr. BSV, C, 10 serie BSV,C,5 data operatiei, D,8 suma incasata, N,6 suma vanduta, N,6 |
Actualizare |
1,n |
MISC- VALUTE VALUTE |
|||
Valute VALUTE |
Cod valuta, C,3 Curs cump, N,4 Curs vanz, N,4 % comision, N,6,2 | ||||||
Miscari valute MISC |
Nr. Doc Descrierea operatiei, C, 40 Sold initial, N,12,2 |
*) Relatia reprezinta corespondetele de aceeasi natura care apar intre o realizare din prima entitate si una sau mai multe realizari apartinand celeilate entitati. Astfel un client realizeaza una sau mai multe tranzactii. Relatia se poate crea pe mai mult de doua entitati, dar si pe o singura entitate (relatie reflexiva). Colectia este lista de entitati care participa la o relatie.
Uneori relatiile au propriile lor atribute. Acestea sunt independente de apartanenta relatiei la la o colectie. De exemplu relatia BANCA-CLIENT , exprimata prin verbul Lucreaza, poate avea ca atribute data inceperii cooperarii (intre banca si client).
d) Modelul conceptual de prelucrare (MCP)
Procesele derulate la nivel conceptual sunt urmatoarele:
Transfer sume valuta intre PSV si CSV;
Intrarea sumelor in valuta prin transfer de la banca;
Cumparare/vanzare de valuta;
Raportari lunare catre BNr.
Dam in continuare un exemplu de reprezentare a unui proces izolat (transferul sume valuta PSV-CSV ) si apoi un exemplu de inlantuire a doua procese (cumparare-vanzare valuta si raportari livrare catre BNR)
PSV
BMITPSV
a
1. TRANSFER SUME VALUTA PSV-CSV
verificarea sumelor transmise intre PSV si CSV.
OK OK
RZT
Procesele cumparare-vanzare valuta si raportari livrare catre BNR
PERSOANA FIZICA PSV
BI AI PT PS XX
f g h i j k
f g h i jÙk
CUMPARARE/VANZARE VALUTA
- inregistrarea cumpararilor de valuta in BC
- inregistrarea vanzarilor de valuta in BV
- inregistrarea cheltuielilor PSV
OK OK
L n p b
BOC JCV m BC RC RZT
l m p b
lÙmÙpÙb
4. RAPORTARI LIVRARE CATRE BNR
- calculul totalului miscarilor in valuta;
la nivelulCSV
- elaborarea RBNR
OK OK
r s
TM RBNR
BNR
Modelarea organizationala
Deoarece modelarea organizationala vizeaza repartitia organizationala a sistemului informational (arhitectura si localizarea fizica a retelei de calculatoare, solutia bazei de date) vazuta prin prisma departamentelor, serviciilor si posturilor de lucru si in cazul unei case de schimb valutar, organizarea este prea simpla pentru a aplica modelul organizational, consideram suficiente detaliile prezentate la curs in legatura cu acest tip de modelare.
Concluzie la primele trei etape ale metodei Merise si la activitatea de analiza in cazul in care in locul acestei metode se folose ste o alta metoda cum ar fi cea a fluxurilor de date.
Indiferent de forma de prezentare a informatiilor culese de analist, din acestea trebuie sa reiasa:
- obiectivele firmei, functiile specifice, atributele conducerii si modul in care sunt derulate activitatile ei; organigrama structurii organizatorice
- domenii de activitate, definirea subsistemelor informatice si/sau aplicatiilor;
- informatiile de care au nevoie persoanele din unitate pentru exercitarea sarcinilor ce le revin;
- datele (tipologia, descrierea lor, volumul, marimea, periodicitatea, amplasarea pentru prelucrari locale, teletransmisie, retele, etc.) vehiculate in unitate pentru fiecare loc de munca;
- cand, cum, de catre cine si ce date circula, se transforma sau se inregistreaza;
- ordinea de prelucrare si dependenta dintre datele trecute prin diverse activitati desfasurate;
- regulile prin care se specifica modul in care sunt transmise si prelucrate datele;
- politicile si orientarile care descriu modul in care se desfasoara activitatea unitatii, tinandu-se cont de mediul si piata in care functioneaza;
- evenimentele marcante si momentele declansarii lor, prin care se schimba valoarea datelor;
La sfarsitul acestei etape trebuie sa dispunem de toate informatiile necesare pentru a putea trece la etapa de proiectare logica.
4. Documentatie pentru etapa de modelarea logica
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 persoana |
NUME |
C,40 |
NUME<>"" |
|
|
C,20 |
|
tip AI |
TIP_AI |
C,2 |
TIP_AI= |
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)>=" DTOC(DATA_OP)=<" |
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 cate un calculator cu structura de workstation, pentru fiecare PSV:
PSV
PC- AT(WS)
c) Modelul logic de date
Se refera in principal la transformarea MCD (modelul entitate-relatie) in relatii. Cuvintele relatie si relatii nu au acelasi inteles. Modelul entitate-relatie este de fapt modelul entitate-legatura, in timp ce relatia in care se transforma acest model in cadrul modelului logic, nu este o legatura ci este echivalentul entitatii in algebra relationala. Acolo se opereaza cu relatii in sensul de tabel bidimensional format din randuri (linii) numite tupluri si coloane numite domenii. Pentru casa de schimb valutar, MLD arata astfel:
0
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:
Ordinea de actualizare a BD |
Ordinea de listare |
|||||||||||||
BC |
BV |
RC |
JCV |
JVV |
RBNR |
TM |
||||||||
1. CLIENTI | ||||||||||||||
2. VALUTE | ||||||||||||||
TRANZ | ||||||||||||||
4. MISC. |
Din acest tabel se vede ca 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 sincronizarile aferente;
tipul fazelor: A (automate) si M (manuale).
Pentru aceasta se pleaca de la MCP. Mai exact operatiile complexe sunt transformate in faze iar operatiile elementare sunt transformate in sarcini:
FREC- VENTA |
BANCA |
PSV |
CSV |
TIP A/M |
|
BMITB EXC |
BMITPSV BMSI |
BMITPSV a a 1. TRANSFER SUME VALUTA PSV-CSV - verificarea sumelor transmise intre PSV si CSV. OK OK b RZT d c c d
verificarea sumelor primite de la banca actualizarea OK OK e b BMSI RZT |
M M |
FREC- VENTA |
PERSOANA FIZICA |
PSV |
CSV |
TIP A/M |
||
k Z L |
BI AI PT PS XX |
BMECH |
j i h g f f g h i jÙk
- inregistrarea cumpararilor de valuta in BC - inregistrarea vanzarilor de valuta in BV - inregistrarea 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. RAPORTARI LIVRARE CATRE BNR - calculul totalului miscarilor in valuta la nivelulCSV - elaborarea RBNR OK OK RBNR TM |
A A |
5. Modelarea fizica
Descrieri si definitii (se fac referiri la urmatoarele aspecte):
- proiectarea strategiilor de prelucrare distribuita: modalitatile in care utilizatorul poate sa dispuna de date si facilitati de prelucrare distribuite in retea. In detaliu aceste modalitati vor fi prezentate in MFC (punctul b)
- proiectarea fisierelor fizice si a bazelor de date: aceasta vizeaza descrierea modului in care datele vor fi stocate si accesate in/din memoriile secundare si cum se va asigura controlul lor pentru a se oferi o securitate maxima. Concret solutia va fi dezvoltata la punctul c (MFD).
- proiectarea structurii sistemului si a programelor: sunt descrise programele si modulele acestora urmarindu-se ca ele sa fie in concordanta cu diagramele fluxurilor de date sau cu MLP (depinde de metoda de abordare a sistemelor informationale folosita) si cu celelalte piese ale documentatiei realizate in etapele anterioare;
In legatura cu proiectarea fizica trebuie avut in vedere ca daca in fazele precedente s-au cautat raspunsuri la intrebarea 'Ce trebuie sa facem?' acum trebuie sa raspundem la intrebarea 'Cum vom face ce ne-am propus in etapele anterioare?'.
Fiind ultima faza inainte de implementare, proiectarea fizica este ultima sansa de punere de acord a solutiilor noastre cu cerintele utilizatorului dar si cu realitatea in care va functiona sistemul.
b) Modelul fizic de comunicatie (MFC)
Generarea concreta a unui model fizic de comunicatie (MFC) presupune realizarea in principiu a urmatoarelor elemente specifice:
interconectarea topologiilor de tip LAN specificate in MLC;
securitatea LAN:
servicii de securitate:
controlul accesului
autentificarea
confidentialitatea datelor
integritatea datelor
nonrepudierea.
- mecanisme de securitate:
criptarea;
- semnatura digitala;
controlul acordului;
integritatea datelor;
integritatea unui camp sau a unei entitati de date;
integritatea unor campuri sau a unor siruri de unitati de date;
schimburi de autentificare;
controlul dirijarii: selectia fizica a cailor alternative;
notarea: asigura faptul ca proprietatile datelor communicate intre doua sau mai multe entitati sunt autentice sub aspectul integritatii, originii, timpului si destinatiei.
c) Modelul fizic de date (MFD) are rolul de a evidentia urmatoarele elemente:
specificatorul asociat relatiei la nivel fizic (denumire tabel/relatie in viziunea beneficiarului si denumire tabel ca fisier, de ex. C:SICSVvalute dbf);
structura inregistrarii;
accesul si spatiul fizic specific relatiei;
constrangerile structurale referentiale interrelatii;
Tabelul urmator este un exemplu de descriere a relatiei "VALUTE":
MFD |
|||||
1. ENTITATEA |
Relatia fizica |
||||
Valute |
C:Exchangevalute.dbf |
||||
2. ACCESUL SI SPATIUL FIZIC |
|||||
Indexare |
Spatiul fizic ocupat |
||||
chei |
Fisier index |
RCS |
R |
Total octeti |
|
CP CS |
COD_V |
Valute.ndx | |||
CONSTRANGERI STRUCTURALE REFERENTIALE INTERRELATII |
|||||
identificator relatie |
CP |
CE |
|||
TRANZ |
Nr_bsv |
Cod_v |
|||
MISC |
Nr_doc |
Cod_v |
|||
4. STRUCTURA INREGISTRARII |
|||||
Nr. |
Identificator |
Tip, lungime |
Conditii de validare |
||
COD_V CURS_CUMP CURS_V PROC_C |
C,3 N,3 N,4 N,6,2 |
COD_V= 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 intocmi cate un tabel ca cel de mai sus, pentru fiecare entitate.
Videoformatele de I/E:
se intocmeste o lista cu videoformatele (formularele) dupa modelul urmator:
Videoformatul |
Descriere |
Figura |
||
Tip |
Denumire |
Identificator |
||
I |
Buletin de cumparare |
BC |
Asigura introducerea datelor aferente cumpararilor de valuta |
19 |
se include macheta fiecarui formular specificat in tabelul de mai sus.
Meniuri de prelucrare
Se face precizarea ca meniul principal de prelucrare pentru aplicatia . este format din urmatoarele optiuni si suboptiuni descrise in ordinea utilizarii acestora: (urmeaza un tabel cu structura celui de mai jos, exemplificat pe inceputul tabelului specific unei case de schimb valutar):
Optiunea |
Suboptiunea |
Nivel |
Descriere |
Figura |
PSV |
Crearea, schimbarea si eliminarea PSV | |||
PSV schimbare |
Schimbarea PSV activ | |||
PSV creare |
Crearea unui PSV nou | |||
PSV eliminare |
Stergerea unui PSV | |||
CONFIGURARE |
Parametrizarea sistemului | |||
Generala |
Particularizarea PSV: exercitiu financiar, parametrizarea PSV, procentul de variatie intre cursul de vanzare si cel de cumparare, precum si conturile folosite: 5311 - casa in lei; 708 - comision cumparare; 708 - comision vanzare; 704 - diferente pret cumparare/vanzare | |||
Utilizatori |
Definirea utilizatorilor si a drepturilor de acces | |||
Imprimanta |
Parametrizarea nmelui si tipului de imprimanta Lungimea si latimea hartiei folosite | |||
Culori |
Parametrizarea culorilor pentru ecran si date | |||
Semnal sonor |
Stabilirea frecventei si duratei semnalului sonor | |||
Fisiere |
Descrierea atributelor bazei de date |
Fig. 11 |
||
Devize |
Declararea devizelor (valutelor): cod, denumire, contul Casa in valuta 5314, precum si: data cursu-lui, cursul BNR, curs cumparare, curs vanzare, etc. |
Tabelul continua, dar cele prezentate mai sus sunt suficiente pentru a reflecta spiritul in care se elaboreaza macheta meniului. In continuare in documentatie vor fi incluse machetele submeniurilor ce apar la alegerea unei optiuni de meniu si daca este cazul se coboara in jos pe arborele meniului pana la ultimul nivel
d) Modelul fizic al prelucrarilor (MFP) are rolul de a ilustra identificatorii procedurilor, schemele de sistem, intrarile, iesirile si functiile asociate acestora. Pentru aceasta se intocmeste un tabel ca cel de mai jos:
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
|
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:SICSVCLIENTI.dbf C:SICSV CLIENTI.ntx C:SICSVVALUTE.dbf C:SICSVVALUTE.ntx C:SICSVTRANZ dbf C:SICSVTRANZ.ntx C:SICSVMISC.dbf C:SICSVMISC.ntx |
Introducere si validare tranzactii valutare. Listarea Iesirilor SICSV Configurare BD |
In continuare se mai specifica:
- ordinea de apelare a optiunilor meniului principal care este urmatoarea
4 PSV
5 CONFIGURARE
FISIERE/BD
BULETINE
LISTARI
8 REVENIRE DOS
configuratia minima a calculatorului pe care urmeaza a se instala aplicatia;
- comenzi prin care se face instalarea si comenzi de lansare a aplicatiei in exploatare. Daca sunt necesare anumite comenzi ce trebuie sa fie prevazute in fisiere CONFIG.SYS, se vor specifica si acelea.
Anexa 6 Exemplu de program de casa de schimb valutar
(prezentat prin intermediul manualului de utilizare)
1. Functiile programului
Realizarea practica a acestui proiect consta intr-un sistem informatic denumit pe scurt in acest capitol, programul pentru casa de schimb valutar, care permite utilizatorului sa rezolve principalele momente din activitatea unei case de schimb valutar, respectiv a unui punct de schimb valutar.
Aceste momente sau activitati se reflecta atat in structura meniului sistemului cat si in aspectul formularului numit Coperta care este un formular de tip Main sau MDI, adica este prezent pe ecran tot timpul cat sistemul este pornit si este folosit ca pupitru de comanda a sistemului.
Cu ajutorul meniului si a formularului Coperta, sistemul poate indeplini urmatoarele functiuni:
- implementarea sistemului intr-o casa de schimb valutar data;
- actualizarea cursului oricarei valute in raport cu valuta de referinta (pentru moment acesta fiind dolarul SUA) si actualizarea pe aceasta baza a cursului leului nou cu oricare din aceste valute;
- actualizarea zilnica a comisionului pentru vanzare si respectiv pentru cumparare;
- miscari de valuta intre banci si casa de schimb sau un punct de schimb valutar apartinand casei de schimb care poseda programul;
- miscari de valuta intre casa de schimb sau un punct de schimb valutar si alt punct de schimb;
- schimb de valuta cu clientii;
- inregistrarea automata in baza de date a sistemului a tuturor schimbarilor de curs valutar, de comisioane, a miscarilor de valuta, precum si a tuturor operatiilor de vanzare-cumparare valuta la si de la clienti;
- elaborarea de rapoarte specifice activitatii de schimb valutar:
- Jurnal cumparari valuta;
- Jurnal vanzari valuta;
- Borderou de cumparari;
- Borderou de vanzari;
- Raport BNR;
- Totaluri miscari;
- Registru de casa;
- consultarea tabelelor cu buletine de cumparare si de vanzare, cu miscari, tabelul de incasari-plati si tabelul clienti, operatii necesare pentru revizii financiare, verificari cu scop de investigatii, etc.
2. Implementarea programului
La prima pornire a sistemului se va raspunde la cod utilizator cu 1 si la parola cu Admin01. In continuare, se va apasa butonul "Apasa aici si ca urmare, se va deschide formularul Coperta cu meniul sau. Imaginea meniului urmata de cea a formularului Coperta, se poate vedea pe pagina urmatoare. Tot la prima pornire, dupa aparitia meniului, prima grija a utilizatorului, care normal ar trebui sa fie administratorul, este sa schimbe parola sa, si apoi sa introduca toti utilizatorii calculatorului in fata caruia se afla in acel moment. Aceasta operatiune se va repeta pentru fiecare calculator din dotarea casei de schimb valutar (CSV) si a punctelor de schimb valutar (PSV).
Pentru schimbarea parolei, administratorul va alege submeniul "Actualizare date variabile", si
apoi optiunea "Schimbare parola operator in tura", cand va apare un formular care-i va cere codul
sau si parola veche. Daca parola este corecta va fi invitat sa introduca noua parola, dupa care poate iesi din acel formular.
In continuare la prima deschidere a programului, administratorul va alege submeniul "Implementare" si apoi optiunea "Utilizatori", cand ii va aparea un formular pentru introducerea tuturor utilizatorilor acelui calculator. Utilizatorii vor fi introdusi cu coduri care ar trebui sa fie numere (diferite de 1 care este rezervat administratorului), diferite pe intreg efectivul casei de schimb valutar, de la un utilizator la altul.
Parola fiecarui utilizator trebuie sa fie mai lunga de 5 caractere, sa fie unica pe intreg efectivul casei de schimb valutar si provizorie, urmand ca la prima ocazie cand un utilizator intra in tura, dupa ce a fost recunoscut de calculator cu parola introdusa de administrator, sa-si introduca o parola noua stiuta numai de el. Cu exceptia administratorlui, nici un utilizator nu poate schimba decat propria sa parola si pentru aceasta el trebuie sa fie acela care a pornit calculatorul si nu altcineva!
Tot in cadrul implementarii, administratorul trebuie sa ruleze pe rand fiecare din optiunile submeniului Implementare. Aceste optiuni pot fi vazute in imaginea alaturata si din ea se poate deduce ca este vorba de completarea datelor pentru societate, datele punctelor de schimb, datele pentru nomenclatorul de valute, cursuri si comisioane, precum si tipuri de acte de identitate acceptabile pentru schimbul valutar.
In continuare sunt prezentate imagini ale formularelor ce trebuie completate pentru fiecare din aceste optiuni. Este vorba de formularul date firma, aferent optiunii Societatea, formularul datepsv folsit de optiunea Puncte de schimb si de formularul Util folosit pentru introducerea datelor despre utilizatori.
In continuare sunt prezentate formularele aferente optiunilor nomenclator valute, curs si comision si tipuri de acte de identitate. Este vorba de formularul nomenclator valuta, curs BNR si comision, precum si formularul ActId.
In general completarea acestor formulare nu ridica probleme deosebite, cu exceptia nomenclatorlui de valuta care in afara de informatiile specifice acestui nomenclator, el mai contine asa cum se poate vedea in imaginea de mai jos, cursul valutei in raport cu valuta de referinta (dolarul SUA), rata la cumparare si rata la vanzare in lei noi. Daca o valuta nu este utilizata in mod curent atunci cursul in raport cu referinta trebuie pus ca fiind zero.
Exceptie de la celelalte valute face leul nou pentru care nu se cere decit suma in lei noi disponibili in casa si valuta de referinta. Celelalte date nu se cer pentru leul nou deoarece ele rezulta de la valuta de referinta unde se cer ratele de schimb la cumparare si la vanzare pentru valuta de referinta exprimate in lei noi.
Inceputul zilei
Pentru ca in mod normal zilele se succed una dupa alta, orice inceput al zilei este precedat de inchiderea zilei precedente (sectiunea 4). La terminarea activitatilor specificate la implementare, problemele legate de inceputul zilei (probleme care vor fi specificate mai jos) sunt rezolvate in mod implicit prin activitatile de implementare care s-au derulat conform sectiunii 2. Totusi in aceasta zi, dupa implementare, este bine sa se faca inchiderea zilei precedente, adica sa se ruleze submeniul Inchiderea zilei, dar cand programul cere data zilei care se incheie sa dati data zilei precedente si nu a zilei in care va aflati, pentru ca ziua in care va aflati va fi inchisa seara la terminarea programului. Daca acum, la implementare inchideti ziua de astazi, seara la terminarea programului, nu o veti mai putea inchide pentru ca orice zi poate fi inchisa doar o singura data. Ca urmare a acestei restrictii, daca odata ati intirziat cu inchiderea zilei curente dupa ora 24, atunci cand faceti inchiderea aveti grija sa specificati nu data zilei in care va aflati ci data zilei pentru care se face inchiderea. Aceste restrictii rezulta din faptul ca inchiderea unei zile de lucru se incheie cu initializarea soldurilor pentru ziua urmatoare si cu initializarea rulajelor de valute astfel ca ele sa inceapa in ziua urmatoare de la zero. Intr-o zi obisnuita de lucru insa, dupa inchiderea zilei precedente, este necesar sa se deruleze activitatile de mai jos, adica activitatile specifice unui inceput de zi.
Inceputul zilei se face din submeniul "Actualizare date variabile" si consta in introducerea cursului leului ca si a celorlalte valute in raport cu valuta de referinta conform BNR (folosind optiunea Curs la CSV care deschide formularul nomenclator valuta) si in introducerea ratei de vanzare-cumparare in lei grei a valutei de referinta. In continuare, pe baza acestor date, daca se apasa butonul Calculez si stochez automat ratele de schimb pt. toate valutele active din formularul nomenclator valuta, se face calculul automat al ratei de schimb la cumparare si vanzare in lei, pentru fiecare valuta. Tot acum, cu optiunea Curs si comision care deschide formularul Curs BNR si comision, se poate schimba comisionul pentru cumparare si vanzare de valuta.
De remarcat ca ratele de vanzare-cumparare in lei grei, daca se introduc manual pentru fiecare valuta, atunci trebuie validate prin apasarea butonului Stochez ratele de schimb pentru aceasta valuta din formularul nomenclator valuta. De asemeni dupa schimbarea comisioanelor, acestea nu intra in vigoare pana ce nu se apasa butonul Validez comisioanele si cursul BNR din formularul Curs BNR si comision. Cu ocazia acestor validari toate schimbarile de rate de schimb la vanzare-cumparare in lei grei, ca si comisioanele si cursul BNR se stocheaza automat in tabele-jurnal pentru arhivare.
Spre deosebire de inchiderea zilei de lucru care se poate face doar o singura data pe zi, operatiile descrise in legatura cu inceputul zilei se pot repeta d.p.d.v. tehnic ori de cate ori se schimba ratele de schimb sau comisioanele. Este obligatia operatorului sa respecte prevederile legale referitoare la modul de schimbare a ratelor de schimb in lei si la schimbarea comisionului.
4. Inchiderea zilei
Aceasta ar trebui sa fie ultima rulare care se face in cursul zilei care se incheie (sau, daca ea nu s-a facut in ziua precedenta, ar fi prima rulare inainte de a face Inceputul zilei curente). Prin aceasta optiune se calculeaza rulajele din ziua care se incheie pentru fiecare valuta in parte, apoi soldul curent devine sold initial pentru ziua urmatoare, se initializeaza rulajele la fiecare valuta cu zero si in plus se calculeaza toti indicatorii statistici in valuta de referinta: soldul total in valuta de referinta, total intrari prin cumparare de valuta dar in valuta de referinta, total iesiri prin vanzare de valuta dar in valuta de referinta, total intrari prin miscari in valuta de referinta si total iesiri prin miscari in valuta de referinta, profitul in lei si in valuta de referinta la sfirsitul zilei. Prin miscari se intelege in acest program, operatii cu banca cu celelalte puncte de schimb sau cu CSV, cheltuieli si alte tranzactii cu lei si valuta decat cele cu clientii prin vanzare-cumparare de valuta.
Indicatorii sintetici sunt afisati automat la terminarea operatiunii de inchidere a zilei.
5. Derularea activitatilor curente intr-un PSV sau CSV
Dupa efectuarea operatiilor legate de inceputul zilei, operatorul de calculator poate desfasura activitatile curente si anume schimburi de valuta cu clientii, miscari de valute intre PSV sau CSV in care se afla calculatorul si alte PSV, tranzactii de valuta cu bancile, eventuale cheltuieli, etc.
Pentru usurinta exploatarii acestui program, alegerea acestor operatii nu mai necesita utilizarea meniului pentru ca ele se pot lansa cu butoanele existente pe formularul Coperta a carui imagine a fost data mai sus. In continuare este descris modul de utilizare a butoanelor de pe formularul Coperta. Cu aceasta ocazie se pot vedea si posibilitatile acestui program si facilitatile pe care le pune la dispozitia operatorului.
a) Butonul Schimb valutar. Astfel la apasarea butonului Schimb valutar apar alte doua butoane, Cumparare si Vanzare.
Daca se alege butonul Cumparare vor apare butoanele Disponibilitate lei si Inregistrare client. Cu butonul Disponibilitate lei care deschide formularul Testare-cumparare ce se poate vedea mai jos, se verifica daca avem suficienti lei in casa pentru a putea cumpara suma oferita de client. Putem cumpara aceasta suma atat cu lei noi cat si cu lei vechi sau daca clientul accepta, combinat o parte lei noi si o parte lei vechi. Cu butonul Inregistrare client se deschide formularul Clienti. Acest formular permite inregistrarea clientului si tot din acest formular, utilizand butonul Buletin de cumparare, vom putea edita buletinul de cumparare.
La apasarea butonului Date client din formularul Buletin-cumparare datele clientului se completeaza automat in buletinul de cumparare, fiind folosite datele utilizate la completarea formularului Clienti. Dupa completarea campurilor cod valuta si suma intrata, celelalte campuri se completeaza automat, pana la campurile platit in lei noi si platit in lei vechi care se vor completa manual de operator in functie de sumele disponibile in casa.
In final operatorul poate vizualiza buletinul, apoi daca mai are ceva corectii va face corectiile dorite si in final va putea tipari buletinul. Un exemplu de buletin pentru cumparare valuta poate fi vazut pe pagina urmatoare. Dupa tiparire, tranzactia se inregistreaza automat in registrul incasari-plati si tot automat se actualizeaza soldurile afectate de aceasta tranzactie.
In mod similar vor decurge si vanzarile de valuta care se efectueaza cu ajutorul butoanelor Vanzare, Disponibilitate de valuta si Inregistrare client. Diferenta fata de cumparare valuta consta in faptul ca pe formularul clienti apare butonul numit Buletin vanzare cu ajutorul caruia se redacteaza Buletinul vanzare. Ca si in cazul buletinelor de cumparare, formularul pentru redactarea buletinelor de vanzare permite atat vizualizarea cat si tiparirea buletinelor de vanzare.
Merita retinut faptul ca toate documentele editate cu acest program (buletine de vanzare-cumparare, buletine de miscari, etc.) sunt la dispozitia operatorului doar cat timp le editeaza. Dupa ce un astfel de document a fost tiparit, el poate fi vizualizat dar nu mai poate fi modificat.
b) Butonul Miscari. La apasarea butonului Miscari, apare formularul cu acelasi nume care se poate vedea mai jos si cu ajutorul caruia se pot redacta toate tipurile de buletine de miscare. Diferenta dintre miscarile de valuta se poate indica prin tipul operatiei (intrare sau iesire) si prin tipul buletinului de miscare care poate fi pentru banca, pentru un PSV, cheltuieli sau alte miscari. Variantele de raspuns la ambele cimpuri se iau dintr-un combobox pentru a usura introducerea datelor, dar mai ales pentru a evita posibilele erori de completare.
Ca si buletinele de vanzare sau cumparare s buletinele de miscare trebuie mai intai vizualizate si apoi tiparite. Cu ocazia tiparirii ele sunt inregistrate automat in tabelul incasari-plati si tot atunci se actualizeaza soldurile valutelor afectate de miscarea respectiva.
c) Butonul Colectii de documente serveste la consultarea tabelelor cu buletine de cumparare si de vanzare, cu miscari, tabelul de incasari-plati si tabelul clienti, operatii necesare pentru revizii financiare, verificari cu scop de investigatii, etc. Toate formularele ce se pot vedea cu butoanele care apar la apasarea acestui buton sunt bune numai pentru vizualizare colectii de date nu si pentru editarea de noi documente. Ca aspect ele seamana cu cele prezentate mai sus, de aceea mai jos este prezentata din aceasta grupa de formulare numai imaginea formularului Incasari si plati. Ultimul camp, cel care nu a incaput in imagine este Plati in valuta echivalenta.
d) Butonul Rapoarte. La apasarea acestui buton se deschide formularul Liste, a carui imagine este cea din stanga. Pe acest formular se gasesc butoane pentru obtinerea tuturor rapoartelor cerute de legislatia in vigoare si anume: Jurnal cumparari valuta, Jurnal vanzari valuta, Borderou de cumparari, Borderou de vanzari, Raport BNR, Totaluri miscari si Registru de casa. Formularul Liste se poate deschide si din submeniul Rapoarte.
Pentru a obtine Jurnalul cumparari valuta sau Jurnalul vanzari valuta, ni se cere sa dam perioada pentru care se doreste raportul.
In cazul borderourilor de cumparare, respectiv de vanzare valuta, se cere data pentru care se va elabora raportul.
Pentru Raport la BNR si Totaluri miscari se cere denumirea lunii pentru care se elaboreaza raportul.
Raportul intitulat Registrul de casa se scoate zilnic si de aceea se cere data la care se refera raportul.
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 4279
Importanta:
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved