METODOLOGII DEARE A SISTEMELOR INFORMATICE

METODOLOGII DE PROIECTARE A SISTEMELOR INFORMATICE

Complexitatea tot mai ridicata a activitatilor economice, modificarea continua si rapida a cerintelor si a obiectivelor, precum si instabilitatea in timp a proceselor desfasurate in cadrul organizatiilor, au impus necesitatea stabilirii unor modalitati noi de abordare a problematicii ciclului de dezvoltare, denumite si metodologii de proiectare a sistemelor informatice. in acest context, se apreciaza ca, in prezent, pe plan mondial, exista cateva sute de astfel de metodologii de proiectare, a caror definitie, conform lui Avison si Fitzgerald[5], este prezentata in continuare.

O metodologie de proiectare proiectare reprezinta o colectie de proceduri, tehnici, instrumente si documentatii care pot fi utilizatede cafre o echipa de proiect in procesul de realizare a unui sistem informatic.

Desi, dupa cum s-a precizat, exista un numar mare de metodologdii de proiectare, acestea prezinta o serie de caracteristici comune:

reflecta o anumita modalitate de abordare a ciclului de dezvoltare a sistemului informatic;

structureaza procesul de proiectare in etape, faze, activitati si sarcini individuale;

utilizeaza un set de reguli de formalizare a componentelor sistemului informatic si foloseste un instrumentar de tehnici, proceduri, norme si standarde specifice;

se subordoneaza strategiei de realizare a sistemului informatic prin prisma modalitatilor de conducere a proiectului si a modului de utilizare a resurselor financiare, umane si materiale;

practica un anumit tip de abordare sistemica.

O prima clasificare a metodologiilor de proiectare, propusa de Avison si Fitzgerald[5j, imparte metodologiile in patru clase, in functie de specificitatile si cerintele activitatii sau sistemului pentru care se doreste proiectarea :

Clasa 1 Clasa metodologiilor utilizate la nivelul unor procese bine structurate si relativ stabile in timp, pentru care se cunosc obiective clare si cerinte bine specificate. Aceste metodologii utilizeaza abordarea clasica de tip SDLC (System Development Life Cycle).

Clasa2 Clasa metodologiilor utilizate la nivelul unor procese bine structurate si relativ stabile in timp, pentru care se cunosc obiective clare, insa pentru care cerintele sunt incerte. Aceste metodologii, precum STRADIS, MERISE sau SSADM, utilizeaza modelarea datelor si proceselor si incearca astfel sa rezolve limitele abordarii traditionale de tip SDLC.

Clasa3 Clasa metodologiilor utilizate la nivelul unor procese slab structurate si instabile in timp, pentru care obiectivele sunt neclare. Din aceasta clasa de metodologii, cea mai reprezentativa este SSM (Soft System Methodology), dezvoltata in cadrul Universitatii din Lancaster.

Clasa 4 Clasa metodologiilor utilizate atunci cand exista o puternica interactiune a sistemului cu utilizatorii. Metodologiile din aceasta clasa pornesc de la premisa ca, in procesul de proiectare a unui sistem informatic trebuie luat in considerare atat factorul tehnic, cat si cel uman. Cea mai reprezentativa este ETHICS (Effective Technical and Human Implementation & Computer-based Systems).

O a doua clasificare, imparte metodologiile in doua mari clase, in functie de modalitatea de abordare a sistemelor :

Clasa 1 Clasa metodologiilor cu abordare structurata (SSADM,

MERISE, JSD, STRADIS).

Clasa 2 Clasa metodologiilor cu abordare orientata pe obiect (OMT,

UML, OOD, OOA, OOSA).

Metodologiile cu abordare structurata prezinta o serie de caracteristici legate de modul de organizare a datelor si informatiilor:

abordeaza sistemul intotdeauna prin prisma subsistemelor sale, delimitate, de regula, folosind criteriul functiunii;

asigura modelarea datelor separat de modelarea procedurilor;

utilizeaza diagrame si tehnici de modelare specifice;

proiectarea sistemului se face pornind de la premisa ca acesta nu

este unul izolat, ci se afla in continua interactiune cu alte sisteme

din mediul extem al organizatiei.

intre avantejele utilizarii acestor metodologii in procesul de realizare a sistemelor informatice pentru management, enumeram:

utilizeaza reprezentari grafice sugestive, usor de interpretat de catre analisti si beneficiari;

asigura o planificare eficace a proiectului prin divizarea sa in subsisteme;

reducerea timpului si costurilor de dezvoltare a sistemului, prin luarea in considerare de la inceput a tuturor cerintelor si prin interactiunea continua cu beneficiarul;

modificarea anumitor activitati din cadrul sistemului nu impune

reluarea integrala a studiului.

Metodologiile cu abordare orientata pe obiect prezinta drept caracteristici:

grupeaza activitatilor in etape in functie de omogenitatea acestora si de obiectivele urmarite;

realizeaza o documentatie de sistem care constituie mijlocul de comunicare intre diferitele categorii de personal antrenate in activitatea de realizare si exploatare a acestuia;

asigura modelarea sistemului, utilizand, in general, trei tipuri de modele: static, dinamic si functional. Dintre avantajele metodologiilor din aceasta clasa subliniem:

datele si prelucrarile nu mai sunt reprezentate distinct, ci incapsulate in clase de obiecte

modelele utilizate sunt flexibile si usor de intretinut;

imbunatatirea comunicarii intre utilizatori, analisti, proiectanti si programatori.

1 SSADM

SSADM (Structured Systems Analyses and Design Methodology) este o metodologie de proiectare creata pentru administratia publica fiind fost lansata de catre Agentia Centrala de Informatii si Comunicatii si utilizata ca metodologie standard de catre guvernul Marii Britanii inca din anul 1981. Instrumentarul metodologic a fost modernizat si revizuit de mai multe ori, in prezent ajungandu-se la varianta SSADM 4++.

Principiul de baza utilizat este cel al proiectarii 'in cascada', conform caruia o etapa nu poate sa inceapa inainte de finalizarea si acceptarea de catre beneficiar a tuturor fazelor care o preced.

In   general, utilizarea SSADM presupune parcurgerea urmatoarei succesiuni de etape[31]:

a. Realizarea studiului de fezabilitate din care sa rezulte oportunitatea

proiectarii sistemului informatic.

b.      Analiza cerintelor functionale care stau la baza noului sistem.

c.       Elaborarea specificatiilor viitorului sistem si stabilirea arhitecturii

hardware si software necesara pentru asigurarea functionalitatii

sale.

d. Proiectarea fizica prin elaborarea specificatiilor de program si

definirea bazei de date. SSADM utilizeaza o serie de concepte asemanatoare cu cele folosite, in general, de metodologiile de proiectare a sistemelor informatice pentru management (tabelul nr. 5.5).

Tabelul nr. 5.5 Concepte utilizate in metodologia SSADM

Principalul avantaj al utilizarii SSADM il reprezinta faptul ca metodologia include un instrumentar puternic pentru modelarea datelor si proceselor, realizata pe trei nivele[31j :

Modelarea logica a datelor, care reprezinta procesul de identificare si definire a cerintelor unui sistem informational.

Modelarea fluxurilor de date, care asigura procesul de identificare, si definire a fluxurilor informationale.

Modelarea entitate/eveniment, care asigura identificarea si definirea evenimentelor care pot afecta fiecare entitate si a momentelor in care acestea apar.

Astfel, SSADM permite cunoasterea amanuntita a sistemului existent, structurarea unui volum mare de date, gestionarea ordonata a unor sisteme de mari dimensiuni si asigura un grad ridicat de flexibilitate a sistemului proiectat.

Trebuie subliniat insa ca, in acelasi timp, utilizarea in practica a metodologiei prezinta si o serie de dezavantaje, generate de costurile ridicate de implementare si adeseori, de subestimarea acestora.

2 MERISE

MERISE(Methode d'Etude et de Realisation pour les Systemes d'Entreprise) este o metodologie structurata de proiectare, dezvoltare si realizare a sistemelor informatice, bazata pe abstractizarea si separarea datelor si procedurilor cu ajutorul unor seturi de modele conceptuale si fizice. Ea a fost creata in anul 1977, la cererea Ministerului Industriilor din Franta, ca urmare a lipsei unui instrumentar de metode si tehnici care sa permita dezvoltarea de sisteme informatice cu functionare in timp real, atat la nivelul companiilor private cat si la nivelul institutiilor publice.

In cadrul MERISE, conceptul de sistem informatic este abordat etapizat el trebuind sa reflecte un sistem informational functional, parte a unei realitati fizice. Trecerea de la sistemul informational carcterizat printr-un numar ridicat de proceduri manuale la unul preponderent automatizat, presupune parcurgerea urmatoarelor etape[31]:

definirea cerintelor;

elaborarea modelului conceptual;

elaborarea modelului logic;

elaborarea modelului fizic.

l.Definirea cerintelor

Corespunde practic, etapei de analiza din cadrul ciclului de dezvoltare a sistemelor informatice si presupune identificarea procedurilor ce urmeaza a fi automatizate, constand in doua faze:

inventarierea informatiilor necesare pentru functionarea viitorului sistem informatic;

structurarea informatiilor in functie de potentialii beneficiari ai acestora.

2.Elaborarea modelul conceptual

Aceasta etapa este compusa din trei faze:

elaborarea modelul conceptual al comunicarii;

elaborarea modelul conceptual al datelor;

elaborarea modelul conceptul al prelucrarilor.

2.1.Elaborarea modelului conceptual al comunicarii

Cuprinde urmatoarele etape:

a.Identificarea actorilor externi, respectiv a elementelor din mediul extern care interactioneaza cu organizatia (figura nr. 5.2).

Figura nr. 5.2. Interactiunile existente intre organizatie si actorii din mediul extern

b) Identificarea actorilor interni, adica a entitatilor organizatorice din cadrul sistemului (figura nr. 5.3)

Figura nr. 5.3 Relatiile functionale stabilite intre actorii interni ai organizatiei

c) analiza fluxurilor informationale, care presupune crearea a doa categorii de diagrame:

diagrama de context, care reflecta fluxurile informationale dintre organizatie si actorii externi (fig. Nr. 5.4)

Figura nr 5.4 Diagrama de context a sistemului informational al organizatiei

diagrama conceptuala de flux, care extinde diagrama de context prin descompunerea organizatiei in actori interni

Figura nr. 5.5 Diagrama conceptuala de flux a sistemului informational al organizatiei

2.2 ELABORAREA MODELULUI CONCEPTUAL AL DATELOR

In procesul de elaborare a modelului conceptual se utilizeaza urmatoarele notiuni:

Tabelul nr. 5.6. Notiuni utilizate pentru elaborarea modelului conceptual in cadrul metodologiei MERISE

Figura nr. 5.6 reflecta modul in care modelul conceptual al datelor reflecta asocierea existenta intre doua entitati (Beneficiar si Serviciu), pe baza atributelor acestora (nume, prenume, data nasterii, adresa pentru beneficiar, si respectiv denumire si persoana de contact pentru serviciu).

Figura nr. 5.6. Descrierea asocierilor existente intre entitati folosind modelul conceptual al datelor.

2.3 ELABORAREA MODELULUI CONCEPTUAL AL PROCEDURILOR

Are drept scop reprezentarea schematica a activitatilor desfasurate in cadrul unui sistem, fara a face insa referire la deciziile adoptate sau la mijloacele de executie (fig. Nr. 5.7.) utilizeaza urmatoarele concept:

Figura nr. 5.7 Modelul conceptual aferent procedurii de solicitare si obtinere a unei autorizatii

3.ELABORAREA MODELULUI LOGIC

Presupune elaborarea structurii de tabele, fara insa a se face referire la un limbaj de programare, desfasurandu-se in doua etape:

a.  Construirea unui tabel pentru fiecare entitate identificata anterior. In aceasta situatie, atributele entitatii devin campuri, instantele devin inregistrari, iar identificatorii entitatilor devin chei primare ale tabelelor.

b.  Amplasarea informatiilor de legatura intre entitati prin intermediul unor campuri denumite chei externe. Alegerea tabelului care va contine cheia externa se face in functie de tipul asocierilor stabilite intre entitati.

4.ELABORAREA MODELULUI FIZIC

Are drept obiectiv implementarea modelului logic intr-un Sistem de Gestiune a Bazelor de Date.

Gruparea datelor si asocierilor in module.

4 UML

Primele metodologii de proiectare cu abordare orientata pe obiect au aparut la inceputul anilor '80. in anul 1989 existau 10 astfel de metodologii, pentru ca in anul 1994, numarul lor sa depaseasca 50. La momentul respectiv, insa, nici una din metodologii nu satisfacea complet cerintele utilizatorilor, astfel ca s-a pus problema unificarii acestora in vederea dezvoltarii unei noi metodologii, care sa utilizeze un instrumentar unitar de instrumente, tehnici si documentatii.

in vederea realizarii acestui obiectiv, in 1994, o echipa de specialisti ai companiei Rational Software Corporation a inceput procesul de unificare a metodologiilor Booch si OMT (Object Modeling Technique). In urma acestui efort, a fost dezvoltata metodologia OOSE (Object-Oriented Software Engineering), prin a carei perfectionare ulterioara s-a dezvoltat, in 1996, metodologia UML (Unified Modeling Language).

Principalele concepte utilizate m UML sunt[56]:

Tabelul nr. 5.8 Definirea principalelor concepte utilizate in UML

Utilizarea metodologiei ofera posibilitatea dezvoltarii unei documentatii de sistem usor de inteles atat de furnizor cat si de beneficiar, pe tot parcursul celor trei mari etape ale realizarii sistemelor informatice: analiza, proiectarea si implementarea. in acest sens, UML utilizeaza un numar mare de diagrame, organizate dupa cum urmeaza[56]:

Diagrame statice.

Diagrame de cazuri de utilizare, care asigura reprezentarea intr-o forma grafica a actorilor, cazurilor de utilizare si a relatiilor intre acestea. Aceste relatii sunt de doua tipuri : de extindere si de utilizare.

Diagrama claselor, care precizeaza clasele existente si relatiile dintre acestea, nu insa si modul in care acestea interactioneaza pentru a asigura un anumit comportament al sistemului.

Diagrama obiectelor reprezinta descrierea unui set de obiecte si a relatiilor existente intre acestea la un anumit moment. Aceste diagrame se folosesc in vederea modelarii statice a unui sistem, la fel ca si diagramele de clase, abordarea facandu-se insa, din perspectiva obiectului.

2. Diagrame dinamice.

a.  Diagrama de secventa, care transforma evenimentele identificate in scenariile cazurilor de utilizare, intr-o reprezentare grafica a utilizarilor sistemului de catre actor. Descrie cronologic interactiunile dintre obiecte, identificand mesajele schimbate intre obiecte ca raspuns la un eveniment, impreuna cu secventa mesajelor.

b. Diagrama de stare, care identifica evenimentele care realizeaza tranzitia unui obiect dintr-o stare in alta.

c.  Diagrama de colaborare, care releva legaturile de colaborare existente in cadrul unui grup de obiecte. Deoarece permite focalizarea asupra unei anumite clase, diagrama de colaborare ajuta la rafinarea diagramei claselor, adaugand atribute si operatii.

d.  Diagrama de activitate, care permite o mai buna intelegere a detaliilor din cadrul unei operatii a unei clase. Diferenta dintre diagrama de stare si cea de activitate consta in faptul ca un grafic de stare reprezinta intregul obiect, in timp ce o diagrama de activitate evidentiaza actiunile si rezultatul acestor actiuni asupra obiectului.

3. Diagrame arhitecturale.

a.  Diagrama componentelor, care colecteaza informatiile din diagrama claselor pentru a crea componente. Modeleaza dependenta componentei software in functie de codul sursa, codul binar si componentele executabile.

b. Diagrama de desfasurare, care realizeaza amplasarea componentelor pe echipamente hardware.

c. Diagrama pachetelor, care grupeaza elementelor din cadrul diagramelor, prin intermediul pachetelor. intr-un pachet pot fi ambalate alte pachete, clase, cazuri de utilizare, colaborari etc. Un pachet este un mecanism destinat unor scopuri generale, care organizeaza elementele in grupuri.

Utilizarea unor astfel de instrumente complexe a facut ca UML sa fie cea mai utilizata metodologie de proiectare pe plan mondial. Aceasta se datoreaza si avantajelor pe care le ofera furnizorilor si beneficiarilor de software[31]:

Punerea la dispozitia utilizatorilor a unui limbaj de modelare vizual expresiv si usor de utilizat.

Asigurarea unor mecanisme de specializare care sa permita dezvoltarea ulterioara a componentelor sistemului.

Crearea instrumentarului necesar pentru formularea de specificatii independente de limbajul de programare utilizat.

incurajarea pietei instrumentelor orientate pe obiect