	Biologie	Chimie	Didactica	Fizica	Geografie	Informatica
	Istorie	Literatura	Matematica	Psihologie

Informatica

Index » educatie » Informatica
» PROIECTAREA FIZICA A SISTEMELOR INFORMATICE

PROIECTAREA FIZICA A SISTEMELOR INFORMATICE

PROIECTAREA FIZICA A SISTEMELOR INFORMATICE

Proiectarea fizica se desfasoara pe parcursul a trei subfaze sau pasi [1]:

- proiectarea fisierelor fizice si a bazelor de date: aceasta vizeaza descrierea modului in care vor fi stocate si accesate in/din memoriile secundare si cum se va asigura controlul lor pentru a se oferi o securitate maxima;

- 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 si cu celelalte piese ale documentatiei realizate in etapele anterioare;

- proiectarea strategiilor de prelucrare distribuita: modalitatile in care utilizatorul poate sa dispuna de date si facilitati de prelucrare distribuite in retea.

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.

1. Proiectarea fisierelor fizice si a bazelor de date

1.1 Aspecte generale ale proiectarii fisierelor fizice si a bazelor de date

Proiectarea fisierelor fizice si a bazelor de date trebuie sa asigure trecerea de la descrierea logica a datelor la una tehnica, de stocare a datelor. Proiectantul trebuie sa aiba in vedere ca proiectarea fizica trebuie sa se materializeze in specificatii tehnice ce vor fi folosite ulterior de pogramatori si alti specialisti implicati in construirea sistemului, adica la crearea fisierelor, definirea modurilor de organizare acestora, precum si a bazelor de date.

Proiectarea fizica a fisierelor si a bazelor de date are doua obiective:

- transpunerea relatiilor dintr-un model de reprezentare logica a datelor intr-un proiect tehnic. Mai exact, se vor stabili:

- formatele sub care vor fi reprezentate atributele;

- modul de grupare a atributelor din una sau mai multe relatii in una sau mai multe inregistrari fizice;

alegerea modului de organizare a fiecarui fisier cu inregistrari;

- proiectarea metodelor de accesare a datelor din unul sau mai multe fisiere;

- selectarea tehnologiilor folosite pentru stocarea datelor Tehnologiile se refera la diverse functii ale sistemului de operare (numite metode de acces) si sisteme de gestiune a bazelor de date. Fiecare tehnologie va fi specifica unei anumite arhitecturi a sistemului.

Pentru realizarea acestor obiective se pleaca de la urmatoarele informatii:

- relatiile normalizate, inclusiv dimensiunea bazei de date;

- definirea fiecarui atribut;

- specificarea momentului si a locului utilizarii datelor: introducerea, resta-urarea, stergerea, actualizarea (inclusiv frecventa operatiilor);

- timpul preconizat pentru obtinerea raspunsurilor;

- descrieri ale tehnologiilor folosite pentru crearea fisierelor si a bazelor de date.

Cele doua obiective se vor materializa pe baza informatiilor de mai sus, in urmatoarele decizii ale analistului de sistem:

- selectarea formatului de stocare (tipul datei) pentru fiecare atribut al modelului logic al datelor si precizarea tuturor proprietatilor specifice tipului de date ales (format, input mask, validation rule, default value, etc.);

- stabilirea structurii inregistrarilor/datelor stocate (gruparea atributelor din modelul logic al datelor in inregistrari fizice);

- stabilirea organizarii fisierelor (modul de plasare a inregistrarilor inrudite in memoria secundara - discuri, benzi magnetice) astfel incat inregistrarile individuale sau grupate sa poata fi stocate, restaurate si actualizate rapid; tot acum se stabileste modul de protectie a informatiilor si al reconstituirii lor dupa anumite incidente;

- selectarea suportului datelor care, desi este mentionat ultimul, este corelat si influenteaza hotarator structurile de stocare a datelor precum si organizarea fisierelor.

In cazul SGBD aceasta presupune selectarea optiunilor pentru accesul secvential sau prin chei, precum si implementarea legaturilor/asocierilor dintre entitati si relatii .

Structura primara cea mai utilizata in prezent se bazeaza pe indecsi construiti prin chei primare si chei secundare.

Aceste decizii se vor materializa in specificatii care, asa cum s-a mentionat mai sus, vor fi utilizate de programatorii sau analistii bazelor de date pentru definirea formatului si structurii datelor stocate in memoria secundara.

Ele se pot pastra in depozitul CASE sau manualul dictionarului proiectului, dar determina si completarea dictionarului proiectului, in timpul proiectarii fizice a fisierelor si bazelor de date, cu unele elemente reprezentative cum ar fi:

- proprietatile campului: nume, tip data, UM (unitatea de masura), codul (regula de codificare), reguli de validare (de asigurare a integritatii datelor), controlul intretinerii ( de ex. nu se poate schimba un numar de factura validat), Null, for-mula in cazul campurilor calculate (ex. valoare=pret*cantitate), cifra de control, integritate referentiala, cine este autorizat sa introduca, sa valideze, sa actualizeze data si cine o poate consulta;

- proprietatile inregistrarii: lista campurilor unei inregistrari, date structurale necesare interpretarii formatului inregistrarii (pointeri sau alte elemente ale campurilor de lungime variabila), durata de pastrare a datelor;

- proprietatile fisierului: nume si amplasare, inregistrari ce vor fi stocate in fisier, cheia primara, indecsi, factorul de blocaj, pastrare si copii de siguranta, organizarea fisierelor, modalitatea de auditare si de criptare;

- proprietati ale bazelor de date: fisiere ce fac parte din baza de date, arhitectura (tipul structurii bazei de date din punct de vedere al s.g.b.d. ce poate sa o gestioneze: de exemplu un s.g.b.d. relational), relatii (mecanismele utilizate pentru punerea laolalta a fisierelor: de ex. tipul pointerilor folositi pentru legarea inregistrarilor din fisiere diferite, in cadrul unei baze de date retea sau ierarhica).

1.2 Proiectarea campurilor

De regula fiecare atribut al modelului logic al datelor va fi reprezentat ca unul sau mai multe campuri (de ex. NUME_PERS poate fi reprezentat prin NUME, INITIALA si PRENUME). Analistul trebuie sa specifice proprietatile campurilor enumerate mai sus, ca elemente de completare a dictionarului proiectului.

1.3 Proiectarea inregistrarilor fizice

In cadrul acestei actiuni se urmareste printre altele si utilizarea rationala a suporturilor magnetice, care se concretizeaza in aspecte cum ar fi factorul de blocaj sau partitionarea inregistrarilor. Factorul de blocaj tine de faptul ca in general calculatoarele, prin sistemele lor de operare, citesc cantitati fixe de informatii, care constituie un fel 'de pat al lui Procust' pentru inregistrarile fizice. Mai exact, in cazul discurilor cantitatea fixa posibil a fi citita/scrisa la o comanda de citire/scriere se numeste pagina, iar in cazul benzilor magnetice se numeste bloc de inregistrari. Ideal ar fi ca dimensiunea acestor capacitati impartita la lungimea unui articol, sa dea un rest cat mai mic (daca se poate sa fie zero) In practica dimensiunea articolului depinde de nevoile logice de organizare a datelor in tabele si rareori se poate potrivi cu acest criteriu de optimizare. Factorul de blocaj este raportul dintre lungimea utila a blocului de inregistrari si lungimea fizica a acestuia. Ideea se poate extinde si la pagini. Oricum, cu cat articolul este mai lung, cu atat este posibil ca factorul de blocaj sa fie mai mic. Articolele lungi mai prezinta un dezavantaj: ele pot incetini inutil citirile si scrierile in cazul in care intr-o prelucrare nu avem nevoie decat de cateva campuri din tabelul sau fisierul supus prelucrarii. Pentru a evita astfel de situatii, se foloseste partitionarea inregistrarilor. Aceasta este operatiunea prin care inregistrarile fizice sunt descompuse in doua sau mai multe segmente fizice, pe criterii de legaturi de afinitate intre unele campuri, cu scopul cresterii operatiunilor de prelucrare. De regula, inregistrarile fizice sunt descompuse intr-un segment primar care contine campuri necesare in cele mai multe tranzactii si un segment secundar care contine campurile solicitate mai rar.

Astfel inregistrarea logica CLIENT poate fi descompusa intr-un segment primar format din cod_client, limita-creditare, sold_curent si unul secundar format din: adresa_client, localitatea, judetul, tara, cod_postal, statut_client. Separarea inregistrarilor fizice se poate face si pe criterii de apartenenta la anumite compartimente ale unitatii ( de ex. contabilitate, marketing, proiectare, etc.). Este de remarcat faptul ca partitionarea duce la denormalizare, adica la incalcarea structurii inregistrarii logice aflata la cea de a treia forma de normalizare. Practic denormalizarea conduce la doua stari contradictorii:

- anularea efectelor benefice ale normalizarii;

- optimizarea procesului de prelucrare.

Este de datoria analistului-programator sa gaseasca solutia de compromis cea mai avantajoasa.

1.3.1 Inregistrari cu campuri de lungime fixa si variabila

Cu inregistrarile formate din campuri de lungime fixa este foarte usor de lucrat: atat inregistrarile cat si campurile se gasesc foarte usor. In cazul campurilor de lungime variabila (cazul memo), lucrurile sunt mai complicate. Unele SGBD, intre care si FoxPro, Paradox, dBASE descompun relatiile obtinute in proiectarea logica in doua parti: una care sa reuneasca toate campurile de lungime fixa si alta care sa cuprinda campurile de lungime variabila.

1.4 Proiectarea fisierelor fizice

1.4.1 Tipuri de fisiere

In functie de gradul de mentinere in timp a datelor stocate in fisiere, ele se clasifica in:

- fisiere permanente (de exemplu nomenclatoarele)

- fisiere de stare (de exemplu stocurile, soldurile, etc;

- fisiere variabile (temporare sau de conjunctura): de exemplu impuse de legisla-tia in vigoare, cum ar fi statele de plata - pentru a permite calculul pensiilor sau fisiere necesare pentru reconstituirea datelor dupa anumite incidente;

- fisiere-tabel: tabel cu medicamente compensate, tabel cu dobanzi, cu procentele de impozit, tabele statistice, etc.;

- fisiere index;

- fisiere istoric (de ex. fisierul vanzarilor ce va fi folosit pentru determinarea trend-ului);

- fisiere back-up (copii ale unor fisiere permanenete sau ale altor fisiere, folosite pentru reconstituirea evidentei);

- fisiere cu suspendari. Contin inregistrari care au fost identificate ca eronate sau cu un statut incert. De exemplu, cand s-au efectuat tranzactii si nu exista inregistrarea corespunzatoare in fisierul permanent, stocuri omise sau determinate prea tarziu. Aceste fisiere necesita mare atentie.

- fisiere de raportare;

- baza de date (in sensul ei cel mai clar, o colectie de date integrate intr-un numar de fisiere, memorate astfel incat sa faciliteze atat actualizarea rapida a datelor cat si accesul la ele).

1.4.2 Metode de prelucrare a fisierelor

prelucrare pe loturi (batch processing);

- prelucrarea on-line (individual, de indata ce apar informatiile, prelucrarea efectuandu-se in punctul de origine a informatiilor). Aceasta poate fi de doua feluri:

- actualizare on-line (prelucrari de tranzactii);

- prelucrare de tip intrebare/raspuns (consultari ale fisierelor principale in vederea efectuarii unei tranzactii). De exemplu consultarea contractelor sau a altor conditii impuse pentru declansarea unei tranzactii.

1.4.3 Caracteristicile fisierelor fizice

Numar de articole din fisierul permanent referite la o intretinere

Total inregistrari din fisierul permanent

- suportul de inregistrare;

- indicile de activitate: Ia=

- volatilitatea, o masura a frecventei adaugirilor, stergerilor si a altor operatiuni necesare pentru un fisier permanent, intr-o anumita perioada de timp:

Numarul total al operatiilor relative la fisier

Unitatea de timp standard (zi, saptamana, etc.)

Volatilitatea fisierelor=

- accesibilitatea se refera la usurinta cu care inregistrarile pot fi regasite. Ea depinde de suportul de informatii si de echipamentele utilizate, dar si de modul de codificare, de indexare si de modul de realizare a referintelor incrucisate de la o inregistrare la alta.

Proiectantul mai trebuie sa elaboreze o programare a tipurilor de inregistrari stocate si aceasta trebuie sa contina doua elemente:

- perioada de timp dupa care inregistrarile pot fi trecute din categoria active la categoria celor inactive;

- perioada de timp dupa care fiecare tip de inregistrare poate fi sigur distrusa. Inregistrarile inactive trebuie stocate pe suporturi ieftine, intr-un loc diferit de prelucrarea datelor.

Unele companii au infiintat functia de Records management , intr-un departament separat care se ocupa de:

- crearea formularelor care se folosesc pentru culegerea si memorarea datelor;

- prelucrarea , stocarea, reconstituirea inregistrarilor;

- retinerea inregistrarilor inactive;

- renuntarea la inregistrarile invechite.

In unele unitati aceste sarcini sunt preluate de serviciul de birotica sau de catre administratia birourilor.

1.4.4 Organizarea fisierelor si accesarea inregistrarilor

a) Principalele moduri de organizare a fisierelor:

- organizare secventiala;

- organizare secvential indexata (organizare secventiala pe baza unei chei primare);

- organizare relativa, o forma de organizare directa bazata pe valoarea inregistarii relative (un numar care indica pozitia relativa a inregistrarii fata de inceputul fisierului);

- organizare selectiva, a doua forma de organizare directa, bazata pe o adresare speciala: aceasta foloseste o cheie relativa ce se obtine printr-un calcul de randomizare, pornind de la valoarea cheii primare.

b) Moduri de acces al inregistrarilor:

- accesul secvential;

- accesul aleator.

Organizarea fisierelor se stabileste odata cu crearea fisierului si numai in cazuri foarte rare se modifica.

1.5 Proiectarea securitatii fisierelor si bazelor de date

Securitatea fisierelor si bazelor de date vizeaza securitatea averii informationale, adica posibilitatea reconstituirii datelor pierdute sau prelucrate eronat, blocarea accesului neautorizat sau macar incomodarea pana la a face imposibila citirea datelor prin criptare, atunci cand ele sunt accesate ilegal.

1.5.1 Reconstituirea datelor

De cele mai multe ori ne duce cu gandul la fisiere de tip back-up (reconstituire inainte), dar se poate face si fara acest tip de fisiere (reconstituire inapoi). Reconstituirea inapoi consta in reluarea efectului invers al tranzactiilor pana la ultima tranzactie eronata, continuata cu corectarea erorilor.

Pentru controlul corectitudinii datelor despre tranzactii se apeleaza la fisiere care reflecta istoricul schimbarilor si accesarilor efectuate asupra fisierelor si bazelor de date, numite probe in auditare. Ele, impreuna cu registrul tranzactiilor, contin imaginea inregistrarilor inainte si dupa modificare, copii ale datelor despre tranzactii si alte informatii. Toate acestea pot fi enumerate sintetic astfel:

- elemente de identificare a tranzactiei;

- elemente de identificare a operatorului/utilizatorului;

- valoarea tranzactiei;

- imaginea unui camp inaintea efectuarii unei schimbari;

- tipul operatiei efectuate;

- data si momentul din zi cand a avut loc tranzactia;

- codul sau numele programatorului care a declansat tranzactia;

- echipamentul cu care s-a efectuat operatiunea, s.a.

1.5.2 Criptarea datelor presupune transformarea datelor de comunicat intr-o forma neinteligibila pentru oricare receptor, cu exceptia celui autorizat.

Criptarea se poate face prin coduri sau prin cifruri.

Codurile sunt mesaje numerotate sau insotite de un identificator. In procesul de comunicatie se transmite numai numarul sau identificatorul, iar destinatarul consulta lista cu semnificatia codului.

Cifru presupune existenta unor chei care, odata puse in functiune, asigura la criptare conversia fiecarui simbol din mesajul in clar, intr-un corespondent din mesajul cifrat. Procesul este reversibil la decriptare. Daca se foloseste aceeasi cheie la criptare si decriptare avem de a face cu un cifru simetric, altfel cu un cifru asimetric.

Cifrurile se pot aplica asupra simbolurilor intregului mesaj sau ale unor grupuri din el, in mod continuu. In acest caz se numesc cifruri in flux continuu, dar exista si cifruri bloc, acelea care se aplica numai asupra unui grup de simboluri.

Exista trei feluri de cifrari: camuflajul, transpozitia si substitutia.

Camuflajul presupune ca mesajul sa nu fie observabil, adica sa fie ascuns intr-un mesaj banal, dar credibil.

Transpozitia presupune utilizarea unui sablon atat la criptare cat si la decriptare. Pe timpul transportului, mesajul este un fel de puzzle. Daca este posibil, este bine ca transpozitia sa fie imbinata cu camuflajul, adica textul criptat sa arate pasnic, sa nu sfideze, pentru ca atunci ar atrage atentia si poate si interesul unora de a sparge codul.

Substitutia presupune inlocuirea literelor dupa reguli bine stabilite, cu alte litere sau cifre .

1.6 Proiectarea bazelor de date este precedata, dupa cum s-a putut vedea in sectiunile anterioare, de proiectarea fisierelor fizice, dar in practica activitatea se desfasoara in spirala.

Cand se proiecteaza arhitecturile bazelor de date, trebuie sa fie luate in consideratie mai multe aspecte, dar determinanta este marimea sistemului.

Exista patru tipuri de arhitecturi: ierarhica, retea, relationala si orientata-obiect.

Modelul ierarhic este de fapt o structura arborescenta cu nivele strabunic (fisier radacina), bunic (fisiere intermediare), tata si fiu. Pentru a lega nivelul inferior la cel superior se folosesc noduri. Fisierele extreme sunt fisiere frunza.

Modelul retea este folosit in situatii complexe, dar este nevoie specialisti de inalta clasa ca sa lucreze cu astfel de modele. Ele arata astfel:

Modelul relational al bazelor de date este cel mai des utilizat pe PC-uri. Se bazeaza pe realizarea de legaturi intre relatii create cu ajutorul cheilor lor, angrenate cu rolul de cheie primara si respectiv cheie externa.

Modelul relational depinde exclusiv de legaturile dintre obiecte (tabele).

La acest model s-a ajuns din considerentul ca, desi pentru utilizator importanta primordiala o are entitatea, din punct de vedere al modelului relational entitatea exista prin combinatii ale valorilor caracteristicilor sale. In acest sens trebuie stiute domeniile fiecarei caracteristici, adica multimea valorilor pe care o caracteristica le poate lua si din combinatia acestor domenii va rezulta o realizare a entitatii. Aparent pana aici n-am spus nimic nou, dar acest mod de abordare a entitatilor

i-a permis matematicianului C. F. Codd sa expuna in 1969 modelul relational de organizare a bazelor de date. Conform acestui model, o entitate poate fi definita ca o relatie (in sens matematic), R D₁ xD₂ xD₃ x . ..D_n , mai exact o submultime a produsului cartezian de <<n>> multimi denumite domenii si notate cu D₁, D₂, D₃ , . ,D_n . Odata ce acest lucru este demonstrat, pe obisnuitul tabel cu date referitoare la o entitate s-au putut aplica toate conceptele unei metode logice si riguroase de modelare a datelor, inclusiv algebra relationala. Astfel, relatiei (tabelului) i se poate asocia un grad <<n>> (numarul de coloane ale tabelului) si o cardinalitate <<m>> (numarul de realizari sau randuri sau articole), iar mai nou , un articol se identifica in cadrul modelului relational cu ceea ce se numeste tuplu.

Modelul relational foloseste urmatoarele concepte fizice:

- relatie = tabel bidimensional format din randuri (linii) numite tupluri si coloane numite domenii. Relatiile abordate sunt finite chiar daca domeniile pe care sunt construite pot fi infinite (de ex. domeniul numerelor intregi);

- tuplu = un rand dintr-o tabela;

- caracteristica= numele/antetul unei coloane dintr-o tabela (relatie);

- cheie = o caracteristica sau o multime de caracteristice a caror valoare identifica fiecare tuplu dintr-o tabela;

- cheie primara = cheia care permite identificarea in mod unic a unui tuplu (inregistrare);

- cheie secundara = cheia ce permite identificarea tuturor tuplurilor care au aceeasi proprietate;

- cheie externa = cheie identica cu cheia primara a relatiei asociate; prin construirea cheilor externe se realizeaza un acces rapid la informatiile continute in baza de date datorita legaturilor pe care le realizeaza;

- domeniu = multimea de valori ale unei caracteristici (o coloana dintr-o tabela);

- grad = numarul de coloane din cadrul unei tabele; se noteaza G(R)=n, unde R este numele tabelei;

- cardinalitate = numarul de randuri din cadrul unei tabele; se noteaza C(R)=m, unde R este este numele tabelei;

- dimensiunea relatiei = produsul dintre cardinalitate si gradul relatiei.

Un model relational cuprinde trei elemente:

- structura datelor;

- reguli de integritate, care guverneaza utilizarea cheilor in model;

- operatori.

a) Structura datelor in modelul conceptual se defineste prin schema relatiei sau prin diagrame entitate-relatie combinate cu lista caracteristicilor din compunerea unui tabel.

Sintaxa generala a unei scheme de relatie este:

<nume relatie> (<car1>,<car2>, . ,<carm>), unde campul subliniat (unul din aceste <car . >) reprezinta cheia de acces.

Cat priveste cea de a doua forma de reprezentare a relatiilor dintre tabele, un exemplu il constituie imaginea de pe pagina urmatoare:

b) Pentru cei care au studiat SGBD Access regulile de integritate, care guverneaza utilizarea cheilor in model sunt cunoscute de la modul practic cum au fost definite in Access relatiile dintre tabelele bazei de date si mai exact din modul cum au fost folosite optiunile ferestrei de Edit Relationship, vizibila si ea mai jos.

c) Cat priveste operatorii, trebuie precizat ca pentru manipularea relatiilor, modelul relational ofera doua categorii de limbaje:

- limbaje algebrice bazate pe operatori specializati ce com-bina relatiile intre ele sau le filtreaza. La baza acestor limbaje sta algebra relatio-nala. Aceste limbaje cuprind doua tipuri de operatori relationali: operatori de baza si operatori auxiliari.

Operatorii relationali de baza se impart in:

- operatori de asamblare: reuniunea, intersectia, diferenta si produsul cartezian;

- operatori unari (de restrictie): selectia si proiectia;

Operatorii auxiliari (de extensie) pot fi dedusi din setul de operatori de baza si cuprind: compunerea, semicompunerea, diviziunea

- limbaje logice (predicative) care permit specificarea relatiei utilizand formule de logica matematica, ceea ce numim calcul relational (orientat pe tupluri sau domenii). Calculul relational este limbajul logic pe care s-a construit majoritatea limbajelor de interogare a bazelor de date. Dintre aceste limbaje mai frecvent, este folosit SQL.

Exemple de S.G.B.D. relationale: FOXPRO (pentru P.C.), ORACLE (P.C. + mini-calculatoare), INGRES (UNIX), CAMPUS (P.C. si APPLE II), ACCESS , VISUAL FOX (WINDOWS), DB2 si SRL Server

In cele ce urmeaza avem in vedere arhitectura relationala si faptul ca la sfarsitul acestei etape trebuie sa avem definita structura generala, din punct de vedere fizic, a bazei de date relationale.

La aceasta descriere se poate ajunge prin doua metode: sintetica si analitica [5].

a) Metoda sintetica vizeaza entitatile (tabelele), atributele lor si corespondentele dintre entitati. Dupa aceasta metoda entitatile se clasifica in:

- nuclee (cu existenta independenta; ex. SECT, ATEL, MAT, BEN);

- intermediare (rezulta din prelucrarile altor entitati; sunt de manevra);

- de stare (retin date sintetice provenite din prelucrarile datelor stocate in entitatile de tip nucleu, intermediar sau chiar de stare).

Fazele descrierii structurii generale a bazei de date relationale:

- atribuirea specificatorului entitatii: dispozivul, directorul unde va fi stocata entitatea, extensia acesteia (ex. DBF);

- descrierea atributelor specifice entitatii: (NUM (numarul de ordine al atributului in cadrul entitatii) , FIELD NAME, FIELD TYPE, WIDTH, DEC INDEX (cheia de indexare), conditii de validare ;

- descrierea corespondentelor dintre entitati (determinarea entitatii de legatura, cheia externa si cardinalitatea);

- caracteristici fizice si de acces (se are in vedere definirea organizarii entitatilor de tip index, cheile de indexare, numarul maxim de inregistrari si lungimea maxima a unei inregistrari); cheile de indexare pot fi primare sau secundare. Acestea din urma indeplinesc si ele conditiile de cheie primara, dar nu au fost ele desemnate drept cheie primara.

b) Metoda analitica se aplica atunci cand exista o baza de date relationala deja proiectata, iar structura sa trebuie optimizata: ea se aplica atunci cand in baza de date au ramas de verificat numai depentele functionale de forma C A unde C reprezinta cheia primara, iar A orice alt atribut din entitate.

Indiferent de metoda aplicata, rezultatul descrierii structurii generale a bazei de date relationale este acela ca pentru fiecare relatie se va intocmi un tabel.

Tabelul urmator este un exemplu de descriere a relatiei B.D. "RULAJE PRECEDENTE"

Un astfel de tabel se poate construi numai pe baza organigramei sistemului informatic, a dictionarului atributelor si a tabelului numit baza de atribute, toate elaborate in faza de proiectare logica. In plus, se va tine seama de restrictiile impuse de sistemul de operare si de restrictiile de integritate.

Descrierea bazei de date [5]

DESCRIEREA ENTITATII
Nume entitate		Specificator
Rulaje precedente		Peri-feric	Identificator			Extensie			Securitate
			RULF			dbf			sgbdr Fox
STRUCTURA INREGISTRARII
Nr. nivel	Identi-ficator atribut	Tip, lungime	Mod repre-zentare	Lo	FA	Antetul atributului			Conditii de validare
	COD-CONT	N,3	D		Z3	'COD'/'CONT'			COD CONT >100
	DEN-CONT	C,20	D		X2O	'DEN'/'CONT'			#b
	SOLD-DB	N,8	D		Z8	'SOLD INITIAL'/'OB'
	SOLD-CR	N,8	D		Z8	'SOLD INITIAL'/'CR'
CARACTERISTICI FIZICE SI DE ACCES
Orga- ni-	CHEI DE INDEXARE			Nr. maxim		Lungi-me	Tip in- reg.	F.B.	Numar blocuri virtualitate
zare		Identi ficato-ri	Restrictii	inreg.		maxima in- reg.
	Prima-ra	Cod-cont	No dup. No change						Ini-tial	extensie
Secvential indexat	Secun-dara	Den-cont	No dup. No change	50			F
RESTRICTII DE INTEGRITATE
NUME FISIER			CHEIE EXTERNA				CARDINALITATE
MAT.			COD-CONT				1-n
PROD			COD-CONT				1-n
INTRARI			COD-CONT				1-n
IESIRI			COD-CONT				1-n
LIVRARI			COD-CONT				1-n

2. Proiectarea programelor si a procedurilor

2.1 Aspecte generale ale proiectarii programelor si procedurilor

In cazul sistemelor mari se face distinctie intre proiectantul de soft si programator. Primul defineste si structureaza componentele in asa fel incat sa formeze un tot unitar, un proiect soft operational. El trebuie sa grupeze functiile ce trebuie interconectate si sa descrie modalitatile de realizare a legaturilor. Al doilea, trebuie sa transpuna proiectul soft in realitate. El isi propune, ca prin intermediul programelor, sa controleze intrarile, prelucrarile, stocarile si iesirile din sistem.

Softul are doua componente: instructiunile (statements) si modulele. Modulele se pot grupa pentru a forma programele. Programele trebuie sa tina seama si de modul in care calculatorul rezolva accesul mai multor programe la resursele sale. Aceste modalitati de administare a resurselor calculatorului au evoluat de la prelucrari in batch, la multiprogramare si apoi la multiprogramare-multicalculator. Acum se folosesc si calculatoare avand unitati centrale cu mai multe procesoare si evident, cu posibilitatea prelucrarii concomitente a mai multor programe. Au aparut retelele de teletransmisie si teleprelucrare a datelor si sisteme interactive, iar legat de aceasta si limbaje de programare conversationale. Exista mai multe clasificari ale programelor, dar una ar fi aceea care imparte programele in :

- programe S realizate pe baza unei specificatii si care dau solutia problemei;

- programe P, care accepta anumite incertitudini, folosesc anumite criterii arbitrare si aproximeaza lumea reala;

- programe E, care automatizeaza o anumita activitate umana sau sociala. Ele sunt strans legate de mediu si ca urmare sunt cele mai dispuse la modificari.

Programele trebuie sa posede eficienta, fiabilitate, flexibilitate, inteligibilitate si alte calitati, dar pentru aceasta ele trebuie sa respecte anumite principii:

- Principiul conformarii (sa fie elaborate in conformitate cu cerintele utilizatorului);

- Principiul completitudinii (sa realizeze descrierea completa a obiectivelor programului pe toate nivelurile ierarhice de descompunere);

- Principiul abstractizarii (functia programului se realizeaza tinand cont de elementele esentiale si facand abstractie de detaliile nesemnificative);

- Principiul modularizarii (programele se descompun in subdiviziuni logice - module).

Tehnici de programare care s-au conturat pana in prezent:

- Programarea clasica (fara intentii de structurare). In acest context se pot omite sau plasa eronat operatii in cadrul schemei logice, se face apel la instructiuni de salt, schema logica este artizanala si greu de inteles, implica mult timp pentru depanare;

- Programarea modulara. Aceasta presupune descompunerea programului inca din faza de proiectare in module usor de intrebuintat: se poate realiza descendent (top-down) sau ascendent (bottom-up). Se desfasoara pe trei etape:

- modularizarea functionala;

- modularizarea structurala (vizeaza structurarea datelor);

- modularizarea procedurala (vizeaza ordinea de executie a programelor).

Programarea modulara permite organizarea rationala a activitatii de programare, prin standardizarea unor grupuri de operatii, cresterea randamentului calculatorului prin economisirea memoriei centrale si mai permite usurarea activitatii de depanare si actualizare a programelor;

- Programarea structurata. Se considera ca aceasta ofera o rezolvare standardizata si structurata in mod unitar a programelor, reprezentand o ridicare a activitatii de programare la nivelul activitatii industriale, fundamentata pe o metodologie stiintifica. Unii specialisti considera insa ca programarea structurata este ceva incomplet daca nu se precizeaza si contextul in care este abordata problema ( de exemplu top-down sau bottom-up). In plus, i se imputa o oarecare lipsa de rigoare precum si unele contradictii in formalizarea ei. De exemplu, ii lipsesc criteriile de identificare a elementelor terminale si deci se confrunta cu imposibilitatea deducerii unui criteriu de finitudine a aplicarii ei.

2.1.1 Atributele modulelor

Se considera ca modulele au urmatoarele carcteristici:

- sunt formate dintr-un grup de instructiuni contigue din punct de vedere fizic si sunt executate ca o unitate distincta;

- au inceputuri si sfarsituri bine definite;

- de regula au doar un punct de intrare si unul de iesire;

- poate fi referit printr-un cod mnemonic sau printr-un nume atribuit de proiectant;

- sunt identificabile prin termeni standard ai programarii cum ar fi: procedura, subprograme, etc.

Un modul are trei atribute de baza: functia, logica si interfetele.

Functia consta in transformarea datelor prin procesul de executie a modulului. La nivele superioare functia se refera la problema de rezolvat, iar la nivele inferioare functia decade spre specificarea prelucrarilor.

In diagramele de structura ale proiectelor soft, un modul este reprezentat printr-un dreptunghi ce poarta denumirea functiei indeplinite. In aceasta faza nu se acorda atentie modului de executie cu calculatorul, adica implementarii functiei. In denumirea functiilor trebuie evitate conjunctiile deoarece prezenta lor ne duce cu gandul la posibilitatea descompunerii modulului in mai multe module.

Logica modulului descrie prelucrarile care au loc in interiorul acestuia. Daca functia modulului il vede pe acesta ca pe o cutie neagra, logica modulului il vede ca pe o cutie alba. Prelucrarile se pot descrie sub diverse forme (scheme logice, pseudocod, tabele de decizie, arbori de decizie sau combinatii), dar toate se refera la algoritmii de prelucrare. Pasii algoritmului se vor transforma in instructiuni de programare.

Interfetele sunt conexiuni sau cuplaje intre module. Acestea se realizeaza pe doua planuri:

- cel al transferarii controlului de la un modul la altul;

- cel al transmiterii datelor de la un modul la altul.

De fapt eficienta cu care se transfera controlul si metoda de transmitere a datelor determina eficienta proiectelor soft.

2.1.2 Structurile de control ale programelor

In compunerea schemei logice a modulelor sau programelor intra trei tipuri de structuri de control: secventa (structura secventiala), selectia (structura alternativa) si iteratia sau repetitia (structura repetitiva - conditionata anterior, posterior sau la sfarsit). Aceste structuri pot fi formate din instructiuni sau din module si mai precis din blocuri standard, care vor fi definite mai jos. In elaborarea programelor structurate este necesar sa se respecte o serie de restrictii si anume:

- fiecare element (secventa, iteratia sau selectia) are un punct de intrare;

- fiecare element are un punct unic de iesire;

- elementul de iteratie permite si o executie cu factor de repetitie zero, adica excluderea elementului respectiv din executie.

Fiecare element care respecta restrictiile de mai sus defineste un bloc standard. In schema de mai jos folosim blocuri standard. De altfel, orice combinatie de blocuri standard, care respecta restrictiile de mai sus, defineste un bloc standard. Un exemplu de schema de control a unui program, folosita in proiectul soft, este schema structurii alternative de mai jos:

Nu Da

Bloc-2 Bloc-1

2.2 Diagramele de structura

In raport cu DFD si DER, diagramele de structura sunt o replica a acestora la nivelul sistemului, exprimata prin intermediul programelor sau modulelor. Practic, prin diagrama de structura este descrisa arhitectura fizica a modulelor sistemului. Ea scoate in evidenta intr-o forma grafica, modul in care partile sistemului sau ale programului sunt legate intre ele, sub aspectul transmiterii controlului de la una la alta sau a transferului de date. De regula se foloseste structura arborescenta inversa. Se poate spune ca diagrama de structura redefineste fluxurile si prelucrarile de date din DFD, convertindu-le in structura componentelor sistemului, prin care sa se respecte anumite principii ale proiectarii programelor. Diagramele de structura se folosesc si pentru a arata structura interna a programelor scrise in limbajele de generatia a treia si partial din generatia a patra.

Structura programelor scrise in limbaje de programare mai noi, orientate-obiect sau orientate-eveniment este redata prin intermediul diagramelor starilor de tranzitie sau pseudocod.

Pentru a ilustra modul cum se concepe o diagrama de structura, vom porni tot de la un pseudocod:

PRELUCRARE_TRANZACTII

DO INCEPUT

WHILE EXISTA-INCA-TRANZACTII

DO TRANZACTIE RETURNAND MATERIAL_TRANZ

DO VALIDARE_TRANZ TRANSMITAND

MATERIAL_TRANZ RETURNAND BUNA_SAU_REA

IF BUNA_SAU_REA ESTE REA

DO CORECTARE_TRANZ TRANSMITAND TRANZ_REA

RETURNAND TRANZ_OK

END IF

DO PRELUCRARE_TRANZ_BUNA TRANSMITAND

TRANZ_OK RETURNAND REZULTAT

DO SCRIE_REZULTAT

END LOOP

DO SFARSIT

Convertita intr-o diagrama de structura, prin notatia Yourdon & Constantine, procedura de mai sus va arata ca in figura de pe pagina urmatoare [1].

In aceasta figura, secventele in care sunt plasate modulele in pagina nu au legatura cu ordinea in care acestea vor fi apelate, dar daca ar coincide, schema ar fi mai usor de inteles prin citire de la stanga la dreapta.

Parametri plasati de-a lungul sagetilor mari si care reprezinta date elementare sau structuri de date, sunt scosi in relief prin sageti mai mici, terminate cu un cerculet neumplut, in timp ce parametri care simbolizeaza semnale de control (de ex. Buna_sau_rea ) sunt reprezentati prin cerculete umplute la punctul terminal al sagetilor mici.

O structura repetitiva (bucla) este marcata printr-o bucla plasata peste sagetile ce reprezinta modulele apelate in ciclul respectiv.

PRELUCRARE_

TRANZACTII

INCEPUT SFARSIT

TRANZACTIE SCRIE_REZULTAT

VALIDARE-TRANZ CORECTARE_TRANZ PRELUCRARE-

TRANZ_BUNA

Apelarea conditionata (exemplu CORECTARE_TRANZ) este reprezentata printr-un romb mic. Mai usor de realizat pare sa fie sistemul Michael Jackson de elaborare a diagramelor de structura, a carui varianta pentru pseudocodul de mai sus este urmatoarea:

PRELUCRARE_

TRANZACTII

PRELUCRARE *

INCEPUT TRANZACTII_IN_ SFARSIT

BUCLA

TRANZACTIE VALIDARE_TRANZ CORECTARE_TRANZ PRELUCRARE_ SCRIE_

TRANZ_BUNA REZULT

In aceasta varianta se folosesc tehnici speciale pentru indicarea repetitiei si a elementelor optionale, dar nu mai apar parametri dintre module.

Modulele care fac parte dintr-o structura repetitiva sunt marcate cu o steluta, iar cele optionale, ca efect a unei selectii, sunt notate cu un cerculet in interiorul lor.

2.3 Strategii de proiectare a softului

In decursul timpului s-au putut identifica trei strategii de proiectare a softului:

- descompunerea functionala;

- strategia centrata pe tranzactii;

- strategia centrata pe transformari.

Dintre acestea, descompunerea functionala care apartine anilor '70, nu prea mai este luata in consideratie. Motivul este acela ca strategii informatizarii vad sistemul prin prisma functiilor intreprinderii, pe care le descompun in subfunctii inrudite, operationale, dar informaticienii, care sunt legati de conditiile concrete de realizare a sistemului fizic, vad structura sistemului prin prisma resurselor fizice ale acestuia, adica legat de echipamente si de potentele limitate ale acestora si in consecinta ei descompun sistemul proiectat dupa criterii fizice. Ca urmare a celor de mai sus, s-a ales un reper mai usor accesibil ambelor categorii de persoane implicate in elaborarea sistemului informatic si anume transformarile la care sunt supuse datele. Aceasta orientare a dus la analiza transformarilor.

2.3.1 Analiza transformarilor

Metoda este orientata spre fluxul datelor si incearca sa ofere modalitati de identificare si organizare a functiilor programelor, care sa se apropie mai mult de modelul de structurare a problemei. De fapt, ea este o incercare de schimbare a mentalitatii programatorilor prin aceea ca le ofera acestora o alta cale de prestare a activitatii lor.

Analiza transformarilor apeleaza la DFD, pentru modelarea problemei si pentru a face structura ei cat mai inteligibila. In acest fel, activitatea de proiectare transfera modelul economic intr-o organizare ierarhica a modulelor softului, care sa nu se departeze de primul.

Esenta acestei metode poate fi ilustrata, pornind de la o diagrama abstracta a fluxurilor de date [1], prin care se modeleaza o parte a sistemului ce va fi implementat ca un program executabil.

In practica diagrame de acest fel vom avea la dispozitie numai dupa determinarea unitatilor de prelucrare (sectiunea 4.1) cand le vom folosi la proiectarea de detaliu a unitatilor de prelucrare (sectiunea 4.2)

b i

d g

e h

c j

LS2

B F

D E

C G

LS1 H

In aceasta diagrama fiecare cerculet reprezinta cate o transformare a datelor din fluxul sistemului, iar LS1 si LS2 sunt locuri de stocare, cum ar fi fisiere.

Proiectul, bazat pe fluxul descris prin aceasta DFD, va incepe prin identificarea modulului de nivel superior (notat EXEMPLU ABSTRACT) si care reprezinta functia programului in intregimea lui. In continuare se urmareste identificarea pe DFD a ramurilor importante de prelucrare a sistemului, urmand ca lor sa li se asocieze module de control in diagrama de structura a sistemului. Aceste ramuri sunt in general de trei tipuri: aferente (intrarile programului), centrale si eferente (cele care defluiaza dintr-un punct central spre altele periferice, cuprind toate transferurile datelor de iesire nestructurate, neformatate, produse de sistem, care trec printr-o serie de transformari in vederea obtinerii iesirilor fizice).

Ramurile aferente transforma intrarile fizice in intrari logice, pregatite pentru exercitarea functiilor principale de prelucrare ale organizatiei. Un exemplu de transformari aferente ar putea fi introducerea datelor, validarea, sortarea si alte prelucrari ce premerg constituirea datelor intr-o inregistrare care este buna sa intre in ramura centrala.

Ramura centrala de transformare poate sa nu fie unica. Ea consta in tot ce ramane dupa identificarea ramurilor aferente si eferente.

In cadrul acestei ramuri, fluxurile datelor de intrare sunt transformate in fluxuri de iesire.

EXEMPLU

ABSTRACT

Ramuri aferente Ramuri eferente

Obtinere Obtinere Creare Plasare Plasare

d e g,h g h

De regula, modulele aferente sau de intrare din diagrama de structura sunt pozitionate in stanga si sub superiorii lor, cele eferente in dreapta si sub superiorii lor, iar cele de transformare sunt pozitionate intre cele aferente si eferente.

In diagrama de structura a programului, ramurile aferente, eferente si centrale ale fluxurilor de date arata ca in figura de mai sus [1].

In aceasta diagrama avem cate un modul de control pentru fiecare ramura aferenta, fiecare ramura eferenta si pentru fiecare transformare centrala. Daca ar fi fost un caz mai complicat ar fi trebuit sa avem cate un modul de control pentru fiecare grup logic de transformari. Daca diagrama de structura a fluxului prezentat mai sus prin DFD s-ar opri la acest nivel, ea ar fi una superficiala. In realitate, ea trebuie dezvoltata pe nivelele inferioare. Practic, dupa ce s-a realizat structura de nivel superior a sistemului, se continua cu procese iterative, de tip top-down, pentru fiecare ramura a diagramei de structura. Fiecare cerculet al diagramei fluxurilor de date devine baza urmatorului set de module la nivel inferior al diagramei de structura. Procesul inceteaza la nivelul cel mai de jos al ramurii respective, adica acolo unde pot fi identificate intrarile (pentru ramurile aferente) si iesirile (pentru ramurile eferente).

Astfel, pentru ramura initiata de modulul Obtinere d, fluxul de date d este generat de procesul B, care la randul sau foloseste ca intrare fluxul de date b. Ca urmare, Obtinere d poate fi descompus in doua procese: unul de transformare a lui b in d (marcat pe DFD de transformarea B) si celalalt de obtinere a intrarii b in procesul de transformare (B). Ca urmare a acestui rationament, ramura initiata cu modulul Obtinere d, va evolua astfel:

EXEMPLU Se vede cum modulul Obtinere d receptioneaza un d

ABSTRACT prin apelarea modulului B, dar la apelarea lui B, el

d trebuie sa-i transmita acestuia pe b, or ca sa aiba un b,

trebuie sa apeleze modulul Obtinere b.

Obtinere Observam din DFD ca Obtinere b, ca sa obtina b, ar

d trebui sa apeleze modulul A, dar nu-l poate apela pe

A daca nu-i poate oferi un a si pentru aceasta trebuie sa

apeleze Obtinere a. Toata aceasta inlantuire de

b b d evenimente, face necesar sa-i adaugam modulului

Obtinere b, urmatoarea secventa:

Obtinere

b a b

Obtinere

Modulul Obtinere e va avea o structura asemanatoare cu cea a modului Obtinere d, doar ca in loc de b si respectiv B, acolo vor fi implicati c si C, iar in ce priveste al doilea nivel, reprezentat in cazul lui Obtinere d prin a si respectiv A, un asemenea nivel nu mai este necesar, deoarece transformarea C este prima pe aceasta ramura, nu ca B care era precedata de A.

In ce priveste ramurile eferente, cum ar fi cea initiata de modulul Plasare h va avea in prima treapta urmatoarea dezvoltare:

Ulterior, ca si ramura initiata de modulul

Obtinere d, ramura Plasare h va fi dez-voltata si pe nivelul al doilea pentru a-l plasa pe j lui H, iar acesta il va produce pe k, ce va face obiectul modulului Plasare k.

Aplicand rationamente asemanatoare pe toate ramurile diagramei de structura, aceasta va arata in final, ca cea de pe pagina urmatoare:

EXEMPLU

ABSTRACT

Plasare

j j

Sa remarcam ca aceasta diagrama va fi modificata prin apelare la unele criterii de evaluare, ce vor fi prezentate spre sfarsitul acestei sectiuni.

Pentru reprezentarea in diagrama de structura a ramurilor transformarii centrale, s-a plecat de la ideea ca, pentru fiecare cerc din mijlocul diagramei fluxului de date trebuie definit cate un modul separat. De cele mai multe ori, ramurile transformarii centrale sunt descompuse dupa aceleasi reguli ca ale descompunerii functionale. Aici se pune problema stabilirii unor criterii dupa care sa putem sti cand am ajuns la un nivel acceptabil pentru a opri descompunerea. Se spune ca descompunerea este completa atunci cand:

- nu mai exista subactivitati identificabile care sa poata fi adaugate nivelurilor inferioare;

- exista posibilitatea folosirii unei rutine sau a unei biblioteci standard pentru realizarea functiilor continute de un modul identificat de proiectant;

- modulele sunt atat de mici, incat au atins un nivel la care criteriile cuplarii, coeziunii si dimensionarii (care vor fi descrise in continuarea acestei sectiuni), ar putea fi incalcate prin continuarea partitionarii.

EXEMPLU

ABSTRACT

d h

e d,e g,h g

Obtinere Obtinere Creare Plasare Plasare

d e g,h g h

b d c e d,e g,h g h

b e f f i i j j

Obtinere B Obtinere C D E F Plasare G Plasare

b c i j

a b j

a k

Obtinere

Prima forma a diagramei de structura bazata pe analiza transformarilor [1]

2.3.2 Analiza tranzactiilor (operatiunilor)

Tranzactiile au intrat in atentia proiectantilor de soft pentru ca in unele domenii de activitate, cum ar fi cel bancar, operatiile sunt mai la indemana beneficiarului decat transformarile, iar din punct de vedere al proiectantilor de soft ele sunt avantajoase pentru ca in practica multe operatii prezinta asemanari in prelucrare si daca procesul este analizat pe baza tranzactiilor, se identifica posibilitati de refolosire a unor module program in prelucrarea mai multor tranzactii ceea ce reduce volumul de munca necesara pentru scrierea programelor.

Diagrama de structura a unui proiect centrat pe tranzactii arata in principiu astfel:

Centrul de

tranzactie

Proces tip 1 Proces tip 2 Proces tip 3

Structura A Structura B Structura C Structura D Structura E

a procesului a procesului a procesului a procesului a procesului

Proces detaliat Proces detaliat Proces detaliat

1 2 3

In aceasta diagrama modulul superior evidentiaza rolul tranzactiei, iar rombul simbolizeaza posibilitatea exprimarii optiunii pentru unul dintre modulele situate pe nivelul urmator (cel al proceselor).

La acest nivel, fiecare modul de prelucrare 'cunoaste' detaliile intime ale unei tranzactii (ce date foloseste, care sunt pasii de prelucrare) dar nu tine cont de celelalte tranzactii.

De acest lucru se tine cont incepand cu nivelul urmator, cand sunt efectuate prelucrarile reale ale tranzactiilor si unde incep sa se caute asemanari intre tranzactii, in vederea elaborarii unor module comune, eventual poliforme.

In varianta centrata pe tranzactii, DFD corespunzatoare a diagramei de structura trebuie sa indice punctele de ramificare paralela a fluxurilor de date ce vor trata fiecare tip de tranzactie. Ca urmare, o secventa de diagrama a fluxurilor de date va arata astfel [1]:

Proces

tip 1

Tip 1

Tranzactii Tip 2 Proces

tip 2

Tip 3

Proces

tip 3

Modelul de trecere de la diagrama fluxurilor de date la diagrama de structura este similar celui folosit in analiza transformarilor. Este de datoria proiectantului sa recunoasca situatiile in care intervin tranzactii multiple, precum si componentele inerente unei prelucrari logice dintr-o situatie data din unitatea studiata.

In ce priveste tranzactiile comune, cele mai reprezentative exemple sunt cele legate de actualizarea fisierelor, introducerea datelor on-line, programele orientate pe meniuri, s.a.

Astfel programele de actualizare se pot materializa in una din urmatoarele variante:

- o tranzactie de adaugare de noi inregistrari in fisier;

- o tranzactie de modificare a valorilor din anumite campuri ale inregistrarii;

- o tranzactie de stergere a unor inregistrari.

Ca urmare, un singur flux de intrare va fi transferat pe una dintre cele trei rutine, in functie de tipul tranzactiei.

2.3.3 Recomandari pentru proiectarea programului

Putem concluziona de pe acum ca se disting cel putin trei metode de proiectare a programelor: cele structurate pe functiile intreprinderii, cele structurate pe transformari si cele structurate pe tranzactii. La acestea se mai poate adauga o metoda orientata spre date si mai exact spre structura datelor de iesire ale programelor care se presupune ca trebuie sa reflecte structura datelor organizatiei. Totusi metoda nu este raspandita, asa ca ne vom concentra atentia asupra primelor trei.

Indiferent de metoda de proiectare a programelor folosita, softul de aplicatii trebuie sa urmareasca atingerea unor performante cum ar fi:

- functionare corecta;

- sa respecte specificatiile de realizare;

- sa fie sigur, mentenabil, usor de folosit, de implementat si de testat;

- sa foloseasca eficient resursele sistemului informatic;

- sa respecte planificarile calendaristice si bugetare;

- sa fie usor adaptabil diverselor medii de operare si programare.

Tot indiferent de metoda de proiectare a programelor folosita, se considera ca in elaborarea programelor ar trebui parcursi, in principiu, pasii urmatori:

- realizarea unei prime structuri pe componente a programelor, printr-o schema logica de sistem, pe baza diagramei fluxurilor de date, prin apelarea la unitatile de prelucrare (proceduri);

- examinarea partiala a DFD asociate fiecarui program al schemei logice a sistemului;

- pentru fluxurile mari de date se va aplica analiza transformarilor, ca un prim pas al descompunerii programului in rutinele sale principale de prelucrare;

- pentru programele ce nu se preteaza partitionarii corecte prin metodele tranzactiilor si transformarilor se incepe cu descompunerea functionala;

- de la caz la caz, se va continua cu descompunerea programelor dupa principiile analizei functionale, ale transformarilor sau ale tranzactiilor. Se va trece apoi la utilizarea structurilor de control fundamentale ale programarii, pentru realizarea sistemului;

dupa ce s-a realizat proiectul se va trece la aplicarea criteriilor de evaluare a obiectivelor proiectului ( a intregii structuri), criterii de care ne vom ocupa in continuare. Daca dupa aplicarea acestor criterii mai este cazul, se va efectua ultima restructurare a sistemului.

2.3.4 Evaluarea obiectivelor proiectelor software

Evaluarea calitatii proiectului soft se refera atat la caracteristicile externe cat si la cele interne ale modulelor, surprinse prin criteriile (conceptele) de cuplare si coeziune.

a) Cuplarea este masura gradului in care modulele programelor sunt interconectate. Pentru usurinta implementarii si intretinerii, se recomanda ca gradul cuplarii sa fie redus.

Exista cinci tipuri de cuplari:

- prin date elementare. Cuplarile datelor elementare din module, conectate printr-un control activ, inseamna doar transferarea datelor elementare necesare.

- prin date grupate. Presupune transferarea datelor grupate sub forma de structuri de date sau chiar inregistrari intregi, ceea ce implica riscul ca nu toate informatiile transmise sa fie si necesare ;

- cuplare prin informatii de control: aceasta presupune sa se transmita de la un modul la altul si coordonatele prelucrarii, de ex. modulul precedent sa transmita modului urmator daca a fost constatata o eroare si daca da ce eroare anume, pentru ca modulul urmator sa stie ce mesaj de eroare sa dea. Desigur, in acest caz modulele devin dependente unele de altele;

- cuplare comuna, cand doua sau mai multe module acceseaza in comun aceleasi date elementare aflate intr-un loc comun, cunoscut si ca bloc de date. Interdependenta intre module este in acest caz destul de mare;

- cuplare prin continut. Cea mai de nedorit forma de cuplare: ea duce la implicarea directa a unui modul in intimitatea prelucrarilor altui modul. De ex. un modul poate sa schimbe datele altuia, sau si mai grav, sa schimbe chiar instructiunile acestuia.

b) Coeziunea este masura legaturilor interne dintre componentele de prelucrare sau instructiuni, la nivelul unui modul. Altfel spus, se urmareste forma in care instructiunile dintr-un modul sunt folosite pentru realizarea aceleiasi functiuni. Gradul de coeziune ar trebui sa fie cat mai ridicat.

Exista sapte niveluri ale coeziunii. In ordinea descrescatoare a coeziunii, aceste nivele sunt: functional, secvential, comunicational, procedural, temporal, logic si coincidental:

- coeziune functionala, presupune ca modulul cu un nume cat mai sugestiv in ce priveste functia sa, sa se comporte ca o cutie neagra. Adica se cunoaste cu precizie de ce date are nevoie, cum trebuie sa fie ele structurate si se cunoaste si ce rezulta. Modulul poate fi folosit fara a se cunoaste prelucrarile sale interne.

- coeziunea secventiala, presupune ca modulul sa realizeze functii multiple de prelucrare asupra acelorasi structuri de date. De ex. calculeaza media studentului, calculeaza nivelul anului de studii si aplica criteriul de eligibilitate pentru bursa;

- coeziune comunicationala: se intalneste la modulele ce realizeaza functii multiple de prelucrare ce presupun acelasi set de date de intrare si de iesire. In diagrama fluxurilor de date, aceasta coeziune este reprezentata sub forma unor functii simultane de prelucrare. De ex. un modul care verifica datele ce lipsesc dintr-o tranzactie, afiseaza tranzactia pe ecran si realizeaza o copie a acesteia intr-un fisier.

Cu alte cuvinte modulul realizeaza mai multe functii pe aceeasi structura de date;

- coeziune procedurala: modulul contine elemente grupate pe baza fluxurilor de control din cadrul programului, adica functii independente, reunite doar pentru a asigura transferul controlului de la o functie interna la alta. Cazul modulelor ce contin blocurile standard de control: secventa, repetitia si selectia. De exemplu, un modul stie sa faca actualizare sub cele trei forme: adaugare, stergere sau modificare si in functie de codul operatiunii pe care-l primeste, va transmite controlul unuia din cele trei module de care dispune;

- coeziune temporala: se refera la module dependente de timp, cum ar fi deschidere fisier, initializare variabile, citirea primei inregistrari - module care trebuie executate toate, fara intercalarea altor module intre ele, de fiecare data, pe masura executarii programului.

- coeziune logica: se realizeaza prin includerea elementelor unui modul intr-o categorie generala cum ar fi de intrare-iesire, de corectare a erorilor, rutine de editare, etc., dar in realitate fiecare din elementele sale are functii distincte. Coeziunea logica poate fi evitata printr-o descompunere completa a programului. Uneori ea este folosita intentionat pentru a evita unele probleme de proiectare legate de realizarea legaturilor cu mediul extern, cu hardware-ul sau software-ul, respectiv includerea functiilor de intrare-iesire intr-un singur modul.

- coeziunea coincidentala presupune existenta unui numar redus de legaturi sau a nici unei legaturi intre elementele unui modul. De ex. din motive de utilizare eficienta a memoriei, proiectantul, pentru a evita redondanta in codificare a lasat un singur modul capabil sa faca o anumita operatie, dar nu stie care este structura problemei asupra careia se va executa modulul. Ulterior, daca sunt necesare modificari asupra proceselor de prelucrare, va fi greu de gasit setul de instructiuni corespondent functiilor incluse intr-un astfel de modul. Un modul care are o coeziune coincidentala nu functioneaza ca o cutie neagra, pentru ca proiectantul trebuie sa cunoasca detaliile interne de functionare a unui modul pentru a putea proiecta componentele cu care se afla in legatura.

3. Proiectarea sistemelor distribuite [1]

3.1 Aspecte generale privind sistemele de prelucrare distribuita a datelor

Un sistem de prelucrare distributia a datelor presupune existenta a doua sau mai multe sisteme independente de prelucrare a datelor numite noduri, avand putere proprie locala de prelucrare si stocare, interconectate intr-o configuratie de retea.

Intr-un astfel de mediu coopereaza trei componente tehnologice distincte: prelucrarea datelor, comunicarea datelor si reteaua de calculatoare. Sistemul de prelucrare distribuita a datelor trebuie sa dispuna de un sistem de prelucrare automata a datelor caracterizat de:

- posibilitatea prelucrarii independente;

- o configuratie de retea;

- posibilitatea transferurilor de date folosind sisteme de comunicatie partajate;

- un obiectiv comun de realizat.

3.2 Stabilirea obiectivelor si selectia sistemelor de prelucrare distribuita a datelor

3.2.1. Obiectivele proiectului trebuie sa fie enuntate in scrisoarea de intentie a echipei manageriale a beneficiarului. ele pot fi clasificate in obiective financiare si functionale.

Din punct de vedere financiar se urmareste maximul de profit cu minimum de cheltuieli, iar din punct de vedere functional scopul este acela de realiza un sistem cat mai eficient, deci cu rezultate cat mai bune.

In ciuda faptului ca obiectivele financiare sunt cuantificabile, iar cele functionale nu, efectele avantajelor necuantificabile se regasesc in situatia contului Profit si Pierdere a firmei.

3.2.2 Costurile sistemului de prelucrare distribuita a datelor

In cazul sistemelor mari de prelucrare distribuita a datelor (p.d.d.) trebuie luate in calcul atat costul din punct de vedere al utilizatorului, cat si costul din punct de vedere al companiei care presteaza serviciul. In aceste cazuri se descompun sistemele in module mai mici, bine definite, in care sa se poata controla necesarul de echipament si de software pentru subsistemele de p.d.d. si pentru comunicarea lor. In continuare, costul fiecarui modul va fi descompus in costuri initiale si costuri functionale, operationale sau de exploatare.

a) Costurile initiale. In cazul sistemului de comunicatie a datelor se pleaca de la costul inchirierii sau luarii in leasing a componentelor necesare atingerii obiectivelor. La acesta se adauga costul fiecarui loc de munca, cheltuielile de intretinere si mentinere in stare functionala a fiecarui echipament.

Mai trebuie avute in vedere costurile procesoarelor (calculatoarelor), perifericelor, costurile cablarii si costurile softului.

b) Costurile operationale. Acestea pot fi impartite in:

- costurile distribuirii datelor;

- costurile cu personalul;

- costurile functionarii echipmentelor din sala calculatoarelor (daca este cazul);

- costurile intretinerii sistemului.

3.2.3 Performantele sistemului.

Sunt apreciate prin prisma productivitatii si eficientei sistemului si sunt o functie a timpului de raspuns, randamentului, calitatii serviciilor oferite utilizatorilor si a nivelului serviciilor.

Calitatea serviciilor vizeaza siguranta sistemului, fidelitatea sistemului, integrarea sistemului ( la nivel nod si la nivel subsisteme de comunicatie), controlul si acceptabilitatea.

3.2.4 Criterii de selectie a sistemului de prelucrare distribuita a datelor.

Sistemul propus trebuie sa fie fezabil din punct de vedere tehnic si eficient din punct de vedere al costurilor de prelucrarea automata a datelor si a comunicatiilor din sistem.

Performantele sistemului mai sunt influentate si de alti factori cum ar fi: timpul de raspuns, randamentul, disponibilitatea, siguranta s.a.

Principalele criterii de selectie raman totusi timpul de raspuns, costul si securitatea.

Timpul de raspuns depinde de intarzierile produse in componentele aflate la distanta, intarzieri ale liniei de transmisie si intarzieri la centrul de prelucrare a datelor.

In ce priveste securitatea datelor, se au in vedere amenintarile si masurile de protectie.

Amenintarile pot proveni din partea componentelor sistemului, a personalului neloial firmei, slabiciunea procedurilor de protectie si de penetrarea retelei de comunicatie (prin ascultarea firelor sau prin captarea radiatiilor semnalelor transmise).

Masurile de protectie vizeaza securitatea fizica, securitatea personalului, criptarea informatiilor importante, studierea tehnicilor specializate ale intrusilor, suprimarea radiatiilor compromitatoare, securitatea liniilor de comunicatie si securitatea sistemelor de prelucrare automata a datelor.

3.3 Metodologia proiectarii sistemelor de prelucrare distribuita a datelor

Aceasta are doua componente majore:

- proiectarea nodurilor sistemului, care continua cu proiectarea propriilor sisteme de prelucrare automata a datelor ;

- proiectarea retelei de comunicatie a datelor (proiectarea fiecarei legaturi de date si a schemei de ansamblu a intregii retele cu topologia adecvata).

3.3.1 Proiectarea nodurilor sistemelor de prelucrare distribuita a datelor

- identificarea nodurilor;

- identificarea cerintelor aplicatiilor locale sau la distanta, a datelor locale si globale, a modurilor de prelucrare si a utilizatorilor sistemului de la fiecare nod;

- identificarea cerintelor locale de comunicare a datelor;

- selectarea echipamentelor de prelucrare ale nodurilor; se va tine seama de configuratia sistemului si de caracteristicile tehnice ale transmisiilor. Acestea din urma sunt urmatoarele:

- modul de transmitere (semi-duplex, full-duplex);

- tehnica transmisiilor (asincrona, sincrona);

- viteza de transmisie;

- codul transmisiei (ASCII sau EBCDIC);

- formatul de transmisie a mesajului (caracter-cu-caracter, linie-cu-linie, bloc-cu-bloc);

- protocolul de comunicatie(ASCII, BSC, SDLC, altele);

- tipul legaturii fizice (punct-la-punct sau multipunct);

- tipul microprocesoarelor folosite(Intel, Motorola s.a).

Selectarea sistemelor vizeaza selectarea terminalelor, a calculatorului, a unitatilor de memorie externa, a echipamentelor de intrare/iesire.

3.3.2 Echipamentele de transmisie a datelor catre noduri

- selectarea procesorului de comunicatii (un echipament special al unei retele folosit pentru separarea functiilor fizice si logice ale retelei de aplicatiile utilizatorului);

- selectarea modemului;

- selectarea multiplexoarelor.

3.3.3 Proiectarea subsistemului de comunicatie

- proiectarea liniilor de date (constituirea fizica a liniilor de date, selectarea protocoalelor de linie);

- proiectul retelei;

- proiectul topologiei retelei;

- selectia componentelor de comunicatie;

- interfatarea (inter-retele si intra-retele).

3.3.4 Elemente de proiectare a retelelor

De regula arhitectura unei retele trebuie sa raspunda cerintelor de interconectibilitate completa pentru toate resursele sistemului, prin apelare la protocoale si componente soft adecvate.

a) Tehnici de concepere a arhitecturii retelelor

Aceste tehnici vizeaza structura si protocoalele sistemului. Se folosesc urmatoarele tehnici:

- stratificarea si modularizarea . In faza de implementare, fiecare strat va fi tratat independent;

- abstractizarea stratului: se creaza un nivel de abstractizare in fiecare strat al retelei;

- mecanismul functional: o functie specifica dintr-o aplicatie data sau una de folosire a sistemului sa fie mutata la nivelul utilizatorului;

- protocoale in protocoale (imbricarea protocoalelor): protocoalele sunt structurate unul in interiorul altuia ;

- strat in strat: se concep straturi/niveluri ale arhitecturii retelei si protocoalelor corespunzatoare, concepute cu substraturi sau subseturi;

- folosirea resurselor: sunt avute in vedere resursele sistemului si modulele functionale de comunicare si identificare. Ca urmare, fiecare sistem sau subsistem al retelei stie daca poate sa transmita sau nu o anumita informatie catre alta componenta din reteaua sistemului;

- metoda sistemelor integrate: trebuie sa avem imaginea functionarii de ansamblu a sistemului, in asa fel incat toate nodurile sa functioneze in cadrul unei structuri date, iar arhitectura sa le trateze fie ca procesoare inteligente locale, fie ca niste comutatoare.

b) Criterii de selectie a retelei. Trebuie sa coreleze cerintele utilizatorilor cu cerintele retelei si se materializeaza prin gasirea protocoalelor, a cerintelor partii de legatura cu alte retele, a vitezei de transmisie, a protejarii impotriva erorilor, etc..

3.3.5 Proiectarea topologiei retelei. Aceasta afecteaza in mod direct costul ei de functionare. La proiectarea topologiei retelei sunt necesare sinteza traficului de date si sinteza retelei.

a) Sinteza traficului de date presupune colectarea informatiilor necesare estimarii gradului de incarcare a traficului de date al sistemului. Ulterior, acesta va fi transformat astfel incat sa poata fi utilizat in procesul de sinteza al retelei.

b) Sinteza retelei. Reteaua este alcatuita din noduri si linii de legatura. Nodurile pot fi finale sau centrale. Legaturile dintre centre se numesc intermachine trunk (IMT) iar cele care duc spre nodurile finale linii de acces (acccess line). Sinteza retelei vizeaza costurile retelei, optimizarea costurilor, dar se materializeaza in numarul de centre ale retelei, plasamentul acestora, alocarea fiecarui nod final la un centru si structura ierarhica a cailor pe care circula fluxul de date ale traficului.

3.3.6 Selectarea posibilitatii de comunicatie vizeaza selectarea posibilitatii de comunicatie (analogice sau digitale, comutate sau inchiriate, terestre sau prin satelit, etc.), selectarea unitatii publice de telecomunicatii (selectarea companiei) sau selectarea liniilor private.

3.3.7 Aspecte ale proiectarii retelelor locale:

- controlul retelei (flexibilitatea reconfigurarii, urmarirea starii retelei, detectarea caderilor si izolarea lor, managementul retelei);

- performantele retelei: siguranta, disponibilitatea si functionalitatea (cauzele defectiunilor, punctele sensibile ale retelelor, metode de control ale defectiunilor retelei);

- copiile de siguranta;

- sisteme de arhivare a datelor.

3.3.8 Interconectari de retele. Mare atentie trebuie acordata incompatibilitatilor generate de nestandardizarea echipamentelor si protocoalelor din domeniile comunicarii si prelucrarii datelor. Acestea pot genera probleme intraretea si probleme interretea.

- interfatarea in retea presupune conexiunea intre echipamente si acordul echipamentelor ce trebuie sa comunice printr-un protocol comun de comunicatie;

- interfatarea interretele; se disting doua situatii:

- retele ce au aceleasi protocoale interne si cerinte identice de interfatare (retele omogene);

- retele ce au protocoale interne diferite si cerinte de interfatare diferite (retele neomogene).

Un caz de retele neomogene dar si de lunga distanta este interconectarea LAN-uri cu retele pe distanta lunga. Acestea se vor aborda prin prisma accesului la retea, a folosirii serviciilor retelei si a folosirii functiilor protocoalelor.

3.4 Particularitatile sistemelor file-server si client/server

3.4.1 Arhitectura file-server presupune mai multe statii de lucru si un server in care se vor afla bazele de date si aplicatiile folosite in comun de celelalte calculatoare, toate legate intr-o retea locala. Toate operatiunile asupra datelor se efectueaza la statiile de lucru, care lanseaza serverului cereri de date. Serverul este vazut de statiile de lucru ca un hard disc suplimentar; in plus el ofera resurse suplimentare (unitati de discuri, imprimante, etc.) si aplicatii de comunicare (de ex. Posta electronica). Daca se foloseste un SGBD, fiecare statie poate folosi programele de aplicatii SGBD ca si cum i-ar apartine. Pentru aceasta trebuie sa existe mai multe copii ale bazei de date si acestea pot fi exploatate concurential de statiile de lucru. Pentru o prelucrare de date, statia isi trage fisierul de care are nevoie de pe hardul serverului si-l foloseste pe hardul sau. Softul de pe file-server creaza cozi de asteptare a cererilor. Controalele pe linia securitatii, precum si blocarea fisierelor sau a inregistrarilor sunt efectuate prin PC-uri, ceea ce conduce la un proces complex de dezvoltare a aplicatiilor multi-server. Utilizarea retelelor locale bazate pe file-server sunt limitate de:

- un transfer excesiv de date;

- nevoia utilizarii unor statii de lucru foarte puternice;

- descentralizarea controlului datelor.

3.4.2 Arhitectura client/server este o imbunatatire esentiala a sistemelor bazate pe retele locale. Aici prelucrarile din aplicatii sunt impartite intre client si server. Clientul rezolva problema administrarii interfetei-utilizator si prezentarea datelor, iar serverul stocheaza datele si da acces interogarilor primite. Acum serverul nu mai da tot fisierul ci numai partea selectata prin interogarea transmisa de client. Mai mult decat atat, uneori serverul lanseaza pe client si programul necesar pentru a executa o anumita operatie. Cu alte cuvinte a scazut volumul datelor transferate, dar a aparut si un transfer de soft. Toate operatiunile de restaurare a datelor, de securitate si de gestionare a accesului concurential sunt centralizate la server. In cazul SGBD, functiile centrale sunt numite DataBase-Engine sau Back-end, iar cele bazate pe client se numesc Front-end. Serverul trebuie sa fie mult mai puternic decat in cazul arhitecturii file-server.

Un avantaj al arhitecturii bazate pe client/server consta in posibilitatea decuplarii mediului clientului de cel serverului. Astfel, un client poate folosi Quattro Pro, Foxpro, dBase IV sau orice alt limbaj de generatia a patra care are o interfata a programului de aplicatii (API) pentru motorul bazelor de date. Cele mai populare medii API utilizate in prezent sunt:

SQL Link (pentru Paradox), DataEase SQL (pentru limbajul DataEase), @SQL (Add-In) din LOTUS, Q+E (Add-In) din Excel , SQL Windows, Power Builder, Object/l, s.a.

3.5 Administrarea datelor in sistemele distribuite. Cand statiile sunt dispersate geografic, bazele de date pot fi stocate pe un calculator central, dar acum se folosesc baze de date distribuite pe o retea de calculatoare locale. Punctele de lucru pot fi dispersate la nivelul unei cladiri sau la nivelul intregii planete.

De fapt este vorba de o singura baza de date dispersata fizic pe calculatoarele retelei locale. Apare astfel conceptul de transparenta a amplasarii (location transparency) in sensul ca un utilizator care are o cerere de date nu trebuie sa stie in ce loc se afla acele date.

3.5.1 Optiuni de distribuire a bazelor de date. Exista patru strategii principale de distribuire a bazelor de date:

- replicarea (reproducerea sau copierea) datelor; presupune pastrarea a cate unei copii la fiecare nod al retelei;

- partitionarea (separarea) orizontala; unele linii ale tabelei sunt plasate intr-un nod, altele in locuri diferite;

- partitionarea (separarea) verticala; presupune transfer de coloane (de campuri) pe principii relationale;

- combinatii ale primelor trei forme.

3.6 Solutii de proiectare a sistemelor distribuite

Exista tendinta trecerii spre sisteme cu date si prelucrari distribuite;

Forme avansate ale arhitecturii client/server pleaca de la existenta a trei componente (functii) esentiale ale oricarui sistem informational: managementul datelor, prezentarea datelor si analiza datelor. Diferitele forme de arhitecturi distribuie functiile de mai sus fie numai clientului, fie numai serverului, fie amandurora. Ca urmare s-au conturat 6 variante de arhitecturi client/server:

- prezentare distribuita (reformatare date la utilizator);

- prezentare la distanta (date formatate pe comanda la server) ;

- managementul datelor la distanta (datele primare de pe server sunt restaurate si analizate);

- functie distribuita (datele primare selective de pe server sunt restaurate si analizate pe server si apoi transmise statiei);

- baza de date distribuita (datele restaurate sunt analizate atat la server cat si la client);

- prelucrarea distribuita (datele sunt restaurate de pe server pentru analiza, apoi transmise clientului pentru analiza si prezentari).

4. Documentatia fazei de proiectare fizica

Teoria expusa in sectiunile acestui capitol poate fi aplicata numai pe o situatie concreta, preluata din faza de proiectare logica si dezvoltata pentru a se ajunge la un model fizic al sistemului. Aceasta dezvoltare presupune sa definitivam descrierea structurii generale a bazei de date relationale, conform modelului prezentat in subsectiunea 1.6 (descriere efectuata in termenii specifici proiectarii fizice) si apoi sa determinam unitatile de prelucrare. Vom continua cu proiectarea de detaliu a unitatilor de prelucrare, care se poate realiza prin aplicarea teoriei din sectiunea 2 conjugata si cu unele considerente expuse in subsectiunea 4.1 si 4.2. Documentatia proiectarii fizice trebuie sa se incheie cu descrierea entitatilor, organigrama unitatilor functionale, machetele videoformatelor si meniurilor, cu schemele unitatilor functionale (bazate pe structura specifica a bazei de date) si bineinteles cu listele programelor sursa si cu imagini ale meniurilor si ecranelor generate de aceste programe.

4.1 Determinarea unitatilor de prelucrare [5]

Aceasta presupune stabilirea tipologiei si succesiunii unitatilor de prelucrare.

Prelucrarile bazei de date sunt asigurate de succesiunea logica a tipurilor de unitati functionale prezentate la punctul 5.1 din capitolul proiectare logica.

Pentru unitatile functionale de creare si reactualizare a bazei de date, succesiunea unitatilor de prelucrare se determina pe baza ordinii de prelucrare a entitatilor bazei de date determinata in etapa de proiectare logica si descrisa in capitolul precedent, la sectiunea 6. Pentru unitatile functionale de exploatare a bazei de date si obtinerea iesirilor solicitate, succesiunea unitatilor de prelucrare este determinata in raport de natura subsistemelor informatice proiectate, frecventa, termenul si continutul informational propriu situatiilor de iesire preconizate.

Unitatea de prelucrare sau procedura reprezinta o secventa de operatii automate, repetitive, executate fara intreruperi externe de la un terminal, care transforma un ansamblu de date de intrare pe baza unui program, intr-un ansamblu de date de iesire, prin intermediul unor operatiuni de prelucrare.

In mod concret, determinarea unitatilor de prelucrare presupune:

- stabilirea functiei unitatii de prelucrare; din acest punct de vedere exista

- unitati de prelucrare pentru dirijarea tuturor prelucrarilor unitatii functionale (UPd);

- unitati de prelucrare pentru creare si validarea bazei de date (UPc);

- unitati de prelucrare pentru actualizarea continutului bazei de date (UPa);

- unitati de prelucrare pentru exploatarea bazei de date si obtinerea situatiilor de iesire (UPi) ;

- unitati de prelucrare pentru reorganizarea bazei de date (UPr);

- unitati de prelucrare pentru salvarea si protectia bazei de date (UPs);

- stabilirea intrarilor: optiuni de prelucrare, date de intrare si structura fizica a bazei de date (se va indica perifericul de la care se introduc date si calea spre fisierul-entitate necesar);

- stabilirea iesirilor: entitati create sau informatii afisate la terminal, prin grafice sau la imprimanta; (se va indica perifericul la care ies date si calea spre fisierul-lista rezultat);

- logica interna de prelucrare (modul concret de transformare a intrarilor in iesiri (validare, conversie, actualizare, constituirea entitatilor intermediare, ordonarea si compunerea acestora, obtinerea unor indicatori, a situatiilor de iesire, etc.);

- interfata intre unitatile de prelucrare: este formata din entitatile bazei de date la momentul t care pot constitui intrari intr-o alta unitate de prelucrare la momentul t+1.

Determinarea unitatilor de prelucrare (procedurilor) se concretizeaza in Organigrama unitatii functionale, intr-un tabel de forma urmatoare:

Denumire unitate de prelucrare (U.P.)	Functiile U.P.	Caracteristici intrari/iesiri	Unitati de prelucrare componente
Unitatea functionala 1
UP 1
UP 2
Unitatea functionala 2

Unitatile functionale (UF) dezvoltate in acest tabel sunt cele determinate in etapa de proiectare logica. Acolo, organigrama lor de prelucrare se prezenta sub forma grafica. Pentru elaborarea acestui tabel trebuie sa tinem cont de urmatoarele aspecte:

- natura sistemului informatic proiectat, frecventa si dispozitivul periferic de obtinere a situatiilor de iesire;

structura UF, intrari/iesiri UF, modul de realizare a interferentelor din UF, asa cum reiese din Organigrama sistemului informatic;

- restrictii impuse de sistemul de operare, inclusiv S.G.B.D., restrictii ale sistemului electronic de calcul;

- descrierea logico-fizica a bazei de date efectuata in sectiunea 1.6;

- identificatorii atributelor de tip cheie;

- ordinea de creare a entitatilor, asa cum rezulta din ordinea de prelucrare a B.D. stabilita in etapa de proiectare logica.

Organigrama unitatii functionale este organizata pe urmatoarele unitati functionale:

- UF pentru crearea/actualizarea B.D.:

- UP pentru dirijarea prelucrarii;

- UP pentru actualizarea bazei de date ;

- UF pentru exploatarea bazei de date si listarea situatiilor de iesire;

- UP pentru dirijarea prelucrarilor;

- UP pentru listarea situatiilor de iesire;

- UF pentru reorganizarea structurii conceptuale a bazei de date;

- UP pentru dirijarea prelucrarilor;

- UP pentru reorganizarea bazei de date;

- UF pentru securitatea/protectia B.D.:

- UP pentru dirijarea prelucrarilor;

- UP de protectie a B.D.;

- UP de criptare/decriptare a B.D.

4.2 Documentatia referitoare la proiectarea de detaliu

a unitatilor de prelucrare [5]

Odata determinate unitatile de prelucrare din cadrul fiecarei unitati functionale trebuie sa realizam proiectarea de detaliu a unitatilor de prelucrare.

Acestea se definitiveaza in functie de destinatia lor:

- unitati de prelucrare necesare pentru actualizarea si exploatarea structurii specifice a bazei de date;

- unitati de prelucrare necesare pentru exploatarea structurii fizice a bazei de date.

4.2.1 Proiectarea de detaliu a unitatilor de prelucrare necesare pentru actualizarea si exploatarea structurii specifice a bazei de date are doua faze:

4.2.1.1 Descrierea structurii specifice a bazei de date realizeaza selectarea atributelor specifice pe categorii de utilizatori (compartimente functionale sau activitati) rezultand subscheme ale B.D.

Proiectarea structurii specifice se bazeaza pe:

- analiza corelatiei dintre continutul si structura bazei informationale;

- gruparea situatiilor de iesire pe activitati, compartimente beneficiare si frecventa de obtinere in functie de obiectivele noului sistem;

- analiza:

- naturii activitatilor si subactivitatilor reflectate de catre atributele necalculate existente in situatiile de iesire;

- compartimentelor functionale implicate in realizarea sistemului;

- frecventei de prelucrare a atributelor prin intermediul bazei de date;

- omogenitatii atributelor din structura bazei informationale.

Descrierea structurii specifice a bazei de date trebuie sa reflecte apartanenta fiecarei entitati la una sau mai multe subscheme sau mai exact la ce entitati

trebuie sa aiba acces sau ce entitati trebuie sa contina o subschema.

4.2.1.2 Determinarea intrarilor-iesirilor si modulelor

(Organigrama unitatii de prelucrare)

Pornind de la structura datelor de intrare-iesire stabilita in etapa de proiectare logica (avem in vedere structura entitatilor bazei de date, a listelor de erori, a listelor de tranzactii externe sau a iesirilor generale ale sistemului informatic), se urmareste conturarea clara a modulelor componente ale unitatii de prelucrare. Acestea urmaresc descompunerea functiei complexe a unitatii de prelucrare in functii elementare, interconectate si interconditionate logic, astfel incat modulele sa asigure integral functia generala a unitatii de prelucrare. Modulul este caracterizat de:

- nume modul;

- functia modulului ;

- variabilele de apelare si revenire; ultima are rolul de a preciza daca modulul si-a indeplinit functia sau nu;

Intrarile si iesirile modulelor precizeaza dispozitivele, directoarele, subdirectoarele, denumirea si extensia fiecarei intrari-iesiri.

Organigrama unitatii de prelucrare se poate prezenta sub forma unui tabel avand structura:

Denumire

modul

Functie modul

Variabile

Intrari

Iesiri

La apelare

La revenire

Daca, cu toate criteriile enumerate mai sus, unele unitati functionale sau chiar unele proceduri sunt greu de descompus, se poate apela la teoria din sectiunile 2.2 si 2.3. Dupa identificarea structurii unitatilor de prelucrare pe fondul subschemelor BD, se pot elabora machetele meniurilor specifice fiecarui comportament functional, iar pentru fiecare unitate de prelucrare se poate intocmi schema de sistem asociata procedurii.

O astfel de schema contine un simbol pentru perifericul de unde se lanseaza procedura, insotit de codul programului prin care se lanseaza procedura, simbolul de program (un dreptunghi), divizat corespunzator numarului de module de care dispune procedura, langa care, pentru fiecare modul se va specifica lista parametrilor de intrare. Acest simbol va fi legat cu un simbol de BD in care sunt specificate tabelele de care este nevoie, dar va fi legat si cu un simbol de iesire (de ex. de listing), pe care vor fi specificate codurile rapoartelor sau listelor ce se obtin la terminarea rularii procedurii. Figura de pe pagina urmatoare prezinta un exemplu de schema de sistem.

4.2.2 Proiectarea structurii fizice a bazei de date presupune proiectarea algoritmilor specifici prelucrarii structurii fizice a bazei de date si exploatarea structurii fizice a bazei de date.

4.2.2.1 Proiectarea algoritmilor specifici prelucrarii structurii fizice a bazei de date presupune determinarea si utilizarea operatorilor de prelucrare, a variabilelor de memorie necesare, inclusiv verificarea atributelor bazei de date, dupa cum urmeaza:

CON: R1.frx

Exemplu de schema de sistem

Informatiile trecute pe schema nu sunt corelate; ele au fost trecute doar pentru a sugera natura informatiilor specificate pe schema: denumire de document, de periferic de intrare, cod program de lansare procedura, numele programelor din compunerea procedurii, baza de date si tabelele necesare, periferic de iesire, cod document de iesire.

R2.frx

Fisa cont client

Conturi

list

banca.dbf act.pl

cont.dbf pl

plati.dbf

LPT1: R1.frx

R2.frx

- operatori generali de prelucrare: duplicare, conversie, sortare, interclasare, separare, asociere, scindare, actualizare;

- operatori relationali: reuniune, diferenta, intersectie, proiectie, selectie, compunere, recompunere, produsul si diviziunea;

- variabile de memorie: sunt folosite pentru dirijarea prelucrarilor unei proceduri sau pentru stocarea temporara a unor valori utilizate la nivelul unui modul sau a unei unitati de prelucrare. Ele pot fi salvate in entitati specifice care au extensia implicita MEM; exista variabile de memorie locale si variabile de memorie globale;

- verificarea atributelor bazei de date presupune introducerea, transpunerea datelor din documentele de intrare in structura fizica a bazei de date, urmata de

verificarea (validarea) valorii atributelor introduse.

.2.2.2 Proiectarea de detaliu a unitatilor de prelucrare impuse de exploatarea structurii fizice a bazei de date presupune elaborarea procedurilor necesare pentru crearea, actualizarea, listarea, reorganizarea si salvarea bazei de date.

Exploatarea structurii fizice a bazei de date este realizata prin intermediul unei secvente logice de unitati de prelucrare, de dirijare, creare, actualizare, listare, reorganizare si salvare a bazei de date, constituite omogen sub forma unei baze de proceduri (BP). Daca unitatile de prelucrare realizeaza fiecare cate o functie complexa, modulele din care acestea sunt formate realizeaza functiile elementare din care se compun de fapt functiile complexe.

Exista trei tipuri fundamentale de module:

- de pregatire a prelucrarii (alegere culori, initializari de variabile, memorare rezultate ale unitatii de prelucrare);

- modul general de prelucrare (cel care ofera utilizatorului optiunile de prelucrare precum si structurile de programare);

- modul final de prelucrare (de inchidere a bazei de date, precizarea unor valori finale pentru variabilele de memorie, utilizarea comenzii RETURN, QUIT, etc.).

Pornind de la aceste considerente, putem aplica, daca mai este nevoie, teoria prezentata in sectiunea 2 a acestui capitol. Oricum, pentru fiecare unitate de prelucrare trebuie sa dispunem la acest stadiu de schema procedurii si de organigrama unitatii de prelucrare sau de diagrama de structura a procedurii.

Este momentul sa ne asezam in fata calculatorului, sa pornim SGBD-ul ales, sa creem tabelele, sa facem legaturile intre acestea, sa instauram restrictiile de integritate a bazei de date, sa elaboram meniurile, formularele si rapoartele, (eventuale interogari si/sau views) si unde este cazul chiar sa facem programare. In paralel se pot elabora programe de help, tururi de instruire si manualul de utilizare a sistemului sau aplicatiei. Sa nu uitam de siguranta si securitatea datelor, iar in final sa ne gandim la un kit de instalare a softului astfel elaborat.

4.3 Documentatia privitoare la softul ce compune sistemul informatic

Aceasta contine imagini reale extrase de pe ecranul calculatorului referitor la:

meniuri, dialoguri si mesaje, formulare/formate, exemple de liste/rapoarte scoase de la calculator pe baza unor date de test.

Observatii

1. Daca este cazul, formularele/formatele proiectate in etapa de proiectare logica se adapteaza la specificul unitatilor de prelucrare determinate in etapa de proiectare fizica, eventual se adauga noi videoformate.

2. In conditiile utilizarii bazelor de date distribuite documentatia fazei de proiectare fizica va mai contine o sectiune referitoare la configuratia retelei de calculatoare si una la organizarea bazei de date distribuite.

Solutiile concrete adoptate pentru bazele de date distribuite vor tine seama de teoria prezentata in sectiunea 3.

Bibliografie: Dumitru Oprea, 'Analiza si proiectarea sistemelor informationale economice', Editura Polirom, Bucuresti, 1999.

EXEMPLU DE DOCUMENTATIE PENTRU

ETAPA DE PROIECTARE FIZICA [2]

a) 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;

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
3. 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	Descriere	Figura
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, sche-mele 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