Home - Rasfoiesc.com
Educatie Sanatate Inginerie Business Familie Hobby Legal
Doar rabdarea si perseverenta in invatare aduce rezultate bune.stiinta, numere naturale, teoreme, multimi, calcule, ecuatii, sisteme



Biologie Chimie Didactica Fizica Geografie Informatica
Istorie Literatura Matematica Psihologie

Informatica


Index » educatie » Informatica
» PROIECTAREA LOGICA A SISTEMELOR INFORMATIONALE


PROIECTAREA LOGICA A SISTEMELOR INFORMATIONALE




PROIECTAREA LOGICA A SISTEMELOR INFORMATIONALE

Exista trei variante de abordare a proiectarii logice:

- iesiri - intrari;

- intrari - iesiri;

- mixta.

Indiferent de varianta de abordare, proiectarea logica trebuie sa asigure:

- fundamentarea stiintifica a obiectivelor noului sistem;




- definitivarea continutului informational al iesirilor sistemului in concordanta cu obiectivele stabilite;

- determinarea bazei informationale necesara satisfacerii eficiente a obiectivelor propuse;

- formalizarea atributelor de intrare pentru adaptarea acestora la cerintele de prelucrare automata ale noului sistem (vezi sectiunea 7);

- structurarea sistemului informatic in subsisteme si aplicatii in scopul realizarii esalonate a acestuia.

Proiectarea logica incepe cu definirea obiectivelor sistemului informatic si se incheie cu proiectarea structurala si functionala a sistemului informatic.

Intre aceste repere, proiectarea logica se desfasoara pe parcursul a trei subfaze sau pasi:

- proiectarea formularelor/formatelor (folosite la preluarea datelor) si proiectarea rapoartelor (folosite pentru extragerea si punerea in pagina sau pe ecran a datelor cuprinse in rapoarte);

- proiectarea interfetelor si a dialogurilor (folosite la comunicarea utilizatorului cu programul activ);

- proiectarea bazelor de date (modelul logic/relational al datelor).

In general se pleaca de la diagramele entitate-relatie, la care se vor adauga datele descoperite in timpul proiectarii logice. In aceasta actiune trebuie sa luam in consideratie evenimentele din diagramele de actiuni, ce declanseaza actiunile utilizatorului.

Sa retinem ca subfazele enumerate mai sus nu se parcurg secvential si o singura data, ci avem de a face cu un proces in spirala, care se repeta pana ce toate prelucrarile isi gasesc locul cuvenit.

La sfarsitul acestei faze vom sti precis tipul de sistem electronic de calcul folosit in sistemul informatic, precum si solutia de gestiune a datelor (BD locala, centrala sau mixta, gestionata prin SGBD sau EXCEL, etc.).

1. Definirea obiectivelor sistemului informatic

a) obiective generale:

- de conducere:

- rentabilizarea permanenta a activitatii economice;

- realizarea globala si structurala a indicatorilor economico-financiari, calculul si planificarea rezultatelor, planificarea financiara a investitiilor, previzionarea activelor circulante si a surselor de finantare, previziunea activitatii de trezorerie, inclusiv utilizarea bugetului general al unitatii economice;

- perfectionarea activitatii de conducere in vederea asigurarii unui optim global la 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, adaptate sistemelor electronice de calcul;

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

- obiective functionale pentru:

- activitatea comerciala;

- aprovizionare tehnico-materiala;

- desfacere a produselor/rezultatelor activitatii;

- marketing ;

-activitatea financiar-contabila:

- subactivitatea financiara (impozite, buget, relatii banesti,

decontari);

- contabilitate:

- contabilitate financiara (sintetica);

- contabilitate si gestiunea (analitica);

- control financiar;

- activitatea de personal:

- evidenta personalului;

- salarizare;

- perfectionarea calificarii personalului.

b) obiective specifice:

obiectivele specifice activitatii de baza. Ele trebuie sa urmareasca:

- utilizarea eficienta a capacitatilor de productie;

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

- realizarea ritmica si de calitate a lucrarilor de investitii;

- modernizarea utilajelor si a altor factori de productie;

- imbunatatirea continua a calitatii productei;

- 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: au un caracter particular, o pondere si o importanta diferentiata de la un agent economic la altul.

2. Proiectarea formularelor/formatelor si a rapoartelor

Sa observam ca deocamdata ne referim la formulare sau rapoarte existente in sistemul manual sau la machete de ecran.

a) Formularele au in structura patru elemente: introducerea, instructiunile, partea principala si concluziile:

- introducerea contine titlul, numarul formularului, numele si adresa destinatarului;

- instructiunile vizeaza modul de completare a formularului si destinatia lui dupa completare;

- partea principala contine viitoarele casute de text, deocamdata doar in macheta, grupate logic dupa inteles, dupa momentul sau locul completarii datelor;

- concluziile apar la sfarsit si se refera la inregistrarea informatiilor cu privire la dispozitiile finale si/sau aprobarile necesare in legatura cu operatiile

consemnate, incluzand semnaturile si data. Pe formularele cu operatiuni financiare va fi marcat locul totalului formularului.

Alte elemente de luat in calcul la proiectarea unui formular: tipul de hartie, formele si culorile caracterelor folosite in diferite zone ale formularului care trebuie concepute conform standardelor in vigoare, adresa care sa fie vizibila si prin fereastra plicului.

b) Rapoartele contin doar date predefinite si ca urmare pot fi considerate documente pasive. Pentru rapoarte se intocmesc modele demonstrative care trebuie sa fie acceptate de beneficiar. Pentru rapoartele care ies la imprimanta este bine sa se intocmeasca macheta imprimantei ( un formular cu 50 de linii si 150 de coloane). Este bine sa aiba pondere rapoartele grafice.

In raport cu timpul, rapoartele se clasifica in rapoarte programate (la termen), analize neprogramate ( rapoarte ad-hoc elaborate la intrebarile managerilor), rapoarte declansate de exceptii (au continut predeterminat, dar se elaboreaza in situatii de exceptie: depasiri de costuri, stocuri supradimensionate, etc.) si rapoarte la cerere (acestea au continut predeterminat, dar se elaboreaza numai la cererea managerilor).

Atat machetele formularelor cat si cele ale rapoartelor pot fi facute cu un editor de texte, cu o aplicatie pentru grafica pe calculator sau cu un program de calcul tabelar.

2.1 Specificatie de proiectare

Subfaza proiectarea formularelor/formatelor si de proiectare a rapoartelor se va incheia cu cate o specificatie de proiectare structurata pe trei parti: prezentarea descriptiva a iesirii, un model al proiectului si testarea si evaluarea comportamentului in utilizare. Un model de specificatie apare in figura urmatoare.

2.2 Caracteristicile datelor continute in formate/formulare sau rapoarte

Aceste caracteristici se completeaza prin raspunsul la intrebarea asociata fiecarei caracteristici dupa cum urmeaza:

- Tipul datei: este cel mai indicat pentru atingerea scopului propus?

- Corectitudine/Precizie: datele folosite sunt suficient de precise?

- Actualitatea: datele necesare se obtin la timp?

- Orizontul de timp: datele apartin orizontului de timp adecvat?

- Nivelul de sintetizare: datele sunt prea sintetice sau prea detaliate?

- Completitudine: datele sunt insuficiente sau excesive?

- Accesibilitate: datele sunt accesibile?

- Sursa: sursa este sigura?

- Relevanta/valoarea: datele vor influenta deciziile? Beneficiile vor depasi costurile?

Forma de prezentare a datelor: date formatate, text, imagini, audio, video, hypertext. Mai trebuie precizat care date sunt interne si care sunt externe, care se

obtin on-line si care pe hartie, care se prelucreaza on-line si care se prelucreaza pe loturi (documentele se acumuleaza si se prelucreaza la comanda ).

Recomandari generale de formatare a iesirilor

- sa aiba o introducere (partea de titlu) sugestiva;

- prezentarea foarte clara a numelui formularului in partea superioara a paginii, central;

- evidentierea numarului si datei;

- daca trebuie distribuit in alte locuri, care sunt acestea?

- specificarea datei de emitere a iesirii care poate sa coincida sau nu, cu data intocmirii;

- daca este cazul se va consemna ora iesirii.

a) Prezentarea descriptiva

Formular: Situatia contului CLIENTI

Utilizatori: Persoanele care urmaresc contul CLIENTI

Rol: Prezentarea informatiilor despre clienti: adresa, situatia la zi a contului

Sistem: Novell Network, Microsoft Windows

Mediu de lucru: Mediul unui birou standard

b) Modelul proiectului

S.C. LEBADA s.r.l.

SITUATIA CONTULUI CLIENTI Pagina 1 din 2

Data: 30–Martie-01

Cod client: 1234

Nume client: Dobrogea S.R.L.

Adresa: Varfu cu Dor, 45

Localitate: Constanta

Judet: Constanta

Tara: Romania

Cod postal: 8700

Vanzari la zi: 25.000.000,00

Incasari la zi: 15.000.000,00

Limita credit: 10.000.000,00

Procent reducere: 2,00

Sold la zi: 18,000,000,00

Starea:     Activ

c) Testarea si evaluarea comportamentului la utilizare

Gradul de perceptie a utilizatorilor (cca. 12 utilizatori):

Consistenta ( de la 1 – consistent, la 5 – inconsistent): 1.25

Suficienta (de la 1 – suficient, la 5 – insuficient): 1.12

Precizie (de la 1 – precis, la 5 – imprecis) 1.20

Exemplu de specificatie de proiectare [1]

- informatiile din instructiunile cu privire la iesiri:

- regulile de completare sa fie clare;

- sa se specifice etapa ce urmeaza dupa editare;

- sa se evite comentariile lungi, folosind in schimb rubrici cu nume sugestive;

- sa se consemneze destinatia fiecarui exemplar al documentului/raportului tiparit;

- informatiile oferite sa nu mai necesite si eventuale precizari manuale.

- partea principala (corpul iesirii):

- sa se faca o prezentare echilibrata evitandu-se incarcarile;

- folosirea corecta a spatierilor si marginilor;

- etichetarea corecta a rubricilor;

- gruparea logica a rubricilor;

- scoaterea in relief a zonelor ce marcheaza o alta rubrica;

- accentuarea prin linii sau culori a zonelor-cheie.

- Concluziile (finalul iesirii):

- sa fie plasate la sfarsitul paginii;

- sa fie alocat suficient spatiu pentru semnaturi;

- aici se vor prezenta ultimele indicatii (cele privind regimul de lucru cu documentul/raportul);

- totalurile vor fi puternic accentuate.

- Deplasarea lejera prin document (navigarea):

- de indicat in faza de editare, cum se pot efectua deplasarile inainte/inapoi;

- de aratat locul unde se afla utilizatorul (ex. pag. 4 din 12);

- de specificat cum se poate efectua iesirea din regimul de editare;

in cazul in care sunt mai multe pagini, semnalarea clara a ultimei pagini;

- tratarea ecranului dupa acelasi regim cu documentul original (clasificarea informatiilor d.p.d.v. al secretului si al accesului la ele);

- protejarea impotriva pierderii, modificarii, sustragerii ilegale sau din greseala a informatiilor.

2.3 Scoaterea in evidenta a informatiilor

- Forme de marcare a anumitor informatii sau grupuri de informatii aflate in interdependenta, a totalurilor, etc:

- marcaj clipitor/intermitent (blink);

- marcaj sonor;

- intensitati diferite de culoare;

- culori diferite (dar nu papagal!);

- diferentieri prin dimensiuni variate ale caracterelor;

- diferentieri prin fonturi;

- video invers;

- casete cu date grupate;

- subliniere;

- caractere majuscule;

- tiparirea informatiilor nestandard cu caractere diferite de celelalte.

- Imprejurari ce necesita scoaterea in evidenta a unor informatii:

- introducerea unor date eronate sau aparitia unor rezultate eronate;

- neincadrarea datelor in anumite limite sau starea de inoperativitate a unor echipamente;

- intrarea operarii intr-un regim anormal: se impune semnalarea prin comenzi, cuvinte cheie, mesaje;

- necesitatea afisarii sau tiparirii unor rubrici de subtotal sau total sau a unor rubrici in care se asteapta afisarea unei valori;

- existenta in pagina a unor zone comune;

- Probleme ce apar in legatura cu folosirea culorilor:

- anumite suprapuneri de culori duc la culori 'spalacite' sau culori 'fantoma';

- rezolutia este diferita de la un mediu de lucru la altul;

- fidelitatea culorii difera de la un mediu la altul; tiparirea sau conversia pe alt echipament ar putea crea probleme;

- culorile obosesc ochii, varianta alb-negru este mai odihnitoare, dar nu si mai placuta.

Recomandari referitoare la texte:

- caracterele: se recomanda folosirea literelor mari si mici, inclusiv respectarea regulilor de punctuatie;

- spatierea: daca este posibil, este de dorit folosirea dublei spatieri. Daca nu, se recomanda plasarea unei linii cu spatii intre paragrafe;

- alinierea : se recomanda alinierea textului la stanga, iar la nevoie partea dreapta poate ramane la stilul versurilor;

- liniuta de unire: nu se recomanda ca textele de pe ecrane sa contina cuvinte despartite in silabe de pe un rand pe altul;

- abrevierile: sunt permise numai pentru cuvintele care au o recunoastere generala.

2.5 Recomandari referitoare la tabele

Folosirea unor nume semnificative

- toate coloanele si randurile sa aiba nume (etichete) cat mai relevante;

- numele respective vor fi scoase in evidenta fata de celelalte prin tehnicile corespunzatoare, descrise anterior;

- reafisarea numelor coloanelor sau randurilor cand datele depasesc limitele unei pagini;

- evitarea numelor lungi, a ambiguitatilor generate de sensul cuvintelor folosite;

- pe cat posibil, de renuntat la despartirea in silabe;

- centrarea in cele mai multe cazuri a numelor coloanelor si alinerea la stanga a numelor randurilor.

Formatarea coloanelor, a randurilor si a textului

- sortarea intr-o ordine logica a datelor prezentate, dupa una sau doua chei ascendent sau descendent;

- folosirea unei linii cu spatii dupa fiecare cinci randuri atunci cand exista prea multe coloane;

- informatiile similare afisate in mai multe coloane trebuie sa fie sortate pe verticala, intrucat ordinea lor se urmareste pe coloana, deci de sus in jos si nu de la stanga la dreapta - pe linie;

- intre coloane sa existe cel putin doua spatii ;

- de lasat loc suficient pe rapoartele tiparite care sa-i permita utilizatorului sa introduca diverse adnotari;

- de folosit acelasi gen de caractere, cu exceptia cazurilor care trebuie sa fie scoase in evidenta;

- de evitat excesele de fonturi fanteziste, greu de citit.

Formatarea datelor de tip numeric, alfabetic sau alfanumeric

- datele numerice trebuie sa fie aliniate la dreapta si/sau pe marca zecimala, coloanele fiind astfel usor de citit;

- datele de tip text vor fi aliniate la stanga;

- se recomanda folosirea liniilor scurte de text, de regula de 30-40 de caractere, pentru o parcurgere usoara prin citire ( ca in cazul ziarelor);

- de evitat blocurile mari cu date alfanumerice; in astfel de cazuri trebuie gasite criterii de descompunere a lor in grupuri mai mici, mai usor de citit, deci si mai inteligibile, care sa nu aiba mai mult de 3-4 caractere, gen numere auto sau de telefon.

Elementele de baza ale unui tabel

- numarul tabelului: se va atribui consecutiv, in ordinea aparitiei, pe parcursul intregului raport, sub forma numerelor arabe. Numarul se va scrie la marginea din stanga, apeland la metoda numerelor duble ( de ex. 2.3) numai in rapoartele lungi care contin mai multe capitole, fara a se pune punct dupa ultimul grup de numere. Numarul si titlul se vor plasa deasupra tabelului, iar elementele suplimentare, in zona imediat urmatoare sub tabel;

- titlul tabelului: va fi scris la marginea stanga, la doua randuri sub numar. Prima litera a titlului si substantivele proprii se scriu cu litera mare, celelalte se scriu cu litera mica. Daca necesita a doua linie, ea va incepe tot de la stanga, la doua randuri. Nu se pune punct dupa titlu;

- liniile tabelului: in general tabelele au trei linii orizontale si nici una verticala! Ultima linie va delimita continutul tabelului de elementele suplimentare cum ar fi sursa tabelului si notele explicative;

- alte elemente ale unui tabel: titlul cotorului, titlul coloanelor, titlul coloanelor multiple, titlul liniei, subtitlul, sursa si notele explicative. Pozitia lor in tabel este data in macheta urmatoare:

(1) Numarul tabelului

(2) Titlul tabelului

(3) Linie__________ ______ ____ _____ _______ ______ ______________

(6) Titlul coloanelor multiple

(4) Titlul cotorului (5) Titlul coloanei Titlul coloanei

(7) Titlul liniei

(8) Subtitlu Date Date

Subtitlu Date Date

Titlul liniei Date Date

(3) Linie__________ ______ ____ _____ _______ ______ ______________

(9) Sursa:

(10) Note explicative

2.6 Utilizarea graficelor in rapoarte

Argumente ce pledeaza in favoarea graficelor in comparatie cu tabelele:

- un desen este mai sugestiv decat 1000 de cuvinte;

- se prezinta o sinteza riguroasa a datelor;

- marcarea celor mai importante elemente;

- exceptiile sunt usor de sesizat;

- evidentiaza eventualele corelatii dintre elemente;

- se poate aprecia tendinta in timp;

- se pot efectua comparatii multiple rapide;

- se ofera sansa efectuarii de prognoze;

- cantitatile mari de date valorice pot fi vizualizate mai simplu cu ajutorul unui grafic.

Tipuri de grafice: histograma, histograma cumulata, linie, diagrama de structura (de tip Pie). Datele pot sa apartina fie unei serii discrete (de ex. populatiile diferitelor orase), fie unei serii continue (date care se schimba in timp , de ex. evolutia populatiei unui oras).

Totusi, atunci cand ne intereseaza valori individuale, tabelele sunt de neinlocuit.

2.7 Criteriile de apreciere de catre utilizatori a formularelor/formatelor

- stabilitatea: folosirea acelorasi termeni, abrevieri, formate, titluri si metode de navigare in toate iesirile sistemului;

- eficienta: formatarea trebuie sa se deruleze in stransa concordanta cu sarcinile de executat. Textele trebuie sa fie aliniate, coloanele sortate, deplasarea sa fie usor de realizat. Pentru a formula cererile de iesire este de dorit ca pe cat este posibil sa fie necesare cat mai putine date;

- comoditatea: sa nu se faca trimiteri la afisari anterioare, sa se foloseasca etichete clare, precum si factori de scala corespunzatori;

- formatul: pentru aceleasi tipuri de informatii, este bine sa se mentina acelasi format; de asemenea sa se scoata in evidenta ceea ce este important. Printre caracterele tiparite este bine sa fie prezente la locul cuvenit semnele monetare, marcile zecimale, separatorii

ordinelor de marime si semnele +, _, %, etc.

- flexibilitatea: trebuie sa i se ofere utilizatorului posibilitatea de a lista in modurile dorite de el, de a opri procesul si de a naviga in locurile dorite.

Satisfactia utilizatorilor se poate rezuma la : timpul de invatare (acomodare), viteza de executie, rata erorilor, persistenta in timp (stabilitatea), satisfactii subiective.

3. Proiectarea interfetelor si a dialogurilor

3.1 Rolul interfetelor si al dialogurilor

3.1.1 Interfete

In Computer Technology interfata este definita ca un echipament sau un program conceput pentru a comunica informatii de la un sistem de echipamente electronice sau programe, la altul.

In ce priveste interfata utilizatorului care face obiectul acestei etape CVDS, ea este definita ca o combinatie a mijloacelor prin care un utilizator interactioneaza cu un sistem electronic de calcul. In prezent interfetele sunt toate grafice (Graphical User Interface - GUI). Cea mai populara este cea reprezentata de Windows prin meniuri, pictograme si mouse, dar mai exista interfete pentru calculatoarele dotate cu creioane optice, interfete pentru preluarea/redarea vocii si interfete multimedia, care asigura acces la text, sunet si imagine.

3.1.2 Dialogul

Dialogul este conversatia intre doi parteneri. Dialogurile se pot purta pentru simpla cooperare dintre utilizator si calculator, dar ele fac parte si din procesul decizional. Un sistem de sprijinire a procesului decizional are urmatoarele componente: managementul datelor, managementul modelelor si managementul dialogurilor. Acesta din urma poate fi redat schematic astfel [1]:


Module de intrare Module de iesire

bazate pe: bazate pe:

  • Limbaje de actiune

- tastatura

- mouse

- cititor optic

- creion optic, etc,

  • Limbaje de comanda

Subset al limbajului natural

Specificatii ale asistentei

prin meniuri

Specificatii de ecrane

(pentru completarea spatiilor

din rubrici)

Interfete tip pictograme

Activare voce

3.2 Metode si echipamente folosite in dialogul om-calculator

3.2.1 Metode de interactiune


- Interactiunea prin limbaj. Se bazeaza pe utilizarea comenzilor. Exista comenzi sintactice si comenzi secventiale. Comenzile se mai pot clasifica in comenzi mnemonice si comenzi-taste.

- interactiunea prin meniuri; se folosesc:

- liste simple;

- zone cu comenzi si linii meniu (meniuri pop-up sau drop-down);

- meniuri prin imagini (pictograme).

- interactiunea prin limbaj natural. Se afla in stadiu incipient.

3.2.2 Selectarea echipamentelor necesare interactiunii cu sistemul

Se folosesc: tastatura (Keyboard), Mouse, Joystick, Trackball, Touch Screen, Light Pen, Graphics Tablet si Voice.

3.3 Proiectarea interfetelor

3.3.1 Proiectarea machetelor

Se recomanda parcurgerea pasilor de mai jos [1]:

Pasii anteriori conceperii Pasii conceperii Pasii post-concepere


Stabilirea Determinarea

scopului operatiunilor de:

(Ce mesaj - completare

Revizuire

corectare

editare

 
trebuie sa - citire si actiune

transmita?) - citire si Schitarea

reamintire documentului

- aflarea de - selectarea

informatii unui continut

D

O

C

U

M

E

N

T

  Definirea Definirea adecvat

motivatiei (De beneficiarilor - organizarea

ce este nevoie (Cine va folosi lui pentru a fi

de acel documentul folosit mai

Evaluare

(Raspunde

documentul scopului

pentru care a fost conceput?)

 
document?) De ce ii este usor

necesar?) Determinarea - scriere clara

restrictiilor - folosirea

impuse de: graficii pentru

- sistem clarificarea

- modul de mesajelor de

folosire de transmis

- modul de

distribuire.

Machetele trebuie concepute astfel incat deplasarea pe ecran sa se faca de la stanga la dreapta si de sus in jos. La completarea formularului nu sunt permise salturile .

3.3.2 Criteriile de evaluare a performantelor interfetelor din programele de introducere a datelor

- deplasarea pe ecran/formular sau chiar in cadrul campului: la campul urmator, la precedent, la primul, la ultimul, eventual la oricare alt camp;

- posibilitati de editare: stergerea unui caracter, cuvant, rubrici/casete, linii, coloane, grup de caractere/casete; stergerea tuturor datelor din formular, adaugarea de noi caractere, inserarea de caractere;

- facilitati de iesire: salvarea ultimului ecran in baza de date, trecerea la alt ecran/formular, confirmarea salvarii sau trecerii la alt formular, iesire temporara din mediu de lucru ajutator (vizualizare ceas, folosire calculator de buzunar, etc.);

- oferirea de help: despre orice camp, despre intregul formular, despre alte elemente; posibilitati de control al accesului: restrictionarea accesului utilizatorilor, identificarea si autentificarea utilizatorilor, autorizarea unor categorii de utilizatori la anumite tipuri de date, criptarea datelor secrete, crearea nivelurilor de parole pentru acces ierarhizat la bazele de date, autentificarea utilizatorilor in timpul sesiunii dupa criterii aleatoare, pastrarea datelor despre utilizatorii aplicatiei pentru reconstituirea unor prelucrari sau accese la date, interzicerea modificarilor/stergerilor inregistrarilor anterioare care au un regim special;





- facilitati oferite la introducerea datelor: sa nu se ceara date usor de calculat cu datele existente, folosirea valorilor implicite, specificarea clara a UM, scoaterea in evidenta a modului de introducere a datelor numerice de exceptie (in milioane lei, in miliarde, etc.), trecerea automata la campul urmator cand s-a introdus un numar de caractere, specificarea continutului casetei (sub forma: titlu de linie, titlu dedesubt, titlu incasetat, caractere delimitatoare, bifare de casete de validare, oferirea de exemple cum ar fi Data: ZZ/LL/AA), alinierea automata a datelor introduse, oferirea de help in context (vezi capitolul XI), controlul tipului de caractere introduse;

- tehnici de validare a datelor: testarea daca datele sunt de tipul care se cere, testarea combinata a datelor din mai multe campuri (de ex. preturi mari combinate cu cantitati mici, etc), verificare daca datele sunt cele asteptate ( de ex. suma achitata este egala cu cota prima?), testarea lipsei datelor in unele campuri (Required), verificarea incadrarii unor date in anumite sabloane (input mask), verificarea incadrarii valorilor in anumite intervale, limitarea valorii maxime a unor date, utilizarea cifrei de control (vezi sectiunea 7.1), verificarea numarului de caractere introduse, verificarea existentei valorilor introduse in cadrul unei liste cu valori admise (de ex. combobox).

3.4 Proiectarea dialogurilor

Este procesul prin care sunt proiectate toate secventele folosite de utilizator pentru a comunica cu un sistem informatic. In aceasta etapa analistul si proiectantul trebuie sa selecteze cele mai potrivite metode si echipamente, sa prezinte conditiile in care se pot afisa informatiile precum si conditiile in care informatiile se pot obtine de la utilizator.

Operatiunea se efectueaza in trei etape:

- proiectarea secventei de derulare a dialogurilor;

- construirea prototipului;

- evaluarea comportamentului in utilizare.

La elaborarea dialogurilor trebuie sa se tina cont de urmatoarele reguli:

- uniformitatea dialogurilor sub aspectul derularii actiunilor, a utilizarii tastelor si a terminologiei (operatiunile identice sa aiba aceleasi denumiri pe ecrane diferite, iar locul lor de amplasare sa fie acelasi);

- comenzile sa fie scurte, sa se foloseasca short keys;

- feed-back-ul: fiecare operatiune, dupa terminare, sa faca cunoscut faptul ca s-a terminat si eventual care este rezultatul; nu se ofera direct cadrul pentru urmatoarea operatiune;

- marcarea sfarsitului: ultima secventa de ecrane sa indice faptul ca nu mai exista alte ecrane;

- rezolvarea erorilor: erorile trebuie sa fie detectate si afisate; se va sugera modul de rezolvare; se vor accepta forme multiple de raspuns (ca d, D, Da, etc);

- operatiunea inversa: de exemplu la stergere sa se poata reveni asupra stergerii; datele nu trebuie sterse fara confirmare. Inregistrarea trebuie mai intai afisata si numai dupa aceea sa poata fi stearsa;

- controlul: dialogul trebuie sa-i dea utilizatorului convingerea ca detine controlul asupra sistemului;

- usurinta lucrului cu sistemul: se vor folosi cele mai simple forme de introducere a datelor si de navigare pe ecran.

3.4.1 Proiectarea secventei dialogurilor

La proiectarea secventei dialogurilor, chiar daca nu folosim metoda Merise, este bine sa avem in fata un tabel asemanator celui cu modelarea organizationala a prelucrarilor (MOP) si eventual reprezentarea grafica a MOP, pe baza carora putem intocmi un tabel cu activitatile ce trebuie desfasurate de actori in cadrul sistemului informatic. In acest tabel, pentru fiecare activitate vom specifica fazele, actiunile, actorii, frecventele de prelucrare si tipurile de prelucrari anticipate (automate – A sau manuale – M). In acest tabel, unde pentru o activitate corespund mai multe faze si actiuni (separate intre ele cu linii orizontale), liniile orizontale nu pleaca din prima coloana, cu exceptia celor care urmeaza la sfarsitul prezentarii unei activitati. Indiferent daca intocmim un tabel de forma celui de mai sus sau beneficiem de alte forme de prezentare a informatiilor cum ar fi modelarea logica a prelucrarilor (MLP) din Metoda Merise, important este ca la inceperea proiectarii dialogurilor sa stim clar ce trebuie sa se execute la nivelul fiecarui agent, iar daca este cazul, sa cunoastem si conditiile de sincronizare ce trebuie sa existe intre diferiti agenti.

Numai cu aceste elemente la dispozitie, putem incepe proiectarea secventei dialogurilor.

Dialogurile se pot derula prin intermediul meniurilor, dar si al formularelor care pe de o parte sunt cele care realizeaza dialogul propriu-zis sau parti din el, iar pe de alta parte, ele pot apela alte formulare, uneori chiar sub influenta unor criterii ce se aplica rezultatelor dialogului curent.

In ce priveste meniurile, mai ales cele care la randul lor apeleaza alte meniuri, ele se pot reprezenta cu ajutorul unor diagrame de forma celei de mai jos [1]:


START

M01 Ctrl+End

MENIU PRINCIPAL

F9 F1 F2 F5

P01 M02 P02 P03

ADAUG_STUDENT MENIU_INTEROGARE MODIFIC_STUDENT STERG_STUDENT

F1 F2 F3

P04 P05

REVENIRE

INTEROGARE DUPA INTEROGARE DUPA (la meniul principal)

NUME_STUDENT MATRICOL_STUDENT

In aceasta diagrama cu M s-au notat meniurile, cu F sau notat formularele si cu P – procesele (procedurile).

Trecerea de la un meniu la altul poate fi redata si sub forma unei scheme de forma celei de mai jos [1]:

MENIU PRINCIPAL

ADAUG_STUDENT

MODIFIC_STUDENT

STERG_STUDENT

QUIT

MENIU_INTEROGARE

INTEROGARE DUPA NUME_STUDENT

INTEROGARE DUPA MATRICOL_STUDENT

In cazul dialogului multi-ecran intervin trei parti: operatorul, sistemul si o alta persoana care contacteaza direct sau telefonic operatorul.

Dialogul purtat duce la ramificarea proceselor, deci si a structurii de folosire a meniurilor, ceea ce concura la planificarea si controlarea tuturor scenariilor posibile.

Scenariile pot fi redate in doua variante: pe coloane multiple si scenarii-joc.

In varianta coloane multiple se poate folosi o structura tabelara de genul: conditii/evenimente externe, actiunea operatorului, afisarile din sistem, actiunea sistemului. Scenariile-joc au in structura text/conditii logice, actorii, actiunile.

3.4.2 Construirea prototipului si evaluarea comportamentului in utilizare

Construirea prototipului dialogului si evaluarea comportamentului in utilizare sunt in general activitati optionale. Pentru aceasta se pot folosi produse CASE sau facilitatile oferite de diferite medii de dezvoltare care dispun de wizard-uri, designere, builders, etc. cu care se pot face prototipuri sumare de formulare, rapoarte sau ferestre, dar cu care se poate testa apoi logica dialogului.

Pe timpul acestor testari trebuie avute in vedere si unele cerinte mai deosebite care tin de profesionalismul programatorului cum ar fi posibilitatea folosirii regimului de lucru cu 'Cut and Paste', setarea imprimantei, proiectarea formularelor de tip Top-Level, proiectarea meniurilor si a formularelor capabile sa ruleze intr-un formular de tip Top-Level, folosirea comenzilor spre alte aplicatii sau sub Windows (API, DLL, etc), dar si o categorie de cerinte care deriva din nevoia de a folosi cat mai eficient resursele de care dispunem.

Cateva din aceste cerinte sunt urmatoarele:

- daca folosim optiunea File, aceasta sa fie prima;

- Edit, sa fie a doua;

- Window este penultima;

- Help este ultima;

- o sageata plasata in dreapta unei optiuni ( ) indica faptul ca urmeaza un submeniu;

- trebuie sa marcam cumva elementele selectate sau activate (de exemplu bifate in stanga numelui);

- trei puncte ( . ) plasate in dreapta unei optiuni, semnifica faptul ca urmeaza un meniu pop-up sau chiar o fereastra de dialog;

- afisarea pe prima linie a unui text comentariu, referitor la pozitia pe care se afla prompterul;

- evidentierea pozitiilor ce mai pot fi activate fata de celelalte care nu pot fi folosite (de exemplu folosirea unor culori accentuate pe butoanele ce mai pot fi activate si a unor culori sterse pentru butoanele dezactivate).

Ferestrele sau ecranele ce se folosesc in aplicatii trebuie sa aiba unele trasaturi specifice cum ar fi:

- modalitatea (sa ceara decizia utilizatorului cu privire la modul prin care doreste sa infaptuiasca o actiune; de exemplu daca vrea sa iasa dintr-o fereastra, sa specifice cum: prin Cancel, prin Save, prin Ok, etc).

- redimensionarea;

- sa fie mobile (sa poata fi mutate dintr-un loc in altul) ;

- sa accepte maximizarea si minimizarea;

- sa accepte optiuni de meniu sistem pentru actiuni cum ar fi salvarea sau copierea datelor.

Trecerea de la o aplicatie la alta, selectarea anumitor functii inseamna multe comutari intre ele, ceea ce face necesara utilizarea diagramelor starilor de tranzitie, descrise la etapa de analiza.

4. Proiectarea logica a bazelor de date:

modelarea logica a datelor

In aceasta sectiune se are in vedere:

- definirea locului modelarii logice a datelor;

- simplificarea datelor prin normalizare;

- transformarea diagramelor entitate-relatie in relatii;

4.1 Locul modelarii logice a datelor in ciclul de viata al sistemelor

Activitatile legate de modelarea logica a datelor sunt o continuare a modelarii conceptuale a datelor efectuata in etapa de analiza. Ele pleaca de la diagramele entitate-relatie si tind spre descrierea structurii datelor din baza de date fizice descriere bazata pe modelul relational.

Modelarea logica a datelor se realizeaza nu numai pe baza diagramei entitate-relatie ci si pe baza machetei formularelor si a rapoartelor.

In procesul de modelare logica a datelor exista patru pasi:

a) Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare si rapoarte) privind aplicatia, folosindu-se principiile normalizarii.

De exemplu, daca utilizatorul solicita rapoartele 'Cel mai bun client al produsului X (ecran)' si 'Situatia comenzilor in curs (raport)', dispunand de macheta lor si analizand aceste machete [1], putem desprinde imediat din

Flowchart: Document: 		        Pagina 1
Situatia comenzilor in curs
	       31/03/2001
COD PRODUS    CANTITATI  DE  LIVRAT
A1111			0
A2222			0
B1111			150
 . 			 . 
Z9999			1000

Flowchart: Alternate Process: Cel mai bun client al produsului

Introduceti codul produsului:   P1122
Data de inceput:		 10/10/00
Data de sfarsit:		  31/12/00
-------- ----- ------ ----- ----- -----
COD CLIENT		   1111
NUME CLIENT       s.c. LEBADA srl
VOLUM:		    1000

analiza ecranului, existenta urmatoarelor relatii:

CLIENT (COD_CLIENT, NUME)

COMANDA (NR_COMANDA, COD_CLIENT, DATA_COMANDA)

PRODUS (COD_PRODUS) si

LINIE_COMANDA (NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA),

iar din analiza raportului existenta urmatoarelor entitati:

PRODUS (COD_PRODUS)

COMANDA (NR_COMANDA, DATA_COMANDA)

LINIE_COMANDA (NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)

LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)

FACTURA( NR_FACTURA, DATA_FACTURA).

b) Contopirea tuturor perspectivelor normalizate ale utilizatorilor intr-un model logic consolidat (centralizat) al datelor. Pasul mai este numit si integrarea perspectivelor

In exemplul de mai sus, aceasta presupune sa rezulte urmatoarele relatii:

CLIENT (COD_CLIENT, NUME)

PRODUS (COD_PRODUS)

FACTURA( NR_FACTURA, DATA_FACTURA)

COMANDA (NR_COMANDA, COD_CLIENT, DATA_COMANDA)

LINIE_COMANDA (NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)

LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA)

c) Transformarea modelului conceptual al datelor (entitate-relatie), realizat fara sa se tina cont de perspectiva utilizatorului, intr-un set de relatii normalizate.


COD_CLIENT NUME_CLIENT ADRESA NR_FACTURA

CLIENT FACTURA

Lanseaza Facturare

CANTIT. LIVRATA

COMANDA LIVRARE

CANTITATE-COMANDATA LINIE_COMANDA PRODUS

COD_PRODUS    DENUMIRE

Diagrama entitate-relatie pentru exemplul dat mai sus, realizata in etapa de analiza, mai exact in subetapa de modelare conceptuala este cea de mai sus [1].

Din analiza acestei diagrame se desprind urmatoarele relatii:

CLIENT (COD_CLIENT, NUME, ADRESA)

PRODUS (COD_PRODUS, DENUMIRE)

COMANDA (NR_COMANDA,COD_CLIENT)

LINIE_COMANDA (NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)

FACTURA( NR_FACTURA, NR_COMANDA)

LIVRARE(NR_FACTURA , COD_PRODUS, CANTITATE_LIVRATA)

d) Compararea modelului logic consolidat al datelor cu modelul transformat al entitatii-relatie si realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicatiei, dupa cum urmeaza:

CLIENT (COD_CLIENT, NUME, ADRESA)

PRODUS (COD_PRODUS, DENUMIRE)

COMANDA (NR_COMANDA,COD_CLIENT)

LINIE_COMANDA (NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA)

FACTURA( NR_FACTURA, NR_COMANDA)

LIVRARE(NR_FACTURA , COD_PRODUS, CANTITATE_LIVRATA)

Rezultatul modelarii logice a datelor il constituie relatiile normalizate obtinute din acest din urma pas al procesului, precum si actualizarea depozitului (repository) sau a dictionarului proiectului. In aceasta faza cerintele structurate de date se materializeaza in relatii si nu in entitati. Din cauza normalizarii nu este necesara o corespondenta de unu-la-unu intre entitati si relatii.

4.2 Simplificarea structurii datelor prin normalizare

Normalizarea bazelor relationale (eliminarea redundantelor si a anomaliilor de stocaj) inseamna obtinerea de relatii 'atomice', fara a pierde nimic din informatii. Dupa normalizare, urmeaza optimizarea schemei interne, constand in eventuale denormalizari (join-uri) si apoi se alege: modul de organizare a tabelelor, metode de acces, cheile de indexare.

Practic normalizarea inseamna sa eliminam 'dependentele functionale' folosind scheme de modelare care pot fi:

- schema de descompunere entitati;

- schema sintezei atributelor.

Dependentele functionale se refera la legaturile dintre atribute si pot fi:

- reflexive (ciclice);

- tranzitive;

- de crestere.

Dependentele functionale mai pot fi partiale sau totale, precum si multiple.

Normalizarea se face in 5 trepte (forme):

- 1NF: impune ca fiecare celula a tabelului sa contina o singura valoare nedecompozabila: daca exista caracteristici compuse (de ex. adresa = localit. + adresa), atunci vor rezulta mai multe caracteristici, daca exista mai multe caracteristici care fiecare in parte ar putea fi valori ale unui camp, vor rezulta mai multe tupluri.

- 2NF: impune sa fie indeplinit 1NF + fiecare caracteristica non-cheie sa fie dependenta de o cheie primara; daca exista campuri ce nu depind de toata cheia primara, ele vor fi plasate separat intr-un nou tabel a carui cheie primara va fi doar partea de care campurile in cauza depindeau si in vechiul tabel. Se elimina astfel dependentele partiale.

- 3NF: impune 2NF + sa nu existe dependente functionale tranzitive intre caracteristicile non-cheie. Tranzitiva inseamna ca un camp (caracteristica) X depinde de Y si acesta depinde de Z, dar X depinde direct de Z. In acest caz vom mai initia un tabel avand cheie primara pe Y, iar in acest tabel X va fi un camp non-cheie. Y va ramane si in vechiul tabel, ca un camp non-cheie.

Ceva intermediar intre nivelul 4 si 5 de normalizare este NF Boyce Codd (BCNF); acesta pretinde 3NF + pentru orice dependenta totala X-- A,

rezulta ca X este o cheie a lui R (tabelul in discutie).

- 4NF: impune BCNF + fiecare dependenta multipla devine o dependenta functionala;

- 5NF: impune 4NF + si nu are dependenta ciclica (joints) sau daca exista, sa fie implicata printr-o cheie secundara.

4.3 Transformarea diagramelor entitate-relatie in relatii

Intregul proces se deruleaza in patru pasi:

- Reprezentarea entitatilor. Fiecare tip de entitate din diagrama entitate-relatie este reprezentata ca o relatie in modelul relational al datelor. Identificatorul tipului de entitate devine cheie primara a relatiei, iar celelalte atribute ale tipului entitatii devin atribute non-cheie ale relatiei.

Exemplu: Entitatea angajat prezenta in DER sub forma

Nume

Marca Angajat Adresa

va fi descrisa ca relatie astfel: ANGAJAT (MARCA, NUME, ADRESA) sau tabular:

ANGAJAT

MARCA

NUME

ADRESA

Ionescu Adrian

str. Vasile Parvan, nr. 23, Mangalia

- Reprezentarea legaturilor. Fiecare legatura din diagrama entitate-relatie trebuie sa fie reprezentata in modelul relational al datelor. Reprezentarea legaturii se face in functie de natura ei. Astfel, uneori se poate constitui o relatie prin includerea cheii primare a unei relatii ca o cheie straina/externa in alta relatie. De exemplu, la prima vedere cineva ar putea prezenta o comanda de carte ca o entitate cu atributele nr_comanda, data_comanda si data_restituire. Dar la o analiza mai atenta se poate observa ca entitatea ar trebui sa mai aiba un atribut si anume numar_matricol, care este de fapt cheia primara a entitatii student si ca urmare s-au creat premisele unei legaturi intre relatia student si comanda_carte. Alteori, se poate crea o relatie separata pentru reprezentarea legaturii (cazul LINIE_COMANDA).

- Normalizarea relatiilor. Relatiile create in pasii precedenti pot contine redundante nedorite si vor constitui surse de aparitie a anomaliilor in timpul actualizarii. Normalizarea va conduce la o buna structurare a relatiilor.

- Fuziunea relatiilor. In timpul modelarii logice a datelor s-au creat diferite relatii, atat pe baza normalizarii ascendente a perspectivelor utilizatorilor, cat si a transformarii uneia sau a mai multor diagrame entitate-relatie in seturi de relatii. In structura acestor seturi de relatii pot exista unele relatii redundante cum ar fi existenta a doua sau mai multe relatii care descriu acelasi tip de entitate, ce ar trebui sa fuzioneze si sa se renormalizeze pentru extragerea eventualelor redundante.

5. Proiectarea structurala si functionala a sistemului informatic

Pana la aceasta faza nu s-au facut referiri in cadrul proiectarii logice a sistemului informatic, la structurarea sa pe subsisteme, aplicatii, unitati functionale, etc. si nici la elementele de structura organizatorica implicate intr-o aplicatie sau alta. Acum este momentul sa apropiem conceptia sistemului informatic de structura organizatorica a unitatii beneficiare si de felul cum sunt realizate concret functiile acesteia prin intermediul atributiunilor functionale ale elementelor din structura organizatorica.

Aceasta actiune implica pe de o parte, structurarea sistemului informatic in subsisteme, aplicatii, unitati functionale sau proceduri logice si unitati de prelucrare sau proceduri automate, iar pe de alta parte asigurarea functionalitatii sistemului proiectat.

Unitatea functionala este o parte componenta a unei aplicatii, reprezentata de un grup omogen si specific de prelucrari, interconectate functional si aplicate unei subfaze informationale omogene.

Reamintim ca procesele se pot descompune din doua puncte de vedere: conceptual si organizational.

Conceptual: Organizational:

- operatii complexe;    - faze;

- operatii elementare;    - sarcini

Unitatea functionala sau unitatea logica de prelucrare rezulta din descompunerea sarcinilor si contribuie la indeplinirea operatiilor. Cu alte cuvinte sarcinilor li se pot atasa unitati functionale, entitati, posturi de lucru, iar acestora li se pot atasa resurse.

5.1. Structurarea sistemului, subsistemelor si unitatilor functionale Sistemele informatice la nivelul unitatilor beneficiare pot fi :

- sisteme informatice independente, neconectate cu alte sisteme;

- sisteme informatice distribuite total sau partial;

- sisteme informatice mixte.

Structurarea sistemelor informatice se face mai usor, daca se coboara pana la nivel unitate functionala si acolo se face legatura cu elementele de structura organizatorica (posturile de lucru).

Structurarea pe unitati functionale se face tinand cont de urmatoarele criterii:

- omogenitatea activitatilor, combinata cu compartimentele functionale

implicate in sistemul proiect;

- ciclurile de functionare ale sistemului informatic; dupa acest criteriu se pot distinge trei tipuri de unitati functionale:

- pentru crearea initiala si actualizarea colectiilor de date;

- pentru exploatarea colectiilor de date si obtinerea iesirilor;

- pentru realizarea de interfete cu alte sisteme informatice;

- aspecte legate de relatia sistemului cu mediul exterior. Se are in vedere adaptarea sistemului la schimbarile de mediu, precum si contracararea efectelor mediului exterior asupra sigurantei si securitatii datelor din sistem. Acestea necesita unitati functionale :

- pentru reorganizarea structurii conceptuale a bazei de date;

- pentru securitatea/protectia B.D;

- frecventele sau termenele de realizare ale prelucrarilor automate specifice noului sistem (rezulta unitati functionale pentru prelucrari operative, la anumite termene si cu prelucrari aleatoare). Criteriile de mai sus pot fi folosite corelat sau independent, astfel incat numarul componentelor sa fie optim, iar functionalitatea sistemului sa fie maxima.

5.2 Asigurarea functionalitatii sistemului proiectat vizeaza definirea organizarii prelucrarilor si a fluxurilor informationale intre compartimentele implicate in noul sistem si acest lucru se poate face mai usor pornind de la elementele structurale ale unitatii functionale (intrari-prelucrari-iesiri).

Definirea elementelor structurale ale fiecarei unitati functionale se face in urmatoarea succesiune:

a) Ordonarea listelor/situatiilor de iesire in functie de compartimentele beneficiare, frecventele si termenele de realizare ale acestora intr-un tabel cu rubricile:

Iesirile sistemului

Volum

Compartimente beneficiare

Frecventa si termenul

Dispozitiv de obtinere

Cod

Denumire

b) Verificarea structurii bazei informationale in functie de documentele de intrare utilizate pentru introducerea atributelor specifice acestora, conform unui tabel cu structura:

Entitatile bazei informationale

Documente de intrare folosite

Elemente de

legatura

Denumire

Identificator

c) Verificarea corespondentelor dintre structura bazei informationale si listele/situatiile de iesire obtinute prin intermediul algoritmilor de calcul, conform unui tabel cu structura:

Structura bazei

informationale de intrare

Iesirile sistemului

S1

S2

S3

S4

S5

Sn

d) Ordonarea documentelor de intrare in functie de compartimente, frecvente si termene de utilizare pentru crearea si actualizarea colectiilor de date; se intocmeste un tabel cu structura:

Documente de intrare

Volum

Comparti-

ment emitent

Frec-

venta

Dispozitiv

de preluare

Struc-tura B.I.

Cod

Denumire

e) Definirea structurii unitatii functionale presupune precizarea intrarilor, prelucrarilor si iesirilor specifice. Pentru fiecare unitate functionala se stabileste criteriul sau criteriile utilizate pentru definirea sa, frecventa de apelare, interfata cu alte unitati functionale si fluxurile de prelucrare specifice.

Se intocmeste un tabel Format A4 (Landscape) cu structura de pe pagina urmatoare, unde prelucrarile (P) sunt defalcate pe atatea coloane cate entitati informationale (EI) exista in sistem. In acest tabel se are in vedere ca:

- intrarile sunt facute pe baza documentelor de intrare folosite pentru constituirea si actualizarea entitatilor bazei informationale;

- prelucrarile sunt asigurate prin intermediul entitatilor bazei informationale care vor fi actualizate sau exploatate in vederea obtinerii rezultatelor solicitate;

- iesirile sunt formate fie din entitatile bazei informationale pentru prelucrari ulterioare, fie din listele/situatiile de iesire solicitate de beneficiarul sistemului, inclusiv listele de tranzactii externe;

Tabelul este intitulat “Structura generala a unitatii functionale” si macheta lui este urmatoarea:

Unitati functionale

proiectate

Intrari

P

Iesiri

EI

Codul UF

Criterii de definire a UF

Frecventa de utilizare

Interfata cu alte UF

Fluxurile de prelucrare

Codul documentului de intrare

Denumirea documentului de intrare

Compartimentul emitent

Frecventa de transmitere

E1

En




Codul

Denumirea

Compartimentul beneficiar

Frecventa de transmitere

Dispozitiv periferic de obtinere

U.F. 1

Ciclurile de functionare

(Creare-actualizare B. I.)

U.F. 2

Ciclurile de functionare

(Exploatare listare B.I.)

Folosind datele completate in tabelul de mai sus, se poate intocmi organigrama unitatii functionale. Se intocmeste cite o organigrama pentru fiecare unitate functionala. Elementul de baza al organigramei este un dreptunghi aflat in centrul foii. Dreptunghiul contine date despre unitatea functionala respectiva (codul unitatii functionale, criterii, frecventa, entitatile implicate in unitatea functionala si codul fluxului prin care sunt implicate). Pe laterala, ca niste sateliti sunt prevazute alte dreptunghiuri (cate unul pentru fiecare element organizatoric (serviciu, conducerea unitatii, etc.) implicat in unitatea functionala) legate de cel central prin sageti de tip fulger (rupte) pe care sunt inscrise codurile fluxurilor ce leaga cele doua dreptunghiuri (cel lateral cu cel central). In fiecare dreptunghi sunt trecute: denumirea serviciului, codurile documentelor de intrare sau iesire implicate in fluxul dintre cele doua dreptunghiuri, eventual operatiile ce le executa serviciul respectiv asupra documentelor (de ex. verificare, sau modificare, analiza sau decizie, etc.). Cand s-au completat toate cele 5 tabele descrise mai sus de la literele a la e si cate o organigrama pentru fiecare unitate functionala, putem spune ca s-a completat organigrama sistemului informatic.

6. Documentatia etapei de proiectare logica

Documentatia incepe cu dictionarul atributelor, un tabel cu structura:

Nr. crt.

Denumire

Identificator

Tip, lungime

Conditii de validare

Numarul ordinului

nr_ordin

N,8

Nr_ordin>0

Daca este cazul, vom preciza topologia retelei de calculatoare (de ex. LAN). Modelul logic de date se poate reprezenta printr-un tabel din care sa rezulte ordinea de prelucrare a bazei de date, complemetar celui prezentat la punctul 4.3, aliniatul reprezentarea entitatilor, avand structura:

Nr. crt. Den..rel

Ordinea de actualizare a BD

1. CLIENTI

unde cifrele de la intersectia unei relatii din prima coloana cu numarul altei relatii dispus pe orizontala in prima linie indica ponderile entitatii din prima coloana in raport cu celelalte entitati. Aceasta ia valoarea 0, daca corespondenta EiEj este de tip 1 m sau n, si 1 daca valoarea corespondentei este de tip m sau

n 1, unde Ei este entitatea din prima coloana de pe pozitia i, iar Ej este entitatea din coloana j de pe prima linie. Astfel la intersectia primei entitati cu cea de a patra, in tabel gasim 1.

In continuare, se face suma pe linie si apoi se decide ordinea de prelucrare pentru entitatile care au cea mai mica suma; astfel suma ponderilor pentru entitatea Clienti este 1. Fiind cea mai mica din aceasta coloana, o desemneaza pe prima entitate ca facand obiectul actualizarii si pentru aceasta s-a conceput procedura P1;

- ulterior entitatile care fac obiectul actualizarii cu procedura P1 (ar fi putut fi si altele cu aceeasi suma ca entitatea Clienti), se exclud din calculul sumei si se recalculeaza suma, urmand a se lua in calcul suma cea mai mica; se obtin astfel entitatile ce vor fi actualizate cu procedura P2 (in exemplul de mai sus intra entitatea 7);

- se repeta pasul precedent pana ce se stabileste ordinea de prelucrare pentru toate entitatile.

Coloanele rezultate in zona 'Ordinea de actualizare a bazei de date', desemneaza procedurile ce se disting pentru actualizarea bazei de date. Astfel in exemplul de mai sus, se distinge o procedura P1 care va actualiza entitatea 1, una P2 care va actualiza entitatea 7, P3 pentru entitatile 2, 3, 4, 5, 6 si 9 si P4 pentru entitatile 5 si 8. Exemplul este fictiv si nu trebuie cautata compatibilitatea solutiei.

In mod asemanator cu ordinea de actualizare a bazei de date, se mai stabileste si ordinea de obtinere a rapoartelor, care poate apare in tabelul de mai sus ca o alta coloana in continuarea celei de actualizare a bazei de date.

Pentru modelul logic al prelucrarilor se poate intocmi un tabel cu structura: Activitatea, Faze, Actiuni, Actori, Frecvente si A sau M, adica automat sau manual.

Astfel unei activitati A pot sa-i corespunda de exemplu 4 faze (A1, A2, A3 si A4) . In acest tabel fiecare faza va ocupa un rand, dar fara a diviza pe verticala zona atribuita activitatii A. Cu alte cuvinte coloana intaia continua nedivizata pana ce se trece la activitatea B, s.a.m.d. Pentru fiecare faza coloana Actiuni poate cuprinde (una sub alta, cu linioara) mai multe actiuni.

In continuare, in documentatie vor fi incluse machetele documentelor de intrare (reproiectate), organigrama unitatilor functionale, organigrama sistemului informatic, machetele formularelor si rapoartelor, eventual a meniurilor (toate asamblate in asa fel incat sa se constituie in dialoguri si interfete, proiectate conform regulilor prezentate in acest capitol), precum si un tabel cu algoritmii folositi in diferite calcule.

7. Codificarea atributelor, documentelor si componentelor structurale ale sistemului informatic [5]

In cadrul etapei de analiza (subetapa modelare conceptuala), un punct aparte va fi cel al consemnarii codurilor folosite. In cadrul etapei de proiectare logica se vor pune de acord codurile noi cu cele existente sau, daca nu exista coduri vechi se vor da coduri noi, dar oricum la sfarsitul acestei etape trebuie sa avem coduri pentru:

- atributele componente ale bazei informationale de intrare;

- documentele primare (intrari), indicatorii sintetici, listele/situatiile, graficele, etc. (iesiri) si entitatile structurii bazei informationale (abrevierea denumirii entitatilor);

- componentele structurale ale sistemului informatic proiectat (subsisteme, aplicatii, proceduri, module program, etc.).

7.1 Codificarea atributelor componente ale bazei informationale de intrare

a) Cerintele si functiile codificarii.

Cerintele codificarii.

- unicitatea codului;

- stabilitatea si supletea in timp a codului (de exemplu capacitatea de a se adapta la extinderi de nomenclatoare);

- comoditatea utilizarii codului; sa fie usor de inteles si aplicat, sa permita detectarea si corectarea erorilor;

- concizia codului;

Functiile codificarii

- functia de caracterizare: codul trebuie sa fie caracteristic pentru atributul pe care-l reprezinta (sa reflecte continutul semantic al acestuia), deci sa fie pe cat posibil descriptiv;

- functia de identificare: sa permita regasirea rapida a atributelor;

- functia de control: sa permita verificarea corectitudinii codului;

- functia de manipulare a atributelor codificate: deci sa fie usor de introdus, de prelucrat, si chiar usor de folosit de utilizatori;

Codul este de fapt un simbol acordat atributului respectiv, reprezentat printr-un sir de caractere ce pot fi interpretate de factorul uman sau de procedurile sistemului informatic. Codul este deci 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.

Avantajele codificarii

- compactitatea;

- posibilitatea ierarhizarii lor;

- viteza de acces;

- reducerea erorilor;

- simplitate in comparatie cu denumirile.

Structura logica a codurilor trebuie sa asigure realizarea optima a unei corespondente biunivoce intre multimea valorilor reale ale atributelor

si multimea codurilor asociate acestora.

b) Tipuri de coduri utilizate intr-un sistem informatic

- dupa structura simbolului:

- coduri elementare:

- coduri secventiale (succesive, dar cu acelasi numar de cifre);

- secventiale pe grupe sau clase (ex. conturile de balanta);

- coduri cu semnificatie mnemonica (ex.OL=otel laminat)

- coduri cu semnificatie descriptiva (ex. OR 15 10 = otel rotund F15, lg. barei=10);

- coduri complexe:

- coduri ierarhizate:

- liniar simplu (ex. 9 9 99=grupa de produse, subgrupa de produse, tip de produs; in acest ex. avem trei trepte, primele doua de cate o cifra, iar a treia de doua cifre);

- zecimal;

- coduri juxtapuse; se realizeaza prin concatenarea codurilor ierarhizate sau a codurilor elementare (ex. un cod de personal compus din sectie, atelier, echipa, marca: 9 9 9 9999);

- dupa modul de detectare si corectare a erorilor:

- autodetectoare de erori;

- autocorectoare de erori;

- dupa natura atributelor:

- numerice;

- alfabetice;

- alfanumerice;

- dupa lungime:

- fixa;

- variabila;

- dupa modul de elaborare:

- manual;

- automat;

Codurile cu mai mult de trei cifre este bine sa aiba adaugata la sfarsit o cifra de control: aceasta se poate genera prin mai multe metode:

- metod-metoda aritmetica: c=Z-unde:

Ci reprezinta cifrele din cod, iar Pi coeficienti de pondere, iar Z este primul numar format numai din zeci, mai mare decat suma produselor CiPi. De remarcat ca daca un produs CiPi este mai mare de 9, el se va inlocui cu suma cifrelor care-l compun; astfel 16, de exemplu se va inlocui cu 7; metoda este simpla si precisa, dar nu permite localizarea erorilor;

- metod-metoda geometrica: c=restul impartirii

unde coeficientii de pondere sunt puterile crescatoare ale lui 2 sau numerele naturale in ordine crescatoare (de la stinga la dreapta), iar Z este un numar ales conventional ca limita superioara a cifrei de control, stiut fiind ca restul va fi mai mic decat Z.

Daca se alege Z=27 atunci restul se poate inlocui cu litera corespunzatoare din alfabetul englez.

Indiferent de metoda aleasa pentru determinarea caracterului de control, principiul de verificare a codului este acelasi: calculatorul calculeaza caracterul de control la fiecare citire de cod si compara cifra calculata de el cu cea atasata codului.

Corectarea automata a erorilor se bazeaza pe cifre de control calculate prin metoda aritmetica astfel (vom ilustra principiul de lucru pe un exemplu):

se descompune codul intr-o matrice; de ex. cu 4 linii si 3 coloane:

Text Box: 734	6
285	5
411	4
936	2
854	3

Se calculeaza caracterul de

control pentru fiecare linie 6+5+4+2=17;

si se trece in coloana din 20-17=3

dreapta; rezulta 6, 5, 4 si 2;

Se calculeaza caracterul de 8+5+4=17

control pentru fiecare coloana 20-17=3

si se trece pe ultimul rand in dreptul coloanei de unde provine. In cazul de mai sus, a rezultat 4, 5 si 8, pentru care se face din nou cifra de control si rezulta 3, care s-a pus in coltul din dreapta. De remarcat ca aceeasi cifra de control trebuie sa se obtina si pentru cifrele de control calculate pe linii (deci tot 3). Acesta este numit caracterul general de control.

Codul prevazut cu cifra de control va fi codul original urmat de coloana cifrelor de control pe linii (6542), de linia cifrelor de control pe coloane (854) si de cifra sau caracterul general de control (3).

Astfel codul 734 285 411 936 devine 734 285 411 936 6542 854 3.

Calculatorul va face si el acelasi calcul si daca rezultatul nu va fi acelasi cifra gresita se gaseste la intersectia liniei cu coloana care nu a obtinut cifre de control corecte, iar 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.

Inainte de a opta pentru un sistem de codificare, se cerceteaza daca exista un asemenea sistem si in ce masura poate fi utilizat.

c) Fazele realizarii codificarii

- pregatirea activitatilor de codificare;

- codificarea atributelor bazei informationale de intrare; se stabilesc:

- codurile sintetice si analitice din structura planului de conturi (cod ierarhizat): 999 99 999999 X reprezentand de la stanga la dreapta:

- cont sintetic;

- cont analitic de gradul I;

- cont analitic de gradul II;

- cifra de control;

- codurile materialelor, produselor sau reperelor (cod ierarhizat):

999 9 9 9 999999 9 reprezentand de la stanga la dreapta:

- clasificare generala;

- materia prima utilizata;

- clasificare detaliata:

- destinatia de consum;

- tehnologia de fabricatie;

- codul analitic material/produs;

- cifra de control;

- codurile compartimentelor: (ex. 999 9 9, reprezentand magazia, gestiunea si caracterul de control; sau 9 99 99 9, reprezentand: sectia, atelierul, formatia de lucru, caracterul de control);

- codurile salariatilor: cod secvential de 4-5 cifre; nu trebuie sa contina elemente privitoare la locul de munca (sectie, atelier, etc.) sau la specialitate, gradatie, clasa, etc., pentru ca aceste elemente sunt schimbatoare;

- codurile clientilor si furnizorilor (ierarhizat pe tip (intern sau extern), tara/judetul, felul unitatii economice (regie, SRL, SA, etc.), numarul de ordine;

- codurile unitatilor de masura: (semnificatie mnemonica);

- codurile operatiilor tehnologice (9 99 9 = operatie tehnologica, faze tehnologice, caracter de control);

- intocmirea nomenclatoarelor de coduri;

- intretinerea codurilor; codurile trebuiesc intretinute (actualizate cu elementele nou aparute: produse noi, angajati noi, etc.).

7.2 Codificarea intrarilor, iesirilor si entitatilor structurii bazei informationale de intrare

Se atribuie coduri cu semnificatie mnemonica (D1,D2, . , Dm) pentru documentele de intrare, (S1,S2, . , Sn) pentru indicatorii sintetici economico-financiar, liste/situatii de iesire, grafice, etc. si coduri de 8-9 caractere, denumiri abreviate, pentru entitatile existente in structura bazei informationale.

7.3 Codificarea componentelor structurale ale sistemului informatic proiectat Se au in vedere subsisteme, aplicatii, proceduri, module program. Se vor folosi coduri ierarhizate.

EXEMPLU DE DOCUMENTATIE PENTRU ETAPA

DE PROIECTARE LOGICA A METODEI MERISE

Modelarea logica pentru o casa de schimb valutar

a)     Dictionarul atributelor

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

Denumire atribut

Identificator

Tip, lungime

Conditii de validare

cod PSV

COD PSV

C,5

COD PSV<>””

nume persoana

NUME

C,40

NUME<>””

tara

TARA

C,20

TARA<>””

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)>=”01-01-01” and

DTOC(DATA_OP)=<”31-12-01”

Nr. doc. Miscare



NR_DOC

C,10

NR_DOC<>””

descr. op. miscare

DESCR

C,40

DESCR<>””

sold initial

SOLD_I

N,10

SOLD_I<>0 and SOLD_I=<9(10)

b)     Modelul logic de comunicatie (MLC)

Pentru casa de schimb valutar MLC este bazat pe 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:


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

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

AL


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

INTRARI VALUTE TRANSFER BANCA

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

CUMPARARE/VANZARE VALUTA

- 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

Bibliografie

  1. Dumitru Oprea, 'Analiza si proiectarea sistemelor informationale economice', Editura Polirom, Bucuresti, 1999.
  2. Nicolae Dumitru Davidescu, 'Sisteme informatice financiar - bancare', Editura All Beck, Bucuresti, 1998.



loading...




Politica de confidentialitate


Copyright © 2020 - Toate drepturile rezervate

Informatica


Access
Adobe photoshop
Autocad
Baze de date
C
Calculatoare
Corel draw
Excel
Foxpro
Html
Internet
Java
Linux
Mathcad
Matlab
Outlook
Pascal
Php
Powerpoint
Retele calculatoare
Sql
Windows
Word


SmartMPS - cum se utilizeaza
Movie Maker
Globalizarea sistemelor informationale
Calculatoare specializate
Atestat informatica - Catalog si gestiune de imbracaminte
Utilizarea elementelor de grafica pentru redactarea textelor tehnice
Programarea in LADDER a automatelor programabile Twido
PROTEJAREA COMUNICAȚIEI PRIN INTERNET
SISTEME INFORMATICE DE CONTABILIATE
Atestat informatica - Plante si animale pe cale de disparitie