34 CAPITOL 2 METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC 2.1. Cerinţe generale în utilizarea unei metode de proiectare a sistemului informatic Evoluţia tehnologică presupune o anumită infrastructură care trebuie să cuprindă pe lângă hardware, produse şi sisteme informatice bazate pe noi sisteme de gestiune a bazelor de date sau pe noţiunea de teletransmisie materializată prin reţele naţionale de date cu rate de transfer cât mai mari; posturi de lucru la toate nivelele operaţionale dintr-o unitate (sisteme interactive om–maşină). Mediile economice trebuie să se adapteze rapid la aceste tehnologii care presupun costuri relativ ridicate ocazionate de elaborarea şi întreţinerea produsului informatic, dar şi dificultăţilor crescânde de menţinere la anumite standarde a nevoilor utilizatorilor. Necesitatea adaptării devine stringentă în mediul financiar–contabil care priveşte schimbările într-un orizont de timp ca pe o protecţie a investiţiei. Continua dezvoltare a domeniului tehnologiei informaţiei impune elaborarea de noi metodologii pentru realizarea sistemelor de aplicaţii informatice, cristalizându-se în analiză şi proiectare două tipuri de metode utilizate: tradiţionale (structurate, orientate pe funcţii/date, metode sistemice) şi metode orientate obiect.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
34
CAPITOL 2
METODE MODERNE DE PROIECTARE A UNUI
SISTEM INFORMATIC
2.1. Cerinţe generale în utilizarea unei metode de proiectare a sistemului
informatic
Evoluţia tehnologică presupune o anumită infrastructură care trebuie să cuprindă pe
lângă hardware, produse şi sisteme informatice bazate pe noi sisteme de gestiune a
bazelor de date sau pe noţiunea de teletransmisie materializată prin reţele naţionale
de date cu rate de transfer cât mai mari; posturi de lucru la toate nivelele
operaţionale dintr-o unitate (sisteme interactive om–maşină).
Mediile economice trebuie să se adapteze rapid la aceste tehnologii care presupun
costuri relativ ridicate ocazionate de elaborarea şi întreţinerea produsului
informatic, dar şi dificultăţilor crescânde de menţinere la anumite standarde a
nevoilor utilizatorilor.
Necesitatea adaptării devine stringentă în mediul financiar–contabil care priveşte
schimbările într-un orizont de timp ca pe o protecţie a investiţiei.
Continua dezvoltare a domeniului tehnologiei informaţiei impune elaborarea de noi
metodologii pentru realizarea sistemelor de aplicaţii informatice, cristalizându-se în
analiză şi proiectare două tipuri de metode utilizate: tradiţionale (structurate,
orientate pe funcţii/date, metode sistemice) şi metode orientate obiect.
35
Aportul fiecărei metode concretizat printr-un limbaj comun utilizator–informatician
este manifestat pe parcursul întregului proces de studiu prin apariţia şi existenţa
punctelor de validare.
Metoda, produs al reflexiei permanente, constituie un demers raţional şi empiric,
deductiv şi inductiv. Conform unor specialişti, metoda reprezintă un „ansamblu de
mijloace industriale puse în practică pentru organizarea unei fabricaţii” sau un
„ansamblu de reguli, principii normative care corespund învăţământului, practicii şi
artei” 14 . Ea se aplică tuturor conceptelor create de tehnologie, care observă şi
analizează practica cotidiană din organizaţii. Retrospectiv se constată că evoluţia
tehnologiei informatice15 are un impact important asupra metodelor de producere a
sistemelor informatice.
Un alt aspect care trebuie remarcat este faptul că o metodă nu poate servi scopuri
fundamentale divergente. Marea varietate de soft-uri disponibile (sisteme logice,
sisteme de gestiune în timp real) şi dezvoltarea activităţii de producţie software, mă
conduc la ideea că în informatică o metodă universală nu este posibilă.
Orice metodă de concepţie a unui sistem informatic trebuie să ia în considerare
factorii de natură tehnică şi socio-economică. În domeniul tehnic trebuie să permită
derularea activităţilor în timp real, utilizarea bazelor de date, a instrumentelor mini
şi micro-informatice pe fondul resurselor materiale, umane existente sau atrase.
În domeniul social şi economic metoda trebuie să integreze obiectivele unor
categorii de agenţi care urmăresc descentralizarea deciziilor operative; simplificarea
sarcinilor şi ameliorarea ergomiei postului de lucru; securitate şi confidenţialitate;
dezvoltarea proceselor de gestiune prin creşterea posibilităţii de supervizare la
diverse nivele; supleţe tehnică şi comercială sau structurală strict necesară în situaţii
de fuziune, extindere.
Metoda vizează asocierea eficientă a aspectelor organizaţionale şi informatice;
creşterea calităţii relaţiilor utilizatori–informaticieni, reprezentând un mijloc comun
de studiu, concepţie, dialog, formalizare a deciziilor şi de control preventiv. Cu alte
14 Le Nouveau Petit Le Robert, Edition 1993 15 O’Brien J. - Systèmes d’information de gestion, De Boeck Université
36
cuvinte, metoda în cadrul unui organism economic trebuie să fie un mijloc precis,
eficace, suplu dar nu rigid.
2.1.1. Parametrii specifici de performanţă pentru sistemele informatice
Calitatea informaţiilor determină în mare măsură performanţele compartimentului
financiar-contabil, atingerea obiectivelor pe care firma şi le-a propus. Există două
abordări ale performanţei: una ce dezvoltă o situaţie stabilă a sistemului şi o alta
care pune în valoare dinamismul, noutatea în domeniul considerat. În cazul unor
schimbări apare problema determinării valorii informaţiei noi; definită prin efectul
deciziei posibile de adoptat. Existenţa stabilităţii mediului informaţional induce
aprecierea globală a sumei atuurilor sistemului informatic financiar-contabil
(S.I.F.C.).
Pentru un control eficient al modului de realizare al sarcinilor stabilite apreciez că
există două soluţii: funcţionarea controlului intern de gestiune; reconsiderarea rolul
tabloului de bord şi a bugetelor.
În acest context propun abordarea compartimentului financiar-contabil în trei
ipostaze (figura 2.1.):
Figura 2.1 Compartimentul financiar-contabil prin prisma costului, profitului, investiţiei
37
a) centru de costuri unde utilizatorii decidenţi şi managerul îşi asumă
responsabilităţi sporite în gestionarea a costurilor, iar performanţele vor fi judecate
prin capacitatea de a micşora ecarturile raportate la costurile previzionale, de a
sporii productivitatea şi de a propune soluţii (acţiuni) generatoare de profit.
b) centru de profit scoate în relief faptul că deşi profitul obţinut de contabilitatea
informatizată nu este autentificabil în sine, trebuie să considerăm că ea este un
prestator de servicii ce se adresează unor beneficiari bine identificaţi.
Opinia mea este că profitul mediului contabil este indus de beneficiile obţinute de
celelalte segmente ale firmei sau de aceasta ca urmare a folosirii produselor
informatice. Rezultatele obţinute pot fi apreciate, extrem de clar prin relaţia:
număr de lucrări (aspect cantitativ), « timp » conţinut lucrare (aspect calitativ).
c) centru de investiţie vizează contabilitatea informatizată care trebuie să câştige
autonomie în efectuarea investiţiilor (informatice) şi apoi se impune să le justifice.
Pentru zona contabilă informatizată putem vorbi de reliefarea unor plusuri
cantitative (economice) şi calitative (politice). În legătură cu primul aspect consider
că viteza de circulaţie a informaţiei, dar şi capacitatea ei de adaptare se pot constitui
în resurse importante. Remarc două faţete ale acestui tip de performanţă:
♦ Câştigurile directe de productivitate permit executarea unei aceleiaşi
atribuţii (decizii), cu mijloace reduse. De exemplu: o suprafaţă ocupată mai
mică, utilizatorii decidenţi mai puţini, costuri ale hardului, softului sau reţelei
mult diminuate.
♦ Creşterea volumul activităţilor financiar-contabile, unde informaţia
suplimentară poate avea un impact pozitiv asupra domeniului contabil
informatizat, dar numai în măsura în care are „desfacerea asigurată”.
Performanţele politice (calitative) sunt mult mai greu de evidenţiat sau mai
ales de comensurat.
Consider că cele mai importante obiective ale unei metode sunt:
♦ flexibilitatea sistemului;
38
♦ satisfacţia utilizatorilor;
♦ calitatea produselor financiar-contabile.
Flexibilitatea reprezintă capacitatea de adaptare a structurii contabilităţii
informatizate la mediu. Un sistem deschis, cu numeroase puncte de „ascultare” şi cu
o grijă deosebită pentru comunicaţie (orală, scrisă sau electronică) va reacţiona
rapid la oportunităţi şi va putea să ţină cont de restricţii. Flexibilitatea se va aprecia
prin raportarea la un anumit obiectiv, fixat în cadrul unei evoluţii „istorice”.
Sistemul deschis va avea în vedere şi practicile agenţilor economici16.
Satisfacţia utilizatorilor decidenţi reprezintă criteriul de apreciere a performanţei
sociale stabilit de „actorii” participanţi la procesul productiv creativ.
Calitatea produselor financiar–contabile este apreciată subiectiv de diferiţii
beneficiari: clienţi, bancă, manageri etc., dar şi obiectiv - prin deducerea „deşeurilor
informaţionale”, a erorilor etc. Depinde foarte mult de aşteptările diverşilor
consumatori (din interiorul sau exteriorul firmei), dar şi de sistemul de producţie
financiar – contabil în „ansamblu (inclusiv modalităţile de control).
În continuare voi prezenta câteva criterii de apreciere a performanţelor zonei
contabile informatizate pe care, după părerea mea, le consider esenţiale:
a) criteriile de natură tehnică au în vedere conţinutul sistemului, capacitatea
acestuia de a îndeplini funcţii specifice. Vor fi luate în considerare atât aspectele
legate de producerea de informaţii utile, cât şi cele ce privesc gestiunea sistemului şi
a firmei.
b) criteriile organizaţionale reduc incertitudinile sistemului informatic financiar-
contabil şi permit grefarea pe structura acestuia. Creşterea capacităţii lui de
prelucrare ori gradul său de deschidere va determina modificări structurale ce se
impun a fi pe deplin stăpânite. Apreciez că fiind necesară analiza evoluţiei şi a
adaptărilor prin prisma următoarelor stări ale structurii:
- specializare - gradul în care activităţile financiar-contabile sunt divizate pe „roluri"
specializate, în funcţie de pregătirea utilizatorilor decidenţi.
39
- standardizare - măsura în care sunt stabilite reguli şi proceduri generale pentru a
defini sarcinile de executat şi a controla aplicarea lor. Informatizarea contabilităţii
duce la crearea de noi proceduri, le elimină pe cele redundante sau neutilizate.
- formalizarea - nu este legată implicit de noile tehnologii, depinzând uneori de
gradul de pregătire al utilizatorilor decidenţi.
- centralizarea - vizează importanţa acordată luării deciziilor de către manager,
urmărindu-se să nu se accentueze fenomenul birocratic. În categoria criteriilor
organizaţionale de apreciere a performanţelor segmentului financiar–contabil
informatizat cred că se impune a fi inclusă şi măsurarea gradului de schimbare. În
acelaşi timp este importantă şi cunoaşterea atitudinii utilizatorilor decidenţi, în
vederea anticipării unei eventuale reacţii de respingere (putându-se folosi în acest
sens metodologia CRIG).
c) criteriile economice - utilizarea lor are în vedere tipul proiectului şi etapa
procesului de decizie. După părerea mea există două mari categorii de repere în
stabilirea dimensiunii contabilităţii informatizate: unele ce îşi propun să urmărească
costurile şi avantajele (metode a posteriori) şi altele care doresc să efectueze
demersuri pentru o analiză complexă în vederea alegerii investiţiei (metode a
priori).
Consider că, pentru zona contabilităţii informatizate, putem pune în evidenţă mai
multe praguri şi măsurări ale eficienţei:
♦ coeficientul eficienţei globale a sistemului informatic financiar-contabil
(Keg):
Keg = (Ec + As) / (Chi + Che) unde:
Ec - economii rezultate prin introducerea tehnologiilor informatice şi de
comunicaţie.
As - acumulările suplimentare;
Chi - cheltuieli de implementare;
16 Transition from the „data/processing”, www.softeam.com/conseil_modelisation
40
Che – cheltuieli de exploatare a sistemului.
Calea principală de creştere a eficienţei sistemelor informatice este reducerea
cheltuielilor prin:
• utilizarea de elemente standardizate şi tipizate;
• elaborarea bugetului informatic şi controlul realizării indicatorilor prevăzuţi;
• îmbunătăţirea parametrilor de exploatare a aplicaţiilor informatice.
Cu cât durata de recuperare a cheltuielilor cu caracter informatic (ce privesc
echipamentele, programele, reţelele) este mai mică, cu atât standardele vor fi mai
mari şi se vor înregistra acumulări suplimentare (implicit profit net).
♦ durata de recuperare a cheltuielilor este invers proporţională faţă de
coeficientul eficienţei globale.(Dr):
Dr = 1/Keg
Se va avea în vedere totalitatea cheltuielilor (de investiţie, de exploatare) iar
sistemul informatic se va aprecia ca fiind eficient dacă Keg >1, iar Dr <5.
Performanţele sunt direct legate şi de dimensionarea optimă a sistemului informatic
financiar – contabil aşa cum este prezentat mai jos:
Caracteristicile sistemului Efectele economice
Abordare orientată client Efect de anvergură (eficienţa partajării resurselor şi eficacitatea utilizatorilor decidenţi)
Bază comună a prelucrărilor şi comunicaţiei
Efect de anvergură (cost al sistemului integrat < costurile a două neintegrate)
Evoluţie progresivă Reducerea efectului de complexitate Portabilitate Efect de anvergură (partajarea aplicaţiilor pe
platforme mai eficiente) Convivialitate Efecte de învăţare şi experienţă (reducerea costului
de pregătire) Performanţa sistemului: - optimizarea prelucrărilor - optimizare traficului
Efect de anvergură (diminuarea costului de prelucrare şi transmitere)
Remarc anumite „forţelor motrice” care ajută la formarea rezultatului sistemului
informatic financiar–contabil: producţia informaţională şi modalităţile de
41
valorificare a acesteia; preţurile de aprovizionare cu diferite materiale; evoluţia
salariilor utilizatorilor decidenţi şi/sau a managementului; costul de întreţinere şi
reparare al reţelei sau echipamentelor etc. Contribuţia fiecărui factor asupra
evoluţiei profitului se determină utilizând procedeul substituţiilor în lanţ care
permite măsurarea influenţelor sau a alternativelor.
2.1.2. Necesitatea şi structura procesului de evaluare a contabilităţii
informatizate
Liniile de forţă ale evaluării contabilităţii informatizate se bazează pe două puncte
esenţiale: eficacitatea şi eficienţa. Există o raportare permanentă a contabilităţii
informatizate la un sistem de referinţă (referenţial) şi o legătură directă cu actul
deciziei, fapt ilustrat în figura 2.2.
Figura 2.2 Legăturile aferente actului decizie
Operaţia de evaluare în cadrul sistemului informatic financiar-contabil va ţine cont
de trei elemente fundamentale:
• resursa umană;
• raporturile de putere;
• referenţialul.
42
Pentru o evaluare corectă şi completă a contabilităţii informatizate consider că se
impune să se cunoască foarte bine contextul, practicile existente, dar şi „cultura" sau
istoricul. După părerea mea soluţia apelării la experţii din exterior nu este
întotdeauna cea mai bună deoarece ei se interesează mai mult de analiza
disfuncţionalităţilor decât de efectele declanşate de comportamentul sistemului.
Procesul de evaluare a unui sistem presupune parcurgerea următoarelor faze:
selecţia, interpretarea şi decizia.
A. Faza de selecţie permite obţinerea unei imagini sistemică a situaţiei şi pentru a
nu lua decizii cu consecinţe negative se stabilesc foarte clar factorii de tip selectiv.
Aceştia pot fi de natură economică, tehnică, organizaţională, politică sau
sociologică şi se referă la aspecte cantitative şi calitative între care apare o vie
concurenţă. În acest fel se va evita creşterea sarcinilor administrative şi a efectelor,
accentuarea complexităţii căutării şi selecţiei datelor, depăşirea unui nivel al
costurilor dificil de suportat.
Managerul trebuie să obţină maxim de informaţii pentru a reduce incertitudinea în
faţa căreia se află, însă în unele situaţii consumă foarte mult timp cu această
preocupare şi nu-i mai rămâne decât foarte puţin pentru activităţile de decizie
efective (mai ales de tip strategic). J.C. Emery şi G.A. Miller arată că în mod
normal capacităţile cognitive ale unui om nu pot înţelege simultan mai mult de 5-9
informaţii noi - „chunks”17.
Faza de selecţie presupune înţelegerea comportamentului sistemului informatic
financiar-contabil, plecând de la tendinţele existente în cadrul lui, precum şi de la
liniile sale de forţă. Apare evidentă evaluarea strategică faţă de cea operaţională.
Consider că informatica, inteligenţa artificială (în special sistemele expert) pot
aduce un ajutor substanţial în faza de selecţie, prin consultarea bazelor de cunoştinţe
îmbogăţite cu experienţa trăită, utilizând şi facilităţile procesoarelor de tabele.
B. Faza de interpretare. În cadrul „acesteia în procesul de evaluare a
contabilităţii informatizate pot apare probleme legate de: puterea simbolurilor,
fluiditatea „catartică", dinamica actului de evaluare.
ele fiind în fapt carteziene. Concepţia constă în crearea, pornind de la specificaţiile,
unui ansamblu unitar în interacţiune având fiecare o funcţie clar definită.
Diagramele de fluxuri de date descriu prelucrările logice ale datelor şi arată maniera
în care datele intrate sunt modificate printr-o suită de transformări funcţionale
pentru a ajunge la datele de ieşire. Cele mai cunoscute metode aparţinând acestei
prime generaţii sunt: SADT (Structured Analisys and Design Technique), JSD
46
(Jackson System Development), Yourdon etc. Toate au la bază analiza funcţională a
întreprinderii. Diagramele de structură permit vizualizarea structurii ierarhice,
descrierea programului sau a unui modul fiind stabilite pe mai multe niveluri, prin
rafinări succesive.
Metoda SADT propune un ansamblu de diagrame ordonate ierarhic în care fiecare
poate fi considerată fie ca o diagramă – părinte (sinteză a diagramelor sale fiu), sau
ca o diagramă – fiu (dezvoltare a unei părţi a celei părinte). În cazul metodei SADT,
datele şi prelucrările sunt examinate împreună definindu-se actigrame (sau
diagrama activităţilor) şi datagrame (diagrama datelor).
Figura 2.5 Diagrama fluxurilor de date pentru Clienţi
Avantajele metodelor ierarhice constau în simplitate şi o bună adaptare la cerinţele
formulate de utilizator. Dezavantajele pornesc de la conceperea sistemelor
informatice conform cerinţelor analizei funcţionale, ceea ce determină concentrarea
efortului de analiză şi proiectare asupra prelucrărilor în condiţiile în care acestea
sunt cele mai supuse modificări în timp, modelarea datelor căzând pe un plan
secund.
Proliferarea aplicaţiilor creează propriile lor fişiere ducând la redundanţe şi mai ales
incoerenţă a datelor în sistemele de informare a organizaţiilor.
Metodele structurate au fost integrate în S.G.B.D. prin limbajul de descriere a
datelor.
47
Metodele sistemice permit vizualizarea şi înţelegerea organizării datelor. Aceste
metode se compun din abstractizări care prezintă lumea reală ca pe o colecţie de
entităţi şi de legături, stabilite între acestea. Majoritatea permite definirea de
restricţii descriind aspectele statice, dinamice sau chiar temporare ale entităţilor. În
această calitate ele constituie formalisme lizibile în cadrul specificaţiilor de nevoi.
Două metode constituie referinţa de reprezentare semantică: metoda individuală18
care va fi integrată Merise şi metoda entitate–relaţie19.
Amintesc printre metodele sistemice pe cele de concepţie în timp real care asigură
funcţionarea corectă în funcţie de rezultatele produse prin sistem şi de momentul la
care ele sunt produse. Acestea reprezintă oarecum un sistem de stimuli/răspuns;
stimulii fiind generaţi de captatori sau de acţionari. Atunci când stimulii sunt
aperiodici se poate concepe un sistem ca un ansamblu de procese paralele care
cooperează de o manieră în care transferă controlul componentei apropiate, de la
recepţia unui stimul. Se disting două clase active în timp real:
• sistemele de urmărire-control;
• sistemele de cumulare de date.
Sistemele de urmărire şi control cercetează în permanenţă numărul de captatori, şi
în funcţie de valoarea lor, declanşează acţiuni care eficientizează acţionarii (de
exemplu sistemele de alarmă antifurt din imobile).
Sistemele de cumulare de date culeg datele captate pentru procesare şi analiză.
Perioadele procesului de achiziţie şi cele ale procesului de procesare nu sunt în
armonie. Astfel apar diferenţe de viteză dictate de recurgerea la un mijloc de stocare
(tampon). Sistemul este organizat după modelul producător–consumator cu
mecanisme de excludere mutuală, pentru a evita cazul unde producătorul şi
consumatorul de date acced, în acelaşi timp, la elementul tampon. Aceste metode
recurg la diverse formalisme, de remarcat fiind cele din reţele Petri pentru aspectul
dinamic care au fost dezvoltate de formalizări specifice.
18 Tardieu H. şi col. - The individual model, International WorkShop on Data Structure Models for Informations Systems 19 Chen P.- The entity-relationship model, ALM transaction of database systems, 1, 1, mars 1976
48
Metodele sistemice cuprind de o manieră globală sistemul informaţional şi
reprezintă a doua generaţie a metodelor de proiectare. Reprezentative sunt metodele
Information Engeneering, MERISE, AXIAL etc. Apropierea se realizează la nivel
conceptual20 şi se disting patru nivele de abstractizare.
1. Nivelul conceptual exprimă opţiunile de gestiune; formulând întrebarea: Ce facem?
2. Nivelul organizaţional exprimă alegerile întreprinderii legate de resurse umane şi materiale. Se integrează la acest nivel noţiunile de timp, loc de actori şi se pun următoarele întrebări: cine, unde, când şi cum?
3. Nivelul logic permite alegerea mijloacelor şi a resurselor informatice făcând
abstracţie de caracteristicile lor tehnice precizate.
4. Nivelul fizic este reprezentat prin alegerile tehnice urmărind specificitatea
lor. La fiecare nivel de abstractizare sistemul de informare este reprezentat
prin trei modele: datele, prelucrările, comunicările.
Ceea ce este specific acestor metode este utilizarea teoriei sistemelor în analiza
întreprinderii. Sistemul informatic este abordat sub două aspecte complementare,
datele şi prelucrările analizate-modelate independent cu reunirea lor cât mai târziu
posibil. Spre deosebire de metodele ierarhice, metodele sistemice acordă „prioritate
datelor faţă de prelucrări şi respectă cele trei nivele de abstractizare introduse de
raportul ANSI/SPARC: conceptual, logic şi fizic”21. Avantajele metodelor sistemice
apar din promovarea tehnologiei bazelor de date. Dezavantajele sunt datorate
deficienţelor care pot apărea în modelarea prelucrărilor şi a discordanţelor posibile
între modelele datelor şi prelucrărilor.
Metoda orientată obiect este caracterizată prin atenţia deosebită acordată
concomitent structurii datelor şi structurii funcţionale. Această viziune permite
construirea unei baze stabile în procesul de dezvoltare a modelului şi utilizarea
conceptului obiect, unitar de-a lungul întregului ciclu de viaţă. Toate celelalte
concepte: funcţii, asocieri, evenimente gravitează în jurul obiectelor, astfel încât nu
este necesară trecerea la alte notaţii sau interpretări de semantică în diferite etape de
dezvoltare. Metoda orientată obiect se caracterizează prin definirea a trei modele:
20 Nanci D. şi col. - Ingénierie des systèmes d’information avec Merise, Sybex 21 Stanciu V. şi col. - Proiectarea sistemelor informatice, Editura Dual Tech, Bucureşti
49
• Modelul obiectelor are rolul de a descrie obiectele care intervin în problema
de rezolvat şi relaţiile dintre ele. Modelul obiectual reprezintă descrierea
structurii statice a obiectelor, claselor de obiecte, a operaţiilor şi atributelor,
precum şi a legăturilor şi a relaţiilor dintre ele.
• Modelul dinamic are rolul de a descrie stările pe care le poate avea un obiect
şi evenimentele la trecerea dintr-o structură în alta. Modelul dinamic descrie
interacţiunea dintre obiecte şi este focalizat pe aspecte ce se schimbă în timp,
deoarece orice obiect are un ciclu de viaţă cu un punct de pornire şi unul de
sfârşit. Modelul dinamic descrie acest ciclu de viaţă, ce se întâmplă de-a
lungul său şi cum este influenţat obiectul.
• Modelul funcţional are rolul de a descrie prelucrările şi fluxurile de date.
Modelul funcţional prezintă transformările valorilor datelor precizând sursa
şi destinaţia lor.
Avantajele oferite de metoda OMT sunt valorificate pe deplin în proiectarea şi
realizarea de sisteme informatice care trebuie să răspundă unor noi cerinţe şi anume:
• Reprezentarea complexă a realităţii (firmă, clienţi, produse, servicii, etc.);
• Informaţia gestionată în cadrul unui sistem informatic are tendinţa de creştere
în complexitate, iar manipularea ei trebuie să fie într-o formă uşor de perceput
de către utilizatorul final;
• Sistemele informatice realizate trebuie să fie flexibile în raport cu modificarea
structurilor de date şi trebuie să evolueze natural în timp, urmând astfel
evoluţia organismului economic, bancar, financiar pe care îl deserveşte;
• Sistemele informatice evoluează spre abordări multimedia care combină text
cu foi de calcul, grafice, animaţie şi voce.
Majoritatea metodelor orientate obiect utilizează reguli sau operaţii semantice:
generalizarea/specializarea, agregarea/descompunerea, combinate cu moştenirea şi
încapsularea.
50
2.2.1. Caracterizarea metodei Merise
Metoda MERISE asigură proiectarea de sisteme de gestiune ambiţioase permiţând
dualitatea între tratamentul evenimentelor trecute şi furnizarea elementelor de
previziune aplicabile centrelor de responsabilitate. Ea dispune de toate
instrumentele care să permită realizarea etapizată a unui sistem informatic cu grad
mare de integrabilitate, pornind de la localizarea unui subansamblu reprezentativ.
Numele metodei este abrevierea de la „Methode d’Etude et de Realisation
Informatique par le Sous – Ensemble representatif”.
Utilizarea metodei MERISE trebuie să facă posibilă descompunerea problemelor de
organizare a muncii. Practica în acest domeniu a evoluat considerabil traversând un
curent de gândire numit sistemică sau, ceea ce altă dată, se numea teoria sistemelor.
Din raţiuni didactice, pe parcursul însuşirii metodelor sistemice se poate asocia
figurativ enunţul următor: „a se ridica pentru a vedea mai bine...a înţelege...pentru a
acţiona mai bine”. Acest curent de gândire care a cuprins şi alte discipline de
cercetare, a oferit garanţia stabilităţii şi evoluţiei metodei, fiind baza filosofiei
MERISE22 iar toate conceptele operatorilor sistemici pentru ştiinţa organizării sunt
asimilaţi şi în cadrul acestei metode. „A înţelege nu este suficient pentru a acţiona,
trebuie şi să...decizi” constituie al doilea „suport” al filosofiei MERISE. Pot fi
consecinţe importante legate de acest demers, pentru că, de cele mai multe ori, în
ultimă instanţă soluţia pentru informatizarea unui domeniu dat este în realitate o
problemă de luare a unei decizii adecvate.
Fundamentul metodei constă în utilizarea mijloacelor de reprezentare cumulativă a
structurii organismelor economice corelată cu domeniile de activitate proprii.
Consider necesară corelaţia fluxurilor de intrare-ieşire cu sistemul de pilotaj al
agenţilor economici fapt materializat prin acţiunea în timp real a sistemului
informaţional. În figura 2.5 prezint implicarea sistemului de management şi a
» studiul existent; » concepţia; » organizarea punerii în lucru; » bilanţul cantitativ şi calitativ; » concluziile studiului prealabil.
Metoda se utilizează pentru toate proiectele de organizare a unui domeniu de
activitate chiar dacă nu conţin elemente de informatizare, situaţie în care nu apare
contextul informatic. Se poate constitui într-un instrument al metodei orice mijloc
„care permite să se execute un lucru: o muncă, o operaţie” (Larousse).
În metoda MERISE se regăsesc instrumente generale (interviul, ancheta) cât şi
proprii (formalizări individuale şi ale prelucrărilor). Instrumentele specifice
MERISE sunt utilizate pentru reprezentarea sistemelor informaţionale şi a
diferitelor nivele de modele de date şi prelucrări după cum se deduce din sinteza
supusă atenţiei în continuare:
Alegere Obiect descris
Nivel de abstracţie
Exemplu de modele
Ce se doreşte să se facă în fond
GESTIUNE Date
Relaţii Reguli de gestiune Înlănţuiri de prelucrări
CONCEPTUAL MODELUL CONCEPTUAL AL DATELOR (invariant static) MODELUL CONCEPTUAL AL PRELUCRĂRILOR (invariant dinamic)
Cine face Cu ce şi Când
ORGANIZAŢIONAL Oameni Maşini Reţele diferite Repartiţie geografică
LOGIC SAU ORGANIZAŢIONAL
MODELUL LOGIC DE DATE
MODELUL LOGIC DE PRELUCRARE
Cum se face
TEHNIC Entităţi
Programe
Proceduri
FIZIC
SAU
OPERAŢIONAL
MODELUL FIZIC AL DATELOR
MODELUL FIZIC AL PRELUCRĂRILOR
Pot concluziona că la întrebarea „cum se face?” din punct de vedere tehnic prin
modelul fizic al datelor, modelul fizic al prelucrărilor pot răspunde prin entităţi
programe proceduri. La întrebarea „cine, cu ce şi când?“ din punct de vedere
58
organizaţional răspunde modelul logic al datelor şi cel al prelucrărilor. La
interogarea „ce se doreşte a se realiza?” datele, relaţiile, regulile de gestiune,
înlănţuirile de prelucrări apar ca răspuns dedus din modelul conceptual al datelor şi
al prelucrărilor.
În continuare supun atenţiei sintetiza nivelelor de abstractizare corelate cu
ansamblul date-prelucrări.
DATE PRELUCRĂRI
CONCEPTUAL Modelul conceptual al datelor
MCD
- Concepte fundamentale
- Relaţii semantice
Modelul conceptual al prelucrărilor
MCP
- Descrierea macroscopică (noţiunea de proces)
LOGIC Modelul logic de date
MLD
Integrarea restricţiilor de organizare
- Traducerea în SGBD
entitate
relaţie
instanţă (realizare)
Modelul logic al prelucrărilor
MLP
- Integrarea alegerii opţiunii
- Repartiţia om - maşină
- Timp real – timp diferit
Desfacerea proceselor proceduri Faze sarcini
FIZIC Modelul fizic al datelor
MFD
Descrierea bazelor de date
Noţiuni de înregistrare
Modelul fizic al prelucrărilor
MFP
Descrierea programelor
Descrierea procedurilor
Corelând figura 2.8 referitoare la „Merise Ce-cum-cu cine se realizează?”,
nivelurile de abstracţie, modelele rezultate, deduc şi prezint următoarele expresii:
Viziunea exterioară: model extern=o vedere a unui utilizator
=
Ansamblul informaţiilor operaţionale pentru o prelucrare
FORMALISM
=
Model individual
Conceptele adecvate pentru fiecare nivel al modelării datelor şi prelucrărilor sunt
caracterizate printr-un grad mare de generalitate, dar în acelaşi timp şi de relevanţă
surprinzând aspecte semnificative din realitatea supusă modelării.
59
Modelul conceptual al datelor este un ansamblu de concepte şi reguli de combinare
care permit reprezentarea realităţii circumscrise domeniului supus informatizării.
Pentru definirea modelului conceptual al datelor se apelează la modele intermediare
care sunt folosite ca suport al unei metodologii de proiectare. Modelul conceptual
utilizează o abstractizare prin relaţie, recunoscută de ISO fiind o apropiere de
modelul entitate-relaţie. Mai multe concepte de bază caracterizează acest model:
- proprietatea este o modelare a informaţiei elementare, de exemplu funcţia
exercitată de un salariat: vânzător, contabil, informatician etc.
- identificatorul permite modelarea unui ansamblu de obiecte concrete sau abstracte,
percepute ca fiind pertinente pentru sistemul informatic studiat, de exemplu
identificatorul salariatului sau identificatorul produsului. Elementele din acest
ansamblu sunt ocurente, de exemplu în cazul salariatului ocurenţa este exprimată
astfel: „Georgescu, 28 ani, manager”.
Regulile de pertinenţă, de identificare, de evidenţiere, de verificare şi omogenitate
conduc la modelizarea termenilor identificării.
- relaţia între mai mulţi indivizi este un ansamblu de produse carteziene de ocurenţă
a acestora. De exemplu produsul cartezian vânzător * client reprezentat prin toate
cuplurile vânzător/client, va fi modelat prin ansamblul de legături care exprimă
aceeaşi natură între mai mulţi indivizi. Bineînţeles, aceste relaţii trebuie să fie
pertinente în raport de sistemul informatic studiat.
- cardinalitatea reprezintă cuplul entitate–relaţie. În spatele cardinalităţilor se găsesc
reguli de gestiune reale.
Inspirat din reţelele Petri, modelul conceptual al prelucrărilor (MCP) are menirea
ca în funcţie de domeniul investigat să răspundă la întrebarea: Ce prelucrări se
realizează?
Fluxurile, receptorii (stimulii) şi emiţătorii (reacţii) prin domeniu sunt modelări ale
evenimentelor şi rezultatelor. Evenimentele şi rezultatele pot fi externe sau interne.
Cele externe provin sau sunt destinate unui actor extern, iar cele interne rămân în
60
domeniu pentru a asigura continuitatea procesului, urmărind satisfacerea sistemului
de pilotaj.
Operaţia descrie comportamentul domeniului la declanşarea produsă prin mai multe
evenimente. Ea este o secvenţă continuă de acţiuni elementare producătoare de
evenimente care se execută neîntrerupt din momentul declanşării acesteia de către
unul sau mai multe evenimente. Operaţia constituie un bloc de prelucrare
cuprinzând acţiuni elementare generatoare de evenimente interne, înlăturând
posibilitatea de generare a evenimentelor intermediare între acţiunile ce aparţin
operaţiei. Operaţia emite, în retur rezultate în funcţie de condiţiile traduse prin
expresii logice.
Prelucrările reprezintă partea dinamică a sistemului informaţional. Ele descriu
acţiunile exercitate asupra datelor cu scopul obţinerii informaţiilor dorite,
reprezentând materializarea sub formă de acţiuni a regulilor de gestiune specifice
activităţii întreprinderii. MCP urmăreşte reprezentarea înlănţuirii operaţiilor cu
definirea condiţiilor necesare pentru declanşare dar şi consecinţele derulării
operaţiilor respective. În reprezentarea acestei înlănţuiri de operaţii şi evenimente
declanşatoare în cadrul modelului, se impune respectarea unor cerinţe determinate
de regulile de gestiune. Asocierea MCP ↔ eveniment indică faptul că ceva anume
s-a întâmplat şi în consecinţă sistemul trebuie să reacţioneze.
- sincronizarea reprezintă o condiţie prealabilă a unui flux de operaţii în care mai
multe evenimente participă la declanşare. Sincronizarea se traduce prin expresii
logice. Regulile de sintaxă şi de funcţionare permit verificarea coerenţei MCP.
Modelul conceptual de comunicaţie (MCC) are drept scop reprezentarea fluxurilor
de informaţii sau mesaje între diferitele subsisteme omogene ale întreprinderii,
numite domenii. Domeniile privesc marile funcţiuni sau procese majore din
întreprindere. Un mesaj este trecerea de informaţii între domenii sau între un
partener (factorul extern) al întreprinderii şi un domeniu. Mesajul este emis de o
parte (partener sau domeniu, emiţător) şi recepţionat de alt element structural
(receptorul).
61
Construcţia modelelor organizaţionale 27 reprezintă o etapă delicată şi deseori
complexă datorită varietăţii şi interacţiunii parametrilor de luat în consideraţie:
organizarea intrărilor, varietatea soluţiilor organizaţionale posibile, criterii de
evaluare (economice, sociale, ergonomice, tehnice). Totodată poate fi considerată ca
o etapă accesibilă, deoarece nu apar dificultăţi induse de abstractizare.
În figura 2.10 vă supun atenţiei reprezentarea cumulată a MOP-MOD-MOC care
încearcă să evidenţieze circuitul „sarcini-prelucrări”, „date” şi „mesaje”.
Figura 2.10 Traseul „sarcini-prelucrări”, „date”, mesaje”
Problematica modelului organizaţional este sintetizată în tabelul următor:
Problematica MOP Problematica MOD Problematica MOC
- Repartizarea prelucrărilor pe centre, unităţi şi posturi de lucru - Caracterizarea sarcinilor: posturile raportate, gradul de automatizare, termenul de răspuns, modul de funcţionare, regulile şi procedurile aplicabile, frecvenţa, durata, capacitatea
- Repartizarea datelor: pe centre, unităţi şi posturi de lucru - Volumetrie - Istoric - Securitate
- Schimburile de mesaje între centre
Modelarea priveşte sistemul de informaţii organizaţional care se finalizează prin
abordarea printr-o grilă de coerenţă MCD – MOP – MOD, machetare şi validarea
MCD – modele externe. Modelele externe28 privesc datele drept mesajele legate la
evenimente–rezultate. Continuarea studiului presupune modelarea sistemului şi se
27 Nextobjects is based on the Merise Method, www.nextobjects.sourceforge.net 28 Information Systems Group UG2, www.cee.hw.ac.uk/ism/ug2/ass3
62
surprind în acest moment delimitările de modele care apar utilizând percepţia de
gestionare (modele organizaţionale) şi viziunea specialistului informatic (modelele
logice şi fizice).
În cele ce urmează supun atenţiei sinteza reunirii modelelor logice şi fizice ale
datelor, prelucrărilor, comunicaţiei.
Problematica MLP şi al MFP Problematica MLD şi
al MFD
Problematica MLC şi
al MFC
- Repartizarea prelucrărilor informatizate: centre, unităţi logice de prelucrare. - Modularizare
- Transformare MOD după tipul SGBD - Dimensiunea MLD - Optimizarea
- Mesaje între centre prin magistrale informatice
Concluzionând ideile prezentate pe parcursul acestui subcapitol, afirm că utilizarea
metodei MERISE în contextul cadrului metodologic al conducerii proiectelor
informatice este oportună deoarece:
• determină limitele nivelelor de preocupare (conceptual, logic, fizic);
• permite exprimarea unor concepte complementare legate de conducerea
studiilor detaliate;
• propune un plan de lucru detaliat pentru derularea fiecărei etape pentru a
facilita conducerea proiectelor în concepţia sistemelor informatice;
• furnizează documentele tip ISO pentru constituirea documentaţiei aferente
fiecărei etape.
Se poate afirma că este o metodă „deschisă”, susceptibilă să se integreze într-un
cadru metodologic mai larg.
2.2.2. Metoda OMT de proiectare a sistemelor informatice
OMT – Object Modeling Tehnique – este bazată pe modele ca abstracţii ale
problemelor din lumea reală, care urmăresc focalizarea aspectelor importante ale
63
problemei şi omisiunea celor irelevante. Această metodă a fost creată de James
Rumbaugh şi este cea mai cunoscută şi utilizată metodă de proiectare orientată
obiect (POO). Un sistem informatic este privit ca un ansamblu de obiecte care
cooperează între ele şi tratează obiectele ca instanţe ale unei clase în interiorul unei
ierarhii. Noţiunea de „obiect” 29 este dependentă de implementarea metodei în
limbajele de nivel înalt cum ar fi: ADA, MODULA, SMALLTALK, C++, CLOS
(Common Lisp Object System).
Această metodă are în vedere trei aspecte importante:
• abstractizarea realităţii, ceea ce înseamnă că pentru aceeaşi problemă se pot
crea mai multe modele care să focalizeze diferite aspecte;
• scopul modelului este să se focalizeze ceva cunoscut;
• comunicarea între membrii echipei de analiză-proiectare şi între utilizatori.
Metodele orientate obiect propun modelarea concomitentă a datelor şi a funcţiilor
obţinând ierarhii de clase de obiecte care înglobează atât datele cât şi
comportamentul, spre deosebire de modelarea datelor separată de a funcţiilor,
element structural al metodelor tradiţionale.
Comparativ cu metodele tradiţionale, abordarea orientată-obiect mută centrul de
greutate al soluţionării problemei în faza de analiză, fapt compensat printr-un minim
de efort necesar a fi depus în faza de implementare. O bună înţelegere a cerinţelor
problemei reale va conduce la construirea unui model fiabil, adaptabil, care suportă
uşor modificările ulterioare.
Metodele obiect integrează modelarea de structură cu cea comportament30. Obiectul
reprezintă o entitate (reală sau abstractă) a lumii supuse modelării, caracterizată prin
identitate, stare şi comportament. În fapt, obiectul reprezintă un element
identificabil, concret sau abstract, caracterizat prin structură, atributele şi metode
proprii.
29 Rational whitepaper, www.rational.com 30 Ayache R. N. - The management control function, Boston: the Harvard Business School Press
64
Corespunzător metodologiei31 se parcurg următorii paşi:
• definirea problemei;
• elaborarea unei modalităţi informale de identificare a datelor şi a funcţiilor
relevante corespunzătoare problemei;
• formalizarea strategiei prin identificarea obiectelor şi atributelor, operaţiilor
asupra obiectelor, stabilirea instanţelor şi implementarea operaţiilor.
Metoda OMT, folosită pentru proiectarea software-lui contează pe mijloacele de
reprezentare: diagrama de flux de date pentru surprinderea comportamentului
dinamic şi diagrama modulară (arhitectura produsului) pentru surprinderea
comportamentului static. Această metodă de proiectare susţine strategia
prototipizări de structurare a procesului de realizare a produselor informatice.
Supun atenţiei câteva dintre avantajele acestei abordări:
• software-ul este asamblat (construit) din componente care au o calitate
probată în implementările anterioare;
• obiectele individuale pot fi modificate fără a le afecta pe celelalte, rezultând
că software-ul construit modular poate fi modificat şi dezvoltat cu eforturi
minime;
• reutilizarea componentelor soft existente, tehnologie care asigură realizarea
de aplicaţii într-un timp scurt şi la costuri reduse.
OMT propune trei tipuri de modele, obiect, dinamic şi funcţional pentru scopuri şi
descrieri diferite de obiecte, interacţiuni, transformări. Cele trei tipuri de modele
sunt de fapt proiecţii ale unei singure informaţii, fiecare prezentând un anumit
specific. Existenţa şi necesitatea acestor modele solicită şi realizează o strânsă
conexiune între ele. Fiecare model în OMT poate fi reprezentat prin diagrame
distincte32:
31 Rumbaugh's Method, www.iconixsw.com/Rumbaugh.html 32 Castellani X. - Méthodologie générale d’analyse et de conception des systèmes d’objects. 1. L’ingénierie des besoins, Masson
65
• pentru modelul de obiecte – CAD (Class Association Diagram sau DAC
Diagrama de Asociere a Claselor);
• pentru modelul dinamic – ETD (Event Trace Diagram sau DTE Diagrama de
Trasare a Evenimentelor), precum şi STD (State Transition Diagram) sau
DTS (Diagrama de Tranziţie a Stărilor);
• pentru modelul funcţional se apelează la DFD (Diagrama de Flux de Date -
Data Flow Diagram); DCC (Diagrama de Comunicare a Claselor, CCD
Class Comunication Diagram); DGM (Diagrama de Generalizare a
Mesajelor - MGD Message Generalization Diagram).
În reprezentarea ciclului de viaţă al unui proiect se utilizează mai multe modele, dar
flexibilitatea metodelor orientate-obiect permite lucrul într-un ciclu de viaţă
„spirală”. Ciclul de viaţă spirală sau modelul spirală, spre deosebire de modelul în
cascadă, specific metodelor structurate, presupune faptul că doar o parte a
modelului trebuie să fie finalizat înainte de a trece la faza următoare. Aceasta
înseamnă că versiunii parţiale ale sistemului pot fi livrate în timp scurt, evaluate şi
validate de către utilizator, proiectantul realizând extrem de rapid analiza pentru
completarea modelelor.
Feed-back-ul permite găsirea de soluţii convenabile, iar flexibilitatea modelelor
orientate–obiect permite armonizarea cerinţelor utilizatorului cu soluţiile propuse de
echipa de realizatori. Modelul „în cascadă”, chiar în varianta care cuprinde iterarea
fazelor, permite detectarea şi corectarea erorilor înainte de trecerea la faza
următoare şi impune ca în fiecare fază să se producă un document şi produse valide.
Corectarea erorilor în fazele următoare celei în care s-au produs este foarte
costisitoare (timp, efort), aducând importante prejudicii prin faptul că utilizatorul
trebuie să aştepte până la sfârşitul implementării pentru a vedea dacă sistemul
corespunde necesităţilor exprimate.
66
2.2.2.1. Etapele ciclului de realizare a unui proiect în abordarea orientată–obiect
Etapele ciclului de realizare în abordarea orientată – obiect sunt în mare parte
comune cu viziunea Merise, dar apar şi elemente specifice.
Analiza are drept obiectiv modelarea problemei din lumea reală sau definirea
Domeniului Aplicaţiei (Application Domain). Proiectantul creează modele de
obiecte şi funcţii fără a lua în considerare aspectele de implementare. În figura 2.11
am reprezentat o secvenţă a activităţi analizei şi modelării evenimentului studiat.
Figura 2. 11 Circuitul analiză-modelare evenimente
Modelul de analiză trebuie înţeles şi validat de utilizator. Această etapă are ca
rezultat formularea problemei, modelul obiectual, modelul dinamic şi cel funcţional.
Analiza este utilă clarificării cerinţelor, realizării conexiunii beneficiar-producător
bazată pe înţelegere, reprezentând în acelaşi timp cadrul pentru proiectarea
ulterioară şi implementare. Finalizarea etapei analiză-modelare (figura 2.12) se
materializează prin definirea unui model precis, concis, inteligent şi corect al
viitorului sistem.
67
Figura 2. 12 Obţinerea modelului de analiză
O reprezentare sintetică a activităţilor şi rezultatelor este supusă atenţiei în tabelul
următor:
Faze şi activităţi Mod de reprezentare Descriere A.1. Analiza şi modelarea evenimentelor Scrierea declaraţiei problemei (formularea problemei)
Text liber Declaraţia problemei (de către client sau elaborator)
Analiza evenimentelor problemei
Diagrama de Trasare a Evenimentelor (DTE)
Scenarii de evenimente pentru evenimentele complexe ale aplicaţiei
Modelarea evenimentelor
Diagrama de Comunicare între Clase (DCC) Diagrama de Generalizare a Mesajelor (DGM)
Diagrama de Comunicare între Clase cu mesaje şi interacţiunile dintre clase Diagrama de Generalizare a Mesajelor specifică interacţiunii între clase
A.2. Construirea modelului de analiză Definirea modelului obiectual
Diagrama de Asociere a Claselor (DAC)
Model de obiecte cu clasele aplicaţiei atributele, operaţiile şi asocierile lor.
Definirea modelului dinamic
Diagrama de Tranziţie a Stărilor (DTS)
Modelul dinamic (DTS) pentru clase importante şi modelul de obiecte care încorporează rezultate din DTS
Definirea modelului funcţional
Diagrama de Flux de Date (DFD)
Modelul funcţional cu funcţionalitatea operaţiilor complexe şi completarea lor în DAC
Reiterarea şi verificarea
Verificări Se completează modelul de obiecte din celelalte iteraţii şi se verifică consistenţa
68
Proiectarea de sistem – împarte modelul de analiză în părţi mai mici, uşor de
înţeles şi construieşte arhitectura sistemului prin identificarea subsistemelor şi
transpunerea lor pe hardware-ul disponibil. Proiectarea de sistem porneşte de la
domeniul aplicaţiei şi ia în considerare conceptele de implementare adică
optimizarea, rafinarea şi extinderea celor trei modele până la nivelul de detaliu care
să permită implementarea. Se poate spune că, analiza descrie problema iar
proiectarea de sistem descrie soluţia. Rezultatul acestei etape este realizarea
arhitecturii de bază a sistemului şi adoptarea deciziilor privind strategia la nivel
global.
Scopul acestei etape este transpunerea declaraţiei problemei aşa cum a fost definită
în etapa de analiză într-o arhitectură adecvată, bazată pe divizarea în subsisteme
precum şi decizii de implementare la nivel global. Rezultatul este un concept de
implementare care rafinează, optimizează şi extinde cele trei modele preluate din
etapa de analiză, până la etapa de proiectare obiectuală care să permită
implementarea propriu-zisă.
Proiectarea de sistem presupune două mari faze şi anume: construirea arhitecturii
sistemului; modelarea detaliilor subsistemelor.
În faza de construire a arhitecturii sistemului se dezvoltă aşa numitele clase de
bază, pe seama cărora se studiază funcţionalitatea sistemului şi se decide privitor la
configuraţia sistemului hardware-software; sistemul de gestiune al bazelor de date;
interfaţa grafică de conexiune cu utilizatorul.
Soluţia de sistem proiectată va include pe lângă clasele de bază şi clasele de
interfeţe grafice, clasele de acces la bazele de date. Suma acestora reprezintă soluţia
generală de organizare.
În a doua fază se modelează în detaliu fiecare sistem individual, accentul pus pe
diferitele modele fiind diferit de la un tip de sistem la altul. Se creează aşa numitele
clase container organizate pe sistem.
Sintetizarea fazelor şi activităţilor etapei de proiectare de sistem este relevată de
tabelul de mai jos:
69
Faze şi activităţi Modalităţi de reprezentare
Descriere
1. Construirea arhitecturii sistemului 1.1. Organizarea sistemului în subsisteme a) Importul sistemului claselor de bază
DCC DAC
Se utilizează din etapa de analiză DCC şi DAC
b) Alegerea unei arhitecturi Text Se stabileşte arhitectura sistemului c) Crearea unui Model de Comunicare între Clase de Nivel de Proiect
DCC la nivel de proiect
În DAC din etapa de analiză, actorii vor fi înlocuiţi cu subiecţi, clasele de bază vor fi grupate, se adaugă şi se conectează subiectul „Clase de Interfaţă”
d) Crearea sistemelor pentru fiecare subiect
Text Fiecare subiect din diagramă va fi descompus într-un sistem cu acelaşi nume.
1.2. Definirea interfeţelor DGM DCC
Completarea modelului de comunicare a claselor la nivel de proiect cu mesajele compuse nou definite
1.3. Identificarea obiectelor active concurente şi exclusive
Text Identificarea obiectelor care sunt active în acelaşi timp şi a celor care au un comportament exclusiv
1.4. Alocarea subsistemelor pe procesoare şi task-uri
Text Se alocă subsistemele la procesoare, astfel încât să asigure satisfacerea cerinţelor de performanţă şi minimizarea comunicării
1.5. Alegerea strategiei de bază pentru implementarea datelor memorate
Text Se aleg structurile de date, fişierele sau bazele de date corespunzătoare
1.6 Identificarea resurselor globale şi determinarea mecanismelor pentru asigurarea accesului la date.
Text Identifică resursele globale şi determină mecanismele pentru controlarea accesului
1.7. Alegerea variantei de implementare a controlului
Text
1.8. Stabilirea condiţiilor limită
Text
1.9. Stabilire priorităţi 2. Modelarea detaliilor de subsistem 2.1 Definirea modelului de comunicare a claselor
DCC Definirea modelului de comunicare între clase la nivel de sistem din modelul de comunicare la nivel de proiect
2.2. Detalierea modelului obiect
DAC Detalierea modelului obiectual din faza de analiză
Proiectarea obiectuală – are drept scop alegerea modului de implementare pentru
fiecare clasă, proiectându-se algoritmi şi implementându-se asocierile. Se realizează
70
gruparea claselor în superclase pentru uşurarea implementării şi pentru
îmbunătăţirea performanţelor. În urma acestei etape se obţin: modelul obiectual
detaliat, modelul dinamic detaliat şi modelul funcţional detaliat.
Scopul etapei este de a adăuga la modelul obiectual rezultat al etapelor de analiză şi
proiectare de sistem, detaliile de implementare necesare fie pentru generarea
automată de cod, fie pentru dezvoltarea ulterior fără generare automată. Când se
trece la etapa de implementare prin generare automată de cod, atunci modelul obiect
este singurul utilizat, una din activităţile etapei de proiectare obiectuală
Plecând de la aceste obiective în etapa de proiectare obiectuală operaţiile
identificate în etapa de analiză sunt transpuse în algoritmi iar clasele, atributele şi
asocierile sunt implementate în structuri de date specifice. Modelele utilizate sunt
identice cu cele din etapa de analiză, diferenţa constând în faptul că acum clasele
sunt descrise din punct de vedere al implementării33. Astfel:
• modelul obiectelor determinat în etapa de analiză va fi acum rafinat prin
introducerea de noi clase (care păstrează rezultatele intermediare ale calculului),
operaţii (descoperite abia acum) şi atribute.
• modelul funcţional va descrie operaţiile pe care proiectantul trebuie să le
implementeze. În timpul proiectării acesta va alege algoritmii de implementare a
unei operaţii şi va descompune operaţiile mai complexe în operaţii mai simple.
• modelul dinamic descrie felul în care sistemul răspunde stimulilor externi.
Structura de control a programului derivă din acest model. Fluxul de control din
cadrul unui program trebuie realizat fie explicit (printr-un planificator intern, care
recunoaşte evenimentele şi le transformă în apeluri de proceduri), fie implicit
(alegând algoritmii care realizează operaţiile în ordinea specificată de modelul
dinamic).
Rezultatul final al acestei etape îl constituie modelul obiectual, modelul dinamic şi
modelul funcţional rafinate şi detaliate. Deciziile de proiectare luate trebuie
susţinute de o documentaţie adecvată care alcătuieşte o extensie a cerinţelor de
documentaţie realizate în etapa de analiză.
33Object-Oriented Development Interactive Systems, http://citeseer.nj.nec.com/aalto94objectoriented.htm
71
Se poate concluziona că deciziile de proiectare trebuie documentate pornind de la
modelul de analiză, prin adăugarea de detalii modelelor obiectual, dinamic şi
funcţional. În acest scop se vor folosi construcţii specifice de implementare:
Se poate concluziona că metodologiile orientate-obiect analizate nu se deosebesc
substanţial, ele prezintă de fapt aceleaşi concepte văzute din puncte de vedere
diferite şi cu notaţii diferite.
OMT comparativ cu celelalte metode orientate-obiect prezintă avantajul că
utilizează aceleaşi notaţii pentru modelare în întregul ciclu de viaţă, astfel încât nu
este necesară o trecere brutală la alte notaţii sau interpretări ale semanticii în etapele
următoare ale proiectării. Principalul dezavantaj este acela că nu oferă o ghidare
metodologică încă din etapele timpurii ale procesului de dezvoltare.
88
CAPITOL 2...................................................................................................................... 34 METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC............................................................................................................................................. 34
2.1. Cerinţe generale în utilizarea unei metode de proiectare a sistemului informatic.... 34 2.1.1. Parametrii specifici de performanţă pentru sistemele informatice .................... 36 2.1.2. Necesitatea şi structura procesului de evaluare a contabilităţii informatizate... 41
2.2. Metodele de concepţie şi de realizare a unui sistem informatic ............................... 45 2.2.1. Caracterizarea metodei Merise .......................................................................... 50 2.2.2. Metoda OMT de proiectare a sistemelor informatice........................................ 62
2.2.2.1. Etapele ciclului de realizare a unui proiect în abordarea orientată–obiect . 66 2.2.2.2. Modelul obiect în metodologia OMT......................................................... 71 2.2.2.3. Modelul dinamic în accepţiunea metodei OMT......................................... 77 2.2.2.4. Modelul funcţional al metodei OMT.......................................................... 79
2.3 Unified Modeling Language – cale de reunire a conceptelor orientate-obiect.......... 81 2.3.1 Avantajele oferite de UML................................................................................. 83 2.3.2 Obiectivele fundamentale ale UML ................................................................... 83
2.4. Comparaţii între metodele de proiectare .................................................................. 85
Figura 2.1 Compartimentul financiar-contabil prin prisma costului, profitului, investiţiei 36 Figura 2.2 Legăturile aferente actului decizie ..................................................................... 41 Figura 2.3 Criteriile de analiză a unei situaţii...................................................................... 43 Figura 2.4 Evaluarea compartimentului financiar–contabil prin metoda scenariilor .......... 45 Figura 2.5 Diagrama fluxurilor de date pentru Clienţi ........................................................ 46 Figura 2.6 Reprezentarea domeniilor unui organism economic.......................................... 51 Figura 2.7 Funcţii şi activităţi într-un sistem operant.......................................................... 52 Figura 2.8 MERISE – Ce-cum-cu cine se realizează?......................................................... 55 Figura 2.9 Studiu prealabil în cadrul metodei Merise ......................................................... 56 Figura 2.10 Traseul „sarcini-prelucrări”, „date”, mesaje”................................................... 61 Figura 2. 11 Circuitul analiză-modelare evenimente........................................................... 66 Figura 2. 12 Obţinerea modelului de analiză....................................................................... 67 Figura 2. 13 Forma generală de reprezentare a unei asocieri modelate ca o clasă.............. 73 Figura 2. 14 Asociere „Împrumut” modelată ca o clasă...................................................... 74 Figura 2. 15 Asociere „Client”-„Bancă”-„Investiţie” ......................................................... 74 Figura 2. 16 Reprezentarea generală a „moştenirii”............................................................ 76 Figura 2. 17 Monitorizarea simultană a clienţilor, comenzilor şi a stocurilor..................... 76 Figura 2. 18 DTE a aplicaţiei Clienţi................................................................................... 77 Figura 2. 19 Forma generală a unei DTS............................................................................. 79 Figura 2. 20 DTS pentru clasa de obiecte „Element_în_stoc” ............................................ 79 Figura 2. 21 Ierarhia de modele, vederi şi diagrame utilizate de UML............................... 82 Figura 2. 22 Proiecţia viziunilor cazului Use Case ............................................................. 85