STUDIU APROFUNDAT AL METODOLOGIILOR DE ELABORARE A SISTEMELOR INFORMATICE

STUDIU APROFUNDAT AL METODOLOGIILOR DE ELABORARE A SISTEMELOR INFORMATICE

Metodologia MERISE - un exemplu de corelare a

ciclului de dezvoltare cu nivelul si cu viziunea asupra sistemului

In cursul precedent am vazut ce este ciclul de dezvoltare de sisteme si am amintit despre modelare si modelul informational. Acum trebuie sa remarcam ca nivelul de la care privim sistemul informational difera de la o etapa la alta a ciclului de dezvoltare de sisteme, iar modelul sistemului informational evolueaza de la o etapa la alta reflectand nivelul de la care privim sistemul informational. Astfel, daca ar fi sa ne referim la etapele metodei Merise, ar trebui sa distingem un nivel global (asociat studiului de evaluare) si apoi nivelele conceptual, organizational, logic si fizic, carora le vor corespunde modelele global, conceptual, organizational, logic si respectiv modelul fizic. Aceasta evolutie a modelulului sistemului informational spre un model de sistem informatic este continua si logica, in sensul ca fiecare din modelele de mai sus, n-ar putea fi construit daca nu avem definitivat modelul etapei precedente.

A sti sa proiectam sisteme informatice indeamna sa stim CE si CUM trebuie facut in cadrul fiecarei etape a ciclului de dezvoltare de sisteme pentru ca sa obtinem modelul specific acelei etape, iar raspunsul la aceste intrebari il ofera metodologiile.

Pentru a realiza o modelare eficienta a sistemului informational, agentii (persoanele care joaca un rol oarecare intr-un proces ce trebuie modelat) ca si entitatile care opereaza in sistem ( de exemplu documentele de intrare), trebuie implicate in model impreuna cu functiiile pe care le indeplinesc, cu comportamentul lor si cu datele referitoare la ele.

Prin comportament in cazul agentilor se intelege ceea ce fac ei in anumite imprejurari in contextul functiilor lor, iar in cazul documentelor de intrare - se intelege ce efecte au ele (in contextul fluxului in care sunt implicate) asupra datelor.

In ce priveste datele, exista date care determina starea agentilor sau entitatilor, date de care au nevoie pentru a-si indeplini functiile (respectiv procesul in care sunt implicate) si date pe care le modifica sau le produc prin activitatea lor.

Diversitatea metodelor de abordare a sistemelor informationale are de a face si cu nevoia de a surprinde functiile, comportamentul si datele implicate in sistem, in sensul ca unele metode surprind mai usor functiile, altele redau mai usor comportamentul, iar altele evidentiaza mai bine datele. Daca am imagina un spatiu cu cele trei dimensiuni ce caracterizeaza o entitate (functia, comportamentul sau datele de care este legata), atunci pozitia oricarei entitati in acest spatiu va depinde de ponderea pe care o au in existenta acelei entitati, functia, comportamentul si datele de care este legata.

Cand analistii incep sa studieze un sistem informational, in vederea trecerii acestuia pe calculator, ei trebuie sa identifice care este trasatura dominanta a sistemului (coordonata cu valoarea cea mai mare) si sa aleaga metoda de abordare, respectiv metodologia cea mai potrivita.

Odata aleasa metoda de abordare a sistemului informational, ar trebui identificat ciclul de viata al dezvoltarii sistemului (ciclul asociat metodologiei respective), asa cum apare el in literatura de specialitate si ar trebui sa efectuam operatiile specificate in cadrul metodologiei, pentru fiecare etapa.

Am precizat mai sus ca de fapt in cadrul fiecarei etape, metodologia precizeaza CE si CUM trebuie facut. Pentru a preciza CE trebuie facut, in metodologie sunt enumerate obiectivele urmarite in cadrul fiecarei etape, iar pentru a preciza CUM trebuie facut, este precizata forma sub care se considera ca se poate prezenta fiecare din aceste obiective, in cadrul documentatiei de faza. Uneori aceasta forma de prezentare poate fi una grafica, dar nu una oarecare ci respectand forme si inscrisuri tipizate, prevazute in metodologie. O astfel de forma tipizata se formalism.

Formalism, in sensul de mai sus, inseamna un set de definitii si reguli, combinat cu un set de tipuri de diagrame si/sau de tabele. Cele mai sofisticate formalisme le contine metoda Merise, dar si diagramele de flux ale datelor (DFD) sau cele de tip entitate_relatie (DER) sunt tot niste formalisme.

Numai dupa ce proiectantul aplica situatiei concrete, oferita de sistemul analizat, formalismul specific etapei, el poate indeplini cerintele de proiectare privind documentatia de faza.

Documentatia de faza are pe de o parte rolul de a valorifica constatarile etapei curente pentru a putea fi folosite ca punct de plecare pentru etapa urmatoare, iar pe de alta parte ea are si un rol comunicativ in relatia cu beneficiarul pentru ca prin consensul dintre proiectant si beneficiar, proiectantul are garantia ca a inteles cerintele beneficiarului si va realiza un sistem care sa satisfaca aceste cerinte. Legat de acest aspect, documentatia de faza mai are si o utilitate juridica, in sensul ca poate constitui baza legala pentru plata muncii efectuate de proiectant, iar in caz de litigii ulterioare intre proiectant si beneficiar, documentatia de faza poate constitui un factor care inclina balanta in favoarea uneia sau alteia din parti, dupa cum situatia din teren corespunde sau nu cu ceea ce s-a aprobat de catre beneficiar prin avizarea documentatiei de faza.

Avizarea documentatiei de faza are loc inainte de a se trece la faza urmatoare.

Revenind la ideea de a realiza sistemul informatic numai prin simpla traducere in viata a specificatiilor privind CE si CUM trebuie facut in fiecare etapa a CVDS, trebuie spus ca din nefericire, lucrurile nu sunt atat de simple si aceasta pentru ca foarte rar ciclul de viata al dezvoltarii sistemului informatic se deruleaza secvential si o singura data. De cele mai multe ori ciclurile se reiau din diferite puncte si uneori chiar de mai multe ori si din puncte diferite, ducind la aparitia unor modele ale ciclurilor de viata. Cu alte cuvinte ciclurile de viata difera odata de la un mod de abordare la altul, ceea ce se concretizeaza printr-o anumita structura a etapelor ciclului de dezvoltare (structura materializata printr-un anume numar de etape si succesiune), dar apoi ele difera si de la un model la altul al ciclului de dezvoltare, prin modul cum vor fi reluate si repetate anumite faze. Motivul pentru care se complica lucrurile in acest fel este acela ca de cele mai multe ori, prima varianta a softului produs initial nu este satisfacatoare.

Cauzele acestei situatii sunt multiple. Iata doar cateva dintre ele:

- pe timpul elaborarii unei variante, in sistemul analizat pot sa intervina schimbari de structura sau de functionare;

- este mai greu sa perfectionezi o aplicatie care inca nu functioneaza, aflata doar pe hartie, decat una care a inceput sa functioneze; ca urmare incepem cu ceva care urmeaza a fi perfectionat;

- cand am dat primul program in functiune, incepem sa comunicam mai bine cu beneficiarul; s-ar putea ca el sa constate ca n-a fost bine inteles, sau ceea ce a cerut nu era ceea ce dorea.

Cele mai reprezentative modele ale ciclurilor de viata sunt urmatoarele: modelul cascada, modelul V, modelul incremental, modelul spirala, modelul evolutiv, modelul piramida (specific ingineriei informatiei orientate-obiect).

In sectiunea 2 sunt prezentate in detaliu cele mai reprezentative modele ale ciclurilor de viata.

Presupunand ca am identificat elementul care va fi supus analizei (functie, proces, date, obiecte, etc.), adica am ales orientarea si am ales si modelul ciclului de dezvoltare, deci avem o secventa clara de faze ce trebuie parcurse pentru a realiza sistemul informatic, am putea trece la indeplinirea activitatilor prevazute pentru fiecare etapa, numai ca inainte de aceasta urmeaza sa mai luam in calcul inca un element: viziunea (view) sau aspectul pe care-l analizam la un moment dat pentru a realiza abstractizarea impusa de modelare, adica pentru a elabora modelul informational. Inainte de a explica ce este viziunea, merita sa remarcam ca spre deosebire de alte entitati cu care operam in viata cotidiana sistemele informatice implica mai multe puncte de vedere (views). Asa de exemplu un motor poate fi privit din punct de vedere al principiului de functionare, al componentelor sale majore, deci a subansamblelor sale si cam atat, in timp ce sistemul informatic implica si forme abstracte si mai ales forme abstracte si aceasta pentru ca el nu este realitatea pura ci este o abstractizare a realitatii.

Viziunea este legata de faptul ca sistemul informational se va materializa sub forma a cel putin patru aspecte diferite la care va trebui sa facem referire in fiecare din etapele CVDS. Cu alte cuvinte o etapa se considera parcursa daca pe timpul sau am facut referirile ce se impun la urmatoarele aspecte:

- descrierea si definirea elementelor aditionale si auxiliare specifice etapei;

- comunicatii implicate in sistem;

- datele ce se vehiculeaza in sistem;

- prelucrarile specifice fiecarei etape;

Cu etapele ciclului de dezvoltare dispuse pe verticala si cu aspectele sau viziunile enumerate mai sus, dispuse pe orizontala (sub forma unui cap de tabel), am putea obtine o matrice pe care s-o completam cu activitati sau obiective ce trebuie atinse in fiecare etapa CVDS, pentru fiecare aspect sau viziune. De regula matricea (un rezultat al interferentei dintre etapele CVDS si viziuni) este completata de catre cei care au elaborat metoda cu obiective (mai exact cu CE trebuie facut in cadrul fiecarei etape). Partea privitoare la CUM trebuie facut, este una descriptiva si prea voluminoasa pentru a fi inclusa in matrice. Un exemplu de astfel de model tabelar este matricea oferita de metoda Merise. Cat priveste nivelul de la care privim aceasta matrice, acesta ar putea constitui o a treia dimensiune, ceea ce ar insemna aparitia unui cub! Un asemenea exemplu se intalneste la modelul propus de CIMOSA - un cunoscut concept de arhitectura de referinta. De fapt si autorii metodei Merise au introdus un CVDS pe trei dimensiuni, dar a treia dimensiune este nivelul decizional cu privire la mersul proiectului (ceea ce nu a prins la specialisti!)

In ce priveste nivelul de la care se face analiza sistemului, in cadrul metodei Merise, acesta poate fi reprezentat de-a lungul axei etapelor CVDS, in sensul ca un nivel va cuprinde cel putin una din etapele CVDS, astfel ca pe latura verticala a matricii putem materializa atat etapele CVDS cat si nivelul la care trebuie vazut sistemul.

Pentru ilustrarea interferentei dintre metoda, CVDS, nivel si viziune prezentam mai jos matricea Merise completata nu cu obiective de studiat, ci cu conceptele specifice fiecarei etape, la nivelul corespunzator, pentru fiecare viziune sau aspect. Aceste tabele sunt utile numai pentru a surprinde mai usor interferenta tuturor aspectelor ce trebuie avute in vedere pe timpul proiectarii sistemelor informatice, dar indicatiile metodologice concrete sunt prea voluminoase pentru a fi stocate intr-o matrice.

In practica, activitatile dintr-un astfel de tabel ar trebui detaliate si comentate pe parcursul a catorva capitole. De regula fiecare etapa CVDS este tratata pe cate un capitol.

Cu privire la diversitatea modelelor ciclurilor de viata, trebuie sa tragem urmatoarele concluzii:

- modelele sunt diferite, in functie de tehnologiile folosite in procesul de realizare a sistemelor; un salt considerabil se observa in mediile orientate-obiect;

- modelele depind de marimea proiectelor dar si de domeniile de care apartin sistemele;

- la alegerea unui model trebuie sa tinem seama nu numai de ordinea in care se deruleaza etapele de elaborare a sistemului, ci si de proportia in care modelul presupune abordarea sistemului, adica pe parti sau global. Unele modele cum ar fi cel in cascada, presupune parcurgerea tuturor etapelor la nivelul intregului sistem, in timp ce modelul evolutiv de exemplu, permite derularea marii majoritati a etapelor pe parti/componente ale sistemului;

- alegerea modelului va depinde si de experienta echipei ce efectuiaza proiectarea sistemului;

- cerintele functionale isi pun de asemenea, amprenta pe tipul de model; sistemul poate fi abordat in intregime sau pe componente functionale;

- complexitatea sistemului se va reflecta in mare masura in tipul modelului selectat.

In afara de aspectele a caror interferenta in cadrul procesului de analiza si proiectare a sistemelor informatice a fost analizata mai sus, mai exista si alte aspecte a caror interferenta nu poate fi formalizata, dar trebuie luata in calcul de proiectantii de sisteme informatice. Este vorba de noutatile care s-au inregistrat in informatica pe planul tehnicilor de programare, a retelelor de calculatoare si mai ales in domeniul CASE.

In cursul precedent au fost enumerate cateva instrumente CASE asociate principalelor metodologii de elaborare a sistemelor informatice. Este bine ca atunci cand ne hotaram sa aprofundam o metodologie de elaborare a sistemelor informatice, sa ne informam daca dispune de instrumente CASE si daca acestea sunt accesibile. Bineinteles ca orice metodologie poate fi aplicata si fara a dispune de instrumentele CASE asociate acelei metodologii, dar daca se poate sa folosim si instrumentele CASE ritmul de munca va fi mult mai mare.

2. Modele reprezentative ale ciclurilor de viata ale dezvoltarii de sisteme (Optional)

Modelul cascada. Asigura trecerea de la o etapa la alta, in ordine secventiala.

Definirea

cerintelor

Analiza

Proiectarea

Implementarea

Testarea

Utilizarea si

intretinerea

Fazele sunt structurate pe activitati si subactivitati. Punctul sau slab este ca se aplica la nivel sistem si nu se poate trece la etapa urmatoare pana ce nu au fost aduse la zi toate aplicatiile; in practica se solicita decalaje intre aplicatii.

Modelul V. Latura din stanga este cea de la modelul cascada, iar pe cea din dreapta se realizeaza verificarile si validarile. Ea se parcurge ascendent.

Definirea

cerintelor

Proiectare Testare

sistem sistem

Proiectare Testare

subsistem subsistem

(componenta) (componenta)

Codificare

asamblare componente

Modelul incremental. Permite livrarea sistemului pe componente, dar si global. Definirea cerintelor si analiza se executa totusi la nivelul intregului sistem.

Este o metoda de tip top-down, ceea ce implica cunoasterea si formularea cerintelor pentru intregul sistem inca din faza encipienta de abordare a sistemului, chiar daca ulterior se vor rezolva doar parti din el. De regula adaugarea unei parti presupune testarea a tot ce este realizat pana in acel moment, ceea ce poate duce la modificari multiple ale componentelor realizate printre primele.

Definirea Proiectare Instalare

cerintelor componenta-1 componenta-1

Analiza Implementare Intretinere

componenta-1 componenta-1

Arhitectura --- ---

sistemului

Proiectare Instalare

componenta-n componenta-n

Implementare Intretinere

componenta-n componenta-n

Modelul spirala. Este modelul cel mai des folosit in toate domeniile proiectarii, acolo unde este vorba de obiective complexe.

Prototip-1

Prototip-2

Prototip-3

Prototip-4

Modelul evolutiv. Necesita efectuarea unei investigatii initiale pe baza careia sa se poata elabora o strategie de descompunere a proiectului in parti/segmente, fiecare cu o valoare deosebita pentru client.

Acestea sunt sunt realizate si livrate in mod iterativ si contribuie la sporirea

treptata a performantelor sistemului. Se are in vedere posibilitatea aplicarii unor

adaptari sau modificari ulterioare.

Studiul initial  Integrare

Descompunere  segmente

in segmente

Segment-1 Segment-2

Definire cerinte Implementare  Definire cerinte Implementare

Analiza Testare  Analiza  Testare

Proiectare  Utilizare Proiectare Utilizare 

Metoda are succes deoarece se bazeaza pe o arhitectura deschisa, flexibila, elaborata prin participarea tuturor partilor interesate, inclusiv a utilizatorilor si a unor specialisti profesionisti.

Modelul X. In partea de sus a X-ului este aplicat modelul cascada si V, iar in partea de jos sunt avute in vedere actiuni de valorificare a softului creat anterior. Aceasta preocupare este din ce in ce mai extinsa pe plan mondial si pare foarte rationala deoarece softul prezinta o mare suplete in ce priveste adaptarea de la o problema la alta. De fapt nu conteaza decat asemanarea structurilor, semnificatia variabilelor fiind la libera alegere a celui care foloseste softul.

In partea de sus, modelul ia in consideratie utilizarea unor specificatii de sistem, a proiectului arhitectural si de detaliu , codificarea, testarea pe componente, integrarea si testarea sistemului. Parte inferioara a X-ului este un V intors, pentru a sugera notiunea de gestiune patrimoniala a depozitelor reutilizabile la nivel componenta, structura, domeniu si chiar aplicatie.

Avand in vedere ca partea inferioara a modelului se aplica practic doar in fazele de proiectare fizica, modelul - ca si modelul tridimensional al autorilor metodei Merise, nu este prea popular. Dealtfel metoda Merise mai prezinta un model in doua dimensiuni in care pe abscisa este trecut sistemul actual si cel viitor, iar pe ordonata sunt trecute nivelele global, conceptual, organi-zational, logic, fizic si de exploatare, dar dupa cum s-a putut vedea, din cele prezentate in sectiu-nea 1 a acestui capitol, metoda Merise este aplicata de fapt pe un model in doua dimensiuni, sub forma de matrice care este foarte riguros si se preteaza la exigentele ingineriei softului.

3. Automatizarea dezvoltarii sistemelor prin instrumente CASE

Acronimul CASE vine de la de la Computer Aided System Engineering si are ca obiectiv punerea in practica a produselor- program de proiectare si realizare a softului cu ajutorul calculatorului. Instrumentele oferite de CASE (ca de exemplu EXCELERATOR, aparut pe la mijlocul anilor '80), sunt utilizabile din faza de definire a cerintelor pana la intretinerea fizica a sistemului informatic, dar prioritate au analiza si proiectarea bazate pe conceptele si metodele structurate. In ultimii ani, acestora li s-au adaugat analiza, proiectarea si programarea orientata pe obiecte. Instrumentele CASE implica utilizarea calculatorului ca mijloc de sustinere a activitatilor de planificare, definire, proiectare si realizare a softului. Ele se bazeaza pe logica structurata, pe descompunerea functionala si reprezentarea prin diagrame a fluxurilor de date ale aplicatiilor.

Mijloacele CASE realizeaza proceduri si metode ce prezinta diferente majore fata de metodele clasice si care se constituie in performate ale acestor produse, cum ar fi:

- prezentarea logicii de proiectare a sistemului;

- posibilitati de vizualizare a datelor;

- sprijin in definirea obiectivelor;

- definirea si utilizarea unor termeni de referinta;

- folosirea unui depozit partajat de date;

- usurinta efectuarii unor schimbari;

- realizarea unei documentatii flexibile si dinamice;

- aplicarea unor reguli de verificare a consistentei;

- folosirea reprezentarilor grafice simple;

- construirea de pseudocoduri structurate;

- sprijinirea modularizarii;

- folosirea pe scara larga a prototipurilor;

- constituirea unei interfete pentru generatoarele de coduri;

- construirea bibliotecilor de module si documente.

Pe masura evolutiei lor, sistemele CASE au devenit mai complexe, permitand ca procesele de proiectare si realizare a aplicatiilor sa se desfasoare intr-un mediu informatic interactiv, oferind utilizatorilor un intreg arsenal de instrumente si proceduri, prin care pot proiecta, realiza, testa, documenta, intretine/actualiza si exploata sistemul.

Utilizarea sistemelor CASE a inceput cu introducerea diagramelor fluxurilor de date, care fac posibila realizarea unui model al derularii proceselor sistemului/aplicatiei care se proiecteaza. A urmat folosirea dictionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicatia Au aparut ecranele predefinite pentru a prezenta ce poate sa obtina utilizatorul prin exploatarea sistemului. S-a apelat la facilitati grafice, care pot folosi simbolurile logicii structurate si care permit proiectantului sa realizeze o diagrama coerenta a fluxurilor de date.

Primele sisteme CASE erau un set de aplicati neintegrate, cu functii distincte, fara a fi interconectate. Aceste limite au fost eliminate, in cea mai mare parte, prin generatiile actuale, care incearca sa realizeze o integrare completa si usoara a tuturor elementelor, integrarea reprezentand de fapt, factorul cel mai imoprtant al metodologiei CASE.

CASE se bazeaza pe doua functii fundamentale:

- prima este bazata pe posibilitatea descompunerii de sus in jos (top-down) a sistemului informatic in procese si module distincte, fiecare avand definite responsabilitatile functionale si/sau operationale; odata cu orientarea spre obiecte, functiile se inlocuiesc cu obiectele care indeplinesc functia, ceea ce usureaza controlul procesului;

- a doua se refera la faptul ca sistemele informationale pot fi reprezentate intr-o forma grafica concisa, folosind cateva simboluri de baza

Importanta acestor functii rezida in posibilitatea utilizarii modularitatii aplicatiilor, a diagramelor, obtinerea unei documentatii privind realizarea, evaluarea arhitecturii si utilizarea sistemului.

Pentru definirea si construirea sistemelor, produsele CASE presupun stabilirea si respectarea unei anumite discipline. Metodologia ofera o interfata intre crearea si verificarea/validarea proiectului logic, dezvoltarea unei biblioteci cu documentatii, care include si integreaza caracteristicile proceselor si pasii de parcurs, pentru descrierea modului de lucru; ofera un model al produsului final, ce poate fi folosit in realizarea operatiilor de exploatare si intretinere a sistemului/aplicatiei si ofera o interfata pentru pastrarea evolutiei proiectului.

Folosirea reprezentarilor grafice in logica CASE ofera posibilitatea descompunerii aplicatiei in mai multe componente logice.

Prin atasarea unei baze de date la elementele grafice, se va obtine un depozit ce va contine pasii si functiile reprezentate in diagramele construite. Daca aceste elemente sunt corect stabilite, ele vor sta la baza descrierii proceselor, ce vor constitui procedurile de prelucrare a sistemului /aplicatiei.

Modelarea grafica in sistemele CASE prezinta o interactivitate ridicata, permitand construirea diagramelor, deplasarea de la o diagrama la alta , modificarea, extinderea, copierea, evaluarea si descrierea elementelor unei aplicatii. Modelele grafice permit conectarea fluxurilor logice intre activitatile si functiile specifice aplicatiei, relatii care pot fi testate si validate in mod automat.

Din punct de vedere al momentului in care a avut loc automatizarea fazelor din ciclul de viata al sistemelor, se considera ca analiza si proiectarea reprezinta faze superioare, adica au fost automatizate mai recent. Instrumentele CASE referitoare la aceste faze se numesc Upper CASE sau Front End, iar cele referitoare la fazele care au fost automatizate primele se numesc Lower CASE sau Back End.

Clasificarea instrumentelor CASE

Pentru ca exista instrumente CASE care nu pot fi legate de fazele ciclului de viata a dezvoltarii de sisteme, cele din categoria Upper si Lower CASE sunt denumite CASE Vertical, iar celelalte se numesc CASE Orizontal

Clasificarea instrumentelor CASE este data in tabelul de pe pagina urmatoare.

Caracteristicile mediilor moderne de tip CASE:

- reprezinta un set de instrumente specifice pentru realizarea sistemelor;

- diversitatea modurilor de interactiune;

- semnificatia reprezentarilor grafice;

- elemente de tip verificare si validare (V & V);

- natura bidirectionala, deplasari pe verticala in structura sistemului;

- deschiderea pentru interconectarea instrumentelor CASE;

- sprijin pentru lucru cu utilizatori multipli;

- descompunerea;

- performante de deplasare, pe orizontala, de la un instrument la altul;

- grade diferite de automatizare;

- integrare.

4. Cateva provocari ale tehnologiei informatice actuale

4.1 Programarea orientata pe obiecte. In cursul precedent este prezentat un scurt istoric al evolutiei analizei si proiectarii sistemelor prin metodologii orientate obiect, dar se cuvine o precizare: sintagma 'orientare-obiect' are acceptiuni diferite in diverse discipline: una in modelarea informatiilor, alta in programare si alta in analiza si proiectarea sistemelor. Pentru a proiecta si implementa soft orientat spre obiecte trebuie cunoscuta metoda de abordare specifica acestei paradigme si bineinteles un limbaj de programare adecvat.

Cat priveste utilizarea acestei orientari in analiza si proiectarea sistemelor, trebuie subliniat ca actualele SGBD de tip Visual, in speta Visual Fox si Access sunt foarte usor de manevrat, mai ales ca bazele de date din aceste medii de programare se realizeaza sub forma de baze de date relationale, iar utilizarea obiectelor se face foarte subtil, la nivel camp. Obiectele intervin vizibil numai in realizarea controalelor. Totusi pentru cei care cunosc programarea pe obiecte este pacat sa nu stie sa foloseasca si proiectarea obiectuala a sistemelor informatice, mai ales ca exista si instrumente CASE bine puse la punct si pentru metodologiile orientate obiect (Rational Rose, Visual Modeler, etc.)

4.2 Aparitia aplicatiilor si a bazelor de date multimedia, mai ales in legatura cu bazele de date distribuite sau cu comunicatiile pe WWW, este o chestiune care trebuie sa ne puna in stare de veghe si daca sistemul la care lucram o impune, trebuie sa avem in vedere si alte aspecte cum ar fi reclama pe Internet, utilizarea paginilor WEB, e-learning, punerea la dispozitia utilizatorilor a unui help profesionist, documentatie online, s. a.

4.3 Un element deloc lipsit de importanta este softul pe care vom realiza si pe care va fi implemetat sistemul informatic (este vorba de interfata grafica/sistem de operare si de SGBD). Poate este util de stiut ca in tarile occidentale se lucreaza mai mult sub UNIX si LYNUX si mai rar sub Windows, iar ca SGBD se foloseste foarte mult - ORACLE. Pentru o aplicatie care sa reziste 'afara', vom folosi daca nu UNIX sau LYNUX cel putin Windows NT.

4.4 Aparitia inteligentei artificiale. Aceasta, in ciuda valului de 'elita' in care este infasurata nu trebuie sa-i alerteze prea mult pe realizatorii de sisteme informatice obisnuite pentru ca acestea se pot realiza si fara inteligenta artificiala, dar daca se pune problema unor aplicatii menite sa coordoneze procese, sau sa ofere mijloace de invatare cu ajutorul calculatorului, sau sa operam activ pe Internet, atunci s-ar putea ca apelarea la inteligenta artificiala sa fie inevitabila. De aceea, inainte de a incepe detalierea etapelor de proiectare a sistemelor informatice, vom dedica cate un curs sistemelor support de decizie si respectiv sistemelor expert.

5. Rolul sistemelor informatice in conducerea

organizatiilor economice

Remarcam faptul ca in conditiile create de Internet, sistemul informatic se detaseaza de intreprindere si chiar iese din cadrul ei facand legatura directa cu bancile, cu furnizorii si ofera conducerii date despre miscarile pe care le executa concurenta. Conducerea intreprinderii moderne nu se mai multumeste cu o informare operativa ci doreste prognoze, doreste sa prevada viitoarele miscari ale concurentei si viitoarea evolutie a pietei tinand cont de ceea ce se petrece in prezent. Deaceea chiar daca nu proiectam sisteme suport de decizie sistemele informatice moderne trebuie sa iasa din perimetrul intreprinderii.

In [1] Dumitru Oprea vede relatia sistemului informatic cu intreprinderea ca in figura de pe pagina urmatoare.

Date

Concepte de baza ale proiectarii sistemelor informatice

  2. METODE SISTEMICE DE PROIECTARE

2.1. Nivele de abstractizare si modelare

Modele

2.2. Modelarea conceptuala a datelor. Modelul entitate-asociere.

2.2.1. Concepte de baza

Entitate:

- reprezentarea unui 'obiect' concret sau abstract care:

- apartine spatiului problemei de rezolvat (face parte sau este relevant

pentru realitatea observata);

- are o existenta de sine statatoare;

- poate fi identificat in raport cu celelalte obiecte de acelasi tip.

Exemple: angajat, produs, utilaj, operatie tehnologica, client, factura

O entitate este reprezentata printr-un ansamblu de atribute.

Atribut: caracteristica sau proprietate a unei entitati, semnificativa pentru spatiul problemei de rezolvat.

Exemplu:

Entitatea este perceputa aici ca un tip de "obiecte". Fiecare obiect individual constituie o realizare a entitatii respective.

Atributele au, la randul lor, aceeasi conotatie tipologica, in sensul ca despre orice realizare a unei anumite entitati se cunosc aceleasi atribute, dar pentru fiecare dintre acestea continutul sau valoarea atributelor respective difera.

Tip de valori: un anumit ansamblu de valori, definite fie printr-o proprietate fie printr-o enumerare.

Exemplu:

Stare civila = (necasatorit, casatorit, vaduv, divortat)

Zile lucratoare = (luni, marti, miercuri, joi, vineri)

An studii = (a : a intreg, 1 £ a £ 5)

Un atribut poate fi:

- simplu: atunci cand pentru o entitate sau o asociere poate lua o singura valoare;

- repetitiv: daca pentru o entitate sau o asociere poate lua mai multe valori (ex: limbi straine cunoscute)

Reguli privitoare la atribute:

1. fiecare atribut poate apare intr-o singura entitate (principiul nonredondantei)

2. un atribut poate avea numai valori elementare.

Exemplu incorect: deoarece 'prenume copii' poate avea mai multe valori pentru o anumita persoana.

Identificatorul entitatii: un atribut sau un grup de atribute care primesc valori unice pentru fiecare realizare a entitatii respective si pot servi astfel pentru identificarea fara echivoc a acestora.

Pentru simplitate se recurge frecvent la coduri care sunt atribute construite special astfel incat sa raspunda cerintelor de identificare (ex: marca salariat) sau la atribute de tip 'numar de ordine' sau 'numar de aparitie' (ex: numarul de inventar al unui mijloc fix).

In reprezentarea grafica, identificatorul entitatii se subliniaza.

Asocierea: reprezentarea legaturii sau corespondentei existente intre doua sau mai multe realizari de entitati.

O asociere nu are existenta de sine statatoare, depinzand de existenta realizarilor de entitati pe care le leaga.; in consecinta, nu are identificatori specifici.

O asociere poate avea atribute proprii.

Entitatile care participa la o asociere constituie colectia acesteia.

Numarul de entitati care participa la o asociere formeaza dimensiunea sau gradul acesteia (mai mare sau egala cu numarul de entitati al colectiei).

Cardinalitatea minimala / maximala exprima modul de participare al realizarilor fiecarei entitati la asociere ( valori uzuale:0,1; 1,1; 0,n; 1,n ).

Reprezentarea grafica:

Intre realizarile acelorasi entitati pot exista mai multe asocieri diferite, cu semantica si cardinalitati distincte.

Asociere reflexiva: o asociere care leaga realizari diferite ale aceleiasi entitati (colectie = 1). In asemenea cazuri, este indispensabila specificarea in schema a rolurilor jucate de entitate.

Rol al entitatii nume care serveste pentru a desemna participarea entitatii la o asociere.

Restrictii de integritate: reguli suplimentare, nereprezentabile direct in formalismul EA, care trebuie respectate permanent de date.

Restrictii de integritate structurale: inerente conceptelor folosite la modelare:

- integritatea entitatii: valorile luate de identificatorul entitatii trebuie sa fie unice si nenule;