PREFAŢĂ

Proiectarea sistemelor informatice reprezintă astăzi o activitate deosebit de complexă prin complexitatea problemelor abordate, care necesită deopotrivă experienţă şi inventivitate, cunoştinţe despre ce s-a creat în domeniu şi despre noile tehnologii informatice ce pot fi utilizate, despre succese şi eşecuri ale acestei activităţi care este deopotrivă ştiinţifică, practică, imaginativă, creativă şi aplicativă.

În condiţiile unei evoluţii spectaculoase, fără precedent, în domeniul hardware şi software, a unor tehnologii moderne de comunicare, de prelucrare şi stocare a datelor, proiectarea sistemelor informatice capătă noi valenţe, trebuie să ţină cont de toate acestea la un loc şi, mai mult, de specificul activităţii beneficiarului, de dorinţa acestuia de informatizare, dar şi de puterea sa financiară pentru susţinerea acestora.

Dimensiunea nouă, impunătoare, atât a problematicilor abordate, cât şi a costurilor antrenate pentru dotarea cu platforma hardware necesară şi pentru proiectarea şi exploatarea sistemelor informatice impune cu necesitate o activitate de proiectare a sistemelor informatice responsabilă, bine fundamentată, organizată şi justificată economic. Spunem deci că responsabilitatea echipei de proiectare a unui sistem informatic, a şefului de proiect creşte considerabil, cu atât mai mult cu cât sumele de realizare antrenate sunt mai mari sau efectele colaterale mai nocive.

În aceste condiţii specialiştii în informatică, alături de personalul implicat în proiectarea şi realizarea sistemelor informatice trebuie să cunoască din punct de vedere teoretic termeni, concepte, tehnici şi metode ce pot constitui instrumentarul lor de lucru, dar şi modul de utilizare practică a acestora pentru modelarea corectă a fenomenelor şi proceselor economice.

“Tehnologii informatice” reprezintă un termen actual, care defineşte combinaţia dintre tehnologiile de calcul – formate din platforma hardware şi software implicate – şi tehnologia informaţiei, reprezentată prin reţele de transmitere a datelor, a imaginii, a sunetului.

Se ştie că sistemul informaţional este astăzi un element component al sistemului de management, iar automatizarea sa prin introducerea prelucrării, transmiterii şi stocării automate a datelor în diferite sectoare dă naştere sistemului informatic. Practic orice sistem informaţional modern presupune includerea tehnologiilor informatice în activităţile de culegere, prelucrare şi transmitere a datelor. Cu alte cuvinte, mai mult ca oricând se pune azi problema proiectării unor sisteme informatice integrate, a unor aplicaţii informatice sau produse program la cheie, sau a reproiectării unora mai vechi, care nu mai corespund cerinţelor actuale de informare şi posibilităţilor tehnice moderne de realizare a acestora.

Mutaţiile din domeniul tehnologiilor informaţionale şi cele din domeniul metodelor de abordare a sistemelor se reflectă continuu în ciclul de viaţă al

5

sistemelor informatice, fie prin schimbări ale etapelor acestora, fie prin schimbarea opticii de abordare şi parcurgere a acestora.

Noile tehnologii informatice influenţează direct proiectarea unui sistem informatic nou sau fac necesară reproiectarea unui sistem existent, tocmai pentru a ţine seama de ele.

În aceste condiţii – echipa de proiectare şi realizare a unui sistem informatic – ţinând seama de ultimile noutăţi în domeniul tehnologiilor informatice, cunoscând ultimile metode, tehnici şi strategii de realizare a sistemelor informatice – şi având o bogată experienţă în domeniu, va trebui să analizeze, să modeleze şi să reprezinte structura noului sistem.

Pe de altă parte, creşterea complexităţii problematicilor apărute, diversitatea funcţiilor ce trebuie realizate, cerinţele ridicate faţă de calitatea prelucrărilor, au impus necesitatea abordării sistemice, unitatea economico-socială fiind privită ca sistem. Şi, cum metodele moderne se bazează pe aplicarea teoriei sistemelor în analiza, proiectarea şi chiar realizarea efectivă a sistemelor informatice, se impune prezentarea şi înţelegerea unor concepte de bază din teoria sistemelor.

Ţinând seama de toate acestea, manualul se adresează în primul rând specialiştilor în informatică, oricare ar fi domeniul lor de competenţă, care doresc să-şi clarifice aspecte legate de partea de proiectare propriu-zisă sau de implementare a unui sistem informatic

Cartea se adresează într-un mod special studenţilor de la Facultatea de Informatică Managerială din cadrul Universităţii Româno-Americane, care se pregătesc acum să devină informaticieni de elită, specialişti în proiectarea sistemelor informatice.

Cartea se adresează deasemenea tuturor celor care sunt sau vor fi implicaţi în proiectarea sau reproiectarea sistemelor informatice singulare sau integrate, la nivelul unei firme, grup de firme, administraţie publică sau la nivel naţional, ca proiectanţi sau beneficiari ai sistemelor proiectate, deopotrivă.

Despre toate acestea, despre tehnici, tehnologii şi metode de abordare, de proiectare şi realizare a sistemelor informatice veţi afla citind această carte.

Mult succes, vă doreşte

Autoarea

6

1. SISTEMUL INFORMATIC – COMPONENTĂ A SISTEMULUI DE MANAGEMENT

1.1.Unitatea economico-socială privită ca sistem

Teoria sistemelor îşi găseşte azi aplicarea în cea mai mare parte a domeniilor vieţii economice şi sociale. Astfel, în prezent marea majoritate a teoriilor, metodelor şi realizărilor societăţii umane sunt concepute, prezentate, proiectate, realizate şi în general abordate prin prisma teoriei sistemelor.

La modul general, un sistem se poate defini ca un ansamblu de elemente intercorelate funcţional, care acţionează într-un anumit scop. Orice sistem se caracterizează prin următoarele:

a) intrările sistemului (Xi)b) ieşirile sistemului (Yi)c) obiectivele sistemului sau scopul final (Zi)d) procesele ce au loc în cadrul sistemului (P)e) starea sistemului la un moment datPutem reprezenta grafic un sistem ca în figura 1.1.

Fig. 1.1 Sistemul – reprezentare grafică

Având în vedere definiţia de mai sus, putem spune că orice unitate economică, societate comercială individuală sau de grup, poate fi privită ca un sistem. Astfel, în orice societate economică identificăm:

Elementele sistemului, formate din compartimentele sau elementele structurale ale acesteia (departamente, compartimente, birouri sau secţii, ateliere etc..), între care se stabilesc relaţii (de subordonare sau colaborare) prevăzute prin statutul societăţii, prin organigrama asociată acestuia şi/sau prin Regulamentul de Organizare şi Funcţionare.

O societate economică oarecare poate fi privită şi prin prisma funcţiilor sale de bază, ca elemente între care se stabilesc relaţii :

- Producţie sau Prestări Servicii- Resurse Umane- Financiar-Contabilitate

7

- Comercială (Aprovizionare-Desfacere)- Cercetare –Dezvoltare- Marketing Scopul funcţionării oricărei societăţi este realizarea de produse sau

prestarea de servicii în vederea obţinerii unui profit; Intrările în sistem sunt reprezentate de resursele materiale, financiare şi

umane necesare pentru realizarea activităţilor din cadrul unei societăţi. O parte dintre acestea se constituie de la început, sub formă de capital social, iar restul constituie obiectul activităţilor de aprovizionare şi consum curente;

Ieşirile din sistem sunt reprezentate de produsele şi serviciile vândute, conform unor programe şi grafice de realizare şi desfacere, pe baza unor contracte sau comenzi ferme;

Procesele ce au loc în cadrul unei societăţi sunt reglementate şi descrise în cadrul procesului tehnologic, a sarcinilor stabilite prin Regulamentul de Ordine şi Funcţionare (ROF) pentru fiecare compartiment, birou sau post – prin Fişa postului.

Starea sistemului – unitate economică – este reflectată, în orice moment, prin evidenţa financiară, contabilă, a personalului, prin indicatorii analitici şi sintetici calculaţi în orice moment.

Putem reprezenta grafic sistemul oricărei unităţi economice ca în figura 1.2..

Fig. 1.2. Unitatea economică reprezentată ca sistem

Pe de altă parte, în cadrul unei unităţi economice identificăm două mari subsisteme: subsistemul decizional sau de conducere şi subsistemul operativ sau de execuţie.

Comunicarea între diferite subsisteme şi în cadrul acestora se realizează prin intermediul sistemului informaţional. Dacă ne referim la o unitate economică ca sistem cibernetic, sistemul informaţional se interpune între sistemul condus şi sistemul de conducere, asigurînd comunicarea dintre ele (puntea de legătură) (fig. 1.3.).

8

Orice sistem poate fi deci privit ca un ansamblu de elemente interconectate şi intercondiţionate prin relaţii fizice, sociale şi de altă natură care funcţionează în vederea realizării unui scop sau a finalizării unui obiectiv.

Procesele desfăşurate într-o activitate organizată nu au loc la întâmplare, ci sunt declanşate de anumite informaţii, care prelucrate, servesc la luarea unor decizii. Aceste decizii determină executarea unor serii de operaţii.

Deci, activitatea desfăşurată în vederea realizării unui obiectiv poate fi definită ca fiind rezultatul acţiunii conjugate a trei subsisteme ce acţionează într-o strânsă interdependenţă şi care la rândul lor pot fi considerate sisteme:

- sistemul de conducere, de management sau decizional (S.D.) - sistemul condus, de execuţie sau operaţional (S.O.) - sistemul informaţional.Sistemul de conducere (de management) are rolul de a dispune şi îndruma

activitatea în vederea realizării obiectivelor fixate, cu eficienţă maximă.Sistemul condus (operativ sau de execuţie) are rolul de a executa practic

deciziile luate şi de a furniza date privind acţiunile realizate sau în curs de execuţie, folosind pentru aceasta resursele materiale, financiare şi umane existente, repartizate pe obiective dinainte stabilite.

Pentru executarea activităţilor de bază ale procesului decizional: planificare, urmărire, control şi decizie, sistemului de conducere îi sunt necesare informaţii despre starea şi evoluţia sistemului de execuţie, despre legăturile acestuia cu exteriorul. De la Sistemul de conducere spre sistemul condus vor circula decizii. Acest circuit de informaţii şi decizii reprezintă un proces permanent care se realizează prin existenţa Sistemului informaţional.

Sistemul informaţional este un instrument indispensabil conducerii, având ca părţi componente mijloacele şi procedeele ce asigură legăturile între elementele de execuţie şi elementele decizionale pentru conducere şi organizare.

În felul acesta prin sistemul informaţional se pot cunoaşte la timp şi în cantităţi necesare toate elementele de caracterizare a activităţilor desfăşurate, el cuprinzând fondul de informaţii, tehnicile de colectare şi stocare, mijloacele şi metodele necesare în vederea prelucrării şi transmiterii informaţiilor.

Deci, sistemul informaţional este un ansamblu de fluxuri şi circuite informaţionale organizate într-o concepţie unitară. El utilizează modele, proceduri, resurse umane şi materiale pentru colectarea, înregistrarea, prelucrarea, stocarea şi/sau transmiterea datelor şi a informaţiilor, prin intermediul cărora asigură interconexiunile informaţionale dintre sistemul de conducere şi sistemul condus, dintre elementele componente ale acestor sisteme, dintre organismul social economic pe care îl serveşte şi mediul social economic extern. Sistemul informaţional reprezintă deci un ansamblu de oameni, echipamente, software, procese şi date destinate să furnizeze informaţii active sistemului decizional.

9

Scopul final al sistemului Informaţional (SI) este realizarea obiectivelor proprii organismului social-economic în concordanţă cu obiectivele generale ale societăţii şi în condiţii de maximă eficienţă.

Sistemul informaţional primeşte intrări, le prelucrează şi furnizează ieşiri. Intrările şi ieşirile unui Sistem informaţional sunt date, informaţii şi decizii.

Ansamblul operaţiilor la care sunt supuse intrările pentru a furniza ieşirile se constituie în proceduri.

În funcţie de mijloacele şi procedeele utilizate pentru executarea operaţiilor, acestea pot fi grupate în proceduri manuale, proceduri automate, proceduri mecanizate sau mixte. În cazul când metodele, procedurile şi mijloacele utilizate pentru colectarea, înregistrarea, prelucrarea, stocarea şi/sau transmiterea datelor şi a informaţiilor sunt cu preponderenţă automatizate, sistemul informaţional devine un sistem informatic.

De remarcat faptul că cele două noţiuni, cea de sistem informaţional şi cea de sistem informatic nu sunt în mod substanţial diferite, din punct de vedere al scopurilor urmărite şi al funcţiunilor îndeplinite, ele fiind identice (ca dovadă, în limbajul de specialitate al altor ţări, pentru cele două noţiuni nu se utilizează termeni diferiţi). Singura diferenţă se reduce la gradul de automatizare a proceselor de prelucrare a datelor şi informaţiilor.

Sistemele informaţionale şi informatice, în plină expansiune de acoperire/acaparare a activităţii umane prezente utilizează şi dezvoltă la rândul lor teoria sistemelor, devenind din ce în ce mai complexe atât din punct de vedere conceptual, dar şi din punct de vedere tehnic (echipamentele de prelucrare automată a datelor având în prezent o dezvoltare explozivă).

Fig. 1.3. Unitatea economică ca sistem cibernetic

Putem privi sistemul informaţional al oricărei societăţi sub 2 aspecte: a) static, în care caz presupune atât înregistrarea evenimentelor survenite în

baza informaţională cât şi înregistrarea structurilor de date, a regulilor şi a restricţiilor în modelul datelor.

10

b) dinamic, în care caz presupune procesarea informaţiilor (aducerea la zi a datelor memorate) în baza de date şi schimbarea structurilor, regulilor şi restricţiilor modelului de date.

În cadrul multora dintre societăţile comerciale confruntate cu concurenţa şi cu apărarea segmentului de piaţă ocupat de acestea, problema unei organizări cât mai bune a sistemului informaţional este una fundamentală, cu implicaţii majore în buna organizare şi funcţionare a activităţii societăţii, în obţinerea de informaţii valoroase, corecte, complete, oportune.

Mai buna organizare a sistemului informaţional ar putea duce, fără îndoială, la eliminarea unor timpi “morţi” din activitatea factorilor responsabili, ar înlătura redundanţa mare existentă în sistem, ar asigura condiţiile necesare obţinerii de profituri mai mari. Şi astfel, sistemul informaţional reprezintă efectiv o componentă de bază a sistemului de management; un sistem informaţional modern, devenit practic un sistem informatic, aduce elemente noi, de fundamentare ştiinţifică a deciziilor, de operativitate şi prelucrare complexă a unor volume mari de date, ce pot fi acum stocate, accesate, interogate şi transmise la distanţă prin noile tehnologii informatice.

Putem reprezenta schematic unitatea economică ca sistem, privită prin prisma funcţiilor sale ca în fig. 1.4.:

1.4. Cele cinci funcţii ale unei întreprinderi

Orice post din cadrul unei societăţi bine organizate se află în unul din aceste compartimente, şi, în acelaşi timp, la unul din nivelele de management ale acesteia.Nivelele Managementului

Se ştie că majoritatea oamenilor care lucreazã într-o societate nu sunt manageri. La baza piramidei organizaţionale se află personalul de execuţie sau operativ, care produce bunurile şi serviciile. La nivelele superioare se află diferite nivele de manageri, specialişti deosebiţi în procesele ce se desfăşoară în subordinea lor, atât ca mod de execuţie, cât şi ca mod de organizare (cum ar fi supraveghetor, şef de echipă, maistru, şef de secţie, director, manager sau preşedinte). Aceştia realizează planificarea, asigură conducerea, organizarea şi verificarea necesarã , putând să intervină direct în executarea unor operaţii din procesele de muncă, pentru a remedia deficienţele. În cadrul întreprinderilor,

11

managementul, aşa cum este văzut în literatura de specialitate, este împãrţit în trei nivele: nivel operaţional (supraveghetori), nivel tactic (mediu) şi nivel strategic (înalt) – fig. 1.5.

Fig .1.5. Cele trei nivele ale managementului

Managerii de nivel operaţional, reprezentaţi de supraveghetori, şefi de echipe, şefi de tură, şefi de colective, etc dau indicaţii şi monitorizeazã angajaţii, personalul de execuţie din subordine, pe aceia care execută efectiv procesele de muncă. Astfel, aceşti manageri au responsabilitatea numitã probleme operaţionale (de fabricaţie). Ei monitorizeazã evenimentele de zi cu zi, informaţiile de detaliu din timpul desfăşurării procesului de muncă şi imediat acţioneazã corespunzãtor, dacã este necesar. De exemplu, la un hotel, şeful de etaj verifică dacă toate camerele sunt curate şi au toate dotările necesare, dacă cele eliberate au fost imediat curăţite, dacă există nemulţumiri ale clienţilor, dacă personalul din subordine îşi respectă sarcinile şi programul de lucru din fişa postului. Dacă se constată abateri sau nereguli, supraveghetorul trebuie sã acţioneze imediat, să rezolve situaţia sau, dacă îl depăşeşte, să comunice mai departe, nivelului ierarhic superior.

Managerii de nivel mediu (tactic) sunt responsabili cu verificarea, planificarea (care mai este numitã planificare tacticã) şi luarea-deciziilor. Ei stabilesc obiectivele pe termen lung ale întreprinderii. De exemplu, managerul local al unui hotel stabileşte politica de cazare şi de contractare pe termen lung a hotelului, în timp ce managerul restaurantului, cunoscând şi datele de cazare, îşi stabileşte propriile măsuri şi oferte de masă, astfel încât să aibă cît mai mulţi clienţi la masă, să obţină deci un profit cât mai mare.

Managerii de nivel înalt (strategic) sunt preocupaţi de planificarea pe termen lung (denumitã şi planificare strategicã). Ei au nevoie de informaţii care îi vor ajuta sã planifice creşterea viitoare şi direcţia de mers a întreprinderii. În condiţiile actuale, când volumul mare de date care circulă nu mai poate fi stăpânit şi prelucrat manual, se impune realizarea unor baze de date şi utilizarea unor

12

programe sau pachete de programe care să ajute sau doar să asiste managerul în luarea unor decizii. Numai prelucrând volume mari de date se pot face estimări ale evoluţiei viitoare a unui fenomen, se pot face previziuni fundamentate ştiinţific şi se pot lua măsuri pentru bunul mers al societăţii în viitor.

1.2. Conceptul de sistem cibernetic

Un sistem cibernetic este un sistem cu autoreglare, deci un sistem care, sesizând diferenţa dintre rezultate şi aşteptări (ieşiri şi obiective), are capacitatea de a acţiona în consecinţă, pentru a elimina acele deficienţe.

Se ştie deasemenea că asupra oricărui sistem acţionează o serie de factori care pot să perturbe desfăşurarea normală a activităţilor din sistemul de referinţă.

La nivelul oricărei societăţi economice managerii (factorii de decizie) caută să intervină în scopul preîntâmpinării sau înlăturării factorilor perturbatori, astfel încât să fie asigurate condiţiile unei bune desfăşurări a activităţilor din cadrul sistemului.

În general, factorii de decizie vor interveni şi vor regla starea sistemului atunci când se constată o neconcordanţă între ieşirile sistemului şi obiectivele stabilite ale sistemului.

Intervenţia managerilor se manifestă printr-un factor de reglare, pe care îl vom nota cu ΔX (fig. 1.6.). Forma de intervenţie poartă denumirea de buclă de reglare (conexiunea inversă sau feed-back). Acţiunea (intervenţia) are loc atâta timp cât există diferenţe între ieşirile obţinute şi obiectivele stabilite.

Ţinînd cont de aceste sarcini ale sistemului de management, atunci când îl vom studia pentru realizarea unui sistem informatic, va trebui să identificăm metodele şi stilul de conducere practicat, informaţiile necesare şi forma exactă de prezentare a acestora, astfel încât prelucrarea automată să-i ofere mai repede, mai corect şi cu gradul de sintetizare necesar acele informaţii de care are nevoie, pentru ca actul decizional să fie oportun şi bine fundamentat.

Fig. 1.6. Un sistem cibernetic

Modul cibernetic de a aborda fenomenele şi procesele economice, de a organiza şi conduce sistemele economice, de a realiza simbioza micro-

13

macroeconomie, reprezintă o realitate evidentă, a cărei valabilitate este confirmată pe deplin de realizările concrete obţinute în practica economică. Aplicarea metodelor ciberneticii economice în rezolvarea problemelor organizării şi conducerii economice, în proiectarea traiectoriilor de creştere economică dorită, în realizarea unui dialog continuu între comandă-decizie şi complementul ei control-reglare, a devenit un element constitutiv al conducerii ştiinţifice.

Direcţia principală de dezvoltare este promovarea metodelor moderne bazate pe mijloace de calcul şi prelucrare electronică a datelor, extinderea cercetărilor de cibernetică economică şi a celor de informatică, de conducere şi de gestiune a întreprinderilor.

1.3. Conceptul de sistem informaţional

Sistemul informaţional reprezintă un ansamblu de metode, tehnici, metodologii şi proceduri de culegere, verificare, transmitere, stocare şi prelucrare a datelor necesare factorilor de conducere în procesul de fundamentare şi elaborare a deciziilor.

În cadrul sistemului informaţional apar o serie de alte concepte dintre care: conceptul de date – reprezintă mesaje, caractere sau simboluri prin

intermediul cărora se descriu fenomenele şi procesele economice sau se cuantifică acestea.

conceptul de informaţie – reprezintă un caz particular al datelor; pentru ca datele să poată fi considerate informaţii acestea trebuie să îndeplinească 3 condiţii:

- să aibă semnificaţie.- să prezinte interes.- să aducă un spor de cunoaştere beneficiarului ei.

conceptul de decizie – reprezintă un caz particular al informaţiei; deosebirea dintre informaţie şi decizie constă în faptul că decizia va avea un caracter imperativ, un rol de directivă pentru cei cărora se adresează şi asupra cărora decidentul are autoritate.

1.3.1. Parametri de eficienţă

În orice activitate organizată de om există o permanentă circulaţie a infor-maţiilor. Fiecare persoană angrenată în execuţia sau dirijarea unei activităţi participă la această circulaţie şi utilizează informaţii pentru lucrările care sunt în sarcina sa. Dacă pentru rezolvarea unei probleme există mai multe soluţii, lucrătorul care prelucrează este nevoit să opteze pentru una din ele. Pentru aceasta însă, el are nevoie de un criteriu de judecată.

În cazul în care o astfel de alegere efectuată pe baza unui proces raţional în vederea realizării unui obiectiv, are implicaţii în activitatea altor persoane, avem de-a face cu o decizie.

14

Pentru ca aplicarea deciziei luate de o persoană să nu fie împiedicată sau chiar anulată de împotrivirea acelora cărora le este destinată, cel ce ia decizia trebuie să fie investit cu autoritatea necesară. Totodată, pentru ca să existe suficientă garanţie că decizia luată este de bună calitate, asigurând realizarea în condiţii optime a obiectivului propus, cel ce o elaborează trebuie să posede competenţa profesională corespunzătoare naturii deciziilor sale.

În sistemul informaţional, deciziile pot constitui la rândul lor informaţii care sunt stocate, prelucrate şi transmise pentru a fi utilizate la luarea altor decizii cu implicaţii la nivelele inferioare, pentru transpunerea lor în practică.

O activitate este reprezentată de o sumă de acţiuni care sunt dependente sau nu între ele, care se influenţează sau nu reciproc şi pentru a căror declanşare este necesară luarea de decizii.

Sistemul informaţional furnizează permanent sistemului decizional informaţii asupra modului de desfăşurare a unei activităţi în diverse sectoare sau locuri de muncă din interiorul sau din exteriorul acesteia.

Sistemul decizional analizează aceste informaţii, le prelucrează şi pe baza lor generează alte decizii. Aceste decizii se transmit sistemului de execuţie tot prin sistemul informaţional şi pot duce fie la declanşarea unei alte acţiuni, fie la modificarea sau stoparea celor ce sunt în plină desfăşurare.

În felul acesta ia naştere un adevarat ciclu informaţie – decizie - acţiune, ce se poate descompune în două părţi principale, ţinând seama de faptul că sistemul informaţional furnizează informaţii şi decizii atât sistemului operaţional cât şi celui decizional.

Parametri de caracterizare a celor două părţi ale ciclului informaţie - decizie - acţiune sunt:

a) timpul de elaborare a informaţiei, adică timpul dintre momentul în care începe colectarea datelor din sistemul operaţional şi momentul transmiterii informaţiilor sistemului decizional şi cuprinde:

. timpul de colectare a datelor şi de control al veridicităţii acestora; . timpul de transmitere a datelor în sistemul informaţional şi de control al

acestora; . timpul de prelucrare şi controlul prelucrării; . timpul de transmitere a datelor sistemului de conducere. b) timpul de reacţie, adică timpul care se scurge între momentul în care

informaţiile prelucrate ajung în sistemul operaţional şi momentul când acesta acţionează, adică declanşează acţiunea la decizia primită.

Organizarea, reorganizarea sau îmbunătăţirea funcţionării unui sistem informaţional trebuie să includă atât analizarea timpilor de elaborare a informaţiilor cât şi timpii de reacţie a Sistemului Decizional şi Sistemului Operativ. Deci nu se poate acţiona asupra unuia din cele 3 sisteme, fără a ţine seama de reacţiile provocate asupra celorlalte două.

15

În analizarea etapelor de elaborare a informaţiilor, trebuie să se ţină seama de următoarele considerente:

- erorile de colectare nu sunt eliminate de folosirea echipamentelor moderne, care pot elimina aproape complet numai erorile de prelucrare;

- colectarea şi transmiterea datelor trebuie să fie precedate şi urmate de controale;

- intervenţia omului va fi totdeauna în ciclul elaborării informaţiilor, probabilitatea apariţiei erorilor putând fi redusă numai printr-o raţională proiectare a sistemului informaţional.

Timpii de reacţie a Sistemului Decizional (S.D) şi Sistemului Operativ (S.O) constituie un factor determinant al eficienţei funcţionării unui sistem informaţional.

1.3.2. Principalele cerinţe ale unui sistem informaţional

La nivelul oricărei societăţi, sistemul informaţional trebuie să satisfacă o serie de cerinţe, care pot fi sintetizate astfel:

a) Să asigure informaţiile necesare şi cu gradul de prelucrare dorit la toate nivelele decizionale.

Relevant în privinţa acestui aspect este principiul piramidei informaţionale, care reprezintă grafic volumul informaţiilor vehiculate la diferite nivele (fig. 1.9).

Nivelul inferior al piramidei deţine o multitudine de informaţii cu un grad înalt de detaliere, ce se difuzează în principal pe orizontală.

Deasupra acestui nivel se găsesc, succesiv, alte nivele de decizie, fiecare din acestea răspunzând pentru realizarea obiectivelor (sarcinilor) de către verigile subordonate.Volumul informaţional se restrânge treptat de la nivelul inferior spre nivelul superior, prin prelucrare şi sintetizare.

b) Operativitatea informării. Informaţiile necesare trebuie furnizate la timp. Realizarea acestei cerinţe necesită stabilirea în prealabil atât a conţinutului şi volumului informaţiilor cât şi a termenelor la care acestea trebuie să fie furnizate.

c) Selectarea informaţiilor. Aceasta cerinţă se referă la necesitatea ca fiecare destinatar să primească numai acele informaţii de care are nevoie în exercitarea atribuţiilor ce îi revin, în sensul de a primi numai informaţii utile, selectarea acestora de informaţiile neutile făcându-se înainte de transmiterea către destinatar.

d) Adaptabilitatea la modificări. Un sistem informaţional trebuie să fie uşor adaptabil la modificările ce pot apare şi care pot fi:

- modificări ale cererilor de informaţie;- modificări ale datelor de intrare;- modificări ale structurii organizatorice;- modificări ale metodelor de prelucrare a datelor.

16

Observaţie:Sistemul informaţional există deci la nivelul oricărei societăţi economice, de

orice tip, încă din momentul înfiinţării ei; se ştie că prin statutul societăţii sunt prevăzute structura organizatorică şi sarcinile, responsabilităţile diferitelor nivele de conducere, iar prin Fişa postului sarcinile individuale.

Sistemul informaţional este, altfel spus, ansamblul elementelor implicate în procesul de colectare, transmisie, prelucrare, sintetizare şi valorificare de informaţii în cadrul oricărei societăţi economico-sociale.

Rolul sistemului informaţional este de a transmite informaţia între diferitele elemente implicate în prelucrare. De exemplu, în cadrul unei unităţi economice, rolul sistemului informaţional este de a asigura persoanele din conducere cu informaţii necesare pentru luarea diferitelor decizii economice sau de altă natură şi de a transmite personalului de execuţie deciziile luate.

El se realizează practic prin cele trei forme de evidenţă existente la nivelul oricărei societăţi, şi anume:

- evidenţa tehnic-operativă- evidenţa contabilă- evidenţa statistică.Evidenţa tehnic-operativă are un caracter operativ, înregistrând fenomenele

economice în momentul şi la locul producerii lor, ceea ce înseamnă că încă se poate interveni în desfăşurarea lor. Astfel, dacă ne referim la o activitate comercială, evidenţa operativă înregistrează pe loc intrările de materiale, ieşirile din magazie şi calculează stocurile curente de materiale sau produse. Dacă ne referim la activitatea de recepţie din cadrul unui hotel, această evidenţă vizează înregistrarea pe loc a cazărilor efectuate, a ieşirilor din hotel cu decontarea serviciilor consumate, astfel încât să existe în orice moment o oglindă a camerelor libere şi ocupate, a încasărilor efectuate şi a tuturor serviciilor consumate.

Evidenţa contabilă nu mai are carater operativ, ci unul istoric, deoarece înregistrează fenomenele economice după ce ele s-au desfăşurat, deci fără a mai putea interveni în desfăşurarea lor. Ea este însă necesară şi obligatorie, căci prelucrând datele referitoare la intrările şi ieşirile din societate, de orice fel (materii şi materiale, resurse umane sau financiare, etc) se obţine oglinda reală a resurselor de care dispune societatea pentru a începe o nouă perioadă (ciclu) de viaţă (o nouă lună). Evidenţa contabilă este reglementată prin acte normative (legea contabilităţii), prin norme metodologice de aplicare a legii, deci este, în mare parte, similară, pentru aceleaşi categorii de societăţi (cu activităţi asemănătoare). Totuşi, asupra activităţii contabile îşi pune amprenta şi experienţa contabilului şef (sau director economic), personalitatea şi stilul de conducere al acestuia.

Evidenţa statistică, cu un caracter pronunţat istoric, serveşte pentru realizarea, pe baza unor volume mari de date privind perioadele anterioare, a unor prognoze,

17

estimări, previziuni cu privire la evoluţia viitoare a fenomenelor. Aceasta presupune însă existenţa unor baze de date şi programe care să le prelucreze în mod automat, deci existenţa calculatorului în cadrul sistemului informaţional.

Pe de altă parte, sistemul informaţional cuprinde, legat de circulaţia informaţiilor pe documente, următoarele elemente de structură:

- fluxuri informaţionale- circuite informaţionaleFluxul informaţional este ansamblul datelor, informaţiilor şi deciziilor

necesare desfăşurării unei anumite operaţii, acţiuni sau activităţi. Fluxul informaţional este caracterizat prin conţinut, volum, frecvenţă, calitate, formă, suport, proces de obţinere şi cost.

Fluxurile informaţionale sunt vehiculate pe trasee prestabilite, denumite circuite informaţionale.

Circuitul informaţional reprezintă multitudinea compartimentelor organizatorice prin care circulă documentele primare sau mesajele de la sursă până la destinaţia finală.

Fluxul informaţional reprezintă deci cantitatea de informaţii (volumul de date) care se vehiculează în cadrul circuitului informaţional; prin analogie, circuitul informaţional poate fi asociat cu sistemul de conducte, iar fluxul informaţional cu debitul apei ce circulă prin conducte.

Identificarea fluxului informaţional şi a caracteristicilor calitative şi cantitative ale acestora constituie o activitate importantă pentru stabilirea cerinţelor informaţionale şi realizarea sistemului informatic. Deasemenea raţionalizarea circuitelor informaţionale în vederea eliminării redundanţei datelor şi a asigurării unicităţii intrării lor în sistem sunt cerinţe prioritare ale activităţii de reproiectare sau raţionalizare a unui sistem informaţional.

1.4. Conceptul de sistem informatic1.4.1. Prezentare generală

În cadrul sistemului informaţional se regăsesc: informaţia vehiculată, documentele purtătoare de informaţii, personalul, mijloace de comunicare, sisteme de prelucrare a informaţiei, etc. Printre posibilele activităţi desfăşurate în cadrul acestui sistem, pot fi enumerate: achiziţionarea de informaţii din sistemul de bază, completarea documentelor şi transferul acestora între diferite compartimente, centralizarea datelor, etc.

J.C. Emery, vorbind despre sistemul informaţional, identifică în cadrul acestuia componente ce execută funcţii bine stabilite: recunoaşterea, transmiterea, stocarea, compararea şi distribuirea informaţiei.

18

H.C. Lucas arată că sistemul informaţional se referă la totalitatea procedurilor organizate, astfel încât să permită furnizarea de informaţii necesare luării deciziilor şi/sau controlului organizaţiei.

În cadrul sistemului informaţional, majoritatea activităţilor se pot desfăşura acum cu ajutorul tehnicii de calcul. Se pot prelucra datele primare şi apoi, rezultatul poate fi transferat mai departe, către alt compartiment spre prelucrare. Transferul se poate face şi el pe cale electronică, prin intermediul unei reţele de calculatoare sau cu ajutorul modemului.

Ansamblul de elemente implicate în tot acest proces de prelucrare şi transmitere a datelor pe cale electronică alcătuiesc un sistem informatic. Acesta poate fi astfel definit ca un ansamblu de principii, concepte, reguli şi tehnici folosite pentru culegerea, înregistrarea şi transmiterea datelor în vederea prelucrării automate, pentru a obţine informaţii care stau la baza luării deciziilor

Sistemul informatic reprezintă deci un ansamblu de metode, metodologii, tehnici şi proceduri automate de culegere, verificare, transmitere, stocare şi prelucrare a datelor în scopul satisfacerii cerinţelor informaţionale necesare conducerii în procesul de fundamentare şi elaborare a deciziilor.

Comparând definiţia sistemului informaţional cu definiţia sistemului informatic se poate deduce faptul că sistemul informatic reprezintă partea automatizată a sistemului informaţional.

Trecerea la prelucrarea automată a informaţiilor, deci transformarea unui sistem informaţional într-unul informatic este o problemă tehnică de înaltă specialitate, laborioasă, ce necesită o perioadă relativ mare de timp de realizare.

Experienţa naţională şi internaţională arată că pentru a rezolva cu succes şi optim această trecere e necesară parcurgerea unor etape bine definite.

S-au elaborat mai multe metodologii şi tehnici de investigare, de proiectare şi realizare practică a unui sistem informatic, care stabilesc etapele şi documentaţia necesară pentru finalizarea unei lucrări de acest gen.

Nu trebuie neglijat faptul că sistemul informatic, ca parte componentă a sistemului informaţional, trebuie să satisfacă toate cerinţele unui sistem informaţional şi chiar să ducă la raţionalizarea, la simplificarea acestuia prin automatizarea unor proceduri manuale, să conducă la o creştere a calităţii informării, a complexităţii şi operativităţii ei.

Prin realizarea unui sistem informatic sau produs-program se înţelege acea parte a ciclului său de viaţă care constă din: elaborarea proiectului, a programelor asociate, a documentaţiei de utilizare, exploatare şi întreţinere, punerea în funcţiune la cel puţin o unitate beneficiară până la recepţionarea sau omologarea sa.

19

Fig. 1.7. Sistemul informaţional şi informatic

În ceea ce priveşte sfera de cuprindere a sistemului informatic se poate spune că aceasta tinde să egaleze sfera de cuprindere a sistemului informaţional, însă egalarea nu se va realiza niciodată. Există şi vor exista o serie de activităţi sau proceduri care nu pot fi automatizate integral - de exemplu controlul formal efectuat de C.F.I. (controlul financiar intern), etc.

Observaţie : În unele ţări se face distincţie între cei doi termeni: sistem informaţional şi sistem informatic, dar în altele nu se mai face nici o distincţie. În prezent orice sistem informaţional tinde să devină sistem informatic, iar sistemul informatic tinde să cuprindă o parte din ce în ce mai mare din sistemul informaţional.

Prezenţa sistemului informatic în cadrul sistemului informaţional imprimă acestuia o serie de valenţe sporite de ordin cantitativ şi calitativ. Un sistem informaţional modern nu poate fi conceput fără o parte semnificativă de culegere, transmitere şi prelucrare automată a datelor, folosind noile tehnologii informatice, deci fără un sistem informatic.

Elementele componente ale sistemului informatic sunt:a). Baza tehnico-materială a sistemuluiInclude multitudinea echipamentelor de culegere, verificare, transmitere,

stocare şi prelucrare a datelor. În cadrul acestora rolul hotărâtor îl deţine calculatorul electronic şi/sau reţeaua de calculatoare. Mai pot fi incluse liniile de comunicaţii pentru sistemele informatice concepute în regim de teleprelucrare precum şi echipamentele corespunzătoare transmisiei datelor, purtătorii tehnici de informaţii (discuri magnetice, diskete, Cd-uri etc.).

b). Sistemul de programe ( software-ul sistemului)Include sistemele de operare, S.G.B.D.-urile şi programele de aplicaţii ale

utilizatorilor.

20

c). Baza informaţionalăInclude multitudinea datelor stocate ce urmează a fi prelucrate.În cadrul sistemelor informatice baza informaţională este organizată sub formă

de fişiere sau baze de date.d). Aparatul ştiinţific şi matematicInclude multitudinea metodelor, metodologiilor şi tehnicilor utilizate în

activităţile de realizare a sistemelor informatice, precum şi multitudinea modelelor matematice implementate în cadrul acestora.

e). Factorul uman şi cadrul organizatoricFactorul uman include categoriile de personal specializate în domeniul

informaticii (analişti, programatori, operatori, ingineri de sistem, administratori de baze de date şi/sau de reţele). Cadrul organizatoric defineşte acele structuri organizatorice capabile să asigure buna desfăşurare a activităţii de informatică la nivelul unităţilor economice.

În prezent asistăm la o pronunţată descentralizare a activităţii de informatică, însă la nivelul unei unităţi economice pot exista structuri organizatorice de forma : oficii de calcul (staţii de calcul) şi departamente de informatică.

1.4.2. Clasificarea sistemelor informatice

Sistemele informatice se pot clasifica după mai multe criterii, astfel:A. În funcţie de domeniul de aplicabilitate1. sisteme informatice pentru conducerea activităţilor unităţilor

economico-sociale2. sisteme informatice pentru conducerea proceselor tehnologice3. sisteme informatice pentru activităţile de cercetare-proiectare4. sisteme informatice speciale

Sistemele informatice pentru conducerea activităţilor unităţilor economico-sociale au ca specific faptul că intrările sistemului sunt reprezentate în general de date, culese de pe documente primare elaborate de factorul uman, iar ieşirile se concretizează în date prelucrate, reprezentate sub formă de situaţii de informare-raportare destinate tot factorului uman. Ele servesc pentru prelucrarea automată a datelor din diverse domenii de activitate, mai rapidă, mai corectă, cu posibilităţi de prelucrare, verificare, sintetizare mult sporite prin utilizarea calculatorului electronic.

Sistemele informatice pentru conducerea proceselor tehnolgice au ca specific faptul că intrările reprezintă mărimi fizice sub formă de impulsuri (temperatură, presiune, umiditate) preluate de la instalaţii, maşini, agregate direct din procesul tehnologic în timpul desfăşurării lui şi care apoi, prelucrate, au drept ieşiri tot impulsuri care declanşează anumite dispozitive prin care se reglează automat procesele tehnologice (temperatura, umiditatea, presiunea, etc). Această categorie

21

de sisteme informatice o regăsim în locurile unde este pereclitată intervenţia factorului uman. Obiectivul unor astfel de sisteme constă în sporirea randamentului maşinilor, instalaţiilor şi agregatelor, dar şi în creşterea considerabilă a calităţii produselor fabricate. De exemplu, în centralele nucleare, în petrochimie, în industria farmaceutică, dar şi în industria alimentară (fabricarea berii, a drojdiei de bere, etc).

Sistemele informatice pentru activităţile de cercetare-proiectare sunt destinate spre a uşura documentarea ştiinţifică, elaborarea proiectelor, efectuarea calculelor ştiinţifice, elaborarea studiului tehnico-economic.

Ele sunt destinate să fie utilizate de către cercetătorii şi personalul care lucrează în acest domeniu. Aceste categorii de personal folosesc pe lângă sistemele informatice existente şi sisteme specializate, numite sisteme bazate pe cunoştinţe pentru a crea informaţii în sectorul lor. De exemplu, inginerii implicaţi în proiectarea produsului şi producerea lui folosesc sisteme informatice în proiectare,sisteme informatice în proiectare, sisteme informatice în procesul de fabricaţiesisteme informatice în procesul de fabricaţie. Aceste sisteme utilizează calculatoare foarte performante, care rulează programe speciale care integrează informaţia necesară activităţii de proiectare cu informaţia provenită din activităţile de fabricaţie. Sistemele computerizate care ajută în proiectarea şi fabricarea produsului sunt larg utilizate în producţia de automobile şi a altor produse.

Sistemele informatice speciale se referă la sistemele din domeniul evidenţei populaţiei, poliţie, S.R.I.

B. În funcţie de specificul domeniului abordat, sistemele informatice pot fi grupate astfel:

1. Sisteme informatice pentru conducerea activităţii comerciale (aprovizionare-desfacere). În cadrul acestora putem identifica o serie de aplicaţii de prelucrare automată a datelor, cum sunt:

- Gestiunea stocurilor de materii prime, materiale, servicii şi utilităţi;- Gestiunea stocurilor de produse finite, semifabricate şi mijloace fixe;- Controlul automat al gradului de lichidare a creanţelor şi a stadiului plăţii

furnizorilor;- Cunoaşterea influenţei unor pîrghii de marketing asupra stabilităţii, pe piaţă,

a societăţii comerciale.- Urmărirea modului de derulare a contractelor încheiate cu partenerii

societăţii şi evidenţierea cantităţilor restante sau livrate în avans acestora.

2. Sisteme informatice pentru conducerea activităţii de producţie.În această categorie sunt incluse o serie de aplicaţii informatice care vizează

următoarele activităţi :- lansarea în fabricaţie;- programarea producţiei;- întreţinerea şi funcţionarea utilajelor;

22

- calculul necesarului de combustibil şi de energie electrică destinată necesităţilor tehnologice.

Dintre aplicaţiile informatice care pot fi realizate în acest domeniu se pot menţiona :

Cele care vizează structura de producţie a societăţii comerciale, în cadrul lor putând fi dezvoltate module informatice care urmăresc:

- amplasarea optimă a utilajelor în cadrul secţiilor de producţie;- utilizarea raţională a capacităţilor de producţie prin corelarea cererii pieţei

cu dimensiunea optimă a nomenclatorului de fabricaţie;- determinarea automată a susccesiunilor optime între fazele procesului de

producţie. Aplicaţiile informatice din acest modul urmăresc optimizarea proceselor economice prin intermediul unui aparat economico-matematic adeseori foarte complex.

Aplicaţii informatice pentru activităţile de programare, lansare şi urmărire a producţiei care conţin modulele :

- determinarea momentelor optime de lansare în fabricaţie a loturilor de produse, urmărind încadrarea societăţii în obligaţiile contractuale asumate faţă de clienţii săi;

- stabilirea loturilor optime ce urmează a fi lansate la un moment dat în fabricaţie.

Aplicaţiile din această categorie sunt uzuale atunci când lansările în fabricaţie se fac pe bază de comenzi şi sunt caracteristice îndeosebi societăţilor în care producţia este de serie mică şi unicate.

- urmărirea automată a modului de derulare a procesului de producţie pe toată durata fabricării cantităţilor dintr-un anumit lot. Pe plan mondial există preocupări de extindere a acestor aplicaţii la prelucrări automate ale datelor care urmăresc simularea desfăşurarii diverselor activităţi economice în timp.

3. Sisteme informatice privind forţa de muncă (personalul), cuprind aplicaţii de tipul:

- Evidenţa personalului;- Calculul salariilor;- Fişe fiscale, etc..4. Sisteme informatice pentru conducerea activităţii financiar-contabile, care

pot cuprinde aplicaţii informatice specifice activităţilor de evidenţă financiar–contabilă, cum sunt:

- Elaborarea şi evidenţa automată a notelor contabile, soldurilor de materii prime şi produse finite şi a balanţei de verificare analitică şi sintetică. Trebuie subliniat faptul că această categorie de aplicaţii informatice ar trebui completată cu o serie de proceduri automate care să asigure analiza asistată de calculator a datelor din bilanţurile contabile.

23

- Evidenţa automată a plăţii şi încasării facturilor, urmărind evidenţierea şi reflectarea în costuri a tuturor categoriilor de plăţi efectuate de societate sau către societate. Este o categorie de aplicaţii foarte solicitate în prezent, deoarece societăţile înregistrează în urma blocajului financiar creanţe care influenţează negativ bugetul de venituri şi cheltuieli al acestora. În plus, achitarea între societăţi poate fi făcută şi în regim de compensare, activitate imposibil de evidenţiat într-un sistem manual de prelucrare a datelor.

- Dezvoltarea unor aplicaţii informatice care să asigure suportul logistic în procesul de negociere a preţurilor. Aceste aplicaţii urmăresc crearea unor instrumente decizionale care să permită societăţilor comerciale perfectarea unor contracte prin negocieri în condiţiile păstrării profitului antecalculat într-o anumită plajă de valori dorită. Esenţa acestor aplicaţii informatice constă în elaborarea automată a unor costuri de producţie antecalculate prin variaţii acceptabile ale elementelor care intră în structura costurilor (articole de calculaţie sau elemente primare). Prin aceste costuri de producţie antecalculate fundamentate pe o anumită tehnologie de fabricaţie a produselor, societatea comercială are posibilitatea să cunoască aprioric în ce interval poate varia preţul de vânzare cu amănuntul, astfel încât profitul total să ramână cel dorit.

- Elaborarea automată a jurnalelor de operaţii contabile. Aceste operaţii se doresc a fi un suport în procesul de analiză economică, deoarece evidenţiază variaţiile valorilor intrate în debitele şi creditele conturilor, precum şi influenţa lor asupra soldurilor finale.

- Elaborarea activităţilor de postcalcul asistate de calculator, concomitent cu evidenţierea cheltuielilor de producţie efective şi compararea acestora cu nivelele planificate. În societăţile comerciale există deja implementate o serie de produse software care permit evidenţierea acestor abateri şi defalcarea lor pe cauze obiective şi subiective. Această categorie de aplicaţii a permis implementarea în cadrul societăţilor comerciale a metodei de conducere de tip tablou de bord asistat de calculator.

- Aplicaţii informatice integrate, care asigură intercorelarea activităţilor financiar-contabile cu cele de producţie şi cu activităţile comerciale. Necesitatea existenţei acestora este dată de faptul că esenţa activităţii economice din orice societate comercială este definită prin tripletul: cerere, producţie, resurse, care implică activităţi din funcţiunea financiar contabilă, de producţe şi comercială. Toate aplicaţiile informatice complexe enumerate mai sus trebuie precedate de un ansamblu de aplicaţii mai simple care urmăresc gestiunea contabilă a mijloacelor fixe, obiectelor de inventar, pieselor de schimb, materiilor prime şi materialelor, produselor finite etc., precum şi de o serie de produse informatice care asigură calculul automat al salariilor.

5. Sisteme informatice de birou sunt proiectate, în primul rând, să ajute personalul care lucrează cu datele din sistemul obiect (angajaţii care se ocupă cu culegerea, stocarea, prelucrarea şi difuzarea datelor). Aceste sisteme se bazează în

24

principal pe procesarea documentelor, pe comunicaţii şi pe stabilirea planului de muncă. Documentele sunt procesate utilizând un procesor de texte, programe de calcul tabelar, tehnologii de preluare a imaginilor, etc. Comunicaţiile se realizează prin e-mail, mesagerie vocală şi video-conferinţă.

Aceste sisteme informatice au atribuţii pe linia prelucrării şi comunicării informaţiei în cadrul compartimentelor firmei şi între firmă şi mediul extern. Principalii utilizatori sunt personalul din activităţile de secretariat, managerii etc. Un produs software reprezentativ pentru această clasă de sisteme informatice este produsul integrat MS OFFICE (cu componentele WORD, EXCEL, POWER POINT, ACCESS şi altele care asigură servicii INTERNET).

C. În funcţie de poziţia ierarhică pe care se situează în cadrul societăţii :1. sisteme informatice la nivelul unităţilor economico-sociale

(microeconomic) ;2. sisteme informatice la nivelul unităţilor economice cu structură de grup

(regii autonome) ;3. sisteme informatice la nivel teritorial (direcţii judeţene sanitare, comisii

judeţene de statistică) ;4. sisteme informatice generale (ministere, comisia generală de statistică).

D. În funcţie de rolul său în procesul decizional din cadrul societăţii, sistemul informatic poate fi:

Sistem de prelucrare a tranzacţiilor (SPT), care înregistreazã operaţiunile (tranzacţiile) curente din cadrul societăţii, le validează şi le memorează în baze de date pentru a servi ulterior prelucrărilor de nivel înalt.

Aşa sunt comenzile clienţilor, facturile emise sau primite, nivelul stocurilor (consumul de materii prime) şi ieşirile de produse din fabricaţie, încasările prin casă sau bancă, intrările sau ieşirile de materii prime, materiale sau produse, consumurile de energie, combustibil, etc.

Sistem Informatic de Management (SIM), care prelucrează şi sintetizează datele detaliate ale sistemului de prelucrare a tranzacţiilor în rapoarte standard necesare managerilor de nivel mediu. Astfel de rapoarte ar putea conţine planul de producţie sau prestări servicii, gama sortimentală a acestuia, cantităţile şi termenele de execuţie, bugetul de venituri şi cheltuieli, stadiul îndeplinirii contractelor şi valoarea acestora, etc..

Sistem Suport de Decizie (SSD) oferã, prin natura datelor prelucrate, instrumente corespunzătoare pentru analizã. Acest sistem serveşte managerilor de nivel mediu în analize economico-financiare, în analiza diferitelor probleme din cadrul societăţii, cum ar fi evenimente întâmplătoare sau de excepţie apărute fie ca urmare a unor factori interni, fie legate de influenţa unor factori externi. Ca şi

25

Sistemul Informatic de Management, Sistemul suport de Decizie se bazeazã în cea mai mare parte, pe datele detaliate ale sistemului de prelucrare a tranzacţiilor.

Sistem Suport al Executivului (SSE), cunoscut şi sub numele de Sistemul Informatic al Executivului, prezintã informaţiile în formulare prestabilite. El ajutã managerii de nivel înalt sã supravegheze acţiunile întreprinderii şi sã creeze sau să dezvolte proiecte strategice. Sistemul Suport al Executivului combinã datele interne de la Sistemul de Prelucrare a Tranzacţiilor şi Sistemul Informatic de Management cu datele externe, cum ar fi cele ale factorilor de mediu, de conjunctură a pieţei, de legislaţie sau de contracte din afara societăţii.

O extensie a Sistemelor Suport de Decizii o constituie sistemele Expert. Un sistem expert este un sistem informatic care colectează cunoştinţe şi expertize în rezolvarea problemelor şi luarea deciziilor şi simulează gândirea unui expert care are experienţă în domeniu. Sistemele expert imită logica şi motivaţia unor experţi în domeniul respectiv cum ar fi de exemplu utilizarea unui sistem expert la un producător de mase plastice pentru a determina cauzele care produc probleme în zona controlului de calitate asociate cu fluxurile de fabricaţie.

1.4.3. Obiectivele sistemelor informatice

Obiectivele sistemelor informatice sunt subordonate obiectivelor conducerii activităţilor unităţilor economice, întrucât sistemul informatic se defineşte ca un instrument care deserveşte factorii de conducere în procesul de fundamentare şi elaborare a deciziilor.

Clasificarea obiectivelor sistemelor informaticeObiectivele unui sistem informatic, ca parte componentă a sistemului

informaţional, sunt practic subordonate obiectivelor sistemului informaţional din domeniul abordat. De aceea, aceste obiective pot fi grupate astfel:

A. În funcţie de sfera de cuprindere:1. obiective generale/principale2. obiective secundareObiectivele principale se exprimă prin indicatori sintetici ce caracterizează

activităţile din domeniul de referinţă.De exemplu sistemul informatic poate avea ca obiective generale:- creşterea vitezei de rotaţie a mijloacelor circulante- creşterea rentabilităţii activităţii unităţii economice- creşterea profitului- creşterea prestigiului unităţii economice

26

Obiectivele secundare mai poartă denumirea de condiţii de realizare a obiectivelor principale. Acestea trebuie să fie compatibile între ele şi compatibile cu obiectivele generale în ideea de a acţiona în acelaşi sens.

De exemplu, sistemul informatic poate avea ca obiective secundare :- sporirea gradului de încărcare a capacităţilor de producţie- utilizarea raţională a forţei de muncă- aplicarea şi transpunerea pe calculator a principiului selecţiei şi informării

prin excepţie- reducerea cheltuielilor de aprovizionare cu materii prime şi materiale prin

implementarea unor modele matematice privind optimizarea rutelor şi capacităţilor de transport.

B. În funcţie de subsistemul de activităţi la care se referă:1. obiective referitoare la conducerea activităţii de comercializare

(aprovizionare-desfacere)2. obiective referitoare la conducerea activităţii de producţie3. obiective referitoare la forţa de muncă4. obiective referitoare la conducerea activităţii financiar-contabile5. obiective referitoare la conducerea activităţii cercetare-dezvoltare etc.Astfel, un sistem informatic va cuprinde activităţile desfăşurate în cadrul unui

subsistem (definit de principalele funcţii ale societăţii), şi se va constitui astfel ca un subsistem al sistemului informatic al întregii societăţi. Aceasta înseamnă că, practic, fiecărei funcţii a unei societăţi, indiferent de specificul ei, îi poate corespunde un subsistem informatic.

Vom putea vorbi astfel, la nivelul oricărei societăţi, de un subsistem informatic pentru:

- activitatea de producţie sau prestări servicii;- activitatea de personal – retribuire;- activitatea financiar-contabilă;- activitatea de cercetare-dezvoltare;- activitatea de marketing;- activitatea de aprovizionare-desfacere (comercială).

C. În funcţie de sistemul şi activitatea de referinţă:- obiective referitoare la activitatea de bază (sistemul condus)- obiective referitoare la sistemul informaţional

D. În funcţie de posibilitatea de cuantificare a efectelor economice dobândite:

- obiective calitative (necuantificabile)- obiective cantitative (cuantificabile)

27

Efectele economice ale obiectivelor de ordin calitativ se estimează în mod indirect. De foarte multe ori efectele economice ale obiectivelor de ordin calitativ depăşesc cu mult efectele economice ale obiectivelor de ordin cantitativ.

Necesitatea clasificării obiectivelor sistemelor informatice şi identificarea acestora provine din faptul că resursele umane, materiale, financiare disponibile la nivelul unei societăţi comerciale sunt limitate. De aceea se impune identificarea obiectivelor şi abordarea realizării acestora într-o ordine prioritară prestabilită.

1.4.4. Principii de realizare a sistemelor informatice

Realizarea sistemelor informatice presupune o activitate laborioasă, care cuprinde mai multe etape, consumatoare de timp, de resurse umane şi financiare uneori deosebit de mari. De aceea, la baza realizării unui sistem informatic trebuie să stea o serie de principii, dintre care mai importante sunt:

1. Principiul eficienţei economiceAcesta presupune recuperarea cheltuielilor de realizare şi întreţinere a

sistemului informatic din economiile obţinute ca urmare a implementării şi punerii lui în funcţiune. Termenul de recuperare a cheltuielilor este de dorit să fie de maxim 4-5 ani, ţinând seama de dinamismul prin care se caracterizează domeniul informaticii, precum şi posibilitatea unor schimbări majore în activitatea unor unităţi economice.

2. Principiul structurării sistemului informaticAcesta presupune structurarea sistemului informatic în subsisteme, module,

aplicaţii, abordate iniţial independent şi integrate apoi într-un sistem unitar.Necesitatea structurării sistemului informatic provine din cel puţin două

considerente de ordin practic: complexitatea sistemului informatic resursele umane, materiale, financiare disponibile la nivelul unităţii

beneficiare sunt limitate.Ţinând seama de cele două considerente, ca urmare a structurării sistemului

informatic se va putea trece la realizarea acestuia într-o ordine prioritară prestabilită, ţinând seama de resursele disponibile.

De exemplu, două activităţi deosebit de importante ale unei societăţi, indiferent de specificul ei, pot fi: activitatea comercială şi cea de producţie. În mod corespunzător, cele două subsisteme aferente, vor putea fi împărţite, la rândul lor ca în fig. 1.8.

28

Fig. 1.8. Structurarea subsistemelor

În cadrul fiecărui subsistem am identificat astfel aplicaţiile de prelucrare automată a datelor corespunzătoare.

3. Principiul unicităţii datelor de intrareAcest principiu presupune preluarea datelor din documentele primare o singură

dată, chiar dacă acestea circulă prin mai multe compartimente. Acest lucru crează premize pentru un control riguros al datelor, pentru asigurarea exactităţii lor, precum şi pentru răspunderea celui care le furnizează, le introduce şi le prelucrează.

4. Principiul selecţiei şi informării prin excepţieAcesta presupune stabilirea indicatorilor necesari şi suficienţi pe fiecare nivel

ierarhic de conducere. Factorii de conducere vor fi informaţi cu acei indicatori necesari, numai atunci când se constată abateri de la starea normală.

Ca urmare a aplicării acestui principiu se ajunge la definirea piramidei informaţionale în cadrul unităţii beneficiare, care reprezintă cantitatea de informaţii vehiculată în cadrul sistemului informaţional (fig. 1.9).

Fig. 1.9. Piramida informaţională

Aceasta înseamnă că volumul informaţiilor se restrânge tot mai mult către nivelul ierarhic superior, nu prin selecţia informaţiilor transmise, ci prin sintetizarea lor, prin prelucrări superioare, care conduc către indicatori sintetici ce caracterizează corect activităţile desfăşurate la nivelul sistemelor de execuţie.

29

Fiecare nivel de management are cereri diferite de informaţii. Managerii de nivel înalt au nevoie de informaţii sintetice, cu grad ridicat de prelucrare, scrise în formulare pentru a arãta starea generalã globalã a afacerii. Deasemenea, ei au nevoie de o serie de informaţii dinafara societăţii, deoarece managerii de nivel înalt trebuie sã prevadã şi sã planifice evenimentele pe termen lung. Managerii de nivel mediu au nevoie de informaţii scurte şi precise – rapoarte săptămânale sau lunare. Ei trebuie sã realizeze o alocare a bugetului, precum şi o evaluare a performanţei, a profesionalismului şefilor subordonaţi.

Supraveghetorii, şefii de la nivelul operativ, au nevoie zi de zi de informaţii detaliate şi foarte recente din cadrul societăţii, pentru a putea menţine un flux constant al operaţiunilor de fabricare.

5. Implementarea unor modele matematice în cadrul sistemelor informaticeAcest principiu impune necesitatea documentării aprofundate a subsistemului

abordat în vederea identificării corecte a algoritmilor de prelucrare, a modelelor matematice ce urmează a fi implementate pentru prelucrarea automată în domeniul respectiv. Astfel de modele matematice pot fi realizate de echipa de proiectare sau pot fi preluate şi implementate modele existente în teoria matematică, cum sunt:

a. modele de programare liniară (algoritmul Simplex)Se pot aplica cu succes pentru rezolvarea problemelor de optimizare a

transporturilor în vederea stabilirii rutelor corespunzătoare, optimizarea costurilor, a producţiei şi, în general pentru probleme de determinare a unui optim.

b. modele de programare neliniară, utilizate în probleme de determinare a minimului unei funcţii reale, cu sau fără restricţii.

c. modele de programare dinamică (lanţurile Markov), utilizate în probleme de programare dinamică a producţiei sau de stabilire a planului de revizie şi reparaţie a utilajelor sau parcului de maşini.

d. modele de simulare, care cuprind o serie de modele statistice cu aplicabilitate în diverse domenii ale activităţilor din cadrul unei societăţi comerciale. Aceste modele servesc fie pentru simulări ale fenomenelor în viitor, pe baza datelor stocate în perioade anterioare, fie pentru a studia valoarea unor parametri şi a stabili valori dorite ale unor indicatori, prin mecanismul numit ‘jocuri de întreprindere‘.

e. modele de teoria grafurilor, care fac apel la algoritmii cunoscuţi din teoria grafurilor, cum sunt algoritmul Foulkes, algoritmul Ford-Fulkerson, algoritmul Ford, etc. utilizaţi în rezolvarea unor probleme pentru determinarea fluxului maxim într-un graf fără circuite.

f. modele de gestiune a stocurilor utilizate pentru determinarea stocurilor optime de produse şi/sau de materii şi materiale în vederea optimizării activităţilor de aprovizionare, de desfacere şi prin aceasta şi a celei de producţie.

30

g. modele de teoria deciziilor, utilizate pentru fundamentarea deciziilor multidimensionale, a deciziilor în condiţii de risc şi incertitudine şi rezolvarea acelor probleme care au mai multe funcţii obiectiv.

h. modele de aşteptare, utilizate pentru rezolvarea acelor probleme care vizează minimizarea timpului de aşteptare.

i. modele de tip PERT, folosite în rezolvarea problemelor de optimizare cost-durată, deci de optimizare a perioadei de execuţie a unei lucrări şi de utilizare optimă a resurselor disponibile.

6. Adoptarea unor soluţii performante de organizare şi prelucrare a datelorAceastă cerinţă ţine de calificarea echipei de realizare a sistemului informatic,

de experienţa sa în domeniu, de condiţiile contractuale stabilite, de modul de colaborare cu beneficiarul şi de implicare a acestuia în diferite etape (deci de o serie de factori obiectivi şi subiectivi).

Pe parcursul proiectării şi realizării sistemului informatic beneficiarul va putea lua cunoştinţă de toate acestea şi-şi va putea exprima opţiunea cu ocazia avizărilor intermediare, prevăzute de regulă în contract. Toate sunt însă posibile numai dacă beneficiarul se implică şi colaborează efectiv cu echipa de proiectare pe toată durata de execuţie a sistemului.

7. Respectarea cadrului legislativAceasta înseamnă că echipa de proiectare are datoria de a studia cadrul

legislativ care reglementează problematica abordată şi de a-l respecta întocmai, răspunzând în mod direct de legalitatea modului de abordare şi rezolvare a problemei respective.

Observaţie:Tendinţa actuală este de a proiecta şi realiza sisteme informatice integrate,

caracterizate prin faptul că asigură introducerea unică a datelor pornind de la documentele primare şi apoi prelucrarea complexă a acestora, pentru a răspunde tuturor cerinţelor de informare ale utilizatorilor (la toate nivelele de management)

31

1.5. Întrebări recapitulative

1. Definiţi conceptul de sistem şi sistem cibernetic.2. Este o societate economică un sistem? Argumentaţi răspunsul.3. Definiţi conceptele de Sistem informaţional, Sistem informatic şi

prezentaţi relaţia dintre ele.4. Definiţi conceptele de dată, informaţie, decizie şi relaţia dintre ele.5. Precizaţi obiectivele unui sistem informaţional (informatic).6. Specificaţi cerinţele unui Sistem informatic.7. Prezentaţi elementele componente ale unui sistem informatic.8. Tipuri de sisteme informatice. Exemplificaţi.9. Cum explicaţi definirea sistemului informatic ca o componentă a

sistemului de management?10. Ce înseamnă modernizarea unui sistem informaţional şi ce implică ea?11. Care sunt nivelele de management într-o societate economică şi atribuţiile

acestora?12. Ce subsisteme informatice pot fi realizate la nivelul unei firme, oricare ar

fi specificul ei de activitate?13. Ce aplicaţii de prelucrare automată a datelor puteţi realiza pentru

activitatea comercială?14. Ce aplicaţii de prelucrare automată a datelor s-ar putea realiza pentru

activitatea de marketing?15. Ce aplicaţii de prelucrare automată a datelor consideraţi că ar putea fi

realizate pentru activităţile desfăşurate într-o bancă?16. Ce aplicaţii de prelucrare automată a datelor s-ar putea realiza pentru o

societate de asigurări?17. Ce aplicaţii de prelucrare automată a datelor s-ar putea realiza pentru o

firmă de consultanţă şi realizare software?18. Ce aplicaţii de prelucrare automată a datelor ar necesita un depozit de

marfă?19. Cum se poate estima eficienţa unui sistem informatic?

32

2. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE

2.1. Scurt istoric

În ultima perioadă am asistat la o dezvoltare explozivă în lumea calculatoarelor. Acum câţiva ani, echipe alcătuite din doi / trei analişti-programatori reuşeau să proiecteze şi să programeze cu succes diferite aplicaţii pentru calculatoare. Cu timpul, mărimea şi complexitatea proiectelor software a crescut, odată cu volumul de date manipulate şi cu cerinţele de securitate şi access la acestea, ajungându-se în prezent la proiecte de mii de linii de cod program sursă. Acest lucru a determinat necesitatea unei mai bune organizări şi planificări a procesului de proiectare, realizare şi dezvoltare de software. Nu întâmplător, firme şi organizaţii puternice pe piaţa de sofware precum Microsoft sau OMG (Object Management Group) au început să investească tot mai mult în activităţi legate de metodologiile de analiză şi proiectare de software. Pe de altă parte, componenţa echipelor de proiectare s-a schimbat, reunind acum analişti, programatori, ingineri de sistem şi administratori de reţea, având un şef de proiect care poate utiliza cu succes produsul Microsoft Project pentru planificarea şi împărţirea diferitelor sarcini în cadrul echipei.

Metodologiile de proiectare au apărut ca o necesitate de definire a unor paşi şi reguli generale, ce trebuiesc îndeplinite pentru analiza, proiectarea şi realizarea diferitelor tipuri de aplicaţii informatice. Pentru a nu "descoperi" de fiecare dată procedeul care a dus la succesul realizării unui produs anterior, s-a căutat definirea unor metode pragmatice de structurare a programelor şi ulterior de analiză şi proiectare a acestora. "Reutilizarea" este un cuvânt cheie în dezvoltarea aplicaţiilor din ultimii ani, iar aceasta nu se referă numai la reutilizarea părţilor de cod, ci la toată experienţa acumulată pe parcursul dezvoltării produsului software. Un factor important care a dus la apariţia conceptului de reutilizare în ingineria software este timpul, termenele de realizare a proiectelor devenind tot mai scurte (de ordinul săptămânilor sau lunilor). Produsul este dezvoltat adeseori "din mers", în sensul că programatorul încearcă să ghicească şi să implementeze cerinţele schematizate ale clientului. Acesta urmează să formuleze cerinţele efective pornind adeseori de la un prototip furnizat de proiectant.

În prezent există o multitudine de metodologii de proiectare şi realizare a sistemelor informatice. Toate metodologiile recurg la etapizarea activităţilor de realizare a sistemelor informatice.

Aceste metodologii sunt asemănătoare în mare parte, dar diferenţiate fie prin documentaţia realizată pentru fiecare etapă, fie prin modul de reprezentare grafică a rezultatelor fiecărei etape, fie prin modul de abordare al acestora sau prin metodele utilizate.

Prin metode de analiză şi proiectare înţelegem o mulţime de procedee, tehnici şi recomandări utilizate în etapele ciclului de viaţă al unei aplicaţii având ca scop

33

final crearea unui model al aplicaţiei care urmează a fi construită. Specificarea acestui model se realizează prin intermediul unui limbaj sau formalism vizual compus dintr-un set de simboluri grafice şi adnotări textuale.

Spre deosebire de modele, o metodologie se defineşte ca o cale prin care modelele şi tehnicile din diferite stadii ale ciclului de viaţă al realizării sistemului sunt puse laolaltă pentru a crea un sistem.Evoluţia lor poate fi structurată în trei generaţii de metode, determinată de:

- creşterea ariei de utilizare a tehnologiei informatice; - creşterea gradului de complexitate a aplicaţiilor şi a cerinţelor de integrare; - necesitatea diminuării costurilor, a creşterii productivităţii şi a reducerii

riscurilor de realizare; - evoluţia structurii şi tipologiei aplicaţiilor de gestiune: SPT, SIM, SSD,

SSE, birotică, multimedia; - influenţa exercitată de evoluţia limbajelor de programamre, a S.G.B.D-

urilor, a reţelelor de calculatoare, a tehnicilor de gestiune în timp real etc.

Se poate pune, în mod normal întrebarea “de ce nu există o singură metodologie de proiectare” care să fie general valabilă şi aplicabilă în toate cazurile? Un răspuns ar putea fi acela că metodologiile diferă între ele destul de mult, unele fiind mai eficiente în anumite domenii sau cazuri şi mai puţin în altele. Practic, aceste metodologii s-au născut din generalizarea soluţiilor testate pe cazuri particulare.

O problemă decisivă pentru echipa de proiectare devine astfel alegerea metodei ce urmează a fi aplicată pentru fiecare caz în parte. Se poate spune că acesta este primul pas deosebit de important în realizarea proiectului. Dacă alegerea făcută este bună, acest fapt va putea duce la rezultate pozitive din toate punctele de vedere. În cazul în care s-a optat însă pentru o metodă nepotrivită problemei, rezultatele proiectului pot fi pe măsură (adeseori la sfârşitul proiectului se constată că aplicaţia trebuie proiectată şi implementată într-un mod diferit).

Alegerea unei metode pentru rezolvarea unei anumite probleme date depinde de mai mulţi factori, printre care: tipul problemei de rezolvat, domeniul în care se încadrează problema, pregătirea şi calificarea echipei de proiectare şi realizare a produsului software, resursele hardware şi software disponibile, şi, nu în ultimul rând, bugetul şi timpul alocat proiectului.

Făcând un scurt istoric al metodologiilor de proiectare a sistemelor informatice, se poate face o grupare a acestora în trei mari categorii, astfel:

1. Metode ierarhice Reprezintă prima generaţie a metodelor de proiectare, corespunzătoare anilor

1970, caracterizate în principal prin următoarele: - sistemul informaţional/informatic este structurat şi analizat pe baza

funcţiilor sale;

34

- sunt centrate pe analiza funcţională, adică fiecare funcţie identificată se subdivide ierarhic în subfuncţii, continuând în acest fel până se ajunge la componente suficient de mici încât să poată fi programate cu uşurinţă (fig. 1.1);

Exemple de astfel de metodologii: SADT (Structured Analysis and Design Technique), JSD (Jackson System Development), Yourdon.

Fig. 2.1. Divizarea funcţiilor unei întreprinderi

Avantajele acestui mod de abordare în proiectare ar fi: simplitate, bună adaptare la definirea cerinţelor utilizatorului;

Ca dezavantaj se poate considera faptul că se concentrează efortul de analiză asupra funcţiilor (de prelucrare) neglijând coerenţa datelor, a căror structură este mult mai stabilă. Ca efect, modificarea continuă a cerinţelor de prelucrare a utilizatorilor (a funcţiilor) fac ca aplicaţiile să fie într-o continuă reproiectare (reconsiderare).

2. Metode sistemice Reprezintă generaţia a doua a metodelor de proiectare, corespunzătoare anilor

1980, caracterizate în principal prin următoarele: - se bazează pe aplicarea teoriei sistemelor în analiza întreprinderii; - sistemul informaţional/informatic este abordat şi analizat sub două aspecte

complementare: datele şi prelucrările, care sunt studiate şi modelate independent şi reunite cât mai târziu cu putinţă;

- acordă prioritate datelor faţă de prelucrări; - respectă cele trei nivele de concepţie introduse prin raportul

ANSI/SPARC/X31: extern, conceptual, intern; Ca exemple se pot aminti : SSADM (Structured System Analysis and Design

Method ), MERISE, AXIAL, Information Engineering (J.Martin). Avantaje: sistemele se axează pe conceptul de bază de date, care oferă mai

multă coerenţă, stabilitate şi elimină redundanţa datelor. Dezavantaje: deficienţe în modelarea prelucrărilor, posibilitatea apariţiei de

discordanţe între modelele datelor şi ale prelucrărilor, analizate iniţial separat.

35

3. Metode orientate obiect (obiectuale) Reprezintă generaţia a treia, aparţinând perioadei de după anul 1990,

caracterizată prin următoarele:- sistemul informaţional/informatic este perceput ca o structură de obiecte

autonome, care se organizează şi cooperează între ele; - un obiect are un anumit comportament, definit prin ansamblul operaţiilor

(serviciilor) pe care le poate efectua; datele şi prelucrările prin care este implementat acest comportament sunt încapsulate şi sunt inaccesibile celorlalte obiecte;

- fiecare obiect poate participa la compunerea altor obiecte mai complexe;- fiecare obiect poate interveni în mai multe funcţii sau scenarii funcţionale

diferite;Ca exemplu, amintim metodologiile: OOD – Object Oriented Design (Grady

Booch, 1993), OMT – Object Modeling Technique (James Rumbaugh, 1991), OOA – Object Oriented Analysis (Peter Coad şi Ed Yourdon), HOOD (Hierarchical Object Oriented Design, 1999 ), OOM (Rochfeld).

Avantaje: permite reutilizarea componentelor de program, favorizează modelarea şi utilizarea de obiecte complexe.

Dezavantaje: percepţia şi reprezentarea monolitică de tipul " totul este obiect " nu corespunde întotdeauna realităţii reprezentate.

Observaţie:

În literatura de specialitate metodologiile de proiectare şi realizare a sistemelor informatice mai sunt grupate în trei mari categorii astfel:

- clasice (IBM, ICI)- moderne (SSADM, MERISE)- orientate obiect (OMT, UML)

2.2. Ciclul de viaţă al sistemelor informatice

Un sistem informatic are, indiferent de evoluţia tehnicii de calcul, a metodologiilor şi tehnicilor de realizare, a experienţei echipei de proiectare sau a cerinţelor beneficiarului, un ciclu de viaţă, care începe cu momentul deciziei de realizare a sa şi durează până la scoaterea din funcţiune sau înlocuirea cu un altul. Prin urmare, un sistem informatic/aplicaţie informatică se realizează de către echipa de proiectare (specialişti în informatică) la cererea unui beneficiar şi în condiţiile prevăzute de acesta. Se impune astfel definirea unor termeni noi, legaţi de utilizatorii sistemului proiectat.

Utilizatorul este o persoană sau un grup de persoane pentru care proiectantul de sistem construieşte şi menţine în exploatare aplicaţii sau sisteme informatice, adică este client al sistemului informatic.

36

Remarcabilul autor şi consultant de sisteme informatice Ed. Yourdon observa că utilizatorul este în fond clientul care formulează cerinţele (oricât de contradictorii ar fi) şi este în ultimă instanţă persoana care plăteşte sistemul informatic şi deci poate refuza plata dacă nu este mulţumit de produsul realizat.

Din această observaţie rezultă două categorii de utilizatori şi anume: utilizatorii sistemului; proprietarii sistemului.Utilizatorii sistemului reprezintă acea categorie de personal care are contact

direct cu sistemul informatic sau cu aplicaţiile realizate, adică utilizează calculatoarele pentru introducerea, stocarea sau transmiterea datelor sau utilizează informaţiile furnizate în rapoartele sistemului.

Proprietarii sistemului sunt cei care asigură resursele financiare ale sistemului informatic, adică ei plătesc costurile de realizare şi exploatare a sistemului informatic.

Ciclul de viaţă al unui sistem informatic sau al unei aplicaţii reprezintă totalitatea etapelor care sunt parcurse în procesul de dezvoltare a sistemului/ aplicaţiei respective. Dintre acestea, cele mai importante etape, întâlnite practic în toate metodologiile de proiectare a sistemelor informatice, sunt:

- Culegerea de specificaţii (analiza funcţională) - presupune definirea problemei; specificarea detaliată a funcţionalităţilor ce trebuie îndeplinite de către sistemul informatic;

- Analiza - în cadrul căreia se realizează cunoaşterea şi apoi modelarea sistemului existent (date, prelucrări), identificarea direcţiilor de perfecţionare a acestuia, stabilirea caracteristicilor esenţiale pentru soluţiile corecte posibile;

- Proiectarea - care adaugă modelelor de analiză noi elemente prin care se defineşte o soluţie particulară, pe baza optimizării anumitor criterii;

- Programarea – în care se realizează scrierea efectivă a programelor pe baza specificaţiilor tehnice rezultate în urma celorlalte etape;

- Implementarea - în care se realizează un proiect executabil al soluţiei particulare modelată în faza de proiectare. Se verifică astfel cu date reale aplicaţia realizată, se fac ultimele corecţii şi se definitivează documentaţia de utilizare şi exploatare a acesteia.

- Exploatarea curentă, întreţinerea şi dezvoltarea sistemului realizat presupune adaptarea acestuia la modificările ce pot apare sau dezvoltarea cerută de nevoi suplimentare de informare pentru fundamentarea deciziilor.

În funcţie de metodologiile, metodele, tehnicile şi instrumentele folosite, etapele de realizare a sistemelor informatice comportă mai multe modele de abordare, dintre care prezentăm câteva:

1. modelul clasic (liniar) sau în cascadă;2. modelul structurat3. modelul cu prototip

37

4. modele orientate obiect5. alte modele, precum: modelul V, modelul spirală, modelul evolutiv,

modelul tridimensional, modelul X, etc.

1. Modelul clasic (liniar)Este specific metodologiilor clasice de realizare a sistemelor informatice, cum

ar fi ICI, IBM, AXIAL etc. În mod sugestiv modelul poate fi reprezentat ca în fig. 2.2.

Fig.2.2. Modelul clasic (liniar)

Prin forma sa de abordare modelul mai poartă denumirea de model în cascadă. În prima etapă se realizează studiul sistemului existent sau fotografierea

acestuia. Obiectivul urmărit îl constituie cunoaşterea şi însuşirea sistemului existent.

A doua etapă are ca obiectiv definirea unor criterii de apreciere (evaluare) a stării sistemului în vederea stabilirii diagnosticului sistemului (dificultăţilor şi neajunsurilor acestuia). În funcţie de concluziile desprinse se definesc variante de soluţii cu privire la perfecţionarea sistemului existent. Acestea vor fi supuse spre alegere factorilor de conducere. Soluţia aleasă va deveni obiect de preocupare pentru următoarele etape.

În etapa a treia, în concordanţă cu varianta aleasă, se trece la proiectarea logică şi fizică de detaliu a fiecărei componente din cadrul sistemului informatic.

În etapa a patra se realizează asigurarea prin eforturi proprii sau prin achiziţie a resurselor software necesare aplicaţiilor informatice.

38

În etapa a cincea se realizează testarea şi verificarea funcţionării sistemului în condiţii concrete (în mediu real). În măsura în care se constată că sistemul răspunde performanţelor şi obiectivelor prestabilite se trece la exploatarea şi întreţinerea curentă a acestuia. În cadrul acestei etape se urmăreşte adaptarea sistemului informatic la modificările, schimbările intervenite în cadrul unităţii beneficiare.

Se observă că, în primele 2 etape se răspunde la întrebarea CE trebuie să facă sistemul, adică: ce informaţii se prelucrează, ce funcţii şi performanţe se cer, ce restricţii se impun, ce criterii de validare trebuie respectate.

În următoarele etape se răspunde la întrebarea CUM trebuie proiectată structura datelor, cum va fi arhitectura sistemului, cum vor fi implementate procedurile şi cum se face testarea sistemului cu date reale.

În ultima etapă se urmăreşte funcţionarea sistemului, adaptarea lui la modificări, corectarea eventualelor erori.

Avantajul modelului clasic constă în faptul că oferă posibilitatea realizării sistemului informatic într-o succesiune logică, gradată.

Dezavantajele modelului clasic ar putea fi următoarele: presupune surprinderea încă din start a tuturor cerinţelor informaţionale ca

situaţii de informare-raportare, ceea ce este destul de dificil. orice scăpare a unor cerinţe sau obiective ale conducerii implică reluarea

mai multor etape din cadrul modelului. ţinând seama de faptul că realizarea unui sistem informatic integrat poate

dura câţiva ani de zile, beneficiarul aşteaptă o durată îndelungată de timp pentru a se convinge că sistemul realizat este performant şi răspunde cerinţelor şi obiectivelor prestabilite.

2. Modelul structurat cu elemente de generaţia a patra (4 GL)Specificitatea modelului (fig. 2.3) constă în utilizarea unor instrumente de

generaţia a patra în proiectarea şi realizarea sistemului, cum sunt: limbaje de generaţia a patra generatoare de aplicaţii instrumente CASE alte TOOLS-uri

Cu ajutorul unor astfel de elemente se reuşeşte să se reducă timpul de analiză-proiectare, precum şi cel necesar elaborării programelor. Se reuşeşte în final să se realizeze atât documentaţia de sistem, cât şi generarea totală sau parţială a produselor program.

Reuşita modelului depinde în mare măsură de dialogul şi relaţia proiectant – utilizator.

39

Fig. 2.3. Modelul structurat

Avantajul acetui tip de model constă în creşterea productivităţii muncii în activitatea de programare.

3. Modelul cu prototip (prototipizarea)

Se pleacă de la definirea cerinţelor şi obiectivelor globale formulate de beneficiar. Pe baza acestora proiectantul realizează un model prototip de sistem informatic, punând accent în mod deosebit pe evidenţierea interfeţelor sistemului cu utilizatorul. Vor fi precizate intrările ca surse de date, apoi ieşirile ca situaţii de informare-raportare prestabilite, necesare conducerii.

Modelul astfel elaborat nu se livrează beneficiarului ci se “aruncă” acestuia. Pe baza demonstraţiei făcute se ajustează (se rafinează) modelul şi apoi se trece la implementarea şi exploatarea curentă a acestuia.

Modelul prototip (fig. 2.4) poate fi prezentat în diferite variante: sub forma unor scheme privind circuitul şi fluxul informaţional pe

domenii de interes; în cadrul schemei vor fi evidenţiate intrările, procedurile şi ieşirile sistemului.

sub forma unui sistem prototip realizat în cadrul unităţii beneficiare sau deja existent, evidenţiind problematica la modul parţial sau în totalitate.

sub forma unui sistem deja existent, prezentându-se chiar problematica în extenso, beneficiarul având posibilitatea să opteze sau nu pe extensiile sistemului.

40

Fig 2.4. Modelul proptotip

Avantajele modelului prototip sunt următoarele: se reduce mult timpul de realizare a sistemului informatic. oferă mari facilităţi de revenire în diferite etape.Dezavantajele modelului prototip: tocmai datorită faptului că modelul oferă

facilităţi de revenire în diferite etape, beneficiarul are tendinţa de a sugera, de a solicita mereu noi “mici modificări”. Proiectantul va ţine seama de acestea, va efectua modificări, însă în situaţia efectuării unor multiple modificări este posibil să se ajungă la îndepărtarea faţă de obiectivele iniţiale şi chiar de performanţele prestabilite.

    4. Metodele de analiză şi proiectare orientată-obiect permit parcurgerea

etapelor ciclului de viaţă a aplicaţiilor într-o manieră iterativă, foarte asemănătoare cu cele funcţionale sau structurale (fig. 2.5).

       Fig 2.5. Modelul iterativ de dezvoltare a unei aplicaţii în

cazul utilizării unei metode de analiză şi proiectare orientate-obiect

41

Odată cu evoluţia metodelor de analiză şi proiectare orientate-obiect s-au dezvoltat o serie de instrumente care permit automatizarea procesului de realizare a aplicaţiilor având la bază aceste metode. Astfel de instrumente poartă numele de instrumente CASE (Computer Aided Software Engineering) şi sunt formate dintr-o colecţie de componente care sprijină realizarea operaţiilor ce trebuie efectuate în cadrul uneia sau mai multor etape ale unei metode de analiză şi proiectare.

2.3. Concepte de proiectare şi realizare a sistemelor informatice

Conceptul general după care se realizează un sistem informatic poate fi diferit, de la caz la caz. În literatura de specialitate sunt definite mai multe concepte, dintre care S. Blumenthal distinge şase tipuri şi anume:

a). Conceptul schemei organizatorice. În acest caz sistemul este proiectat ca o imagine a funcţiunilor şi legăturilor din structura organizatorică a societăţii.

Ca dezavantaj, metoda păstrează tot ce este rău în această schemă şi ca urmare, realizează în final automatizarea operaţiilor executate manual.

b). Conceptul colectării datelor. În acest caz toate datele care apar în fluxurile informaţionale ale societăţii sunt colectate şi analizate, iar rezultatele analizei constituie baza noului sistem. Metoda este de cele mai multe ori oportună şi eficientă, dar practic este greu de realizat la sisteme complexe, cu volum mare de date.

c). Conceptul cerinţelor conducerii. În acest caz se cere conducerii societăţii să enumere ce crede că este necesar să se facă şi aceste cereri servesc ca bază pentru proiectare. Teoretic conceptul e bun, dar în practică implică:

- conducători care să ştie exact ce este necesar pentru îmbunătăţirea activităţii;

- un mod de formalizare a cererilor foarte exact;- proiectanţi care, numai pe baza acestor cereri, să poată proiecta sistemul

necesar. d). Conceptul băncii de date. Metoda impune crearea unei bănci de date care să

conţină toate datele importante referitoare la societate, structurate şi memorate astfel încât să permită utilizatorilor interogarea sistemului în orice moment.

e). Conceptul integrării imediate, dorit de multă lume dar foarte greu de realizat.

f). Conceptul integrării ulterioare. În acest caz datele sunt colectate, analizate şi memorate treptat, pe măsura rezolvării unor probleme şi în speranţa integrării ulterioare. Dacă însă planul de realizare şi integrare nu este bine urmărit şi realizat întocmai, obiectivul nu se mai poate realiza sau implică eforturi foarte mari de reproiectare a sistemului.

42

Ţinând cont de toate aceste concepte, de avantajele şi dezavantajele fiecăruia, se poate aprecia că realizarea sistemelor informatice e bine să se realizeze după următorul concept:

- stabilirea, la început, a unei concepţii generale de realizare a sistemului, pe baza obiectivelor şi cerinţelor informaţionale pe care acesta le va îndeplini, în vederea realizării în final a unui sistem integrat;

- împărţirea sistemului în principalele sale componente – subsisteme şi aplicaţii – cu determinarea legăturilor dintre acestea;

- analiza datelor semnificative din societate şi stabilirea modului de organizare şi prelucrare a acestora;

- stabilirea, de comun acord cu beneficiarul, a priorităţilor în elaborarea componentelor;

- planificarea, proiectarea, realizarea efectivă şi apoi implementarea treptată a subsistemelor şi a aplicaţiilor, cu verificarea permanentă a modului de realizare a interfeţelor între acestea şi cu utilizatorul.

Observaţie:1. Trebuie precizată necesitatea reluării (reiterării) anumitor activităţi cu

reactualizarea corespunzătoare a planificărilor făcute şi, dacă e cazul, chiar a conceptului stabilit pentru proiectarea sistemului informatic.

2. Este bine de ştiut că în proiectarea şi realizarea unui sistem informatic pentru orice societate beneficiară sunt câteva etape în care este absolut obligatorie participarea directă a viitorului utilizator, a specialistului în domeniu, care ţine în mod curent evidenţa manuală. Dintre aceste etape, deosebit de importante prin efectele lor ulterioare, sunt etapele de analiză şi apoi de implementare. Pentru ca utilizatorul să-l înţeleagă pe proiectant, să-l asiste şi să-l îndrume pe toată perioada analizei, să înţeleagă şi să aprobe gîndirea, soluţia proiectantului, este necesar să ştie ce se aşteaptă de la echipa de proiectare în această etapă şi ce trebuie să facă beneficiarul.

2.4. Strategii de investigare, metode de analiză şi proiectare a sistemelor informatice

În activitatea de proiectare şi realizare efectivă a unui sistem informatic se utilizează numeroase metode şi tehnici, care pot fi grupate, la o primă vedere, în două mari categorii :

metode specifice informaticii, cum sunt: descendentă (top-down) simbolizată prin TD; ascendentă (bottom-up), simbolizată prin BU; hibridă sau mixtă (top-down-bottom-up) simbolizată prin TDBU. Tehnica concordanţei intrări-ieşiri, care presupune realizarea sistemelor

informatice pornind de la mulţimea informaţiilor necesare fundamentării

43

deciziilor. Ea este mai mult o tehnică de analiză a sistemului existent, pentru determinarea datelor şi a prelucrărilor acestora necesare elaborării modelului datelor şi prelucrărilor. Ea serveşte la analiza completitudinii datelor din sistem.

metode generale ce pot fi aplicate şi în informatică, cum sunt : metodele de facilitare a “realităţii” (Breinstorming, Delphi, etc.), metodele de conducere a proiectelor (drumul critic, diversele metode

derivate din teoria deciziei, etc); metodele de reducere a costurilor (cuprinse în cele două discipline:

ingineria şi respectiv, analiza valorii); metodele de fundamentare a investiţiilor (metode specifice Marketing-

ului, metode de simulare etc.).Având în vedere specificul activităţii de proiectare a sistemelor informatice,

vom prezenta în continuare metodele specifice acestei activităţi.Conform definiţiei adoptate în literatura de specialitate, o metodă de analiză

şi/sau proiectare a unui sistem informatic este un ansamblu de concepte şi reguli prin aplicarea căruia poate fi realizată această activitate. La baza tuturor metodelor specifice informaticii stă conceptul de “modularitate”, iar modul de abordare al sistemelor pentru investigare şi descompunere în module componente se constituie ca o strategie de abordare a acestora.

Din acest punct de vedere se poate aprecia justificarea eficienţei aplicării celor trei strategii de abordare astfel:

Strategia descendentă (TD) – prin obiectivele sale specifice, este cea mai indicată pentru analiza, conceperea şi proiectarea produsului în ansamblu, precum şi pentru construirea fiecărui subsistem în parte;

Strategia ascendentă (BU) – este extrem de utilă pentru verificarea şi ajustarea unor rezultate obţinute în urma aplicării metodei TD precum şi pentru implementarea de subsisteme sau componente a sistemelor informatice complexe.

Strategia mixtă (TDBU) – este indicată la “stabilirea dimensiunilor sistemului” prin abordarea prioritară a subsistemelor care sunt semnificative din acest punct de vedere, precum şi la “Planificarea realizării lui” prin punerea accentului pe componentele “critice”.

Se impune să facem precizarea că abordarea top-down presupune în mod implicit conceptul de modularitate a sistemelor. Aceasta permite ca funcţiile logice să poată fi grupate şi apoi subgrupate cât mai independent, ajutând de fapt dezvoltarea separată a modulelor, adică a componentelor sale. Realizarea unei bune modularităţi funcţionale cere însă din partea proiectantului un efort de creaţie, o înţelegere corectă a conceptului şi o bună experienţă în proiectare.

Expresia concretă a modularităţii este noţiunea de modul care se caracterizează prin :

orice modul este ansamblu de module care reprezintă rafinări ale modulului iniţial;

44

se admite existenţa unor module care practic nu mai pot fi rafinate şi care poartă numele de module terminale;

orice modul se poate integra cu alte module, formând noi module; orice modul se adaptează la mediu.Un modul ar trebui să fie conceput astfel încât să respecte următoarele reguli:- Să îndeplinească o funcţie bine definită, unică, pentru a uşura eventualele

modificări;- Să fie complet, pentru a putea fi realizat independent;- Să aibă minimizate interfeţele de date cu celelalte module, pentru a face

posibilă o întreţinere uşoară;- Să permită o înţelegere uşoară a problemelor pe care le rezolvă;- Să se poată încadra şi utiliza în diversele nivele de modularitate ale

sistemului. Ceea ce diferenţiază cele trei metode specifice informaticii sunt seturile de

reguli care caracterizează fiecare metodă în parte.Din acest punct de vedere, cele 3 metode pot fi descrise astfel:

Strategia descendentă (TD) constă în descompunerea unui sistem complex pe nivele ierarhice, succesiv, până la module elementare, simple şi relativ independente, astfel:

A. Se consideră drept punct de pornire (nivel 0 de descompunere) o componentă neterminală.

B. Se aplică descompuneri succesive, în paşi, de sus în jos, pentru toate componentele neterminale ale unui nivel.

C. Un nivel de descompunere corespunde cu sfârşitul unui pas de sus în jos.D. Descompunerea se consideră terminată atunci când toate componentele

unui nivel sunt module terminale.E. a). Se înlocuiesc rezultatele obţinute la un nivel de descompunere cu

rezultatele obţinute la nivelul următor,sau :b). După terminarea descompunerii se aplică succesiv regula E a, începând de

la ultimul nivel (ce conţine numai componente / module terminale) şi terminând cu nivelul 0 de descompunere.

Strategia ascendentă (BU) constă în agregarea modulelor de jos în sus, evidenţiind legăturile dintre ele, până când se ajunge la un modul, astfel:

A. Se consideră drept punct de pornire (nivel 0 de agregare) un set de componente (module) terminale.

B. Se realizează agregări succesive în paşi, de jos în sus.C. Un nivel de agregare corespunde unui pas de jos în sus; odată cu obţinerea

unui nivel de agregare se realizează, implicit, şi o integrare a componentelor (modulelor) de nivel superior.

45

D. Agregarea se consideră terminată atunci când în cazul unui nivel (de agregare) se obţine o unică componentă (modul).

Strategia mixtă (TDBU)Se bazează pe diversele mixturi între regulile metodelor TD şi BU, oferind o

gamă largă de posibilităţi în funcţie de regula care fixează pornirea şi care poate fi:

A. Se începe cu componentele (modulele) considerate critice din anumite puncte de vedere, ca de exemplu : din punctul de vedere al realizării şi implementării şi/sau al tipului de răspuns, al dimensiunilor sistemului, etc.

B. Se începe cu componentele (modulele) cele mai complexe.C. Se începe cu componnentele (modulele) identice, indiferent de nivel, etc.D. Se începe cu componentele (modulele) cele mai simple, indiferent de

nivel, etc.Fiecare regulă de începere atrage dupa sine câte un set specific de reguli de

continuare şi terminare.

Precizare : Nu trebuie confundată strategia mixtă (TDBU) cu o înşirare secvenţială, pe fluxul tehnologic, a metodelor descendentă (TD) şi ascendentă (BU). O înşiruire secvenţială de metode care poate cuprinde şi metoda mixtă este de fapt o strategie de realizare a produselor informatice.

Observaţie:Oricare ar fi metodologia de proiectare utilizată, oricare ar fi strategia de

abordare, metodele şi tehnicile de investigare sau de proiectare, toate recurg la o modelare coceptuală, logică şi fizică a datelor şi a prelucrărilor, aşa încât se impune studiul acestora înainte de a descrie în detaliu, specificul fiecărei metode.

46

3. MODELAREA CONCEPTUALĂ A DATELOR3.1. Concepte utilizate în organizarea datelor

În orice domeniu de activitate crearea modelelor reprezintă o muncă creativă. În timpul modelării, cele mai bune soluţii sunt obţinute printr-o muncă tenace, în timpul căreia sunt propuse diferite soluţii, care sunt modelate şi apoi testate.

Modelele care ajung să fie utilizate trebuie să îndeplinească nişte condiţii minimale, cum sunt:

Fidelitate: modelul descrie în mod corect sistemul care trebuie construit; Consistenţă: modelul trebuie să reprezinte viziuni despre lucruri care nu

sunt în conflict cu altele; Uşurinţa de a comunica cu ceilalţi, de a fi sugestive; Uşurinţa de a fi schimbate, adaptate la modificări; De înţeles: simplu, intuitiv, sugestiv (altfel spus, mai simplu de atât nu se

poate).În activitatea de anliză şi proiectare a unui sistem informatic se apelează la

tehnica modelării, care trebuie să se supună tuturor acestor reguli şi altora suplimentare, cerute de specificul activităţii.

Proiectarea şi realizarea unui sistem informatic care presupune prelucrarea automată a datelor necesită, pe lângă activităţile legate de formularea problemei, de analiza acesteia în vederea găsirii algoritmului de rezolvare şi o altă activitate, deosebit de importantă, legată de organizarea datelor, în concordanţă atât cu caracteristicile tehnice ale echipamentelor de calcul, cât şi cu cerinţele de prelucrare. Acestea trebuie să fie structurate astfel încât prin codificarea şi apoi memorarea lor pe suporţi tehnici să permită prelucrările necesare, stocarea şi regăsirea ulterioară a datelor după criteriile stabilite.

Organizarea datelor reprezintă deci un proces de structurare a datelor, de organizare şi grupare a acestora în colecţii de date, între care se stabilesc relaţii şi pentru care se definesc restricţii, condiţii de validare.

Organizarea datelor este ca urmare un proces deosebit de important în cadrul proiectării unui sistem informatic şi cuprinde următoarele activităţi:

- Identificarea datelor;- Clasificarea şi descrierea proprietăţilor, a caracteristicilor datelor;- Gruparea datelor în colecţii de date destinate prelucrării automate;- Reprezentarea externă pe suporturi tehnice;- Identificarea, definirea şi descrierea procedurilor de prelucrare automată.Eficienţa prelucrării automate a datelor, deci şi eficienţa unui sistem informatic

proiectat, succesul acestuia depind, în mare măsură, de organizarea internă şi externă a datelor, de stabilirea unor structuri de date care să corespundă cerinţelor de prelucrare, să satisfacă cererile de informare, de sintetizare sau grupare a datelor, de regăsire şi ordonare a acestora după criteriile dorite.

47

Organizarea datelor a evoluat odată cu componentele hardware şi software, cu posibilităţile oferite de acestea, dar şi cu exigenţele crescute ale beneficiarilor sau experienţa acumulată de proiectanţii de sisteme.

În etapa de analiză a sistemului se realizează practic identificarea şi inventarierea cerinţelor sistemului, analiza şi structurarea acestora, definirea direcţiilor de perfecţionare. Structurarea cerinţelor sistemului înseamnă realizarea celor trei activităţi propri analistului şi anume:

- modelarea proceselor de prelucrare a datelor;- modelarea logicii acestora;- modelarea conceptuală a datelor. 3.1.1. Concepte de bază

Modelarea conceptuală a datelor este o modalitate de reprezentare a datelor din domeniul analizat, cu scopul de a scoate în evidenţă toate regulile privind identitatea şi legăturile existente între date.

Cea mai utilizată formă pentru modelarea conceptuală a datelor este modelul entitate – asocire (sau entitate – relaţie). Acest model se crează printr-un proces iterativ, utilizând iniţial un volum mare de date descrise care sunt apoi prelucrate şi selectate astfel încât să răspundă cerinţelor benefiarului. Modelul entitate asociere care se crează prezintă caracteristicile şi structura datelor din domeniul analizat, independent de modul în care acestea vor fi memorate în calculator.

Lumea care ne înconjoară este formată din obiecte concrete sau abstracte, care se descriu în procesul cunoaşterii, aşa cum am văzut, prin informaţii. Dacă vom numi obiectele entităţi, atunci proprietăţile acestora se vor numi atribute. Aceste atribute pot lua diverse valori, definite astfel ca măsură a proprietăţilor.

Odată cu apariţia bazelor de date ca modele de structurare a datelor, în terminologia curentă au fost introduse şi utilizate cele 3 concepte de bază în organizarea datelor, şi anume: entitate, atribut şi valoare. Cele trei noţiuni sunt strâns legate între ele: o entitate are mai multe atribute, iar unui atribut i se asociază o mulţime de valori.

Entitatea este deci un obiect concret sau abstract, reprezentat prin proprietăţile lui. Entitatea reprezintă astfel obiectul informaţiei, iar atributul o proprietate a entităţii.

Pe de altă parte, orice proprietate a unui obiect poate fi descrisă printr-o pereche (Atribut, Valoare). Prin urmare, o entitate poate fi reprezentată prin mai multe proprietăţi, deci mai multe perechi de forma (Atribut, Valoare).

În lume există însă o infinitate de entităţi şi atribute. Responsabilitatea analistului este de a determina subsetul cel mai relevant şi precis pentru problema abordată.

48

În concluzie, o entitate este reprezentarea unui "obiect" concret sau abstract care:

- aparţine domeniului problemei de rezolvat (face parte sau este relevant pentru realitatea observată);

- are o existenţă de sine stătătoare; - poate fi identificat în raport cu celelalte obiecte de acelaşi tip.Exemple: student, angajat, produs, mijloc fix, client, comandă, factură.

Entitatea este deci “un tip de obiecte“, iar fiecare obiect individual constituie o realizare (o instanţă) a entităţii respective. O entitate este reprezentată printr-un ansamblu de proprietăţi, de atribute.

Atributele sunt descriptori ai entităţilor; ele reprezintă informaţiile care trebuie cunoscute despre entităţi. Altfel spus, atributele reprezintă modul în care informaţia despre entităţi este stocată.

Atributul este deci o caracteristică sau proprietate a unei entităţi, semnificativă pentru problema de rezolvat. Pentru fiecare realizare a unei entităţi se cunosc aceleaşi atribute, dar pentru fiecare în parte valoarea atributelor diferă.

De exemplu, un student X se poate reprezenta prin perechi (Nume, Popescu), (Facultate, Turism), (Telefon, 4201254), (Grupa, 501), etc.

Practic, mulţimea atributelor Nume, Facultate, Telefon, Grupa poate fi asociată mai multor studenţi; Aceasta înseamnă că un atribut nu caracterizează doar o entitate, ci o clasă de entităţi, numită entitate grup. În exemplul nostru entitatea grup se poate numi STUDENTI.

Observaţie:Când identificăm o entitate, identificăm de fapt un grup de obiecte. În interiorul

grupului există instanţe individuale.•Instanţele nu trebuie confundate cu entităţile;•O entitate este o clasă sau o categorie de lucruri/obiecte (de exemplu Angajat);•O instanţă este un lucru/obiect specific (de exemplu Ionescu Ion);

STUDENTI

NUMEFACULTATE

TELEFONGRUPA

ATRIBUTE

POPESCU IONTURISM4201254501

POP VASILEINFORMATICĂ0748521478602..........................

REALIZĂRI ale entităţii

49

Dacă o entitate nu are mai multe instanţe, atunci ea nu este practic o entitate, ci mai degrabă un atribut al unei alte entităţi. În astfel de situaţii se impune o analiză suplimentară.

De exemplu, într-o firmă există mai multe departamente; entitatea Departament are mai multe instanţe: Personal, Contabilitate, Desfacere etc. Fiecare are un set comun de atribute sau informaţii stocate, de exemplu fiecare are un cod şi un nume.

Se ştie că o bază de date poate fi definită ca o mulţime de date ce modelează un univers. Acest univers este format din obiecte legate între ele.

Obiectele de acelaşi tip constituie o entitate, iar legătura între două entităţi defineşte o relaţie (asociere). Entităţile şi relaţiile au anumite caracteristici, numite atribute.

Un atribut poate fi, după complexitatea sa:- simplu sau elementar, dacă valorile lui nu pot fi descompuse (ex. Număr

matricol pentru student, an de studii,etc);- complex sau decompozabil, dacă valorile sale pot fi descompuse în mai

multe valori semnificative (ex. Data naşterii, cu semnificaţia an/lună/zi, un cod structurat pentru un produs, etc).

Un atribut poate fi analizat din punctul de vedere al realizărilor pe care le reprezintă, astfel:

- obligatoriu, ceea ce înseamnă că trebuie să prezinte cel puţin o realizare, deci să aibă o valoare Not Null (exemplu Numele studentului).

- opţional, dacă nu este obligatoriu să prezinte o valoare, cum ar fi: număr telefon, fax, cont în bancă etc.

- monovaloare, atunci când pentru o entitate sau o asociere poate lua o singură valoare; ex nume student, cod numeric personal, cod produs, denumire produs, etc ;

- multivaloare (repetitiv), dacă pentru o entitate sau o asociere poate lua mai multe valori (ex: limbi străine cunoscute -un student cunoaşte mai multe limbi străine-, nume copil -un salariat are mai mulţi copii).

Atributele trebuie să respecte următoarele reguli minimale:- fiecare atribut poate să apară într-o singură entitate (principiul

nonredundanţei) - un atribut poate avea numai valori elementare.Se numeşte tip de valori un anumit ansamblu de valori, definite fie printr-o

proprietate, fie printr-o enumerare. Aşa sunt de exemplu:Stare civilă = (necăsătorit, căsătorit, văduv, divorţat) An studii = (n : întreg, 1 £ n £ 5)

50

Fiecare instanţă (realizare) a unei entităţi trebuie să fie unic identificabilă faţă de alte instanţe ale aceleeaşi entităţi. Un atribut sau un set de atribute ce realizează acest deziderat se numeşte Identificator Unic.

Identificatorul entităţii reprezintă deci un atribut sau un grup de atribute care primeşte valori unice pentru fiecare realizare a entităţii respective şi poate servi astfel pentru identificarea fără echivoc a acestora.

De regulă se recurge la coduri numerice care sunt atribute construite special astfel încât să răspundă cerinţelor de identificare (ex: marcă salariat, număr matricol studenţi, cod numeric personal pentru cetăţeni) sau la atribute de tip "număr de ordine" sau "număr de apariţie" (ex: numărul de inventar al unui mijloc fix). În reprezentarea grafică, identificatorul entităţii se subliniază.

Se numeşte tip de entitate mulţimea tuturor entităţilor care prezintă aceleaşi caracteristici. De exemplu: Studenţi, Produse, Contracte, Mijloace fixe, Comenzi, Furnizori, Clienţi, etc.

Exemplu:Dacă ne gândim la activitatea unui spital, vom identifica grupe de obiecte cu

aceleaşi caracteristici, deci entităţi cum sunt:- medici, care lucrează în secţii şi saloane; - secţii;- saloane;- pacienţi, care vin la consult sau tratament;- proceduri de tratament;- medicamente prescrise în anumite cantităţi.Fiecare dintre aceste entităţi se poate caracteriza prin atribute proprii, cum ar fi

de exemplu:Medici: Cod medic, nume, specialitate, adresă, telefon;Pacienţi: CNP, Nume, adresă, act identitate.Secţii: Cod secţie, denumire.Medicamente: Cod medicament, denumire, preţ, formă de prezentare, etc

Problema de modelat, deci cea din domeniul ce urmează să fie informatizat este adeseori foarte complexă, conţinând atât obiecte simple cât şi obiecte complexe, compuse din obiecte simple legate între ele. În urma analizei lor,

51

STUDENTI

NUMEFACULTATE

TELEFONGRUPA

CNPNUME

FACULTATETELEFON

GRUPA

informaticianul venit să modeleze acest univers, va identifica obiectele simple şi pe cele compuse. În modelul Entitate-Asociere, ce urmează a fi realizat, el va asocia fiecărui obiect simplu câte un tip de entitate cu atribute monovaloare.

Pentru obiectele compuse, funcţie de experienţa modelatorului, se pot identifica de la început obiectele şi legăturile lor, fiecărui obiect corespunzându-i un tip de entitate. De cele mai multe ori însă, se asociază iniţial obiectului compozit, cu caracteristici multivaloare, o entitate cu atribute multivaloare; modelul astfel obţinut va fi optimizat, astfel încât obiectului respectiv să-i corespundă mai multe tipuri de entităţi, cu condiţia ca atributele multivaloare să fie grupate într-un tip separat de entitate. Se ajunge astfel la un model cu obiecte simple, cărora le corespund tipuri de entităţi cu atribute elementare (simple).

De exemplu, dacă ne referim pentru activitatea de desfacere produse la o factură, în cadrul ei se identifică o parte fixă, cu atribute elementare, şi anume: Nr factură, data facturii, cod furnizor, banca furnizor, cont furnizor (plătitor) şi o parte de atribute repetitive sau multivaloare, reprezentate practic de rândurile din factură corespunzătoare produselor livrate (cumpărate). Grupând atributele repetitive într-un tip de entitate, rezultă ca urmare, 2 tipuri de entităţi, şi anume:

Factura, cu primele atribute: Nr factură, data facturii, cod furnizor, banca furnizor, cont furnizor (plătitor);

Rânduri factură, cu datele despre produsele vândute: cod produs, denumire produs, preţ unitar, cantitate vândută.Analizând mai atent cea de-a doua entitate, se vede că produsul este de fapt un obiect al problemei de modelat, căruia trebuie să-i corespundă un tip de entitate distinct şi anume Produse (Cod produs, denumire, caracteristici).

Observaţie: În modelul relaţional, entităţile devin tabele. Pentru fiecare entitate este necesar

să se realizeze o descriere detaliată, cât mai completă.Într-un model relaţional, nu pot să existe două entităţi cu acelaşi nume sau o

entitate cu nume diferite. O entitate se identifică unic print-un identificator, numit cheie primară, care face astfel distincţie între valori diferite ale entităţii.

Se ştie că în lumea care ne înconjoară obiectele, deci şi entităţile care le modelează, sunt în legătură unele cu altele, se influenţează sau se condiţionează reciproc. În procesul modelării aceste legături sunt reprezentate prin noţiunea de asociere sau relaţie.

O relaţie este o asociere semnificativă, bi-direcţională, între două entităţi sau între două instanţe diferite ale aceleeaşi entităţi.

Când luăm în considerare o relaţie, trebuie să o privim în ambele sensuri. De exemplu, un curs are o relaţie cu un profesor şi un profesor are o relaţie cu un curs:

52

•Un curs poate fi proiectat de un profesor.•Un profesor poate preda un curs.Asocierea (relaţia) se defineşte astfel ca o reprezentare a legăturii sau

corespondenţei existente între două sau mai multe realizări de entităţi şi a rolului pe care îl joacă fiecare entitate participantă la legătură. O asociere nu are existenţă de sine stătătoare, ea depinde de existenţa realizărilor de entităţi pe care le leagă; ca urmare, asocierea nu are identificatori specifici.

O asociere poate avea atribute proprii, cu scopul de a caracteriza legătura dintre entităţile participante la asociere. Entităţile care participă la o asociere constituie colecţia acesteia.

Numărul de entităţi care participă la o asociere formează dimensiunea sau gradul acesteia (mai mare sau egală cu numărul de entităţi al colecţiei).

Se numeşte tip de asociere ansamblul legăturilor care prezintă aceeaşi semnificaţie dintre două sau mai multe entităţi.

Cardinalitatea cuplului entitate-asociere se defineşte ca o pereche de valori întregi, de forma (m,M) care exprimă modul de participare al realizărilor fiecărei entităţi la asociere, având următoarea semnificaţie:

- m – cardinalitate minimală – arată numărul minim de realizări ale legăturii care există pentru o realizare a entităţii;

- M – cardinalitate maximală – arată numărul maxim de realizări ale legăturii care pot exista pentru o realizare a entităţii.

Cele două cardinalităţi au valori uzuale: 0,1; 1,1; 0,n; 1,n .Astfel, cardinalitatea minimală 0 arată că pot exista entităţi care să nu participe

la nici o asociere (legătură).Exemplu:

Interpretare: Un client poate exista chiar dacă nu a emis nici o comandă. Orice comandă însă trebuie emisă de un client.

Cardinalitatea minimală 1 arată că toate realizările tipului de entitate trebuie să participe la o realizare a tipului de asociere.

Din exemplul anterior: Orice comandă trebuie să fie emisă de un client. Cardinalitatea maximală 1 arată că numărul maxim de apariţii ale asocierii

care poate exista pentru o realizare a entităţii este 1.Din exemplul anterior: O comandă poate să fie emisă de un singur client (cel

mult unul). Odată ce a fost emisă, clientul nu mai poate fi schimbat.

53

CLIENT COMENZI Emite

0,n 1,1

Cardinalitatea maximală n arată că mai multe entităţi ale unui anumit tip participă la o asociere; în acest caz se poate chiar preciza uneori valoarea lui n.

Observaţie:Cardinalitatea minimă reprezintă deci acea regulă care specifică dacă o relaţie

trebuie să existe pentru toate instanţele unei entităţi (sau nu). Ea mai este cunoscută sub numele de Opţionalitate (relaţia este opţională). Dacă identificăm o relaţie cu gradul 0, atunci ea este o relaţie opţională.

Cardinalitatea maximă reprezintă acea regulă care precizează câte relaţii de acelaşi tip pot exista: una singură sau mai multe. Ea mai este cunoscută sub numele de Grad.

Între realizările aceloraşi entităţi pot exista mai multe asocieri diferite, cu semantică şi cardinalităţi distincte.

Se numeşte rolul entităţii un nume care serveşte pentru a desemna participarea entităţii la o asociere.

Exemplu:Dacă ne referim la o entitate Angajat, identificată dacă analizăm activitatea

compartimentului (sau funcţiei) de resurse umane din cadrul unei societăţi comerciale, atunci ea poate să fie descrisă cu atributele: Nume, marcă, functie, compartiment, salariu de încadrare, data angajării, domiciliul, localitatea, CNP, sex, telefon,etc. Compartimentul constituie însă un alt obiect relevant al problemei, deci o entitate cu atributele sale: cod şi denumire. Între cele două entităţi se stabileşte o relaţie (asociere), fiecare angajat fiind încadrat într-un compartiment, la o anumită dată.

54

Interpretarea cardinalităţilor :În primul exemplu, cardinalitatea (1,1) arată că fiecare angajat este încadrat

neapărat la un compartiment şi la cel mult unul; cardinalitatea (o,n) privită din partea entităţii Compartiment arată că un compartiment poate exista structural fără a avea vreun angajat, dar poate avea (cel mult) n angajaţi.

În exemplul 2, cardinalitatea (0,1) arată că există angajaţi care nu conduc nici un compartiment, iar cea maximală egală cu 1 arată că un angajat conduce cel mult un compartiment. Privită dinspre entitatea Compartiment, cardinalitatea (1,1) arată că fiecare compartiment este condus de un angajat şi cel mult unul.

În funcţie de numărul de tipuri de entităţi care participă la o asociere, aceasta poate fi: reflexivă (unară), binară sau complexă.

Se numeşte Asociere reflexivă o asociere care leagă realizări diferite ale aceleiaşi entităţi (colecţie = 1). În aceste cazuri, este indispensabilă specificarea în schemă a rolurilor jucate de entitate.

Exemplu:

Deci, în cadrul entităţii Angajat, există persoane căsătorite cu persoane din aceeaşi colectivitate (entitate), fiecare jucând rolul său (soţ sau soţie).

Se numeşte Asociere binară o asociere care leagă realizări aparţinând la două tipuri de entităţi diferite (colecţie = 2). Aşa a fost cazul asocierii prezentate între entităţile Angajat şi Compartiment.

55

Se numeşte Asociere complexă (ternară) o asociere care leagă realizări aparţinând la mai multe tipuri de entităţi diferite (colecţie >= 3). În acest caz se impune descompunerea asocierii complexe în asocieri binare.

Exemple de entităţi şi asocieri care se constituie practic ca fragmente ale unui viitor model Entitate Asociere:

Este vorba despre o dispoziţie de livrare a unui/unor produse, de clienţi care îşi deschid un depozit la o bancă sau de contribuabili care au câte un rol deschis la Administraţia Financiară.

3.2 Modelul entitate – asociere (MEA)3.2.1. Prezentare generală

Procesul de descriere a entităţilor şi a asocierilor se numeşte modelare şi este realizat cu ajutorul unui model de date.

Modelarea unei baze de date permite trecerea de la percepţia unor fapte din lumea reală la reprezentarea lor prin date. Modelul de date trebuie să reflecte fidel

56

fenomenele lumii reale, să urmărească evoluţia acestei lumi şi comunicarea între fenomenele sale.

Modelul entitate – asociere (MEA) nu este un simplu model teoretic de reprezentare a datelor, ci reprezintă un model neformalizat pentru reprezentarea unor fenomene, a unui sistem din lumea reală. El devine astfel un instrument de lucru şi de comunicare între proiectanţii unei aplicaţii informatice. Scopul lui este de a stabili entităţile de date (obiectele despre care se impune stocarea datelor) şi relaţiile care există între acestea. Pentru reprezentarea grafică a modelului entitate-asociere este utilizată adeseori Diagrama entitate-asociere (DEA).

Modelul E/A împarte elementele unui sistem real în două categorii: Entităţi Legături (asocieri) între entităţiEntitatea reprezintă: o persoană, un loc, un concept, o activitate sau eveniment

care este semnificativ pentru ceea ce modelăm. În modelul relaţional, entităţile devin tabele. Pentru fiecare entitate este obligatoriu să dăm un nume şi o descriere detaliată. Într-un model relaţional, nu pot să existe două entităţi cu acelaşi nume sau o entitate cu nume diferite. O entitate se identifică unic printr-un identificator care face distincţie între valori diferite ale entităţii; acesta devine în modelul relaţional cheie primară.

Entităţile nu pot exista în mod izolat. Fiecare entitate trebuie să fie legată de cel puţin o altă entitate printr-o relaţie.

Relaţia (asocierea) reprezintă o comunicare între două sau mai multe entităţi, un raport care există între ele. O valoare a unei relaţii este o comunicare între valorile entităţilor care le leagă. De regulă relaţiile se exprimă prin verbe şi se pot simboliza printr-un cerc sau romb.

Alteori, în reprezentarea grafică lipseşte rombul sau cercul şi apare o linie cu vârf simplu de săgeată pentru cardinalitate 1 sau linie cu vârf dublu de săgeată pentru cardinalitate n.

P Chen, considerat creatorul modelului EA, utilizează rombul pentru a specifica asocierea şi caracterele 1,0 sau m pentru tipul asocierii (plasate chiar pe linia ce leagă entitatea de asociere).

De exemplu:

57

R. G. Ros utilizează tot rombul pentru reprezentarea asocierii, dar pentru redarea tipului ei foloseşte săgeata cu vârf unic pentru 1 şi cu vârf dublu pentru n.

Aceleaşi exemple devin acum reprezentate astfel:

3.2.2. Tipuri de relaţii

a). Relaţii (mai) Mulţi-la-UnuAcestea sunt cele mai comune şi arată că o relaţie are un grad de unu sau mai

mulţi într-o direcţie şi unul singur în cealaltă direcţie. O astfel de relaţie este privită ca o relaţie părinte - copil sau master – slave.

Majoritatea relaţiilor de tip mulţi-la-unu au entităţi copil opţionale şi entităţi părinte obligatorii, ceea ce înseamnă că un exemplar de părinte poate exista fără a fi asociat cu copilul, dar copilul nu poate exista fără părintele său.

Aceasta înseamnă că entitatea părinte trebuie creată prima, după care sunt asociate şi entităţile copii.

Observaţie:În cazul unei relaţii mulţi-la-unu complet opţionale, oricare dintre cele două

entităţi – părinte sau copil – poate fi creată prima.Relaţiile mulţi-la-unu care sunt obligatorii la ambele capete sunt foarte rare şi

semnifică faptul că o entitate nu poate exista fără cealaltă.

b). Relaţii (mai) Mulţi-la-(mai) MulţiReprezintă un tip de relaţii foarte întâlnite îndeosebi în stadiul de creare a unui

model şi au un grad de unul sau mai mulţi în ambele direcţii. Majoritatea relaţiilor mulţi-la-mulţi sunt opţionale în ambele direcţii, ceea ce

înseamnă că un exemplar din fiecare poate să existe fără nici o asociere. Practic aceasta înseamnă că fiecare entitate poate fi creată, iar asocierea poate fi adăugată mai târziu.

Observaţie:Relaţiile mulţi-la-mulţi care sunt obligatorii la ambele capete sunt foarte rare,

ceea ce impune ca instanţele ambelor entităţi să fie create simultan.

58

O relaţie de tipul mulţi-la-mulţi se tratează prin descompunerea în două relaţii de tip mulţi-la-unu, astfel:

- Se identifică şi se crează o nouă entitate.- Se transformă entitatea nou creată într-o entitate de detaliu pentru celelalte

două entităţi.- Se transformă relaţia mulţi-la-mulţi în două relaţii mulţi-la-unu cu noua

entitate la capătul mulţi, ca detaliu. Relaţiile cu entitatea de intersecţie sunt obligatorii.

Dacă identificăm o entitate de intersecţie şi nu există atribute pentru ea, atunci înseamnă că ea reprezintă doar o listă de referinţe încrucişate între instanţele entităţilor; ea devine astfel o excepţie de la regula care spune că toate entităţile trebuie să aibă atribute. Entităţile de intersecţie conţin de obicei informaţii temporale precum cantităţi şi date.

c). Relaţii de tip Unu-la-UnuSe caracterizează printr-un grad de unul singur în ambele direcţii. Relaţiile de

Unu-la-Unu sunt destul de rare, ele arătând că cele două entităţi sunt de fapt una şi aceeaşi în cadrul modelului.

Notaţia uzuală reprezintă tipul de asociere 1 la mulţi printr-o linie cu terminaţie în formă de laba gâştei:

Relaţia de tip 1 la 1 se reprezintă printr-o linie dreaptă simplă:

Observaţie:Pentru a denumi o relaţie vom alege un nume semnificativ în contextul

problemei de modelat. Numele relaţiilor sunt adeseori perechi, cum ar fi:conduce – şi – condus;cumpărat de la – şi – furnizat de;reprezentat de – şi – reprezentant al;responsabil pentru – şi – responsabilitatea lui.

Pentru a crea o relaţie trebuie parcurşi următorii paşi, în ambele direcţii ale acesteia:

• Se stabileşte existenţa relaţiei.• Se stabileşte numele relaţiei.• Se determină gradul relaţiei.• Se determină opţionalitatea relaţiei.• Se modelează relaţia.• Se validează relaţia prin citire.Un model al relaţiilor între entităţi va putea fi pus apoi în orice format fizic, ca

de exemplu:•Bază de date ierarhică•Bază de date tip reţea

59

•Bază de date relaţională•Fişiere clasice

Observaţie:Modelarea conceptuală a datelor ar trebui să fie independentă de platforma

hardware şi software existente pentru implementare. Aceast lucru ne permite să avem o privire obiectivă asupra cerinţelor informaţionale şi de prelucrare ale problemei abordate, fără a avea constrângeri legate de dotarea firmei.

O modelare corectă a datelor va permite implementarea cererilor în medii diferite. Dacă mediul trebuie schimbat după implementare, modelul original va fi uşor aplicat noului mediu.

3.3. Restricţii de integritate

Modelarea conceptuală a datelor este un proces de documentare a cerinţelor informaţionale ale problemei de rezolvat, concretizată pe de o parte în identificarea structurii datelor, pe de alta în stabilirea regulilor prin care se câştigă încrederea în integritatea acestora.

Astfel, cerinţele pe care datele trebuie să le respecte pentru a fi corecte şi coerente în raport cu realitatea pe care o reprezintă se numesc restricţii de integritate. Acestea se referă la:

Integritatea entităţiiFiecare instanţă a entităţii trebuie să aibă un identificator unic, adică o cheie

primară a cărei valoare nu poate fi valoarea Null. Identificarea unei entităţi se realizează cu atributele proprii, împreună eventual cu rolurile jucate de alte tipuri de entităţi.

Problemă: Analizaţi în acest sens entităţile Angajat şi Pontaj identificate în cadrul compartimentului de retribuire resurse umane.

DomeniiAceste restricţii privesc valorile pe care le pot lua atributele entităţilor,

eventualele corelaţii care trebuie să existe între acestea. Ele se pot referi la realizările unor atribute care aparţin aceleeaşi entităţi sau asocieri şi se numesc restricţii intraentitate, sau a unor atribute aparţinând la entităţi sau asocieri diferite, caz în care se numesc restricţii interentitate. Prin precizarea domeniului se stabilesc de regulă următoarele caracteristici ale atributelor:

-tipul datei;-lungimea;-formatul;-semnificaţia;-formatul;-dacă se acceptă valoarea nul sau nu;

60

-intervalul de valori admise.Prin aceste restricţii datele sunt validate, asigurându-se astfel încrederea în

operaţiunile executate şi uşurinţă în manipularea datelor.Problemă : Daţi exemple de :- corelaţii între valorile mai multor atribute ale aceleeaşi entităţi sau asocieri; - corelaţii între atributele mai multor entităţi sau asocieri diferite; - corelaţii cu valori obţinute pe baza unor operaţii de sintetizare (numărare,

însumare, medie etc) a unui ansamblu de entităţi.

Rolurile jucate de entităţi în cadrul asocierilor Un alt tip de restricţii de integritate stabilesc condiţii ce trebuie îndeplinite de

rolurile jucate de un tip de entitate în diverse asocieri, cum ar fi incluziunea, egalitatea şi excluziunea de roluri.

Incluziunea: Dacă o entitate E care joacă un rol r1 într-o asociere a1 va juca neapărat şi rolul r2 într-o asociere a2, atunci spunem că rolul r1 include sau implică prin incluziune rolul r2.

Notaţia grafică:

Exemplu: Un client al băncii depune o cerere pentru a primi un credit. Aceasta este

analizată şi, dacă este aprobată, clientul primeşte creditul. Se impune observaţia că el poate beneficia de credit numai dacă a depus o

cerere pentru acesta. Spunem că între rolurile primeşte şi depune ale aceluiaşi client există o restricţie de incluziune.

Faptul că un client al băncii depune o cerere pentru un credit nu implică şi acordarea creditului, dar acordarea acestuia implică întotdeauna existenţa cererii corespunzătoare.

61

R1R1 R2R2I

Observaţie: RI de incluziune este redundantă atunci când cardinalitatea minimală a rolului indus este mai mare de zero (analizată ® depusă în exemplul nostru).

Problemă: Analizaţi în mod asemănător cazul unei facturi achitate pentru marfa de pe un document NIR (Notă de Intrare Recepţie). Identificaţi incluziunea de roluri şi explicaţi.

Egalitatea: Egalitatea de roluri presupune că restricţia de incluziune între rolurile r1 si r2 ale unei entităţi este reciprocă. Aceasta înseamnă că rolul r1 jucat de entitatea E în asocierea a1 determină rolul r2 jucat de aceeaşi entitate în asocierea a2 şi invers.

Notaţia grafică:

Exemplu: Dacă mergem mai departe cu exemplul nostru de mai sus, atunci putem spune

că orice client care este beneficiarul unui credit trebuie să constituie o garanţie pentru acesta şi, invers, constituirea unei garanţii de către un client se face atunci când acesta primeşte un credit (considerăm cazul unui credit care impune constituirea unei garanţii).

Excluziunea: Rolul r1 jucat de o entitate E în asocierea a1 exclude existenţa rolului r2 jucat de aceeaşi entitate în asocierea a2. Notaţie grafică:

Exemplu:Dacă ne gândim la un apartament proprietate particulară, putem spune că

acesta nu poate să aparţină simultan unei persoane fizice şi unei persoane juridice.

62

R1R1 R2R2=

R1R1 R2R2#

Problemă: Analizaţi în mod similar, entitatea factură, ştiind că o societate poate primi o factură de la furnizori pentru plata produselor cumpărate sau poate emite factură către clienţi pentru plata produselor/serviciilor livrate.

Reguli de stabilire a asocierilor dintre entităţiAcest set de restricţii numite restricţii de integritate pe asocieri se referă la

tipul de asociere, la rolurile determinate de asociere şi anume: incluziune, egalitate şi excluziune de asocieri. Ele vizează deci asocierea şi toate entităţile participante la ea.

Incluziunea de asocieri: Dacă o asociere A1 dintre 2 entităţi va determina asocierea A2 în cadrul modelului EA, atunci aocierea A1 include A2.

Analizând exemplul nostru de mai sus, un client care a primit un credit începe să plătească ratele, care în timp vor stinge creditul.

Problemă: Analizaţi, pentru o firmă de distribuţie produse pe bază de comenzi, tipul asocierilor şi restricţiile de integritate a acestora.

Se precizează că orice produs livrat trebuie să corespundă unui produs comandat. Deasemenea, unei comenzi îi pot corespunde mai multe livrări diferite.

Egalitatea de asocieri arată că asocierile de tip A1 determină asocierile de tip A2 şi invers. De exemplu, în cazul unui cititor de la o bibliotecă, fiecărui împrumut făcut trebuie să-i corespundă o restituire şi invers, fiecărei restituiri trebuie să-i corespundă un împrumut. Reprezentând grafic aceste asocieri, se obţine :

63

Excluziunea de asocieri: Dacă o asociere A1 dintre 2 entităţi exclude asocierea A2 în cadrul modelului EA, atunci aocierea A1 exclude A2.

De exemplu, într-o tranzacţie imobiliară, clientul firmei imobiliare vinde sau cumpără un bun imobiliar (casă, vilă, apartament sau teren).

Problemă: Analizaţi mişcările înregistrate de materiale într-o gestiune de materiale, ştiind că documentul poate fi de intrare (NIR) sau de ieşire din gestiune (BC), determinând în mod corespunzător creşterea sau micşorarea stocului existent.

3.4. Dependenţe funcţionale3.4.1.Caracteristici de bază

Se numeşte dependenţă funcţională o relaţie între două atribute, dintre care unul este determinant şi celălalt este determinat, ambele atribute aparţinând aceleeaşi entităţi.

Exemplu:Marcă Nume angajatCod numeric personal Nume persoanăCod produs Denumire produsAceasta înseamnă că fiecărei realizări a atributului determinant îi va

corespunde întotdeauna aceeaşi realizare (valoare) a atributului determinat. Unei anumite mărci îi va corespunde acelaşi nume, unui anumit cod numeric personal acelaşi nume de persoană, unui cod produs aceeaşi denumire.

Dacă vorbim de o dependenţă funcţională X® Y , unde X şi Y sunt atribute ale unei entităţi, atunci pentru realizări ale entităţii care au aceleaşi valori pentru X există aceleaşi valori ale atributului Y.

Determinantul poate fi compus din unul sau mai multe atribute. De exemplu, dacă ne referim la activitatea de desfacere a unei firme, se ştie că

preţul unitar de vânzare este determinat de tipul produsului şi de numele clientului (beneficiarului), deoarece acelaşi produs se poate vinde la preţuri diferite la

64

clienţi diferiţi (se acordă discount pentru cantitatea cumpărată, pentru fidelitatea clientului, etc) .

Deci, Cod produs,Cod client®Preţ vânzare.O dependenţă funcţională X® Y se numeşte elementară dacă pentru orice

X1 strict inclus în X, dependenţa funcţională X1 ®Y nu este adevărată.

Între două atribute X şi Y există o dependenţă funcţională multivaloare (DFM), notată:

X®®Y dacă o valoare a lui X determină mai multe valori pentru Y. De exemplu, un anumit zbor al unei companii aeriene se efectuează în mai

multe zile din saptămână (luni, vineri, duminica). Nr zbor ®® Zi săptămână

În contextul modelului EA, DFM corespunde existenţei atributelor repetitive sau multivaloare. De regulă acest tip de DF se întâlneşte atunci când entitatea are cel puţin trei atribute notate X,Y şi Z între care se stabilesc următoarele dependenţe: X®®Y, X®®Z, dar Y şi Z sunt independente.

X®Y se numeşte dependenţă funcţională completă dacă Y este dependent funcţional de X şi nu este dependent de nici o componentă a lui X.

În mod asemănător, X®Y se numeşte dependenţă funcţională parţială dacă Y este dependent funcţional atât de X cât şi de părţi ale acestuia.

Dacă însă Y X atunci dependenţa funcţională se numeşte trivială.X®Z se numeşte dependenţă funcţională tranzitivă dacă X®Y şi Y®Z şi Y

nu determină pe X. De exemplu, analizând o factură, pot fi identificate următoarele dependenţe

funcţionale:1. Nr factură ® Cod furnizor2. Nr factură®Data3. Nr factură ®Cod produs4. Cod produs®Cantitate vândută5. Nr factură®Cantitate vândută Dependenţa 4 este însă tranzitivă, corespunzând definiţiei date.

Proprietăţi ale dependenţelor funcţionale:

Reflexivitatea: X®X.

Exemplu: Marca ® Marca Dezvoltarea:

Dacă X®Y atunci este valabilă şi X,Z®Y. Exemplu: Marca ® Nume angajat

Marca, Localitate® Nume angajat

65

Tranzitivitatea:Dacă X®Y şi Y®Z atunci X®Z.

Exemplu: Marca ® Localitate, Localitate ® Judeţ Marca ® Judeţ

Aditivitatea:Dacă X®Y şi X®Z atunci X®Y,Z.

Exemplu: Marca ® Nume angajat, Marca ® Adresă angajat Marca ® Nume angajat, Adresă angajat

Proiecţia:Dacă X®Y,Z atunci X®Y şi X®Z.

Exemplu: Marca ® Nume angajat, Adresă angajat Marca ® Nume angajat, Marca ® Adresă angajat

Pseudo-tranzitivitatea:Dacă X®Y şi W,Y®Z atunci X,W®Z.

Exemplu: Marca angajat ® Compartiment; Compartiment, Funcţie ® Indemnizaţie conducere

Marca angajat, Funcţie ® Indemnizaţie conducere

Observaţie:Cardinalităţile 1,1 corespund întotdeauna unor dependenţe funcţionale.Dependenţele funcţionale reprezintă restricţii de integritate. Identificatorul unei entităţi este un atribut sau un grup de atribute faţă de care

toate celelate atribute sunt dependente funcţional. Dependenţele funcţionale pot exista şi între entităţi şi asocieri.

3.4.2. Studiul dependenţelor funcţionale

Studiul dependenţelor funcţionale se poate realiza cu ajutorul unor instrumente specifice, dintre care amintim: matricea dependenţelor funcţionale şi diagrama dependenţelor funcţionale.

A). Matricea dependenţelor funcţionale

Acest instrument de analiză a structurii datelor, deosebit de util, reprezintă practic un tablou în care pe coloane se trec atributele cu rol de determinanţi ai dependenţelor funcţionale, iar pe linii toate atributele identificate în procesul modelării datelor.

Matricea poate fi elaborată în două formate şi anume: matricea simplificată, care cuprinde pe coloane doar determinanţii dependenţelor funcţionale, şi matricea completă, construită cu un număr egal de linii şi coloane (care cuprinde

66

şi pe coloane toate atributele identificate, nu numai pe cele cu rol de determinanţi).

La intersecţia unei linii cu o coloană, acolo unde există o dependenţă funcţională între atributul cu rol de determinant din coloană şi atributul înscris în linia respectivă, se va înscrie valoarea 1. Existenţa mai multor valori de 1 pe o linie pun în evidenţă dependenţe funcţionale tranzitive datorate unor asocieri ierarhice (numite restricţii de integritate funcţională) sau necesitatea unei analize în vederea stabilirii corecte a determinantului dependenţelor funcţionale descrise.

Se ştie că într-un model entitate-asociere atributele sunt unice, ceea ce înseamnă că un atribut trebuie să aparţină unei singure entităţi (sau asocieri). În funcţie de dependenţa funcţională la care atributul respectiv participă în legătura cu identificatorul tipului de entitate, el va fi plasat într-o anume entitate.

Exemplu de matrice simplificată pentru evidenţa automată a activităţii de spitalizare a pacienţilor.

Se pot identifica entităţile: medici, pacienţi, secţii, saloane, medicamente. Reprezentând MDF se obţine :

Analizând matricea, se observă că pe linia Cod secţie există două valori de 1, iar pe cea de număr salon trei valori de 1, arătând că există dependenţe tranzitive. Se impune crearea unor noi entităţi, astfel încât să fie eliminate aceste anomalii. În acest caz se crează o entitate nouă, Internaţi, cu atributele: Cod internat, cod medic, cod secţie, număr salon, data internării.

Atribute Determinanţi1 3 7 9 1+3+9

1.Cod medic 1*

2.Nume medic 1

Atribute Determinanţi1 3 7 9 9+3 1+7

1.Cod medic 1*

2.Nume medic 13.Cod pacient 1*

4.Nume pacient 15.Adresa 16.Act identitate 17.Cod secţie 1 1*

8.Denumire secţie 19. Număr salon 1 1 1*

10.Capacitate salon 111Data intrării 1 1

67

3.Cod pacient 1*

4.Nume pacient 15.Adresa 16.Act identitate 17.Cod secţie 1*

8.Denumire secţie 19. Număr salon 1*

10.Capacitate salon 111Data internării 112.Cod Internat 1*

13 Data internării 1În urma unei analize riguroase a matricei simplificată sau complexă, se vor

defini deci tipuri de entităţi optimizate, în care să nu mai existe decât dependenţe funcţionale corecte (elementare sau neelementare).

B). Diagrama dependenţelor funcţionaleDiagrama dependenţelor funcţionale serveşte pentru reprezentarea grafică a

modelului de date sub forma unui graf, care se construieşte începând cu dependenţele funcţionale identificate. Apoi, pe baza acestora, se pot defini entităţile modelului Entitate-Asociere, astfel încât să nu existe dependenţe funcţionale complexe între ele.

Practic, luând în considerare toate atributele identificate în cadrul problemei de rezolvat, identificăm dependenţele funcţionale şi apoi le grupăm în cadrul diagramei în funcţie de determinanţi. În cadrul diagramei sunt puse în evidenţă dependenţele funcţionale tranzitive, care vor trebui apoi eliminate.

C). Reguli pentru trecerea de la diagrama dependenţelor funcţionale la modelul Entitate-Asociere.

- Pentru fiecare dependenţă funcţională în care determinantul este elementar se va crea un tip de entitate în care determinantul respectiv va avea rol de identificator. Ex. Cod medic, Nume - se va crea entitatea Medici cu identificatorul Cod medic.

- Toate atributele care au acelaşi determinant în cadrul dependenţelor funcţionale vor fi grupate în acelaşi tip de entitate, având ca identificator atributul cu rol de determinant în cadrul dependenţelor funcţionale

- Fiecare dependenţă funcţională dintre identificatorii tipurilor de entităţi va avea corespondent, în cadrul modelului entitate-asociere, un tip de asociere.

- Pentru fiecare dependenţă funcţională neelementară, deci care are determinantul format din mai multe atribute, se crează un tip de asociere

68

neierarhică, definită prin atributul care are rol determinant în cadrul dependenţei funcţionale.

Respectând aceste reguli şi realizând încă o dată matricea dependenţelor funcţionale se poate observa că, pe fiecare linie a acesteia a rămas înscrisă o singură valoare de 1, ceea ce înseamnă că fiecare atribut are un singur determinant.

3.5. Alte forme ale MEA

Un model entitate asociere poate fi dezvoltat ulterior, funcţie de condiţiile concrete ale problemei date, prin:

- generalizare sau definire de supertipuri;- specializare sau definire de subtipuri;- introducerea timpului şi crearea unui model temporal.Astfel, prin generalizare se grupează, în cadrul modelului EA, caracteristicile

comune într-un supertip de entitate, în timp ce elementele de descriere specifice sunt grupate în subtipuri de entităţi. Ca exemplu, putem considera cazul documentelor care circulă în cadrul compartimentului financiar-contabilitate şi înregistrează diverse operaţii ce se execută aici, cum ar fi: factura, ca document care însoţeşte o intrare de produse şi ordinul de plată, ca document de plată a facturii respective (care se presupune că a fost confirmată şi acceptată la plată).

Se ştie că o factură cuprinde informaţii despre:- număr factură (document);- data facturii;- unitatea beneficiară (denumire, banca şi cont);- unitatea furnizoare (denumire, bancă şi cont);- rândurile facturii, cu date despre produsele livrate, cantitatea şi preţul

acestora, valori calculate pentru Tva şi total.În mod similar, un ordin de plată conţine în prima parte informaţii despre:- numărul ordinului de plată (document);- data documentului;- unitatea beneficiară (denumire, banca şi cont);- unitatea plătitoare (denumire, bancă şi cont);- suma şi obiectul supus plăţii.Prin generalizare, caracteristicile comune oricărui document care formează

practic antetul acestuia, şi anume: numărul, data, beneficiarul şi emitentul pot fi grupate într-un supertip, numit Document, urmând ca datele din conţinutul acestora (rândurile documentului) să formeze subtipuri sau subclase de entităţi (rând factură). În mod firesc, subclasele moştenesc atributele supertipului, iar atributele supertipului nu aparţin subtipului.

69

În practică sunt numeroase astfel de cazuri, când în ansamblul entităţilor care aparţin unui anumit tip există subgrupuri cu o anumită relevanţă pentru realitatea reflectată şi ca urmare, trebuie reprezentate explicit.

Aceste grupuri de entităţi se numesc subclase ale tipului, acesta fiind, la rândul sau, superclasa acestora.

Ca exemplu, entităţile aparţinând tipului ANGAJAT pot fi grupate în muncitor, tehnician, inginer, economist etc. Fiecare entitate a unui asemenea grup este, în acelaşi timp, o entitate a tipului ANGAJAT, care ne apare astfel ca o superclasă.

Definirea unor subclase se poate face în principal, astfel: -pe baza valorilor unui anumit atribut ; -pe baza unor criterii definite de utilizator.

Prin definirea de subclase se efectuează specializarea entităţilor superclasei acestora (Angajat). Acestea moştenesc toate atributele superclasei şi pot avea atribute proprii specifice, inexistente la nivelul superclasei.

În cazul exemplului nostru, în subclasele Muncitor şi Economist ale superclasei Angajat dintr-o societate, pe lângă atributele comune, specifice oricărui angajat (Marca, Nume, Loc de muncă, Data naşterii, etc), pentru muncitori pot exista, suplimentar, atributele specifice Meserie şi Calificare iar pentru economişti atributul Specialitate.

Reprezentând grafic modelul nostru, se obţine:

Se poate observa existenţa unor asocieri Subtip, în care cardinalitatea subtipurilor este 1,1 iar a supertipului (superclasei) este 0,1.

Generalizarea ne apare astfel ca procesul invers, prin care două sau mai multe tipuri de entităţi sunt generalizate, pe baza proprietăţilor comune, într-un nou tip. În această relaţie, tipurile iniţiale devin subtipuri ale tipului obţinut prin generalizare (Angajat). Dacă ne gândim la o universitate, tipurile de entităţi Angajat şi Student pot fi generalizate prin tipul PERSOANA, care va prelua astfel atributele comune ale acestora: Nume, Prenume, Data naşterii, Adresa, Telefon, Domiciliu, Cod Numeric Personal, etc.

70

Modalitatea de lucru adoptată în mod concret – specializare sau generalizare – depinde de cerinţele unei reprezentări cât mai corecte a realităţii, dar şi de experienţa şi stilul de lucru al echipei de proiectare a noului sistem.

Se impune precizarea că specializarea poate fi totală, ceea ce înseamnă că orice entitate a tipului face parte, obligatoriu, dintr-un subtip, sau parţială, însemnând că pot exista entităţi care să nu aparţină nici unui subtip.

În exemplul nostru specializarea este parţială deoarece există şi alţi angajaţi în afara muncitorilor şi economiştilor. Aceasta este o restricţie de integritate specifică. În schimb generalizarea, obţinându-se prin gruparea tipurilor de entităţi deja existente, nu poate fi decât totală.

Între subtipuri poate exista un raport de excluziune, ceea ce înseamnă că fiecare entitate poate să aparţină unui singur subtip (în exemplul nostru persoana ori este angajat ori este student). Există însă şi cazuri în care aceeaşi entitate poate aparţine mai multor subtipuri diferite (altfel spus submulţimile entităţilor care aparţin subclaselor respective nu sunt disjuncte). Această RI este reprezentată grafic prin intermediul simbolului de excluziune. În cazul în care nu există exclusivitate, este posibilă existenţa unei RI de incluziune, care să precizeze condiţiile în care are loc "suprapunerea" entităţilor care aparţin fiecărui subtip.

De exemplu, dacă Economist şi Cadre de conducere sunt subtipuri ale tipului de entitate ANGAJATI, se poate formula o restricţie de incluziune de forma: pot fi cadre de conducere (la nivel mediu sau strategic) numai angajaţii economişti.

Cele doua restricţii de integritate sunt total independente.Introducerea de subtipuri prin specializare şi/sau generalizare prezintă avantaje

legate de faptul că grupează proprietăţile comune la nivelul tipului (superclasei) şi permite o reprezentare mult mai clară a unor tipuri de asocieri la care participă numai o parte dintre entităţi.

Un model EA de această formă necesită introducerea unor restricţii de integritate cum ar fi:

- dacă pentru un angajat Specialitate nu este Economist, atunci el nu poate juca rolul component-în;

Un anumit tip de entitate poate face obiectul mai multor specializări diferite, dacă aceasta prezintă semnificaţie pentru problema modelată. De exemplu, un bun

71

oferit pentru o firmă imobiliară poate fi oferit spre vânzare sau închiriere, şi, la rândul său, poate fi apartament, vilă (casă) sau teren.

Timpul în cadrul MEAModelarea EA nu posedă formalisme specifice pentru aspectul temporal.

Totuşi, timpul este frecvent în numeroase probleme, cel mai adesea sub forma datei calendaristice. Astfel, reprezentarea sa este aceeaşi atât pentru entităţi cu caracter permanent cum ar fi de exemplu, nomenclatoarele de clienţi, produse, angajaţi etc. cât şi pentru cele cu caracter aleator, care au semnificaţia unei schimbări, modificări, asocieri produse la un moment dat, cum ar fi cele cu privire la facturi, plaţi, încasări etc.

Reprezentarea evenimentelor cu caracter aleator nu prezintă probleme deoarece, prin definiţie, acestea au o dată la care se produc. În activitatea curentă de gestiune operativă acestea sunt reflectate în documente care au numere unice ca identificatori, astfel că data apare ca un simplu atribut. De exemplu, o comandă, o factură, o plată vor fi identificate prin numărul documentului în care sunt consemnate şi vor avea un atribut care să specifice data producerii lor (data comenzii, data facturării, data plăţii).

O problemă deosebită o ridică însă asocierile repetitive sau de scurtă durată care apar între entităţile stabile. De exemplu, asocierea care apare între un student şi facultatea la care învaţă. O soluţie ar putea fi cea reprezentată în schema de mai jos, care prezintă însă dezavantajul de a nu arata decât ultima facultate a fiecărui student. În cazul în care un student se transferă de la o facultate la alta (problema fiind similară şi la trecerea de la o grupă la alta), asocierea corespunzătoare noului loc de studiu o va înlocui pe cea anterioară, deci vechea facultate va fi uitată.

Se pune însă întrebarea ce se întâmplă dacă trebuie să se cunoască în orice moment toate facultăţile la care a studiat un student ?

În acest sens se poate introduce un nou tip de asociere între cele două entităţi pentru a indica facultăţile anterioare. Aceasta nu este însă o soluţie bună, căci realizările acesteia riscă să nu poată fi identificate: nimic nu împiedică un student să revină la o facultate la care a mai învăţat cândva, dar pe care a întrerupt-o. Aceasta înseamnă că aceeaşi pereche de valori "Marca, Cod facultate", care ar trebui să identifice fiecare asociere, apare de mai multe ori.

72

Pentru a rezolva problema aceasta de evidenţă, este posibilă fie introducerea unui nou tip de entitate DATA pentru reprezentarea timpului, ceea ce face ca Data calendaristică să completeze Marca şi Codul facultăţii în identificarea asocierilor, fie transformarea asocierii în entitate, aceasta având semnificaţia de istoric al facultăţilor la care a studiat fiecare student. În acest caz identificarea entităţilor ISTORIC-F se face prin atributul propriu Data inceperii şi prin rolurile entităţilor STUDENT şi FACULTATE.

Din analiza acestor exemple se pot trage câteva concluzii cu privire la reprezentarea timpului în cadrul modelului EA.

Astfel, o soluţie bună ar fi plasarea timpului sub formă de atribute în cadrul entităţilor sau a asocierilor corespunzătoare; dacă acest lucru nu e posibil, se poate introduce o entitate abstractă pentru reprezentarea timpului sau se transformă asocierea dintre entităţile durabile într-un nou tip de entitate care să reflecte derularea relaţiilor dintre acestea în timp (istoric).

O asemenea extensie introduce distincţia dintre "obiectele" conceptuale, echivalente entităţilor şi cele temporale.

73

Entităţile reprezintă deci obiecte persistente care, odată apărute, nu dispar niciodată. Obiectele temporale materializează rolurile active jucate de un obiect conceptual în timp.

De exemplu, o persoană este o entitate. De-a lungul vieţii sale, persoana a fost elev, apoi student şi apoi angajat. Aceste stări sunt reflectate prin entităţi temporale destincte.

Problemă: Analizaţi în mod similar necesitatea de evidenţă a angajaţilor unei firme pe

locuri de muncă (compartimente), ştiind că un angajat poate trece de la un loc de muncă la altul. În mod similar analizaţi problema de evidenţă a angajaţilor pe funcţii, ştiind că aceştia îşi schimbă funcţia în timp.

3.6. Reguli privind Modelarea Conceptuală a Datelor3.6.1. Reguli de validare a modelului

Criteriile de validare a modelului sunt reprezentate de cerinţele de informare ale conducerii. Modelarea datelor s-a realizat iniţial independent de cerinţele diferitelor aplicaţii, în principal pe baza proprietăţilor obiectelor identificate, independent de aplicaţiile care operează cu obiectele respective.

Este însă necesar să se verifice în ce măsură modelul conceptual al datelor satisface diferite aplicaţii, verificând practic completitudinea şi consistenţa sa. Se efectuează adăugările şi corelaţiile necesare, se verifică dacă relaţiile dintre entităţi sunt stabilite corect în vederea regăsirii informaţiilor din mai multe entităţi şi editării unor situaţii complexe cu date agregate, dacă modul în care au fost definite legăturile dintre entităţi asigură coerenţa informaţiilor din baza de date, actualizarea concomitentă a datelor redundante acceptate etc.

De exemplu, din legăturile N:1 (compartimente – intreprindere) şi 1:N (intreprindere – angajaţi) s-ar părea că legătura compartimente – angajatţi, prin intermediul intreprindere ar face posibilă determinarea angajaţilor care lucrează într-un anumit compartiment, ceea ce este fals.

Diagrama poate sugera existenţa unei legături între entităţi, fără să existe însă legături între anumite realizări ale entităţilor respective (pentru relaţiile parţiale).

În concluzie, prin verificarea modelului se poate impune rearanjarea anumitor componente ale modelului, adăugarea de relaţii suplimentare, definirea unor relaţii complexe care în final înseamnă introducerea de noi entităţi.

Există uneori tendinţa de a introduce în modelul de ansamblu al datelor mai multe legături decât este necesar, eventual chiar toate legăturile posibile. Acest lucru duce la creşterea nejustificată a complexităţii logice a modelului, a redundanţelor, la creşterea timpului de realizare a proiectului. De aceea,

74

introducerea unor noi relaţii sau entităţi în modelul conceptual de ansamblu trebuie făcută cu mulă atenţie şi numai atât cât este necesar.

Validarea unui MCD presupune deci o activitate care vizează pe de o parte elementele sale de construcţie, pe de alta completitudinea sa.

Pentru validarea unui model conceptual al datelor din punctul de vedere al construcţiei se impune respectarea unui set de reguli, dintre care mai importante sunt:

Unicitatea numelor Această regulă se aplică tuturor elementelor care apar în MCD: atribute, roluri,

restricţii de integritate. Prin urmare, se cere eliminarea eventualelor ambiguităţi prin utilizarea de nume unice şi complete (ex: Nume angajat, Nume client, Nume beneficiar şi nu, simplu, Nume, crezând că apartenenţa acestui atribut la un tip de entitate sau altul înlătură de la sine ambiguitatea). În acest sens se impune eliminarea omonimelor şi sinonimelor în cadrul modelului.

Atribute derivabile Atributele derivabile sunt cele ale căror valori se obţin din valorile altor

atribute, de regulă prin relaţii de calcul (ex: Valoarea produsului existent în stoc se calculează înmulţind Cantitatea din stoc cu Preţul produsului respectiv).

În mod normal, acestea trebuie eliminate din modelul conceptual al datelor, fiind redundante. Adeseori însă aceste atribute pot prezenta o semnificaţie particulară deosebită pentru problema studiată, fiind necesare pentru prelucrări ulterioare(listări, interogări complexe). În asemenea cazuri este posibilă menţinerea lor în schemă, însoţite însă de precizarea relaţiilor de calcul sau derivare sub formă de restricţii de integritate.

Atribute repetitive sau decompozabile Aceste atribute pot fi menţinute dacă prezenţa lor indică existenţa unor

structuri care trebuie reprezentate ca atare. De exemplu, pentru un student, reprezentarea rezultatelor la examene constituie un atribut repetitiv şi decompozabil care indică existenţa unei asocieri între student şi disciplinele pentru care trebuie să susţină examene.

Această regulă se aplică pentru orice atribut repetitiv sau decompozabil numai dacă el conduce la evidenţierea unor elemente, entităţi sau asocieri semnificative pentru problema respectivă. De exemplu, descompunerea atributului Adresa în Localitate, Strada, Numar se va face numai dacă delimitarea acestora prezintă interes în raport cu problema modelată.

Minimalitatea identificatorilor Aceasta înseamnă că în cazul identificatorilor compuşi dintr-un grup de

atribute nu trebuie să existe un subgrup al acestora care să poată îndeplini funcţia de identificator. Nerespectarea acestei reguli duce la existenţa dependenţelor funcţionale parţiale.

Valoarea NULL.

75

Atributele cu rol de identificatori ai entităţilor trebuie să aibă valori unice şi nenule (diferite de NULL). Atributele care nu au rol de identificator pot lua valori Null, ceea ce conduce la definirea unor subtipuri de entităţi.

Unicitatea asocierilor Aceasta cere ca, pentru fiecare realizare a asocierii, să nu existe decât o

realizare a fiecărei entităţi participante la asociere şi invers.Dacă pentru aceleaşi entităţi apar mai multe asocieri de acelaşi tip, înseamnă că

restricţia de unicitate este încălcată. În acest caz soluţia constă în transformarea asocierii într-o nouă entitate.

Observaţie:Ca şi entităţile, asocierile trebuie să fie identificabile iar identificarea lor se

face prin entităţile participante, mai exact prin identificatorii acestora. Condiţiile impuse identificatorilor: valori nenule şi unice pentru fiecare element trebuie respectate şi în cazul asocierilor.

De exemplu, dacă ne referim la împrumutatea unor exemplare de la o bibliotecă de către un cititor, dacă acesta împrumută de mai multe ori acelaşi exemplar, restricţia de unicitate este încălcată (fiecare restituire să corespundă unui singur împrumut şi invers). Rezolvarea constă în introducerea unei entităţi temporale Imprumutate care să caracterizeze împrumutul.

Aici, fiecare împrumut este identificat prin atributul Data împrumut şi prin rolul împrumută al cititorului. Un împrumut este făcut de un singur cititor şi poate cuprinde unul sau mai multe exemplare. Exemplarele împrumutate pot fi restituite toate sau pe rând.

Aceeaşi soluţie este benefică şi atunci când participarea anumitor entităţi este opţională. De exemplu, produsele comandate de clienţi sunt livrate şi facturate.

3.6.2. Reguli de normalizare a modelului

76

Modelul Entitate Asociere obţinut ca urmare a unei actitvităţi de analiză a datelor din sistemul obiect, oferă o viziune macro asupra acestora, fiind rezultatul unui proces iterativ care a dus la identificarea şi denumirea entităţilor, a atributelor acestora, a relaţiilor dintre ele. Un asemenea model trebuie supus apoi unei acţiuni de analiză specifică, pentru identificarea şi apoi înlăturarea dependenţelor funcţionale nepermise şi a anomaliilor semnalate.

Acest proces prin care se analizează entităţile şi atributele lor, în scopul eliminării anomaliilor, a redundanţelor acestora şi se înlătură dependenţele funcţionale tranzitive sau multivaloare se numeşte normalizare. În procesul normalizării pot lua naştere tipuri noi de entităţi sau se pot modifica cele existente. În procesul normalizării, care poate fi abordat atât în varianta top-down cât şi bottom-up, se pot aplica, pentru uşurinţă şi înţelegere, cel puţin următoarele trei reguli:

R1. Fiecare entitate trebuie să aibă un identificator cu valori unice nenule şi atribute elementare. Nu sunt acceptate deci atribute multivaloare (care se repetă) sau compuse. Identificatorul poate fi format din unul sau mai multe atribute.

Se spune că modelul este în forma normală 1 (FN1).

R2. Toate atributele entităţii, altele decât identificatorul, trebuie să se afle în dependenţă funcţională directă şi completă cu identificatorul. Aceasta înseamnă că atributele trebuie să depindă de identificator luat în totalitatea sa şi nu de părţi ale acestuia. Atunci când identificatorul este un atribut cerinţa este automat respectată. Dacă însă identificatorul este format dintr-un grup de câmpuri, atunci se cere o analiză mai atentă a atributelor definite, în vederea depistării dependenţelor funcţionale parţiale şi înlăturării acestora. Un model care respectă această regulă se află în forma normală 2 (FN2).

R3. Toate atributele unei asocieri trebuie să depindă complet de identificatorii entităţilor participante la asociere (altfel spus de identificatorul asocierii) şi să respecte regulile 1 şi 2. Aceasta înseamnă practic că modelul nu trebuie să conţină dependenţe tranzitive.

Sintetizând aceste acţiuni de normalizare a unui MCD într-o formă grafică,

rezultă:

77Start

Cercetările în domeniu au arătat că normalizarea poate continua şi după FN3, pentru a îndepărta toate anomaliile care pot să apară. Astfel, forma normală Boyce-Codd, după numele celor doi specialişti, R.F.Boyce şi E.F. Codd (FNBC) cere ca fiecare determinant să fie o cheie candidat.

3.7. Modelul relaţional3.7.1. Prezentare generală

Pornind de la modelele conceptuale ale datelor, mai exact de la modelul Entitate/Asociere se poate trece relativ uşor, pe baza unor reguli precise, la realizarea schemei conceptuale a bazei de date relaţionale.

Ideea este de a reprezenta entităţile şi legăturile dintre acestea sub formă de tabele (relaţii). Modelul relaţional se bazează pe noţiunea matematică de relaţie, aşa cum este definită în teoria mulţimilor, şi anume ca o submulţime a produsului cartezian a unei liste finite de mulţimi numite domenii.

Regulile de conversie ale entităţilor, atributelor şi asocierilor au la bază ideea minimizării numărului de valori null şi a redundanţei datelor.

Principalele caracteristici ale modelului relaţional sunt:- nu există tupluri identice;- ordinea liniilor şi coloanelor este arbitrară;- articolele unui domeniu sunt omogene;- fiecare coloană defineşte un domeniu distinct şi nu se poate repeta în

cadrul unei relaţii;

78

Model nenormalizat

Extragerea grupurilor repetitive (FN1)

Extragerea dependenţelor parţiale (FN2)

Extragerea dependenţelor tranzitive (FN3)

Stop

- toate valorile unui domeniu corespunzătoare tuturor cazurilor nu mai pot fi descompuse în alte valori (sunt atomice).

Codd a introdus, în anul 1985, un set de 13 reguli în raport cu care un sistem de gestiune a bazelor de date poate fi apreciat ca relaţional.

Un model relaţional de baze de date cuprinde trei componente principale: Structura datelor prin definirea unor domenii (valori atomice) şi a relaţiilor

n-are (atribute, tupluri, chei primare, etc); Operatorii de prelucrare a datelor, prin operaţii din algebra relaţională sau

calculul relaţional. Integritatea datelor prin impunerea unor restricţii;

Noţiunea de atribut este cunoscută şi sub numele de câmp sau caracteristică. Fiecare atribut poate lua valori într-un domeniu, fiecărei caracteristici corespunzându-i o coloană în cadrul relaţiei. El este caracterizat de natura valorilor pe care le poate lua. Astfel, un atribut este de tip numeric, alfanumeric, şir de caractere, logic etc. Deci, fiecare câmp de date se caracterizează prin ceea ce se numeşte tip.

Domeniul reprezintă un set de valori pe care le poate lua un atribut.Relaţia (sau tabela) se defineşte ca o submulţime a produsului cartezian de n

domenii. Ea se prezintă sub forma unei tabele bidimensionale, formată din rânduri numite tupluri şi coloane numite domenii.

Tuplul reprezintă o linie din cadrul tabelei, numită şi înregistrare.Schema unei relaţii reprezintă lista atributelor care aparţin relaţiei cu

domeniile lor. Dacă relaţia numită R are atributele A1, A2, ... Ak , atunci schema relaţională se notează R(A1, A2, ... Ak).

Cardinalitatea relaţiei defineşte numărul de tupluri care aparţin unei relaţii (rânduri).

Gradul (aritatea) relaţiei este dat de numărul de coloane, deci atribute ale relaţiei.

Cheia primară reprezintă un atribut sau grup de atribute ale cărui valori permit identificarea unică a unui tuplu.

Cheie candidată este un atribut sau grup de atribute ale cărui valori pot identifica un tuplu. Dintre cheile candidate se alege cheia primară a tabelei.

Cheie externă este un atribut sau grup de atribute care joacă rol de cheie primară într-o altă tabelă. O cheie externă trebuie să respecte cerinţele de integritate referenţială.

Pentru relaţiile (tabelele) ce constituie o bază de date se fac diferite presupuneri iniţiale, cum ar fi: inexistenţa unor tupluri duplicate, neapariţia într-o ordine dată a tuplurilor, neapariţia într-o ordine dată a atributelor, posibilitatea ca toate atributele să aibă numai valori atomice (nedecompozabile) şi altele.

Tuplurile unei relaţii nu pot să conţină valoarea nulă în coloane ce aparţin cheii primare.

79

Mulţimea tuturor schemelor relaţionale corespunzătoare unei aplicaţii se numeşte schema bazei de date relaţionale, iar conţinutul curent al relaţiilor la un moment dat se numeşte bază de date relaţională.

Cele mai multe cereri privesc determinarea unor informaţii cu anumite proprietăţi, iar răspunsul posibil este o relaţie care descrie toate elementele cu aceste proprietăţi. Modul de prezentare al răspunsului depinde de interfaţa dintre SGBD şi utilizator.

Algebra relaţională constă deci dintr-o colecţie de operatori ce au ca operanzi relaţii. Rezultatul aplicării unui operator la una sau două relaţii este tot o relaţie.

Presupunem că toate relaţiile au un număr finit de tupluri distincte şi sunt descrise printr-o mulţime ordonată de atribute. Atributele se deosebesc prin poziţia pe care o ocupă în relaţie sau prin numele asociat, numărul atributelor dând aritatea relaţiei. Cererile din algebra relaţională pot fi exprimate prin cinci operaţii asupra relaţiilor (tabelelor) numite operaţii de bază, şi anume: Reuniune, Diferenţă, Produs cartezian, Proiecţie, Selecţie .

Pe lângă cele cinci operaţii de bază, mai pot fi utilizate şi alte operaţii numite operaţii derivate, ce se pot exprima în funcţie de operaţiile de bază. Utilizarea acestora permite o mai simplă exprimare a cererilor şi, uneori, dacă sunt bine implementate, obţinerea unui răspuns mai rapid.

Cele mai des utilizate operaţii derivate sunt următoarele : Intersecţia, Câtul, Uniunea (join), Uniunea naturală (natural join).

Cu operatorii din algebra relaţională se pot defini noi relaţii ce pot fi utilizate pentru : regăsirea unor informaţii din baza de date, definirea unor actualizări (inserare, ştergere sau modificare) în baza de date, definirea unor date virtuale (vederi), definirea unor rezultate intermediare, definirea unor drepturi de acces la date, definirea unor cerinţe de stabilitate în cazul accesului concurent la date, definirea constrângerilor de integritate şi altele .

Se poate obţine o eficienţă mai bună dacă se combină mai mulţi operatori ce pot să apară într-o succesiune dată în diferitele cereri .

3.7.2. Trecerea de la MEA la schema conceptuală a bazei de date

Întreaga activitate de trecere de la MCD la schema conceptuală a unei baze de date relaţionale se face pe baza unor reguli precise, care sunt însă intuitive pentru un proiectant cu experienţă. Dintre acestea precizăm următoarele:

R1. Fiecare tip de entitate din MCD se va reprezenta printr-o relaţie (tabelă) în modelul relaţional al datelor, iar identificatorul entităţii devine cheie primară pentru tabelă. Se ştie că valoarea cheii trebuie să identifice în mod unic fiecare înregistrare (tuplu), că nu se admit valori multiple şi nici valori nule ale acesteia.

R2. Asocierile unare sau binare de tip 1:1 şi 1:N dintre două tipuri de entităţi, X şi Y, se reprezintă prin fie prin adăugarea cheii primare a lui X la entitatea Y ca

80

şi cheie străină, fie prin adăugarea cheii primare a lui Y la entitatea X ca şi cheie străină, fie şi una şi alta.

R3. Asocierile binare de grad M:N se reprezintă prin trei relaţii, două corespunzătoare entităţilor legate iar a treia corespunzătoare legăturii. Aceasta din urmă va avea drept cheie primară cheile primare ale entităţilor legate, la care se pot adăuga componente suplimentare.

3.8. Modelarea logică şi fizică a datelor

Am văzut că modelarea conceptuală a datelor defineşte reprezentarea modului de organizare a datelor independent de tehnologiile de prelucrare a acestora şi fără a acorda o atenţie deosebită calităţii modelului datelor. Modelul conceptual este prezentat prin intermediul diagramelor EA şi evidenţiază reprezentarea logică, detaliată a entităţilor, a asocierilor şi a datelor elementare din cadrul sistemului obiect.

Modelarea logică a datelor înseamnă de fapt descrierea datelor în concordanţă cu modul lor de organizare de către sistemele de gestiune a bazelor de date. Ea urmăreşte, în cadrul modelului datelor, îndeplinirea mai multor cerinţe, dintre care:

- o structurare performantă a datelor, prin procesul de normalizare;- un model logic al datelor care să conducă la modelul relaţional de baze de

date şi să răspundă cerinţelor de prelucrare ale utilizatorilor (se poate opta şi spre alte modele de baze de date, cum ar fi reţea, ierarhice sau orientate obiect).

Observaţie:Utilizând diagramele EA se poate realiza şi o proiectare orientată obiect.

Obiectul, ca abstractizare a lucrurilor reale prin care datele şi procesele sunt puse laolaltă, este văzut ca o structură care înglobează atributele (caracteristicile) şi metodele ce operează asupra acestora. Prin urmare, tehnicile utilizate în analiză şi proiectare vor fi orientate spre obiecte, nu spre date şi procese , aşa cum prevăd metodele sistemice.

Procesul de modelare logică a datelor se desfăşoară în paralel cu celelalte

activităţi de proiectare, cum sunt proiectarea rapoartelor, a machetelor de introducere a datelor, a interfeţei. În fiecare moment al proiectării se compară modelul logic al datelor cu modelul entitate-asociere rezultat în urma normalizării, în cadrul unui proces iterativ de corectare şi completare.

Derivarea modelului se realizează practic printr-o succesiune logică de operaţii, şi anume:

- identificarea stocurilor logice de date;- înlăturarea referinţelor fizice şi temporare;- derivarea proceselor logice;

81

- derivarea fluxurilor logice;- gruparea proceselor elementare.

Se impune aici să ne reamintim noţiunile de entitate normală şi entitate slabă.O entitate normală devine în modelul relaţional o tabelă care are o cheie

primară şi atribute non-cheie. O entitate slabă devine în modelul relaţional o tabelă cu o cheie primară

compusă, în care este inclusă cheia primară a fiecărei entităţi de care depinde această entitate şi atribute non-cheie. Sunt elemente deosebit de importante, atunci când definim restricţiile de integritate a bazei de date, pentru a elimina anomaliile la actualizarea acesteia. Astfel, fiecare cheie primară şi cheie externă din tabelele unei baze de date relaţionale trebuie să satisfacă restricţiile de integritate:

- Integritatea entităţii (entity integrity) care cere ca nici un atribut care participă la formarea cheii primare a unei tabele de bază să nu poată primi valori nule (Not Null);

- Integritatea referenţială (referential integrity) care cere ca, dacă valoarea unei unei chei externe nu este nulă, atunci ea trebuie să se regăsească printre valorile cheii primare ale tabelei referite şi, dacă un tuplu referă un alt tuplu dintr-o altă tabelă, atunci acel tuplu trebuie să existe.

Modelul logic al datelor prevede toate aceste caracteristici, defineşte atributele, cheile, condiţiile de integritate.

De la modelul logic al datelor se trece la realizarea modelului fizic al datelor, care este însă în strânsă dependenţă cu sistemul de gestiune a bazelor de date (SGBD) ales. El trebuie să conducă astfel la schema bazei de date, adică să precizeze tabelele, structura acestora şi relaţiile dintre ele.

Dată fiind importanţa alegerii SGBD-ului, se impune precizarea unor cerinţe minimale pe care acesta să le îndeplinească, cum ar fi:

- timp de răspuns minim;- confidenţialitatea şi securitatea datelor;- uşurinţă în exploatare;- portabilitatea aplicaţiilor şi a bazei de date;- portabilitatea SGBD-ului;- instrumente pentru generare automată de rapoarte, formulare, meniuri;- facilităţi de gestionare şi refacere a bazei de date;- facilităţi de administrare a bazei de date;- facilităţi de ordin economic , etc.Practic, odată ales SGBD-ul, se trece la proiectarea fizică a fişierelor şi a bazei

de date, la definirea caracteristicilor fiecărui atribut din modelul logic al datelor, la descrierea tehnologiilor utilizate pentru crearea fişierelor şi a bazei de date, a

82

timpului de răspuns preconizat, a sistemului de indecşi creat în vederea grupării datelor în rapoarte şi interogări, a ordonării lor pentru acces rapid la datele necesare. Tot în această etapă se stabilesc structurile de stocare a datelor şi suportul acestora.

Specificaţiile realizate în această etapă vor fi de regulă orientate spre un limbaj de descriere a datelor (SQL- limbaj standard pentru baze de date relaţionale) sau spre un limbaj de programare, cum ar fi: Cobol, C, etc. şi vor servi programatorilor pentru descrierea datelor. În acest sens, modelul fizic al datelor va specifica, pentru fiecare atribut, următoarele:

- Numele - numele câmpului, servind pentru identificarea acestuia;

- Tipul datei – formatul datei, inclusiv lungimea ei;- Reguli de integritate a datelor – precizează limitele

între care se pot înscrie valorile câmpului respectiv;- Formula de calcul – pentru câmpurile calculate;- Cifra de control – dacă este cazul, se precizează

algoritmul de obţinere a acesteia;- Integritatea referenţială – precizează dacă valoarea

câmpului respectiv trebuie să coincidă cu valoarea altui câmp din altă înregistrare.

Observaţie:În cadrul unei tabele definite acum vom putea defini:- atribute normale sau ordinare, care nu participă la formarea unei chei;- atribute desemnate chei primare pentru identificarea unică a unui tuplu al

tabelei;- atribute desemnate chei alternative, pentru definirea unor căi suplimentare

de acces la un tuplu şi diminuarea timpului de răspuns la interogări;- atribute desemnate chei externe, de mare importanţă în materializarea

asocierilor dintre tuplurile tabelelor şi care trebuie să respecte o serie de restricţii, pentru a asigura coerenţa logică a datelor din baza de date.

De aceea, la proiectarea bazei de date, se impune formularea precisă a unor

restricţii, în principal pentru atributele cu rol de chei primare şi chei externe, care trebuie să fie specificate şi în cadrul documentaţiei puse la dispoziţia utilizatorilor.

Astfel, cheia primară din cadrul fiecărei tabele va respecta cel puţin următoarele reguli:

- pentru fiecare atribut din cadrul cheii primare nu se acceptă valori nule;- se impune crearea unui index care să permită doar valori unice pentru

atributul sau combinaţia de atribute care formează cheia primară;- la fiecare inserare de noi tupluri sau modificare a valorii cheii primare se va

testa mai întâi acest index, pentru a nu permite valori duplicate ale cheii;

83

Cheia externă din cadrul fiecărei tabele va respecta cel puţin următoarele reguli:

- pentru fiecare atribut din cadrul cheii externe nu se acceptă valori nule dacă şi numai dacă pentru cheia externă nu se admit valori nule;

- dacă este necesar, se poate crea un index pentru valorile cheii externe, care va accepta, probabil, şi valori duplicate;

- se vor crea şi se vor preciza în specificaţiile tehnice de programare, mecanisme de autorizare a accesului la baza de date, de întreţinere a acesteia, astfel încât să nu fie violate restricţiile ce se impun acestor chei externe. Când vorbim despre o cheie externă avem în vedere totdeauna două tabele: o tabelă care referă – sau părinte - şi una care este referită – sau copil. În acest sens trebuie precizate clar în ce condiţii se pot efectua asupra bazei de date operaţii cum sunt:

adăugarea unui tuplu în tabela care referă; modificarea valorii cheii externe în tabela care referă; ştergerea unui tuplu în tabela referită (copil); modificare valorii cheii primare a tabelei referite.

3.9. Probleme

3.9.1. Probleme rezolvate

1. Să se realizeze modelul entitate asociere pentru activitatea de împrumutare cărţi dintr-o bibliotecă.

Rezolvare:Se identifică, în urma analizei activităţii respective, următoarele entităţi:ClienţiAutoriCărţiDomenii ale cărţilorEdituri

84

2. Să se realizeze modelul entitate asociere pentru activitatea de gestiune a mijloacelor fixe din cadrul unei firme.

Precizare:Se ştie că un mijloc fix este achiziţionat pe baza unei facturi şi este dus la un

anumit loc de folosinţă pentru a fi pus în funcţiune pe baza unui proces verbal de punere în funcţiune.

De aici el poate fi casat – pe baza unui proces verbal de casare, poate fi vândut – pe baza unei facturi de vânzare sau poate fi transferat la un alt loc de folosinţă pe baza unui bon de mişcare.

Rezolvare:

85

3. Se consideră o societate de valori imobiliare, care oferă clienţilor săi bunuri imobiliare (apartamente, case, vile) pentru vânzare sau pentru închiriere. La vânzare se cunosc preţul şi starea bunului (liber, disponibil ulterior). Pentru închiriere, se cunosc chiria lunară, durata minimă a închirierii şi avansul ce trebuie plătit.

Rezolvare:Se observă că un bun al tranzacţiei imobiliare poate fi ofertat pentru vânzare

sau cumpărare. Pe de altă parte, orice bun imobiliar care se tranzacţionează poate fi: imobil şi în acest caz – apartament, vilă sau casă – ori teren. Toate acestea duc la specializări ale entităţii bun imobiliar. Astfel, un bun imobiliar face aici obiectul unei duble specializări, în funcţie de tip (apartament la bloc sau casă/vilă)

86

şi în funcţie de natura ofertei făcute de proprietar (vânzare sau închiriere). Specializarea elimină în acest caz necesitatea unui atribut care să precizeze natura ofertei făcute şi a RI de rol care să precizeze că numai un bun oferit spre vânzare poate fi vândut.

Notă:Specializarea tipului de entitate CLIENT aduce avantajul că nu poate fi

ofertant decât un client care este proprietarul unui bun imobiliar, intermediarii fiind astfel excluşi). Absenţa RI de excluziune dintre cele două specializări precizează că aceeaţi persoană poate fi atât ofertant pentru un bun cât şi solicitant pentru un alt bun. RI dintre asocierile CUMPARA si VINDE precizează că, pentru o anumită vânzare, cumpărătorul şi vânzătorul trebuie să fie persoane diferite.

4. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de recepţie hotelieră. Se face precizarea că există mai multe tipuri de camere, că un client poate consuma şi alte servicii oferite de hotel (telefon, spălătorie, tratamente, masaje, piscină etc) şi că există posibilitatea rezervării de la distanţă (fax, telefon, etc)

87

Sugestie:Se pot identifica două activităţi mari: - Cazarea clienţilor , care ocupă camere şi solicită diverse servicii;- Rezervarea de camere făcută de diferite persoane, prin fax, telefon,etc.,

3.9.2. Probleme propuse

1. Să se realizeze modelul entitate asociere şi DDF pentru evidenţa activităţilor dintr-un garaj auto. Se ştie că există un parc de maşini, fiecare maşină având şoferul ei. Maşinile pleacă în curse şi înregistreză consumurile de carburanţi şi alte cheltuieli ocazionate.

88

2. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de evidenţă a stocurilor de produse dintr-o magazie, ştiind că firma cumpără produse pe bază de factură şi vinde produsele emiţând facturi către clienţii săi. Firma încasează un comision cuprins între 5 şi 20%.

3. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de rezervare locuri la avion. Se ştie că sunt mai multe companii aeriene la care se poate solicita biletul, că aceeaşi companie are mai multe curse, mai multe tipuri de avion. Se poate solicita bilet de mai multe tipuri, la diferite clase la o anumită dată.

4. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de calcul şi evidenţă a salariilor pentru personalul unei firme. Se ştie că fiecare angajat este încadrat pe un post din statul de funcţiuni, corespunzător nivelului de studii şi specializare, cu un salariu de încadrare. Lunar se întocmeşte un pontaj cu prezenţa la lucru. Se calculează drepturile salariale cuvenite, eventual şi cele pentru concediul medical (mai multe tipuri de boli şi modalităţi de plată) şi se reţin, în afara sumelor datorate la buget (impozit, şomaj, Cas, etc) şi eventualele reţineri (rate, credite, penalităţi, etc).

5. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de creditare bancară. Se ştie că se pot acorda mai multe tipuri de credite, către persoane fizice sau juridice. Pentru fiecare caz, se realizează o instruire a clientului, se analizează dosarul acestuia şi, dacă sunt îndeplinite condiţiile de venituri, de garanţie şi altele ce trebuie precizate, se acordă creditul respectiv.

6. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de gestiune a studenţilor de la universitatea noastră. Se ştie că un student este înscris la o facultate (sau chiar 2), învăţământ de zi sau cu frecvenţă redusă, într-un an de studiu, o grupă, o promoţie. El studiază astfel materiile cuprinse în planul de învăţământ şi predate de un profesor titular de curs şi se prezintă la examene, unde obţine diferite rezultate. Formulaţi restricţiile de integritate care se impun.

7. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de închiriere maşini de către turiştii străini de la o firmă specializată în aceste activităţi.

8. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de calcul a manoperei realizate (suma cuvenită pentru operaţiile executate pe fluxul tehnologic la toate pachetele la care a lucrat) de salariatele unei firme de confecţii, ştiind că fiecare îşi consemnează toate operaţiile executate pe bonul de manoperă lansat odată cu pachetul de produse pe flux tehnologic. O muncitoare poate

89

executa la un produs mai multe operaţii diferite. Un pachet lansat în fabricaţie poate avea un anumit model, o mărime, poate aparţine unui anumit contract, deci poate avea un unumit termen de livrare. . Fiecare operaţie are un tarif pe model sau mărime.

9. Să se realizeze modelul entitate asociere şi DDF pentru activitatea de evidenţă contabilă, ştiind că fiecare document de intrare sau ieşire valori, de mişcare, de plăţi sau încasări generează o înregistrare în contabilitate (pe debitul sau creditul unui cont).

10. Să se realizeze modelul entitate asociere şi DDF pentru evidenţa activităţii de service a unei firme de calculatoare. Se face precizarea că firma prestează service atât pentru perioada de garanţie şi postgaranţie, cât şi pentru clienţi care au cumpărat calculatoarele de la alte firme.

11. Să se realizeze modelul entitate asociere şi DDF pentru evidenţa activităţii curente a unui cabinet medical. Se cere o evidenţă clară a pacienţilor, a diagnosticelor şi a tratamentelor acestora, a medicilor care îi tratează .

90

4. MODELAREA CONCEPTUALĂ A PRELUCRĂRILOR4.1. Concepte de bază

Se ştie că, în cadrul sistemului informaţional, datele circulă şi sunt supuse la diferite prelucrări. Prelucrările reprezintă practic acţiunile exercitate asupra datelor pentru obţinerea informaţiilor necesare. Aşa sunt de pildă algoritmii de calcul a datelor, procedurile manuale sau automate executate asupra acestora.

Modelul Conceptual al Prelucrărilor (MCP) se defineşte astfel ca o reprezentare schematică a activităţilor desfăşurate în cadrul sistemului obiect, a prelucrărilor la care sunt supuse datele, independent de structura organizatorică şi mijloacele de realizare. Modelul trebuie să răspundă la întrebarea: Ce prelucrări se efectuează asupra datelor? Pentru aceasta analistul trebuie să identifice cât mai complet şi corect care sunt acţiunile, cu toate operaţiile lor componente şi care sunt evenimentele care le declanşează. În aceste condiţii MCP realizează reprezentarea grafică a succesiunii operaţiilor, a condiţiilor necesare pentru declanşarea lor şi a consecinţelor lor.

Modelul conceptual al prelucrărilor vede întreaga prelucrare ca o succesiune ordonată şi logică de proceduri înlănţuite, toate acestea în strictă concordanţă cu legislaţia în vigoare. În acest sens nu se poate neglija impactul utilizării instrumentului informatic (SGBD) asupra MCP. Astfel, anumite validări pot fi efectuate încă din faza de culegere a datelor, evitând să se constate ulterior că datele sunt incomplete sau eronate; aceasta înseamnă că anumite operaţii din MCP pot fi eliminate.

MCP realizează deci modelarea proceselor de prelucrare a datelor, redată prin intermediul diagramelor de flux a datelor (DFD). DFD este deci o reprezentare grafică a transformării datelor de intrare în date de ieşire.

Pentru ca MCP să fie cât mai stabil, trebuie să fie independent de aspectele organizatorice, tehnologice şi chiar geografice. El operează cu noţiuni precum: procesul, operaţia, evenimentul.

Evenimentul se defineşte ca un semnal receptat de sistem, la care acesta trebuie să răspundă. Practic, el desemnează un fapt a cărui apariţie declanşează o reacţie în cadrul organizaţiei; apariţia unui eveniment va determina derularea de activităţi, de operaţii, reprezentând “motorul” unei acţiuni, al unei operaţii (de exemplu, sosirea unui document, cum ar fi: o comandă, o cerere de credit din partea unei persoane, etc).

Sosirea unei comenzi de la un client este un eveniment declanşator extern. A satisface această cerere înseamnă pentru firmă să o transforme într-o livrare de produse. Descrierea prelucrărilor necesare pentru aceasta constituie modelul conceptual al prelucrărilor şi trebuie să fie independentă de:

- aspectele tehnologice (dacă se utilizează calculatorul sau nu);

91

- aspectele geografice (comanda este prelucrată la depozit sau în altă parte);- aspecte organizatorice (livrarea este facută de o persoană de la serviciul

comercial sau de la magazie);- aspecte temporale (livrarea se face dimineaţa sau seara). Evenimentele pot fi externe, dacă provin din afara sistemului obiect şi nu pot fi

controlate de acesta. Evenimentele generate de desfăşurarea unei operaţii se numesc interne şi pot fi de tip rezultate, destinate mediului extern sau intermediare, având rolul de a declanşa alte operaţii în sistem.

Pentru a vorbi de un eveniment trebuie să fie îndeplinite anumite condiţii: - să se întâmple ceva (în afara sau în interiorul firmei);- acest ceva trebuie să fie perceput de sistem;- firma să fie interesată, văzând în el un posibil eveniment declanşator al

activităţii sale. Operaţia reprezintă o succesiune de acţiuni elementare care generează

evenimente interne, împreună cu regulile de producere a acestora.Se numeşte tip de operaţie o categorie de operaţii care prezintă aceleaşi

caracteristici. Un tip de operaţie se caracterizează prin următorii parametri caracteristici:

- denumirea operaţiei; - durata exprimată în unităţi de timp; - acţiunile elementare componente; - evenimentele emise şi condiţiile de emitere.

O operaţie se finalizează întotdeauna prin emiterea de evenimente funcţie de situaţiile identificate pe parcurs şi de condiţiile exprimate de aceste situaţii (aşa-numitele reguli de emisie).

Observaţie:O operaţie se desfăşoară în timp, având o anumită durată. La un moment dat ea

poate fi :- în aşteptarea execuţiei; - în curs de execuţie; - terminată.

Se numeşte rezultat sau eveniment emis produsul executării unei operaţii. Întotdeauna este respectată regula conform căreia o operaţie produce unul sau mai multe rezultate. Descompunerea unei operaţii în mai multe operaţii distincte determină apariţia unor rezultate intermediare. Un eveniment emis poate fi în acelaşi timp un eveniment declanşator pentru o altă operaţie (sau alte operaţii).

În MCP toate operaţiile trebuie să aibă rezultat. În unele cazuri obţinerea rezultatelor poate fi condiţionată de îndeplinirea

anumitor condiţii. În acest caz este necesar să fie definite aşa numitele reguli de emisiune sau reguli de acţiune.

92

Spre exemplu, dacă valoarea facturată este mai mare de 2 milioane, atunci se acordă un discount de 1o%. La lansarea unei livrări se impune verificarea stocului existent, astfel: dacă stocul este insuficient, comanda este ţinută în aşteptare (nu se întocmeşte dispoziţie de livrare), altfel se onorează livrarea. Condiţia de stoc suficient defineşte în acest caz o regulă de emisiune a rezultatului cu două cazuri diferite: stoc suficient şi stoc insuficient.

Se numeşte sincronizarea unei operaţii un ansamblu de condiţii care determină declanşarea operaţiei, exprimate de fapt printr-un ansamblu de evenimente declanşatoare. Ea se exprimă printr-o expresie logică. Sincronizarea reprezintă deci concordanţa între două sau mai multe evenimente.

Conceptul de sincronizare exprimă o logică şi o dinamică a prelucrărilor. La un moment dat, expresia logică poate fi verificată. Spunem atunci că sincronizarea este activă şi operaţia este declanşată. La un alt moment însă este posibil ca un singur eveniment declanşator să fie realizat; în acest caz sincronizarea este în aşteptarea realizării altor evenimente participative care să declanşeze operaţia. Dacă nici un eveniment nu are loc, sincronizarea este inactivă.

De exemplu, în procedura de acordare a unui credit, modelul conceptual al prelucrărilor descrie ceea ce se face, fără a preciza nici cine face şi nici cu ce instrument. Astfel, odată cu primirea cererii de credit (care este un eveniment extern), are loc o operaţie de instruire a deschiderii unui dosar de creditare, care se finalizează după caz (funcţie de regulile de emisiune concrete) printr-un refuz (cerere nerezolvabilă), prin deschiderea efectivă a unui dosar de creditare şi în sfârşit, printr-o cerere de informare suplimentară (vezi fig. 4.1).

Procesul se defineşte în acest context ca un subansamblu al unei activităţi în care punctele de intrare şi ieşire nu depind de structura organizatorică a societăţii. De exemplu, în activitatea comercială, procesul de gestiune a comenzilor.

Un proces descrie dinamica prelucrărilor dintr-o activitate determinată. El este format din operaţii executate ca reacţie la evenimente şi care produc rezultate. Un proces este:

- omogen, adică operaţiile şi rezultatele concură la o finalitate comună.- limitat, având graniţe marcate de evenimentele declanşatoare şi de

rezultatele terminale. Procesul este practic un MCP ce corespunde unui domeniu de activitate. El

este construit printr-un demers metodologic de modelare (analiză, abstractizare, concepţie) care cuprinde următorii paşi:

- Stabilirea domeniului de investigat, a ariei sale de cuprindere; - Identificarea evenimentelor declanşatoare, ştiind că fiecare flux de date

este asociat unui eveniment. Aici trebuie stabilite principalele evenimente externe şi interne ale procesului, acestea fiind elementele cheie în realizarea modelului.

- Întocmirea tabelului Evenimente-Rezultate, care permite definirea conţinutului procesului şi în care, pentru fiecare eveniment declanşator se

93

precizează acţiunea determinată şi evenimentele emise de aceasta. Avem de a face cu un tabel de forma:

Evenimente Acţiuni Rezultate sau Evenimente emise

- Identificarea şi descrierea operaţiilor; O analiză riguroasă a contextului permite relevarea regulilor de gestiune, care sunt adesea elemente ale operaţiilor.

- Identificarea sincronizărilor; Aparent, mai multe evenimente distincte pot să declanşeze aceeaşi operaţie. Odată stabilite aceste elemente se poate construi schema de bază pentru fiecare operaţie, numită bloc operaţie.

- Identificarea regulilor de emisie ; Se caută, printre regulile de gestiune, pe acelea care definesc condiţii de obţinere a rezultatelor şi se completează schema de bază cu elementele respective.

- Ordonarea blocurilor-operaţie.- Elaborarea modelului conceptual al prelucrărilor. Structura generală a procesului decurge din cronologia evenimentelor. Prin

urmare evenimentele trebuie ordonate cronologic, ceea ce înseamnă că în ordonarea diferitelor blocuri-operaţie şi legarea lor acţionează principiul : un rezultat al operaţiei n-1 declanşează operaţia următoare (operaţia n).

- Verificarea şi validarea modelului. În acest sens se verifică dacă: o orice operaţie duce la cel puţin un rezultat; o orice operaţie este declanşată de cel puţin un eveniment; o toate blocurile sunt legate.

Validarea modelului se face de către persoanele implicate în proces.

Observaţie:Toate metodologiile de proiectare a unui sistem informatic utilizează

modelarea datelor şi proceselor de prelucrare a acestora şi recurg la diagrame de flux pentru descrierea grafică a acestora.

Diagramele de flux pot fi realizate la nivelul unei componente funcţionale (aprovizionare, vânzare produse finite, încasare produse sau servicii facturate, etc) sau a unei componente organizatorice, cum ar fi un compartiment, o secţie de producţie, de service auto, etc. Oricum, diagramele de flux trebuie să identifice şi să menţioneze clar următoarele aspecte:

- sursa datelor;- circuitul acestora;- prelucrările ce au loc asupra lor în cadrul circuitului;- destinaţia datelor prelucrate.

94

Datorită complexităţii activităţilor analizate şi deci şi a datelor şi proceselor de prelucrare pe care acestea le comportă, diagramele se pot elabora pe nivele de detaliere, astfel încât să surprindă elementele de bază ale problemei şi să le poată reprezenta sugestiv, intuitiv.

De aceea, în cadrul diagramelor, se pot identifica: - diagramele de context;- diagramele fluxurilor de date ale sistemului fizic existent;- diagramele fluxurilor de date ale sistemului logic existent;- diagramele fluxurilor de date ale sistemului logic nou;Diagrama de context stabileşte aria de cuprindere a sistemului obiect,

precizând elementele din interiorul sistemului şi pe cele din exterior, ca entităţi externe.

Diagrama fluxurilor de date ale sistemului fizic existent precizează care sunt procesele de prelucrare a datelor (transfer, calcul, stocare), care sunt intrările şi ieşirile din aceste procese, care sunt persoanele şi tehnologiile utilizate de fiecare proces.

Diagrama fluxurilor de date ale sistemului logic existent identifică şi precizează care sunt funcţiile de prelucrare a datelor, independent de tehnologiile utilizate.

Diagrama fluxurilor de date ale sistemului logic nou reprezintă grafic circuitul datelor, prelucrările acestora, structura şi cerinţele noului sistem, aşa cum a fost gândit el în urma analizei sistemului existent şi a stabilirii direcţiilor de perfecţionare.

Descrierea obiectelor din DFD se face în aşa numitele Dicţionare de date sau depozite Case (repository).

Observaţie: Diagrama Fluxurilor de Date reprezentând modul de transfer al datelor

(circuitul) între procesele de prelucrare a acestora se mai numeşte şi Model al Proceselor de Prelucrare, iar activitatea se numeşte modelarea proceselor.

DFD reprezintă una din tehnicile de analiză structurată care datează din jurul anilor 1980.

Dintre tehnicile de prezentare a diagramelor fluxurilor de date mai utilizate în lumea proiectării sistemelor informatice sunt: Gane & Sarson şi Yourdon & De Marco1 după numele celor care le-au realizat. Cele două tehnici de reprezentare sunt foarte asemănătoare, folosind simboluri asemănătoare şi având la bază acelaşi obiectiv: acela de prezenta cât mai fidel şi sugestiv, pentru o anumită activitate, domeniu sau societate, sursa datelor, procesele de prelucrare a acestora, destinaţia

1 DE Marco T- Structured Analysis and Design Specification, Prentice Hall, EnglewoodCliffs, New Jersey, 1979.

95

datelor obţinute în urma prelucrărilor şi eventual legătura existentă între prelucrări şi activitatea de stocare a datelor.

Yourdon şi DeMarco recomandă însă ca nici o diagramă să nu conţină mai mult de 7 procese de prelucrare, astfel că se ajunge ca, pentru un sistem sau activitate complexă să se realizeze o descompunere, pe nivele, de sus în jos (tehnica Top-Bottom) a diagramelor de flux a datelor până la procese sau operaţii elementare. De aceea vom întâlni în reprezentările grafice diagrame din ce în ce mai detaliate, de nivel 0, 1, 2 şi aşa mai departe.

Pentru reprezentarea fluxului de date şi a proceselor de prelucrare a acestora se pot utiliza mai multe simboluri grafice, cum ar fi cele specifice metodologiei SSADM, care vor fi prezentate în cadrul metodologiei respective, dar şi o serie de alte simboluri consacrate, cum ar fi:

Descrierea unui proces: un dreptunghi cu colţurile rotunjite, despărţit în două zonecare specifică numărul şi respectiv denumirea procesului de prelucrare descris.

Descrierea operaţiunii de stocare a datelor, indiferent de mediul manual sau informatizat în care se realizează se reprezintă grafic printr-un dreptunghi alungit, cu două zone: una specifică numele, identificatorul unic al locului de stocare şi alta care precizează numele acestuia.

Se ştie că entităţile pot fi surse de date, de unde pleacă datele în prelucrarea lor, sau locuri de stocare a acestora. De aceea este posibil ca în cadrul unei diagrame a fluxului de date numele unor entităţi să se regăsească şi ca locuri de stocare a datelor.

La aceste simboluri se mai adaugă:Pentru timpul de sincronizare a operaţiilor simbolul grafic:

Pentru o entitate externă un pătrat simplu sau îngroşat:

sau

Pentru fluxul de date se pot utiliza săgeţi sau arce de cerc de diferite forme:

96

Propoziţie logică

Nr proces

Denumire proces

D1 Produse

Un flux de date înseamnă practic un traseu, un circuit pe care datele (elementare sau grupate) se deplasează în sistem sau din sistem.

Pentru procese se pot utiliza în reprezentarea grafică şi cercuri cu textul explicativ scris în interior.

Cu privire la reprezentarea modelului prelucrărilor prin diagramele de flux a datelor, pentru o bună înţelegere a acestora, se fac, în metodologiile de proiectare utilizate, o serie de convenţii, dintre care mai importante sunt:

procesele de prelucrare şi stocurile de date sunt numerotate secvenţial, pentru a putea fi identificate. Numerele asociate lor nu semnifică ordinea de execuţie a acestora;

pentru a face diagramele mai uşor de înţeles, entităţile externe sunt plasate, de regulă, în jurul diagramei iar stocurile de date în partea centrală ;

pentru mai multă claritate, DFD nu conţine mai mult de 7- 9 procese; fluxurile de date de la sursă către stocurile de date sunt unidirecţionale (fie

de adăugare, fie de consultare) şi nu sunt etichetate. pentru a evita fluxurile de date întretăiate entităţile externe şi stocurile de

date pot fi duplicate. O entitate externã duplicată se reprezintã prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie suplimentară verticală în partea stângă a cutiei

Exemplul 1:Analizând procedura de acordare a unui credit, MCP ar putea fi realizat astfel:

97

Exemplul 2.Să se realizeze modelul conceptual al prelucrărilor pentru activitatea de

recepţie hotelieră (pentru care am realizat anterior şi modelul entitate asociere).

98

Exerciţii propuse:

1. Realizaţi modelul conceptual al prelucrărilor şi apoi diagrama de flux a datelor pentru toate problemele analizate sau propuse spre rezolvare pentru realizarea modelului entitate asociere şi a diagramei dependenţelor funcţionale (capitolul anterior).

99

4.2. Descompunerea funcţională şi rafinarea DFD

Dacă sistemul analizat pe care-l descriem cu ajutorul DFD este complex, nu vom putea realiza de la început o DFD detaliată. Pentru a descrie însă în detaliu aceste sisteme, metodele sistemice propun o abordare Top - Down, adică o descompunere funcţională a sistemului, prin descompunerea succesivă a proceselor.

Se realizează mai întâi Diagrama Contextuală care defineşte aria de întindere a sistemului analizat, stabilind graniţele acestuia, separarea lui de mediul extern. Acesta este primul nivel – numit nivelul 0 - al DFD. Fluxul de legătură a sistemului cu mediul său se numeşte interfaţă.

Nivelele următoare se obţin prin rafinarea (descompunerea) proceselor complexe într-o diagramă de nivel inferior. Rafinarea poate continua până se ajunge la operaţii elementare.

E bine ca în cadrul operaţiei de rafinare a DFD să respectăm următoarele reguli1:

fiecare proces va fi numerotat corespunzător nivelului de descompunere şi poziţiei în cadrul diagramei. Astfel, dacă procesul 2 din diagrama de nivel 1 va fi descompus, procesele de nivel inferior vor fi: 2.1, 2.2., ...

fluxurile de intrare şi de ieşire pot fi şi ele descompuse în componente; o diagramă de pe orice nivel de descompunere nu trebuie să conţină mai

mult de 9 procese; descompunerea DFD se poate considera terminată atunci când ajungem la

procese elementare. Procesele elementare sunt marcate în colţul din dreapta jos prin "*".

pentru procesele elementare se realizează o descriere sau o specificaţie, sub formă de text; se poate recurge însă şi la alte posibilităţi de reprezentare, cum sunt: pseudocod, scheme logice, tabele de decizie sau chiar cod scris într-un limbaj de programare;

regula balansului cere ca intrările şi ieşirile unei diagrame de nivel inferior să coincidă cu intrările şi ieşirile procesului pe care-l descompun.

Observaţie:Alături de diagrame de flux a datelor pot fi utilizate cu succes şi alte forme

de reprezentare a sistemului obiect sau ale celui nou, cum ar fi de pildă schemele logice de sistem, schemele de structură ale sistemului, etc.

4.3. Modelul fizic al prelucrărilor1 Gh. Sabău, V. Avram, Sisteme informatice pentru management, Oscar Print, 1999 .

100

Înainte de a realiza modelul logic al prelucrărilor din sistem se impune construirea unui model organizaţional (fizic) al prelucrărilor, care să ţină seama de particularităţile organizatorice din cadrul societăţii.

Diagrama fluxului de date fizice (DFDF) ca reprezentare schematică a sistemului existent, pune în evidenţă entităţile interne, pe cele externe sistemului, precum şi fluxul datelor între acestea. Practic ea răspunde astfel la întrebările: Cine realizează prelucrarea, Unde se realizează şi Cum?

O entitate internă poate fi o persoană, un compartiment, o resursă hardware sau software care participă la transformarea datelor. Toate aceste entităţi sunt reprezentate în DFDF prin cercuri (cele externe sunt reprezentate prin pătrate) în interiorul cărora este scris numele fiecărei entităţi (Cine?). Arcele de cerc reprezintă fluxurile de date şi poartă numele documentului sau modalităţii concrete prin care se transmit aceste date (Cum?). Locul unde se face prelucrarea şi se amplasează fişierul este precizat în diagramă şi răspunde la întrebarea Unde?.

Diagramele de flux a datelor pot fi construite manual sau utilizând instrumentele CASE, care sesizează mai uşor deficienţele ce pot apare în cadrul acestora.

În literatura de specialitate s-a acordat o atenţie deosebită procesului de construire a diagramelor, dată fiind importanţa lor în în etapa de analiză şi proiectare ulterioară. Astfel, au fost stabilite reguli de construire şi validare a diagramelor1 prelucrate şi prezentate ulterior şi de specialişti de clasă în proiectarea sistemelor informatice din România2, pe care le voi prezenta pe scurt, şi anume:

1). Despre procese: Nici un proces de prelucrare nu poate avea doar ieşiri, căci ar însemna să

obţină date din nimic. Dacă totuşi un obiect are numai ieşiri, atunci el este o sursă. Nici un proces nu poate avea doar intrări, altfel, el este o destinaţie. Un proces se denumeşte printr-o expresie care începe cu un verb urmat de

precizarea obiectului la care se referă verbul. De exemplu, creare situaţie stocuri.

2). Despre stocare: Datele nu pot fi transferate direct dintr-un loc în altul; ele pot fi transferate

doar prin intermediul unui proces. De la o sursă externă la un loc de stocare datele nu pot fi transferate direct,

ci prin intermediul unui proces.

1 Celko J, Data Flow Diagrams, Computer Language 4, 1987. 2 Dumitru Oprea, Analiza şi proiectarea sistemelor informaţionale economice, Polirom 1999, pag 221

101

Datele nu pot transferate dintr-un loc de stocare spre o destinaţie externă, decât prin intermediul unui proces.

Un loc de stocare se denumeşte printr-un substantiv.3). Despre Sursă/Destinaţie: Datele nu pot fi transferate direct de la sursă la destinaţie; trebuie folosit un

proces de trecere. O sursă sau o destinaţie se denumeşte printr-un substantiv.4). Despre Fluxurile de date: Un flux de date are o singură direcţie de flux între simboluri. El poate fi şi

bidirecţional, între un proces şi un loc de stocare a datelor, pentru a sugera o citire înainte de actualizare; se vor folosi însă pentru reprezentare două săgeţi de sensuri contrare, deoarece procesul se execută la momente diferite.

O ramificaţie într-un flux de date arată că aceleaşi date se transferă dintr-un loc comun în două sau mai multe procese de prelucrare, locuri de stocare sau surse/destinaţii (de regulă sunt copii ale aceloraşi date).

Unirea mai multor fluxuri înseamnă că aceleaşi date vin din mai multe procese sau locuri de stocare spre un loc comun de stocare.

Un flux de date nu poate reveni direct la procesul pe care l-a părăsit, ci doar prin intermediul a cel puţin unui alt proces de la care să revină apoi la cel iniţial.

Un flux de date spre un loc de stocare înseamnă actualizare (modificare valori, ştergere).

Un flux de date dinspre un loc de stocare înseamnă restaurare sau folosire date.

Un flux de date se denumeşte printr-un substantiv sau mai multe, semnificând transferul unui pachet de date.

Odată construite diagramele de flux a datelor (fizice), utilitatea lor în procesul de analiză a sistemului, de identificare a deficienţelor sale funcţionale şi de stabilire a direcţiilor de perfecţionare este deosebită, cu atât mai mult cu cât experienţa analiştilor este mai mare.

Dar, pentru a ne baza pe analiza lor, diagramele de flux trebuie să fie corecte, în sensul că trebuie să îndeplinească un set de cerinţe minimale, cum sunt:

Diagramele trebuie să fie complete, adică să includă toate componentele sistemului obiect (analizat). În acest sens se verifică dacă toate fluxurile de date au o finalitate, duc undeva şi dacă nu au rămas entităţi sau procese în afara diagramelor, deci nelegate de ceva.

Diagramele trebuie să fie consistente, adică descrierea unui nivel trebuie să fie compatibilă cu descrierea nivelului superior sau a celor inferioare.

Diagramele de flux a datelor să fie completate cu diagramele stărilor de tranziţie, pentru a scoate astfel în evidenţă şi timpul, ca element determinant.

102

Contează în acest sens că un proces se produce la un moment sau altul, că un flux de date are loc zilnic, săptămânal, lunar, etc.

Observaţie:Procesul de descompunere a diagramelor este şi rămâne totuşi un proces

subiectiv, depinzând atât de complexitatea sistemului analizat, cât şi de experienţa analistului sau a echipei de proiectare. Acesta va decide când se opreşte descompunerea, ce nivel de detaliere este cel mai bun pentru analiza datelor şi a proceselor de transformare a acestora.

Astfel, din analiza diagramelor, analistul poate identifica următoarele deficienţe:

- fluxurile de date redundante, care vor putea fi apoi eliminate ;- datele cerute de diverse procese, care nu sunt însă folosite (date nefolosite);- date actualizate în mai multe locuri, ceea ce duce la inconsistenţa acestora în

sistem; ele vor trbui să fie corect preluate şi actualizate în mod unic în viitorul sistem proiectat.

4.4 Modelul logic al prelucrărilor

Diagrama fluxului de date logice (DFDL) este o reprezentare simbolizată a unui sistem, care evidenţiază procesele sistemului, precum şi intrările sau ieşirile de date în/din procese. Prin ea se reprezintă natura logică a sistemului, ce activităţi efectuează sistemul, fără să specifice cum, unde sau de către cine sunt executate activităţile1. Prin urmare, DFDL pune în evidenţă funcţiile executate de sistem.

Modelul logic al prelucrărilor descrie procedurile logice pe baza următoarelor criterii: omogenitatea prelucrărilor, frecvenţa acestora, locul lor de desfăşurare şi recursivitatea prelucrărilor. Procesele sunt reprezentate în cercuri prin verbe, care descriu acţiunea de executat.

Astfel, în cadrul modelului logic al prelucrărilor vom identifica proceduri pentru:

- actualizarea bazei de date;- exploatarea bazei de date;- salvarea şi/sau restaurarea bazei de date;- reorganizarea bazei de date;- protecţia şi securitatea datelor;- dirijarea tuturor acestor prelucrări.

1 Dumitru Oprea, Analiza şi proiectarea sistemelor informaţionale economice, Ed. Polirom 1999, pag 217

103

Pentru fiecare procedură se descriu prelucrările ce trebuie executate:- meniuri, submeniuri şi ecrane de introducere/extragere a datelor;- validări, prelucrări asociate ecranelor;- liste, rapoarte ce vor fi generate, etc

În modelul logic al prelucrărilor se acordă o atenţie deosebită succesiunii operaţiilor de executat, grupării lor în proceduri de actualizare şi proceduri de exploatare a bazei de date, precum şi interfeţei cu utilizatorul. Interfaţa reprezintă o componentă deosebit de importantă a noului sistem, deoarece permite accesul utilizatorului la funcţiile aplicaţiei, precum şi fluxul de informaţii de la calculator la utilizator şi invers1. Caracteristicile interfeţei, accesibilitatea, forma ei contribuie în mare măsură la succesul sau insuccesul unei aplicaţii.

Descompunerea DFD logice se face de sus în jos, sistemul analizat fiind considerat ca un întreg alcătuit din mai multe subsisteme care interacţionează între ele. Prin această descompunere succesivă se identifică tot mai multe detalii ale sistemului obiect.

Observaţie:Logica proceselor de prelucrare se poate reprezenta utilizând instrumente de

analiză precum:- engleza structurată;- tabele de decizie;- arbori decizionali;- diagrame sau tabele ale stărilor de tranziţie.

Problemă:

Se consideră o firmă de publicitate. Să se analizeze fluxul informaţional al activităţii de Prestări servicii publicitate şi să se reprezinte diagrama fluxului de date şi modelul prelucrărilor.

1 Victoria Stanciu, Proiectarea sistemelor informatice de gestiune, Ed.Cison, 2000, pag.154

104

105

Urmează, în mod firesc, descrierea procedurilor şi a documentelor.Descrierea procedurilor:

1.Clientul trimite o cerere de ofertă către firma noastră, la departamentul de publicitate.

2. Cererea este înregistrată în Registrul de cereri al firmei.

3. Se numerotează cererea clientului.

4.Oferta este trimisă directorului firmei .

5.Pe baza ofertei se încheie un contract de colaborare între cele două firme.

6. Dep de contabilitate al firmei noastre de publicitate emite factura pe baza contractului încheiat.

7.Factura este trimisă către departamentul de plăţi al clientului.

8.Departamentul de plăţi emite ordinul de plată sau fila CEC.

9.Ordinul de plată sau fila CEC este trimisă departamentului de contabilitate al firmei noastre de publicitate.

10.Departamentul de contabilitate emite chitanţa către client atunci când primeşte ordinul de plată.

106

5. METODOLOGII CLASICE ŞI MODERNE DE REALIZARE A SISTEMELOR INFORMATICE

Sinteza etapelor de realizare a sistemelor informatice

Proiectarea şi realizarea unui sistem informatic presupune, din partea echipei de proiectare, formată de regulă din specialişti în informatică (analişti, programatori, ingineri de sistem şi administratori de baze de date) o activitate laborioasă, grupată în mai multe etape, fiecare având sarcini şi finalităţi bine stabilite.

Indiferent de metoda de proiectare şi realizare adoptată, pentru sistemele complexe se impune o descompunere pe subsisteme, pe unul sau mai multe nivele. Proiectarea unor astfel de sisteme informatice complexe necesită ca urmare mai întâi o proiectare globală, de ansamblu, în care sunt identificate şi precizate subsistemele, relaţiile dintre ele şi aplicaţiile componente, colecţiile de date comune, intrările şi ieşirile din sistem. Proiectarea de detaliu şi realizarea programelor se face la nivel de subsistem, pentru fiecare aplicaţie în parte, ţinând cont de cadrul general trasat în proiectarea de ansamblu.

Date fiind importanţa şi specificul acestor activităţi, se impune să facem câteva precizări cu privire la activitatea de proiectare şi realizare a sistemelor informatice:

Proiectarea este prin esenţa ei, o activitate prospectivă , căci un proiectant îşi imaginează un produs care este inexistent în acel moment. El pleacă de la caracteristicile dorite ale sistemului pentru ansamblul de componente propuse şi determină caracteristicile necesare acestor componente. În sarcina sa cade determinarea structurii sistemului având cerinţele şi obiectivele definite iniţial. În acest context, proiectarea constituie o activitate orientată spre un scop şi desfăşurată în mod iterativ, prin verificări şi corectări succesive ale proiectului.

Prin conţinutul ei complex şi diversificat, prin natura dificultăţilor întâmpinate în soluţionarea problemelor, activitatea de proiectare necesită specialişti cu experienţă, cu aptutudini imaginativ-creative. Proiectantul trebuie să mai fi participat la elaborarea altor proiecte informatice şi să aibă cunoştinţe de programare, altfel ar fi dificil să propună structuri fezabile care să poată fi programate uşor.

Participarea la proiecte anterioare similare poate, pe baza cunoştinţelor acumulate, să-i ofere un prototip pe care să se bazeze noul proiect.

Oricum, multe din activităţile de proiectare necesită intuiţie şi elaborarea unor decizii, mult mai uşor de luat dacă proiectantul a învăţat dintr-o experienţă anterioară. Abordarea unor probleme din ce în ce mai complexe împreună cu utilizarea de metode, tehnici şi instrumente evoluate, solicită proiectantul să creeze noi elemente, combinaţii ale acestora, structuri noi, perfecţionate, cu alte cuvinte să inoveze mereu. Pentru fiecare nou sistem proiectantul selectează şi ajustează un model existent sau propune unul nou. Astfel, capacitatea creativă a

107

proiectantului îi permite acestuia alegerea tipului de model, a variantei convenabile. Este semnificativ faptul că aici se construieşte mai întâi modelul şi apoi se realizează produsul program corespunzător.

Astfel, dacă la proiectarea unui sistem informatic avem de-a face cu un important potenţial de creativitate al proiectantului, dublat de cunoştinţe şi experienţă în domeniu, atunci putem spera într-o calitate deosebită a proiectului şi deci şi a sistemului proiectat.

Am văzut că există o serie de metodologii de proiectare a sistemelor informatice / aplicaţiilor informatice, cu activităţi specifice şi documentaţie corespunzătoare. Dintre acestea vom prezenta o metodologie clasică (IBM sau ICI) şi dintre metodologiile moderne pe cea denumită SSADM.

Deşi ar părea că activitatea de proiectare şi realizare efectivă a unui sistem informatic este doar sarcina proiectantului specialist, practica dovedeşte în mod constant că reuşita unui sistem informatic, calitatea lui şi modul cum este primit şi utilizat de beneficiar depinde, în mare măsură, de implicarea directă a acestuia în diferitele etape ale proiectării. De modul de colaborare dintre echipa de proiectare şi beneficiar depinde, în mare măsură, succesul final al sistemului proiectat.

5.1. Metodologia IBM (ICI)

Metodologiile clasice cuprind practic metodologia IBM, preluată şi impusă în România sub denumirea de metodolodia ICI (Institutul Central de Informatică), ca metodologie unitară şi obligatorie pentru toţi ofertanţii de produse software. Practica şi experienţa în utilizarea acestei metodologii de către specialişti timp de mulţi ani face ca ea să rămână în continuare o metodologie larg utilizată de către proiectanţii de sisteme informatice şi produse program la cheie. Această metodologie cuprinde, în succesiunea lor logică, următoarele etape:

ETAPA I. Studiul şi analiza sistemului existent sau Tema de realizare

Obiectivul etapei: definirea cerinţelor şi sferei de cuprindere a sistemului informatic.

Documentaţia elaborată: Tema de realizare – care aparţine metodologiei ICI sau Dosarul de studiu şi analiză a sistemului existent – care aparţine metodologiei IBM.

Activităţi specifice:

A. Studiul sistemului existent, cuprinzând:1. caracteristici generale

profilul unităţii economice specificul activităţii unităţii economice nomenclatorul de produse / servicii prestate

108

2. studiul cadrului organizatoric studiul structurii organizatorice studiul metodelor şi stilului de conducere

3. studiul activităţilor de bază (fluxul tehnologic)4. studiul sistemului informaţional existent

studiul ieşirilor studiul intrărilor studiul circuitelor şi fluxurilor informaţionale studiul sistemelor de codificare a datelor

5. studiul activităţii de informatică dotarea cu tehnică de calcul (numărul, structura şi amplasarea

calculatoarelor) personal de specialitate (număr analişti, programatori, operatori,

ingineri de sistem, administratori baze de date, etc) aplicaţii informatice în exploatare curentă aplicaţii informatice în curs de proiectare modul de organizare a datelor

B. Analiza (evaluarea) actualului sistemObiectiv: diagnosticarea sistemului existent, adică identificarea neajunsurilor

actualului sistem.1. Definirea criteriilor de evaluare

din punct de vedere al gradului de utilizare a capacităţilor de producţie din punct de vedere al productivităţii muncii din punct de vedere al costurilor de producţie din punct de vedere al utilizării forţei de muncă din punct de vedere al materiilor prime din punct de vedere al satisfacerii cerinţelor etc.

Se identifică şi se specifică aşa numitele puncte forte şi puncte slabe din punct de vedere al cerinţelor informaţionale ale conducerii.

În concluzie se precizează punctele în care actualul sistem informaţional nu satisface cerinţele informaţionale ale conducerii.

2. Elaborarea sugestiilor (direcţiilor) de perfecţionare. În această etapă se stabilesc direcţiile de perfecţionare ale noului sistem

informaţional.

C. Definirea variantelor de perfecţionare a actualului sistem1. elaborarea variantelor2. estimarea eficienţei economice pentru fiecare variantă

109

costuri efecte economice (directe şi indirecte)

3. analiza şi alegerea variantei de sistem.

ETAPA II. Proiectarea de ansamblu (conceperea noului sistem)

Obiectivul etapei: elaborarea proiectului de ansamblu.Activităţi specifice:1. definirea obiectivelor sistemului informatic2. structura sistemului informatic pe subsisteme3. definirea ieşirilor (situaţii de informare / raportare)4. definirea intrărilor (documente primare sau alte intrări)5. definirea sau alegerea modelului matematic implementat6. definirea sau alegerea modului de organizare a datelor

fişiere baze de date

7. [ alegerea S.G.B.D.-ului ]8. alegerea variantei tehnice de prelucrare a datelor9. elaborarea schemei de ansamblu a sistemului informatic10. [ arhitectura noului sistem ]11. elaborarea planului de realizare a sistemului informatic

ETAPA III. Proiectarea de detaliu

Obiectivul etapei: Proiectarea logică şi fizică (tehnică) de detaliu a fiecărei componente a sistemului informatic.

Documentaţia elaborată: 1. proiectul logic de detaliu 2. proiectul fizic (tehnic) de detaliu

Activităţi specifice:1. proiectarea ieşirilor2. proiectarea intrărilor3. proiectarea organizării datelor

fişiere nivel logic nivel fizic

baze de date nivel logic nivel conceptual (virtual) nivel fizic

4. proiectarea sistemului de codificare a datelor

110

5. proiectarea procedurilor de control şi validare a datelor6. proiectarea fluxului tehnologic de prelucrare automată a datelor

ETAPA IV. Programarea

Obiectivul etapei: Asigurarea cu resurse software prin efort propriu sau achiziţie necesare fiecărei aplicaţii. În această etapă este implicată de regulă numai echipa de proiectare.

Documentaţia elaborată:1. manualul de prezentare – apare ca o descriere a produsului software

sub aspectul resurselor hardware necesare, problemelor pe care le rezolvă, performanţelor propuse a fi realizate, anumite restricţii referitoare la program.

2. manualul de utililizare – este destinat utilizatorilor finali ai sistemului.3. manualul de exploatare – este destinat analiştilor sau programatorilor

din unitatea beneficiară în scopul de a putea întreţine şi dezvolta sistemul în concordanţă cu modificările ce apar în cadrul unităţii beneficiare.

Activităţi specifice:1. elaborarea specificaţiilor de programare2. elaborarea schemelor logice de program cu datele de test necesare3. elaborarea programelor4. testarea programelor şi lanţurilor de programe5. elaborarea documentaţiei de programare

ETAPA V. Implementarea noului sistem

Obiectivul etapei: Testarea şi verificarea performanţelor sistemului în condiţii concrete de funcţionare (în mediu real).

Documentaţia elaborată: Comportă aspectul unui proces verbal de recepţie; în cadrul raportului se precizează persoanele care au participat din partea executantului şi a beneficiarului la implementarea sistemului, condiţiile în care a avut loc implementarea.

Activităţi specifice:1. pregătirea personalului unităţii beneficiare pentru exploatarea curentă a

sistemului2. asigurarea condiţiilor necesare pentru trecerea la starea de implementare

a sistemului3. încărcarea fişierelor sau bazei de date sau conversia fişierelor4. alegerea strategiei şi tacticii de implementare5. implementarea propriu-zisă (testarea sistemului)6. verificarea performanţelor noului sistem

111

7. actualizarea şi definitivarea documentaţiei de sistem în concordanţă cu modificările efectuate pe parcursul perioadei de implementare

8. întocmirea raportului de implementare9. elaborarea planului de implementare10. [ omologarea sistemului ]

ETAPA VI. Exploatarea şi întreţinerea curentă a sistemului

Se are în vedere exploatarea curentă a sistemului precum şi adaptarea sistemului la noile cerinţe ale utilizatorilor sau la modificările intervenite pe parcurs în cadrul unităţii beneficiare.

5.2. Metodologia S.S.A.D.M. (Structured System Analysis and Design Method)

        Metodologia SSADM (Structured Systems Analysis and Design Method) a fost elaboratã în Marea Britanie, servind iniţial pentru realizarea sistemelor informatice din domeniul public. Ea a fost ulterior utilizată pe scară din ce în ce mai largă, devenind astăzi o metodologie cunoscută şi aplicată cu succes în domeniul proiectării şi realizării efective a sistemelor informatice.

        Metodologia SSADM se poate caracteriza prin următoarele: este o metodologie modernă de proiectare sisteme informatice face parte din categoria metodelor sistemice de proiectare este orientată pe structurarea datelor se bazeazã pe specificarea clară a cerinţelor şi a unor reguli precise pentru

proiectarea celor două modele Metodologia se caracterizează deasemenea prin faptul că pune în evidenţă

două modele: modelul logic şi modelul fizic, separând astfel proiectarea logică de cea fizică. Ea face apel la utilizarea reprezentărilor grafice, folosind în acest sens o multitudine de diagrame. Iniţial se defineşte o diagramă contextuală (de nivel zero) prin care se pune în evidenţă aria de cuprindere a problematicii de interes; din aproape în aproape diagrama se descompune până se ajunge la module terminale, uşor de programat. Acestea se pot constitui ca module ale aplicaţiei sau sistemului ce va fi realizat.

În cadrul acestei metodologii sunt definite mai multe etape, ale căror activităţi sunt riguros precizate.

ETAPA I. Studiu de fezabilitate

În unele metodologii această etapă mai poartă denumirea de studiu preliminar, studiu de oportunitate sau de diagnosticare. În cadrul ei se urmăreşte

112

identificarea globală a neajunsurilor sistemului existent şi stabilirea necesităţii şi oportunităţii trecerii la proiectarea unui nou sistem informatic.

Studiul de fezabilitate se realizează pentru sistemele complexe sau pentru aplicaţii extrem de severe sub aspectul exactităţii datelor, realităţii şi termenelor de predare a lucrărilor.

Studiul precizează graniţele sistemului proiectat, cu alte cuvinte care este tema de realizare, care sunt neajunsurile sistemului existent (să nu uităm faptul că poate exista un sistem informatic sau o aplicaţie informatică, dar acestea să nu mai satisfacă cerinţele informaţionale, să nu mai corespundă dotării actuale sau structurii organizatorice actuale, deci să fie necesară reproiectarea sau chiar înlocuirea lor), care trebuie să fie performanţele noului sistem şi timpul de realizare a acestuia.

ETAPA II. Analiza cerinţelor sistemului

Această etapă poate fi asociată cu studiul şi analiza sistemului existent din cadrul metodologiilor clasice. Are ca scop cunoaşterea sistemului fizic existent şi identificarea problemelor şi deficienţelor acestuia. Se recurge la un studiu complex privind activităţile şi fluxurile informaţionale existente, volumul informaţiilor de prelucrat precum şi aria de cuprindere a sistemului informaţional. Pe baza acestui studiu se elaborează diagramele de flux a datelor (DFD) parcurgând următorii paşi:

se întocmeşte o listă a documentelor fizice implicate în sistemul obiect se trasează diagrama fluxului documentelor (DFD) se elaborează primul nivel al DFD-urilor prin enumerarea proceselor

(prelucrărilor) care vor fi realizate pentru fiecare document.Pe baza studiului realizat se recurge la analiza sistemului informaţional pentru

a fundamenta direcţiile de perfecţionare ale sistemului existent şi înlocuirea lui cu un sistem informatic care să permită satisfacerea tuturor cerinţelor informaţionale necesare conducerii.

Practic, în această etapă se prezintă, în urma documentării, a investigării şi analizei efectuate, următoarele:

a. Prezentarea societăţii, principalele sale activităţi, principalii indicatori ce caracterizează activitatea acesteia, pentru a dovedi şi faptul că aceasta îşi poate permite realizarea unei lucrări de informatizare într-un anumit domeniu sau în toate, aşa cum s-a cerut.

b. Structura organizatorică a societăţii, reprezentată grafic prin organigrama sa, va crea o imagine asupra structurii funcţionale şi organizatorice a societăţii, va scoate în evidenţă principalele relaţii dintre compartimentele societăţii şi dintre aceasta şi mediul extern.

113

c. Prezentarea activităţii sau sistemului obiect se realizează în urma unui studiu aprofundat al activităţii domeniului sau subsistemului ce urmează a fi informatizat din cadrul societăţii analizate, pentru a surprinde şi a descrie toate documentele care circulă în sistem, toate datele şi procesele de prelucrare a acestora, modelele matematice utilizate în prelucrarea datelor, termene de realizare, condiţii de validare, etc.

d. Conducerea activităţii analizate descrie structura de conducere a activităţii analizate, principalele atribuţii şi competenţe ale ale acesteia, încercând să stabilească cerinţele informaţionale, termene, condiţii de prezentare.

e. Modelul fizic al sistemului existent Se ştie că DFD este o reprezentare grafică a transformării datelor de intrare în

date de ieşire, folosind un set de simboluri de reprezentare şi având asociat un set de reguli de completare si validare.

Utilizând metodologia SSADM diagramele de flux a datelor se pot realiza cu ajutorul următoarelor simboluri:

Proces (prelucrare, transformare): Procesele sunt etichetate cu text ce sugerează modul de transformare a datelor şi sunt identificate printr-un număr. În DFD fizică a sistemului existent, se precizează şi locaţia (compartimentul / persoana) procesului.

Flux de date: este constituit din datele transmise între două procese. Fluxul de date e etichetat printr-un substantiv ce sugereazã informaţia sau pachetul de informaţii transmise.

Entitate externă: poate fi o sursă sau un receptor de date, sau poate fi un alt sistem (firmă, compartiment).

Stoc de date: un depozit temporar sau permanent de date. El poate fi un depozit:  

manual, format din registre, dosare, arhivă de documente

pe suport magnetic, sub formă de fişiere sau baze de date.

        Dacă sistemul analizat şi descris cu ajutorul DFD este complex, nu vom putea realiza de la început o DFD detaliată. Şi, cum metodele structurate propun o abordare de tip Top-Down, vom realiza o descompunere funcţională a sistemului, prin rafinarea succesivă a proceselor de prelucrare.

 Primul nivel (nivelul 0) îl constituie Diagrama Contextuală, care va defini graniţele între sistemul analizat şi mediu. Nivelele următoare se vor obţine prin

114

rafinarea proceselor complexe în diagrame de nivel inferior, respectând regulile de descompunere cunoscute.

În cadrul acestei etape se realizează mai întâi modelul datelor pentru sistemul existent.

Modelul datelor pune în evidenţă pe de o parte datele din interiorul sistemului, iar pe de alta legăturile care există între acestea. Analiza datelor astfel identificate se realizează apoi independent de modul de utilizare a lor în cadrul sistemului (procesele de prelucrare).

Pentru construirea modelului fizic al datelor se parcurg următorii paşi: 1. Identificarea entităţilor . 2. Identificarea relaţiilor dintre entităţi. Se poate construi în acest sens o

matrice a entităţilor pentru a analiza şi identifica relaţiile între entităţi. 3. Întocmirea modelului entitate - asociere.    Pentru fiecare asociere dintre entităţi se determină:

- semnificaţia, exprimată printr-un verb;   - tipul legăturii, dat de cardinalitatea acesteia (1:1, 1:M, M:M)

 f. Modelul logic al sistemului existent    Pornind de la modelul fizic al sistemului existent, se va obţine prin derivare,

modelul logic al aceluiaşi sistem. Acesta este deosebit de util pentru analiza sistemului existent şi identificarea cât mai corectă a direcţiilor sale de perfecţionare, deoarece:       

pune în evidenţă funcţiunile de bază ale sistemului; permite identificarea şi eliminarea problemelor legate de redundanţa

datelor şi duplicarea proceselor de prelucrare; permite stabilirea cu o precizie mai mare a graniţelor sistemului prin

eliminarea proceselor manuale care nu pot fi automatizate complet. pune în evidenţă ce face sistemul, eliminând detaliile referitoare la modul

cum funcţionează sistemul în implementarea actuală;    Construirea modelului logic presupune transformarea diagramei de flux a

datelor fizică în diagrama de flux a datelor logică.   Procesul de derivare a modelului logic va începe de la ultimul nivel de

descompunere al proceselor şi va continua prin agregarea acestora către nivelele superioare. Pentru aceasta se vor parcurge următorii paşi:

1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor, prin gruparea într-un stoc logic de date a entităţilor înrudite sau utilizate frecvent.

După identificarea stocurilor logice de date se construiesc: - diagrama de corespondenţă între stocurile logice şi entităţile din modelul logic;- diagrama de corespondenţă între stocurile logice şi stocurile fizice de date.

115

2. Înlăturarea dependenţelor fizice şi temporale din cadrul proceselor şi a fluxurilor de date (din DFD la nivel fizic)

3. Derivarea proceselor logice, care impune următoarele activităţi: scoaterea în afara graniţelor sistemului a proceselor manuale care nu pot fi

automatizate (deciziile); identificarea şi înlocuirea proceselor care nu realizează nici o transformare

asupra fluxurilor de date cu cele corecte, reale; combinarea proceselor care realizează prelucrări asemănătoare sau

multiple, care se execută împreună sau în secvenţă; înlăturarea proceselor care ţin de implementarea actuală şi a proceselor

redundante.     De exemplu, în cazul unei aplicaţii de gestiune stocuri de materiale, putem

avea: se combină procesele Ieşire de materiale din gestiune şi Intrare de materiale în gestiune, deoarece realizează prelucrări asemănătoare. Se introduce un atribut de genul: tip operaţie, de tip caracter, care va putea lua valorile I pentru Intrare şi E pentru Ieşire.

 4.  Derivarea fluxurilor logice care presupune înlocuirea numelui de document numai cu fluxul de informaţii utilizate efectiv de proces.     5. Gruparea proceselor elementare şi transformarea diagramei fizice în diagramã logicã, aplicând cei 5 paşi.

g). Catalogul cerinţelorPe baza analizei modelului logic al sistemului existent, se

poate elabora catalogul cerinţelor pentru noul sistem, care pot fi descrise într-un tabel de forma:

Nr.crt. Cerinţa Sursa Soluţia

1.Înregistrarea comenzilor emise de clienţi

clienţi COMENZI

2.Înregistrarea facturilor de desfacere

Financiar-contabilitate

FACTURI

3. Înregistrarea încasãrilor beneficiar ÎNCASÃRI

4. Securitatea datelor analizã SGBD

5.Refacerea datelor în caz de incident

analizã SGBD

ETAPA III. Specificarea cerinţelor pentru sistemul cerut

Activităţile din cadrul acestei etape se realizează în mai mulţi paşi. Iniţial se înlătură deficienţele privind organizarea sistemului existent, se construieşte un model al noului sistem prin modificarea DFD-urilor logice şi a structurii logice a

116

datelor. În final se construieşte un catalog al cerinţelor şi al entităţilor; pentru fiecare entitate se prezintă evoluţia în timp a acesteia.

Prin urmare, se porneşte de la modelul logic al sistemului existent, realizat în etapa de analiză şi de la catalogul cerinţelor formulat pe baza acestuia şi se vor  preciza în detaliu cerinţele noului sistem informatic, ce urmează a se realiza.

Această etapă realizează practic trecerea de la etapa de analiză la cea de proiectare a noului sistem.

Metodologia SSADM prevede şi aici parcurgerea mai multor paşi, bine identificaţi şi anume:

a). Definirea soluţiei de realizare a noului sistem (aplicaţii informatice)  În această etapă se realizează o descriere a noului sistem, atât din punct de

vedere al cerinţelor funcţionale ale acestuia, cât şi din punctul de vedere al costurilor pe care le implică, al condiţiilor de dotare, de personal şi software pe care le impune societăţii în vederea implementării lui ulterioare. Ca urmare, se vor realiza următoarele activităţi:

Descrierea noului sistem, prin prisma următoarelor aspecte:        Cerinţe funcţionale, care se referă la activităţile, la funcţiunile pe care

sistemul informatic trebuie să le realizeze. Se pot formula şi cerinţe noi, legate de posibilităţile suplimentare de informare, de prelucrare pe care le oferă prelucrarea automată. De exemplu:

- Se creazã fişierul Comenzi în care sunt înregistrate comenzile emise de clienţi.

- Se creazã fisierul Facturi Desfacere în care sunt înregistrate facturile pentru produsele livrate.

- Se creazã fisierul Incasări, în care se înregistreazã încasările în numerar si prin virament de la clienţi, primite de la Serviciul Financiar - Contabilitate.

    Cerinţe nefuncţionale, care precizează, de exemplu, cine sunt utilizatorii sistemului, ce pregătire trebuie să aibă pentru a putea utiliza viitorul sistem, cum se pot reface fişierele, baza de date în caz de incident, cum se arhivează şi cât timp trebuie să fie ele păstrate, etc.

    Restricţiile impuse de noul sistem, cum ar fi necesitatea unei dotări minime, necesitatea asigurării legăturilor cu celelalte aplicaţii existente în funcţiune în cadrul societăţii, necesitatea alinierii la sistemul de codificare existent sau necesitatea reproiectării lui, restricţii de ordin legislativ, etc.   

Analiza cost-beneficiu         Se ştie că proiectarea şi realizarea efectivă a unui sistem informatic

necesită o activitate laborioasă a unui număr adeseori mare de specialişti de înaltă clasă în domeniul informaticii. În aceste condiţii, se va determina costul de realizare a sistemului informatic, adică preţul plătit proiectantului pentru realizarea sistemului informatic, la care se adaugă costurile suportate de societatea

117

respectivă pentru instruirea personalului care va utiliza sistemul, precum şi costul determinat de achiziţionarea unor componente hardware performante (calculatoare, plăci de reţea, componente multimedia,etc) şi software (licenţe pentru sisteme de operare, programe utilitare, limbaje de programare sau sisteme de gestiune a bazelor de date necesare).

  Se va estima deasemenea costul de funcţionare a sistemului informatic în cadrul societăţii; de regulă acesta nu este semnificativ dacă societatea respectivă avea calculatoare şi lucrări în funcţiune, deci avea şi un minim de personal calificat în domeniu.

  Cunoscând aceste costuri, se impune calculul beneficiului obţinut prin realizarea sistemului respectiv, a timpului de recuperare a investiţiei efectuate. Adeseori, beneficiul constă în calitatea deosebită a informaţiilor furnizate şi economia de timp pe care o aduce prelucrarea automată a datelor, cu efecte benefice asupra fundamentării şi derulării actelor decizionale, reflectate într-o mai bună relaţie cu furnizorii şi clienţii, cu personalul din interior şi cu piaţa şi creşterea, în acest fel, a profitului realizat.

Analiza impactului introducerii sistemului informatic Analiza impactului noului sistem este în stânsă dependenţă cu stadiul societăţii

la momentul respectiv legat de existenţa sau inexistenţa altor aplicaţii informatice în cadrul ei, ceea ce înseamnă practic existenţa sau nu a unui personal calificat în domeniu. Deasemenea trebuie precizat dacă introducerea noului sistem atrage după sine sau nu modificări în structura organizatorică a societăţii. Se specifică deasemenea dacă este necesară o pregătire a personalului care va utiliza sistemul în cadrul unor cursuri de lungă durată sau va fi suficientă instruirea făcută de colectivul de proiectare la implementarea sistemului.

b). Definirea prelucrărilor sistemuluiÎn această etapă se realizează diagrama de flux a datelor la nivel logic pentru

noul sistem. Se analizează cerinţele funcţionale ale noului sistem şi se stabileşte dacă se păstrează toate funcţiunile acestuia sau nu, dacă apar funcţiuni suplimentare. Se construieşte, în mod corespunzător, noua diagramă de flux a datelor la nivel logic pentru noul sistem, care poate fi identicã cu cea pentru sistemul existent sau poate să difere.

Se descriu apoi, într-o formă tabelară, fluxurile de intrare şi de ieşire, se descriu entităţile externe, stocurile de date şi procesele elementare de prelucrare. Exemplu:       

Descrierea fluxurilor de intrare / iesire

    Sursa DestinatiaNume flux

Continutul fluxului

118

Desfacere 1.Înregistrare facturi desfacere

facturã desfacere

Codclient, Denclient, Adresac,  Contc, Banca_C, Denprod, Um, Cant, Pu, Tva, Datafactd, Nrfactd, Totalfactd

Serv. Contabilitate financiarã

2. Înregistrare încasãri

Situaţia încasãrilor în numerar

Codclient, Denclient, Nrfactd,   Datafactd, Sumaîncasatã,   Dataîncasãrii

   c). Definirea datelor din sistem

Dacă au fost stabilite funcţiile noului sistem, pe diagrama entitate asociere se pot opera modificările care decurg din funcţiunile stabilite.

Dacă au fost eliminate unele funcţiuni, atunci trebuie eliminate şi datele corespunzătoare acestora şi invers, dacă au fost introduse funcţiuni noi, trebuie introduse şi noile date, aferente lor.

Se obţine astfel modelul logic al noului sistem, pentru care se realizează în paralel şi descrierea entităţilor, într-o formă tabelară, cum ar fi de exemplu:

Entitatea CLIENTI

Atribut Natura Lungimea Cheia Primară Chei externeCODCLIENT N 4 X  

DENCLIENT C 15    

ADRESAC C 20    

CONTC  N 18    

BANCA_C C 5    

SOLD N 9    

 d). Definirea funcţiilor

   În metodologia SSADM funcţia reprezintă un concept de bază care se referă la un set de procese sau prelucrări care, din punct de vedere al utilizatorului, se executã împreună, de la început până la sfârşit.

   Majoritatea funcţiilor de bază ale unui sistem se regăsesc în opţiunile din meniul aplicaţiei; există însă şi funcţii care nu apar explicit în meniu, dar sunt realizate în cadrul sistemului. Funcţiile sunt identificate în cadrul diagramei de flux a datelor, fiecare proces elementar urmând să fie alocat cel puţin unei funcţii.

 Clasificarea funcţiilor se poate realiza după mai multe criterii, cum sunt:     1. După modul de iniţiere, putem identifica:

119

funcţii iniţiate de utilizator sau de o altă entitate externă sistemului; funcţii iniţiate de sistem fie la un anumit interval de timp, fie ca urmare a

rezultatelor unui proces de prelucrare.     2. Dupã efectul pe care îl au asupra sistemului, putem identifica: funcţii de actualizare, care modifică datele din cadrul sistemului; funcţii de interogare, care se regăsesc în catalogul cerinţelor şi parţial în

diagrama de flux a datelor.     3. După modul de operare, putem identifica: funcţii care se execută on-line, realizate în regim de lucru interactiv prin

dialog cu utilizatorul; funcţii care se execută off-line, care pot fi iniţiate fie de sistem, fie de

utilizator şi care sunt lăsate să-şi urmeze cursul fără alte intervenţii.   Corespondenţa dintre funcţii şi procesele de prelucrare este determinată de

gradul de detaliere a proceselor în cadrul diagramelor. Dacă diagrama este foarte detaliată, atunci o funcţiune va grupa mai multe procese. Dacă diagrama nu este detaliată, fiecare proces poate deveni o funcţie.

  Dacă un proces se realizează întotdeauna împreună cu un alt proces, atunci ele vor fi grupate într-o singură funcţie.

 Odată definite funcţiile sistemului, se poate trece la realizarea matricei de corespondenţă entitate-funcţii. Această matrice pune în evidenţă aspectul dinamic al sistemului, adică efectul pe care îl au în timp funcţiile sistemului asupra entităţilor din sistem. Acest efect pe care o funcţie îl poate avea asupra unei entităţi poate fi:

creare sau adăugare (inserare): C/I modificare: M ştergere: S arhivare: A consultare, interogare: R salvare, etc   Fiecare entitate are un ciclu propriu de viaţă, care pune în evidenţă viaţa

entităţii, din momentul creerii sale şi până în momentul distrugerii sau arhivării. Se construieşte câte o astfel de diagramã pentru fiecare entitate din modelul entitate asociere. De exemplu, pentru entitatea Produse:

  

ETAPA IV. Specificarea sistemului logic

120

PRODUSE

Actualizare PRODUSE

Analiza stocurilor de produse

Această etapă poate fi asociată direcţiilor de perfecţionare a actualului sistem din cadrul metodologiilor clasice. Astfel, se propun beneficiarului mai multe variante, ca soluţii de realizare a viitorului sistem.

Acestea sunt analizate de beneficiar şi în urma discuţiilor purtate se alege o anumită opţiune sau combinaţie de opţiuni pentru proiectarea noului sistem. Opţiunea selectată va fi descrisă precizând:

detalii tehnice referitoare la dotarea hardware şi software propusă; modul de lucru al noului sistem; costurile implicate de proiectarea, realizarea şi funcţionarea sistemului.Se vor preciza aspecte legate de posibilităţile viitoare de perfecţionare, de

întreţinere şi de dezvoltare a sistemului. În urma aprobării de către beneficiar se va trece la proiectarea logică de detaliu a datelor şi prelucrărilor (procedurilor). Proiectarea datelor va duce în final la definirea entităţilor ce vor constitui baza de date. Proiectarea procedurilor se va face elaborând mai întâi schiţe detaliate ale proceselor, apoi agregarea acestora. Proiectarea datelor şi procedurilor se realizează în paralel şi se intercondiţionează permanent.

În această etapă se realizează proiectarea şi descrierea noului sistem, prin următoarele sale componente:

a). Proiectarea ieşirilor Proiectarea ieşirilor la nivel logic presupune specificarea structurilor logice

pentru fluxurile de ieşire, adică a situaţiilor, a rapoartelor obţinute precum şi specificarea caracteristicilor lor.

Acest lucru se realizează de regulă într-un tabel de forma:

Denumire document

DestinatiaNr. de

exemplarePeriodicitate Frecventa

Situatia clienţilor debitori  

Situaţia facturilor achitate

Ordin de platã

Serv. Contab. Fin   Serv. Contab.

Fin  

Furnizor

1  

   1

3

la cerere  

  la cerere 

zilnic

lunar  

lunar  

aleator

La nivel fizic, se întocmeşte macheta situaţiei de ieşire, formatul său fizic. De exemplu, macheta pentru "Situaţia produselor vândute".  

b). Proiectarea sistemului de codificarePentru fiecare cod utilizat în cadrul entităţilor, fie drept cheie de identificare

unică (cheie primară) fie drept cheie externă sau candidat, se va preciza tipul

121

codului, lungimea şi eventual semnificaţia elementelor componente, în cazul codurilor structurate. Toate aceste informaţii se pot grupa într-un tabel de forma:

Caracteristica Atribut Natura Lungimea Structura codului

Cod produs

Cod client  

Număr operaţie  

Tip operaţie

COD_P  

COD_CLIENT     NR_OP 

TIP_OP

N  

N    

N  

C

4  

4      4  

1

cod numeric, structurat astfel: prima cifră arată grupa, următoarea subgrupa, ultimile 3 o secvenţă 

c). Proiectarea intrărilorProiectarea intrărilor la nivel logic trebuie să prezinte, pentru fiecare document

de intrare, principalele caracteristici, cum sunt, de exemplu:Denumire Sursa Periodicitate Frecventa

Comandă produseFactura aprovizionare 

Bon de consum  Situaţia încasărilor în

numerar  

ClienţiAprovizionare  

ProducţieContabilitate

financiarã

zilnic   zilnic   zilnic   zilnic

aleator   aleator   aleator   1 / sãpt

   La nivel fizic proiectarea intrărilor înseamnă proiectarea machetei fizice pentru fiecare document de intrare proiectat logic. Pentru fiecare astfel de machetă se va proiecta un ecran de introducere a datelor, se vor preciza în clar condiţiile de validare a datelor, restricţii legate de domeniul admis al valorilor acestora, condiţii de integritate a acestora. De exemplu, macheta documentului "Bon de consum".

d). Proiectarea bazei de dateProiectarea bazei de date înseamnă, şi în cadrul acestei metodologii,

proiectarea bazei de date sub cele trei forme ale sale, anume: Proiectarea schemei conceptuale a bazei de date; Proiectarea schemei externe; Proiectarea schemei fizice a bazei de date.Se are în vedere realizarea schemei bazei de date rezultate în urma procesului

de normalizare a acesteia.  Se prezintă fiecare tabelă a bazei de date, cu atributele şi descrierea acestora, cu precizarea cheilor primare şi externe.

De exemplu, tabela CLIENTI:

122

Atribute Tip Lungime Cheie

CODCLIENT   DENCLIENT   ADRESAC  

CONTC   BANCA_C  

SOLD

e). Proiectarea interfeţei cu utilizatorulÎn această etapă se proiectează şi se descrie interfaţa sistemului cu utilizatorul,

având în vedere ca toate funcţiunile identificate şi descrise în cadrul modelului noului sistem să se regăsească printre opţiunile meniului principal sau ale submeniurilor aferente.

Se poate realiza la acest nivel o diagramă de structură a noului sistem, pe baza meniurilor şi submeniurilor proiectate, deci a principalelor funcţii ale sistemului.

f). Proiectarea funcţiunilor noului sistemÎn aceastã etapă se prezintă în detaliu, atât la nivel logic, cât şi la nivel fizic,

toate componentele sistemului proiectat. Ca rezultat se obţin specificaţiile tehnice, numite şi specificaţii de programare, pe baza cărora urmează să se realizeze întreaga activitate de programare efectivă care urmează. Fiecare componentă va fi practic descrisă prin: datele de intrare, procesele, algoritmii de prelucrare a acestora, formatul şi conţinutul rapoartelor de ieşire, condiţii de validare, de restaurare sau de arhivare. În final se obţine astfel arhitectura logicã a sistemului nou care se va realiza.

ETAPA V. Proiectarea fizicăÎn această etapă se realizează, pe baza modelului logic bine pus la punct în

urma etapelor anterioare, mai întâi modelul fizic al datelor şi prelucrărilor pentru noul sistem şi apoi elaborarea programelor. Se trece apoi la realizarea documentaţiei pe baza căreia se realizează planul de testare şi implementare a sistemului sau aplicaţiei proiectate.

 Avantajele metodologiei S.S.A.D.M.:

are la bază o abordare sistemică a societăţii sau domeniului de activitate informatizat;

permite o abordare top-down a sistemului obiect; este orientată pe structura datelor; prezintă o abordare simplă a problemelor prin viziunea utilizatorului.

123

pune în evidenţă cele două modele: logic şi fizic, separând iniţial proiectarea logică de cea fizică;

utilizează o multitudine de diagrame pentru reprezentarea grafică a fluxurilor de date şi a prelucrărilor acestora;

oferă o flexibilitate mare în analiză şi proiectare. permite implementarea uşoară a sistemului informatic. documentaţia de sistem este foarte sugestivă, completă şi este aproape în

întregime redată sub formă grafică. permite utilizarea instrumentelor Case pentru asistarea proiectantului; permite o realizare modulară a componentelor sale (programe, proceduri),

o testare modulară şi chiar implementarea sistemului pe module .

5.3. Metodologia MERISE

Cu siguranţă MERISE este numele cel mai puţin cunoscut printre metodologiile de reazare a sistemelor informatice. Dezvoltarea metodei MERISE se datorează iniţiativei ministerului francez al industriei, care a venit cu propunerea realizării unei metodologii de analiză şi proiectare a sistemelor informatice de timp real ce implică manipularea informaţiilor stocate în baze de date.

În cadrul metodologiei sistemul informaţional este privit ca un obiect natural, căci reflectă activităţile de comunicare, transformare şi memorare a datelor, aşa cum sunt ele în realitate. Pe de altă parte, sistemul informaţional poate fi privit ca un obiect artificial, dacă aceste activităţi sunt automatizate, deci dacă există proceduri create pentru a fi prelucrate pe calculator. Astfel, conform acestei metodologii, proiectarea sistemului informatic constă în analiza sistemului informaţional obiect real şi proiectarea unui obiect artificial care să-l reprezinte corect şi să-i crească eficienţa. În cadrul metodologiei putem distinge trei cicluri majore: ciclul de viaţă al unui sistem, ciclul de decizie şi ciclul de abstractizare (sau ciclul de modelare). Fiecare din aceste cicluri cuprinde mai mulţi paşi de dezvoltare.

Astfel, ciclul de viaţă al sistemului cuprinde trei etape :- Concepţia sistemului, materializată într-o descriere a specificaţiilor

funcţionale şi tehnice de realizare.- Realizarea propriu-zisă a sistemului, care constă în realizarea efectivă a

programelor şi documentaţiei de utilizare.- Menţinerea sistemului, care are drept scop adaptarea continuă a sistemului

la evoluţia mediului. Ciclul de abstractizare sau de modelare este alcătuit din următorii paşi:

realizarea modelului dinamic, a celui static şi a modelului proceselor din sistem. Practic, avem de a face cu descrierea unei ierarhii cu trei nivele de abstractizare:

124

- nivelul conceptual;- nivelul organizatoric pentru prelucrări şi logic pentru date;- nivelul operaţional pentru prelucrări şi fizic pentru date.Metodologia MERISE utilizează modelul entitate-relaţie pentru analiza şi

proiectarea modelelor statice, deci a structurilor de date şi reţelele Petri pentru modelele dinamice.

MERISE nu utilizează diagramele de flux de date care fac legătura între modelul static şi cel dinamic. De aceea, pentru o analiză şi o proiectare completă şi eficientă a sistemelor informatice, se recomandă utilizarea acestei metodologii în conjuncţie cu alte tehnologii. Elementele care stau la baza operaţiei de descriere a unui proces dinamic sunt următoarele: evenimente, operaţii şi sincronizări.

Ciclul de decizie ţine seama de alegerile ce trebuie făcute în timpul ciclului său de viaţă şi privesc:

- descompunerea sistemului în subsisteme;- stabilirea orientărilor majore privind soluţiile tehnologice;- planificarea realizării sistemului, stabilirea priorităţilor, a interfeţei, etc.Etapele de realizare a sistemelor informatice corespunzător acestei metodologii

trebuie să abordeze cele trei cicluri (conceptual, organizatoric şi operaţional) şi se prezintă astfel:

- Studiu preliminar - Studiu de detaliu- Studiu tehnic- Realizarea programelor- Implementarea- Menţinerea sistemului în funcţiuneO schemă generală de construire a unui model MERISE cuprinde următorii

paşi: - construirea diagramei de flux de date utilizând o altă tehnologie; - ordonarea informaţiilor identificate şi selectate; - construirea unui model liniar MERISE; - verificarea sincronizărilor diferitelor operaţii. Rezultatele utilizării MERISE constau în crearea unei vederi de ansamblu

asupra fluxului informaţiilor, a ordinii temporale şi a interdependenţelor dintre acestea. Aceste informaţii vor fi utile atât la analiza, cât şi la proiectarea sistemului.

5.4. Metodologii de analiză şi proiectare orientate obiect (A.P.O.O.)

Ideea abordării programării, analizei şi proiectării orientate obiect este apărută la nivelul anilor 1960 când au fost concepute primele limbaje orientate obiect. Limbajele orientate obiect nu au dobândit la început un succes prea mare întrucât

125

nu existau metode de organizare a datelor în concordanţă cu filosofia orientată obiect.

După anii 1980 s-a conturat apariţia bazelor de date orientate obiect care au oferit suport pentru aplicarea limbajelor de programare orientate obiect. Însă nici în aceste condiţii limbajele de programare orientate obiect nu şi-au găsit o largă aplicabilitate.

O.M.G. (Object Management Group), consorţiu american format din peste 800 de companii ce produc şi distribuie aplicaţii informatice la a căror realizare s-a utilizat tehnologia orientată obiect, a hotărât să studieze posibilităţile de realizare a unui standard în domeniul construirii sistemelor software.

Astfel, în 1997 a fost realizat Limbajul de Modelare Unificat (U.M.L. – Unified Modelling Language).

Proiectarea şi analiza orientată obiect se bazează pe aşa numitul model obiectual. Acesta a introdus principii precum abstractizarea, încapsularea datelor, modularitatea, ierarhia şi persistenţa. Nici unul din aceste principii nu este nou, dar ceea ce este important la acest model de programare, este faptul că aduce toate aceste concepte împreună, încercând armonizarea lor prin diferite tehnici.

Proiectarea orientată obiect necesită un mod diferit de percepţie a problemelor, de înţelegere a modului cum urmează să fie analizate, proiectate şi implementate acestea. În centrul atenţiei se află noţiunea de obiect (respectiv de clasă), aceasta punându-şi amprenta asupra întregului proces de proiectare şi implementare.

Trebuie specificat faptul că, în decursul timpului, au apărut mai multe metode de analiză orientate obiect. Acestea sunt relativ asemănătoare, diferind de cele mai multe ori prin detalii nesemnificative. Printre acestea putem enumera următoarele :

- OOA/OOD (Object Oriented Analysis / Object Oriented Design); această metodă a fost elaborată de Coad şi Yourdon şi cuprinde cinci paşi: găsirea claselor şi a obiectelor, identificarea structurilor, identificarea entităţilor, definirea atributelor şi, nu în ultimul rând, definirea serviciilor. Comportamentul dinamic al diferitelor clase este specificat de diagramele de stare ale obiectelor. Această metodă oferă totodată posibilitatea de măsurare a calităţii proiectării efectuate.

- DOOS (Designing Object Oriented Software), realizată de Wirfs şi Brock. Metoda constă din două etape, una de identificare a entităţilor din sistem (clase/obiecte, responsabilităţi şi legături dintre diferitele obiecte) şi o etapă de analiză detaliată, fază în care se stabilesc ierarhii, subsisteme şi protocoale. Metoda permite realizarea unor specificaţii exacte şi complete.

- OMT (Object Modeling Technique); această metodă a fost realizată de Rumbaugh. Analiza şi proiectarea se desfăşoară în paralel, în patru etape (analiza, proiectarea de sistem, proiectarea obiectelor şi implementarea). Este de remarcat faptul că sistemul este văzut din trei perspective diferite: din punct de vedere obiectual, dinamic şi funcţional. Această abordare permite realizarea a trei modele diferite, facilitând traducerea acestora în limbajele de programare orientate obiect.

126

- OODA (Object Oriented Design with Attributes) a fost realizată de Booch şi este împărţită în patru etape: identificarea claselor şi a obiectelor, identificarea semanticii, identificarea relaţiilor dintre acestea şi implementarea claselor. Metoda împrumută termeni şi concepte din limbajele de programare orientate obiect, cu preponderenţă din C++, oferind patru perspective asupra problemei abordate (o vedere logică şi una fizică; un model static şi unul dinamic pentru cele două vederi).

- OOSA (Object Oriented Systems Analysis), realizată de Shlaer şi Mellor. Această metodă constă din patru etape: analiză, specificările externe, proiectarea sistemului şi implementarea proiectului. Faza de analiză este alcătuită la rândul ei din realizarea modelului informaţional, a celui de stare şi a celui de proces.

- OOAD (Object Oriented Analysis and Design), metodă preponderent teoretică, a fost realizată de Martin şi Odell pentru a integra aspectele structurale şi comportamentale ale analizei orientate obiect. Metoda utilizează trei tehnici: diagrame de flux pentru descrierea proceselor de nivel înalt, scheme de evenimente pentru comportamentul obiectelor şi scheme de obiecte pentru a descrie relaţiile şi tipurile acestora.

După cum se poate observa, există o multitudine de metodologii de analiză orientate obiect, cele mai des utilizate fiind însă OMT şi UML. Tendinţa actuală este de a unifica diversele metode, UML fiind practic rezultatul unei încercări de unificare şi standardizare.

UML (Unified Modeling Language) Metodologia UML se doreşte a fi o reunire a tuturor metodelor de modelare şi

analiză cunoscute până în prezent. Scopul principal a fost acela de a furniza un mecanism eficient de dezvoltare a programelor, dar mai ales de a impune o unică metodă de analiză. Practic, s-a căutat ca UML să preia toate aspectele pozitive întâlnite la celelalte metodologii, şi, pe cât posibil, să elimine toate dezavantajele. Câteva din avantajele şi dezavantajele implicate de operaţia de unificare a acestora prin UML pot fi:

- eliminarea unor diferenţe de concepţie şi de notaţie; - eliminarea conceptelor ce nu s-au dovedit viabile şi păstrarea celor care s-au

dovedit utile. Printre dezavantajele introduse, amintim: - introducerea inevitabilă a unui număr de noi concepte, sporind astfel

complexitatea metodei; - fiecare metodă prezentată până în acest moment ţinea cont de anumite

particularităţi ale problemelor, ceea ce nu mai este posibil în noul context.

Metodologia O.M.T. (Object Modelling Technology)Este o metodologie modernă de proiectare, mai apropiată de utilizator, mai

uşor accesibilă şi intuitivă, datorită modelelor cu care operează.

127

Metodologia OMT, introdusă de J. Rumbaugh, este una dintre cele mai răspândite tehnici de analiză şi proiectare orientată obiect.

Această metodă constă din crearea unui model care cuprinde aspectele esenţiale ale domeniului problemei, model la care se adaugă într-un pas următor detaliile necesare implementării, realizându-se astfel proiectarea completă a aplicaţiei.

Etapele metodologiei O.M.T.: analiza sistemului proiectarea sistemului proiectarea obiectelor implementarea sistemului

I. Analiza sistemului

Obiectivul urmărit: construirea (definirea) modelului sistemului informatic în concordanţă cu obiectivele şi cerinţele prestabilite. Se urmăreşte realizarea unui model global care conţine obiectele din domeniul aplicaţiei, împreună cu o descriere a proprietăţilor şi comportamentului acestora.

Analiza sistemului poate fi desfăşurată conform următoarei scheme:

Într-un prim pas viitorii utilizatori formulează obiective şi cerinţe prin prisma intereselor lor. Analiştii vor recurge la evaluarea obiectivelor şi cerinţelor utilizatorilor şi vor formula domeniul problemei de referinţă construind pe baza acestuia un prim model al sistemului. Modelul astfel conceput ar putea prezenta însă o serie de lipsuri, evitări de situaţii datorate faptului că utilizatorilor le este greu să formuleze din start tot ce şi-ar dori. Modelul elaborat într-o primă formă va fi dezvoltat şi rafinat pe baza unor noi interviuri cu reprezentanţii unităţii beneficiare pentru a lămuri anumite probleme, pentru a surprinde eventuale scăpări.

128

Modelul va fi rafinat ţinând seama şi de experienţa dobândită de analişti, de eventualele concluzii desprinse din documentare sau din concluziile desprinse cu ocazia realizării unor sisteme asemănătoare. În funcţie de aceste situaţii se va construi noul model într-o formă reală şi precisă.

Modelul sistemului conceput va cuprinde: modelul obiectelor modelul dinamic modelul funcţional.

Cele 3 tipuri de modele astfel realizate vor constitui suportul pentru trecerea la proiectarea noului sistem.

Modelul obiectelor reflectă starea statică a sistemului de referinţă. Din acest considerent modelul obiectelor mai este numit şi modelul static.

Modelul dinamic arată comportamentul sistemului şi al obiectelor dependent de timp. Acest model este extrem de semnificativ pentru sistemele ce prezintă un dinamism (schimbări de stări) pronunţat, cum ar fi sistemele informatice de conducere a proceselor tehnologice (sisteme în timp real).

Modelul funcţional pune în evidenţă intrările şi respectiv procedurile privind determinarea ieşirilor. Intrările, respectiv ieşirile pot fi mesaje, documente de intrare, acţiuni concretizate în informaţii stocate pe un purtător tehnic de informaţii.

Fluxurile dintr-o diagramă de date corespund obiectelor sau valorilor atributelor. Procesele dintr-o diagramă de flux de date corespund activităţilor sau acţiunilor din diagrama stărilor claselor de obiecte.

II. Proiectarea sistemului

În cadrul acestei etape se defineşte strategia adoptată cu privire la resursele hardware şi software. Se precizează structura şi delimitarea sferei de cuprindere a sistemului sau a fiecărui subsistem. Se defineşte concepţia de organizare a datelor în fişiere sau baze de date.

III. Proiectarea obiectelor din cadrul sistemului

Este etapa de proiectare şi realizare propriu-zisă a obiectelor, a claselor definite, a procedurilor şi programelor aferente.

IV. Implementarea sistemului

Are ca obiectiv, ca şi la celelalte metodologii, testarea programelor şi experimentarea sistemului în mediu real, până la punerea lui în funcţiune şi intrarea în exploatare curentă.

129

6. STUDIUL ŞI ANALIZA SISTEMULUI EXISTENT6.1. Obiective şi activităţi specifice

În sensul general, cuvântul analiză înseamnă descompunerea unui tot în elementele sale componente semnificative şi studiul relaţiilor dintre aceste elemente sau altfel spus, totalitatea demersurilor efectuate pentru a cunoaşte o problemă. În informatică sensul noţiunii s-a extins, astfel că ea nu reprezintă o simplă fotografiere a unei situaţii, ci reprezintă în acelaşi timp o activitate de concepţie, de găsire a unor soluţii, ceea ce obligă analistul la un bogat bagaj de cunoştinţe, iniţiativă, putere de abstractizare şi sintetizare.

Studiul şi analiza sistemului existent reprezintă activitatea prin care se realizează cunoaşterea sistemului-obiect şi a cerinţelor de informaţii ale sistemului de conducere, analiza acestora în vederea evaluării performanţelor şi a limitelor sistemului informaţional existent necesare pentru proiectarea noului sistem informatic.

Astfel, pornind de la una sau mai multe probleme formulate, analiza trebuie să stabilească cerinţele pe care trebuie să le îndeplinească noul sistem bazat pe prelucrarea automată a datelor. Ea se finalizează, conform metodologiilor moderne de proiectare a sistemelor informatice, într-un model al datelor şi respectiv un model al prelucrărilor (conceptual, logic şi fizic).

Practic, în această etapă se desfăşoară următoarele activităţi:a). Investigarea sistemului existent, constând în: culegerea de informaţii sau, altfel spus, documentarea; studiul sistemului existent sub următoarele aspecte:

- definirea caracteristicilor generale;- studiul activităţilor de bază;- studiul sistemului de conducere;- studiul sistemului informaţional.

b). Analiza sistemului existent, cu următoarele activităţi: evaluarea performanţelor şi limitelor sistemului existent; evaluarea gradului de pregătire pentru proiectarea şi implementarea

sistemului; analiza critică a sistemului existent, cu identificarea punctelor forte şi a

celor slabe.

Abordări posibile:- pornind de la analiza deciziilor;- pornind de la analiza datelor;- mixtă.

130

c). Sistematizarea informaţiilor culese d).Evaluarea sistemului existent şi definirea direcţiilor de perfecţionare.

În termenii Teoriei Sistemelor, cunoaşterea unui sistem înseamnă de fapt cunoaşterea :

- elementelor sistemului şi a legăturilor între ele ;- intrărilor sistemului;- ieşirilor sistemului;- stărilor sistemului;- funcţiei de convertire (transformarea intrărilor în ieşiri);- funcţiei de transfer (transformarea unei stări în alta).

Scopul cunoaşterii detaliate a sistemului-obiect şi a cerinţelor de informaţii poate fi:

proiectarea unui model al sistemului existent, adică un sistem omomorf cu ajutorul căruia să se simuleze funcţionarea sistemului real, sau

proiectarea unui sistem omomorf, care să înlocuiască sistemul existent, având performanţe mai ridicate, sau

proiectarea unui sistem raţionalizat : care pe baza aceloraşi intrări elaborează aceleaşi ieşiri, dar cu o structură

mai simplă (de exemplu raţionalizarea structurii organizatorice în paralel cu raţionalizarea sistemului de evidenţă), sau

care simplifică intrările, structura şi – în cazul în care se dovedeşte necesar – ieşirile sistemului.

Există două concepte care stau la baza stabilirii elementelor sistemului-obiect, care – aplicate la activitatea de analiză – identifică două tipuri de structuri:

conceptul orientat pe organism, care determină structura organizatorică; conceptul orientat pe activitate, care determină structura funcţionalăÎn general sunt studiate ambele tipuri de structură, accentul punându-se însă pe

activităţi, în timp ce elementele organizatorice interesează doar prin prisma aportului lor la realizarea activităţilor.

Studiul sistemului existent cuprinde un grup de activitãţi care urmãresc, în principal:

cunoaşterea performanţelor tehnico-funcţionale ale sistemului informaţional, atât în ansamblul său, cât şi pentru elementele de structură ale acestuia;

cunoaşterea cerinţelor informaţionale ale conducerii; cunoaşterea lipsurilor şi a restricţiilor pe care le prezintã sistemul existent

faţã de aceste cerinţe. De modul de realizare a acestor activităţi, de corectitudinea şi completitudinea

informaţiilor culese şi prelucrate depinde întregul proces de realizare a sistemului

131

informatic. Prin urmare, o bună cunoaştere a sistemului obiect crează premizele unei proiectări bune a noului sistem informatic.

Pe de altă parte, acţiunile ce se realizeazã în cadrul acestei grupe de activităţi sunt strâns legate de criteriile de evaluare a performanţelor şi limitelor sistemului informaţional existent.

În aceste condiţii, cunoaşterea sistemului existent, specificarea cerinţelor de perfecţionare ale acestuia de o manieră completă şi consistentă nu se poate realiza făcând complet abstracţie de o anumită viziune structurală asupra “obiectului” proiectat. Mai ales în condiţiile trecerii spre proiectarea asistată de calculator, studiul sistemului existent, analiza acestuia şi specificarea cerinţelor rezultate din analiză se contopesc tot mai mult cu proiectarea. De aceea, este tot mai greu să separi complet metodele şi tehnicile de analiză de cele ale proiectării.

Totuşi, vom defini şi vom descrie principalele activităţi identificate în cadrul etapei de proiectare denumită Studiul şi analiza sistemului existent.

6.2. Investigarea sistemului existentAceastă activitate, deosebit de laborioasă, care înseamnă practic cunoşterea şi

studiul sistemului obiect, cuprinde o serie de acţiuni care pot fi grupate astfel:a) Culegerea de informaţii , documentareab) Studiul sistemului existent

a). Culegerea de informaţii , documentarea - presupune o succesiune de operaţii prin care:

- se studiază sistemul-obiect, în general, şi sistemul informaţional-decizional, în particular, în ceea ce priveşte :

organizarea sistemului (structura organizatorică); fluxul activităţilor; fluxul de informaţii;

- se identifică cerinţele şi restricţiile noului sistem, cum sunt: cerinţele de informare pentru decizii şi control; restricţiile şi cerinţele organizatorice.

b). Studiul sistemului existent presupune, în principal, următoarele activităţi: definirea caracteristicilor generale ale sistemului economic; studiul activitãţilor de bazã desfãşurate în sistem; studiul sistemului de conducere (decizional); studiul sistemului informaţional ; identificarea metodelor şi mijloacelor tehnice.

Definirea caracteristicilor generale ale sistemului economic implicã, pentru proiectantul sistemului informatic nou, o cunoaştere corectă a următoarelor elemente:

profilul, obiectivele agentului economic; locul în sfera serviciilor şi sfera producţiei pe care îl ocupă;

132

relaţiile de colaborare sau de subordonare cu alţi agenţi economici; specificul activitãţii de bazã ( producţie, servicii); nivelul tehnic şi performanţele de calitate a produselor şi/sau serviciilor; principalii indicatori economici şi evoluţia lor; dezvoltarea, modernizarea, perspectivele pe piaţa concurenţială etc.

Studiul activităţilor de bază desfãşurate în sistemul economic, a modului de realizare a funcţiunilor unităţii economice necesită următoarele acţiuni:

Studiul funcţiunilor unităţii economice (sistemul obiect); Studiul funcţiei de bază a unităţii economice ;

Astfel, în cazul unei societăţi economice de producţie, trebuie cunoscute şi descrise, pentru activitatea de producţie următoarele:

- fluxul de producţie ;- amplasarea locurilor de muncă, a depozitelor, etc.; - tipurile de produse, structura lor, ciclurile de fabricaţie;- modul de organizare a producţiei, stocarea producţiei, transporturile

interne, controlul de calitate; - resursele existente: capacităţi de producţie şi /sau depozitare ; asigurarea tehnică / proiectarea de produse noi; norme tehnice; asigurarea cu materiale necesare; sistemul existent de programare a producţiei ; cercetarea şi marketingul, ca elemente ale producţiei.

Studiul sistemului de conducere are ca scop, în principal : identificarea caracteristicilor sistemului de conducere existent ; sistemul de indicatori cantitativi şi valorici necesari actului decizional ; organizarea conducerii; caracteristicile rezultate din statutul de funcţionare a societăţii, tipuri de

decizii, modul de luare a deciziilor ; tipul de management practicat la nivelul societăţii respective, etc.

Studiul sistemului informaţional existent reprezintă o etapă de investigare, de cunoaştere exactă a sistemului informaţional existent, concretizată în următoarele :

studiul documentelor care circulă în sistem, a conţinutului informaţional al acestora, al circuitului lor, al periodicităţii cu care se emit;

elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a principalelor activităţi şi a legăturilor statice şi dinamice dintre acestea);

estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de culegere şi prelucrare;

133

identificarea principalilor algoritmi, a regulilor de calcul şi a punctelor şi regulilor de control;

cunoaşterea principalelor restricţii ale sistemului informaţional; situaţia raţionalizării fluxurilor şi a documentelor din unitatea economică,

studii elaborate, stadiul lor de implementare; sistemul de codificare utilizat, restricţii; performanţele şi limitele sistemului informaţional existent.

Identificarea metodelor şi mijloacelor tehnice utilizate pentru prelucrarea

datelor în cadrul sistemului informaţional existent se face studiind şi analizând : mijloacele tehnice existente în dotarea unităţii economice (modul de

utilizare, cheltuielile de exploatare, personalul implicat, performanţe); existenţa unor aplicaţii proiectate şi/sau implementate.

6.3. Analiza sistemului existent

Odată terminată documentarea, investigarea sistemului existent, urmează analiza sistemului existent, care constã în următoarele etape:

evaluarea performanţelor, a limitelor sistemului informaţional existent în raport cu cerinţele sistemului de conducere;

evaluarea gradului de pregătire al unităţii economice pentru introducerea noului sistem informatic.

Evaluarea performanţelor şi limitelor sistemului existent se face pe baza următoarelor criterii:

mãsura în care sistemul informaţional asigurã realizarea obiectivelor, îndeplinirea funcţiilor şi sarcinilor de bază ale unităţii şi exercitarea atributelor de conducere;

gradul de asigurare cu informaţii necesare şi suficiente a conducerii la diferite niveluri, a compartimentelor funcţionale;

operativitatea în culegerea şi transmiterea informaţiilor şi datelor, ceea ce caracterizează timpul de răspuns al sistemului informaţional;

calitatea informaţiilor obţinute din prelucrare, privitã sub aspectul preciziei de exprimare şi sub aspectul flexibilitãtii;

calitatea şi siguranţa legãturilor informaţionale, a fluxurilor informaţionale;

posibilitatea sistemului informaţional de a sesiza tendinţele în evoluţia activităţii unităţii respective;

posibilitãţile de control şi de efectuare a corecţiilor, reacţia la apariţia unor evenimente externe, posibilităţile de corectare în timp util a abaterilor;

gradul de integrare a sistemului informaţional, atât sub aspectul reducerii informaţiei redundante, a compatibilităţii informaţiilor de ieşire cu cele de intrare,

134

a organizãrii datelor, cât şi sub aspectul asigurării unui cadru organizatoric adecvat;

gradul de automatizare a operaţiilor de culegere, transmitere, prelucrare şi interogare a datelor, de valorificare intensivã a informaţiei obţinute din prelucrare, de pregătire a personalului şi a sistemului informaţional pentru perfecţionări etc.

Evaluarea gradului de pregãtire a unitãţii economice pentru proiectarea şi implementarea sistemului informatic presupune:

stabilirea nivelului de pregãtire a personalului şi a experienţei dobândite în prelucrarea automatã a datelor;

existenţa unei discipline tehnologice; existenţa cadrului organizatoric adecvat; existenţa fondului de date necesar pentru realizarea sistemului informatic

etc. Analiza criticã vizeazã organizarea şi funcţionarea sistemului informaţional -

decizional existent şi cautã sã identifice aspectele negative, sã surprindã cauzele generatoare de "perturbaţii" ale sistemului şi în final să sistematizeze aspectele negative prin gruparea lor în "puncte critice".

Un loc important în analiză îl ocupă analiza datelor şi analiza procedurilor. Activitatea de analiză se desfăşoară iterativ. Se pot distinge, în acest sens, două

cazuri:- Sistemul-obiect a fost deja delimitat de către beneficiar, delimitare rezultată

din anumite necesităţi ale acestuia. În acest caz analiza se desfăşoară iterativ asupra sistemului-obiect precizat.

- Sistemul-obiect nu a fost delimitat de către beneficiar. În acest caz analiza propriu-zisă este precedată de o analiză având scopul de a delimita aria sistemului-obiect, care poate acoperi întregul sistem real sau părţi ale lui.

Domeniul analizat (obiectul analizei, la o iteraţie a activităţii de analiză) poate fi deci întregul sistem-obiect sau părţi ale lui.

Observaţie:Analiza se poate desfăşura cu scopul determinării cerinţelor de informaţii la

nivelul întregului sistem informatic, caz în care se numeşte analiză de ansamblu - sau a unor părţi (subsisteme sau domenii) ale acestuia, caz în care se numeşte analiză de detaliu.

Activitatea de analiză se poate desfăşura, în cadrul ciclului de viaţă al sistemelor informatice în etapele:

a. Elaborare temă de realizare sau studiu de fezabilitate :În această etapă are scopul de a identifica sistemul-obiect, în cazul în care

delimitarea acestuia nu a fost făcută de către beneficiar şi de a stabili oportunitatea analizei de ansamblu.

135

b. Elaborare proiect de ansamblu sistem informatic: constă în analiza de ansamblu a sistemului-obiect delimitat anterior.

c. Elaborare proiecte de detaliu pe componentele sistemului informatic: constă în analiza de detaliu, indiferent de tipul sistemului informatic.

Activitatea de analiză se realizează printr-o strânsă colaborare între beneficiarul noului sistem şi analist, aportul beneficiarului, ca persoană care cunoaşte direct problematica unităţii, fiind esenţial.

În cadrul activităţii de analiză, se pot identifica trei abordări în activitatea de determinare a cerinţelor informatice, şi anume:

Abordarea pornind de la analiza deciziilor Aceasta este o abordare care caută să obţină cerinţele de informaţii pornind de

la analiza obiectivelor şi/sau a deciziilor ce trebuie luate. Sunt culese şi raportate doar acele informaţii care sunt necesare modelului de decizie. În această abordare, fluxul activităţilor de identificare a cerinţelor informaţionale este :o Identificarea obiectivelor şi/sau deciziilor curente şi potenţiale, precum şi a

atributelor conducerii corespunzătoare obiectivelor şi deciziilor.o Identificarea sau construirea unui model de decizie (a unei proceduri de

elaborare a fiecărei decizii) sau a unui model al procesului de luare a deciziei.o Identificarea datelor necesare luării deciziilor, pentru modelul de decizie

sau pentru cel al procesului de luare a deciziei (atât din sistemul informaţional formal cât şi cel neformal).o Testarea senzitivităţii modelului la acurateţea şi disponibilitatea datelor de

intrare, specificarea limitelor de acurateţe şi disponibilitate a datelor cerute de model.

Această abordare conduce la un volum mic de date de stocat şi de prelucrat.

Abordarea pornind de la analiza datelorAceasta este o abordare care caută să obţină cerinţele de informaţii prin analiza

datelor folosite curent în sistemul existent sau a datelor potenţial folosibile. Sunt identificate datele colectate în sistemul existent, pentru care s-a perceput o necesitate, precum şi datele necolectate în sistemul existent, dar semnalate ca fiind valoroase (datele atât din sistemul informaţional formal cât şi cel neformal).

În această abordare, fluxul activităţilor de determinare a cerinţelor informaţionale este: o colectarea tuturor documentelor, rapoartelor, fişierelor etc. folosite în mod

curent şi identificarea datelor care sunt culese şi prelucrate în mod curent;o identificarea datelor suplimentare, care nu sunt culese şi prelucrate în mod

curent, dar care se dovedesc a fi utile (prin interviuri, comparaţii cu alte sisteme similare etc.);

136

o stabilirea inutilităţii anumitor date, pentru care nu a fost percepută (din interviuri) nici o necesitate.

Acest mod de abordare pleacă de la premisa că toate datele utile trebuie să facă parte din sistem, pentru a preîntâmpina schimbările ce pot apare în mediul unităţii studiate, în stilul de decizie sau în cerinţele informaţionale ale decidenţilor.

Din acest motiv, această abordare este cea folosită, de regulă, pentru construirea bazei de date a sistemului. Ea conduce la un volum relativ mare de date, dar are avantajul că deciziile care se vor lua pe baza acestor date vor fi mai puţin afectate de modificările ce pot surveni pe parcurs.

Abordarea mixtăAbordarea mixtă reprezintă o combinaţie între cele două abordări, care,

dacă este făcută în funcţie de specificul problemei de analizat, devine cea mai recomandată cale de determinare a cerinţelor informaţionale. Fiecare dintre cele două abordări „pure” este mai potrivită pentru un anumit tip de problemă:o analiza deciziilor se recomandă în special pentru activităţile de

conducere, în cazul în care se doreşte proiectarea unui sistem care să constituie suport pentru luarea deciziilor sau a unui sistem omomorf, mai performant decât cel existent şi care să-l înlocuiască pe acesta.o analiza datelor se recomandă în special pentru activităţile de rutină, în

cazul în care se doreşte proiectarea unui sistem de prelucrare a tranzacţiilor, automatizarea unor prelucrări manuale sau proiectarea unui model al sistemului existent.

Combinaţia între cele două abordări ar putea consta în definirea unui model de decizie şi de prelucrare a datelor necesare în modelul de decizie, cu colectarea cel puţin a unor date considerate utile pentru un decident care doreşte să depăşească limitele respectivului model de decizie.

6.3.1. Tehnici de analizăTehnicile de analiză sunt tehnicile prin care se realizează activitatea de analiză

şi care servesc la elaborarea modelului infologic al produsului informatic.Aceste tehnici diferă în funcţie de: etapa din ciclul de viaţă al produsului informatic în care se aplică; tipul de abordare folosit în determinarea cerinţelor informaţionale; modul de realizare a operaţiilor care compun activitatea de analiză.Gradul de acoperire, de către tehnicile de analiză, a operaţiilor care alcătuiesc

activitatea de analiză, conduce la gruparea tehnicilor de analiză în două mari categorii, şi anume :

A. tehnici elementareB. tehnici complexe

137

A. Tehnici elementare de analizăAceste tehnici realizează practic numai operaţia de culegere de informaţii şi o

sistematizare redusă a acestora.Culegerea informaţiilor este orientată spre un anumit domeniu, precizat

anterior. În acest caz problema eşantionării nu prezintă o importanţă deosebită, deoarece se încearcă anchetarea tuturor surselor semnificative de informaţie, numărul lor nefiind prea mare.

Sistematizarea datelor se realizează, în cadrul acestor tehnici de analiză, numai parţial şi se concretizează în aranjarea coerentă a informaţiilor în cadrul rapoartelor.

Din grupa tehnicilor elementare de analiză fac parte:- observarea directă ;- interviul ;- chestionarul ;- studiul documentar sau studiul documentelor din sistem, care înseamnă: studiul actelor normative, a reglementărilor privind organizarea şi

funcţionarea unităţii şi/sau activităţii analizate; studiul documentelor din sistemul de evidenţă al unităţii respective, ştiind

că acesta cuprinde evidenţa tehnico-operativă, evidenţa financiar - contabilă şi evidenţa statistică.

Studiul Regulamentului de Organizare şi Funcţionare, al statutului, etc.Dintre toate aceste tehnici elementare, o importanţă deosebită în reuşita

activităţii de analiză şi o semnificaţie deosebită prin frecvenţa mare cu care sunt utilizate, o au interviul şi chestionarul, pe care le voi prezenta mai detaliat.

B. Tehnici complexe de analizăAceste tehnici realizează practic analiza, prin operaţiile de culegere şi

sistematizare a informaţiilor, precum şi prin evaluarea sistemului informaţional-decizional existent.

Culegerea informaţiilor se realizează utilizând tehnicile elementare de analiză. Sistematizarea informaţiilor, care presupune atât reordonarea cât şi sintetizarea lor, se realizează folosind una sau mai multe tehnici de reprezentare. Dintre tehnicile de reprezentare, amintim:

- tehnica diagramelor;- tehnica grilelor;- tehnica tabelelor de decizieEvaluarea sistemului informaţional decizional existent nu este de regulă pusă în

tipare, ci este lăsată mai mult pe seama puterii de analiză – sinteză a proiectantului, a experienţei sale practice de analiză şi proiectare sisteme informatice.

Trebuie precizat faptul că obiectul evaluării în cazul proiectării unui sistem informatic îl reprezintă sistemul informaţional-decizional.

138

În completare, proiectantul poate face şi o evaluare a sistemului de conducere şi/sau a sistemului condus, putând utiliza, în acest sens, studiul statistic al indicatorilor tehnico-economici. Se face apel astfel la tehnica de analiză prin indicatori şi indici.

Pentru evaluarea efectivă a sistemului informaţional-decizional, analistul va putea calcula:

- indicatori specifici prelucrării datelor pentru domeniul studiat, cum ar fi: volumul informaţiilor prelucrate manual (număr documente* conţinut informaţional), costul prelucrării manuale, costul exploatării echipamentelor existente, capacitatea echipamentului de prelucrare existent, etc;

- coeficienţi de evaluare a prelucrărilor realizate în cadrul sistemului informaţional, cum ar putea fi coeficientul de utilizare a datelor pentru procesul de prelucrare, coeficientul timpului de răspuns, coeficientul nivelului de prelucrare,etc.

Trebuie precizat faptul că aceste tehnici nu dau proiectantului reţete de evaluare a sistemului informaţional-decizional, dar precizează:

- direcţiile pe care s-ar putea face evaluarea;- criterii de evaluare, atât a informaţiilor care circulă în sistem cât şi a

eficienţei sistemului informaţional propriu-zis.Ca o simplă orientare, evaluarea eficienţei sistemului informaţional-decizional

se face prin compararea caracteristicilor acestuia cu necesităţile sistemului de conducere.

Scopul principal al tehnicilor complexe de analiză este acela de a cunoaşte sistemul informaţional-decizional existent, de a-i sesiza neajunsurile şi de a le exprima într-o formă cuantificabilă, în măsura în care acest lucru este posibil.

Tehnicile complexe de analiză pot fi completate şi cu instrumente specializate, de analiză asistată de calculator. Aceste tehnici sunt legate mult de analiza economică a societăţii, căci evaluarea implică aspecte profund economice, iar sistemul informaţional fiind un instrument al conducerii, problemele legate de prelucrarea datelor nu pot fi desprinse de contextul economic. Astfel, dacă în etapa elaborării temei de realizare avem de a face cu tehnici de analiză economică, în proiectarea de ansamblu şi de detaliu se trece la adaptarea tehnicilor de analiză economică la specificul activităţii de informatică, luând forma de analiză-diagnostic sau la tehnici specializate pe analiza sistemului informaţional-decizional, cum ar fi analiza celulară.

Din grupa tehnicilor complexe de analiză fac parte:- analiza-diagnostic;- analiza celulară;- analiza concordanţei dintre intrări şi ieşiri;- analiza prin decompoziţie funcţională; - metoda HIPO, etc.

139

6.3.1.1. Interviul Interviul este o tehnică elementară de analiză care realizează culegerea

informaţiilor despre sistemul-obiect – în general – şi despre sistemul informaţional-decizional existent – în particular – direct de la cadrele de conducere şi de execuţie care concură la deciziile şi la activităţile din domeniul studiat, prin discuţii individuale purtate de către analist cu aceste cadre pe baza întrebărilor formulate de analist.

În paralel cu desfăşurarea discuţiilor, analistul poate aduna exemple de documente de intrare/ieşire folosite în sistemul existent, a căror studiere ulterioară va completa informaţiile culese direct.

Interviul se poate folosi şi în combinaţie cu alte tehnici elementare de analiză, în principal – cu studiul documentar.

Este o tehnică puţin riguroasă, care nu oferă o schemă fixă a culegerii informaţiilor, ci doar câteva reguli utile analistului în purtarea discuţiei, desfăşurarea efectivă a procesului de culegere a informaţiilor şi construirea întrebărilor rămânând la latitudinea analistului. Completitudinea şi corectitudinea informaţiilor culese depind astfel de îndemânarea şi inteligenţa analistului, de capacitatea lui de a pune întrebări. Regulile oferite de o tehnică de culegere pot suplini, într-o oarecare măsură, lipsa de experienţă, dar nu şi creativitatea analistului.

Scopul interviului este de a obţine descrierea informaţională completă a unui anumit domeniu sau problemă -delimitat anterior- precum şi a cerinţelor de informaţii necesare elaborării deciziilor şi exercitării atributelor conducerii în domeniul respectiv. Interviul este o tehnică de analiză folosită la realizarea sistemelor informatice atât la nivel microeconomic, cât şi la nivel macroeconomic. Serveşte deci, la obţinerea informaţiilor referitoare la o gamă variată de sisteme-obiect, ceea ce dă caracterul de generalitate al tehnicii.

Interviul este utilizat în analiza generală şi în cea de detaliu, deci la elaborarea modelului infologic general şi a celui de detaliu, în etapele de Proiectare de ansamblu a sistemului informatic şi Proiectare de detaliu.

Aria de cuprindere a interviului în sistemul-obiect este foarte variată – de la activitatea unui post de lucru până la activitatea unei întregi unităţi economico-sociale.

Reguli generale şi cerinţe ale aplicării interviului În momentul începerii interviului trebuie cunoscute: - domeniul sau problema despre care se culeg informaţii (adică subiectul

interviului să fi fost delimitat şi chiar cunoscut, până la un anumit nivel, prin studiu teoretic-documentar sau prin alte surse de informare);

- sursa de informaţii (persoanele potenţial anchetabile).

140

Alegerea sursei de informaţii se face în funcţie de obiectul despre care se doreşte obţinerea informaţiilor:

- pentru a obţine informaţii cu caracter general, privind activitatea de ansamblu a unui domeniu sau politica unei unităţi, se apelează la cadre de conducere;

- pentru informaţii de detaliu, privind activitatea unui punct de lucru, se apelează la cadre de execuţie.

Beneficiarul viitorului sistem informatic trebuie implicat în proiectarea lui. Analistul nu va impune soluţii, ci va orienta discuţia astfel încât beneficiarul să-şi definească singur sistemul cel mai eficient pentru nevoile sale.

Informaţiile culese prin interviu trebuie verificate, pe cât posibil, prin studiul documentelor şi actelor normative legate de problema analizată.

Este necesară instruirea în tehnica interviului. S-a incetăţenit concepţia falsă că a lua un interviu este un lucru uşor, pe care-l poate face oricine, după propia sa inspiraţie. În realitate, deşi inspiraţia joacă şi ea un rol însemnat în această tehnică – care nu oferă decât un set de reguli de ghidare a desfăşurării interviului – este util, chiar şi pentru analişti cu oarecare experienţă, să cunoască regulile oferite de tehnică.

Câteva reguli ale desfăşurării interviului:a) Analistul va arăta permanent interes faţă de spusele interlocutorului său.b) Analistul nu va introduce subiecte colaterale în discuţie şi va avea grijă ca

nici interlocutorul său să nu abordeze asemenea subiecte (fără a-l întrerupe cu brutalitate, ci reorientând discuţia spre subiectul principal).

c) Analistul va acorda intervievatului timp de gândire, prin pauze între întrebări.

d) Analistul nu va pune întrebări al căror răspuns să fie “DA” sau “NU”, acestea neaducând un plus de informaţii.

e) Analistul se va autochestiona (mintal), pe parcursul discuţiei, făcând astfel o verificare a interpretării pe care o dă răspunsurilor şi o evaluare a acestora.

Autochestionarea este recomandată atât pentru a grăbi procesul de evaluare finală, cât şi pentru a menţine atenţia asupra subiectului principal.

De asemenea se recomandă evaluarea răspunsurilor pentru a se evita suprasaturaţia informaţională (care este la fel de dăunătoare ca şi lipsa de informaţii). Evaluarea răspunsurilor, făcută prin autochestionare, acţionează ca un al doilea filtru al informaţiilor recepţionate, alături de interesul creativ al analistului.

Nu se poate da o schemă standard de evaluare a răspunsurilor primite de analist, ci doar anumite criterii de evaluare:

- completitudinea răspunsului (“Răspunsul primit este complet?”; “A fost omis vreun domeniu?De ce?”);

141

- noutatea răspunsului (“Am mai discutat acest lucru cu altcineva?” Dacă da – “Cum corespunde acest răspuns cu cele primite deja?”);

- vârsta informaţiei primite (“Cât de recentă este informaţia?”);- importanţa răspunsului (“Este o informaţie importantă sau este

colaterală?” – raportând la cunoştinţele prealabile referitoare la problema analizată);

- fundamentarea răspunsului (“Ce fapte are la bază interlocutorul meu pentru a face această afirmaţie?“);

- logica răspunsului (“Raţionamentul dezvoltat de interlocutorul meu este logic sau nu?”).

Întocmirea raportului de analizăRaportul de analiză reprezintă o sistematizare a notiţelor luate pe parcursul

interviului. Forma lui este narativă, iar tehnica de reprezentare folosită este scrierea tehnică. La raportul de analiză se pot anexa mostrele de documente de intrare/ieşire culese o dată cu desfăşurarea discuţiilor.

Raportul va conţine:- toate întrebările puse şi sinteza răspunsurilor primite (răspunsurile evaluate

pe parcursul discuţiei);- toate punctele neclare, cu specificarea neclarităţii. Nu e corect să se

specifice doar “nu am înţeles problema X”, ci trebuie descris în ceea ce constă neclaritatea;

- opiniile intervievatului, separate de faptele prezentate de acesta.Avantaje şi limite ale interviuluiAvantajele interviului constau în larga lui aplicabilitate precum şi în faptul că,

nefiind o tehnică foarte riguroasă, lasă foarte multă libertate creativă analistului, în construirea şi desfăşurarea efectivă a interviului.

Interviul prezintă limitele oricărei tehnici elementare de analiză, respectiv faptul că nu face analiza critică a sistemului informaţional-decizional.

6.3.1.2. Chestionarul

Chestionarual este o tehnică elementară de analiză împrumutată, ca şi interviul, din practica cercetărilor sociologice.

Chestionarul este o tehnică prin care se realizează culegerea informaţiilor prin răspunsuri date de persoanele anchetate (personalul de conducere sau de execuţie din unitatea analizată) la întrebări formulate în scris de către analist.

Formularul de culegere, care conţine lista de întrebări, poartă acelaşi nume ca şi tehnica -“chestionar”- şi este însoţit de o anexă conţinând instrucţiunile de completare (“ghid de completare”). Spre deosebire de chestionarul sociologic, în cadrul chestionarului ca tehnică de analiză pentru realizarea sistemelor

142

informatice nu interesează studiul fenomenelor de masă (pe baza indicatorilor rezultaţi din prelucrări statistice ale chestionarelor), ci strict aspectul furnizării de informaţii.

Chestionarele se pot clasifica după mai multe criterii.După modul de administrare, chestionarele se pot clasifica în:- chestionare autoadministrate (cu răspunsurile completate chiar de

subiecţii anchetaţi):- chestionare poştale;- chestionare distribuite prin operatorii de anchetă;- chestionare apărute în publicaţii etc.- chestionare administrate de operatori de anchetă (cu răspunsurile

completate de operatorii de anchetă – deci interviuri).Chestionarele utilizate în activitatea de analiză efectuată pentru realizarea

sistemelor informatice fiind, după modul de administrare, de tipul celor autoadministrate, se pot clasifica doar pe criteriile: tematică, conţinut şi formă.

Astfel, tipurile de chestionare utilizate în activitatea de analiză şi care interesează deci un analist sunt grupate astfel:

a. După tematică:- chestionare speciale, cu o singură temă;- chestionare “omnibus”, cu mai multe teme, dar toate legate de domeniul

analizat.Acestea din urmă permit surprinderea intercorelării temelor.b. După conţinut:- chestionare cu date factuale;- chestionare de opinie.c. După forma întrebărilor:- chestionare cu întrebări închise (precodificate), care presupun selectarea

unui răspuns dintr-o serie de variante de răspuns scrise tot pe formularul de culegere, imediat după întrebare;

- chestionare cu întrebări deschise (libere).Întrebările închise mai prezintă o serie de avantaje, cum ar fi: sprijină memoria celui anchetat; servesc drept “filtru” pentru întrebările următoare; sporesc senzaţia de anonimat a anchetatului, permiţându-i acestuia o mai

mare angajare în răspunsuri.Chestionarele cu întrebări închise sunt de mai multe feluri:- dihotomice (cu răspunsuri DA-NU);- trihotomice (de regulă cu răspunsuri, DA, NU, NU ŞTIU);- precodificate multiplu (cu n răspunsuri, unde n>3).Chestionarele cu răspunsuri multiple se caracterizează prin următoarele:

143

- presupun cunoaşterea prealabilă, de către analist, a problemei anchetate, pentru a oferi fie toate variantele posibile de răspuns, fie variantele de răspuns semnificative;

- permit o nuanţare destul de bună a răspunsurilor;- elimină tendinţa anchetaţilor – constatată experimental – de a evita în scris

răspunsurile extreme, tendinţă care se manifestă, în cazul chestionarelor dihotomice, printr-o posibilitate crescută de apariţie a non-răspunsurilor, iar în cazul chestionarelor trihotomice printr-o creştere nejustificată a numărului de răspunsuri “NU ŞTIU”, ceea ce conduce la distorsionarea rezultatelor anchetei.

În consecinţă, tipul de chestionar care prezintă cele mai puţine dezavantaje este cel cu întrebări închise, precodificate multiplu.

Obiectivele chestionaruluiChestionarul nu serveşte, în primul rând, culegerii de informaţii “noi”,

referitoare la sistemul informaţional-decizional sau la cerinţele informaţionale ale conducerii unităţii analizate; el nu poate înlocui interviul, ca principală tehnică de furnizare de informaţii “noi”, dar îl completează pe acesta.

Scopul chestionarului utilizat în activitatea de analiză este:- verificarea informaţiilor, culese prin interviuri, referitoare la o anumită

problemă;- sondarea opiniilor diferitelor categorii de beneficiari (în special ale

cadrelor de conducere) referitoare la anumite aspecte legate de prelucrarea datelor;

- detalierea informaţiilor, culese anterior prin interviuri, referitoare la o anumită problemă (temă) bine conturată şi de dimensiuni restrânse .

Utilizarea chestionarelor este recomandată, în cazul în care obţinerea informaţiilor nu este foarte urgentă, iar sursele de informaţii sunt greu de contactat direct.

Limitele chestionarului, ca tehnică de analiză, constau în domeniile restrânse la care poate fi aplicat (spre deosebire de interviu) precum şi în faptul că presupune o cunoaştere prealabilă a domeniului sau a problemei care constituie tema chestionarului. În acest sens, chestionarul, ca atare, reprezintă mai mult o tehnică de verificare a acestor cunoştinţe prealabile decât o tehnică prin care să se culeagă o cantitate însemnată de informaţii “noi”.

6.3.1.3. Analiza - diagnostic informaţionalăAnaliza–diagnostic informaţională constituie o adaptare a tehnicii analizei-

diagnostic – care este o tehnică de analiză economică – la studiul sistemului informaţional-decizional, deci reprezintă un tip de analiză-diagnostic specializată.

Analiza-diagnostic, ca tehnică de anliză-diagnostic economică, este orientată către problemele de organizare şi conducere ale unei unităţi economice şi constă în controlarea şi evaluarea nivelului de funcţionare a sistemului de conducere şi a celui condus, identificarea şi localizarea fenomenelor negative şi a cauzei apariţiei

144

lor (diagnostificarea), precum şi în elaborarea unor recomandări menite să permită o funcţionare eficientă a sistemelor respective.

Studiul sistemului condus nu constituie un scop în sine al analizei-diagnostic, ci este legat de studiul sistemului de conducere, deoarece un sistem de conducere poate fi studiat:

- direct, prin analiza activităţii propriu-zisă a organelor de conducere;- indirect, prin analiza activităţii şi a rezultatelor sistemului condus, plecând

de la premisa că acestea reprezintă reflectarea activităţii de conducere.Se poate considera, deci, că anliza-diagnostic este alcătuită din două părţi:- stabilirea diagnosticului (a “stării” sistemului studiat şi a “perturbaţiilor”

intervenite, care determină “starea”);- elaborarea recomandărilor.Analiza-diagnostic informaţională constă în cunoaşterea sistemului

informaţional-decizional şi evaluarea lui din punct de vedere al eficienţei şi al utilităţii sale pentru sistemul de conducere.

- Ea realizează doar partea de diagnostic, în timp ce elaborarea măsurilor de prevenire sau înlăturare a perturbaţiilor este inclusă, implicit, în proiectul noului sistem .

Colectarea cerinţelor de informaţii în analiza-diagnostic informaţională se face pornind de la analiza deciziilor.

Scopul analizei-diagnostic informaţionale este:- de a oferi o imagine completă a organizării şi funcţionării sistemului

informaţional-decizional existent;- de a evidenţia defectele de funcţionare şi carenţele de organizare ale

acestui sistem;- de a stabili cerinţele pentru realizarea sistemului informatic.Analiza-diagnostic informaţională îşi propune stabilirea “stării” sistemului

informaţional-decizional şi a perturbaţiilor care conduc la aspecte negative.Analiza-diagnostic informaţională, spre deosebire de analiza-diagnostic

economică, nu îşi propune elaborarea unor soluţii organizatorice menite să asigure buna funcţionare a sistemului de conducere şi nici a unor soluţii economice care să asigure buna funcţionare a sistemului condus. Soluţiile menite să asigure buna funcţionare a sistemului informaţional-decizional depăşesc sfera activităţii de analiză, intrând în cea a proiectării noului sistem, care include şi raţionalizarea sistemului informaţional.

Analiza sistemului existent se poate realiza, în acest caz, folosind tehnicile elementare de analiză, şi anume: studiul documentar, interviul şi chestionarul.

b. Sistematizarea informaţiilor culese.Sistematizarea informaţiilor constă în:- sistematizarea şi gruparea informaţiilor;- reprezentarea grafică şi tabelară a grupelor de informaţii;- verificarea exactităţii informaţiilor culese, prin diferite modalităţi.

145

Sistematizarea informaţiilor se realizează utilizând tehnicile de reprezentare:- scrierea tehnică;- tehnica diagramelor;- tehnica grilelor;- tehnica tabelelor de decizie.c. Evaluarea sistemului existent Evaluarea constă în:

c1). Evaluarea funcţionării sistemului informaţional-decizional existent. În general, această evaluare se face prin prisma utilităţii sistemului informaţional-

decizional pentru sistemul de conducere. Nu se pot da tipare de evaluare a sistemului informaţional-decizional, ci se pot indica:

direcţii pe care se axează analiza critică; criterii de evaluare a informaţiilor din sistemul informaţional după modul

în care acestea răspund necesităţilor de informare ale conducerii.Direcţiile pe care s-ar putea axa analiza critică şi evaluarea sistemului

informaţional-decizional ar putea fi:- instrumente de conducere (de previziune şi control);- principalele decizii luate pe diferite nivele de conducere;- sistemul de evidenţă formal şi neformal;- organizarea sistemului informaţional, fluxul activităţilor de prelucrare a

datelor;- modul de desfăşurare a activităţilor de prelucrare a datelor;- fluxuri de informaţii şi circuitul suporţilor de informaţii;- resursele utilizate pentru prelucrarea datelor(echipamente şi oameni).

Evaluarea sistemului informaţional se poate face pe baza:- unor indicatori specifici prelucrării datelor sau referitori la sistemul de

evidenţă, cum sunt volumul informaţiilor prelucrate, capacitatea echipamentelor utilizate, costul prelucrărilor etc.

- unor coeficienţi de evaluare a prelucrărilor efectuate în cadrul sistemului informaţional, cum sunt coeficientul utilizării datelor, coeficientul timpului rămas, coeficientul nivelului de prelucrare etc..

Greutatea constă în faptul că aceşti indicatori şi coeficienţi nu pot fi preluaţi direct din evidenţele existente, ci trebuie calculaţi de către analist. Ca şi analiza prin indicatori şi indici efectuată asupra indicatorilor tehnico-economici, cea efectuată asupra indicatorilor specifici prelucrării datelor şi/sau referitori la sistemul de evidenţă precum şi asupra coeficienţilor de evaluare a prelucrărilor se poate referi fie la rezultatele anterioare, fie la perspectiva de dezvoltare (tendinţa de evoluţie).

Criteriile de evaluare se pot referi la:

146

sistemul informaţional-decizional: ca organizare şi funcţionare:

gradul de organizare a sistemului (entropia); gradul de formalizare şi standardizare a evidenţelor şi a activităţilor de

prelucrare a datelor; gradul de utilizare a datelor introduse în sistem; existenţa circuitelor paralele în fluxul de informaţii şi existenţa unor

circuite neînchise de informaţii; gradul de paralelism şi cel de neînchidere a circuitelor.

ca utilitate pentru sistemul de conducere: gradul de concordanţă între prelucrările existente şi cele rezultate din

reglementările în vigoare; costul funcţionării sistemului existent; performanţa sistemului existent, exprimată prin viteza de răspuns,

nivelul de prelucrare; gradul de dificultate în introducerea datelor primare în sistemul

existent. informaţiile utilizate în procesul de decizie:

volumul de informaţii în unitatea de timp considerată: completitudinea/redundanţa informaţiilor; precizia; vârsta; frecvenţa de utilizare în unitatea de timp; gradul de agregare al informaţiilor.

c2). Stabilirea aspectelor critice ale sistemului informaţional-decizional (analiza critică).

Analiza critică vizează atât organizarea cât şi funcţionarea sistemului informaţional-decizional şi se efectuează încercând să dea răspuns la întrebări cum sunt:

metodele şi tehnicile de decizie sunt corespunzătoare obiectivelor sistemului de conducere?

procedurile/modelele de decizie sunt eficiente? procedurile de prelucrare a datelor sunt eficiente? care sunt cerinţele curente de informare a conducerii? Dar dificultăţile

previzibile în satisfacerea acestor cerinţe? informaţiile vehiculate în sistem sunt necesare şi suficiente?

Analiza critică constă în: relevarea aspectelor negative, legate de organizarea şi funcţionarea

sistemului informaţional-decizional, pe baza evaluării acestui sistem conform criteriilor enunţate;

relevarea, pe cât posibil, a cauzelor generatoare de “perturbaţii”; sistematizarea aspectelor negative prin gruparea lor în “puncte critice”:

147

pe efecte în cadrul sistemului de conducere; Se vor evidenţia funcţiuni, activităţi ale sistemului afectate de aspectele negative din circuitul informaţional-decizional;

pe probleme ; Se vor evidenţia activităţi de prelucrare a datelor implicate în aspectele negative;

pe locuri ; Se vor evidenţia compartimente, locuri de muncă unde s-au constatat “perturbaţii”);

pe urgenţe de rezolvare.Activitatea de analiză-diagnostic informaţională se încheie practic cu o sinteză

sau raport de analiză, care cuprinde :a. Generalităţi:

prezentarea unităţii economice şi a obiectivelor ei; caracteristicile tipologice ale unităţii ; organizarea şi funcţionarea unităţii sau domeniului conform

reglementărilor în vigoare; prezentarea metodelor de organizare şi conducere folosite şi eficienţa

aplicării lor.b. Prezentarea sistemului informaţional-decizional: componentele sistemului şi structura lui; procesul de decizie şi principalele decizii, pe nivele; procedurile de prelucrare a datelor.

c. Analiza critică a sistemului informaţional-decizional: prezentarea aspectelor negative, grupate în “puncte critice”; prezentarea cauzelor generatoare.

d. Restricţii şi condiţii de introducere a noului sistem: modificările organizatorice necesitate de introducerea noului sistem; implicaţiile introducerii noului sistem asupra celorlalte domenii; componente ale sistemului organizaţional şi de conducere (compartimente,

persoane, activităţi) care se opun introducerii noului sistem; modul în care conducerea priveşte introducerea noului sistem.

Forma de redactare a raportului de analiză este aceeaşi ca în cazul analizei diagnostic tehnico-economice. Avantajul analizei-diagnostic informaţionale constă în faptul că, prin evidenţierea aspectelor negative şi gruparea lor în “puncte critice”, facilitează şi orientează analizele din următoarele etape de realizare a sistemului informatic. Restricţiile în aplicarea acestei tehnici sunt determinate de:

necesitatea includerii în echipă a unor specialişti în problema sau domeniul analizat, chiar în condiţiile în care analiştii sunt familiarizaţi cu această problemă;

necesitatea delimitării prealabile a problemelor sau domeniilor de analizat.

148

6.3.1.4. Analiza celularăTehnica analizei celulare este o tehnică de analiză complexă, utilizată în cadrul

metodei de abordare descendentă a sistemului obiect, atât pe compartimente, cât şi pe activităţi, care oferă informaţiile necesare:

proiectării sistemelor informatice complexe pentru unităţi economico-sociale, respectiv sisteme al căror număr de elemente este mare;

raţionalizării sistemului informaţional al unităţii, respectiv reordonării fluxului de informaţii şi standardizării evidenţelor din cadrul acestuia;

simulării unor posibile reorganizări ale unităţii, precum şi a îndeplinirii sarcinilor de serviciu pentru lucrătorii unităţii, după efectuarea acestor reorganizări.

Tehnica analizei celulare este deci o tehnică de abordare de tip top-down a sistemului-obiect. Utilizează ambele concepte de structurare – şi cel orientat pe organism şi cel orientat pe activitate, analiza efectuându-se în trei trepte:

treapta I - tratează structura organizatorică a întregului sistem studiat; treapta a II-a - tratează structura funcţională a sistemului şi/sau a

subsistemelor componente; treapta a III-a - efectuează analiza informaţiilor vehiculate în sistem,

informaţii care constituie legătura între cele două structuri.Tehnica analizei celulare foloseşte abordarea pornind de la analiza datelor în

determinarea cerinţelor de informaţii: pe fiecare nivel de descompunere a sistemului-obiect, obţinut prin metoda top-down, sunt culese şi analizate toate datele vehiculate în sistem.

Scopul utilizării tehnicii este obţinerea unor imagini analitice descriptive, detaliate ale sistemului-obiect, în general, şi al sistemului informaţional-decizional, în special, atât ca organizare cât şi ca funcţionare.

Conceptele folosite de tehnica analizei celulare sunt cele ale Teoriei Generale a Sistemelor şi ale Teoriei Analizei Celulare, şi anume:

a. Sistemul de conducere este considerat un sistem cibernetic, alcătuit din elemente legate atât între ele cât şi cu mediul. Fiecare element, la rândul său, poate fi considerat un sistem care se poate analiza independent şi, deci, descompune în elemente. Fiecărui element i se poate asocia o structură celulară.

Elementul de bază al unei asemenea structuri este celula, adică elementul component de pe ultimul nivel de agregare, care nu se mai poate divide (sau a cărui divizare nu mai prezintă interes).

O celulă este descrisă prin: - intrările (X); - ieşirile (Y);

- operatorul (T).Intrările celulei suferă o serie de transformări devenind ieşirile celulei.Conceptele de structurare folosite sunt: conceptul orientat pe organism, care foloseşte, pentru descrierea structurii

organizatorice, descompunerea: Unitate – Subunitate –Compartiment - Post;

149

conceptul orientat pe activitate, care foloseşte, pentru descrierea structurii funcţionale, descompunerea: Funcţie – Activitate – Sarcină - Procedură.

Funcţia se realizează prin una sau mai multe activităţi omogene. Fiecare activitate se conduce sau se execută prin sarcini. Sarcinile sunt un grup de proceduri de acelaşi fel: previziune, organizare,

dirijare, execuţie, control. Procedura este un complex de operaţii elementare care comportă luarea

unei decizii, efectuarea unui control, etc.b. Problema procesului de conducere fiind considerată a fi cea a

deciziilor şi a comunicaţiilor, pentru modelarea acestora tehnica analizei celulare utilizează terminologia din Teoria Informaţiilor, respectiv conceptele: emiţător, receptor, canal, mesaj, suport de informaţii.

Descrierea sistemului este făcută iterativ pe principiul descompunerii top-down, în următoarele etape:

delimitarea sistemului analizat, care poate fi întreaga unitate sau un domeniu al ei, în funcţie de etapa de realizare a sistemului informatic în care se efectuează analiza;

stabilirea structurii sistemului studiat: structura organizatorică şi funcţională;

stabilirea intrărilor, ieşirilor şi transformărilor succesive ale intrărilor şi ieşirilor la nivelul subsistemelor.

Paşii de realizare a tehnicii corespund operaţiilor care compun activitatea de analiză.

Culegerea datelorSunt culese date referitoare la: structura organizatorică şi cea funcţională, pe componente; restricţii faţă de funcţionarea sistemului, prevăzute în acte normative; relaţiile între elementele organizatorice şi funcţionale; informaţiile de intrare/ieşire utilizate sau generate de proceduri, cu

atributele lor, cum sunt :volum, frecvenţă, etc.; suporţii informaţiilor vehiculate (documente, evidenţe, tabele, constatări,

vizuale, informări verbale şi telefonice) generate de elementele de structură organizatorică (compartimente) şi de elementele de structură funcţională (proceduri de lucru).

Culegerea datelor se face pe formulare speciale completate în mod asemănător chestionarelor de către beneficiarii viitorului sistem informatic.

Sistematizarea informaţiilorConstă în:

a. Sistematizarea informaţiilor, obţinând cataloage ale: elementelor de structură organizatorică şi funcţională; restricţiilor; procedurilor;

150

informaţiilor; suporţilor de informaţii.b. Ordonarea informaţiilor culese:b.1. – gruparea procedurilor: pe elemente de structură (compartiment şi tip sarcină); după frecvenţa executării lor; după volumul de muncă necesară.b.2. – stabilirea unor relaţii între informaţiile din sistem: corespondenţa restricţii-proceduri; corespondenţa informaţii-suporţi; corespondenţa între elementele funcţionale şi cele organizatorice (legătura

proceduri-posturi), incluzând şi legăturile informaţionale între aceste elementeb.3. – descrierea canalelor de comunicaţie ale sistemului: intrările şi ieşirile procedurilor; circuitele de informaţii; încărcarea canalelor la intrare şi la ieşire. Evaluarea sistemului informaţional-decizionalDiagnosticarea sistemului existent constă în evidenţierea următoarelor:

- paralelisme în prelucrări;- sarcini neconcretizate în proceduri;- informaţii neutilizate de proceduri.

Această evidenţiere se realizează analizând:- gradul de încărcare cu activităţi a compartimentelor;- frecvenţa de executare a activităţilor;- circuitul informaţional şi al suporţilor (documentelor);

utilizarea informaţiilor; gradul de încărcare al canalelor de comunicaţie; paralelisme şi redundanţe.

Rezultatul aplicării tehnicii constă în imaginile descriptive ale sistemului-obiect. Acestea constituie o bază pentru raţionalizarea sistemului informaţional prin reproiectarea evidenţei şi eliminarea paralelismelor, depistarea procedurilor care ar trebui automatizate, datorită volumului mare de muncă necesitat şi al frecvenţei mare de execuţie.

Tehnica analizei celulare oferă o imagine completă şi foarte detaliată a sistemului-obiect, ceea ce constituie un mare avantaj, în special în cazul sistemelor complexe, de dimensiuni mari şi foarte mari, pentru care ar fi foarte greu de obţinut o descriere la fel de detaliată fără ajutorul unui instrument de analiză asistată de calculator. În schimb, tehnica analizei celulare, atunci când se aplică în etapa de elaborare a proiectului tehnic este o tehnică laborioasă şi necesită multă răbdare pentru completarea corectă şi completă a formularelor de culegere specifice.

151

6.3.2. Tehnici de analiză ce pot fi utilizate în etapa de proiectare

Analiza este o activitate distribuită, cu diferite ponderi pe parcursul întregului ciclu de realizare a sistemului informatic şi, ca urmare, o serie de tehnici ale analizei pot fi aplicate, de la caz la caz, în diferite etape.

Analiza şi apoi proiectarea sunt văzute ca activităţi care implică o serie de operaţii cum sunt: abstractizarea, elaborarea, operaţionalizarea, verificarea. În aceste condiţii au fost elaborate o multitudine de metode şi tehnici de analiză şi proiectare, care încearcă să ghideze efortul proiectanţilor şi totodată să micşoreze dependenţa soluţiilor de inspiraţia şi talentul individual al acestora.

Aceste metode şi tehnici pun accentul pe unul sau altul din aspectele relevate din punctul de vedere al proiectantului, cum sunt:

aspectul procedural fluxurile de control ierarhia funcţională structura datelor modificările de stare ale sistemului independenţa modulelor.

6.3.2.1. Analiza structurată prin decompoziţie funcţionalăUna din actualele abordări în proiectarea de sisteme informatice este şi

proiectarea structurată.Proiectarea structurată poate fi definită ca arta de a proiecta

componentele unui sistem şi relaţiile sau legăturile dintre aceste componente într-o manieră cât mai bună, în condiţiile în care cerinţele funcţionale ale sistemului au fost bine definite.

Proiectarea structurată constă într-un set de concepte, tehnici şi instrumente care-l ajută pe proiectant să subdividă sistemul în module relativ independente din punct de vedere funcţional, uşor de realizat şi întreţinut. Modulul se caracterizează prin funcţie, logică şi relaţii (interfeţe) cu alte module. Funcţia descrie transformările care se produc când modulul este apelat; ea este o descriere a „exteriorului” modulului, în timp ce logica modulului este o descriere a „interiorului” său.

Proiectarea structurată se referă la funcţia modulului, nu la logica sa.Prin proiectarea structurată se determină caracteristicile majore ale sistemului,

limitele şi performanţele, calităţile pe care cea mai bună implementare a soluţiei le poate atinge şi eventual costul final al sistemului.

Structurabilitatea este deci o caracteristică atât a produsului (rezultatul proiectării) cât şi a procesului prin care s-a realizat proiectarea.

Proiectarea structurată are ca obiectiv crearea într-un mod structurat a unor sisteme informatice, atât prin parcurgerea unui proces de proiectare structurat

152

cât şi prin crearea unui produs structurat. Ea înglobează la ora actuală o multitudine de concepte, tehnici şi instrumente care au la bază următoarele abordări:

- decompoziţie funcţională;- decompoziţie prin date;- decompoziţie hibridă (combinarea alternativă a primelor două abordări).Activitatea de proiectare integrează, de regulă, una sau mai multe din

următoarele operaţii1:- analiză: divizarea sistemului în elemente componente, determinarea

caracteristicilor acestor elemente şi implicit ale sistemului;- sinteză: agregarea acestor elemente, dintr-o colecţie de componente

posibile ale sistemului, care permit realizarea caracteristicilor cerute sistemului;- operaţionalizarea: realizarea unui sistem care funcţionează fără erori, iar

informaţiile pe care le furnizează sunt utile din punctul de vedere al conţinutului şi momentului de apariţie;

- abstractizarea: înlăturarea detaliilor nesemnificative şi extragerea caracteristicilor esenţiale ca ceva general pentru toate elementele componente luate în consideraţie. Principala funcţie a abstractizării este reducerea complexităţii;

- elaborarea: divizarea unei entităţi în părţile sale componente prin punerea în evidenţă a elementelor de detaliu;

- reprezentarea: transpunerea proiectării într-o formă inteligibilă, explicită şi modificabilă;

- iterarea: corectarea continuă a unei soluţii (proiect) prin reproiectări intermediare până când se ajunge la o soluţie finală acceptată;

- evaluarea: verificarea corectitudinii soluţiei în raport cu anumite criterii (specificaţii, standarde, normative).

Din mulţimea tehnicilor de proiectare structurată, în continuare va fi prezentată tehnica de proiectare structurată prin decompoziţie funcţională.

Tehnica constă din utilizarea unor principii de analiză pentru proiectarea soluţiei, a unei scheme pentru reprezentarea grafică a structurii funcţionale, a unei tabele de intrare/ieşire pentru reprezentarea fluxului de date şi unei modalităţi de evaluare a soluţiei. Tehnica poate fi denumită şi „tehnica Chapin”, după numele celui care a elaborat-o în cadrul Institutului de Tehnologie din Illinois.

Diferitele tehnici de proiectare structurată implică stiluri diferite de proiectare. Pentru crearea unui sistem informatic viabil structura sa funcţională trebuie să reflecte carateristicile funcţionale ale sistemului obiect. Duratele şi deci costurile de implementare a proiectului, întreţinere şi modificare, în general, pot fi minimizate când fiecare componentă mică a sistemului proiectat corespunde exact unei componente mici bine definite din sistemul obiect, iar fiecare legătură dintre

1 După unii autori (Naugton, Marker, Freeman, Thomas) aceste operaţii îşi propun să realizeze anumite scopuri care sunt specificate în dreptul fiecăreia.

153

componentele sistemului proiectat corespunde numai unei legături dintre componentele sistemului obiect.

Utilizând abordarea prin decompoziţie funcţională, tehnica are în vedere următoarele scopuri:

- realizarea unui proces de proiectare structurat;- realizarea unui produs structurat care să se caracterizeze prin:

grad înalt de modularitate; ierarhizare funcţională; depanare uşoară în caz de eroare; adaptare la resurse specifice şi la cerinţe utilizator noi; întreţinere uşoară.

Tehnica de proiectare structurată prin decompoziţie funcţională poate fi utilizată în activitatea de analiză şi proiectare din următoarele etape ale ciclului de viaţă ale unui sistem informatic: proiectare de ansamblu, proiectare de detaliu şi elaborare programe.

Dacă la un moment dat, se trage concluzia că este necesară revizuirea structurii, fluxul de proiectare se reia. Fluxul de proiectare generat prin utilizarea acestei tehnici implică înlănţuirea operaţiilor de proiectare astfel: analiză, abstractizare, sinteză, elaborare, operaţionalizare, reprezentare, evaluare, iterare.

Caracteristici:Tehnica este orientată pe funcţiuni şi abordarea top-down.Datorită acestor caracteristici, tehnica implică un proces de analiză

decompoziţională. În procesul de analiză se examinează funcţia supusă analizei – pentru identificarea unor subfunţii specifice a căror „sumă funcţională” să fie echivalentă cu funcţia dată. Procesul de analiză poate fi descris astfel:

Stabilirea funcţiei de analizat. Detalierea funcţiei prin analiză: funcţiile obţinute sunt toate părţi ale

funcţiei iniţiale. Reprezentarea rezultatului analizei, într-o formă grafică adecvată.Procesul continuă, rezultând astfel o ierarhie funcţională care are pe ultimul

nivel al descompunerii funcţii care nu mai necesită o descompunere din punct de vedere funcţional, numite funcţii terminale. În acelaşi timp, procesul de proiectare este un proces de sinteză, deoarece componentele funcţionale (funcţiile specifice) nu există apriori, ci proiectantul le creează pe parcursul procesului.

Procesul de proiectare începe întotdeauna cu o funcţie care caracterizează sistemul sau cu mai multe, care pot fi însă tratate independent păstrând totuşi legăturile dintre ele, dacă acestea există. Fiecare funcţie care se creează prin procesul de analiză a funcţiei inţiale devine, la rândul ei, o funcţie de analizat, reprezentând punctul de plecare pentru următorul nivel al procesului.

154

Principii de analiză

În literatura de specialitate sunt formulate o serie de principii care trebuie să stea la baza activităţii de analiză, şi anume1:

1. Analiza trebuie să conducă la identificarea unei secvenţe liniare de execuţie a funcţiilor.

În raport cu o funcţie, datele pot fi de intrare, asupra cărora acţionează funcţia, sau de ieşire, care rezultă în urma transformărilor exercitate de funcţia respectivă asupra datelor de intrare.

Prin aplicarea acestui principiu se creează subfuncţii care depind succesiv una de alta. Intrările unei subfuncţii trebuie să fie ieşiri ale altei funcţii.

2. Analiza trebuie să conducă la selectarea funcţiilor alternative.Funcţiile alternative dau sistemelor complexitate şi adaptabilitate. Inexistenţa

unor asemenea funcţii fac sistemele şi programele rigide.3. Analiza trebuie să conducă la identificarea funcţiilor interactive.4. Analiza trebuie să conducă la o delimitare precisă a intrărilor,

transformărilor şi ieşirilor.Principiul permite identificarea funcţiilor distincte. Două funcţii sunt

considerate distincte dacă au intrări diferite şi ieşiri diferite. Sunt identificate funcţiile care procură datele de intrare, cele care furnizează datele de ieşire, precum şi cele care realizează transformarea datelor de intrare în date de ieşire. Nu întotdeauna este necesară existenţa simultană a celor trei tipuri de funcţii. Aplicarea acestui principiu imprimă claritate şi eleganţă soluţiei de proiectare.

5. Analiza trebuie să conducă la plasarea funcţiilor de acţiune într-o poziţie subordonată funcţiilor de decizie care le afectează.

O funcţie de decizie este o funcţie care determină ce funcţii trebuie să fie executate şi în ce succesiune în timp.

O funcţie de acţiune este o funcţie care introduce sau extrage, transformă sau comunică date.

Efectul acestui principiu este concentrarea funcţiilor de decizie în partea superioară a structurii funcţionale, iar în partea inferioară concentrarea funcţiilor de intrare, a celor de ieşire şi a celor care execută transformări.

Funcţiile de pe nivelele inferioare trimit date „în sus”, în structura funcţională, către funcţiile de decizie, în care unele din date au rol de control şi declanşare a execuţiei funcţiilor de pe nivelele inferioare.

6. Analiza trebuie să conducă la izolare, ca subfuncţii specifice, a acelor subfuncţii a căror realizare este condiţionată de o decizie ulterioară de proiectare.

Prin „decizie ulterioară de proiectare” se înţelege existenţa mai multor alternative de soluţii referitoare la tipul de echipamente şi configuraţii utilizate, 1 I. Trandafir, R. Hrin, O. Iotici,V.Hărăbor,G Manolescu, C.Morandini, AMC 41,1984, pag 181

155

sistemul de operare disponibil, formatul intrărilor şi ieşirilor dorit de utilizator, algoritmii selectaţi etc. Aceste alternative decurg de obicei din incertitudinea tipului şi cantităţii de resurse avute la dispoziţie în momentul proiectării.

7. Analiza trebuie să conducă la minimizarea transferului de date dintre funcţii prin prevederea de funcţii specifice pentru modificarea distanţei datelor.

Comunicarea între funcţii necesită resurse - de timp, de hard şi de soft - şi presupune existenţa datelor pentru realizarea ei în sistem. Tabela de concordanţă intrări / ieşiri reprezintă o modalitate bună pentru aplicarea acestui principiu.

8. Analiza trebuie să conducă la prevederea unui singur punct de intrare şi a unui singur punct de ieşire pentru fiecare funcţie.

9. Analiza trebuie să se desfăşoare în mod exhaustiv numai după considerente funcţionale, astfel că, nivel cu nivel, trebuie să se definească subfuncţii omogene din punct de vedere al gradului de abstractizare.

Prin abstractizare în acest context se înţelege o grupare a unor date pe baza unor caracteristici comune. Întrebările care se pun la aplicarea acestui principiu sunt:

Ce trebuie să aibă comun funcţiile pentru a putea fi grupate pe nivelele superioare?

După ce criterii se descompun pe nivelele următoare?Funcţiile de pe nivelele superioare au un grad înalt de generalitate

(abstractizare) sau, altfel spus, un grad relativ mare de imprecizie, fiind lipsite de atribute de specificitate. Funcţiile de acest gen trebuie analizate şi descompuse în subfuncţii pe nivelele inferioare ale structurii.

Subfuncţiile astfel definite trebuie să aibă un grad relativ omogen de abstractizare (generalitate) care să fie însă mai mic decât cel al funcţiei de pe nivelul imediat superior. Această decompoziţie continuă nivel cu nivel, până la identificarea unor subfuncţii terminale, procesul de decompoziţie terminându-se atunci când se consideră că funcţia iniţială de la care s-a pornit este complet descrisă.

În concluzie, analiza unei funcţii date în contextul acestei tehnici este un proces de decompoziţie funcţională, în care trecerea de la un anumit nivel la cel inferior lui se face prin utilizarea principiilor prezentate.

Analiza prin decompoziţie funcţională presupune multă inventivitate, se bazează pe o experienţă acumulată în timp. Ea constituie o latură sintetică şi creativă în proiectarea structurată. Pentru reprezentarea structurii funcţionale se poate utiliza fie arborele de structură, fie schema Chapin. Pentru reprezentarea fluxului de date între module se utilizează tabela concordanţei intrări / ieşiri.

Proiectantul construieşte o tabelă de intrare/ieşire pentru un anumit modul, numai după ce au fost analizate toate funcţiile subordonate funcţiei reprezentate prin acel modul. Tabela de intrare/ieşire are forma de “T”. În partea stângă se reprezintă intrările în modul, iar în partea dreaptă ieşirile din modul. Numărul de intrări poate fi mai mare, mai mic, egal cu numărul de ieşiri sau poate fi zero.

156

Datele de intrare şi respectiv datele de ieşire sunt reprezentate în coloanele corespunzătoare ale tabelei de intrare/ieşire prin numele de identificare, sub formă de listă, fără o ordine prestabilită.

Datele, ca mijloc de realizare a legăturilor dintre modulele structurii funcţionale, pot avea unul din următoarele roluri în raport cu un anumit modul analizat:

Control (C) - realizează selectarea funcţiilor care se execută; Prelucrare(P) - participă la prelucrări sau la crearea unei date de ieşire

dorită; Transfer(T) - trec prin modul fără să-şi schimbe identitatea şi valoarea;

data este transmisă între două module prin modulul care este analizat; Modificată(M)- reprezintă rezultatul funcţiilor de prelucrare din modul;poate fi o modificare fie din punct de vedere al indentităţii, fie din punct de

vedere al valorii.Dacă pentru un modul nici una din date nu este de tip C, P sau M, atunci este

posibil ca modulul să nu aibă o funcţie utilă şi ar trebui eliminat. Excepţie poate să facă numai modulul rădăcină.

Avantajele utilizarii tehnicii prezentate sunt următoarele:- nu este exclusă creativitatea în procesul de proiectare:- specificarea clară a funcţiilor:- comunicarea explicită a concepţiei proiectantului relativă la funcţiile

reprezentate, în vederea implementării şi întreţinerii lor ;- face posibilă reprezentarea clară, concisă, neambiguă a proiectării;- permite crearea unui produs operaţional cu caracteristicile corespunzătoare;

Tehnica prezintă limite legate de faptul că nu dă nici o indicaţie relativă la modul de structurare a datelor, ea punând accent numai pe fluxul datelor.

Această metodă de determinare a informaţiilor de intrare pe baza celor de ieşire este foarte utilă îndeosebi în cazul sistemelor complexe care vehiculează multe informaţii. Este uşor de aplicat şi totodatã permite nu numai identificarea informaţiilor de intrare, ci şi a procedurilor sau operaţiilor din aceste proceduri. Totodatã ea permite gruparea informaţiilor şi eliminarea celor redundante.

Abordarea analizei poate fi fãcutã şi plecând de la intrãri şi ajungând la ieşirile sistemului informaţional. Acest mod de abordare presupune identificarea tuturor informaţiilor primare din sistem şi a legăturilor logice dintre ele. Cunoscând intrările sistemului se pot identifica diverse tipuri de informaţii de ieşire necesare fundamentării deciziilor. Această abordare are dezavantajul că nu permite punerea în evidenţă a tuturor legãturilor dintre datele primare existente în sistem, fapt care genereazã la un moment dat neajunsul cã nu se pot obţine anumite date de ieşire.

6.3.2.2. Tehnica tabelelor de decizie

157

Tehnica tabelelor de decizie pleacã de la conceptul de tabelã de decizie. O tabelã de decizie este o tabelă bidimensională cu dublã intrare. În funcţie de valorile logice ale condiţiilor (intrãri –conditii ) şi de valorile booleene ale acţiunilor (intrări – acţiuni), tabelele de decizie se clasificã în:

tabele de decizie cu intrãri limitate; tabele de decizie cu intrãri extinse; tabele de decizie cu intrãri mixte.În funcţie de tipul relaţiilor ce pot exista între diferite tabele diferenţiem: tabele de decizie deschise; tabele de decizie închise. De cele mai multe ori, o problemã nu poate fi reprezentatã într-o singurã tabelã

din cauza numãrului mare de reguli, condiţii şi acţiuni. În acest caz, dacă este posibil, problema se împarte în mai multe subprobleme ce pot fi reprezentate separat prin câte o tabelă de decizie, legate apoi prin instrucţiuni.

Grila informaţională sau de decizie reflectă o problemă şi conţine informaţiile de intrare, informaţiile de ieşire precum şi modul de obţinere a informaţiilor de ieşire din cele de intrare

Aceastã grilã oferã posibilitatea gãsirii unei grupe de condiţii şi acţiuni ale unui proces de decizie care să aibă o slabã legăturã între ele. Ea nu implicã neapărat descrierea precisă a intrărilor, ci doar marcheazã dacã existã o legăturã logicã între acţiuni şi condiţii. Construirea grilei se face în etapa de analiză a problemei informaţionale. În urmãtoarea etapã se face analiza grilei informaţionale cu scopul descompunerii şi transformării acesteia în tabele de decizie.

Grila informaţionalã este utilã deoarece prezintã: logica luãrii deciziilor într-o formã mai compactã; relaţia directă între fiecare acţiune şi fiecare condiţie

6.4. Sistematizarea informaţiilor culese

Pentru sistematizarea informaţiilor în urma studiului şi analizei sistemului existent se utilizează aşa-numitele tehnici de reprezentare. De fapt, ele pot fi utilizate în toate etapele de realizare a sistemelor informatice. Dintre aceste tehnici, cele mai utilizate sunt :

scheme organizatorice; scheme de sistem; scheme logice; scheme de prelucrare;

Schemele organizatorice (organigrame) reprezintã structura organizatoricã, funcţionalã a unei unitãţi economice. Printr-o asemenea organigramã se pun în evidenţã nivelele de conducere, serviciile funcţionale sau secţiile productive şi

158

modul de subordonare a acestora. Pot fi puse în evidenţã, de asemenea, tipurile de decizii la nivelul fiecãrui factor de decizie. În cazul unei aplicaţii informatice poate fi delimitatã structura organizatorică pe care este grefată aplicaţia informatică.

Prin schemele de sistem se descriu purtătorii de informaţii, legătura dintre ei, fluxul circulaţiei informaţiei între purtători. Schemele de sistem se utilizeazã în etapa de analizã, concepere, proiectare tehnică, elaborarea programelor. Prin intermediul lor se pun în evidenţă intrările, ieşirile şi prelucrările, fără a intra în detaliu.

Procedura de prelucrare poate fi detaliată ulterior. Ele constituie o parte componentã a documentaţiei sistemelor informatice. Se pot utiliza şi pentru a pune în evidenţã intrările, ieşirile pentru o aplicaţie informatică.

Schemele logice descriu, cu un înalt grad de detaliere, algoritmul de rezolvare a unei probleme; ele constituie un mod grafic, convenţional de reprezentare al unui algoritm. O alternativã a utilizãrii schemelor logice clasice este utilizarea diagramelor de structurã sau a altor forme echivalente.

Schemele de prelucrare (diagramele globale de flux) descriu prelucrările în cadrul unui sistem informaţional sau informatic. Sunt larg utilizate datorită simplităţii convenţiilor de reprezentare şi vizualizare a structurii şi funcţionării sistemului. Ele constituie un mod eficient de comunicare între spoecialiştii din domenii de activitate diferite. Reprezintă un instrument al cunoaşterii ansamblului activităţilor desfăşurate în sistem. Pentru aspecte de detaliu privind circuitul informaţional ele sunt insuficiente în reflectarea legăturilor informaţionale.

6.5. Evaluarea sistemului existent. Definirea direcţiilor de perfecţionare a actualului sistem

Pe baza activitãţilor de evaluare şi analizã criticã se identificã neajunsurile actualului sistem şi se propun soluţii de înlãturare a acestora, se formuleazã variante de soluţii, iar în cadrul acestora se definesc cerinţele şi restricţiile de realizare a sistemului informatic.

Definirea direcţiilor de perfecţionare presupune: specificarea obiectivelor şi a performanţelor sistemului informatic; stabilirea domeniilor de probleme şi a principalelor funcţiuni ale

sistemului informatic; definirea cerinţelor şi restricţiilor informaţionale pe domenii de probleme

şi funcţiuni care constã în:

159

- definirea principalelor intrãri/ ieşiri; - definirea soluţiei de organizare a datelor;- definirea variantelor tehnologice de prelucrare; - definirea restricţiilor informaţionale şi de control.

formularea condiţiilor pentru realizarea sistemului informatic, care constã în:

- specificarea termenelor şi duratelor solicitate; - precizarea prioritãţilor în realizarea obiectivelor sistemului informatic; - specificarea cerinţelor speciale privind flexibilitatea, compatibilitatea cu alte sisteme, gradul de generalizare al sistemului.

Pentru fiecare variantã de soluţie informaticã se procedeazã la: - evaluarea resurselor necesare (costurile de sistem);

- evaluarea efectelor economice directe şi indirecte; - calculul indicatorilor de eficienţã economicã.

avizarea şi alegerea variantei de sistem de cãtre beneficiar pe baza indicatorilor de eficienţã economicã.

160

7. PROIECTAREA DE ANSAMBLU A SISTEMELOR INFORMATICE7.1. Prezentare generală

Proiectarea de ansamblu este o activitate distinctă în proiectarea unor sisteme informatice sau aplicaţii complexe, care au structuri complexe, în care se pot identifica subsisteme pe mai multe nivele. În această etapă se realizează practic analiza globală şi specificarea cerinţelor noului sistem, modelul de ansamblu al sistemului informatic, structurarea datelor şi specificarea soluţiilor de administrare a datelor, proiectarea arhitecturii configuraţiei de echipamente şi planificarea realizării noului sistem pe părţi componente.

Această proiectare la nivel global este urmată, în astfel de cazuri, de o proiectare de detaliu a fiecărei componente în parte, cu cele două forme ale sale : proiectare logică de detaliu şi proiectare tehnică de detaliu.

Dacă este vorba deci de realizarea unei aplicaţii în cadrul unui sistem existent sau de realizarea unui produs program punctual, nu mai este necesară o proiectare de ansamblu, ci se trece direct la proiectarea de detaliu.

Proiectarea de ansamblu, denumită şi etapa de concepere a sistemului informatic, cuprinde o succesiune de activităţi, cum sunt: definirea obiectivelor sistemului; structurarea sistemului informatic pe subsisteme şi componente; definirea globală a ieşirilor; definirea globală a intrărilor; definirea colecţiilor de date comune; alegerea soluţiilor tehnice; estimarea necesarului de resurse; estimarea eficienţei economice; planificarea realizării sistemului; elaborarea documentaţiei corespunzătoare.

În cadrul acestei etape se impune ca sistemele informatice proiectate să îndeplinească o serie de cerinţe, cum sunt:

Să conţină ca element central o bază de date în care sunt stocate date intercorelate, provenind atât din surse interne cât şi externe, necesare conducerii pentru fundamentarea deciziilor. Acestea pot fi atât date cu caracter normativ cât şi date privind starea sistemului condus. Utlizarea bazei de date ca fond centralizat de date nu exclude posibilitatea existenţei şi altor fişiere specifice unor aplicaţii din cadrul sistemului;

Informaţiile furnizate de sistem să fie corecte, autentice, exacte. Suportul de prezentare, formatul şi gradul de sintetizare / agregare al datelor diferă de la un nivel de conducere la altul, funcţie de cerinţele de informare ale fiecăruia ;

Sistemul trebuie să asigure prelucrarea şi transmiterea informaţiilor la conducere în timp util, adică informaţiile furnizate să fie operative ;

Să înglobeze în procedurile de prelucrare a datelor modele matematice, tehnico-economice şi statistice adecvate, în vederea unei fundamentări ştiinţifice a informaţiilor oferite conducerii;

Să fie conceput ca un sistem om-maşină care să ofere posibilitatea interacţiunii imediate dintre utilizator şi sistem. Acest lucru se impune cu atât mai mult cu cât decidentul uman este plasat mai sus în ierarhia conducerii, iar

161

distribuirea sarcinilor între om şi maşină derivă din capacităţile şi limitele utilizatorului;

Sistemul trebuie să prezinte un grad cât mai mare de integrare sub următoarele aspecte: integrare internă prin asigurarea legăturilor dintre modulele funcţionale ale sistemului şi integrare externă prin asigurarea legăturilor cu alte sisteme atât pe orizontală cât şi pe verticală.

Sistemul trebuie să aibă flexibilitate maximă, adică să fie uşor adaptat sau modificat în cazul unor noi cerinţe ale sistemului de conducere. Pentru realizarea unor sisteme informatice care să întrunească asemenea caracteristici este necesar să ţinem seama de o serie de cerinţe încă din etapa de concepere, cum sunt:

- Conceperea sistemului informatic să fie fundamentată pe criterii de eficienţă economică. Acesta presupune compararea cheltuielolor estimate ca necesare pentru realizarea şi funcţionarea sistemului (proiectare, implementare, exploatare şi dezvoltare) cu efectele economice directe şi indirecte ce se vor obţine prin introducerea noului sistem informatic sau aplicaţie informatică. În acest sens se va urmări ca termenul de recuperare al cheltuielilor să fie cât mai scurt.

- Participarea nemijlocită a conducerii unităţii la conceperea sistemului informatic, prin formularea cerinţelor informaţionale, prin definirea şi ierarhizarea obiectivelor acestuia, prin stabilirea programului de realizare eşalonată a acestuia, pe elemente componente.

- Asigurarea unui nivel tehnic înalt al soluţiilor adoptate. Proiectanţii au ca sarcină utilizarea celor mai moderne şi adecvate metode, tehnici, instrumente, soluţii tipizate şi tehnologii informatice în vederea creşterii calităţii produselor informatice.

- Adoptarea unor soluţii de proiectare în concordanţă cu resursele disponibile şi cu restricţiile impuse în legătură cu: echipamentele de calcul, programele, personalul de specialitate, resursele financiare şi de timp etc.

7.2. Definirea obiectivelor sistemului informatic şi a ariei de cuprindere a acestuia

Aria de cuprindere a sistemului informatic se stabileşte în strânsă legătură cu obiectivele definite pentru acesta. Aceste obiective nu vor fi identice pentru toate societăţile beneficiare, căci ele vor fi definite în urma unei analize complexe a stării şi comportamentului sistemului economic respectiv, efectuată împreună cu conducerea unităţii de la toate nivelele ierarhice.

O asemenea analiză globală a sistemului se efectuează pentru a cunoaşte: evoluţia situaţiei economice şi financiare a unităţii, reflectate prin indicatori sintetici; eficacitatea cu care sunt utilizate resursele financiare; eficienţa economică a utilizării mijloacelor fixe; rentabilitatea produselor şi serviciilor, etc. În urma acestei activităţi de documentare şi analiză critică se vor fi identifica

162

"punctele slabe" ale sistemului, eventualele rezerve interne, eventualele necorelări şi contradicţii care ar putea fi eliminate sau diminuate prin introducerea noului sistem informatic. Pe baza acestor constatări se formulează obiectivele sistemului informatic ce se va proiecta, se identifică sarcinile ce vor fi preluate de acesta, determinandu-se astfel aria de cuprindere a sistemului pentru diferitele stadii sau etape de dezvoltare. Se formulează deci cerinţele şi restricţiile globale pentru realizarea sistemului şi a subsistemelor componente, se justifică necesitatea, oportunitatea şi fezabilitatea sistemului.

Urmează apoi elaborarea modelului de ansamblu al viitorului sistem informatic.

7.3. Structurarea sistemului informatic

Necesitatea structurării sistemului în elemente componente, ierarhizate după anumite criterii, este impusă, în practica de realizare a sistemelor informatice, de considerente precum :

- procesul de realizare a unui sistem se desfăşoară în timp, etapizat, prin dezvoltarea unor componente care ulterior sunt asamblate ;

- modul de organizare, conducere şi desfăşurare a lucrărilor de proiectare necesită în diverse momente o diviziune a muncii, pe elemente componente ale sistemului ;

- cerinţele unora dintre utilizatorii sistemului se referă doar la anumite părţi ale acestuia.

Elaborarea modelului de ansamblu al sistemului informatic presupune deci descompunerea sistemului informaţional-decizional în subsisteme relativ autonome. Fiecare subsistem al sistemului informatic va avea funcţiunile, intrările şi ieşirile sale, colecţii de date specifice, algoritmi de transformare a intrărilor în ieşiri informaţionale.

Intrările unui subsistem de la alte subsisteme, precum şi ieşirile către alte subsisteme constituie legăturile dintre ele, care vor fi materializate prin transferuri de date. La nivelul sistemului va exista şi o colecţie de date comună tuturor subsistemelor componente. În ceea ce priveşte legăturile externe, acestea vor fi reprezentate prin transferuri de informaţii către alte sisteme sau de la alte sisteme.

Deci, prin structurarea sistemului informatic se vor evidenţia subsistemele componente, legăturile dintre acestea precum şi conexiunile exterioare ale sistemului cu alte sisteme, pe verticală şi pe orizontală. Se trece apoi la proiectarea, la nivel global, a subsistemelor componente.

Structurarea sistemului informatic se impune cel puţin din următoarele considerente: numărul mare de elemente şi legături care compun, de regulă, un sistem informatic face aproape imposibilă definirea şi precizarea până în cele mai

163

mici detalii a acestora, astfel încât sistemul să poată fi proiectat "în bloc"; implementarea simultană a tuturor componentelor sistemului informatic într-o unitate economică, fără perturbarea activităţii acesteia, apare ca deosebit de dificilă, datorită complexităţii şi dinamicii proceselor şi fenomenelor economice din cadrul unităţii; stabilirea priorităţii unor obiective faţă de altele ; resurse financiare, umane şi materiale limitate ; necesitatea acumulării experienţei în domeniul proiectării sistemelor informatice.

Structurarea sistemului informatic pe elemente componente asigură astfel posibilitatea realizării eşalonate a sistemului informatic.

O serie de cerinţe se vor avea în vedere la structurarea sistemului informatic. Astfel :

- pe fiecare nivel al structurii se impune asigurarea unicităţii criteriului de descompunere a sistemului;

- structura realizată trebuie să permită constituirea sistemului prin agregarea modulelor;

- structura nu trebuie să conţină suprapuneri ale modulelor componente;- structura trebuie să fie pe cât posibil naturală, ceea ce înseamnă că trebuie

să fie obţinută pe baza unui criteriu semnificativ şi esenţial. Ţinând cont de toate aceste cerinţe, în structurarea unui sistem informatic se

utilizează o serie de criterii de descompunere în subsisteme şi module componente, cum sunt :

a). Criteriul funcţional de structurare, potrivit căruia un sistem informatic este structurat în mai multe subsisteme funcţionale. Potrivit acestui criteriu, structura funcţională a unui sistem informatic pentru conducerea unei unităţi economice, este grefat pe funcţiunile de bază ale acesteia, şi anume: Producţie sau Prestări servicii, Comercială (Aprovizionare – Desfacere), Financiar – Contabilitate, Resurse umane, Cercetare –Dezvoltare, Cercetare ştiinţifică şi Marketing.

Fiecărei funcţii îi va corespunde, conform acestui criteriu de descompunere, câte un subsistem funcţional.(fig 7.1). La rîndul lor, subsistemele funcţionale vor fi descompuse în module sau aplicaţii informatice în concordanţă cu atributele conducerii şi nivelul de conducere: strategic, tactic sau operativ.

b). Structura ierarhică/organizatorică poate constitui un alt criteriu de structurare a sistemului în subsisteme la nivelul compartimentelor sau structurilor organizaţionale ale societăţii.

c) În raport cu nivelele de decizie existente în cadrul societăţii se pot identifica subsistemul strategic, subsistemul tactic şi subsistemul operativ.

Prin urmare, în cadrul sistemului vom defini subsistemele componente, iar în cadrul acestora, aplicaţiile informatice sau modulele componente, cu legăturile informaţionale pe care le necesită, cu intrări, ieşiri, colecţii de date şi algoritmi de prelucrare descrişi la nivel global.

164

Sistemul trebuie să urmărească realizarea obiectivelor generale ale societăţii, fixate pe o perioadă mai lungă de timp. În fixarea şi eşalonarea obiectivelor generale îşi găseşte expresia atributul de previziune al conducerii. De exemplu, aceasta are ca obiectiv atingerea unui anumit nivel al producţiei într-un interval de timp, creşterea rentabilităţii societăţii, etc.

Subsistemul corespunde de regulă unor obiective derivate din cele generale. De exemplu, aprovizionarea cu materii şi materiale conform cerinţelor, politica de vânzare a produselor, cercetarea şi proiectarea produselor şi tehnologiilor noi, etc.

Aplicaţia, ca unitate componentă a subsistemului, se dezvoltă de regulă la nivelul unor activităţi sau compartimente din cadrul societăţii, cum ar fi: programarea, lansarea şi urmărirea producţiei, urmărirea contractelor, etc

În cadrul sistemului informatic orice aplicaţie este alcătuită din programe, proceduri manuale şi date care, utilizând echipamentele specificate în documentaţia aplicaţiei, realizează prelucrarea automată a datelor şi conduc la obţinerea performanţelor dorite.

Structurarea sistemului, împărţirea lui în subsisteme şi aplicaţii rămâne o problemă a proiectantului, pe care acesta o rezolvă de la caz la caz, în funcţie de mărimea, complexitatea şi specificul societăţii, de obiectivele şi cerinţele beneficiarului, de criteriile de eficienţă adoptate.

Fig 7.1: Structura funcţională a unui sisteme informatic la nivelul unei unităţi economice

7.4. Definirea ieşirilor sistemului

Obiectivele oricărui sistem informatic se concretizează practic în satisfacerea cerinţelor informaţionale ale conducerii, pentru fundamentarea sau asistarea deciziilor. Concret, aceasta înseamnă furnizarea la cerere sau periodic a situaţiilor, a rapoartelor de ieşire care grupează informaţii, date necesare cunoaşterii realităţii curente. Pe baza acestora se fundamentează deciziile pentru dirijarea funcţionării viitoare a unităţii economice.

165

Utilitatea şi viabilitatea sistemului informatic este determinată de tipul, conţinutul şi operativitatea cu care se transmit situaţiile de ieşire la factorii de decizie.

Ieşirile sistemului vor fi definite pentru fiecare subsistem în parte. Prin "ieşirile" unui subsistem informatic înţelegem totalitatea informaţiilor furnizate de acesta beneficiarilor interni şi externi.

Definirea "ieşirilor" fiecărui subsistem informatic la nivel global presupune în primul rând, stabilirea la nivel global a informaţiilor necesare conducerii pe diferite trepte ierarhice, precizând, pentru fiecare în parte, conţinutul informaţional, periodicitatea, numărul de exemplare, destinatarul. În definirea ieşirilor vom ţine cont şi de restricţiile privind conţinutul şi forma de prezentare a acestora, cum ar fi cazul unor rapoarte tipizate (bilanţ). Pe baza acestora se va realiza apoi proiectarea logică şi fizică de detaliu a ieşirilor.

7.5. Definirea intrărilor sistemului

Definim "intrările" sistemului informatic ca fiind totalitatea datelor primare necesare obţinerii informaţiilor de ieşire ale sistemului.

Datele primare reflectă starea şi dinamica fenomenelor şi proceselor economice din unitatea economică, necesare pentru crearea, actualizarea bazei de date şi obţinerea situaţiilor de ieşire. Acestea pot fi externe sau interne unităţii economice.

Definirea intrărilor trebuie să includă toate elementele necesare realizării tehnice ulterioare a documentelor de intrare şi să ofere soluţii pentru preluarea datelor în sistemul informatic. Pe baza acestora se va face apoi proiectarea logică şi tehnică de detaliu a intrărilor.

La nivelul fiecărui subsistem informatic "intrările" sunt condiţionate de "ieşirile" sale pe două planuri: în plan logic, orice "ieşire" este un rezultat al aplicării unuia sau mai multor operatori asupra unui ansamblu de date de intrare. Odată definite "ieşirile" sistemului şi operatorii de transformare, "intrările" vor apare ca determinate de aceste "ieşiri". În plan tehnologic, caracteristicile cerute ieşirilor sistemului (obiectivitate, fiabilitate, precizie) condiţionează caracteristicile cerute intrărilor, în particular în ceea ce priveşte datele elementare.

Rezultă deci că determinarea intrărilor presupune o analiză care are ca punct de plecare informaţiile de ieşire din subsistem. După determinarea "intrărilor" sub aspectul conţinutului global al acestora, pentru fiecare document de intrare se va stabili sursa de provenienţă, periodicitatea, volumul, numărul de exemplare, etc. De asemenea, se pot defini la nivel global posibilităţile şi modalităţile de culegere şi verificare în vederea stocării lor. În acest sens trebuie subliniat faptul că există un număr însemnat de documente primare tipizate, adaptate la prelucrarea automată a datelor care pot fi utilizate în cadrul sistemelor informatice.

166

7.6. Stabilirea globală a colecţiilor de date

În această etapă se realizează proiectarea modelului conceptual de ansamblu al datelor, se identifică tipurile de entităţi şi relaţiile dintre acestea, se definesc astfel, la nivel global, colecţiile de date, se face analiza soluţiilor pentru administrarea şi manipularea datelor.

Pornind de la datele definite global în toate aceste activităţi, se trece la gruparea lor în colecţii de date pe baza unor criterii, pentru fiecare subsistem în parte şi la nivelul întregului sistem. Se obţin astfel colecţiile de date specifice fiecărui subsistem şi colecţiile de date comune sistemului. Aceste colecţii au un caracter orientativ pentru proiectarea fişierelor şi/sau entităţilor bazei de date.

Sunt formulate o serie de criterii pe baza cărora se poate face gruparea datelor. Dintre acestea mai cunoscute sunt: stabilitatea conţinutului datelor, domeniul de activitate, sfera de cunoaştere, rolul datelor în procesul prelucrării etc.

a). Din punct de vedere al stabilităţii datelor se pot identifica: - colecţii de date convenţional-constante ;- colecţii de date variabile. La colecţiile de date variabile actualizarea se face des şi conţinutul datelor se

schimbă frecvent. În cadrul colecţiilor de date convenţional-constante o importanţă deosebită o

au datele cu caracter normativ care reprezintă, după cum arată practica, 50 – 60% din volumul total de informaţii care circulă în procesul informaţional al unei unităţi economice. Aceste colecţii de date se mai numesc şi nomenclatoare. Coeficientul de stabilitate al acestor date, definit ca raport între numărul poziţiilor neschimbate dintr-un nomenclator şi numărul total de poziţii, este foarte mare, îndeosebi la unităţile cu producţie de masă, ajungând la valori chiar mai mari de 0,9.

Dintre colecţiile de date cu caracter normativ putem aminti următoarele: - normative de fabricaţie, care memorează componenţa şi structura produselor, numărul de subansamble şi repere care intră în fiecare unitate de produs, sursa acestor informaţii fiind fişa produsului sau reţeta de fabricaţie;

- normative tehnologice, care determină fluxul tehnologic, succesiunea operaţiilor pe diferite utilaje, categoria operaţiei şi calificarea executantului, sursa acestor informaţii fiind fişa tehnologică;

- normative de muncă, acestea referindu-se la timpul consumat pentru executarea unei operaţii sau reper ;

- normative materiale, care se referă la consumul de materie primă şi materiale pe unitate de produs, semifabricat, subansamblu, reper etc.;

- alte normative care memorează timpii de aşteptare interoperaţii, norma de stoc de materiale, norma de stoc de produse, de mijloace circulante, de producţie neterminată etc..

167

b). Din punct de vedere al prelucrării datelor, colecţiile de date se pot grupa în: colecţii de date de bază; colecţii de date pentru tranzacţii; colecţii de date intermediare; colecţii de date statistice; colecţii de date istorice etc.

Colecţiile de date de bază au un conţinut omogen, format din date primare care reflectă stări, caracteristici, evenimente, fapte preluate din unul sau mai multe documente primare. Ele formează fondul de bază al datelor din cadrul sistemelor informaţionale şi au un caracter relativ permanent, în sensul că au o anumită stabilitate în cadrul colecţiei funcţie de existenţa obiectului de referinţă. Dacă dispare obiectul de referinţă dispar şi datele care îl caracterizează. Se poate aprecia că datele îşi păstrează valabilitatea, relevanţa, autenticitatea, au o utilitate pe perioada de existenţă a obiectelor pe care le reprezintă, le descriu, le reflectă. Mărimea acestei perioade de timp este specifică fiecărei colecţii, este delimitată cronologic de momentul apariţiei, înscrierii datelor şi de momentul dispariţiei. În afara acestor limite datele îşi pierd valabilitatea, devin perimate, rămânând doar cu o valoare istorică. Aceleaşi caracteristici cronologice şi acelaşi rol îl au şi nomenclatoarele de coduri asociate lor. Aceste colecţii de date de bază vor fi organizate de regulă în fişiere obiect sau în baze de date.

Colecţiile de date pentru tranzacţii au un caracter temporar şi un conţinut format din totalitatea modificărilor care pot interveni pe parcursul unui interval de timp asupra conţinutului informaţional din colecţiile de date de bază. Deci, aceste colecţii de date sunt utilizate pentru actualizarea colecţiilor obiect şi a nomenclatoarelor. De regulă, în cadrul sistemului, aceste colecţii sunt organizate în fişiere pentru actualizări (tip jurnal).

Colecţiile de date intermediare sau de lucru sunt obţinute pe baza unor operaţii de sortare, fuziune, selectare din una sau mai multe colecţii obiect potrivit unor cerinţe furnizate de utilizator în vederea obţinerii unei situaţii cu rezultate finale sau seturi de situaţii. Acestea vor constitui în sistem fişierele de lucru.

Colecţiile de date statistice au un rol de orientare, de previziune, de fundamentare a unor decizii strategice. Datele din aceste colecţii au un grad mare de sintetizare şi agregare astfel încât ele pot fi păstrate pe perioade mai mari de timp. Aceste colecţii în sistemele informatice vor fi organizate în fişiere statistice.

Colecţiile de date istorice au rolul de arhivare a conţinutului unor colecţii obiect, de tranzacţii sau statistice şi reflectă o stare trecută a fenomenelor şi proceselor economice. Aceste colecţii de date vor fi stocate pe suporţi magnetici, putând fi oricând interogate, verificate sau consultate.

c). După sfera de cunoaştere se pot identifica patru tipuri de colecţii mari de date cu utilitate diferită, cu grad de agregare şi sintetizare a datelor diferit şi anume: date primare; indicatori tehnico-economici cu caracter operativ; indicatori tehnico-economici cu centralizare medie şi indicatori sintetici.

Includerea unor date din ultimele trei colecţii în structura logică a fişierelor sau a entităţilor bazei de date nu este recomandată în mod normal, dar, dacă este

168

bine motivată şi controlată, dacă există o cunoaştere profundă a fenomenelor şi proceselor economice descrise, şi dacă este folosită cu multă atenţie, ea ar putea să conducă la reducerea costurilor de prelucrare automată a datelor, la creşterea operativităţii sistemelor de prelucrare, la creşterea eficienţei sistemelor informatice.

d). După domeniul de activitate la nivelul unei unităţi productive datele pot fi grupate în colecţii ce reflectă entităţi, fenomene şi procese economice.

Aceste colecţii sunt întâlnite la nivel microeconomic în unităţile productive din industrie, transporturi, agricultură, comerţ etc.

Astfel, vom putea întâlni colecţii de date cum sunt :Angajaţi – cu datele ce caracterizează entitatea Angajaţi ;Produse – cu datele ce caracterizează entitatea Produse ;Comenzi – cu date ce caracterizează entitatea Comenzi ;Gestiuni – cu date ce caracterizează entitatea Gestiuni ;Materiale – cu datele ce caracterizează entitatea Materiale ;Încasări – cu datele ce caracterizează entitatea Incasări ;Beneficiari – cu datele ce caracterizează entitatea Beneficiari ;Furnizori – cu datele ce caracterizează entitatea Furnizori ;Plăţi – cu datele ce caracterizează entitatea Plăţi, etcOdată cu stabilirea colecţiilor de date, în această etapă se stabilesc şi o serie de

caracteristici globale, cum sunt: conţinutul, stabilitatea, gradul de sintetizare şi agregare a datelor, utilitatea colecţiei, frecvenţa de actualizare, volumul etc. Cu aceste elemente se poate construi un dicţionar de date cu următoarea structură: codul de identificare, semnificaţia datei, natura, lungimea, sursa, destinaţia.

Odată ce au fost determinate colecţiile de date şi principalele caracteristici globale ale acestora, se poate alege soluţia de organizare şi manipulare a datelor în fişiere, bază sau bancă de date.

7.7. Alegerea tipurilor de modele matematice ce urmeazã a fi utilizate

Pentru optimizarea proceselor economice dintr-o unitate economică sistemul informatic trebuie să se bazeze pe folosirea metodelor şi tehnicilor din teoria sistemelor şi cibernetica economică, pe introducerea unor modele economico-matematice care să-i confere valenţe sporite în analiza proceselor economice şi fundamentarea deciziilor. Toate acestea au ca scop descoperirea rezervelor interne, creşterea volumului de producţie, reducerea costurilor, sporirea profitului, creşterea productivităţii muncii. Alegerea tipului de model utilizat depinde de domeniul în care urmează să se realizeze sistemul informatic, de specificul problemei abordate, de echipamentele de calcul şi programele existente etc .

169

Modelele matematice folosite în fundamentarea ştiinţifică şi perfecţionarea activităţii economice pot fi:

- Modele de programare liniară- Modele de programare neliniară - Modele de programare dinamică - Modele de tip A.D.C. - Modele de teoria grafurilor - Modele de gestiune a stocurilor - Modele de programarea producţiei- Modele de simulare , Modele de teoria deciziilor - Modele de aşteptare, Modele de tip INPUT, etc. De exemplu, în domeniul comerţului exterior, alegerea ofertei optime

reprezintã una din principalele exigenţe la contractare şi se poate realiza prin aplicarea unor modele de decizii multicriteriale în paralel cu asigurarea fondului de date referitoare la dinamica preţurilor, documentaţia tehnică, performanţele utilajelor sau maşinilor etc.

7.8. Alegerea tehnologiei de prelucrare şi estimarea necesarului de resurse

Alegerea tehnologiei de prelucrare automată a datelor se face în funcţie de calitatea şi dimensiunile resurselor alocate, de specificul sistemului obiect, dar şi de modul în care aceste resurse pot fi utilizate pentru satisfacerea cerinţelor impuse sistemului informatic.

Tehnologiile se pot clasifica după diverse criterii cum ar fi : metodele, tehnicile şi echipamentele utilizate; modul de organizare şi structurare a datelor; modalităţi de culegere şi preluare a datelor; metode şi tehnici de prelucrare a datelor, posibilităţi de redare a rezultatelor obţinute etc.

Astfel, ţinând cont de modul de preluare şi transmitere a datelor putem vorbi de:

- Tehnologii fără procedee de teletransmisie şi teleprelucrare a datelor;- Tehnologii cu procedee de teleprelucrare a datelor. Tehnologia de teleprelucrare a datelor face posibilă asigurarea regimului de

lucru interactiv, conversaţional, care permite un dialog om-calculator la distanţă, de forma întrebare-răspuns. Dialogul permite facilităţi de obţinere de la distanţă şi de transmitere la distanţă a rezultatelor sau datelor cerute.

Ţinând cont de performanţele lor tehnico-funcţionale legate de viteza de execuţie a operaţiilor de culegere, înregistrare, prelucrare şi afişare a datelor obţinute din prelucrare, tehnologiile de prelucrare automată a datelor se mai pot grupa în:

- Tehnologii cu răspuns întârziat, specifice sistemelor informatice statistice, de evidenţă, caracterizate prin faptul că oferă informaţii cu întârziere faţă de momentul producerii fenomenului, procesului sau activităţii la care se referă.

170

- Tehnologii în timp real, care oferă informaţii practic instantaneu faţă de momentul producerii procesului sau activităţii la care se referă datele prelucrate. Aceste tipuri de tehnologii sunt, de fapt, tehnologii de teleprelucrare a datelor cu înalte performanţe tehnico-funcţionale utilizate pe scară largă în conducerea proceselor tehnologice, a unor procese cu viteză mare de desfăşurare, pentru controlul operativ al stocurilor, pentru operaţiuni bancare etc.

Funcţie de modul de structurare şi organizare a datelor tehnologiile de prelucrare automată a datelor pot fi grupate în: tehnologii care utilizează fişiere clasice, tehnologii care utilizează fişiere clasice şi fişiere integrate; tehnologii care utilizează baze de date (specifice, distribuite, relaţionale etc.).

Funcţie de modul de amplasare a calculatorului electronic în raport cu punctele de generare a datelor şi cu cele de valorificare a informaţiilor obţinute din prelucrare, tehnologiile mai pot fi grupate în :

- Tehnologii pentru sisteme informatice centralizate, caracterizate prin centralizarea resurselor sistemului informatic.

- Tehnologii pentru sisteme informatice distribuite, o formă superioară din punct de vedere tehnic şi funcţional de teleprelucrare a datelor. Aşa sunt, de exemplu, tehnologiile utilizate în reţele interconectate de calculatoare electronice.

Alegerea tipului de tehnologie de prelucrare se va face după o analiză a tuturor cerinţelor legate de prelucrarea datelor, formulate de beneficiar, a posibilităţilor de organizare şi structurare a acestora, dar şi a posibilităţilor financiare ale beneficiarului de a achiziţiona cele mai adecvate şi moderne sisteme şi echipamente de comunicaţii necesare.

- Practic, proiectantul va trebui să stabilească mai întâi dacă va gândi sistemul pentru prelucrare locală sau teleprelucrare. Aceasta ţine de dotarea existentă la momentul respectiv sau de posibilităţile viitoare privind dotarea cu unul sau mai multe calculatoare proprii.

- Apoi, proiectantul va decide dacă sistemul va realiza o prelucrare pe loturi sau în regim conversaţional. Aceasta depinde de mai mulţi factori, precum : caracterul operativ sau periodic al informaţiilor furnizate de sistem; modul de obţinere al rapoartelor la termene prestabilite sau la cerere, pe hârtie sau pe display; modul de culegere a datelor de către personal specializat sau direct de către utilizatori.

În ultimul timp s-a optat tot mai mult pentru soluţia prelucrării interactive. - Prelucrarea centralizată, descentralizată sau distribuită este cea de-a treia opţiune a proiectantului în cadrul proiectului de ansamblu. În ultima perioadă apariţia microcalculatoarelor şi scăderea rapidă a costurilor acestora favorizează realizarea unor sisteme distribuite. Se ştie că în sistemele centralizate principalele funcţiuni ale sistemului informatic - de prelucrare şi de stocare - sunt realizate pe un calculator sau mai multe, amplasate într-un singur punct. Spre deosebire de acestea, în sistemele distribuite aceste funcţiuni sunt executate descentralizat, de

171

regulă pe microcalculatoare amplasate în diferite puncte ale societăţii economice, cât mai aproape de locurile de generare a datelor şi de factorii de decizie. Între punctele de prelucrare şi stocare există legături de comunicaţie prin care se transferă datele, funcţie de necesităţile de prelucrare la nivelul întregului sistem. Se creează astfel un sistem ierarhizat pe două sau mai multe nivele, în funcţie de complexitatea şi caracteristicile proceselor tehnico-productive şi de numărul de puncte de prelucrare.

Alegerea tipului de sistem se poate face prin evaluarea modului în care sistemul răspunde la o serie de criterii cum ar fi timpul de răspuns, siguranţa în asigurarea funcţiunilor de prelucrare - stocare, adaptabilitate, flexibilitate, costuri de realizare şi exploatare, costuri de întreţinere şi dezvoltare.

Odată stabilite toate aceste caracteristici ale tehnologiei de prelucrare adoptate, se poate face o estimare a resurselor necesare pentru realizarea sistemului informatic. Se au în vedere, în acest sens :

- resursele financiare necesare pentru achiziţionarea echipamentelor, a softului de bază necesar şi a proiectării şi realizării efective a sistemului ;

- resursele umane, deci personalul de specialitate ;

Estimarea necesarului de personal de specialitatePersonalul de specialitate necesar realizării şi apoi exploatării curente a

sistemului informatic se determină funcţie de volumul de muncă cerut de complexitatea proiectului, de volumul de muncă cerut de întreţinerea şi exploatarea sistemului informatic. Astfel, pentru proiectarea şi realizarea sistemului echipa va fi formată din analişti, programatori, ingineri de sistem, administratori de baze de date, administratori de reţea, eventual designer Web, iar pentru exploatare şi întreţinere operatori pentru diversele echipamente, ingineri de sistem, administratori de baze de date sau administratori de reţea, după caz şi personalul de întreţinere. Numărul concret va depinde şi de modul în care se asigură, cu forţe proprii, proiectarea şi exploatarea sistemului informatic.

Estimarea necesarului de produse program Produsele – program necesare sistemului informatic se referă la: - soft de bază pentru calculatorul electronic, adică sistem de operare,

programe utilitare necesare; - elemente tipizate cum ar fi proiecte de subsisteme cu pachetele de

programe asociate, diferite pachete de programe aplicative, programe generalizabile etc care pot fi preluate;

- programe de la alte firme de soft aplicate deja, cu performanţe bune în domeniul nostru de interes;

- efort propriu pentru proiectare şi / sau realizare. Recurgerea la utilizarea unor elemente tipizate necesită însă o analiză

aprofundată, în scopul alegerii unei soluţii dintre cele existente, în raport cu :

172

efortul necesar adaptării, transformării elementelor tipizate şi a programelor preluate, conform specificului sistemului obiect; eficienţa utilizării lor estimată prin economie la activitatea de proiectare; posibilitatea integrării cu alte elemente tipizate utilizate în sistem sau cu elemente proprii, elaborate în etapa de proiectare. Ca urmare a acestei analize, o parte din elementele schemei funcţionale a sistemului informatic va fi acoperită cu elemente tipizate şi programe generalizate, iar o altă parte, cu programe ce urmează a fi realizate prin eforturi proprii.

Estimarea necesarului de resurse financiare presupune comensurarea tuturor cheltuielilor necesare pentru dotarea hardware şi software corespunzătoare, pentru proiectarea, realizarea şi exploatarea sistemului informatic. Cheltuielile pentru achiziţionarea echipamentelor necesare este strict legată de dotarea existentă, dar şi de soluţia aleasă pentru tehnologia de prelucrare, transmitere şi stocare a datelor. Pe baza cuantificării efectelor economice directe şi indirecte ale funcţionării noului sistem şi a cheltuielilor totale determinate de acesta, se estimează eficienţa economică a sistemului informatic, care va fi inclusă în proiectul de ansamblu al sistemului informatic respectiv.

7.9. Planificarea realizării sistemului informatic

Planificarea realizării unui sistem informatic are la bază principiul eşalonării.

Prin eşalonare înţelegem ordinea în care vor fi abordate şi realizate componentele sistemului informatic, începând cu proiectarea de detaliu, programarea, implementarea, până la introducerea în exploatare curentă, cu asigurarea condiţiilor pentru integrarea lor treptată. Atunci când se stabileşte ordinea de prioritate în abordarea componentelor sistemului informatic pot fi luate în considerare o serie de criterii, cum sunt:

- Prioritatea obiectivelor componente - Asigurarea legăturilor dintre componente - Disponibilitatea resurselor

Prioritatea obiectivelor componente poate fi stabilită ca cerinţă expresă a beneficiarului, care şi-a stabilit o ordine de abordare a componentelor sistemului sau poate să fie stabilită de echipa de proiectare. În acest din urmă caz acest criteriu acordă, de regulă, cea mai mare prioritate componentelor subsistemului pentru conducerea producţiei, apoi celor care abordează subsistemele referitoare la resursele necesare producţiei.

Această ordine este determinată de faptul că producţia se consideră activitatea de bază, iar celelalte activităţi care asigură direct sau indirect desfăşurarea producţiei, cu resursele necesare, apar ca procese dependente sau secundare,

173

determinate integral de procesul de producţie. Se consideră astfel că aplicaţiile informatice pentru conducerea producţiei conduc la însemnate efecte economice, cum ar fi creşterea profitului, creşterea gradului de utilizare a capacităţilor de producţie, creşterea productivităţii muncii etc. În acelaşi timp însă, ele ridică şi cele mai dificile probleme de proiectare a soluţiilor de realizare a culegerii, transmiterii şi prelucrării datelor.

Asigurarea legăturilor între componente este o problemă deosebit de importantă, căci la nivel global ele se definesc chiar din etapa proiectării de ansamblu. Legăturile dintre subsisteme înseamnă practic un sistem unitar de codificare a datelor, transferuri de date între acestea, mijloace tehnice şi tehnologii de transfer adecvate. În cadrul unui sistem informatic va exista astfel o colecţie de date comună subsistemelor, dar şi colecţii de date specifice lor. În această etapă se stabilesc şi se descriu practic la nivel global legăturile informaţionale şi forma acestora între diversele subsisteme sau module componente.

Disponibilitatea resurselor reprezintă un criteriu care va influenţa în mod direct ordinea de abordare şi realizare a componentelor sistemului informatic depinzând de: limita fondurilor ce pot fi alocate în timp pentru realizarea sistemului informtic; nivelul de dotare cu tehnică de calcul existent în etapa de concepere şi cel prevăzut a fi realizat ; forţele de proiectare pe care le va antrena proiectul; personalul de specialitate existent şi în curs de pregătire la beneficiar necesar pentru implementarea şi exploatarea sistemului informatic.

Planificarea realizării sistemului informatic înseamnă de fapt precizarea eşalonării, în timp, a proiectării şi realizării fiecărei componente, pe faze de execuţie, cu resursele necesare (financiare, umane, materiale) şi termene precise de realizare.

În funcţie de toate criteriile prezentate mai sus, planificarea se va realiza utilizând ca instrumente de lucru : graficul de detaliu în formă tabelară, sub formă de grafic GANTT sau sub formă de grafic de tip reţea PERT. Acestea din urmă sunt mai explicite, căci pot prezenta şi condiţionările între activităţile de realizare a componentelor şi activităţi nelegate de proiectare cum sunt pregătirea cadrelor, raţionalizarea sistemului de evidenţă, etc.

174

8. PROIECTAREA DE DETALIU A SISTEMELOR INFORMATICE

Am văzut că proiectarea de ansamblu este o etapă a proiectării sistemelor informatice complexe, care necesită o descompunere pe mai multe nivele de elemente componente: subsisteme, aplicaţii sau module informatice. Ea presupune identificarea, definirea şi descrierea la nivel global a tuturor elementelor de importanţă în proiectarea unui sistem informatic, cum sunt: funcţiunile şi structura funcţională a subsistemelor sau aplicaţiilor componente, ieşirile, intrările, sistemul de codificare, colecţiile de date comune şi specifice fiecărui subsistem, alegerea modalităţii de organizare şi structurare a datelor, interfaţa cu utilizatorul, estimarea eficienţei economice a noului sistem. Proiectarea de ansamblu precede şi pregăteşte astfel proiectarea de detaliu.

Aceasta înseamnă că, prin proiectarea de detaliu se realizează practic detalierea, pentru fiecare subsistem în parte sau aplicaţie informatică definită, a tuturor elementelor implicate, pe baza cerinţelor formulate pentru noul sistem şi a activităţii de studiu şi analiză a sistemului existent, concretizate în modelul datelor şi modelul prelucrărilor. Se realizează astfel modelul de detaliu al fiecărui subsistem sau componentă a sistemului şi se stabilesc soluţiile tehnice de realizare ale fiecăruia.

La nivelul unei aplicaţii informatice este posibil ca etapa proiectării de ansamblu să lipsească şi atunci se impune ca definirea şi proiectarea tuturor elementelor componente să se facă direct în cadrul acestei etape, rezultând direct modelul de detaliu al domeniului abordat.

Proiectarea de detaliu cuprinde două activităţi distincte realizate pentru fiecare aplicaţie sau modul din cadrul sistemului, denumite sugestiv:

- proiectare logică de detaliu- proiectare tehnică de detaliu.Cele două activităţi se finalizează cu o documentaţie corespunzătoare,

denumită: Proiect logic de detaliu şi Proiect tehnic de detaliu.

Proiectul logic de detaliu cuprinde informaţii privind cerinţele de detaliu ale componentei funcţionale, soluţia de organizare şi structurare a datelor, descrierea intrărilor, ieşirilor, a interfeţei cu utilizatorul.

Proiectul tehnic de detaliu, adresat specialiştilor (programatori) prezintă, în plus, specificaţii tehnice de realizare a programelor sau procedurilor automate, permiţând astfel comunicarea în cadrul echipei de proiectare şi realizare a sistemului.

175

8.1. Detalierea funcţiunilor şi a structurii funcţionale a subsistemelor şi/sau a aplicaţiilor informatice

În cadrul acestei activităţi se detaliază funcţiunile fiecărei aplicaţii până la nivelul funcţiilor elementare, definind, acolo unde este posibil, chiar procedurile care urmează să fie realizate. Se realizează deasemenea schema funcţională a fiecărui subsistem sau aplicaţie informatică. Se întocmeşte apoi lista procedurilor automate şi manuale pe care le implică realizarea aplicaţiei informatice, pornind de la funcţiile elementare ale acesteia şi se descriu aceste proceduri. Pot fi puse în evidenţă diverse variante funcţionale ale fiecărui subsistem sau aplicaţie informatică, beneficiarul putând opta pentru una din ele.

Apoi, luând în considerare condiţiile, evenimentele externe şi interne care declanşează procedurile, frecvenţa acestora, duratele şi termenele de realizare, se poate realiza eşalonarea în timp a procedurilor şi graficul de exploatare preliminară a aplicaţiei, punând în evidenţă şi legăturile funcţionale cu celelalte subsisteme sau sisteme informatice.

Tot în cadrul acestei activităţi se definitivează modelele matematico-economice utilizate şi algoritmii de calcul ce stau la baza prelucrării automate în cadrul aplicaţiei sau modulului informatic. Pentru fiecare procedură în parte se descriu apoi toate aceste elemente : funcţii elementare, modele utilizate, algoritmi de calcul, legături cu alte proceduri, cu alte aplicaţii, alte subsisteme sau chiar alte sisteme din exterior (cum ar fi raportări la circa financiară, la ministerul tutelar etc).

8.2. Proiectarea de detaliu a ieşirilor

Ieşirile sistemului informatic au fost definite la nivel global în cadrul proiectului de ansamblu, care precede şi pregăteşte proiectarea de detaliu. La nivelul unei aplicaţii informatice însă este posibil ca etapa proiectării de ansamblu să lipsească şi atunci se impune ca definirea şi proiectarea acestora să se facă în cadrul acestei etape.

Se ştie că ieşirile sistemului informatic conţin rezultatul prelucrărilor efectuate asupra datelor de intrare şi se pot prezenta sub forma unor rapoarte, a unor situaţii de raportare afişate pe ecran, scrise pe hârtie sau înregistrate pe un suport extern (disc hard sau flexibil, Cd, casetă magnetică,etc).

În funcţie de natura prelucrărilor care generează ieşirile se pot întâlni următoarele tipuri de ieşiri informaţionale:

- ieşiri obţinute în urma unor operaţii de transfer a datelor (de exemplu numărul şi data unei facturi, denumirea unui produs, numele unui salariat etc.);

- ieşiri obţinute în urma unor operaţii de calcul pe baza unor algoritmi de calcul (de exemplu valoarea totală a facturii, valoarea vânzărilor pe un trimestru, salariul net al unui angajat, etc.).

176

Ieşirile sistemului informatic, denumite uzual rapoarte, pot fi reprezentate sub forma unor indicatori sintetici care stau la baza unor tablouri de bord ce pot fi consultate de managerii firmei sau sub forma unor rapoarte care regrupează mai mulţi indicatori sintetici sau analitici sub formă tabelară.

Rapoartele se pot clasifica după mai multe criterii, cum ar fi:a) Gradul de agregare :- Rapoarte sintetice – care conţin indicatori sintetici şi sunt destinate

activităţii de fundamentare a deciziilor;- Rapoarte analitice – care conţin date privind desfăşurarea unei activităţi pe

un anumit segment de timp. De exemplu: situaţia consumurilor de materiale pe lună, situaţia cazărilor zilnice dintr-un hotel, situaţia camerelor din hotel, etc.

b) Natura informaţiilor conţinute :- Rapoarte conţinând datele de stare ale sistemului condus (exemplu bilanţul

contabil);- Rapoartele statistice cuprinzând informaţii cu caracter statistic necesare

raportărilor ierarhice;- Rapoarte previzionale care permit anticiparea evoluţiei unor procese şi

fenomene economice.c) Destinaţia rapoartelor :- Rapoarte de uz intern destinat cerinţelor proprii de informare şi control;- Rapoarte de uz general – cu un conţinut prestabilit (ex. Bilanţul contabil )d) Frecvenţa de generare: Rapoarte periodice, întocmite la intervale regulate de timp, cum sunt:

- Rapoarte zilnice;- Rapoarte lunare;-- Rapoarte trimestriale-- Rapoarte anuale

De exemplu, rapoartele săptămânale privind realizarea producţiei sau rapoartele lunare privind vânzările din cadrul unei societăţi. Rapoartele de vânzare ale managerilor de vânzări pe unităţi pot fi combinate într-un raport lunar pentru managerii zonali de vânzări.

Rapoartele de excepţie, care atrag atenţia prin intermediul unor indicatori asupra acţiunilor sau evenimentelor neobişnuite. Un exemplu îl reprezintă un raport de vânzare care arată că anumite articole sunt vândute semnificativ peste sau sub previzionările departamentului de marketing. De exemplu, dacă sunt vândute mai puţine bucăţi dintr-un articol decât s-a previzionat pentru o zonă, managerul local va primi un raport de excepţie. Pentru o gestiune de stocuri un raport al produselor cu stocul zero sau sub limita minimă admisă arată managerului că trebuie să se aprovizioneze urgent cu respectivul produs, altfel desfăşurarea procesului de producţie nu poate continua. Pentru o unitate hotelieră, un raport de excepţie va anunţa dacă s-au ocupat toate locurile de cazare prin rezervare automată sau dacă nu au fost solicitate deloc.

177

Rapoarte la cerere, care are reprezintă opusul unui raport periodic, este realizat conform cerinţelor decidentului. Un exemplu este un raport asupra numărului şi funcţiilor deţinute de femei în unitate. Astfel de raport nu este necesar periodic, dar ar putea fi necesar atunci când este solicitat de administraţia locală sau de guvern. Această informaţie este folosită pentru a demonstra că firma are indicatori favorabili şi poate solicita anumite facilităţi. Un raport la cerere pentru o unitate hotelieră ar putea fi, de exemplu, referitor la turiştii străini cazaţi, pe categorii de vârste şi sex.

Rapoartele pot fi listate la imprimantă, vizualizate pe monitor sau memorate pe un suport magnetic în vederea continuării prelucrărilor în cadrul altor subsisteme informatice. Adeseori rapoartele de ieşire sunt însoţite de reprezentări grafice, sub forme adecvate, pentru a se putea observa mai uşor evoluţia unui proces sau a unui fenomen economic. Acestea se recomandă îndeosebi managerilor de nivel înalt, care au nevoie de informaţii cu grad mare de sintetizare. Ele pot avea un format predefinit, cu formatarea dorită a textului sau un format definit de utilizator.

În această etapă de proiectare se definitivează practic proiectarea tuturor ieşirilor sistemului informatic sau aplicaţiei informatice, în două faze: proiectarea logică şi proiectarea fizică.

a). Proiectarea logică de detaliu a ieşirilor înseamnă de fapt detalierea cerinţelor informaţionale stabilite în etapa proiectării de ansamblu şi stabilirea, pentru fiecare situaţie în parte, a machetei corespunzătoare şi a specificaţiilor tehnice de realizare care o însoţesc. Astfel, macheta fiecărui raport reprezintă practic formatul de descriere al acestuia şi conţine un antet, date fixe, date de identificare ale raportului, un cap de tabel, precum şi rândurile de date curente şi eventual de totaluri, subtotaluri, indicatori calculaţi.

Machetele se înaintează beneficiarului, care, în urma analizei lor, poate formula modificări ale formatului acestora.

Machetele rapoartelor, împreună cu specificaţii tehnice de realizare se înaintează echipei de programare, pentru a scrie efectiv programele corespunzătoare. În cadrul acestora sunt precizate informaţii precum: numărul de exemplare, destinaţia, termene, criterii de validare a datelor, algoritmi de calcul.

b). Proiectarea fizică de detaliu a ieşirilor se realizează pe baza specificaţiilor de ieşire şi presupune definitivarea formei şi formatului de prezentare a rapoartelor, aşezarea în pagină, spaţierea rândurilor, stabilirea procedurilor de interpretare a ieşirilor. Tot acum se alege tipul de suport fizic de ieşire (imprimantă, monitor, disc magnetic fix sau flexibil, CD, bandă magnetică, etc) funcţie de situaţia concretă a beneficiarului în ceea ce priveşte dotarea cu calculatoare şi amplasarea acestora, modul de lucru (în reţea sau posturi

178

individuale), costul suportului ales şi măsura în care el răspunde cerinţelor concrete de informare.

Atunci când se definitivează forma de prezentare a rapoartelor o serie de factori pot influenţa în mod concret şi real alegerea făcută, cum sunt:

- formatul cerut de conducere, care poate fi unul existent, cu care s-a obişnuit să lucreze, sau unul nou, cu informaţii suplimentare pe care le poate obţine din baza de date;

- necesitatea utilizării unor formate (formulare) tipizate, utilizate de societate în relaţia cu alţi parteneri sau realizarea unor formulare asemănătoare, cu aceeaşi structurare a datelor;

- conţinutul informaţional al raportului, numărul de coloane pe pagină, numărul de linii afişate pe ecran, posibilităţi de imprimare (negru, color) sau de transmitere a rapoartelor sunt strâns legate de caracteristicile tehnice ale echipamentelor de care dispune firma beneficiară şi de aceea le pot influenţa în mod direct.

- considerente de eficienţă economică a rapoartelor obţinute pot influenţa proiectarea acestora, şi anume: economia de hârtie şi/sau de consumabile la imprimantă, reducerea timpului pentru obţinerea propriu-zisă a rapoartelor, posibilitatea de listare în alt moment sau la alt calculator a rapoartelor, pentru a nu întârzia execuţia lucrării, organizarea mai multor rapoarte pe o pagină, etc.

- necesitatea unei minime autodocumentări a oricărui raport printr-un titlu şi un cap de tabel explicit, prin precizarea unor reguli privind citirea raportului, interpretarea rezultatelor sau semnificaţia codurilor utilizate;

- asigurarea unei bune lizibilităţi a raportului, printr-o spaţiere şi o dispunere corespunzătoare a datelor în cadrul paginii, prin sublinierea sau afişarea colorată a rezultatelor importante sau a celor de excepţie;

- utilizarea, în mare măsură, a vizualizării unor rapoarte pe ecran, care, pe lângă alegerea unor formate adaptate la dimensiunile acestuia, pot apela şi la facilităţile oferite de monitoare sau ecranele video, cum sunt: afişare tip pagină sau prin defilarea imaginii pe ecran, modul de afişare normal, video-invers, luminos sau clipitor, scheme de culori prefabricate sau utilizarea unor culori adecvate situaţiilor obţinute şi celor care le primesc; aceste rapoarte pot fi proiectate să dialogheze cu beneficiarul, care va putea astfel să opteze pentru diferite forme ale rapoartelor sau să ceară în mod expres anumite rapoarte prin intermediul unor meniuri sau opţiuni afişate pe ecran la dipoziţia utilizatorului.

- utilizarea unor generatoare automate de rapoarte puse la dispoziţie de majoritatea limbajelor de programare şi a sistemelor de gestiune a bazei de date.Observaţie:

Se apreciază adeseori că numărul de rapoarte obţinute în cadrul unei aplicaţii informatice este în strânsă legătură cu utilitatea, cu eficienţa ei. Cu cât numărul rapoartelor de ieşire este mai mare, cu atât aplicţia este mai utilă, mai mulţi decidenţi au nevoie de ele pentru fundamentarea sau asistarea actului decizional.

179

Toate acestea, formatul şi conţinutul rapoartelor, reuşita dialogului cu utilizatorul, plăcerea sau dimpotrivă reticenţa acestuia de a utiliza aceste facilităţi oferite de aplicaţia proiectată depind, în mare măsură, de documentarea, dar şi de inventivitatea, creativitatea şi experienţa în domeniu a echipei de proiectare.

8.3. Proiectarea de detaliu a intrărilor

Intrările unui sistem informatic reprezintă ansamblul datelor stocate, gestionate şi prelucrate în cadrul sistemului, date care provin din dinamica operaţiilor şi proceselor economice şi financiare derulate în cadrul firmei. Aceste fluxuri informaţionale de date care însoţesc toate aceste operaţii şi procese (de exemplu fluxul de date referitoare la aprovizionarea cu materii prime, fluxul de date reflectând operaţiile de încasări şi plăţi, fluxul de date ce însoţeşte procesele tehnologice de montaj etc.) se numesc tranzacţii. În cadrul unei firme se pot identifica diverse fluxuri de tranzacţii, cum sunt:

- tranzacţiile care însoţesc operaţiile şi procesele curente din cadrul firmei (Notele de Intrare Recepţie –NIR-, bonurile de consum, facturile emise clienţilor, ştatele de plată, etc.) ;

- tranzacţiile care provin din mediul financiar-bancar (facturi primite de la furnizori, ordine de plată onorate de clienţi, cotele de impozit etc);

- tranzacţiile provenite de la alte sisteme informatice din cadrul aceleeaşi firme;

- tranzacţiile care provin de la alte sisteme informatice exterioare firmei.Din punct de vedere fizic intrările în sistem trebuie să fie realizate utilizând

mijloacele moderne oferite de noile tehnologii informatice, cum sunt:- proceduri specializate de preluare a datelor tastate de operator pe baza unor

machete videoformat de culegere şi de validare a acestora;- scanarea documentelor cu ajutorul unui dispozitiv ce funcţionează pe

principii optice şi care permite preluarea unui volum mare de date aflate pe formulare standardizate într-un timp foarte scurt;

- transfer de date din reţeaua locală a firmei (ex. Reţea Novell sau reţea Extranet);

- transfer de date la distanţă (prin Internet sau prin reţele private).Prelucrările sistemului informatic reprezintă un ansamblu omogen de operaţii

automate prin care se vor realiza următoarele operaţii:- crearea şi actualizarea bazei de date (sau a fişierelor);- prelucrări, interogări şi listări efectuate asupra datelor conţinute în baza

de date (fişiere);- reorganizarea (întreţinerea) bazei de date (fişiere);- salvarea/restaurarea bazei de date (fişierelor).

Proiectarea de detaliu a intrărilor cuprinde, ca şi la ieşiri, cele două etape: proiectarea logică de detaliu şi proiectarea fizică de detaliu.

180

În etapa de proiectare logică de detaliu se stabileşte lista completă a intrărilor, pentru fiecare document de intrare descriindu-se elementele caracteristice cum sunt conţinutul informaţional, natura şi structura datelor, frecvenţa de apariţie, volumul, criteriile de control şi validare a datelor, etc.

Datele de intrare parcurg o succesiune de etape în cadrul sistemului informatic - din momentul generării şi culegerii lor până la momentul utilizării şi prelucrării lor efective. De aceea, în cadrul sistemului sau aplicaţiei proiectate se impune cu stringenţă ca preluarea pe suport magnetic în vederea prelucrării lor automate să aibă în vedere datele primare, deci cele înscrise pe documente primare, adică acelea care consemnează fenomenul economic la locul şi în momentul producerii lor, nu cele rezultate în urma unor procese de prelucrare. Prin urmare, datele de intrare trebuie să fie date culese de pe documentele primare care atestă diferitele procese economice. Acest lucru se impune în primul rând pentru a asigura principiul nonredundanţei datelor în sistem, precum şi pentru a asigura corectitudinea lor şi responsabilitatea celor care le gestionează în cadrul sistemului.

De aceea, în prelucrarea lor automată, datele de intrare vor parcurge mai multe etape intermediare, cum sunt: culegerea datelor de pe documentul de intrare pe baza unei machete, a unui videoformat proiectat de informatician, conversia acestora în formatul proiectat pentru transpunerea lor pe suportul tehnic, verificarea sintactică şi logică a datelor de intrare, corecţia datelor eronate şi reluarea procedeului până la eliminarea erorilor sau anomaliilor constatate în cadrul lor.

În proiectarea fizică de detaliu numită şi proiectare tehnică de detaliu se realizează toată această activitate de proiectare a documentelor de intrare şi a machetelor (ecranelor, videoformatelor sau formularelor) datelor de intrare, se stabilesc condiţiile de validare a datelor şi instrucţiuni de corectare a acestora, se alege suportul tehnic pentru memorarea datelor, se definesc procedurile (manuale sau automate) de culegere şi transmitere a datelor şi se reproiectează, dacă este cazul, chiar documentele primare de înregistrare a datelor – pentru a răspunde cerinţelor prelucrării automate.

Pentru fiecare document primar de intrare la nivel fizic se va recurge la elaborarea machetei documentului primar şi la elaborarea instrucţiunilor de completare şi utilizare a acestuia. Macheta documentului va reprezenta imaginea concretă a documentului ce urmează a fi proiectat. Cu privire la elaborarea machetei documentului primar se pot face următoarele sugestii:

se va ţine seama de standardele sau normele interne şi internaţionale cu privire la proiectarea documentelor primare, atât în ceea ce priveşte forma, cât şi conţinutul.

Astfel, se pot întâlni următoarele situaţii:

181

FORMĂ CONŢINUTimpusă impusliber aleasă impusliber aleasă liber ales indicatorii ce urmează a fi preluaţi în documentele primare pot fi precizaţi

prin includerea lor într-un chenar cu dimensionarea numărului de caractere şi spaţiului rezervat. Dimensionarea spaţiului rezervat completării unui indicator va depinde de o serie de factori cum sunt:

- mijlocul de completare (manual, maşină de scris, imprimantă);- condiţiile ergonomice în care urmează să fie completat documentul

primar- nivelul de pregătire al utilizatorilor de documente primare.

la nivelul machetei documentului indicatorii pot fi grupaţi în chenare. se va recurge, dacă este posibil, la utilizarea formularelor pretipărite. se va ţine seama de facilităţile oferite de echipamentele de calcul şi de

pachetele software existente.Machetele documentelor de intrare a datelor sunt însoţite de o documentaţie

denumită specificaţii de intrare, necesare atât programatorilor pentru scrierea programelor corespunzătoare, cât şi utilizatorului. Aceste specificaţii trebuie să conţină :

- macheta documentului de intrare, pe baza căruia se va proiecta videoformatul de intrare sau formularul de introducere a datelor;

- instrucţiunile de culegere a datelor, de transmitere – dacă este cazul, de utilizare şi transpunere pe suport tehnic;

- regulile de validare a datelor, posibilităţi de corectare a lor, restricţii de completare, chei de control.

- reguli de salvare, de conversie sau de restaurare în caz de incident.Proiectarea fizică (sau tehnică) de detaliu precizează deci în detaliu toate

condiţiile de preluare, validare, transmitere a datelor în vederea unor prelucrări curente sau ulterioare, de corectitudinea, completitudinea şi operativitatea lor depinzând, în cea mai mare parte, succesul aplicaţiei sau sistemului informatic.

Dată fiind această importanţă a activităţii, se impun unele precizări cu privire la momentele cheie ale sale. Astfel:

a). Alegerea suportului tehnic pentru datele de intrare ia în considerare, în ultima perioadă, din ce în ce mai mult, posibilitatea de introducere a datelor direct de la terminal, cu posibilităţile de lucru în regim conversaţional pe care acesta le oferă. Celelalte modalităţi de introducere a datelor utilizând alte suporturi tehnice cum sunt cartelele magnetice, benzile magnetice, cititoarele optice etc se folosesc mai rar.

Odată introduse de la terminal, datele intră în circuitul de prelucrare şi actualizare al unei baze de date sau fişier clasic, sunt transmise electronic (reţea,

182

e-mail, fax, internet, etc) la un punct central sau local de prelucrare sau sunt stocate pe un suport magnetic în vederea prelucrării ulterioare.

b). Proiectarea machetelor documentelor de intrare este, indiferent de metodele de prelucrare a datelor folosite ulterior sau de sistemul de gestiune a bazei de date ales, o activitate deosebit de importantă prin efectul bun sau mai puţin bun pe care îl poate avea asupra întregii aplicaţii.

În primul rând se impune precizarea că nu este permisă dublarea documentelor primare, prin proiectarea unor documente destinate exclusiv preluării datelor în cadrul aplicaţiei de prelucrare automată realizată.

De regulă, pentru fiecare document primar existent sau reproiectat şi acceptat de beneficiar se proiectează o machetă corespunzătoare, care va conţine, cum este şi firesc, următoarele elemente de structură:

- un antet care conţine datele de identificare ale firmei şi/sau a compartimentului care-l emite (denumire, cod fiscal, adresa, după caz), plasat, de regulă, în colţul din stânga sus;

- denumirea documentului, codul acestuia şi elemente de identificare (număr, dată) plasate de regulă sus, în partea dreaptă (sau în centru);

- rânduri şi coloane pentru înscrierea informaţiilor cantitativ - valorice şi a codurilor aferente, dimensionate şi spaţiate astfel încât datele să poată fi introduse într-un mod agreabil, plăcut;

- rubrici şi rânduri speciale pentru semnături şi ştampile, plasate de regulă în partea finală a documentului;

- text explicativ - eventual indicaţii de completare şi verificare a datelor, care trebuie să fie foarte precis şi succint formulate.

Formatul documentului, aspectul şi regulile de completare a datelor depind în mod direct de locul şi modalitatea de completare a documentului (manual, dactilografiat sau automat) şi de nivelul de calificare a personalului care completează acel document.

Proiectarea unui document (formular) de introducere a datelor trebuie să aibă în vedere faptul că un operator, nespecialist în informatică şi cu un grad de pregătire necunoscut, va urmări datele înscrise în document şi le va tasta în vederea introducerii lor pentru prelucrare automată. De aceea, este important ca aspectul formularului afişat pe ecran pentru a permite introducerea datelor de la tastatură să fie asemănător cu cel al documentului de pe care se face citirea datelor, să respecte întocmai ordinea datelor din document şi nu cea de prelucrare din programe, să aibă (eventual) ordinea de culegere a datelor precizată prin numerotarea casetelor, să permită un dialog de forma întrebare-răspuns sau opţiuni ale unui mic meniu sau chiar butoane afişate pe ecran pentru a facilita procesul de introducere şi validare a datelor.

Ordinea firească de parcurgere a unui document este de sus în jos şi de la stânga la dreapta, iar prelucrarea automată a datelor trebuie să o respecte în momentul introducerii datelor.

183

O atenţie deosebită trebuie acordată în proiectarea acestor formulare regulilor de validare a datelor, care se pot referi atât la o validare manuală, ce ţine de verificarea corectitudinii datelor înscrise pe documentul primar, cât mai ales la reguli de validare automată, prin programe, a acestora. Pentru aceasta se vor verifica: încadrarea între limitele admise a unor valori sau indicatori, prezenţa obligatorie a unor date, apartenenţa codurilor la nomenclatoarele aplicaţiei, eventuale corelaţii (logice) ce pot exista între datele introduse, apartenenţa valorilor la un anumit tip, etc menite să asigure consistenţa şi corectitudinea datelor ce urmează a fi prelucrate apoi automat. Dacă este cazul, pentru unele câmpuri de date se pot prelua valori implicite, atunci când acestea nu sunt completate. Aceste valori se preiau din nomenclatoarele de coduri, fişierele bazei de date sau din tabele special memorate pentru valorile asumate prin lipsă sau se determină prin aplicarea unui algoritm de calcul asupra unor valori existente.

O validare specială şi cu rezultate deosebite a codurilor se realizează prin verificarea automată a cifrei de control a acestora, dacă au fost definite astfel de coduri. Se identifică şi se evită astfel erori de codificare a datelor care ar putea avea urmări neplăcute în prelucrarea automată a datelor.

Documentele de intrare, machetele de introducere a datelor trebuie să fie însoţite de instrucţiuni de emitere şi completare bine precizate.

Formatul machetei şi modul de introducere a datelor depind în mare măsură de forma dialogului om-calculator, care se poate desfăşura fie:

a). sub forma întrebare – răspuns, cu defilarea liniilor ecranului.Aceasta presupune un dialog continuu, operatorul introducând succesiv datele

de intrare ca răspuns logic la întrebările afişate anterior pe ecran. Mai mult, operatorul nu poate trece la următoarea întrebare, dacă dintr-o eroare

s-au introdus date incorecte sau a fost sărit un anumit răspuns. În aceste cazuri programul de validare, aflat la baza dialogului om-calculator, va solicita reintroducerea datei eronate sau o opţiune corespunzătoare pentru răspunsul lipsă. Mesajele de eroare pot fi afişate fie imediat sub informaţia greşită, fie într-o zonă prestabilită a ecranului (de exemplu, dreapta-sus) însoţite, la redarea pe display, de o avertizare sonoră sau luminoasă (blinking, video-invers).

La proiectarea videoformatelor de intrare este necesar ca proiectantul să aibă în vedere şi o serie de aspecte practice utile, menite să nu obosească operatorul, să-i uşureze activitatea de culegere a datelor, cum sunt:

- afişarea pe ecran, la un moment dat, a unui volum redus de informaţii;- afişarea, la un moment dat, a unei cereri de răspuns ce se referă la o singură

informaţie; - scurtarea răspunsului dat de operator, prin folosirea abrevierilor şi a

codificărilor numerice;- utilizarea unor formate clare şi precise pentru afişare;- evitarea cuvintelor şi a caracterelor dificile de citit sau înţeles; - existenţa unor rutine speciale de autodocumentare (help);

184

- dialogul trebuie să fie astfel proiectat încât să permită corectarea imediată a erorilor intervenite în executarea programului.

b). prin afişarea pe ecran a machetei de introducere a datelor de intrare În acest caz macheta de introducere trebuie să reproducă în totalitate sau

simplificat documentul de intrare, să respectele toate cerinţele de proiectare formulate, să folosească toate facilităţile oferite de o afişare video, cum sunt: combinaţie plăcută, caldă de culori, sunet, defilarea imaginii, efecte speciale de imagine, precum şi avertizări sonore sau de culoare pentru cazurile speciale.

În proiectarea videoformatelor de intrare, pot fi utilizate componente specializate ale sistemelor de gestiune a bazelor de date (SGBD), cum ar fi de exemplu: FoxBase, FoxPro, Oracle, Paradox precum şi programe specializate scrise în diverse limbaje de programare.

8.4. Proiectarea sistemului de codificare8.4.1. Definiţii, caracteristici

Necesitatea codificării informaţiei derivă din considerente de ordin practic privind procesul de culegere, verificare, transmitere, prelucrare şi stocare a informaţiei.

În cazul procesului de prelucrare automată a datelor, codificarea informaţiei conduce la reducerea dimensiunii fişierelor de date, a timpului în fazele de culegere, verificare, transmitere şi prelucrare a datelor, crează condiţii optime pentru valorificarea, gruparea şi sintetizarea cât mai complexă a datelor, utilizând facilităţile de prelucrare automată.

Operaţia de codificare constă în stabilirea unei corespondenţe biunivoce între obiectele supuse codificării (bunurile materiale) şi simbolurile (codurile) de reprezentare a acestora, obţinute cu ajutorul unui limbaj de codificare.

Rezultatul codificării se concretizează într-un sistem de coduri.

Adeseori reuşita unei aplicaţii informatice, a unui sistem informatic în ansamblul său, depinde de sistemul de codificare ales, de structura codului şi de posibilităţile de grupare a informaţiilor pe care acesta le oferă.

Caracteristicile codurilor lungimea codului. Este dată de numărul de caractere prin care se descrie

codul respectiv. structura şi formatul codului. Se referă la semnificaţia fiecărui caracter din

structura codului. Formatul poate fi variabil sau fix. capacitatea codului (Cc). Reflectă numărul maxim de combinări posibile

pentru codificarea elementelor mulţimii de interes ţinând seama de un format şi o structură prestabilită. Cc se exprimă astfel:

Cc = 10N 26A, unde:

185

10 - numărul de cifre (0-9)26 - numărul de caractere (litere) ale alfabetului excluzând ş, ţ, î, â,ăN - numărul de caractere numerice din structura coduluiA - numărul de caractere alfabetice din structura codului.

Cerinţele (principiile) codificării datelorCu ocazia elaborării nomenclatoarelor de coduri trebuie să se ţină seama de o

serie de cerinţe care prin importanţa pe care o prezintă, sunt ridicate la rangul de principii:

unicitatea codurilor - codurile elaborate trebuie să ofere posibilitatea identificării unice a oricărui element din mulţime. Unicitatea codului în cadrul unei mulţimi codificate înseamnă că fiecărui element din mulţimea codificată îi va fi asociat un cod care nu a mai fost asociat altui element din aceeaşi mulţime;

conciziunea codurilor (minimalitatea) - codurile elaborate trebuie să fie formate dintr-un număr cât mai redus de caractere, adică minimul necesar şi suficient pentru a putea reprezenta prin coduri toate elementele mulţimii.

stabilitatea codurilor - codurile elaborate trebuie să se menţină aceleaşi pe o durată de timp cât mai îndelungată.

semnificaţia codurilor - codurile elaborate trebuie să fie cât mai semnificative (sugestive). În acest sens se impune folosirea unui limbaj de codificare accesibil, astfel încât codificarea şi decodificarea informaţiei să se realizeze cu uşurinţă. Dacă nu este îndeplinită această cerinţă, avem de a face cu un sistem de codificare greoi, care poate constitui o sursă de erori permanentă în introducerea datelor.

operaţionalitatea codurilor - codurile elaborate trebuie să ofere facilităţi cu privire la prelucrarea automată a datelor, manipularea datelor (codificare, decodificare), sortare, interclasare etc. Structura codului trebuie să permită deci, în procesul de prelucrare, sortarea şi formarea de grupe cu obiectele codificate, în conformitate cu cerinţele utilizatorilor. Experienţa proiectantului şi colaborarea lui cu utilizatorul pot asigura succesul în acest sens.

flexibilitatea codurilor - nomenclatoarele de coduri trebuie astfel elaborate încât să ofere posibilitatea adăugării sau excluderii de coduri fără a afecta structura codurilor. Întreţinerea facilă a sistemului de coduri elaborat reprezintă o activitate menită să asigure stabilitatea în timp şi posibilitatea de extindere a sferei de cuprindere a acestuia. Stabilitatea derivă din necesitatea utilizării informaţiilor codificate un timp mai îndelungat; de aceea, se impune ca un cod, o dată stabilit, să aibă în vedere tendinţa de creştere a volumului de informaţii, atât pe ansamblul colectivităţii, cât şi a subcolectivităţilor acesteia, în scopul cuprinderii, pe un timp cât mai îndelungat, a tuturor informaţiilor ce prezintă interes.

8.4.2. Clasificarea codurilor

186

Codurile pot fi clasificate în funcţie de mai multe criterii, cum sunt:a). domeniul de referinţă- coduri interne- coduri externeCodurile interne se referă la modul de codificare a datelor în memoria internă

sau pe purtătorii tehnici de informaţie.Codurile externe sunt folosite de către utilizatori în diferite aplicaţii

informatice.b) natura caracterelor ce intră în componenţa codului:- coduri numerice - formate din secvenţe de numere naturale;- coduri alfabetice - formate din caractere alfabetice;- coduri alfanumerice - formate din caractere alfabetice şi numerice.c) lungimea codurilor:- coduri cu lungime fixă – care conţin acelaşi număr de caractere pentru toate

obiectele supuse codificării;- coduri cu lungime variabilă – care nu conţin acelaşi număr de caractere

pentru toate obiectele supuse codificării.În practică se preferă să se lucreze cu coduri de lungime fixă. De aceea

codurile de lungime variabilă vor fi convertite în coduri de lungime fixă prin adăugarea de zerouri în faţa cifrei semnificative.

Exemplu:coduri de lungime variabilă coduri de lungime fixă

1 2 3

9 10 11

99 100 101

9991000

000100020003

000900100011

009901000101

09991000

d) posibilităţile de prelucrare existente:- coduri elementare, care pot fi:

- secvenţiale;- secvenţiale cu formare de grupe;- mnemonice;- descriptive.

- coduri compuse, care pot fi:

187

- ierarhizate;- juxtapuse;- matriceale;

- binare.

Codurile secvenţiale se formează prin atribuirea unor numere în ordine crescătoare elementelor de codificat. Se obţine astfel o corespondenţă între mulţimea elementelor de codificat şi mulţimea numerelor naturale. Aceste coduri pot avea lungime fixă sau lungime variabilă. Codurile secvenţiale au dezavantajul că nu permit gruparea elementelor colectivităţii pe subcolectivităţi şi prelucrarea corespunzătoare a acestora. Un exemplu elocvent în acest sens îl constituie generatoarele de secvenţă sau atribuirea de coduri numerice strict crescătoare elementelor supuse codificării (tabel 1).

Tabel 1Nr. Crt. Denumirea elementelor Cod atribuit1 ........ 00012 ........ 00023 ........ 0003

Codurile secvenţiale cu formare de grupe se bazează pe împărţirea elementelor mulţimii de codificat în grupe, clase sau familii care, la rândul lor vor fi împărţite în subgrupe, subsubgrupe. La nivelul grupelor, respectiv subgrupelor elementele vor fi codificate în ordine secvenţială. În acest mod la nivelul fiecărei grupe, subgrupe etc. vor rămâne coduri de rezervă.

Exemplu: Codificarea conturilor din planul de conturi.

Avantajele acestui tip de coduri:

Grupa de material

Coduri atribuite grupei

Sub-grupa

Codul subgrupei

Articol de materiale

Cod articol

A 0001-0200 1 0001-0040 1 00012 0002

2 0041-0070 41 0041

42 0042

....

B 0201-0500 1 0201-0250 201 0201202 0202

2 0251-0300 0251 0251

188

sunt extrem de flexibile, în sensul că oferă posibilitatea adăugării de noi coduri sau excluderii de coduri din cadrul nomenclatorului fără a afecta caracteristica de grupare.

oferă posibilitatea prelucrării automate a datelor cu obţinerea de totaluri la nivelul fiecărei grupe, subgrupe etc.

Dezavantaj: comparativ cu codurile secvenţiale, codurile secvenţiale cu formare de grupe se caracterizează printr-o dimensiune sporită.

Codurile mnemonice se formează prin prescurtarea denumirii elementulelor mulţimii de codificat, astfel încât acestea să sugereze elementele corespunzătoare.

Exemplu: PROF ROF - regulament de organizare şi funcţionareCONF ROI - regulament de organizare internăLECTAvantaj: Codurile mnemonice sunt extrem de sugestive şi semnificative.

Codurile descriptive îşi găsesc o largă utilizare în descrierea caracteristicilor tehnico-constructive ale instalaţiilor, maşinilor, utilajelor.

Exemple:PC-486 DACIA 1310PC-586 DACIA 1410HD-400 DACIA NOVA

Avantaj: aceste coduri sunt extrem de sugestive.

Codurile ierarhizate permit exprimarea relaţiilor ierarhice ce se stabilesc între elementele unei structuri. Astfel, fiecărei trepte ierarhice i se atribuie una sau mai multe cifre în funcţie de numărul elementelor componente imediat inferioare. Un exemplu în acest sens este ilustrat în fig. 8.1.

Fig. 8.1

189

Cu ajutorul lor se codifică deci o serie de caracteristici ale elementelor mulţimii de codificat între care există relaţii de ierarhizare / subordonare, deci relaţii de incluziune.

Considerând mulţimea elementelor de codificat elementele structurii organizatorice a unei unităţi, vom avea (fig 8.2):

Fig. 8.2

Avantaj: oferă posibilitatea prelucrării automate a datelor cu obţinerea mai multor grupe de totaluri.(pe ateliere, pe secţii şi pe întreprindere).

Codurile juxtapuse se formează prin alăturarea şi codificarea unor caracteristici între care nu există nici o relaţie de subordonare. Modelul de formare a acestor coduri este ilustrat în fig. 8.3.

Secţiune de planObiectiv de investiţiiBeneficiarConstructor

x xxx xxx xxxFig. 8.3

Alte exemple: codul numeric personal codificarea fişelor tehnice în comerţul exterior

190

Codurile matriceale se formează prin asocierea elementelor unei matrici la două însuşiri ale obiectului supus codificării, astfel încât permit caracterizarea a două însuşiri ale unui element printr-o singură valoare a codului. Se referă în special la caracteristicile tehnice ale unui obiect. Un exemplu privind formarea unui cod matriceal este reprezentat de modul de dimensionare a produselor de cherestea (tabelul 3).

Tabel 3Lungime/

Lăţime (m)

1 2 3 4 5 6 7 8 9

0,10-0,20 1 2 3 4 5 6 7 8 9

0,21-0,30 11 12 13 14 15 16 17 18 19

0,31-0,40 21 22 23 24 25 26 27 28 29

0,41-0,50 31 32 33 34 35 36 37 38 39

Codurile binare constau în combinaţii posibile de cifre binare (0 şi 1) prin care se pot codifica o serie de situaţii complexe. Un exemplu în acest sens îl constituie codificarea stării civile:

0 0 0 - necăsătorit1 1 0 - căsătorit1 1 0 - casătorit fără copii1 1 1 - căsătorit cu copii

În legătură cu codificarea datelor, o problemă deosebită o reprezintă verificarea corectitudinii codului, în procesul de culegere, transmitere şi prelucrare a datelor. De aceea, se impune găsirea unor metode de prevenire a erorilor, metoda cel mai des folosită fiind cea a utilizării cifrei de control, calculată în conformitate cu un algoritm prestabilit.

d) Etapele realizării unui sistem de codificareProcesul de realizare a unui sistem de codificare cuprinde următoarea

succesiune logică de activităţi: identificarea (inventarierea) elementelor ce urmează a fi codificate

(stabilirea vocabularului de intrare); uniformizarea terminologiei şi precizarea denumirilor în vederea

elaborării nomenclatorului elementelor ce urmează a fi codificate (simbolurile de reprezentare);

analiza elementelor ce urmează a fi codificate, stabilirea caracteristicilor acestora şi a relaţiilor de ierarhizare/subordonare, în vederea

191

identificării grupelor şi subgrupelor din cadrul unei colectivităţi; se estimează numărul maxim de elemente din cadrul fiecărei grupe şi subgrupe şi evoluţia probabilă a acestora;

alegerea tipului de cod; estimarea capacităţii codurilor, stabilirea structurii şi dimensiunii

acestora; atribuirea codurilor elementelor mulţimii de codificat. Aceasta înseamnă

întocmirea nomenclatorului de coduri (alfabetul de ieşire) cu gruparea elementelor în funcţie de tipul de cod ales;

determinarea cifrei de control a fiecărui cod şi asocierea acesteia codului respectiv (dacă este cazul);

stabilirea unei modalităţi de întreţinere a nomenclatorului de coduri, astfel încât pe măsura apariţiei de noi elemente neincluse în nomenclator, acestea să fie codificate şi introduse în nomenclator.

Observaţie:Pentru a putea fi codifcată efectiv, o mulţime de elemente trebuie mai întâi

ordonată prin introducerea unei relaţii de ordine. Se folosesc în acest scop clasificări şi nomenclatoare.

Clasificarea reprezintă un procedeu ştiinţific de sistematizare a realităţii obiective, prin care devine posibilă cunoaşterea proceselor şi fenomenelor.

Clasificarea realizează împărţirea conform unor criterii a unei mulţimi de elemente de acelaşi tip în grupe (clase) de elemente, cu anumite caracteristici diferite. Mulţimea caracteristicilor determină ierarhizarea elementelor pe mai multe niveluri, sub formă de structuri arborescente, rezultând ierarhii de clase sau tipuri. Caracteristicile se "moştenesc" de la un nivel la altul, astfel:

- prin substituţie: dacă clasa C2 de elemente este moştenită de la superclasa C1, atunci asupra elementului de tip C2 se vor putea executa mai multe operaţii decât asupra celui de tip C1;

- prin incluziune: o clasă C2 este o subclasă a lui C1, deci orice element de tip C2 este în acelaşi timp şi un element de tip C1;

- prin restricţie, caz particular al incluziunii: o clasă C2 este o subclasă a clasei C1, dacă conţine toate elementele de tip C1 ce satisfac o restricţie specificată;

- prin specializare: o clasă C2 este o subclasă a clasei C1, dacă elementele aparţinând lui C2 aparţin şi lui C1, dar conţin un plus de informaţie specifică.

Elementele care au aceleaşi atribute şi acelaşi comportament pot fi categorisite ca făcând parte din aceeaşi clasă.

O clasificare corectă presupune îndeplinirea următoarelor condiţii:- fiecare clasă trebuie să conţină o parte din elementele mulţimii;- nici un element nu poate aparţine la două clase diferite;

192

- asemănările pe baza cărora se grupează elementele dintr-o clasă sunt mai importante decât deosebirile dintre ele;

- constituirea unei trepte de clasificare se face pe baza aceloraşi însuşiri.Nomenclatorul reprezintă lista elementelor unei mulţimi prezentate în ordinea

dată de o anumită clasificare.Unei entităţi (unui element) care se include într-un nomenclator i se asociază:- cod de identificare propriu;- cod de identificare a entităţii (elementului) de pe nivelul ierarhic superior;- denumirea entităţii (elementului) respective;- coduri asociate din alte nomenclatoare (după caz).La întocmirea nomenclatoarelor se caută eliminarea ambiguităţilor,

sinonimiilor şi asigurarea unicităţii înscrierii elementelor, prin determinarea claselor de sinonime şi alegerea dominantei acestora.

Odată sistematizată mulţimea de entităţi (elemente), prin clasificări şi nomenclatoare, ea poate fi supusă, în continuare, operaţiei de codificare propriu-zise.

8.4.3. Metode de determinare a cifrei de control (cheia codurilor)

În procesul de vehiculare, de manipulare a codurilor acestea pot fi afectate (modificate). Modificarea codurilor cu ocazia manipulării lor poate genera o serie de neajunsuri, constituind o sursă de erori în prelucrarea ulterioară a datelor.

Exemplu: Dacă la introducerea de la tastatură a datelor referitoare la drepturile şi reţinerile băneşti ale salariaţilor ar fi introdusă greşit marca unui salariat, atunci toate drepturile şi reţinerile băneşti ar fi trecute în contul altui salariat.

Dacă într-o aplicaţie de gestiune a stocurilor de materii şi materiale pentru producţie s-ar introduce de la tastatură codul unui material greşit, atunci din stocul altui produs se va scădea cantitatea consumată, iar stocul consumat real ar rămâne în baza de date neschimbat. Aplicaţia ar furniza informaţii eronate cu privire la stocurile de materiale existente în magazie, managerii nu ar putea lua decizii corecte cu privire la ce trebuie aprovizionat şi ce se poate produce, astfel că producţia şi aprovizionarea ar fi influenţate în mod eronat.

Pentru preîntâmpinarea unor astfel de situaţii se recurge la determinarea cifrei de control a codului (cheia codului).

În momentul elaborării nomenclatorului de coduri pe baza unui anumit algoritm se determină pentru fiecare cod o cifră de control corespunzătoare care va fi asociată codului respectiv şi-l va însoţi pe toată durata existenţei lui. Pe parcurs, cu ocazia introducerii unui cod se va recurge la recalcularea cifrei de control care va fi comparată cu cifra de control iniţială. În caz de diferenţă înseamnă că acel cod este eronat şi printr-un mesaj pe monitor va fi atenţionat operatorul care va reintroduce în mod corect codul.

Există o multitudine de metode de determinare a cifrei de control a codurilor.

193

1. Metoda mediei aritmetice ponderate

xi – reprezintă şirul de caractere din care este format codul yi – reprezintă un şir de ponderi prestabilitN – reprezintă un număr prim prestabilitRestul împărţirii va avea semnificaţia de cifră de control.

Exemplu : Fie codul 2138 (xi) şi şirul de ponderi 1234 (yi), N = 97.

Cifra de control 45 va fi ataşată codului: 213845.Presupunem că la un moment dat se doreşte introducerea de la tastatură a

codului 2138 însă din greşeală se tastează 2188.Se recalculează cifra de control.

Cifra de control veche (45) diferă de cifra de control nouă (60).Metoda mediei aritmetice prezintă neajunsuri: în momentul în care cu ocazia

tastării codului s-ar greşi două sau mai multe caractere nu ar fi exclusă situaţia ca prin compensare să rezulte acelaşi rest al împărţirii şi ca atare să nu fie identificate erorile.

2. Metoda mediei geometrice ponderateDiferă faţă de metoda mediei aritmetice ponderate prin faptul că şirul de

ponderi va fi format din puterile lui 2 (21, 22, 23, 24,…).Metoda mediei geometrice ponderate înlătură neajunsul sesizat în cadrul

metodei mediei aritmetice ponderate.3. Metoda conversiei restului împărţirii într-un caracter alfabeticMetoda diferă de precedentele prin următoarele: numărul prim prestabilit luat în considerare va fi cel mai mare număr prim

din cadrul numărului de litere ale alfabetului de referinţă în care se va converti restul excluzând ş,ţ,î,â,ă.

restul împărţirii se va converti într-o literă corespunzătore cardinalităţii acestuia.

Exemplu :

194

Avantajul metodei constă în faptul că întotdeauna cifra de control va fi formată dintr-un singur caracter.

8.5. Proiectarea bazei de date

Proiectarea bazei de date este o activitate distinctă şi deosebit de importantă, prin efectele ei în prelucrarea ulterioară a datelor, care se încadrează în metodologia de proiectare a sistemelor informatice.

Corespunzător celor 3 niveluri de organizare a datelor în baze de date, proiectarea bazei de date se va face la nivel logic, fizic şi virtual.

Activitatea de proiectare a bazei de date presupune realizarea următoarelor activităţi:

a). Proiectarea structurii conceptuale a bazei de date :b). Proiectarea structurii logice a bazei de date ; c). Proiectarea structurii fizice a bazei de date ;d). Alegerea sistemului de gestiune a bazei de date .

Aşadar, proiectarea unei baze de date înseamnă practic un proces de proiectare a structurii conceptuale, logice şi fizice a acesteia. Acesta nu trebuie privit ca un proces liniar de desfăşurare a activităţilor componente, deoarece în practică apar frecvente situaţii când sunt necesare reveniri la activităţile anterioare de proiectare. De exemplu, odată cu proiectarea structurii fizice pot apare cerinţe de modificare în structura conceptuală a bazei de date.

În urma analizei sistemului existent au fost obţinute, aşa cum am văzut, modele informaţionale, adică modele ale datelor şi prelucrărilor acestora în cadrul sistemului. Aceste modele, numite modele conceptuale, sunt independente de SGBD-ul ce va fi ales pentru implementarea lor.

Dacă ne referim la o bază de date relaţională, atunci ne reamintim că modelul relaţional de baze de date cuprinde trei componente principale:

Structura datelor ; Restricţii de integritate a datelor; Operatorii de prelucrare a datelor, prin operaţii din algebra relaţională sau

calculul relaţional.

De regulă relaţiile sunt reprezentate sub forma unor tabele bidimensionale în care fiecare rând reprezintă un tuplu şi fiecare coloană reprezintă valorile tuplurilor dintr-un domeniu dat al produsului cartezian.

În reprezentarea sub formă de tabel a unei relaţii, coloanelor şi, respectiv domeniilor corespunzătoare lor li se asociază nume intitulate atribute.

195

Observaţie:Dacă ne reamintim că un atribut se mai numeşte câmp, că structura tabelei

memorează descrierea câmpurilor de date şi a relaţiilor dintre acestea, vom spune că aritatea tabelei este dată de numărul de cîmpuri de date definite în structura tabelei.

Mulţimea numelor de atribute ale unei relaţii se numeşte schemă relaţională.Dacă relaţia numită R are atributele A1, A2, ... Ak , atunci schema relaţională se

notează R(A1, A2, ... Ak).Practic, relaţia este o asociere stabilită între două sau mai multe câmpuri

comune care se găsesc în două tabele. O relaţie leagă astfel date aparent izolate.

Considerând două tabele, A şi B, relaţiile pot fi de mai multe feluri:

- unu la unu (one-to-one ); În acest caz se cere ca valoarea câmpului cheie dintr-o singură înregistrare a tabelei A să fie identică cu o singură valoare corespondentă din câmpul asociat din tabela de legătură B. Cu alte cuvinte, fiecare înregistrare din tabela A poate avea doar o singură înregistrare corespondentă în B şi invers. Acest tip de relaţie este mai puţin utilizată, căci datele se pot afla, în acest caz, într-o singură tabelă.

- unu la mulţi (one-to-many); În acest caz se cere unicitatea câmpului cheie din tabela A, dar valorile lui să fie identice cu mai multe valori ale câmpului asociat din tabela B. Cu alte cuvinte, o înregistrare din tabela A poate avea mai multe înregistrări corespondente în tabela B, dar o înregistrare din B se potriveşte cu o singură înregistrare din tabela A. Practic legătura se face între cheia primară a tabelei de bază, A, şi cheile externe corespunzătoare din tabelele corelate.

- mulţi la mulţi (many-to-many). În acest caz nu există nici o relaţie unică între câmpurile cheie ale tabelelor A şi B, fiecare dintre acestea conţinând valori duplicat în cealaltă tabelă. Acest tip de relaţie este echivalenttă şi se poate descompune în două relaţii de tip one-to-many. Relaţia este posibilă prin definirea unei tabele noi, C, numită tabelă de joncţiune, a cărei cheie primară este formată din cele două chei primare, devenite astfel chei externe ale celor două tabele care trebuie corelate.

După toate acestea urmează, firesc, încărcarea bazei de date, prin încărcarea tabelelor componente una câte una, în ordinea impusă de relaţiile stabilite între acestea.

Restricţiile de integritate definite nu ne vor lăsa să greşim, în sensul că nu vom putea completa de exemplu un contract dacă nu am introdus mai întâi datele în nomenclatoarele existente de Produse şi respectiv Clienţi.

196

8.5.1. Proiectarea structurii conceptuale a bazei de date

Este o activitate realizată de către echipa de proiectare a sistemului de administrare a bazei de date, care pleacă de la colecţiile de date stabilite la nivel global în etapa de concepere a sistemului informatic (proiectare de ansamblu), când s-a schiţat şi un prim model conceptual de ansamblu al datelor.

Proiectarea structurii conceptuale a bazei de date presupune realizarea următoarelor activităţi specifice: a). Definirea detaliată a colecţiilor de date b). Determinarea legăturilor dintre colecţii c). Definirea modelului conceptual de ansamblu al datelor d). Testarea modelului conceptual de ansamblu al datelor e). Transpunerea modelului conceptual

Toate aceste activităţi pornesc de la Modelul Entitate Asociere, realizat în urma activităţii de studiu şi analiză a sistemului obiect şi au fost prezentate, sub formă de concepte şi de reguli în capitolul 3, intitulat Modelarea conceptuală a datelor.

Definirea detaliată a colecţiilor de date presupune analiza colecţiilor de date şi normalizarea lor pentru a asigura creşterea performanţelor în stocarea, actualizarea şi prelucrarea datelor. Definitivarea colecţiilor de date se face prin descompunerea acestora în colecţii de date simple, în funcţie de descompunerea obiectelor compuse în obiecte simple şi păstrând, dacă este cazul, o redundanţă minimă şi controlată a datelor. De asemenea, se urmăreşte descrierea cât mai precisă a caracteristicilor obiectelor identificate. Astfel, pentru un obiect simplu caracteristicile vor fi cele care îl identifică şi îl descriu în modelul entitate –asociere. Pentru un obiect compus, caracteristicile vor fi cele de identificare a acestuia şi cele de descriere a obiectelor simple, legate de cele compuse.

Definirea modelului conceptual de ansamblu al datelor se realizează prin integrarea tuturor entităţilor definite în Modelul Entitate Asociere prin intermediul relaţiilor determinate într-un model unic, de ansamblu al datelor din baza de date. Definirea modelului conceptual de ansamblu al datelor prezintă o serie de particularităţi, în funcţie de tipul modelului de date pe care urmărim să-l obţinem.

Astfel, dacă în cazul modelelor de tip ierarhic şi reţea pentru definirea modelului conceptual de ansamblu se reunesc toate entităţile şi relaţiile stabilite în etapele anterioare, în cazul modelului relaţional se proiectează tabelele de date care alcătuiesc baza de date şi prin care se reprezintă atât entităţile cât şi relaţiile dintre acestea. Regulile de trecere de la Modelul Entitate Asociere la modelul relaţional au fost prezentate în capitolul 3.7 intitulat Modelul relaţional.

197

Proiectarea tabelelor de date ale unei baze de date relaţională se poate realiza într-o abordare top-down sau într-o abordare bottom-up.

Proiectarea tabelelor de date în abordarea top-down se realizează prin definirea unei tabele în care atributele devin coloane, iar liniile sunt realizări ale relaţiei. Prin normalizare se pot obţine mai multe tabele de date din tabela iniţială. În acest sens se recomandă tratarea diferenţiată a reprezentării fiecărui tip de relaţie.

Reprezentarea relaţiei de tip 1:1 Dacă relaţia dintre două entităţi este totală (ambii membri sunt obligatorii),

atributele celor două entităţi se pot trece în aceeaşi tabelă. Relaţia de tip 1:1 e reprezentată în mod implicit prin prezenţa atributelor ambelor entităţi într-o singură tabelă. Nu este deci necesară introducerea unei tabele suplimentare pentru explicitarea relaţiei.

Dacă însă relaţia este parţială astfel că numai unul din membrii relaţiei este obligatoriu, atunci există posibilitatea definirii a două tabele corespunzătoare celor două entităţi sau a unei singure tabele care va prezenta însă valori nule pentru unele atribute.

Dacă relaţia e parţială astfel că ambii membrii ai relaţiei nu sunt obligatorii, relaţia trebuie să fie reprezentată printr-o tabelă separată. Sunt necesare deci trei tabele.

Reprezentarea relaţiei de tip 1:N Dacă partea cu mulţi a relaţiei este obligatorie, atunci reprezentarea relaţiei se

face prin două tabele. Reprezentarea relaţiei de tip M:N Se realizează prin trei tabele: două pentru entităţile aflate în relaţie şi una

pentru relaţia M:N. Practic această relaţie se descompune în două relaţii de tip : 1 la N şi N : 1. Apoi se trece la completarea tabelelor cu noi atribute, astfel încât tabelele să rămână normalizate. Dacă există mai multe posibilităţi de a adăuga atributul (la mai multe tabele) se va avea în vedere aceea în care se introduc cât mai puţine valori nule.

Tabelele rezultate iniţial sunt apoi rafinate, validate şi transpuse în termenii SGBD-ului ales. Există în acest sens o întreagă activitate de definire şi redefinire a tabelelor unei baze de date pe baza unor principii riguros stabilite în cadrul procedeului numit normalizarea bazei de date. După cum obiectul reprezentat printr-o tabelă este simplu sau complex, tot astfel caracteristicile lui, reprezentate prin câmpuri (atribute) vor fi simple sau complexe. De exemplu, atributele asociate obiectelor cărţi din bibliotecă vor fi: cod, titlu, autor, Isbn, data apariţiei, editura etc.

O tehnică de proiectare a modelului conceptual al bazei de date într-o abordare top-down este tehnica celor cinci forme normale.

Conform acestei tehnici, atributele entităţilor definite se organizează într-o singură tabelă sau în mai multe şi apoi se urmăreşte descompunerea acestora în alte tabele, fără pierdere de informaţii şi în scopul eliminării anomaliilor de ordin

198

logic şi fizic. Se parcurg astfel o serie de etape de normalizare, prin care se trece de la o formă normală la alta. Prin parcurgerea acestor etape, se ajunge în mod succesiv să se amelioreze structura bazei de date, înlăturându-se treptat o serie de neajunsuri şi asigurând facilităţi sporite în privinţa încărcării, actualizării şi exploatării bazei de date.

Nu se impune întotdeauna parcurgerea tuturor etapelor de normalizare, dar în mod obligatoriu prima forma normală este obligatorie.

Se ştie că o tabelă (relaţie) este într-o formă normală dacă satisface anumite restricţii. Necesitatea normalizarii progresive este dată de faptul că anumite relaţii pot genera o serie de situaţii nedorite, aşa-numitele "anomalii de actualizare", cum sunt: anomalia de adăugare, anomalia de modificare.

Anomalia de ştergere rezultă din faptul că ştergând un tuplu al unei relaţii, odată cu ştergerea anumitor informaţii se pierd şi informatiile utile, existente în tuplul respectiv.

Anomalia de adăugare rezultă din faptul ca nu pot fi incluse noi informaţii într-o relaţie deoarece nu se cunosc şi alte informaţii cerute pentru adăugarea unui nou tuplu la acea relaţie, în principal valorile pentru atributele din cheie.

Anomalia de modificare rezultă din faptul că e dificil de modificat o valoare a unui atribut atunci când ea apare în mai mult decât într-un tuplu al relaţiei.

Anomaliile de actualizare apar nu numai la modelul relaţional, ci şi la celelalte modele de date (ierarhice şi reţea) precum şi la fişierele clasice. Pentru modelele ierarhice şi reţea nu există însă o teorie a înlăturării anomaliilor de actualizare.

Toate aceste anomalii trebuie rezolvate în etapa de proiectare a structurii bazei de date şi nu după ce baza de date a fost încărcată cu date reale şi au fost scrise aplicaţii pentru ea. În acest context, teoria normalizării îşi propune înlăturarea acestor anomalii în faza de proiectare a structurii bazei de date, ducând astfel la performanţe de ordin logic, dar şi fizic cum sunt: ocuparea optimă a spaţiului de memorie sau reducerea timpului de răspuns al sistemului.

Enunţăm, pe scurt , regulile normalizării unei baze de date relaţionale:1. O bază de date este în FN1 dacă toate tabelele sale sunt în FN1. O tabelă e în FN1 dacă toate atributele ei sunt elementare (nedecompozabile) şi

nu conţine grupuri repetitive. Deci, în această etapă, structurile de date arborescente sau reţea devin tabele cu atribute elementare.

O tabela în FN1 prezintă însă o serie de anomalii cum ar fi: anomalii în modificarea unor elemente din tupluri datorită necesităţii modificării aceloraşi elemente de mai multe ori; anomalii la ştergerea unor tupluri deoarece se distrug raporturile existente între anumite relaţii. Deasemenea, într-o tabelă în FN1 pot să

199

apară aceleaşi date de mai multe ori. De aceea este necesară eliminarea redundanţei datelor prin trecerea la forma normală FN2.

2. O bază de date este în FN2 dacă toate tabelele sale componente sunt în FN2.

O tabelă este în FN2 dacă şi numai dacă este în FN1 şi fiecare câmp noncheie al tabelei este dependent funcţional direct şi complet de câmpul cheie al tabelei.

Se ştie că un atribut B al unei relaţii depinde în mod funcţional de atributul A al aceleiaşi relaţii dacă în orice moment fiecărei valori a lui A îi corespunde o valoare a lui B. Dependenţa funcţională este completă sau parţială.

Un atribut sau un ansamblu de atribute B din cadrul unei relaţii este dependent funcţional complet de un ansamblu de atribute A ale aceleiaşi relaţii, dacă B este dependent funcţional complet de întreg ansamblul A de atribute şi nu numai de un atribut din ansamblul A.

Un atribut B e dependent funcţional parţial de un ansamblu de atribute A dacă e dependent funcţional de un atribut din ansamblul A.

În acest context proiectantul bazei de date relaţionale are sarcina de a identifica dependenţele funcţionale dintre atributele tabelului şi a asigura dependenţa funcţională completă între atributele noncheie şi atributele cheie din cadrul fiecărui tabel. Acest lucru va determina proiectarea a două sau mai multe tabele, eliminând astfel anomaliile la modificarea unor valori şi repetarea unor valori. Toate acestea au ca efect utilizarea raţională a memoriei externe şi chiar reducerea timpului de întreţinere a bazei de date, protejarea acesteia de ştergerea nedorită a unor informaţii.

Cu toate acestea o tabelă în FN2 prezintă încă o serie de anomalii la crearea şi exploatarea bazei de date din cauza dependenţelor tranzitive a atributelor noncheie faţă de cheia relaţiei, motiv pentru care este necesară trecerea ei în forma normală următoare.

3. O bază de date este în FN3 dacă toate tabelele ce o compun sunt în FN3. O tabelă este în FN3 dacă fiecare atribut noncheie al tabelei depinde în mod

netranzitiv de cheia tabelei. Fie A,B,C, trei atribute din cadrul unei tabele unde A e atribut cheie. Dacă B

depinde de A şi C depinde de B, spunem că C se află în dependenţă tranzitivă de A. Asemenea dependenţe nu sunt acceptate şi se înlătură prin proiectarea a două tabele care conţin : A B şi respectiv B C.

O tabelă în FN3 prezintă însă anomalii de actualizare, motiv pentru care se impune trecerea în forma normală patru.

4. O bază de date este în FN4 dacă şi numai dacă este în FN3 şi nu conţine două sau mai multe dependenţe multivaloare.

Acest neajuns se poate înlătura numai prin realizarea unei noi dependenţe de tip "joncţiune". Dependenţa joncţiune este forma cea mai generală de dependenţă; ea conduce la obţinerea unor tabele prin operaţii de proiecţie şi joncţiune. O tabelă

200

R(A,B,C) menţine dependenţa joncţiune A(AB,AC) dacă şi numai dacă R menţine dependenţele multivaloare A->B/C.

Înseamnă deci că dependenţa multivaloare reprezintă un caz special al dependenţei joncţiune.

5. O relaţie e în FN5 dacă şi numai dacă fiecare joncţiune e generată printr-un candidat cheie a lui R şi e în FN4.

Testarea modelului conceptual de ansamblu al datelor se face pe baza criteriilor formulate pentru validarea oricărui model conceptual al datelor şi poate duce la adăugarea entităţilor şi/ sau a corelaţiilor necesare, la verificarea relaţiilor dintre entităţi în vederea regăsirii informaţiilor necesare la un moment dat din mai multe entităţi precum şi a editării unor situaţii complexe, cu date agregate, a actualizării concomitente a datelor redundante acceptate etc.

Prin verificarea modelului se poate ajunge la rearanjarea unor componente ale modelului, la adăugarea unor relaţii suplimentare care înseamnă practic introducerea de noi entităţi. Dacă se vor introduce în modelul de ansamblu al datelor toate legăturile posibile, se va ajunge la o creştere nejustificată a complexităţii logice a modelului şi, pe această bază, la creşterea timpului de realizare a proiectului. De aceea, introducerea unor noi entităţi sau relaţii în modelul conceptual de ansamblu trebuie făcută cu multă atenţie.

Transpunerea modelului conceptual se face în termenii unui anumit SGBD şi descrierea structurii sale în limbajul corespunzător acestui SGBD.

Modelul conceptual de ansamblu al datelor este un model de ansamblu al datelor independent de instrumentul soft (SGBD) şi de aceea se va concretiza în structură în mod diferit, funcţie de facilităţile tehnice oferite de SGBD, în special de modalităţile de implementare a diferitelor tipuri de relaţii şi date.

Descrierea bazei de date se face în limbajul de care dispune SGBD-ul ales. Rezultatul final al descrierii structurii bazei de date îl constituie schema bazei de date.

Concluzii cu privire la proiectarea structurii conceptuale a bazei de date: a). Proiectarea structurii conceptuale a bazei de date se realizează de regulă

într-o abordare top-down. Se pleacă de la un prim model conceptual de ansamblu, realizat în etapa de concepere a sistemului informatic la nivel global, care în paşi succesivi este realizat, detaliat şi corectat, până la obţinerea structurii conceptuale a bazei de date. Pentru modelul relaţional al datelor este posibilă şi o abordare bottom-up de proiectare, care porneşte de la nivelul logic de detaliu (atribute) şi ajunge la o sinteză, abordare mai puţin utilizată.

b). Proiectarea structurii conceptuale are la bază o modelare a datelor relativ independentă de aplicaţii, cu alte cuvinte nu este orientată exclusiv pe aplicaţii, dar nici nu este complet independentă de acestea. Se ştie că modelarea orientată pe aplicaţii complică artificial structura datelor şi oferă posibilităţi scăzute de adaptare la noi cerinţe informaţionale, în timp ce modelarea independentă de

201

aplicaţii presupune o analiză complexă, consumatoare de resurse şi de timp, iar aplicaţiile nu pot fi dezvoltate decât după detalierea conţinutului bazei de date.

c). Proiectarea structurii conceptuale a bazelor de date are la bază o modelare a datelor independentă de instrumentul informatic de implementare (SGBD). Modelarea datelor orientate spre conceptele proprii unui anumit SGBD prezintă o serie de dezavantaje, cum sunt : schimbarea SGBD-ului presupune reproiectarea bazei de date; conceptele tehnice ale SGBD-ului pot influenţa negativ activitatea de modelare a datelor prin restricţiile lor specifice care pot încuraja sau descuraja anumite reprezentări; pornind de la facilităţile unui SGBD, utilizatorul neinformatician, care nu e specializat în SGBD-uri nu îşi poate exprima cerinţele în deplină cunoştinţă de cauză.

8.5.2. Proiectarea structurii logice a bazei de date

Structura logică a bazei de date reprezintă forma sub care apare structura conceptuală a bazei de date pentru un utilizator oarecare.

Programele de aplicaţie operează asupra elementelor structurii conceptuale prin intermediul structurii logice, având acces doar la acele elemente ale structurii conceptuale care sunt incluse în structura logică.

În general elementele care compun structura logică sunt similare celor care compun structura conceptuală, totuşi depind de tipul de SGBD utilizat.

De regulă, fiecărei entităţi de grup identificate în analiza datelor şi a prelucrărilor lor i se asociază iniţial câte o tabelă, definită prin caracteristicile ei.

În această etapă se denumesc tabelele componente ale bazei de date, se defineşte practic structura logică a fiecărei tabele, se descriu relaţiile dintre ele şi se stabilesc restricţiile de integritate a acestora. Numele dat tabelelor e bine să sugereze conţinutul acestora. Pentru fiecare atribut din structură (câmp de date) se specifică elementele de caracterizare, şi anume: tipul, lungimea, eventuale restricţii privind domeniul valorilor admise sau corelaţiile implicate, rolul de atribut non-cheie sau atribut cheie şi tipul acesteia (cheie primară, cheie externă, cheie candidat). De exemplu, caracteristicile (atributele) asociate obiectelor ANGAJAŢI ar putea fi: cod numeric personal (câmp numeric din 13 caractere, cu o structură bine stabilită, ale cărei componente vor putea fi verificate la introducere); nume angajat (câmp alfanumeric din 30 caractere); cod compartiment (câmp numeric din 3 caractere); cod funcţie (câmp numeric format din 4 caractere); salariu tarifar de încadrare (câmp numeric format din 9 caractere); data încadrării (câmp de tip dată calendaristică - 8 caractere); adresa (câmp alfanumeric din 30 caractere).

Se poate spune că prin separarea nivelului logic de nivelul conceptual se separă practic funcţia de administrare de funcţia de utilizare – exploatare a bazei de date.

202

8.5.3. Proiectarea structurii fizice a bazei de date

Se ştie că structura conceptuală a bazei de date îmbracă diferite forme de reprezentare: liniară, arborescentă, reţea, relaţională. Memorarea datelor pe un suport fizic îmbracă însă numai forma unei structuri liniare. De aceea se pune problema liniarizării structurii virtuale (conceptuale).

Metoda de liniarizare a structurii virtuale este specifică diferitelor SGBD-uri utilizate. Astfel, unele SGBD-uri utilizează pentru realizarea structurii fizice metode tipice de organizare a datelor folosite în cadrul sistemelor de operare gazdă, altele utilizează metode proprii de organizare a datelor, independente de cele folosite în cadrul sistemului de operare gazdă.

Această din urmă grupă de SGBD-uri depinde astfel mai puţin de sistemele de operare gazdă, ceea ce le oferă o portabilitate sporită în comparaţie cu celelalte.

Principalele activităţi abordate în cadrul acestei faze sunt:a. proiectarea machetelor de stocare a datelor b. definirea caracteristicilor fizice la nivelul fişierelor bazei de datec. calculul necesarului de suport tehnic de date

Toate acestea au însă o strânsă legătură cu SGBD-ul utilizat. De aceea alegerea sistemului de gestiune a bazei de date reprezintă o problemă deosebit de importantă în proiectarea unui sistem informatic. Pentru aceasta e necesară parcurgerea următoarelor etape:

- stabilirea cerinţelor beneficiarului şi studiul acestora în ceea ce priveşte: tipurile de structuri de date, timpul de răspuns cerut, metodele de acces, confidenţialitatea datelor, tipul aplicaţiilor, obiectivele generale ale sistemului ;

- stabilirea criteriilor de alegere a unui SGBD din cadrul celor existente, în funcţie de cerinţele beneficiarului.

- inventarierea SGBD-urilor existente, capabile să satisfacă cerinţele prestabilite ale beneficiarului sistemului şi alegerea unui SGBD corespunzător.

În aceste condiţii alegerea sistemului de gestiune a bazelor de date se face pe baza unor criterii riguroase, cum sunt:

Cerinţele utilizatorilor, în legătură cu tipul de aplicaţii solicitate, timpul de răspuns al sistemului, securitatea datelor, confidenţialitatea lor, uşurinţa de utilizare, etc. E posibil uneori ca utilizatorul să impună chiar el un anume SGBD.

Necesităţi de ordin tehnic, legate de portabilitatea colecţiilor de date, a programelor şi a SGBD-ului ales pe diverse sisteme de calcul, facilităţi de încărcare, de întreţinere şi de exploatare curentă a bazei de date.

Se ştie că, pentru realizarea unor programe portabile este necesar ca programele să conţină cât mai puţine elemente legate de echipament, iar acele părţi de program ce presupun elemente legate de echipament să fie izolate atât funcţional cât şi fizic de celelalte părţi ale programului. Se recomandă în acest caz

203

ca programul să fie organizat în două părţi : un program principal independent de echipament şi un program care conţine elemente dependente de echipament. La trecerea de pe un sistem pe altul se va proceda doar la rescrierea subprogramelor dependente, în funcţie de noul echipament.

Portabilitatea datelor se referă la posibilitatea de a folosi o serie de date utilizate în cadrul unui sistem informatic de către un alt sistem informatic, deci posibilitatea integrării fişierelor deja existente în cadrul unui alt sistem.

Cerinţe de ordin economic, legate de încadrarea în totalul resurselor alocate pentru realizarea noului sistem informatic, cum sunt cele financiare, de personal şi de timp.

Costul sistemului dat de timpul de ocupare a unităţii centrale, costul de întreţinere şi dezvoltare al sistemului, resursele hardware imobilizate, costul de adaptare şi trecere pe alt sistem de calcul, costul documentaţiei etc.

Protecţia şi securitatea datelor din baza de date. Specificul aplicaţiei. Se ştie că programele sunt orientate pe aplicaţii, cum

sunt: programarea şi urmărirea producţiei, aprovizionare-desfacere, optimizări, prognoze etc.

Timpul şi costul pentru instruirea personalului care să utilizeze SGBD-ul şi aplicaţia realizată

Facilităţe de implementare, de întreţinere, exploatare a bazei de date. Toate acestea ţin de modalitatea de descriere a datelor, de tehnicile de

organizare şi regăsire a datelor care să permită accesul rapid la acestea, timpul pentru actualizare şi interogare, editarea operativă a situaţiilor solicitate, posibilitatea de utilizare a unor programe de aplicaţie, programe de validare a datelor, de actualizare a bazei de date, rutine statistice, rutine de sortare, rutine de prezentare grafică a ieşirilor etc.

Analiza comparativă a SGBD-ului ales cu altele existente, în funcţie de principalele lor caracteristeici;

Alegerea propriu-zisă a SGBD-ului care urmează să fie utilizat şi eventual achiziţionat (ceea ce presupune cheltuieli pentru licenţa – dreptul de folosire – a produsului respectiv).

Aceste criterii pot fi asociate cu altele, cum sunt: mentenanţa sistemului, facilităţile de administrare a bazei de date, calitatea documentaţiei oferite de proiectant, asistenţă în implementara sistemului, pregătirea utilizatorilor etc.

Se poate aprecia astfel că realizarea proiectării fizice concretizează armonizarea datelor de intrare cu posibilităţile tehnice de prelucrare în raport direct cu cerinţele informaţionale. De calitatea soluţiei obţinută în cadrul proiectării logice depinde calitatea soluţiei tehnice şi implicit, calitatea proiectării bazei de date.

8.6. Proiectarea interfeţei

204

Un element deosebit de important al oricărei aplicaţii informatice este, pe lângă capacitatea ei de a gestiona cât mai bine toate cerinţele de prelucrare a datelor, interfaţa cu utilizatorul sau modul cum comunică aplicaţia proiectată cu utilizatorul nespecialist în informatică .

În acest sens e necesar ca proiectantul să realizeze o interfaţă prietenoasă, plăcută şi unitară, pentru a uşura munca utilizatorului.

Avem în vedere două aspecte importante ale interfeţei unei aplicaţii: caracteristicile vizuale ale interfeţei comportamentul interfeţei ca răspuns la acţiunea utilizatorului. Aceste două caracteristici sunt puternic intercondiţionate. Astfel, multe acţiuni

ale utilizatorului sunt dictate de aspectul vizual al interfeţei; de asemenea, acţiuni similare trebuie să fie reprezentate vizual în aceeaşi manieră.

În această etapă beneficiarul unei aplicaţii proiectate de o echipă de informaticieni poate să ceară şi să aprecieze calitatea interfeţei proiectate funcţie de nişte cerinţe minimale pe care aceasta trebuie să le îndeplinească. Practic, interfaţa aplicaţiei reprezintă posibilitatea utilizatorului de a comunica direct cu aceasta, deci de a înţelege cerinţele aplicaţiei în fiecare moment şi modalitatea în care trebuie să-i răspundă. De reuşita acestui dialog permanent depinde în mare măsură succesul execuţiei aplicaţiei, a corectitudinii datelor furnizate.

În acest sens interfaţa grafică trebuie să fie :o Consistentă: Aceasta înseamnă că pentru o anumită operaţie să se

folosească acelaşi obiect vizual. Accesul la operaţii similare să se face deci prin aceleaşi acţiuni ale utilizatorului (mouse, tastatură) şi folosind acelaşi obiect vizual.

o Intuitivă: Interfaţa să fie sugestivă, să poată fi intuită chiar fără documentaţie sau cursuri de instruire.

o Extensibilă: Aceasta înseamnă că ea trebuie să fie adaptabilă la noi echipamente hard (de exemplu monitoare cu rezoluţie mai mare);

o Atractivă: Aceasta înseamnă că interfaţa trebuie să aibă caracteristici estetice care să atragă utilizatorul, să-i facă plăcere să comunice cu ea. O interfaţă aglomerată va îndepărta utilizatorul.

o Uşor de utilizat: Aceasta înseamnă că operaţiile simple trebuie să se realizeze prin acţiuni simple ale utilizatorului. Operaţiile complexe trebuie să se realizeze printr-o succesiune de acţiuni simple ale utilizatorului.

o Uşor de învăţat: Aceasta înseamnă că orice acţiune utilizator trebuie să fie uşor de realizat. Experienţa acumulată în învăţarea unor acţiuni să poată fi folosită la învăţarea altor acţiuni.

Aceste elemente definitorii ale interfeţei utilizator sunt rezultatul a 10 principii (cerinţe) de proiectare a interfeţelor utilizator.

Aceste principii sunt prezentate adeseori ca “cele 10 porunci”:

205

(1) Utilizatorul (U) controlează programul: U simte că el controlează programul, şi nu invers (programul îl dirijează pe el)

Această cerinţă este caracterizată de rolul activ al utilizatorului, personalizarea mediului de lucru, anumite caracteristici ale aplicaţiei (programului). Rolul activ al utilizatorului înseamnă în special că:

Utilizatorul iniţiază acţiuni ; Utilizatorul conduce aplicaţia: calculatorul doar execută comenzile

utilizatorului şi nu invers. Personalizarea mediului de lucru ţine de caracteristicile personale ale

utilizatorului uman. Oamenii au preferinţe extrem de diverse, iar o interfaţă utilizator bună trebuie să permită utilizatorului să se simtă cât mai comod. Între aspectele de interfaţă supuse personalizării amintim fonturile, stilul formatării, culorile, etc.

Caracteristicile programului pe care se sprijină această calitate se referă la: interactivitate reacţie (răspuns) la fiecare acţiune a utilizatorului flexibilitate Regimul de lucru modal este prin excelenţă unul imperativ (calculatorul cere

utilizatorului să facă o anumită acţiune, aşteptând răspunsul acestuia, deci raportul de forţe se schimbă: calculatorul devine activ, iar utilizatorul devine reactiv).

Se recomandă ca aplicaţiile să fie cât mai puţin modale, în sensul că utilizatorul să se simtă cât mai liber (în sensul de a nu se simţi dirijat) în ceea ce face. În cazul când se folosesc ferestre modale, integrarea lor în aplicaţie trebuie să fie naturală.

Deschiderea unei astfel de ferestre trebuie să fie rezultat direct al unei acţiuni explicite a utilizatorului; în plus, acesta trebuie să o poată oricând abandona, revenind la rolul său eminamente activ.

(2) Utilizatorul manipulează direct informaţia, cu alte cuvinte, U trebuie să poată opera direct cu reprezentarea pe ecran a informaţiei. În acest fel, el poate constata direct relaţia cauză-efect între acţiunile sale (efectuate prin intermediul interfeţei) şi rezultatul acestora (modul în care programul reacţionează la acţiunile sale).

Informaţia trebuie reprezentată în interfaţa utilizator într-o manieră cât mai naturală. Astfel, fereastra, elementul esenţial al interfeţei utilizator în Windows, este utilizat şi în cadrul interfeţelor cu utilizatorul a aplicaţiilor informatice. Într-o fereastră, informaţia este reprezentată într-o formă cât mai naturală, în special prin text. Faptul că de multe ori elementul primar, textul, este înglobat sau înlocuit de obiecte vizuale mai sugestive nu face decât să uşureze capacitatea de percepţie şi de acţiune a utilizatorului.

În aceste situaţii, informaţia cu care utilizatorul operează este reprezentată într-o manieră naturală, iar acţiunea acestuia asupra interfeţei se realizează prin

206

comenzi (acţiuni) foarte simple. Fiecare acţiune (click sau mutare mouse) provoacă o modificare în poziţia obiectului sau conţinutului informaţional al acestuia.

Pentru satisfacerea acestei cerinţe, interfaţa utilizator trebuie să ofere utilizatorului o manieră directă şi intuitivă de comunicare.

(3) Consistenţa. Această proprietate a interfeţei utilizator permite utilizatorului să înveţe rapid

utilizarea unor noi aplicaţii, prin folosirea cunoştinţelor acumulate pe parcursul învăţării şi utilizării altor aplicaţii Windows. Se obţine ceea ce se numeşte stabilitate: interfaţa este familiară (chiar dacă este vorba de o nouă aplicaţie), iar răspunsul aplicaţiei este previzibil (altfel spus, se mizează pe comportamentul uniform al aplicaţiilor).

Putem identifica trei nivele la care se poate discuta consistenţa: consistenţă intra-aplicaţie consistenţă inter-aplicaţii consistenţă cu mediul/sistemul de operare Consistenţa intra-aplicaţie (în interiorul aplicaţiei) statuează că operaţiile

(funcţiile) comune trebuie prezentate vizual prin folosirea unei mulţimi consistente de comenzi şi interfeţe. De exemplu, pentru identificarea unei înregistrări din oricare tabelă a bazei de date, să se deschidă aceleeaşi casetă de dialog iar prescurtările folosite să fie asemănătoare şi sugestive în acelaşi timp.

Consistenţa inter-aplicaţii se referă la comportamentul similar al mai multor aplicaţii atunci când utilizatorul iniţiază o aceeaşi acţiune. Spre exemplu actualizarea unui fişier se face identic (ca acţiune utilizator), iar operaţia de actualizare are nevoie de aceleaşi informaţii

Consistenţa cu sistemul/mediul de operare se realizează prin convenţiile de interfaţă şi de interacţiune utilizator pe care sistemul de operare (Windows) le impune. Trebuie accentuat aici rolul sistemului de operare în uniformizarea interfeţei şi acţiunilor utilizator.

Orice nouă aplicaţie trebuie să se alinieze la standardele pe care sistemul de operare le impune, iar efectul acestei constrângeri este benefic: utilizarea noului produs va fi uşor de învăţat tocmai pentru că acesta respectă cerinţele mediului sub care se execută. Nu este mai puţin adevărat că, la rândul lui, mediul de execuţie pune la dispoziţia programatorului de aplicaţie majoritatea instrumentelor de care acesta are nevoie pentru a realiza interfaţa.

(4) Claritate. Această calitate a interfeţei utilizator poate fi discutată din trei puncte de

vedere: vizual, conceptual, lingvistic.Claritatea vizuală a interfeţei este asigurată de elementele (obiectele) vizuale

care o compun. Acestea trebuie să fie sugestive, uşor de înţeles, ele reprezentând

207

în fapt o transpunere simplificată a unor obiecte reale. De asemenea, aranjarea obiectelor vizuale pe ecran este importantă: ne referim aici la gruparea lor după criteriul similarităţii comportamentului lor, care va uşura identificarea lor.

Claritatea conceptuală se caracterizează prin două atribute: simplu şi realist. Simplitatea interfeţei înseamnă număr rezonabil de obiecte pe un ecran (pe o fereastră). Caracterul realist al interfeţei se realizează prin similitudinile cu obiectele reale (de exemplu, dacă o fereastră conţine un document - de exemplu o factură - atunci obiectele care formează respectivul document trebuie să reproducă cât se poate de exact aspectul acesteia).

Claritatea lingvistică se referă la textul care apare în interfaţă. Denumirile opţiunilor de meniu, etichetele, mesajele, etc. trebuie să fie clare, neambigue, iar exprimarea lor trebuie să folosească limba literară şi nu limbajul propriu comunităţii informatice.

(5) EsteticăInterfaţa trebuie să atragă utilizatorul, să-i placă acestuia. Mediul vizual plăcut,

prietenos, contribuie la confortul utilizatorului şi la o mai bună înţelegere a informaţiei prezentate. Nimic din ceea ce poate contribui la sporirea atributelor estetice ale interfeţei nu trebuie neglijat - inclusiv recurgerea la serviciile unui designer profesionist.

De asemenea, oricând este cazul, e bine ca utilizatorul să fie implicat în proiectarea interfeţei. De multe ori lucruri care par evidente proiectantului sunt ascunse pentru utilizator.

(6) Răspuns imediat la acţiunile utilizatoruluiAceastă cerinţă contribuie la sporirea confortului utilizatorului şi impune ca

aplicaţia să confirme vizual că a preluat cererea utilizatorului şi că este în curs execuţia acţiunii aferente cererii.

În unele situaţii, confirmarea este evidentă: spre exemplu, la iniţierea unei cereri de adăugare de noi înregistrări într-un fişier pe ecran apare o casetă de dialog şi utilizatorului i se cere să introducă informaţiile corespunzătoare.

În alte situaţii, confirmarea s-ar părea că nu este necesară: de exemplu când se lansează o operaţie de prelucrare complexă într-un fişier mare sau când se efectuează sortarea unui fişier cu zeci sau sute de mii de înregistrări. Este o părere greşită, pentru că utilizatorul simplu ar putea crede (în lipsa afişării unei informaţii privind starea operaţiei lansate de el) că sistemul s-a blocat (deoarece interfaţa nu mai reacţionează la comenzile sale), sau, mai rău, că a efectuat o operaţie interzisă ale cărei efecte pot fi catastrofale din punctul lui de vedere.

Când este vorba de acţiuni care durează mai mult, informaţia care trebuie afişată ca răspuns la acţiunile utilizatorului trebuie să precizeze:

starea (derularea) acţiunii în curs modul în care acţiunea poate fi suspendată sau abandonată.

208

(7) Toleranţă la greşelile utilizatoruluiUtilizatorul uman nu este o maşină, iar această cerinţă de toleranţă este cât se

poate de naturală. De multe ori însă, greşelile de operare pot avea efecte irecuperabile. De exemplu, ştergerea unui fişier, efectuată din greşeală, sub imperiul grabei, oboselii sau pur şi simplu din neatenţie. O astfel de greşeală are efecte neplăcute asupra moralului utilizatorului, mai ales când nu există vreo posibilitate de recuperare.

Când discutăm această cerinţă trebuie să plecăm de la premisa că utilizatorul obişnuit poate face frecvent greşeli, mai ales la început, atât accidentale, cum ar fi apăsarea neintenţionată a unei taste, cât şi de judecată. O bună interfaţă utilizator trebuie să înţeleagă gama de erori potenţiale pe care utilizatorul este capabil să le comită şi să aibă prevăzute posibilităţi de recuperare din astfel de situaţii nedorite. Ea trebuie să atenţioneze utilizatorul în situaţiile (provocate prin comenzile pe care acesta le dă) când starea aplicaţiei sau datele cu care acestea operează se pot deteriora. De asemenea, o bună interfaţă utilizator are prevăzute proceduri de recuperare din situaţiile de eroare şi, mai mult, face acţiunile reversibile.

Este un adevăr că învăţarea prin descoperire este una dintre principalele modalităţi prin care se învaţă folosirea unei noi aplicaţii. Tocmai în faza de învăţare numărul de greşeli pe care le face utilizatorul novice este mai mare. De aceea poate că această observaţie are şi o utilitate: interfaţa să fie testată, în faza de proiectare a acesteia, tocmai de către utilizatori novici, complet străini de informatică şi de aplicaţia realizată.

(8) Atenţie acordată limitelor umaneUtilizatorul uman nu este o maşină, un automat. Pe lângă dispoziţia sufletească

schimbătoare, fiecare individ are o anumită capacitate de înţelegere, memorare şi gândire. Cerinţa aceasta statuează că programul, aplicaţia, trebuie să ţină cont de limitele umane, să le înţeleagă şi să le respecte. Acele aplicaţii care forţează depăşirea limitelor umane normale nu au succes la publicul larg.

Cu alte cuvinte, aplicaţia nu trebuie să constrângă utilizatorul la: efectuarea de calcule manuale memorarea unor secvenţe lungi de comenzi sau operaţii pentru realizarea

unei acţiuni memorarea unor prescurtări criptografice pentru denumirile acţiunilor Se recomandă ca toate opţiunile aplicaţiei să fie prezentate explicit, într-o

manieră ierarhică. Un rol important îl joacă, de asemenea, caracteristicile vizuale ale interfeţei, având în vedere constatarea că recunoaşterea elementelor de interfaţă este mai importantă decât memorarea acestora.

(9) Adaptare progresivă

209

La proiectarea interfeţei utilizator trebuie găsit un echilibru între două criterii contradictorii:

maximizarea funcţionalităţii aplicaţiei şi minimizarea complexităţii aplicaţiei. Adaptarea progresivă implică două aspecte: organizarea atentă a informaţiei din interfaţă, evitând aglomerarea acesteia

pe un singur ecran prezentarea fiecărei informaţii la momentul potrivit; când nu este nevoie

de ea, informaţia se ascunde. O bună interfaţă va prezenta informaţia într-o manieră ierarhică. De exemplu,

informaţia de control (comenzile disponibile ale aplicaţiei) se înglobează, de obicei, în meniuri.

Denumirile meniurilor trebuie să fie sugestive pentru gama de opţiuni grupate în fiecare meniu.

În funcţie de contextul de utilizare, o parte dintre opţiunile unui meniu, indisponibile la un moment dat, se pot ascunde sau inhiba. La proiectarea meniurilor trebuie însă avut în vedere şi un alt aspect: sunt contraindicate prea multe niveluri de submeniuri, deoarece utilizatorul este forţat să ţină minte prea multe comenzi cu care ajunge la o anumită opţiune.

De regulă, comenzilor de meniu mai frecvent folosite li se asociază butoane, tocmai în ideea ca accesarea acestor comenzi să se facă cât mai simplu.

(10) MetodologieRegulile sau cerinţele enumerate sunt necesare, însă nu şi suficiente pentru

proiectarea interfeţei utilizator.

Atenţie!Activitatea de proiectare a interfeţei trebuie să aibă în centrul ei utilizatorul.Pe toată durata proiectării interfaţa trebuie gândită de pe poziţia utilizatorului şi

alături de acesta.

Astăzi, sistemele de dezvoltare rapidă de aplicaţii permit proiectarea rapidă a interfeţelor - este bine ca acestea să fie realizate implicând direct utilizatorii (cunoscuţi sau potenţiali) în realizarea primelor versiuni. În acest fel, utilizatorul devine parte a procesului de proiectare, şi acest lucru poate contribui esenţial la o mai bună receptare a aplicaţiei pe piaţă.

210

9. REALIZAREA PROGRAMELOR9.1. Definirea etapei, conţinut şi caracteristici

Realizarea programelor sau activitatea de programare este o etapă deosebit de importantă în ciclul de viaţă al unui sistem informatic, chiar dacă denumirea ei nu apare în clar menţionată, ci doar se subînţelege atunci când spunem realizarea efectivă a sistemului sau construirea sistemului.

Activităţile care se desfăşoară în legătură cu elaborarea programelor pot fi enumerate astfel:

a) Analiza şi însuşirea documentaţiei tehnice de realizareb) Proiectarea programuluic) Programarea, codificarea sau scrierea propriu-zisă a programuluid) Testarea programului realizate) Realizarea documentaţiei corespunzătoare

a). Analiza şi însuşirea documentaţiei tehnice de realizareAm văzut că încă din faza proiectării de ansamblu se realizează, utilizând

tehnica top-down, structurarea sistemului pe elemente componente – subsisteme – şi a acestora în componentele specifice – aplicaţii informatice. Mergând mai departe cu structurarea, pe nivelul 4 identificăm procedurile, ca elemente componente ale aplicaţiilor informatice. Mai ştim că în cadrul unui sistem informatic acestea pot fi: manuale, mecanizate sau complet automate.

În cadrul proiectării logice de detaliu se face descompunerea fiecărui subsistem sau aplicaţie în proceduri, iar proiectarea şi descrierea acestora se realizează practic în etapa proiectării tehnice de detaliu. Fiecare procedură va fi definită prin caracteristicile sale:- denumire, scop;- funcţiuni realizate;- intrări, ieşiri şi legături cu alte proceduri, aplicaţii, subsisteme sau sisteme;- datele folosite;- prelucrări, algoritmi de rezolvare, modele utilizate, reguli de validare;- scheme funcţionale şi de prelucrare;- modalităţi de intrare şi ieşire din procedură;- locul în cadrul subsistemului ;- mod de exploatare. Toate aceste specificaţii tehnice sunt precizate în cadrul proiectului tehnic de

detaliu, pentru fiecare procedură în parte. Odată ce au fost definitivate tipurile de proceduri, se trece la decuparea celor automate în unităţi de programe independente, denumite module. Apare astfel în structura sistemului nivelul 5 de detaliere, modulul.

b). Proiectarea programului

211

Creşterea complexităţii programelor, diversitatea funcţiunilor pe care trebuie să le realizeze acestea, cerinţele ridicate faţă de calitatea acestora, au impus necesitatea abordării sistematice a activităţii de proiectare a programelor. Dacă în etapa de proiectare se descrie soluţia sub forma unei reprezentări abstracte, programarea va schimba această reprezentare într-o formă care poate fi executată pe un calculator real. Cu alte cuvinte, proiectarea programului oferă o viziune din exterior asupra componentelor programului, asigurând descompunerea acestuia în module, subprograme sau proceduri independente, logica de înţănţuire a acestora, corectitudinea descompunerii şi definirii lor.

Modularitatea, ca atribut general al oricărui sistem, permite ca funcţiile logice să poată fi grupate şi apoi subgrupate cât mai independent, în module sau proceduri automate ce vor fi concretizate apoi în programe sau module independente.

Programarea modulară reprezintă un concept care permite efectuarea programării pe module sau subprograme cu următoarele caracteristici:- un singur punct de intrare;- un singur punct de ieşire;- îndeplinesc o funcţie perfect definită;- sunt apelate printr-o instrucţiune sau interfaţă standard;- oferă posibilitatea de compilare şi testare independentă.Transferul datelor necesare fiecărui modul se realizează printr-un modul

monitor sau zonă comună de date.Avantajele programării modulare pot fi:- concepţia este uşoară, clară;- descompunerea se face pe module funcţionale;- scrierea şi testarea pe module este uşoară iar programatorii sunt mai

eficient utilizaţi;- se facilitează exploatarea şi întreţinerea lor, dar şi a aplicaţiei sau

subsistemului care le conţine;- timpul de realizare se poate aprecia mai bine şi se reduce considerabil.O altă formă a programării, cea denumită programarea structurată presupune

existenţa unei concepţii bazate pe o schemă arborescentă a programelor, pe blocuri sau componente, dublată de o structurare clară a datelor utilizate. Se numeşte factorizare procesul de descompunere a programului într-o ierarhie de module, obţinând astfel diagrama de structură a programului. Totdeauna va exista, în cadrul unei astfel de structuri de programe, un modul central, aflat la nivelul cel mai înalt şi o ierarhie de module funcţionale, între care se precizează integral legăturile. În acest caz, proiectarea şi dezvoltarea modulelor, care au aceleaşi caracteristici principale ca şi la programarea modulară, se face într-o abordare top-down. Urmează apoi integrarea acestora, în mod treptat, pe măsura realizării modulelor şi interfeţelor.

212

Un program are un grad mai ridicat de modularitate cu cât părţile sale (modulele) sunt mai independente. O modularitate ridicată a programului se obţine prin minimizarea relaţiilor între module şi maximizarea relaţiilor între elementele modulului. Pentru minimizarea relaţiilor dintre module se utilizează conceptul de cuplare, iar pentru maximizarea relaţiilor dintre elementele unui modul conceptul de coeziune.

Cuplarea defineşte gradul de interconectare între module. Cu cât ea este mai slabă, deci relaţiile dintre module sunt mai puţine, cu atât modularitatea programului este mai mare. În realizarea unui program s-au identificat în literatura de specialitate şase tipuri de cuplare şi anume:- cuplare prin date – ceea ce înseamnă că toate comunicaţiile între module

se fac prin elemente de date;- cuplare prin structură de date – atunci când comunicaţia între module

include un parametru care face referire la o structură de date;- cuplare prin control – atunci când comunicaţia între module include un

parametru transmis de un modul prin care se controlează fluxul controlului din alt modul;- cuplare externă – atunci când comunicaţia între module se face printr-un

element de date declarat extern;- cuplare prin zonă comună – atunci când comunicaţia între module se face

printr-o referinţă la o structură de date declarată extern;- cuplare prin conţinut – atunci când comunicaţia între module se face

printr-o referinţă la conţinutul altui modul.

Coeziunea defineşte gradul de legătură funcţională între elementele componente ale unui modul, înţelegând prin elemente componente: instrucţiuni, un segment sau o parte din modul.

În mod normal, în proiectarea propriu-zisă a unui program se porneşte de la o factorizare iniţială, reprezentată prin diagrama de structură a programului, care pune în evidenţă modulele programului şi interfeţele dintre acestea. Aceasta va avea un modul principal sau de control al aplicaţiei, care va apela modulele imediat subordonate, acestea la rândul lor apelând alte module cărora le transmit date şi de la care aşteaptă rezultate. Toate aceste apeluri sunt incluse în cadrul modulelor în diferite structuri de decizie, iterative sau secvenţiale.

În funcţie de modul cum este realizată conexiunea între modulele unui program putem avea:

Conexiune normală sau secvenţială (fig. 9.1), când în modulul A există o referinţă la modulul B, astfel încât B este un modul subordonat modulului A.

Fig. 9.1.

213

A

B

Conexiune prin flux de informaţii (fig. 9.2.) când modulul B este subordonat modulului A de la care primeşte datele x şi y şi căruia îi transmite parametrul z.

x,y z Fig 9.2.

Conexiune de tip iteraţie (fig 9.3) când referinţa la modul este inclusă într-o buclă. Modulul B se execută în mod repetat prin apelarea sa de către modulul A.

Fig. 9.3.

Conexiune de tip decizie (fig. 9.4) când referinţa la modul este inclusă într-o structură de tip decizie. În funcţie de rezultatul unei decizii (a testării unei condiţii) va fi apelat fie modulul B fie modulul G.

Fig. 9.4

c). Programarea sau codificarea programelor reprezintă activitatea prin care se scriu efectiv programele sursă, utilizând un limbaj de programare. Un program este o listă de instrucţiuni prin care se descrie un algoritm concret de rezolvare a unei probleme date. El se poate constitui ca program, modul sau procedură independentă. Scrierea programelor se face deci într-un limbaj de programare. Adeseori acesta este impus (de beneficiar, de echipa de programatori, de conjunctură), dar alteori el trebuie ales în etapa de proiectare tehnică. Funcţie de modalitatea de structurare a datelor, de caracteristicile modelelor matematice utilizate, de specificul problemei, de algoritmii de calcul ce trebuie descrişi, de modalităţile de prezentare a situaţiilor de ieşire, se poate opta pentru limbajul de programare care răspunde cel mai bine problematicii noastre.

În această etapă se pune accent pe detalierea internă a componentelor, pe asigurarea eficacităţii algoritmilor de prelucrare, pe optimizarea acestora. Formularea corectă şi completă a algoritmului de rezolvare trebuie să fie urmată de realizarea schemei logice a fiecărui modul în parte.

214

A

B

A

B

A

B G

Se poate face apel la tehnici moderne de programare, la generatoare automate de rapoarte, meniuri, formulare.

O proiectare structurată, modulară a programului va duce şi la o structură modulară a programului efectiv obţinut.

d). Testarea programelor reprezintă o activitate importantă, ce poate fi realizată atât de fiecare programator, cât şi de personal specializat, care coordonează întreaga activitate.

Cei care răspund de această activitate stabilesc standardele testării, planifică testarea şi se preocupă de încadrarea întregii activităţi de testare în ciclul de viaţă al sistemelor.

Se impune o testare a fiecărui modul (procedură) în parte, urmată apoi de integrarea lor în programul final şi testarea acestuia.

Problema testării unui program este în strânsă dependenţă cu complexitatea acestuia, de corectitudinea şi completitudinea testării depinzând evaluarea programului respectiv.

Se ştie că un program descrie, de regulă, pentru prelucrarea automată a datelor, un algoritm de rezolvare a unei probleme date şi că, la rândul său, algoritmul exprimă în mod explicit şi neambiguu calea de rezolvare a unei probleme.

Corectitudinea reprezintă o condiţie indispensabilă a oricărui algoritm şi, în cadrul prelucrării automate a datelor, a oricărui program. Este de la sine înţeles că un program incorect nu este utilizabil în scopul pentru care a fost creat.

Un program realizat trebuie să fie deci corect, clar, sigur în funcţionare, uşor de modificat, portabil, eficient, însoţit de o documentaţie corespunzătoare, etc.

În literatura de specialitate sunt prezentate, în acest sens, numeroase tehnici de verificare şi validare a algoritmilor, adresate în principal practicienilor, dar şi cu elemente de fundamentare teoretică uşor accesibile unui începător în programare. Dintre aceste tehnici, metode, amintim următoarele:

testarea programelor şi depanarea programelor verificarea formalizată a programelor cea mai slabă precondiţie cea mai tare postcondiţie instrucţiuni generalizate Sintaxa expresiilor logice, etc

Acţiunea de testare a programelor se deosebeşte de celelalte faze prin care trec acestea (proiectare, programare, documentaţie, etc.) prin caracterul ei în aparenţă “demolator”. Astfel, în timp ce alte faze au o esenţă constructivă, testarea are în aparenţă un caracter distructiv, deoarece scopul ei este de pune în evidenţă proasta funcţionare a programului, de a găsi hibele acestuia şi nu părţile sale bune. Din punct de vedere psihologic, programatorul însuşi trebuie să adopte în această

215

etapă o atitudine “duşmănoasă” faţă de propriul program, pentru a putea găsi defectele acestuia.

Analizînd problema mai atent, realizăm de fapt că scopul testării este în realitate tot constructiv, acela de a pune în funcţiune un program care să funcţioneze la parametri prevăzuţi.

Se ştie că, într-un algoritm de calcul şi deci, într-un program, este oricând posibilă prezenţa unei/unor erori, oricât de precisă şi laborioasă ar fi metodologia de elaborare. Procesul de detectare şi apoi de eliminare a erorilor unui program are două componente, numite:

verificare validareAceste două activităţi ar trebui să caracterizeze practic toate etapele prin care

trece un program, de la formularea cerinţei de rezolvare a unei probleme, la analiza acesteia, la identificarea şi apoi descrierea algoritmului de rezolvare a problemei, a codificării datelor şi validarea rezultatelor obţinute.

Aceasta deoarece tot mai mulţi specialişti din diferite domenii arată că această activitate de testare şi validare nu este specifică doar activităţii de programare, ci se întâlneşte pretutindeni, acolo unde se produce sau se construieşte ceva; există în acest sens controale efectuate la nivelul fiecărei operaţii sau grup de operaţii, după cum există şi un control final, al produsului finit, pentru realizarea recepţiei lui finale.

e). Elaborarea documentaţieiDacă un program a fost proiectat, scris, apoi testat şi depanat se trece la

realizarea documentaţiei aferente: - Manual de prezentare;- Manual de utilizare;- Manual de exploatare.Aceste documentaţii vor fi actualizate, modificate şi completate, după caz, în

etapa care urmează în viaţa unui sistem informatic sau aplicaţie informatică, şi anume implementarea acestuia/acesteia.

9.2. Tehnici de testare a programelor

Prin testarea programului se înţelege deci executarea programului respectiv cu scopul de a descoperi eventuale anomalii sau erori. Ea se bazează pe construirea unor eşantioane de date de intrare care să conducă la depistarea unor erori în funcţionarea programului, într-un timp cât mai scurt şi cu efort cât mai mic.

În acest sens, activitatea de verificare şi validare a unui produs program urmăreşte în principal, următoarele:

descoperirea defectelor programului

216

certificarea faptului că programul va funcţiona corect în condiţii de exploatare curentă

Practic, verificarea (testarea) programului urmăreşte dacă programul a fost construit bine, dacă este compatibil cu cerinţa iniţială, iar validarea controlează dacă programul respectiv este bun, dacă îndeplineşte condiţiile cerute de beneficiar.

Tehnicile pentru testarea şi validarea programelor pot fi: dinamice statice

Tehnicile dinamice de verificare şi validare constau în experimentarea programelor în condiţii asemănătoare cu cele din exploatarea curentă, reală, pentru a verifica dacă acestea îndeplinesc toate condiţiile cerute de prelucrare. Acest experiment efectuat asupra programului se numeşte testarea programului şi înseamnă deci executarea propriu-zisă a programului respectiv.

Tehnicile statice de verificare şi validare constau în analiza şi examinarea atentă a codului programului pentru a depista eventuale anomalii, a documentaţiei, a metodologiei de proiectare utilizată, pentru a putea aprecia funcţionarea corectă a programului.

Observaţie :Procesul de testare a unui program poate semnala existenţa unor erori care vor

trebui apoi corectate. Dar, lipsa semnalării unor erori în testarea unui program nu garantează absenţa lor. Acest lucru este posibil datorită faptului că, în general, nu pot fi testate toate situaţiile (cazurile) posibile în exploatarea curentă, deci, testarea este, prin natura sa, incompletă. Dacă ţinem seama de aceste considerente, vom putea privi fiecare test al unui program ca fiind neconcludent dacă nu a evidenţiat o eroare, nerelevant, căci nu a solicitat îndeajuns programul

Deasemenea, analiza programului fiind o activitate umană este predispusă la erori, ca orice activitate umană şi deci nu poate garanta corectitudinea finală a programului.

De aceea se recurge adesea la metode formalizate, care pot conduce la depistarea în mai mare măsură a erorilor unui program. Metodele matematice de verificare pot fi utilizate cu succes numai dacă există definiţii precise ale semanticii limbajului de programare folosit.

Şi totuşi, testarea programului rămâne metoda de bază pentru verificarea corectitudinii unui program, succesul ei fiind condiţionat în primul rând de experienţa programatorului, de complexitatea şi completitudinea setului de date folosite în procesul testării, de analiza riguroasă, atentă a rezultatelor obţinute în urma fiecărui test.

217

Practic, pornind de la nişte date de test construite de el, programatorul aşteaptă să obţină la final sau pe parcurs, anumite rezultate. Dacă acestea nu sunt corecte, complete sau în formatul aşteptat avem cel puţin o eroare în execuţia programului. Putem spune că succesul testării depinde de “arta” programatorului de a-şi construi setul de date de test.

Observaţie :Relevanţa testului depinde de numărul eşantioanelor de date de test, dar mai

ales de calitatea datelor alese.

În acest sens, au apărut, în ultimul timp, o serie de metode de elaborare a datelor de test, care ajută programatorul, oferindu-i posibilitatea de a aborda sistematic activitatea de testare a programelor, cu o probabilitate crescută de depistare a erorilor.

Aceste metode pot fi denumite: testarea funcţională sau metoda cutiei negre, care presupune construirea

datelor de test astfel încât să permită testarea fiecărei funcţiuni a programului; testarea structurală sau metoda cutiei transparente, care presupune

construirea datelor de test astfel încât toate părţile programului să poată fi testate.

Metoda cutiei negre presupune testarea funcţiunilor programului cu ajutorul datelor de test. În acest caz succesul activităţii de testare constă în conceperea unor date de intrare prin prelucrarea cărora defectele algoritmului şi deci şi ale programului să fie puse în evidenţă prin observarea şi analiza rezultatelor obţinute.

De aceea el este în mare măsură dependent de experienţa şi îndemânarea programatorului, de abilitatea lui de a-şi construi datele de test cât mai complete, complexe, cuprinzătoare din punct de vedere al situaţiilor sau valorilor de excepţie ce pot apare în execuţia curentă a programului.

Astfel, sunt luate în considerare trei categorii de date de intrare pentru testarea programului, şi anume:

a). datele tipice de intrare (normale);

b). datele atipice (netipice);c). datele ilegale, care nu aparţin domeniului. Un aspect deosebit în acest sens îl reprezintă considerarea valorilor netipice ale

domeniului datelor de intrare, numite adeseori valori “de la marginea domeniului”. Astfel, vom acorda o atenţie deosebită în testarea programului modului în care aceste valori sunt sau nu tratate şi a corectitudinii rezultatelor obţinute. Ca exemplu, la parcurgerea şi prelucrarea unui şir de n elemente, vom urmări în mod deosebit prelucrarea primului şi a ultimului element, pentru a nu fi omise sau incorect prelucrate. La prelucrarea unui fişier, primul şi ultimul articol

218

prelucrat trebuie să stea în atenţia noastră, în mod special, pentru a nu fi omise sau incorect prelucrate.

Atunci când, în urma testării se identifică o eroare de program (de algoritm de prelucrare) se impune analiza cauzelor care provoacă funcţionarea necorespunzătoare a programului şi eliminarea acestora. Această activitate se numeşte depanarea programului, şi este urmarea imediată şi firească a unui test concludent, care a evidenţiat o anomalie în funcţionarea programului, vizibilă în neconcordanţa rezultatelor aşteptate cu cele obţinute prin execuţia programului.

Metoda cutiei transparente, care completează cu succes strategia de testare a metodei cutiei negre, presupune examinarea laborioasă a detaliilor programului, a instrucţiunilor şi datelor. Dificultăţile decurg din existenţa, în programe, a instrucţiunilor de decizie (if, case), a celor iterative (while, for, repeat) sau a celor de transfer al controlului de program (go). Toate acestea determină un număr mare de combinaţii în care instrucţiunile elementare ale programului (de calcul, de citire, de scriere, de atribuire sau de apel de proceduri) pot fi executate. Ideal ar fi atunci ca în procesul testării să poată fi executate (solicitate) toate aceste combinaţii de comenzi. Ori, practica dovedeşte că, cel puţin în cazul programelor complexe (nu neapărat mari ca dimensiune), acest lucru este adeseori imposibil. De aceea intervine experienţa, îndemânarea şi intuiţia programatorului în realizarea eşantioanelor de date de test care trebuie să asigure cel puţin testarea combinaţiilor considerate mai importante.

Există o serie de criterii, numite criterii de acoperire, care pot sta la baza stabilirii numărului de combinaţii de comenzi testate efectiv. Acestea ar putea fi:

acoperirea tuturor instrucţiunilor, care înseamnă de fapt că la testare pentru fiecare instrucţiune elementară a programului, trebuie să existe un eşantion de date care să provoace executarea sa;

acoperirea tuturor arcelor, care cere ca testul să fie astfel construit, încât pentru orice arc din graf să existe eşantioane care să provoace parcurgerea arcului la executarea programului; criteriul are calitatea că impune alegerea unui test care să provoace evaluarea fiecărei condiţii cel puţin o dată, atât cu rezultatul de Adevărat, cât şi cu Fals.

acoperirea tuturor condiţiilor simple, care cere ca testul să acopere toate arcele şi să asigure evaluarea tuturor condiţiilor simple atât cu rezultatul Adevărat cât şi cu Fals ; criteriul este practic echivalent cu acoperirea tuturor arcelor, dacă programul conţine doar condiţii simple, în care nu apar operatorii logici And sau Or.

acoperirea tuturor drumurilor, care cere ca pentru fiecare drum al grafului de control, testul să conţină eşantioane prin prelucrarea cărora executarea programului să urmeze drumul ales în mod normal; criteriul acesta este mai tare decât toate celelalte.

219

Testarea unui program trebuie să se finalizeze, pentru a fi utilă, cu semnalarea erorii şi localizarea ei. De aceea, testarea programului este urmată de depanarea lui.

Depanarea unui program constă în localizarea erorii, determinarea naturii sale şi corectarea ei. Ea se poate face în mod:

static, după executarea programului; dinamic, în timpul execuţiei acestuia.Depanarea statică se poate face prin mai multe metode, dintre care mai

utilizată este cea denumită “storage dump”, care presupune analiza conţinutului locaţiilor de memorie, afişate de sistem în sistem de numeraţie hexazecimal sau octal. Este o metodă destul de dificil de utilizat.

Depanarea simbolică, o altă metodă de depanare, este mai uşor de utilizat, deoarece oferă posibilitatea de a urmări executarea programului la nivel de limbaj sursă. Limbajele de programare oferă, în ultimile lor versiuni, un depanator simbolic integrat, care permite depanarea uşoară, plăcută şi eficientă a programelor prin următoarele operaţii:

executarea pas cu pas a programului (un pas înseamnă de fapt o instrucţiune executabilă);

observarea, în timpul execuţiei, a valorilor unor variabile sau expresii specificate de programator (care apar într-o fereastră specială - Watch Window);

specificarea unor puncte de suspendare a execuţiei programului; modificarea valorilor unor variabile.În activitatea de testare şi depanare a programelor, erorile datorate variabilelor

neiniţializate sunt greu de semnalat şi de localizat, mai ales atunci cînd aparent totul funcţionează corect. În acest sens putem vorbi de variabila cu rol de indice (numărător) care asigură parcurgerea elementelor unui vector, de expresia care stabileşte dacă un ciclu se execută sau nu, aşa cum necesită algoritmul de prelucrare descris; este vorba de controlul acestei condiţii, de tipul ciclului – cu testarea iniţială sau finală a condiţiei, etc.

Verificarea formalizată a programelor

Practica a dovedit, în timp, că oricât de numeroase ar fi testele efectuate asupra unor programe foarte complexe, ele nu pot garanta funcţionarea corectă a acestora. Ele rămân deosebit de utile pentru semnalarea multora dintre erori şi deasemenea pentru familiarizarea programatorului cu algoritmul, cu modul său de lucru.

Există o serie de metode de esenţă matematică, venite în completarea metodelor de testare şi depanare a programelor, care pot demonstra, pentru un program, că:

220

Procesul de prelucrare şi calcul se termină în timp finit pentru orice date din domeniul specificat în enunţul problemei;

După terminarea procesului de calcul, datele de ieşire oferă soluţia problemei pentru care a fost creat respectivul algoritm.

Metodologia a fost elaborată de informaticienii R.W.Floyd, C.A.R.Hoare, E.W. Dijkstra şi are la bază analiza, instrucţiune după instrucţiune, a întregului text sursă al programului. Acesta trebuie să fie însoţit de comentarii cu privire la datele de intrare, la rolul variabilelor, la proprietăţile datelor de ieşire, la funcţiunile procedurilor sau secvenţelor de program luate în discuţie.

Corectitudinea instrucţiunilor simple de program se stabileşte foarte uşor. Probleme de testare apar îndeosebi atunci când avem de a face cu algoritmi complecşi; dacă aceştia sunt descompuşi, pe baza unor reguli precise, în elemente simple constitutive, uşor de testat, atunci problema poate fi mai uşor rezolvată.

Iată deci că nu numai proiectarea şi scrierea efectivă a programelor necesită o realizare structurată, modulară ; testarea şi depanarea unui program complex necesită deasemenea descompunerea lui, a problemei complexe pe care o descrie, în elemente simple, constitutive care vor fi ulterior asamblate şi testate ca un produs program unitar.

221

10. IMPLEMENTAREA SISTEMELOR INFORMATICE şi a produselor refolosibile

Implementarea reprezintă acea etapă de realizare a sistemelor informatice în care se asigură testarea cu date reale, definitivarea şi punerea în funcţiune a sistemului proiectat.

Principalele obiective ale etapei de implementare sunt: experimentarea sistemului proiectat; finisarea noului sistem; punerea în funcţiune; recepţia sistemului informatic proiectat.

Obiectivele pe care trebuie să le realizeze implementarea unui sistem sau a unei componente de sistem informatic fac ca momentul punerii în funcţiune să se identifice cu momentul trecerii în exploatare a componentei sau sistemului respectiv. După momentul punerii în funcţiune nu mai este permisă întreruperea exploatării curente a componentei sau sistemului respectiv, căci orice întrerupere înseamnă în acest caz nereuşita acestei acţiuni.

Principalele grupe de activităţi care trebuie realizate în etapa de implementare sunt următoarele:

- Asigurarea condiţiilor de implementare;- Executarea procedurilor de conversie a colecţiilor de date, dacă este cazul;- Testarea şi implementarea procedurilor manuale, mecanizate şi

automatizate;- Verificarea performanţelor sistemului realizat;- Definitivarea documentaţiei sistemului realizat;- Omologarea şi recepţionarea sistemului realizat.

1. Asigurarea condiţiilor de implementare a sistemului proiectat Implementarea sistemului informatic proiectat depinde în mod hotărâtor de

modul în care beneficiarul asigură condiţiile de implementare şi punere în funcţiune.

Aceasta este o activitate complexă, care cuprinde o serie de activităţi, cum sunt:

Difuzarea instrucţiunilor de executare a procedurilor manuale, mecanizate şi automatizate

Aceste instrucţiuni se pot grupa în două mari categorii, şi anume:o Instrucţiuni pentru beneficiar, care trebuie să ofere acestuia posibilitatea

să cunoască procedurile manuale sau automatizate pe care trebuie să le execute. În acest sens, documentaţia anexată trebuie să facă o prezentare a aplicaţiei şi fluxurilor informaţionale, a rapoartelor şi machetelor de introducere şi validare date, etc

222

o Instrucţiuni pentru unitatea de prelucrare, colectiv informatică sau oficiu de calcul, care trebuie să cunoască modalitatea de primire/predare a documentelor primare şi rapoartelor obţinute, procedurile de validare a datelor, de reluare în caz de incident, modalităţile concrete de operare pe fluxul prelucrărilor.

Instruirea personalului utilizator presupune, pentru reuşita implementării, următoarele activităţi :o Sensibilizarea beneficiarului în probleme de informatică, cu scopul de a

aduce la cunoştinţa acestuia posibilităţile şi avantajele tehnicii de calcul, dar şi ordinea şi disciplina informaţională impusă de aceasta. Ea se poate face prin cursuri de iniţiere de scurtă durată organizate de proiectant la sediul dorit.o Atragerea personalului cu putere de decizie în activitatea de implementare

este necesară ca o garanţie pentru asigurarea la timp şi integrală a condiţiilor necesare implementării sistemului realizat. o Pregătirea psihologică a personalului unităţii beneficiare, care nu trebuie

să-şi simtă ameninţat postul de introducerea prelucrării automate a datelor Asigurarea condiţiilor organizatorice necesare Condiţiile organizatorice necesare implementării noului sistem se referă în

primul rând la asigurarea transpunerii în practică a modificărilor organizatorice preconizate în etapa de proiectare, la utilizarea efectivă a documentelor proiectate şi la instituirea noilor fluxuri informaţionale. Deasemenea se impune constituirea colectivului de informaticieni în cadrul unităţii beneficiare, care să preia şi să dezvolte aplicaţia. Este necesară apoi planificarea activităţilor specifice acestei etape, care se poate face cu ajutorul unor grafuri Gantt, a metodei ADC, PERT. Activităţile se pot planifica în condiţiile stabilirii resurselor materiale şi de timp ale utilizatorului, precum şi a modului cum este condiţionată succesiunea activităţilor.

Asigurarea resurselor hard O condiţie esenţială a implementării sistemului proiectat o constituie asigurarea

capacităţii de calcul necesare, care poate fi realizată prin dotarea unităţii beneficiare cu unul sau mai multe sisteme de calcul. Se impune deasemenea asigurarea unui spaţiu corespunzător desfăşurării activităţii de informatică, care să permită realizarea unor lucrări de calitate, asigurarea integrităţii, securităţii şi confidenţialităţii fondului de date manipulat precum şi asigurarea multiplicării documentelor primare reproiectate. Este importantă de asemenea asigurarea materialelor consumabile specifice funcţionării sistemelor informatice .

Asigurarea fondului informaţional Acest lucru presupune pregătirea datelor reale şi încărcarea fişierelor sau bazei

de date în vederea testării şi punerii în funcţiune a noului sistem. Aceasta se face prin:o constituirea fişierelor sau entităţilor bazei de date;

223

o culegerea fondului informaţional necesar şi stocarea acestuia pe purtători tehnici de informaţie, prin proceduri de culegere şi validare a datelor;o preluarea parţială sau integrală a datelor dintr-o serie de fişiere existente,

cu ajutorul unor programe de conversie special realizate, dacă efortul şi timpul necesar justifică această operaţie.

2. Executarea procedurilor de conversie Executarea unor astfel de proceduri se face dacă există un sistem

informatic sau aplicaţii informatice în funcţiune, care trebuie înlocuite sau pentru realizarea legăturilor funcţionale dintre acestea, dacă se impun conversii de fişiere, de programe sau de proceduri.

3. Testarea şi implementarea procedurilor manuale şi automatizate Activitatea de testare cu date reale a aplicaţiei sau sistemului proiectat este o

activitate deosebit de complexă, cu urmări directe asupra desfăşurării activităţii curente din cadrul societăţii. De aceea, ea se poate face prin strategii diferite, cum sunt:

implementarea în paralel cu date curente, care presupune funcţionarea concomitentă a vechiului sistem de evidenţă manual cu cel automat. În acest caz, avem de a face cu două evidenţe în acelaşi timp, care necesită un efort deosebit din partea personalului implicat, ţinând cont de faptul că acesta trebuie să asigure datele de intrare şi să verifice rezultatele obţinute pentru ambele evidenţe. De aceea, în mod normal, se recomandă scurtarea pe cât posibil a acestei etape. Avantajul constă însă în faptul că se pot testa cu date reale toate procedurile, modulele, algoritmii de calcul, situaţiile de excepţie care pot apare, cerinţele de informare ale conducerii, etc.

implementarea în paralel cu seturi de date din perioada anterioară, mai uşor de acceptat pentru conducerea unei societăţi, deoarece permite simularea noului sistem, depistarea şi înlăturarea deficienţelor sale înainte de renunţarea la vechiul sistem de evidenţă. Dezavantajul constă însă în faptul că implică o muncă dublă din partea personalului implicat, pe de o parte, şi se poate prelungi în timp mai mult decât ar dori proiectantul.

implementarea directă sau imediată, care constă în renunţarea imediată la vechiul sistem de evidenţă şi înlocuirea lui cu cel nou. Acest mod de implementare este riscant pentru beneficiar, dar foarte eficient pentru proiectant.

Alegerea strategiei de implementare depinde de o multitudine de factori, cum ar fi: gradul de cuprindere şi de complexitate al prelucrărilor, pregătirea beneficiarului, gradul de implicare al acestuia pe tot parcursul proiectării şi realizării noului sistem, volumul şi diversitatea datelor prelucrate, mulţimea surselor de culegere a datelor, etc.

224

În aceste condiţii, indiferent de strategia de implementare adoptată, se pot utiliza tactici diferite, cum sunt:

implementarea simultană a tuturor componentelor (aplicaţiilor), care necesită o pregătire şi un efort mai mare din partea proiectantului şi a beneficiarului, dar reduce considerabil timpul de implementare. Ea presupune şi un risc crescut pentru beneficiar.

implementarea în serie a componentelor sistemului proiectat, care reduce riscul pentru utilizator, dar creşte considerabil perioada de implementare.

implementarea mixtă sau combinată, care presupune implementarea simultană pentru unele componente cu risc mai mic şi paralelă pentru altele, funcţie deci de complexitatea şi specificul sistemului proiectat.

În momentul în care sistemul proiectat răspunde cerinţelor de testare, se pune problema punerii lui în funcţiune, în vederea intrării în exploatare curentă. Responsabilitatea pentru testarea şi punerea în funcţiune a unui sistem informatic revine unor factori deosebiţi de importanţi, cum sunt:

Conducerea unităţii beneficiare a sistemului informatic. Aceasta are principala răspundere pentru asigurarea condiţiilor organizatorice necesare punerii în funcţiune a sistemului informatic, pentru asigurarea numărului şi calităţii personalului necesar, a informaţiei supuse prelucrării şi a celorlalte categorii de resurse necesare;

Proiectantul sistemului informatic. Acesta răspunde în principal de calitatea proiectului, respectiv de performanţele sale tehnico-funcţionale şi economice în concordanţă cu sarcinile stabilite de beneficiar, de execuţia remedierilor şi completărilor stabilite de beneficiar, de instruirea tehnică a personalului implicat în noul sistem şi de asistenţa tehnică pentru punerea în funcţiune.

Reprezentantul colectivului de informatică sau a colectivului care preia sarcina prelucrării datelor din sistemul informatic. Acesta are sarcina de a organiza procesul tehnologic şi de a executa operaţiile tehnologice de pregătire, arhivare a datelor în concordanţă cu prevederile proiectului, respectiv cu condiţiile impuse de beneficiar în etapele de elaborare a proiectului.

Dacă punerea în funcţiune a sistemului informatic este asigurată de către unitatea beneficiară a sistemului informatic, atunci sarcinile conducerii unităţii respective cresc în mod considerabil, ca urmare a cerinţelor de pregătire a proceselor tehnologice de prelucrare a datelor.

4. Verificarea performanţelor sistemului informatic proiectat

225

Este activitatea în care se verifică gradul în care sistemul informatic proiectat atinge în exploatare parametrii proiectaţi. Această verificare se realizează prin evaluarea rezultatelor obţinute la testarea şi implementarea tuturor produselor informatice, în comparaţie cu cerinţele şi restricţiile formulate în etapa de proiectare.

Se verifică astfel asigurarea condiţiilor necesare pentru exploatarea curentă, în funcţie de soluţia adoptată pentru asigurarea capacităţii de prelucrare, de ritmul de exploatare proiectat, siguranţa în funcţionare, etc. Verificarea performanţelor sistemului proiectat presupune evaluarea şi validarea rezultatelor obţinute prin calculul indicatorilor de eficienţă economică.

5. Definitivarea documentaţiei sistemului proiectat

Etapa de implementare a sistemului informatic se finalizează atunci când noul sistem funcţionează în conformitate cu cerinţele stabilite prin proiect, adică atunci când se realizează corelarea procedurilor manuale şi automate, se completează corect documentele de intrare, se obţin în timp util informaţiile dorite pe toate nivelele de conducere, se atinge ritmul de exploatare şi se obţin performanţele aşteptate.

De aceea, pentru recepţionarea noului sistem de către beneficiar, proiectantul trebuie să elaboreze o documentaţie care să cuprindă pe de o parte o prezentare sumară a sistemului şi a condiţiilor în care s-a desfăşurat implementarea (resurse, arie de cuprindere), iar pe de altă parte evaluarea rezultatelor implementării cu o serie de indicaţii referitoare la trecerea în exploatare curentă şi eventual generalizarea utilizării noului sistem.

Etapa de implementare nu poate fi considerată încheiată dacă nu se definitivează întreaga documentaţie a sistemului, cuprinzând manualele de prezentare şi cele de utilizare şi exploatare. Definitivarea documentaţiei se realizează în paralel cu celelalte activităţi din cadrul etapei de implementare, printr-o strânsă colaborare între beneficiar şi proiectant.

6. Omologarea / recepţionarea sistemului informatic

Omologarea presupune acceptarea în mod oficial, de către beneficiar a sistemului informatic în vederea utilizării sau generalizării lui, în urma verificării modului în care sistemul informatic se încadrează în normele stabilite prin proiect.

Sistemul informatic trebuie să funcţioneze ca un sistem cibernetic complex, având capacitatea permanentă de autoreglare şi de autoperfecţionare, căci altfel, sistemul se autodesfinţează.

Un sistem informatic odată dat în exploatare curentă trebuie să fie permanent îmbunătăţit, întreţinut, completat şi dezvoltat, pentru a răspunde noilor cerinţe de informare ale conducerii, noilor tehnologii ale informaţiei sau modificărilor

226

intervenite în structura organizatorică sau legislaţia ce guvernează domeniul de activitate respectiv.

Dacă aceste modificări sunt majore, se ajunge la necesitatea reproiectării sistemului informatic, care intră astfel într-un nou ciclu de viaţă. În cadrul reproiectării unui sistem informatic unele etape pot lipsi sau pot fi scurtate, datorită experienţei prealabile în domeniu a proiectantului.

În ultimul timp, datorită faptului că tot mai multe domenii de activitate ale oricărei societăţi comerciale au fost informatizate, evoluţia fără precedent a componentelor hardware şi software atrag după sine şi necesitatea reproiectării celor mai multe sisteme informatice, pentru adaptare la noile facilităţi şi performanţe ale acestora.

Dacă ne referim la o unitate hotelieră, existenţa unui site propriu pe reţeaua Internet îi face cunoscută oferta de servicii la scara mondială şi face posibilă rezervarea de locuri de cazare, de excursii şi alte servicii în regim on-line, cu efecte directe asupra activităţii curente şi a profitului obţinut. În aceste condiţii, aplicaţiile de rezervare cazări, recepţie hotelieră şi facturarea corespunzătoare a serviciilor consumate de către clienţi ar trebui reproiectate, ţinând cont tocmai de noile tehnologii informatice, de noile sisteme de gestiune a bazelor de date şi noile limbaje de programare apărute.

227

11. DEZVOLTAREA SISTEMELOR INFORMATICE11.1. Etapizarea activităţilor de proiectare şi reproiectare

Se ştie că orice sistem informatic sau produs program are un ciclu de viaţă propriu, care e declanşat de decizia realizării lui, continuă cu analiza, apoi cu proiectarea şi realizarea lui efectivă, cu punerea în funcţiune, exploatarea şi întreţinerea curentă. Acest ciclu se încheie atunci când sistemul informatic sau produsul program nu mai corespunde cerinţelor pentru care a fost conceput sau se impune o modernizare a acestuia. Ciclul va putea atunci să fie reluat prin decizia realizării unui nou produs sau a dezvoltării sau modernizării sale. Spunem că se trece la reproiectarea sistemului sistemului informatic.

Fie că se pune problema proiectării şi realizării unui sistem informatic nou, fie că se realizează doar reproiectarea, modernizarea celui existent, în practică echipa de proiectare poate întâlni multiple posibilităţi, care se pot încadra în una din următoarele situaţii:

- Proiectarea sistemului se face pentru o societate în care se abordează pentru prima dată introducerea unui astfel de sistem. În acest caz se impune parcurgerea tuturor etapelor de proiectare şi realizare;

- Se proiectează doar unele componente ale sistemului – subsisteme sau aplicaţii, sau se dezvoltă astfel de componente, în condiţiile existenţei unei concepţii generale asupra sistemului. În acest caz se poate trece direct la proiectarea de detaliu –logică şi tehnică – efectuând eventual o revedere şi o actualizare corespunzătoare a documentaţiilor întocmite în fazele anterioare.

- Există unele aplicaţii izolate în funcţiune şi se cere rezolvarea în continuare a unor probleme, fără a exista o analiză de ansamblu a societăţii şi o concepţie unitară asupra sistemului. În acest caz se impune parcurgerea tuturor etapelor, începând cu studiul de oportunitate, urmând să se decidă asupra oportunităţii menţinerii aplicaţiilor existente, respectiv asupra posibilităţilor de integrare a acestora în noul sistem propus.

-Atenţie!Toate acestea fac ca etapele activităţii de proiectare şi realizare a unui sistem

informatic sau produs program să nu se succeadă întotdeauna în secvenţa cunoscută. Astfel, anumite activităţi se întrepătrund, se desfăşoară în paralel, se condiţionează reciproc.

Dacă proiectarea sau reproiectarea solicitată modifică concepţia întregului sistem, deci priveşte legăturile funcţionale dintre componente, platforma hardware, modul de organizare şi administrare a datelor, tehnologia de culegere şi transfer a acestora, atunci se impune reluarea ciclului de la prima sa etapă şi continuarea cu proiectarea de ansamblu a noului sistem. O atenţie deosebită se acordă procedurilor de conversie necesare, mai ales privind colecţiile de date

228

existente. De aceea e bine ca, în cadrul fiecărei etape, funcţie de condiţiile practice concrete de lucru, să se elaboreze grafice de eşalonare a tuturor activităţilor, adaptate permanent la specificul lucrării respective.

11.2. Strategii în dezvoltarea sistemului informatic

Atât în ce priveşte proiectarea şi realizarea iniţială, cât mai ales dezvoltarea unui sistem informatic, funcţie de complexitatea procesului, de cantitatea şi calitatea resurselor implicate pot fi aplicate diferite strategii, cu avantaje şi dezavantaje în raport cu scopul urmărit.

Astfel, în literatura de specialitate se consideră ca strategii de bază în abordarea proiectării sau reproiectării unui sistem informatic cele pe care deja le cunoaştem denumite:

- strategia bottom-up sau evolutivă;- strategia top-down. Strategia bottom-up conduce la parcurgerea următorilor paşi:- Realizarea de aplicaţii independente, fiecare având fişiere proprii de date

şi realizate de regulă ca suport pentru conducerea operativă a unor activităţi. Ele constau practic din operaţii de prelucrare a tranzacţiilor, de actualizare a fişierelor, furnizarea de rapoarte predefinite. E bine de ştiut faptul că aşa au început majoritatea societăţilor beneficiare de soft aplicativ.

- Integrarea fişierelor între care există legături logice într-o bază de date unică, alegerea unui SGBD corespunzător, care asigură gestionarea şi controlul centralizat al datelor. În acest mod pot fi adăugate sistemului noi facilităţi privind interogarea bazei de date pe baza unor cereri predefinite sau create pe loc , utilizând astfel performanţele SGBD-ului selectat.

- Conceperea şi adăugarea unor proceduri sau modele de decizie şi planificare, suport pentru nivelul conducerii tactice, cu prelucrarea datelor din baza de date creată anterior.

- Diversificarea modelelor de decizie şi planificare cuprinse în sistem şi extinderea bazei de date şi includerea în cadrul acesteia a datelor necesare noilor modele.

- Abordarea nivelului conducerii strategice, prin conceperea unor noi modele de decizie destinate acestui nivel şi prin reutilizarea modelelor implementate anterior. Noile cerinţe de informaţii pot conduce la extinderea bazei de date existente sau chiar la crearea unei baze de date independente, destinată acestui nivel (conţine multe date cu caracter conjunctural obţinute din mediul extern sistemului obiect). Se va utiliza în continuare acelaşi SGBD, pentru a asigura coerenţa şi integritatea sistemului în ansamblul său.

Avantajele utilizării acestei strategii pot fi formulate astfel:

229

- dezvoltarea treptată a sistemului se realizează în mod natural şi în corelaţie cu cerinţele reale ale utilizatorului, care pot fi definite astfel mai uşor;

- utilizatorul se familiarizează mai uşor cu implicaţiile introducerii prelucrării automate a datelor şi poate beneficia mai rapid de primele rezultate. Creşte astfel rolul său participativ-activ în dezvoltarea sistemului. Practica demonstrează că utilizatorul va putea să-şi formuleze cerinţe mai precise după primirea primelor rezultate de la calculator.

- echipa de proiectare se acomodează pas cu pas cu problematica societăţii utilizatoare;

- se reduce riscul realizării unui sistem mare, care să se dovedească neoperaţional la punerea în funcţiune.

O serie de dezavantaje au fost însă identificate la utilizarea acestei strategii, dintre care amintim:

- gradul de integrare şi performanţele sistemului rezultat sunt, de obicei, slabe, datorită lipsei unei concepţii de ansamblu iniţiale asupra obiectivelor şi funcţiunilor sistemului.

- fiecare pas nou, deci fiecare adăugare de noi funcţiuni, atrage după sine reproiectarea, completă sau parţială, a aplicaţiilor realizate anterior, ducând astfel la creşterea efortului şi deci şi a costurilor totale de proiectare;

- nu se poate face de la început o evaluare globală a duratelor şi a resurselor necesare;

- dacă se produc modificări în componenţa echipei de proiectare, ceea ce se întâmplă foarte des ca urmare a duratei destul de mari a ciclului de realizare, pot să apară probleme de comunicare între faze sau între membrii echipei;

Strategia top-down presupune parcurgerea următorilor paşi:- analiza obiectivelor generale şi specifice ale sistemului obiect, a relaţiilor

sale cu mediul extern şi a restricţiilor;- identificarea activităţilor principale şi a relaţiilor dintre acestea;- identificarea principalelor decizii şi acţiuni întreprinse pe diferite nivele

de conducere: strategic, tactic şi operativ;- identificarea tipurilor de date necesare pentru fiecare acţiune sau decizie,

la nivelul fiecărei activităţi sau funcţiuni;- definirea modelului de ansamblu al sistemului, cu modelul conceptual al

datelor şi prelucrărilor;- gruparea cerinţelor de informaţii în subsisteme şi module funcţionale,

definirea interfeţelor dintre acestea;- stabilirea priorităţilor în realizarea bazei de date, a subsistemelor şi

modulelor funcţionale componente, ţinând cont de modalităţile de integrare treptată a acestora;

- realizarea propriu-zisă a sistemului, prin realizarea componentelor sale potrivit graficului de priorităţi stabilit.

230

Avantajele aplicării acestei strategii pot fi:- analiza globală a sistemului obiect permite definirea obiectivelor generale

ale sistemului informatic şi ale celor specifice fiecărui subsistem, ceea ce permite o planificare a resurselor şi un control mai riguros al proiectului;

- sistemul informatic obţinut are un grad înalt de integrare, ceea ce duce la creşterea utilităţii sistemului şi a performanţelor sale;

- prin definirea de la bun început a obiectivelor, funcţiunilor şi interfeţelor dintre componente se evită reproiectarea succesivă a acestora (cum se întâmpla la strategia evolutivă).

Ca dezavantaje pot fi enumerate:- definirea modelului de ansamblu necesită, pentru a fi corect, o bună

cunoaştere a sistemului obiect sub toate aspectele sale, identificarea elementelor componente şi a relaţiilor dintre acestea, decuparea corectă chiar din această fază a subsistemelor şi modulelor sale funcţionale; aceasta devine astfel o etapă deosebit de dificilă, căci orice eroare poate avea mai târziu implicaţii imprevizibile.

- parcurgerea corectă a etapelor sale duce la creşterea timpului de aşteptare a utilizatorului până la obţinerea primelor rezultate ale prelucrării automate.

În practică însă cele două strategii care par diametral opuse, nu sunt implementate în forma lor pură, ci într-o formă hibridă, prin combinarea acestora.

Astfel, se recurge de regulă la o strategie de forma: se aplică strategia top-down pentru definirea modelului de ansamblu al sistemului informatic, după care stabilirea priorităţilor de realizare, realizarea efectivă şi implementarea componentelor se face conform strategiei bottom-up.

Nu trebuie neglijat faptul că reproiectarea unui sistem, cerută adeseori de noile tehnologii informaţionale, presupun din partea echipei de proiectare o bună cunoaştere a sistemului sau domeniului obiect, presupun deasemenea existenţa unui personal utilizator instruit şi a unui sistem de conducere cu rol participativ-activ în realizarea sistemului.

Toate acestea influenţează în mod direct şi pozitiv reproiectarea noului sistem, contribuind la creşterea calităţii softului realizat, la reducerea resurselor necesare şi a timpului de realizare.

Observaţie:În funcţie de condiţiile concrete ale fiecărei unităţi care solicită realizarea unui

sistem informatic, de starea ei din momentul iniţial în ceea ce priveşte dotarea hardware, aplicaţii existente şi personal instruit sau de specialitate, în funcţie de obiectivele, cerinţele şi restricţiile formulate pentru noul sistem, în funcţie de posibilităţile financiare şi de timp de care dispune societatea, dar şi în funcţie de componenţa echipei de proiectare, de experienţa în domeniu, de creativitatea, spiritul novator şi motivarea acesteia depinde, la sfârşit de drum, reuşita proiectării sau reproiectării unui sistem informatic sau produs program.

231

11.3. Utilizarea instrumentelor CASE în proiectarea sistemelor informatice

Instrumentele CASE (Computer Aided Systems Engineering) au apărut în jurul anului 1970 din necesitatea de a implica utilizarea calculatorului ca un mijloc de susţinere a activităţilor de planificare, de proiectare şi realizare a sistemelor informatice. Dezvoltarea aplicaţiilor de dimensiuni medii sau mari, începând cu faza de analiză şi terminând cu fazele de testare şi întreţinere nu poate fi realizată eficient fără ajutorul unui instrument CASE adecvat. Aportul instrumentelor CASE este vizibil în primul rând în fazele de proiectare şi implementare, speranţele fiind ca în viitor el să fie semnificativ şi în faza de testare. Adoptarea UML ca limbaj standard de modelare a influenţat benefic evoluţia instrumentelor CASE şi a determinat o creştere sensibilă a interesului proiectanţilor pentru ele.

Utilizarea instrumentelor CASE nu este o problemă de modă, ci este o problemă de eficienţă. Instrumentele nu sunt şi nici nu pot fi creative. Ele sunt şi trebuie să fie în cel mai înalt grad degrevative.

De aceea, automatizarea tuturor activităţilor potrivite reprezintă sarcina de bază pentru orice instrument CASE. În acest fel, instrumentele sprijină utilizatorii să se concentreze asupra activităţilor cu adevărat creative.

Instrumentele CASE au evoluat odată cu componenta hardware a calculatoarelor electronice, dar şi cu limbajele de programare şi metodologiile de modelare. În anii 70-80, nu exista nici suportul (limbaje şi metodologii de modelare) şi nici mijloacele tehnice (limbaje de programare, medii de dezvoltare şi calculatoare suficient de puternice) absolut necesare pentru construirea unor "adevărate" instrumente CASE. Mai mult, nu mai departe de sfârşitul anului 1997 (în momentul adoptării UML ca standard) marea majoritate a instrumentelor erau într-o măsură prea mare apropiate ca funcţionalitate de instrumentele de desenare.

Această imagine este însă într-o schimbare semnificativă, datorată pe de o parte deciziei producătorilor mediilor de dezvoltare de a introduce în (sau de a încuraja conectarea la) mediile lor a unor instrumente de modelare (CASE) iar pe de alta atitudinii realizatorilor de instrumente de a favoriza o legare mai strânsă a instrumentelor la mediile de dezvoltare. La toate acestea se adaugă standardizarea limbajelor de modelare, cererea tot mai mare pentru aplicaţii complexe şi sigure, evoluţia nivelului pregătirii profesionale a realizatorilor de sisteme informatice, care au contribuit şi continuă să contribuie la schimbarea rolului şi implicit a nivelului de utilizare a instrumentelor CASE în procesul dezvoltării softului.

Astăzi dezvoltarea unei aplicaţii de dimensiuni medii sau mari nu mai poate fi realizată eficient fără instrumente CASE adecvate.

Prin instrumente CASE înţelegem acele aplicaţii soft care-i sprijină pe analişti, proiectanţi, programatori, inclusiv personalul de testare şi întreţinere,

232

să analizeze, să proiecteze, să implementeze (cel puţin parţial), să modifice (extindă), respectiv să construiască teste pentru sistemele informatice.

În ultimii ani, instrumentele CASE au fost tot mai mult folosite pentru a realiza modele de intreprinderi sau activităţi economice, motiv pentru care, definiţia precedentă trebuie extinsă cu această precizare.

Instrumentele CASE se bazează pe logica structurată, pe descompunerea funcţională şi pe reprezentarea aplicaţiilor prin diagramele de flux a datelor.

Obiectivele generale ale unui instrument CASE sunt: - Să permită specialiştilor (analişti, proiectanţi, personal de testare) să se

concentreze într-o cât mai mare măsură asupra problemelor cu adevărat importante ce trebuie rezolvate în procesul dezvoltării aplicaţiilor. Acest deziderat se realizează printr-un nivel înalt de automatizare a tuturor tipurilor de operaţii ce pot fi gestionate de instrument;

- Să sprijine realizarea unor activităţi eficiente de verificare la toate nivelele (cu condiţia ca aceste activităţi să nu fie stânjenitoare);

- Să-i ajute pe beneficiari (nespecialişti în informatică) să verifice încă din primele faze consistenţa şi completitudinea descrierii problemei.

O serie de avantaje ale utilizării instrumentelor CASE sunt cunoscute pentru realizatorii de soft, cum ar fi:

- reducerea complexităţii logicii de descriere a sistemului, prin descompunerea lui;

- creşterea vitezei de realizare a sistemelor;- realizarea succesivă a componentelor;- posibilitatea de a alege între mai multe variante;- uşurarea integrării componentelor în sistem;- folosirea depozitelor modularizate;- refolosirea unor componente din diagramele utilizate;- simplificarea activităţilor de proiectare şi realizare, etc.Astfel, se pot utiliza instrumente CASE specifice în diverse domenii ale

activităţii de proiectare şi realizare a sistemelor informatice, cum sunt:- Proiectarea şi modelarea funcţională şi procedurală; primele instrumente

Case serveau pentru crearea automată a fluxurilor de date, construirea schemelor logice structurate de program şi verificarea acestora.

- Modelarea datelor şi proiectarea bazei de date; instrumentele Case sprijină proiectarea logică şi fizică a bazei de date.

- Generarea codurilor. În marea majoritate a cazurilor, modelul construit cu ajutorul unui instrument CASE este transformat ulterior în cod executabil. Din această cauză, transformarea automată a informaţiilor modelului în cod este cât se poate de naturală. În cazul în care comportamentul sistemului este complet specificat cu ajutorul limbajului de modelare, atunci întreg codul aplicaţiei poate fi generat automat. Din această cauză, instrumentele care sprijină semnificativ

233

generarea codului sunt cunoscute şi sub denumirea de instrumente de programare vizuală. Două din cele mai importante probleme care trebuie rezolvate la generarea codului sunt:

(a) Identificarea celui mai potrivit formalism pentru descrierea comportamentului unei entităţi. Există unele situaţii în care modalitatea cea mai simplă şi sugestivă este utilizarea directă a limbajului de programare.

(b) Generarea codului trebuie să fie suficient de flexibilă încât să permită obţinerea unui cod eficient şi adecvat aplicaţiei.

- Editoarele; În acest sens editorul inteligent de limbaje este un instrument de editare care înţelege sintaxa unuia sau mai multor limbaje de programare şi sprijină procesul de realizare a codului.

- Referinţe încrucişate; instrumentele de referire încrucişată controlează riguros toate conexiunile prin existenţa depozitelor CASE.

- Instrumente de test; testarea poate fi automatizată, apelând la funcţia de tezaurizare a sistemelor Case, pe baza căreia se pot obţine datele de test pentru a verifica dacă sistemul realizat răspunde cerinţelor formulate de utilizatori.

- Instrumente de analiză a rezultatelor obţinute, care permit simulări pentru identificarea posibilităţilor de optimizare a programelor realizate.

- Depanatoare de coduri sursă- Instrumente pentru managementul proiectelor- Instrumente de documentare, care permit generarea şi actualizarea

automată a documentaţiei proiectului realizat.Mediul de lucru CASE trebuie să sprijine astfel tehnicile de modelare în

diferite stadii şi metodologia cea mai adecvată pentru o societate sau pentru un domeniu anume. Ele au evoluat odată cu acestea şi îmbracă mai multe forme, cum sunt:

- instrumente Lower CASE;- instrumente Upper CASE;- instrumente Expert CASE;- instrumente OPEN CASE;- instrumente I-CASE;- instrumente CASE orientate –obiect.Utilizarea instrumentelor CASE îmbunătăţeşte considerabil calitatea procesului

de realizare a sistemelor informatice, creşte viteza de proiectare şi realizare a acestora, îmbunătăţeşte calitatea testării lor, a documentaţiei elaborate, promovează reutilizarea unor componente şi simplifică întreţinerea programelor, îmbunătăţeşte managementul proiectelor şi conduce spre standardizarea procesului de dezvoltare a sistemelor.

Ele sunt din ce în ce mai utilizate în diferite etape de către echipele de proiectare şi realizare a sistemelor informatice.

234

12. MANAGEMENTUL ACTIVITĂŢII DE PROIECTARE ŞI REALIZARE A SISTEMELOR INFORMATICE

12.1 Aspecte organizatorice

Dacă avem în vedere importanţa activităţii de proiectare şi realizare a unui sistem informatic, prin obiectivele sistemului, prin cerinţele şi restricţiile impuse acestuia, precum şi prin dimensiunea resurselor folosite (financiare, materiale, umane şi de timp) este evidentă necesitatea unei conduceri atente şi competente, a unui control riguros asupra execuţiei fiecărei etape.

Activitatea de conducere a efortului de realizare a unui sistem informatic este de mare importanţă, ea trebuind să urmărească legarea corespunzătoare a tuturor acţiunilor ce urmează a fi desfăşurate şi să asigure astfel că totul se execută la termenele stabilite, în cadrul fondurilor aprobate, conform obiectivelor formulate şi că rezultatele unei etape sunt corecte şi pot fi utilizate în etapele următoare.

Orice proiect serios care trebuie realizat la cererea unei societăţi beneficiare se dă spre execuţie unei echipe de proiectare, organizată eventual pe subechipe, condusă de un aşa numit şef de proiect.

În această structură de lucru este rolul celor care conduc lucrările să definească:- obiectivele sistemului, exprimate eventual, cantitativ şi calitativ;- limitele până la care se va întinde sistemul, având în vedere obiectivele şi

restricţiile;- sarcinile şi responsabilităţile fiecărui membru în toate etapele de realizare;- planificarea resurselor şi urmărirea continuă a consumului lor;- criteriile de evaluare a performanţelor sistemului, etcMai trebuie făcută precizarea că în echipa de proiectare participă, de regulă,

specialişti din domeniul informaticii: analişti, programatori, ingineri de sistem, administratori de reţea şi sau baze de date, operatori. La aceştia se adaugă neapărat, în toate etapele de lucru, reprezentanţi ai beneficiarului, de obicei reprezentanţi ai compartimentelor sau activităţilor implicate în realizarea şi introducerea noului sistem.

Alegerea şefului de proiect este o problemă cheie pentru reuşita activităţii de realizare a unui proiect, date fiind atribuţiile sale. Astfel, acesta planifică, coordonează, controlează, raportează sarcinile membrilor echipei şi face propuneri pentru suplimentarea sau reducerea echipei, pentru înfiinţarea sau desfinţarea unor subechipe, pentru repartizarea resurselor, pentru evaluarea rezultatelor fiecăruia, etc. Şeful de proiect întocmeşte graficul de desfăşurare a lucrărilor şi asigură utilizarea soluţiilor celor mai eficiente, de înalt nivel tehnic , precum şi realizarea integrării interne şi externe a sistemului. El asigură încadrarea lucrărilor în limitele indicatorilor aprobaţi, respectarea performanţelor şi restricţiilor prevăzute, rezolvarea observaţiilor făcute cu ocazia avizărilor.Tot şeful de proiect este cel care asigură informarea membrilor echipei de proiectare cu privire la sarcinile şi obligaţiile ce le revin, asigură instruirea acestora în vederea respectării unor

235

reglementări specifice unităţii beneficiare, asigură gestiunea şi evidenţa resurselor antrenate.

S-au formulat chiar 9 reguli de aur pentru buna conducere a proiectelor, care

revine în principal şefului de proiect. Prezentate sumar, ele sunt:

1). Respectarea unei ordini riguroase. Proiectul poate începe doar dacă s-a răspuns la întrebări fundamentale ca:

- este oportun?- ştim ce vrem?- care sunt implicaţiile?2). Construirea unui cadru de lucru, de către şeful de proiect, care să conţină:- fluxul informaţional;- probleme legate de culegerea şi validarea datelor;- rezultatele aşteptate;- compartimente sau activităţi implicate;- etapele de desfăşurare.3). Prezentarea globală a proiectului, pentru a găsi răspuns la întrebările:- ce vrem să facem?- ce trebuie să facem?- cu ce începem?- cu cine?4). Formarea şi coordonarea echipei de proiectare este sarcina şefului de

proiect, care trebuie să se încadreze în echipă, astfel ca membrii ei să se simtă informaţi, implicaţi, consultaţi.

5). Dotarea cu mijloace de urmărire şi control care să permită şefului să verifice, să urmărească în mod real cum este realizat planul. Se cunosc astăzi o serie de metode şi instrumente în mâna şefului de proiect pentru planificarea şi urmărirea activităţilor unui proiect (graficul Gantt, graficul Pert), pentru identificarea activităţilor critice.

6). Avizarea tuturor fazelor importante de către beneficiar, deci nici o etapă nu trebuie să înceapă fără o avizare prealabilă a celei anterioare.

7). Controlul avansării realizărilor, pentru a şti permanent unde suntem, care sunt punctele critice şi dacă sunt necesare forţe suplimentare.

8). Controlul calităţii, care înseamnă nu numai rezultate corecte obţinute, ci şi programe bine construite, documentaţie bine întocmită, atât pentru utilizatori cât şi pentru specialişti, utilizarea unor tehnologii adecvate, etc.

9). Identificarea originii modificărilor, dacă acestea apar şi pot fi: omisiuni în cadrul analizei, beneficar nou, schimbarea legislaţiei, etc. Este important, căci modificările produc perturbaţii iar acestea pot să nu fie grave dacă proiectul este bine condus.

236

12.2. Documentaţia proiectului

Documentaţia proiectului, care trebuie să fie bine întocmită, completă, corectă şi organizată corespunzător pentru toate etapele din ciclul de viaţă al unui sistem informatic sau produs program este deosebit de importantă. Astfel, ea reprezintă principalul mijloc de conducere al efortului de realizare a unui sistem informatic, de comunicare între beneficiar şi echipa de proiectare şi în interiorul acesteia, între specialişti.

Se cere ca documentaţia elaborată să asigure:- comunicarea între etape şi activităţi;- controlul lucrărilor realizate, inclusiv a calităţii acestora;- referinţă istorică, mai ales pentru evidenţierea modificărilor apărute ;- instrucţiuni complete pentru utilizarea, exploatarea curentă, întreţinerea şi

dezvoltarea sistemului.

Pentru a răspunde acestor cerinţe, documentaţia elaborată trebuie să respecte anumite principii cum sunt:

- Să permită exploatarea sistemului fără intervenţia autorilor;- Să permită realizarea relativ uşoară a modificărilor necesare pentru

adaptarea sistemului la cerinţele specifice ale utilizatorilor;- Descrierea sistemului să se facă de la general la particular, conform

strategiei top-down;- Fiecare componentă să se adreseze unei categorii bine precizate de cititori

sau utilizatori, pentru o bună înţelegere a acesteia;- Documentaţia să conţină cât mai puţine informaţii redundante.

Astfel, fiecare etapă din ciclul de viaţă al unui sistem informatic este însoţită de elaborarea unei documentaţii care de regulă poartă numele etapei respective şi, atunci când este cazul, dacă se adresează unor categorii diferite de utilizatori are nume diferite, cum ar fi: Proiectul logic de detaliu şi proiectul tehnic de detaliu.

Aceste documentaţii care însoţesc sistemul pe măsura realizării lui sunt:- Studiu de oportunitate sau Studiu de fezabilitate elaborat în etapa cu

acelaşi nume sau în cea denumită analiză preliminară sau temă de realizare.- Proiectul de ansamblu al sistemului informatic, rezultat al proiectării de

ansamblu.- Proiectul logic de detaliu, rezultat al activităţii de proiectare logică de

detaliu. Se elaborează la nivelul fiecărui subsistem şi aplicaţie informatică sau modul funcţional.

- Proiectul tehnic de detaliu, rezultat al activităţii de proiectare tehnică de detaliu. Se elaborează la nivelul fiecărei aplicaţii informatice sau modul funcţional. El conţine practic specificaţiile tehnice de realizare efectivă a

237

programelor, descriind pentru fiecare program/modul sau procedură automată: intrările şi ieşirile cu formatul lor, fişierele sau baza de date, algoritmii de calcul şi modelele matematice utilizate, formatul interfeţei,etc.

- Manual de prezentare şi utilizare a fiecărei aplicaţii informatice sau modul realizat.

- Manual de exploatare a sistemului sau a subsistemului sau a aplicaţiei realizate.

Fiecare etapă trebuie să fie avizată şi însoţită deci de documentaţia corespunzătoare, care va descrie riguros rezultatele acţiunilor întreprinse în cadrul acestora.

Ulterior, orice modernizare, dezvoltare sau reproiectare a sistemului informatic sau a aplicaţiei informatice presupune studiul documentaţiei corespunzătoare acestuia/acesteia şi trebuie însoţită deasemenea de corectarea, actualizarea sau completarea documentaţiei respective cu modificările survenite.

Documentaţia trebuie întreţinută deci la zi, odată cu sistemul.

238

13. EFICIENŢA SISTEMELOR INFORMATICE (produselor program)

Se ştie că eficienţa economică se măsoară, în general, printr-un raport între efectele obţinute şi cheltuielile antrenate.

În mod corespunzător, eficienţa economică a unui sistem informatic se va determina prin compararea efectelor obţinute în urma exploatării lui curente cu cheltuielile necesare pentru realizarea şi funcţionarea sa. Estimarea celor două elemente se face ţinând cont de caracterul deosebit de complex al efectelor obţinute prin introducerea noului sistem şi de ansamblul factorilor în care funcţionează sistemul informatic realizat.

Pentru estimarea eficienţei economice a unui sistem informatic concret trebuie identificate sursele de date necesare pentru calculul indicatorilor de eficienţă. Astfel, în majoritatea cazurilor se cunosc sau se pot estima costurile de realizare, de întreţinere şi dezvoltare, dar efectele economice sunt greu de cuantificat.

În literatura de specialitate teoriile şi conceptele privind eficienţa economică a sistemelor informatice se pot clasifica în funcţie de sursele de estimare a fluxurilor de venituri în trei grupe.

În prima grupă sunt cuprinse teoriile şi conceptele care susţin utilitatea sistemului informatic. În acest caz se rezolvă “vechile probleme cu noile instalaţii” în condiţii de eficienţă. În cadrul acestor teorii se stabilesc criterii privind selecţionarea corectă a fluxurilor informaţionale care necesită informatizarea imediată, se aleg componentele cele mai performante ale tehnologiei informaţiei (echipamente, produse program şi metodologii) preocuparea principală constând în asigurarea stabilităţii şi funcţionalităţii sistemului informaţional existent.

În cadrul grupei a doua privind eficienţa sistemelor informatice sunt incluse teoriile care consideră că eficienţa provine din impactul sistemului informatic asupra activităţii de conducere a sistemelor economico-sociale, exprimată prin creşterea eficienţei deciziilor asupra sistemului condus. Valoarea informaţiilor pe care sistemul informatic economic le furnizează se compară cu cheltuielile necesare pentru obţinerea acestora. Pentru calculul valorii informaţiei se apelează la componente privind caracteristicile tehnice cum ar fi: precizie, operativitate, conţinut informaţional, durata de răspuns etc.

Grupa a treia de teorii privind eficienţa sistemelor informatice economice au la bază evaluarea eficienţei sistemului informatic prin contribuţia sa adusă la sporirea eficienţei activităţilor cu caracter tehnic, în special asupra activităţilor de producţie şi economico – sociale. În cadrul acestei grupe se analizează un număr de indicatori economici din care enumerăm:

239

a) indicatori de fundamentare tehnico – economică a sistemului informatic

b) indicatori sintetici de evaluare a eficienţei economice a sistemelor informatice deja existente

Indicatori de eficienţă economică ai sistemului informatic

Atunci când se elaborează un sistem informatic, acesta poate fi selectat dintr-o gamă de variante, diferenţiate între ele prin elemente de cheltuieli şi prin efecte economice obţinute.

Selectarea unui sistem se face pe baza analizei variantelor posibile de realizat, în raport cu resursele informatice existente atât la proiectant cât şi la utilizator, în contextul unui aşa numit raport cost/performanţă. În acest context au fost elaboraţi indicatori capabili să reflecte raportul dintre costul resurselor consumate şi performanţele scontate ale sistemului informatic după cum urmează:

1. Coeficientul de satisfacere a cerinţelor informaţionale

Un sistem informatic trebuie să satisfacă integral cerinţele informaţionale ale unităţii economico – sociale. Acest indicator se calculează ca un raport dintre cantitatea de informaţii proiecată a fi furnizată de sistemul informatic şi cantitatea de informaţii reale pe diversele nivele ale piramidei ierarhice ale conducerii existente în unitate.

2. Valoarea informaţiilor furnizate de sistemul informatic

Se calculează funcţie de două componente de bază ale sale, şi anume: Cantitatea de informaţie Calitatea informaţiilor furnizate

a). Dacă vorbim despre cantitatea de informaţii, se impune precizarea că, în cazul sistemelor social-economice, comportamentul lor la diferite momente are un caracter aleator datorită perturbaţiilor ce pot apare pe parcursul desfăşurării proceselor tehnico-economice, conducând astfel la o anumită nedeterminare a stării sistemului.

Cu cât gradul de nedeterminare a stării sistemului este mare, ca urmare a perturbaţiilor, cu atât cantitatea de informaţie necesară pentru restabilirea traiectoriei sistemului este mai mare. Altfel spus, cantitatea de nedeterminare este egală cu cantitatea de informaţie necesară.

Presupunând că în urma interacţiunii unor elemente ale sistemului social-economic va rezulta un număr n de rezultate posibile, am putea utiliza pentru calculul cantităţii de informaţie necesară conducerii relaţia:

240

Dacă din calcul se obţine i=0, atunci înseamnă că rezultatele interacţiunii dintre elementele sistemului condus sunt conforme planului, programelor, normelor şi deci aceste informaţii normale ar trebui excluse din sistemul de informare operativă a conducerii şi admise numai cele care depăşesc anumite limite admise.

b). Calitatea informaţiilor furnizate de sistemul informatic ar putea fi definită prin ansamblul caracteristicilor acestora şi anume: acurateţe, timp de răspuns, vârsta, etc determinate de caracteristicile sistemului informatic, cum ar fi:concepţia şi structura acestuia, nivelul de dotare tehnică, metode şi proceduri utilizate în culegerea, prelucrarea, transmiterea şi stocarea informaţiilor.

b1). Acurateţea informaţiilor furnizate de sistemul informatic poate fi măsurată prin gradul de predicţie asupra modului de desfăşurare a proceselor şi fenomenelor, asupra traiectoriei acestora în viitor.Harkevici A. propune pentru calculul acurateţei informaţiilor formula: P1

Prob I = log2 _--- P0

unde:P1 = probabilitatea atingerii obiectivului după obţinerea informaţieiP0 = probabilitatea atingerii obiectivului înainte de recepţionarea

informaţiei.

b2). Vârsta informaţiilor este o caracteristică ce determină în mod esenţial calitatea informaţiilor furnizate de un sistem informatic, deoarece de actualitatea informaţiilor depinde calitatea deciziilor luate de către sistemul de conducere. Durata dintre două rapoarte succesive ce conţin acelaşi gen de informaţii caracterizează vârsta informaţiilor respective.Vârsta informaţiilor are două componente:- intervalul , măsurat în unităţi de timp, dintre momentul în care s-au

obţinut informaţiile precedente şi momentul în care sunt colectate datele pentru prelucrare, în vederea transmiterii noilor informaţii;

- timpul de răspuns al sistemului informatic, definit ca fiind intervalul de timp dintre momentul formulării unei cereri de la un terminal de comunicaţie – date şi obţinerea răspunsului în acelaşi loc.

Practic el măsoară:- timpul de formulare a cererii de la un terminal la un calculator;- timpul de prelucrare al calculatorului, inclusiv timpul de acces şi obţinere

a înregistrărilor din fişiere necesare formulării răspunsului la interogare;- timpul de transmitere a răspunsului de la calculator la terminal.

241

Din analiza corelaţiei dintre timpul de răspuns, efectele economice şi costuri, rezultă că:

- odată cu reducerea timpului de răspuns efectele economice cresc dar în acelaşi timp cresc şi costurile pentru obţinerea informaţiilor. Se impune precizarea: costurile pentru reducerea timpului de răspuns peste anumite limite depăşesc cu mult efectele economice. De aceea, reducerea considerabilă a timpului de răspuns astfel încât informaţiile să se obţină în timp real nu se justifică din punct de vedere economic în cazul sistemelor social-economice, căci nu ar conduce la o creştere considerabilă a valorii informaţiilor.

În aceste condiţii, pentru a determina valoarea informaţiilor furnizate de un sistem informatic este necesar să admitem utrmătoarele ipoteze:- informaţiile nu au o valoare în sine, deşi pentru obţinerea lor se consumă o

anumită cantitate de muncă socială;- valoarea informaţiilor se materializează în efectele ce se obţin ca urmare a

deciziilor care se iau pe baza lor;- informaţiile furnizate de noul sistem informatic sunt superioare celor

furnizate de vechiul sistem informaţional din punct de vedere al conţinutului şi al calităţii;

- fiecărui tip de decizie îi sunt asociate anumite efecte economice.Atunci valoarea informaţiilor furnizate de noul sistem informatic Vi , exprimată prin efectele economice , se va calcula cu relaţia:

unde:C – cantitatea de informaţie;A – acurateţea informaţiilor;T – timpul de răspuns al sistemului informatic;I – intervalul acoperit de informaţiile furnizate (perioadele pentru care informaţiile sunt utile);N – numărul de decizii ce se iau pe o perioadă;n – numărul de perioade acoperite de intervalul I;P – probabilitatea de a lua o decizie corectă cu informaţiile furnizate de vechiul sistem sau fără informaţii.

Creşterea cantităţii de informaţie ce rezultă ca urmare a informaţiilor noi furnizate de sistemul informatic conduce în mod direct la obţinerea unor efecte economice suplimentare, prin diminuarea pierderilor posibile, dar în acelaşi timp antrenează şi cheltuieli suplimentare. Analizând corelaţia dintre cantitatea de informaţie, efectele economice şi costuri se constată că până la un anumit nivel al cantităţii de informaţie , viteza de creştere a efectelor economice este mai mare decât viteza de

242

creştere a costurilor, după care la o creştere în continuare a cantităţii de informaţie, viteza de creştere a efectelor economice este mai mică decât viteza de creştere a costurilor.Corelaţia dintre costuri şi cantitatea de informaţie este dată de funcţia exponenţială :Y = ae bx , unde a>0 reprezintă valoarea iniţială a costurilor, iar b>0 reprezintă coeficientul care determină viteza de creştere a costurilor. Corelaţia dintre costuri şi acurateţea informaţiilor este dată de funcţia hiperbolică :

unde:

a>0 reprezintă coeficientul valorii iniţiale a costurilor, b>0 reprezintă coeficientul care determină viteza de creştere a costurilor

3. Coeficientul eficienţei economice

Acest coeficient reprezintă raportul dintre suma efectelor economice potenţiale însumate pe durata unui an şi totalitatea resurselor consumate (costurile) pe aceiaşi durată. Acesta depinde, în mare măsură, de productivitatea programelor, a echipamentelor, a sistemelor de operare, precum şi a operatorilor.

Astfel, la un an după punerea în funcţiune a unui sistem informatic, când se face evaluarea acestuia, coeficientul eficienţei economice se poate calcula cu relaţia:

, unde:

Ke - coeficientul eficienţei economice;E – efectele economice totale;Ff – valoarea fondurilor fixe utilizate;Fc – valoarea fondurilor circulante utilizate

Acest indicator se poate calcula la nivelul întregului sistem informatic, a fiecărui subsistem sau modul (aplicaţie informatică) a acestuia, în diferite momente ale realizării, cum sunt:- pentru fundamentarea oportunităţii sale;- pentru aprecierea funcţiunilor sale;- pentru fundamentarea necesităţii dezvoltării, modernizării sau reproiectării

sale.

4. Coeficientul termenului de recuperare a cheltuielilor

Acest coeficient se calculează ca raport între cheltuielile antrenate şi efectele economice totale pe durata ciclului de viaţă al sistemului informatic. Se calculează în etapa de fundamentare a oportunităţii introducerii sistemului informatic. Se

243

poate calcula şi pentru fundamentarea fiecărui subsistem sau aplicaţie informatică în parte, precum şi pentru fundamentarea modernizării acestora.

El se calculează ca raport între cheltuielile de realizare, introducere şi dezvoltare a sistemului informatic sau a aplicaţiei informatice şi efectele economice obţinute, astfel:

(ani) unde:

Tr – coeficientul termenului de recuperareC – cheltuieli de realizare, introducere şi dezvoltare antrenateE – efectele economice obţinute

La un an după punerea în funcţiune a sistemului, subsistemului sau modulului informatic termenul de recuperare se recalculează raportând cheltuielile efective ale beneficiarului la efectele economice efective .

5. Coeficientul economiei de personal

Prin introducerea noului sistem informatic timpul de muncă (t1) a personalului se reduce faţă de timpul de muncă consumat anterior (t0) pentru executarea aceloraşi lucrări informaţionale. Astfel, putem vorbi de o economie absolută de personal, dar şi de o economie relativă de personal, care ţine de creşterea numărului şi volumului lucrărilor de evidenţă şi calcul executate cu acelaşi număr de personal.

Acest coeficient Kp se calculează:

Kp = (t0 –t1) / t0

6. Coeficientul tehnico - economic

În multe din situaţiile concrete de estimare a eficienţei economice a sistemelor informatice cu ajutorul indicatorilor prezentaţi nu se ajunge la o soluţie concludentă. În aceste cazuri se recurge la un indicator sintetic, cuantificat pe baza criteriilor de importanţă acordată coeficienţilor enumeraţi anterior. Calculul se va face la un consum minim de resurse necesare obţinerii anumitor efecte economice.

7. Coeficienţi tehnici ai sistemului informatic

Adeseori eficienţa unui sistem informatic nu poate fi uşor calculată şi atunci, pentru a pune în evidenţă utilitatea şi performanţele tehnice ale acestuia, se apelează la o serie de indicatori tehnici de caracterizare a acestuia, cum sunt:

- Coeficientul de utilizare a datelor Ku pentru procesul de prelucrare P:

244

unde:Dn – cantitatea de date ce se prelucrează cu procesul PIn - cantitatea de informaţie ce trebuie furnizată de componenta respectivă

- Coeficientul nivelului de organizare a fişierelor/bazei de date K0 :

unde:

T – timpul total T= T0 + Ti + Ta + Tp T0 – timpul pentru încărcarea şi actualizarea bazei de dateTi - timpul pentru întreţinerea, salvarea şi refacerea fişierelor bazei de dateTa – timpul de acces la fişiereTp – timpul de prelucrare propriu-zis

- Coeficientul nivelului de întreţinere a fişierelor bazei de date Ki

- Coeficientul nivelului de acces la fişierele bazei de date Ka

- Coeficientul nivelului de prelucrare a datelor Kp

- Fiabilitatea sistemului, care exprimă capacitatea sistemului informatic de a-şi îndeplini funcţiile sale o anumită perioadă de timp în anumite condiţii de utilizare.

8. Calitatea serviciilor

Calitatea serviciilor de prelucrare automată a datelor se poate aprecia prin:- siguranţă, robusteţe;- fidelitate, acurateţe;- integrare;- operativitate;- complexitatea prelucrărilor;- fundamentare ştiinţifică prin utilizarea unor modele matematice;- control şi acceptabilitate.

245

Estimarea eficienţei economice a sistemului informatic cu ajutorul analizei cost / beneficiu

Proiectarea şi realizarea unui sistem informatic implică un consum mare de resurse (forţă de muncă, echipamente, produse program, consumabile, etc. ce pot fi exprimate sub formă de costuri) pentru a obţine servicii exprimate sub formă de venituri. Sistemul informatic având o durată de viaţă bine determinată, realizarea lui poate fi asimilată cu o investiţie şi pe această cale putem estima eficienţa economică cu ajutorul indicatorilor oferiţi de analiza cost beneficiu.

Metoda analizei cost beneficiu (ACB), elaborată de către Institutul Băncii Mondiale (BIRD), se bazează pe aplicarea tehnicilor de actualizare şi pe folosirea în analiză a unui număr restrâns de indicatori de eficienţă.

Atunci când se calculează costurile sistemului trebuie luate în considerare două mari categorii:

- costurile iniţiale, determinate de costurile echipamentelor, ale cablării şi ale softului; avem în vedere în acest sens costurile pentru softul de bază, sisteme de operare şi programe utilitare, dar şi costul pentru softul de aplicaţii proiectat şi realizat sau reproiectat, dezvoltat, modernizat.

- costuri operaţionale sau funcţionale, care cuprind costurile cu personalul, cu funcţionarea şi întreţinerea calculatoarelor, cu distribuirea datelor – dacă este cazul, cu întreţinerea şi dezvoltarea sistemului sau aplicaţiei informatice.

Se impune precizarea că adeseori costurile constituie aspecte fundamentale ale proiectării unui sistem nou, dar uneori, indiferent de costuri, pentru realizarea unui sistem informatic performant se acceptă orice efort, inclusiv financiar. Aşa ar putea fi, de exemplu, un sistem care să asigure securitatea naţională.

De aceea nu se poate da o reţetă exactă de apreciere a eficienţei unui sistem informatic, ea fiind influenţată de specificul, de importanţa şi necesitatea fiecărui sistem în parte.

246