Sunteți pe pagina 1din 84

nvmntul profesional i tehnic n domeniul TIC Proiect cofinanat din Fondul Social European n cadrul POS DRU 2007-2013

Beneficiar Centrul Naional de Dezvoltare a nvmntului Profesional i Tehnic str. Spiru Haret nr. 10-12, sector 1, Bucureti-010176, tel. 021-3111162, fax. 0213125498, vet@tvet.ro

MODULUL I

MODELAREA SISTEMELOR INFORMATICE Material de predare anul II

Domeniul: Informatic Calificarea: Analist programator

Nivel 3 avansat

2009

AUTOR: 41

IACOB MIRELA profesor grad didactic I

COORDONATOR:

MARIANA VIOLETA CIOBANU profesor grad didactic I

CONSULTAN: IOANA CRSTEA expert CNDIPT ZOICA VLDU expert CNDIPT ANGELA POPESCU expert CNDIPT DANA STROIE expert CNDIPT

Acest material a fost elaborat n cadrul proiectului nvmntul profesional i tehnic n domeniul TIC, proiect cofinanat din Fondul Social European n cadrul POS DRU 20072013

Cuprins
I. INTRODUCERE......................................................................................................................................................4 II. DOCUMENTE NECESARE PENTRU ACTIVITATEA DE PREDARE........................................................8 III. RESURSE..............................................................................................................................................................9 TEMA 1. SISTEM INFORMAIONAL / SISTEM INFORMATIC.........................................................................................9 Fia suport 1. 1. Definiii sistem informaional /sistem informatic, componentele, rolul, obiectivele i clasificarea sistemelor informatice...........................................................................................................................9 TEMA 2. SISTEME SUPORT DE DECIZIE / SISTEME EXPERT......................................................................................17 Fia suport 2.1. Definiia, caracteristicile, clasificarea, sistemelor suport de decizie / sisteme expert............17 TEMA 3. LABORATOARE PENTRU ANALIZA SISTEMULUI INFORMAIONAL..............................................................29 Fia suport 3.1. Analiza sistemului informaional............................................................................................29 TEMA 4. TIPURILE I ELEMENTELE DE CONINUT ALE METODOLOGIILOR DE REALIZARE A SISTEMELOR INFORMATICE...........................................................................................................................................................30 Fia suport 4. 1. Elementele de coninut ale metodologiilor de realizare a sistemelor informatice.................30 TEMA 5. ETAPELE, METODELE I TEHNICILE DE REALIZARE A SISTEMELOR INFORMATICE....................................41 Fia suport 5.1. Etapele, metodele i tehnicile de realizare a sistemelor informatice......................................41 Fia suport 6.1. Metodologiile de realizare a sistemelor informatice...............................................................49 TEMA 7. MODELAREA SISTEMELOR INFORMATICE..................................................................................................55 Fia suport 7.1. Elaborarea modelului logic i a celui fizic..............................................................................55 TEMA 8. INSTRUMENTE SOFTWARE (CASE, IPSE, PSE, SEE)...............................................................................62 Fia suport 8. 1. Aspecte generale, avantaje i prezentri comparative ale instrumentelor software. Obiectivele i faciliti de utilizare a instrumentelor CASE .......................................................................................62 TEMA 9. LIMBAJE DE MODELARE............................................................................................................................68 Fia suport 9.1. Modelarea orientat obiect. Noiuni de baz, componentele limbajului................................68 TEMA 10. APLICAII PRACTICE................................................................................................................................81 Fia suport 10.1. Elaborarea modelului logic pentru un sistem informatic dat................................................81 IV. FIA DE OBSERVAIE....................................................................................................................................82 V. BIBLIOGRAFIE...................................................................................................................................................84

I. Introducere
Materialele de predare sunt o resurs material orientativ care sprijin cadrul didactic n activitatea de predare, sunt instrumente auxiliare care includ noiuni teoretice de baz pentru acoperirea coninuturilor tematice propuse de curriculum, ofer sugestii metodologice prin care se pot atinge competenele vizate i conin propuneri privind activitatea de evaluare. Semnificaia elementelor grafice din material este dat n tabelul de mai jos: Tabelul 1. Semnificaia simbolurilor ntlnite n lucrare

Definiie

Important

Atenie

Sugestii metodologice

Propuneri evaluare

pentru

Prezentul material de predare, se adreseaz cadrelor didactice care predau n cadrul colilor postliceale, domeniul Informatic, calificarea Analist programator, nivelul 3 avansat. El a fost elaborat pentru modulul I Modelarea sistemelor informatice studiat la coala postliceal, anul II n care activitile de nvare se vor desfura astfel: 5 zile pe sptmn cu 6 ore pe zi pe o durat de 14 de sptmni astfel: 3 zile pregtire teoretic 2 zile pregtire de laborator tehnologic

Modelarea sistemelor informatice are o durat de 4 sptmni totaliznd un numr de 120 de ore. Dintre acestea 36 de ore de pregtire practic prin laborator tehnologic, iar 30 de ore instruire practic. Numrul de credite alocat acestui modul este de 1,5. Temele orientative, propuse pentru fiecare competen individual sunt enumerate n tabelul de mai jos. Fiecrei teme/laborator i sunt asociate fie suport care acoper, la nivel de baz, coninuturile tematice propuse de Curriculum, att pentru partea teoretic ct i pentru cea practic.

Tabelul 2. Corelaia dintre competene teme fie suport Competene individuale Teme Fie suport informaional/ Fia suport 1.1. Definiii sistem informaional /sistem informatic, componentele, rolul, obiectivele i clasificarea sistemelor informatice.

1. Caracterizeaz diferite Tema 1. Sistem tipuri de sisteme infor- Sistem informatic matice. 12 ore teorie + 12 ore lab. teh.

Tema 2. Sisteme suport de decizie / Fia suport 2.1. Definiia, caracteristicile, clasificarea, etc. Sisteme expert sistemelor suport de decizie / sisteme expert.

Tema 3. Laboratoare pentru analiza Fia suport 3.1. sistemului informaional Analiza sistemului informaional Tema 4. Tipurile i elementele de Fia suport 4.1. coninut ale metodologiilor de Tipurile i elementele de coninut ale metodologiilor de realizare a sistemelor informatice realizare a sistemelor informatice. Fia suport 5.1. Etapele, metodele i tehnicile de realizarea sistemelor informatice. Fia suport 6.1. Metodologiile de realizare a sistemelor informatice.

2. Utilizeaz metodologii de realizare a sistemelor Tema 5. Etapele, metodele i informatice. tehnicile de realizare a sistemelor informatice. 12 ore teorie + 12 ore lab. teh. Tema 6. Laborator pentru cunoaterea metodologiilor de realizare a sistemelor informatice.

Competene individuale

Teme

Fie suport sistemelor Fia suport 7.1. Elaborarea modelului logic i a celui fizic. software Fia suport 8.1. Aspecte generale, avantaje i prezentri comparative ale instrumentelor software. Obiectivele i faciliti de utilizare a instrumentelor CASE. Fia suport 9.1. Modelarea orientat obiect. Noiuni de baz, componentele limbajului.

3. Utilizeaz instrumente Tema 7. Modelarea pentru realizarea sis- informatice. temelor informatice. 30 ore teorie + 12 ore lab. teh Tema 8. Instrumente (CASE, IPSE, PSE, SEE).

Tema 9. Limbaje de modelare

Instruire practic 30 ore

Tema 10. Aplicaii practice

Fia suport 10.1. Elaborarea modelului logic/fizic pentru un sistem informatic dat.

Absolvenii nivelului 3 avansat, coal postliceal, calificarea Analist programator, vor fi capabili s utilizeze tehnologiile informatice i ale comunicrii pentru conceperea, proiectarea, elaborarea, testarea, implementarea i dezvoltarea sistemelor informatice, a programelor i a documentaiei tehnice aferente.

Astfel criteriile de performan aferente competenei individuale 1 - Caracterizeaz diferite tipuri de sisteme informatice sunt: 1.a. Identificarea rolului i obiectivelor sistemului informatic n cadrul sistemul informaional. 1.b. Clasificarea sistemelor informatice. 1.c. Caracterizarea sistemelor suport de decizie 1.d. Caracterizarea sistemelor expert. Pentru competena individual 2 - Utilizeaz metodologii de modelare a sistemelor informatice, sunt stabilite criteriile de performan: 2.a. Descrierea metodologiilor de modelare a sistemelor informatice. 2.b. Identificarea elementelor de descriere i etapelor de realizare pentru diferite tipuri de metodologii de realizare a sistemelor informatice. 2.c. Utilizarea metodelor i tehnicilor de realizare a sistemelor informatice. Competenei 3 - Utilizeaz instrumente pentru modelarea sistemelor informatice i s-au alocat criteriile de performan: 3.a. Descrierea facilitilor i obiectivelor instrumentelor CASE. 3.b. Elaborarea modelului fizic i logic al sistemului. 3.c. Utilizarea instrumentele CASE pentru analiz i proiectare structurat i orientat obiect. 3.d. Utilizarea componentelor limbajului de modelare n modelarea sistemului informatic

II. Documente necesare pentru activitatea de predare


Pentru predarea coninuturilor abordate n cadrul materialului de predare cadrul didactic are obligaia de a studia urmtoarele documente: Standardul de Pregtire Profesional pentru calificarea Analist programator, nivelul 3 avansat www.tvet.ro, seciunea SPP sau www.edu.ro , seciunea nvmnt preuniversitar Curriculum pentru calificarea Analist programator, nivelul 3 avansat www.tvet.ro, seciunea Curriculum sau www.edu.ro , seciunea nvmnt preuniversitar

Alte surse pot fi: Crile de specialitate; Reviste de specialitate; Surse web

III. Resurse
Tema 1. Sistem informaional / Sistem informatic
Fia suport 1. 1. Definiii sistem informaional /sistem informatic, componentele, rolul, obiectivele i clasificarea sistemelor informatice Organizaia este un grup, o colectivitate format din dou sau mai multe persoane, care lucreaz mpreun ntr-o activitate bine determinat, cu scopul de a realiza un set de obiective comune. Orice organizaie poate fi privit ca interaciunea dintre: sistemul operaional, care se ocup cu punerea n practic a obiectivelor organizaiei, sistemul decizional, care orienteaz i dirijeaz organizaia, sistemul informaional care gestioneaz informaiile externe i interne necesare conlucrrii dintre sistemele organizaiei.

n figura de mai jos sunt redate conexiunile i fluxurile informaionale care leag cele trei sisteme.

Figura 1. Sistemul informaional n interaciune cu sistemul operaional i cel decizional Fluxurile informaionale notate cu A, B, C i D n figura de mai sus conin n general:

informaii de la procesele desfurate n organizaie, de la pia i se pot concretiza n date numerice, rapoarte etc.

dri de seam, rapoarte prelucrate, modele i programe de calcul, reclamaii de la clieni, situaia prezenei la service etc. hotrri, instruciuni, comenzi, planuri, tehnologii, procedee etc. grafice de lucru, bonuri de materiale, instruciuni pentru controlul calitii, teste de verificare a operatorilor a.

Se vor promova metodele de predare-nvare activ-participative, care duc la rezolvarea problemei pus n discuie, astfel se poate cere cursanilor s asocieze tipurilor de fluxuri informaionale A, B, C, D din figura 2 pe cele corespunztoare, enumerate n lista de mai sus. Pentru sporirea gradului de dificultate ar trebui schimbat ordinea enumerrii, care este n acest caz chiar A, B, C, D. Sistemul informaional este un ansamblu tehnico-organizatoric de proceduri de constatare, consemnare, culegere, verificare, transmitere, stocare i prelucrare a datelor, n scopul satisfacerii cerinelor informaionale necesare conducerii procesului, fundamentrii i elaborrii deciziilor pe baza crora va funciona organizaia. Sistemele informaionale se pot clasifica dup modul n care prelucreaz fluxul informaional n: manual mecanizat automatizat mixt

n practic cele mai rspndite sisteme informaionale sunt cele mixte.

Principalele caliti pe care trebuie s le aib un sistem informaional sunt: asigurarea informrii la toate nivelele organizaiei, operativitatea informrii, selectarea informaiilor, adaptabilitatea la modificri, precizia i exactitatea informaiilor.

Sistemul informatic reprezint componenta automatizat a sistemului informaional, care folosete mijloace tehnice moderne pentru culegerea, prelucrarea, stocarea informaiilor i transmiterea acestora. 10

Pentru a servi eficient procesului decizional i operaional informaia trebuie s ndeplineasc urmtoarele criterii de calitate:

11

s fie oportun, s fie clar, s fie complet,

s fie concis, s fie fidel, s aib relevan.

Componentele unui sistem informatic sunt puse n eviden n schema din figura 2.

Sistem informatic

Componenta fizic

Componenta logic

Componenta de date

Componenta uman

Cadrul organizatoric

Figura 2. Componentele Sistemului informatic Componenta fizic (hardware) a unui sistem informatic este alctuit din totalitatea echipamentelor folosite: calculatoare, periferice de intrare, ieire sau intrare/ieire, echipamente de comunicaie, dispozitive media etc. Componenta logic (software) este format din totalitatea programelor sistemului informatic: sisteme de operare, utilitare, aplicaii, soft-uri specializate etc.

Componenta de date este format din totalitatea bazelor de date necesare funcionrii sistemului informatic au pe care acesta le prelucreaz pentru celelalte sisteme ale organizaiei. Componenta uman este format din personalul specializat pentru ntreinerea i exploatarea sistemului, dar i de utilizatorii lui direci. Cadrul organizatoric se refer la locaia fizic a beneficiarului (organizaiei) sistemului informatic. Rolul sistemului informatic deriv din rolul i funciile unui sistem informaional. Printre principalele funcii ale unui sistem informaional amintim urmtoarele: colectarea informaiilor din sistemele operaional i decizional precum i informaiile ce provin din mediul extern; memorarea acestor informaii precum i informaiile rezultate prin prelucrare; asigurarea accesului la memorie n vederea comunicrii informaiilor stocate; prelucrarea informaiilor la cererea sistemului operaional i a sistemului de conducere, verificarea informaiilor (ele trebuie s ndeplineasc criteriile de calitate de mai sus).

tim deja c sistemul informatic este subordonat sistemului decizional. Rolul sistemului decizional este de a asigura funcionarea normal i optim a ntregii activiti i de a reduce la minimum pierderile n caz de funcionare anormal. innd cont de cele de mai sus rezult c obiectivul oricrui sistem informatic trebuie s fie subordonat obiectivului propriu-zis al unitii economico-sociale, de aceea putem spune c obiectivul principal urmrit prin introducerea unui sistem informatic l constituie asigurarea conducerii cu informaii reale i n timp util, necesare fundamentrii i elaborrii operative a deciziilor. Obiectivele sistemelor informatice, care deriv din obiectivul principal, pot fi grupate dup mai multe criterii: a. b. dup importana lor avem: obiective principale obiective derivate. dup efectele pe care le produc: obiective care afecteaz activitile de baz ale organizaiei,

c.

obiective care nu influeneaz activitile organizaiei. dup posibilitatea cuantificrii efectelor produse obiective cuantificabile, obiective necuantificabile.

Se recomand renunarea la expunere i orientarea ctre metode bazate pe rezolvarea unor sarcini de lucru, utilizndu-se cu precdere rezolvarea unei game ct mai variate de aplicaii practice i punndu-se accent pe realizarea cu exactitate i la timp a cerinelor sarcinilor de lucru. Propun folosirea unui suport de curs cu spaii de completat i/sau asocierea componentelor din schema cu descrierea corespunztoare. Sistemele informatice se pot clasifica dup o gam larg de criterii. Mai jos sunt enumerate o parte dintre acestea:

1. Dup domeniul de utilizare, sistemele informatice se mpart n sisteme pentru: conducerea activitilor economico-sociale, conducerea proceselor tehnologice, cercetare tiinific i proiectare tehnologic, activiti speciale.

2. n funcie de nivelul ierarhic ocupat de componenta economic n structura organizaiei, exist sisteme informatice: pentru conducerea activitii la nivelul unitilor economice, pentru conducerea activitii la nivelul organizaiilor economico-sociale cu structur de grup, sisteme informatice teritoriale, pentru conducerea ramurilor, subramurilor i activitilor la nivelul economiei naionale, sisteme informatice funcionale generale.

3. Dup aportul la actul de decizie avem

- sisteme suport pentru decizie, - sisteme expert.

4. Dup modul de organizare a datelor: sisteme bazate pe fiiere, sisteme ierarhice, sisteme reea, sisteme relaionale, sisteme orientate-obiect, sisteme mixte. Mai jos sunt date i alte criterii de clasificare, diferite de cele pe care le sugereaz curricula. 5. Dup metoda folosit n analiza i proiectarea sistemelor : sisteme dezvoltate dup metoda sistemelor; sisteme dezvoltate dup metoda clasic a ciclului de via; sisteme dezvoltate dup metoda structurat; sisteme dezvoltate dup metoda orientat-obiect; sisteme dezvoltate dup metoda rapid(RAD); sisteme dezvoltate dup metoda echipelor mixte(JAD); sisteme dezvoltate dup metoda prototipurilor. 6. Dup gradul de centralizare: sisteme centralizate; sisteme descentralizate; 7. Dup gradul de dispersie a resurselor sistemului informatic : sisteme informatice locale (bazate pe reea local, staii de lucru): sisteme informatice distribuite (date distribuite).

8. Dup gradul de automatizare a activitilor de analiz i proiectare a sistemelor informatice: sisteme informatice dezvoltate pe baza analizei i proiectrii clasice; sisteme informatice analizate cu instrumente automate i proiectate clasic; sisteme informatice bazate pe instrumente diverse de automatizare a analizei i proiectrii; sisteme informatice dezvoltate cu instrumente de tip CASE. 9. n funcie de elementul supus analizei: sisteme informatice orientate spre funcii, sisteme informatice orientate spre proces, sisteme informatice orientate spre date, sisteme informatice orientate spre obiecte, sisteme informatice orientate spre cunotine

Clasificrile sunt un aspect important, dar nespectaculos, de aceea propun ca aceast component a temei s fie abordat sub forma unui joc. Profesorul s afieze cele 8 criterii de clasificare. Fiecare elev s extrag dintr-o urn un bilet cu denumirea unui tip de sistem informatic i mpreun cu clasa i sub ndrumarea profesorului s le grupeze n forma corect.

Pentru evaluare se recomand a fi utilizate cu precdere, alturi de metodele tradiionale: observarea sistematic a comportamentului elevilor/cursanilor care permite evaluarea conceptelor, capacitilor, atitudinilor fa de o sarcin dat, a comunicrii, investigaia, autoevaluarea prin care elevul/cursantul compar nivelul la care a ajuns cu obiectivele i standardele educaionale avnd astfel posibilitatea de a-i impune un ritm propriu i eficient de nvare, metoda proiectelor .a.

Competena individual aferent acestei teme se poate dobndi dac sunt atinse criteriile de performan din SPP 1.a) i 1b).

Tema 2. Sisteme suport de decizie / Sisteme expert


Fia suport 2.1. Definiia, caracteristicile, clasificarea, sistemelor suport de decizie / sisteme expert. Termenul de Sistem Suport pentru Decizii - SSD (Decision Support System - DSS ) a fost propus pentru prima dat de Michael Scott Morton, cu ocazia prezentrii unui seminar de doctorat, n februarie 1964. De a lungul anilor conceptul a fost definit n diferite moduri de, ctre diveri autori. Definiiile propuse fiind abordate din mai multe perspective precum: a) b) c) d) e) f) g) tipul de probleme (aplicaii), obiectivele urmrite, funciile realizate, tipul de interfa cu utilizatorul, modul de folosire, componentele sistemului, modul de construire a sistemului etc.

O prezentare a celor mai semnificative definiii permite formarea unei imagini asupra unui concept pentru care nu exist nc o definiie unanim acceptat. n 1970 Little definete calculul decizional ca un set de proceduri bazate pe modele matematice pentru prelucrarea datelor n scopul asistrii managerului n luarea deciziilor. Atributele stabilite pentru acest sistem au valabilitate i astzi: a) simplitate b) robustee, c) controlabilitate, d) adaptivitate, e) completitudine f) convivialitate. n 1971 Gorry i Scott Morton identific SSD ca sistem informatic care are menirea s ajute la elaborarea deciziilor atunci cnd problema nu poate fi analizat complet pentru a se lua o decizie, iar rezolvarea ei nu se poate programa sub forma unei secvene de pai.

n 1980 Alter definea un SSD prin difereniere de sistemele de prelucrare a datelor ale timpului su alocnd acestuia urmtoarele atribute: modul de folosire (activ, nu pasiv), utilizatorul (decident aflat pe diferite niveluri, nu un funcionar), scopul (eficacitate global, nu eficiena prelucrrii datelor), orizontul de timp(orientare ctre prezent i viitor, nu ctre trecut), obiectivul urmrit (flexibilitatea utilizrii, nu consistena datelor).

n 1980 Moore i Chang definesc SSD prin: extensibilitatea, capacitatea de a ajuta la efectuarea de analize i la realizarea unor modele de decizie ad-hoc, orientarea ctre probleme de planificare, folosirea neplanificat. n 1981 Bonczek, Holsapple i mai trziu n 1984 Whinston, influenai de arhitectura sistemelor expert, definesc SSD ca pe un sistem compus din trei componente n interaciune i anume: A. B. subsistemul de stocare a cunotinelor, subsistemul de limbaj (pentru primirea cererilor din partea utilizatorului i achiziionarea cunotinelor necesare funcionrii) subsistemul de tratare a problemei.

C.

n 1982 Sprague i Watson definesc, ntr-o lucrare devenit clasic n domeniu, SSD ca o clas de sisteme informatice care se bazeaz pe sistemele de prelucrare a tranzaciilor i interacioneaz cu alte componente ale sistemului informatic din ntreprinderii pentru a asista activitile managerilor i ale altor lucrtori. n 1983 Bennett definete SSD ca un sistem informatic coerent, care cuprinde pe lng hardware i software i documentaia necesar constituirii un suport pentru manager n ndeplinirea sarcinilor sale decizionale. n 1984 Bui spune c SSD este un sistem informatic care ajut utilizatorul s ia decizii eficiente n problemele prost structurate. n 1985 Elam arat c SSD servete la stimularea creativitii pentru luarea acelor decizii care conteaz. n 1987 Sprague consider c SSD este un sistem informatic aflat la confluena tendinelor de evoluie n prelucrarea datelor (n special n domeniul gestiunii bazelor de date) i n tiina conducerii (n special n domeniul modelelor matematice pentru management).

n 1996 Holsapple i Whinston reiau i rafineaz definiia dat de Bonczek, Holsapple i Whinston n anii 80 i completeaz componena sistemului cu un al patrulea element, subsistemul de prezentare (rezultatele procesului de fabricare a deciziei). n 1998 Turban i Aronson arat c SSD cupleaz resursele intelectuale ale indivizilor cu capacitile calculatorului n scopul mbuntirii calitii deciziilor obinnd un sistem informatic de asistare a decidenilor manageri care au de rezolvat probleme semistructurate. n 2002 Power definete SSD ca un sistem informatic interactiv menit s-l ajute pe decident s utilizeze date, documente i modele pentru a identifica i rezolva problemele care stau la baza lurii deciziilor".

Sistemul suport de decizie este o subclas a sistemului informatic, cu caracteristici antropocentrice, adaptive i evolutive, care integreaz o serie de tehnologii informatice i de comunicaii de uz general i specifice. El interacioneaz cu celelalte pri ale sistemului informatic al organizaiei. Scopul principal al unui SSD este de a diminua efectele limitelor i restriciilor decidentului intelectual pentru o gam ct mai larg de activiti/probleme decizionale nebanale prin implementarea computerizat a funciilor de suport ale deciziilor care altfel fi fost realizate de ctre o echip decizional ierarhic.

Din definiia de mai sus se pot deduce cele mai importante caracteristici ale unui SSD. 1. n cadrul unei organizaii SSD poate funciona eficient doar dac interacioneaz cu celelalte pri ale sistemului informatic i/sau informaional, de la care este alimentat cu date sau ctre care transmite informaii. Antropocentrismul SSD a devenit o necesitate datorit ameninrii majore pe care automatizarea o arunc asupra creativitii i dezvoltrii contiente a umanitii. Aceast caracteristic se cere a fi mai pregnant din punctual de vedere al modului de utilizare, al interpretrii rezultatelor, al funcionalitii, dar i al tehnologiei folosite pentru construirea SSD. Adaptivitatea este o caracteristic absolute necesar vremurilor noastre SSD trebuie s in pasul cu evoluia cerinelor utilizatorilor, dezvoltarea mediului organizaional dar i cu schimbrile tehnologice. ndeplinirea acestei caracteristici face ca sistemul s fie obligatoriu evolutiv.

2.

3.

Din definiiile date, de a lungul deceniilor, conceptului de SSD se poate extrage un subset minimal de caracteristici eseniale:

4.

Sistemul nu se substituie decidentului final, rolul SSD este limitat numai la sprijinirea activitilor de elaborare a deciziei, controlul SSD rmne n ntregime n mna utilizatorului. Problemele decizionale a cror rezolvare este sprijinit de SSD nu sunt unele banale, care ar putea fi rezolvate numai pe baza unor raionamente i judeci simple i nici nu pot fi structurate astfel nct s poat fi rezolvate cu ajutorul altor clase de sisteme informatice. Este dezirabil ca SSD s sprijine toate, sau ct mai multe dintre fazele procesului decizional i, n acelai timp, s fie aplicabil unor tipuri diferite de decizii (alegeri simple dintre un numr de alternative, decizii compuse, decizii de tip proces, decizii multiple interdependente luate pe acelai nivel sau pe niveluri diferite ale organizaiei) Clasa utilizatorilor SSD nu se limiteaz numai la managerii de vrf, ea poate cuprinde chiar i nivelurile cele mai de jos ale organizaiei. Utilizatorii pot fi individuali sau colectivi Folosirea SSD nu trebuie s se limiteze la computerizarea unor modaliti de lucru existente nainte de introducerea sistemului ci s faciliteze i s stimuleze adoptarea unor abordri noi. Datele i informaiile coninute n sistem pot proveni din diferite surse (interne sau externe organizaiei). Dimensiunea bazelor de date pe baza crora SSD transmite mesajele ctre utilizator poate varia, dar aproape n toate cazurile volumul mesajelor transmise trebuie s fie redus, adaptat ca format la necesitile informaionale ale diverselor roluri decizionale (sau chiar la stiluri de lucru individuale) i trebuie s se realizeaz on-line prin intermediul unor interfee prietenoase. mult pe creterea deciziilor (calitate, costurilor legate de decizional sau cel al

5.

6.

7.

8.

9.

10. Finalitatea utilizrii SSD trebuie s pun accentul mai productivitii muncii decidentului i mbuntirea oportunitate, aplicabilitate), mai mult dect pe scderea elaborarea acestora (incluznd costul personalului de suport prelucrrii electronice a datelor).

Tabelul 3. Clasificarea Sistemelor Suport pentru Decizii Criteriul Gradul de finalizare Tipurile de SSD - SSD specifice (de aplicaie), - Instrumente SSD (genereaz SSD), - SSD generalizate (pot fi folosite pentru cazuri specifice sau generale),

Tipul decidentului Tipul de suport Orientare sistemului

- individuale (personale) SSDI, folosite de o persoan pentru a-i realiza propriile sarcini legate de elaborarea i adoptarea deciziilor, - de grup SSDG, au rolul de a asista mai muli indivizi cu poziii de autoritate similare, care au de luat decizii colective, - SSD de organizaie SSDO, faciliteaz luarea deciziilor pentru participanii aflai pe niveluri ierarhice diferite. - de asistare pasiv (SSDAP), folosit doar ca instrument de cretere rapiditii regsirii informaiilor, efecturii unor calcule etc., - de asistare tradiional (SSDAT), evalueaz efectul alternativelor propuse de decidentul uman (Ce s-ar ntmpla dac? ), - de suport normativ (SSDSN), aplic modele matematice de optimizare asupra datelor problemei propuse de utilizator sau sunt culese automat din sistemul informatic al organizaiei, - de suport n cooperare (SSDSC), faciliteaz cooperarea dintre sistem i utilizator, joac rolul unui consultant computerizat care ofer sugestii decizionale pe care utilizatorul le poate rafina, iar sistemul le poate reevalua sau completa. - de suport extins (SSDSE), joac rolul unui consultant proactiv, care poate influena desfurarea activitii decizionale, pstrnd prioritatea judecii umane i stimulnd abordarea i delegarea funciilor suplimentare. - orientate ctre date (SSDODa), componenta tehnologic dominant a acestui sistem conine volume mari de date care trebuie prelucrate pentru a putea lua decizii, - orientate ctre modele (SSDOM), deciziile pot fi luate doar n urma simulrii pe baza unor modele matematice de optimizare, - orientate ctre cunotine (SSDOCu), sunt numite des sisteme expert sau inteligente pentru c ele ofer sugestii decidentului, se deosebesc de celelalte tipuri prin faptul c pot fi aplicate unor probleme care nu pot fi modelate matematic, - orientate ctre comunicaii (SSDOCo), asist n primul rnd codeciziile bazate pe comunicare i colaborare, ntre mai muli participani, - orientate ctre documente (SSDODo), poate fi privit ca o variant a SSDODa dar spre deosebire de prima care opera cu date structurate dup un anumit criteriu (baze de date), aceasta din urm colecteaz, gestioneaz i regsete resurse informaionale nestructurate

Tehnologia de baz Urgena deciziilor

- SSD orientate ctre texte, - SSD orientate ctre baze de date, - SSD orientate ctre foi de calcul, - SSD orientate ctre rezolvare, - SSD orientate ctre reguli, - SSD orientate ctre www. - SSD asincrone, nu ofer suport imediat ce i se cere, - SSD sincrone, ofer suport n timp real. -

Din prisma cadrului conceptual generic orice SSD se compune din urmtoarele patru subsisteme: Subsistemul de limbaj (SL) reprezint mulimea formelor de exprimare prin care utilizatorul poate transmite (sub forma unor mesaje de intrare n SSD) solicitri care pot fi nelese i acceptate de sistem, sau prin care executanii deciziilor i cei care alimenteaz cu date sistemul i pot transmite rapoartele. Subsistemul de prezentare (SP) reprezint totalitatea formelor i mijloacelor prin care sistemul emite (sub forma unor mesaje de ieire) ctre utilizatori sau teri soluii pentru probleme sau feedback. Subsistemul Elementelor de Cunoatere (SEC) conine elementele de cunoatere achiziionate sau create de ctre sistem. Subsistemul de Tratare a Problemei (STP) totalitatea modulelor software necesare pentru prelucrarea elementelor de cunoatere din SEC pe baza datelor de intrare oferite de SP i transmiterea ctre SP a mesajelor de ieire pe care le va recepiona utilizatorul. n figura de mai jos sunt incluse componentele SSD i legturile dintre care se stabilesc ntre ele i/sau cu organizaia i utilizatorii.

Figura 3. Componentele cadrului conceptual generic al SSD

Coninuturile acestei teme nu permit renunarea la expunere, dar sugerm utilizarea unei prezentri Power Point, care s cuprind: o reprezentare grafic a evoluiei conceptului de SSD i antrenarea cursanilor n descoperirea perspectivelor prin prisma crora au fost date aceste definiii. definiia acceptat astzi i antrenarea elevilor n determinarea caracteristicilor unui SSD. clasificarea acestora pentru care sugerm crearea unei plane care s fie permanent expus n clasa n care se desfoar orele. schema de reprezentare a componentelor unui SSD i antrenarea cursanilor n identificare rolurilor fiecrui subsistem.

Sugerm evaluarea prin observarea sistemic a comportamentului elevului i participarea sa activ la ndeplinirea sarcinilor propuse de profesor.

Profesorul Eduard Feigenbaum de la universitatea Stanford spunea c sistemele expert sunt programe concepute pentru a raiona n scopul rezolvrii problemelor pentru care n mod obinuit se cere o expertiz uman considerabil Ele sunt produse ale inteligenei artificiale, ramur a tiinei calculatoarelor ce urmrete dezvoltarea de programe inteligente. Ceea ce este remarcabil pentru sistemele expert, este aria de aplicabilitate ce a cuprins multe domenii de activitate de la arhitectur, arheologie, bnci, comer, educaie, pn la ingineria sistemelor i medicin.

Un sistem expert (SE) este un program care urmrete un grup de cunotine pentru obinerea n acelai mod ca i experii umani a rezultatelor despre activiti dificil de examinat. Principala caracteristic a sistemelor expert este derivat din baza de cunotine mpreun cu metoda de raionare specific. Un sistem expert trateaz cu succes probleme pentru care o soluie algoritmic clar nu exist. Primele sisteme expert dezvoltate n domenii aplicative au fost DENDRAL, destinat analizei structurilor moleculare, MYCIN, un sistem expert pentru diagnosticul i tratamentul infeciilor sanguine, sistemele EMYCIN, HEADMED, CASNET i INTERNIST pentru domeniul medical, PROSPECTOR pentru evaluarea prospeciunilor i forajelor geologice, sau TEIRESIAS pentru achiziia inteligent a cunoaterii. La nceputul anilor 1980 apar i primele aplicaii comerciale ale sistemelor expert (XCON, XSEL sau CATS-1), care au cunoscut apoi o explozie la nceputul anilor 1990, cnd acestea au fost dezvoltate i implementate n domenii financiar-contabile: control intern, audit, planificarea impozitelor, diagnostic financiar, raportare financiar, contabilitate managerial, analiz credite, analiza riscului, planificare investiii, etc.

Un sistem expert este format din cinci componente: Baza de cunotine, care servete pentru stocarea tuturor faptelor, regulilor, metodelor de rezolvare, obiectelor etc. specifice domeniului aplicativ, preluate de la experii umani sau din alte surse. Vezi figura 4.

Figura 4. Baza de cunotine Motorul de inferene, program care conine cunoaterea de control, procedural sau operatorie, cu ajutorul cruia se exploateaz baza de cunotine pentru efectuarea de raionamente n vederea obinerii de soluii, recomandri sau concluzii.

Interfaa de dialog, permite dialogul cu utilizatorii n timpul sesiunilor de consultare, precum i accesul utilizatorilor la faptele i cunotinele din baz pentru adugarea sau actualizarea cunoaterii. Modulul de achiziie a cunoaterii l ajut pe utilizatorul expert s introduc cunotine ntr-o form recunoscut de sistem i s actualizeze baza de cunotine. Modulul explicativ are rolul de a explica utilizatorilor att cunoaterea de care dispune sistemul, ct i procesul de raionament pe care l desfoar sau soluiile obinute n sesiunile de consultare. Explicaiile ntr-un astfel de sistem, atunci cnd sunt proiectate corespunztor, mbuntesc modul n care utilizatorul percepe i accept sistemul. Componentele sistemelor expert se pot grupa dup importana lor n

a. Componente principale a.1. Baza de cunotine a.2. Mecanismul (sau motorul) de inferen b. Componente secundare b.1. Interfaa utilizator. b.2. Modulul de achiziie al cunotinelor b.3. Modulul de explicaii.

Caracteristici ale sistemelor expert: vizeaz reconstituirea raionamentului uman pe baza expertizei obinute de la experi; cunotine i capacitatea de a desfura activiti intelectuale umane; achiziioneaz i exploateaz cunotinele dintr-un domeniu particular numit domeniul problemei; dispun de metode de invocare a cunoaterii i exprimarea expertizei comportndu-se ca un sistem inteligent la nivel informatic, sistemele expert, se bazeaz pe principiul separrii cunoaterii de programul care o trateaz (nu folosesc limbaje de programare algoritmice);

memoreaz cunoaterea i stabilete legturi ntre cunotine, trage concluzii, propune soluii i/sau recomandri, sau determin cauzele unor fenomene.

Sistemele expert pot fi folosite de sine stttor sau pot fi integrate n alte sisteme informatice n funcie de necesiti. O clas special de sisteme informatice, n care sistemele expert pot fi integrate mai uor din punct de vedere funcional sunt sistemele suport pentru decizii (SSD), numite n clasificarea acestora SSDOCu. Din punct de vedere operaional, un SSDOCu poate fi definit ca un sistem interactiv i flexibil care are drept obiectiv asistarea managerului n adoptarea unei hotrri atunci cnd reprezentarea unei probleme organizaionale nu poate fi complet formalizat de algoritmi. Printre caracteristicile de baz ale unui SSDOCu, cele mai importante sunt: facilitatea de a rezolva problemele, datorit asocierii raionamentului decidentului cu un sistem informatic; adaptabilitatea n timp, utilizatorii pot aduga, combin, modific i terg elemente constitutive; accesul la o mare varietate de surse de date organizaionale sau din mediul exterior; asigurarea eficacitii procesului decizional n ceea ce privete acurateea, calitatea, finalitatea etc.; asistarea deciziilor la nivel individual sau la nivel de grup de decideni; asistarea deciziei pe niveluri manageriale diferite ntr-o structur ierarhic ce pornete de la top manageri ctre nivelurile inferioare.

Metodele i tehnicile de rezolvarea a problemelor se pot clasifica dup mai multe criterii astfel: I. dup modul de fundamentare empiric A. bazate pe calculul simbolic, care pot fi: bazate pe logic (logica propoziional / predicate de ordinul I), bazate pe regulile de producie, bazate pe reprezentare structurat (reele semantice, cadre, scenarii, dependene conceptuale etc.). B. bazate pe calcul neuronal,

C. bazate pe calcul genetic. II. dup gradul de generalitate A. metode si tehnici generale - metode i tehnici directe - metode i tehnici indirecte: - prin cutarea soluiei - prin descompunerea problemei B. metode si tehnici specifice IA: - metode de achiziionare (manuale, automate) - metode de reprezentare (vezi figura 5) - metode de utilizare (vezi figura 6)

Figura 5. Metode i tehnici de reprezentare

Figura 6. Metode i tehnici de utilizare

Sugerm utilizarea studiilor de caz n care cursanii s identifice componentele unui sistemului expert sau brainstorming-ul n care cursanilor li se cere s identifice situaii concrete n care este necesar utilizarea unui sistem expert.

Se poate utiliza autoevaluarea sau intraevaluarea.

Tema 3. Laboratoare pentru analiza sistemului informaional


Fia suport 3.1. Analiza sistemului informaional

Temele 1 i 2 au acoperit coninuturile aferente competenei individuale 1 Caracterizeaz diferite tipuri de sisteme informatice ale cror criterii de performan sunt: 1.a. Identificarea rolului i obiectivelor sistemului informatic n cadrul sistemul informaional. 1.b. Clasificarea sistemelor informatice. 1.c. Caracterizarea sistemelor suport de decizie 1.d. Caracterizarea sistemelor expert. n cadrul acestor dou laboratoare se pot aborda diferite studii de caz pentru ca elevii s analizeze diverse sisteme informaionale i sistemele informatice ale acestora prin: o o o identificarea rolului i obiectivelor SI, ncadrarea acestuia ntr-o clas conform criteriilor de clasificare date, caracterizarea SSD, dac acesta exist sau enumerarea caracteristicilor unui SSD care ar fi necesar, caracterizarea SE, dac acesta exist sau enumerarea caracteristicilor unui SE care ar fi necesar, Clasa poate fi mprit n 4 grupe. Grupelor 1 i 2 li se poate repartiza un acelai studiu de caz , iar celorlalte dou un alt studiu de caz.

Se recomand interevaluarea prin schimbul ntre grupele care au acelai subiect i susinerea ideilor n faa clasei prin intermediul unui purttor de cuvnt.

Tema 4. Tipurile i elementele de coninut ale metodologiilor de realizare a sistemelor informatice


Fia suport 4. 1. Elementele de coninut ale metodologiilor de realizare a sistemelor informatice. Metodologiile s-au nscut din nevoia de aezare n tipare teoretice a rezultatului experienei practice. Realizarea sistemelor informatice este o activitate profund creativ care mbin numeroase activiti: analiz, proiectare, programare, coordonare, organizare, control.

Putem defini o metodologie dat ca fiind un model n cascad cu procese interconectate i colecii de sarcini opionale, deterministe i/sau cu precondiii n cadrul activitilor care au ca finalitate elemente livrabile.

Metodologiile se pot clasifica dup urmtoarele criterii: A. dup gradul de generalitate 1. Metodologii generale dezvoltate pentru a permite realizarea de sisteme informatice din arii de cuprindere diferite i de complexiti variabile. Exemple de astfel de metodologii: SSADM1, OMT2, UML3. 2. Metodologii cadru (frameworks) dezvoltate n general de marile case de consultanta (PwC4, KPMG5, E&Y6, etc.), cu grad ridicat de generalitate, ns incluznd elemente opionale aplicabile exclusiv unor anumite produse software (numite acceleratori). Exemple: SIIPS7 (metodologia KPMG) are definii acceleratori de implementare pentru SAP8 i Oracle.

1 2

Structured Systems Analysis and Design Methodology Object Modeling Tehnique 3 Unified Modeling Language 4 PricewaterhouseCoopers 5 Klynveld Main Goerdeler & Peat Marwick 6 Ernst & Young 7 Selection and Implementation of Integrated Packaged Software 8 System Analysis and Program

3. Metodologii specializate dezvoltate si optimizate pentru implementarea unui singur produs software: AIM9 (pentru Oracle E-Business Suite), PQIS 10 (pentru SunSystems), Extract (pentru Exact), Signature (pentru Scala), ASAP 11 (pentru SAP). B. dup modelul ciclului de via 1. Metodologii cu model n cascad

Figura 7. Modelul n cascad 2. Metodologii cu model n spiral

Figura 8. Modelul n spiral


9

Application Implementation Methodology Professional Quality Implementation Services 11 Advanced System Analysis Program
10

3. Metodologii cu model incremental

Figura 9. Modelul incremental 4. Metodologii cu model evolutiv

Figura 10. Modelul evolutiv 5. Metodologii cu modele compozite (aa numitele cicluri n V i n X)

Figura 11. Modelul n V

Figura 12. Comportamentul indus de modele, fazelor procesului de realizare

C. dup structura proceselor metodologiei 1. Metodologii monoproces,

2. Metodologii multiproces slab interconectate, 3. Metodologii multiproces interconectate. D. dup modul de abordare 1. Metodologii etnofolclorice, 2. Metodologii structurale, 3. Metodologii procesuale.

Elementele metodologiilor de realizare a sistemelor informatice cuprind : modalitatea de abordare a sistemelor, pentru elucidarea raportului dintre variaiile sistemului i dinamismul su; regulile de formalizare a datelor i proceselor de prelucrare; instrumentele pentru concepia, realizarea i elaborarea documentaiei; modalitatea de derulare a proiectului i aciunile specifice fiecrei etape (ciclul de viat); definirea modului de lucru, rolului analitilor i proiectanilor i a raportului dintre ei; modalitile de administrare a proiectului (planificare, programare, urmrire). Totodat, metodologiile au rolul de a indica modul de desfurare a acestui proces, stabilind: componentele procesului de realizare a sistemului informatic (etape, subetape, activiti, operaii) i coninutul lor; fluxul parcurgerii (executrii) componentelor; metodele, tehnicile, procedeele, instrumentele, normele i standardele utilizate Ciclul de via (derularea sa) Indiferent de etapa istoric sau metodologic, sistemele sunt abordate prin prisma ciclului lor de via. Ele apar se dezvolt, descresc i pier, sau printr-un nou ciclu, se perfecioneaz, dnd natere unei alte versiuni sau chiar unui nou sistem. Mutaiile din domeniul tehnologiei informaionale i al metodelor de abordare a sistemelor s-au reflectat i n ciclul de via al dezvoltrii sistemelor, fie prin schimbarea etapelor acestuia, fie prin modificarea opticii de parcurgere a lor. Spre exemplu, odat cu abordarea orientat - obiect a sistemelor, s-au lansat i noi modele ale ciclului de via.

Etape ale ciclului de via a unui sistem informatic n modelul cascad (vezi figura 6) 1. Iniierea sunt definite scopurile, serviciile i restriciile pe care trebuie s le ndeplineasc sistemul informatic, prezentate ntr-o manier nct s poat fi nelese att de ctre utilizatorii sistemului ct i de personalul de proiectare. 2. Analiza analiza factorilor externi i interni care pot influena sistemul 2. Proiectarea stabilirea cerinelor pentru hardware i software i elaborarea arhitecturii generale a sistemului. Funciile sistemului informaional vor fi reprezentate astfel nct s poat fi transformate n unul sau mai multe programe executabile. 3. Implementarea proiectarea software-ului din etapa anterioar este transpus ntr-o mulime de programe sau module program i verificarea faptului c fiecare program sau modul satisface specificaia sa. 4. Testarea testarea programelor i modulelor program ca un sistem complet pentru a ne asigura c cerinele informaionale sunt satisfcute. Dup testare sistemul este livrat beneficiarului. 5. ntreinerea este faza n care sistemul informatic este efectiv utilizat de ctre beneficiar i n care sunt descoperite i rezolvate eventuale erori de proiectare i programare i omisiuni n cerinele informaionale iniiale. Abordarea sistemului La nceputuri abordarea pentru implementarea unui sistem informatic se fcea pe probleme izolate i ulterior s-a efectuat trecerea la abordarea sistemic (modular), odat cu abordarea funcional sau, mai bine zis, cu analiza i descompunerea funcional (n fiecare modul exist cte o funcie) i ulterior abordarea orientat-obiect, abordarea este una de ansamblu. Pe parcurs s-au impus dou strategii de abordare i anume: strategia top down (de sus n jos); strategia bottom up evolutiv (de jos n sus).

n strategia top down abordarea general este divizat n uniti componente prin rafinri repetate, metoda de proiectare putnd fi descris sub forma unei diagrame ierarhice cu module de control pe nivele superioare i cu module detaliate pe nivelele inferioare. Structura organizatoric a unei uniti economicosociale numit organigrama unitii poate fi reprezentat printr-o astfel de diagram ierarhic. Pentru uniti economice productive n organigram se disting urmtoarele patru nivele de reprezentare:

nivelul conducerii strategice, reprezentat de directorul general i consiliul de administraie; nivelul conducerii tactice (directori pe funciuni); nivelul compartimentelor funcionale (servicii i posturi de lucru) i de proiectare, cercetare (laboratoare) care asigur conducerea operativ a sistemului prin efii lor; nivelul compartimentelor de producie (secii, ateliere) care realizeaz funcia de producie a sistemului economic.

n strategia bottom up evolutiv, se pornete de la o tratare minimal care se extinde treptat pe msura naintrii n realizarea sistemului. n practic, de cele mai multe ori se utilizeaz o combinaie dintre cele dou strategii. Metodele de realizare

Metoda = Reprezint modul unitar sau maniera comun n care analitii de sisteme, programatorii i alte categorii de persoane implicate, realizeaz procesul de analiz a sistemului informaional existent, proiectarea i introducerea sistemului informatic sau decizional dorit, are un caracter general, n cadrul ei aplicndu-se anumite tehnici de lucru. Descrierea unor astfel de metode se va face n tema urmtoare. Metodele de abordare a sistemelor informatice ar putea fi grupate astfel: metode orientate spre funcii, numite i metode ale descompunerii funcionale; metode orientate spre fluxuri date, deci metode orientate spre procese, deoarece diagramele fluxurilor de date se ntrebuineaz pentru descrierea proceselor; metode orientate spre informaie sau date , orientate-informaii, aprute ca urmare a popularizrii puternice a ingineriei informaiei a lui JAMES MARTIN, dar i a diagramelor entitate-relaie ale lui CHEN; metode orientate-obiect.

Reguli de formalizare

n proiectarea sistemului de coduri trebuie s avem n vedere dou aspecte importante i anume: influena tipului i structurii codului asupra performanelor sistemului informatic; implicaiile utilizrii codurilor n operaiile de culegere a datelor i interpretarea rezultatelor finale de ctre utilizatorii neinformaticieni. Primul aspect ridic probleme de ordin tehnic n realizarea nomenclatorului de coduri i are n vedere facilitarea operaiilor de prelucrare, ocuparea unui spaiu de memorie intern i extern ct mai mic etc. Celui de-al doilea aspect trebuie s i se acorde o atenie mai mare n vederea uurrii activitilor de culegere, verificare a datelor i interpretarea rezultatelor din situaiile finale. Avnd n vedere aceste considerente, se impune ca la proiectarea unui sistem de coduri s se respecte o serie de reguli de formalizare.

Activitile parcurse n stabilirea regulilor de formalizare sunt: analiza elementelor ce urmeaz a fi codificate; precizarea i uniformizarea tehnologiei, a denumirilor; stabilirea caracteristicilor i a relaiilor dintre elementele de codificat; alegerea tipurilor de coduri; estimarea capacitii, lungimii i formatului codurilor; atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de coduri); ntreinerea nomenclatoarelor de coduri. Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la nivelul economiei naionale (CAEN, SIRUES, SIRUTA, CNP, etc.). Tehnici

Tehnica = reprezint felul n care se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea diferitelor probleme ce apar n procesul de proiectare. Prin aceste tehnici se mbin armonios cunotinele despre metode cu miestria personal a celor chemai s aplice metodele si s utilizeze instrumentele adecvate. Descrierea ctorva tehnici utilizate va fi fcut n tema urmtoare.

Planificarea

Planificarea proiectului va cuprinde o evaluare a cerinelor informaionale ale sistemului la nivelul ntregii organizaii. Planificarea proiectului este procesul prin care are loc definirea clar a activitilor i a eforturilor necesare nfptuirii lor n cadrul fiecrui proiect. Tipurile activitilor executate n cadrul planificrii proiectului cuprind: 1. Descrierea ariei de ntindere, a variantelor i fezabilitii proiectului, 2. Descompunerea proiectului n activiti uor executabile i controlabile, 3. Estimarea resurselor i crearea unui plan al resurselor, 4. Realizarea unei prime planificri calendaristice, 5. Realizarea unui plan al comunicrilor, 6. Determinarea standardelor i procedurilor proiectului, 7. Identificarea i evaluarea riscului, 8. Crearea unui buget preliminar, 9. ntocmirea rapoartelor de activitate, 10. Definitivarea planului de baz al proiectului. Programarea

n timp s-au conturat mai multe metode de programare, dei mai corect ar fi s se numeasc tehnici de programare. Metoda programrii clasice are la baz construirea monolitic a logicii programului, fr intenii de structurare. Programul este privit n totalitatea lui i analizat direct la nivelul operaiilor elementare pe care le implic executarea lucrrii care se elaboreaz . Metoda programrii modulare const n descompunerea programului, chiar din faza de proiectare, n module uor de ntrebuinat. Fiecare modul este apoi analizat ca un program distinct i rezolvat ca atare. Metoda programrii structurate const n faptul c ofer o rezolvare standardizat i structurat, n mod unitar, a programelor, reprezentnd o ridicare a activitii de programare la nivelul activitii industriale, fundamentat pe o metodologie tiinific. Programarea structurat este caracteristic dezvoltrii sistemelor pe baza diagramelor fluxului de date i utilizeaz limbaje structurate. Ea presupune o separare ntre structurile de date i codul funciilor care le prelucreaz.

Metoda programrii orientate-obiect - const n abordarea natural a lumii reale, folosind componente modularizate i eliminnd restriciile impuse de mediul de programare. Se definesc concepte noi de tip, clas, motenire,

Urmrirea Managerul proiectului dispune de o mare varietate de tehnici pentru reprezentarea i descrierea planurilor proiectelor, care s-l sprijine n urmrirea derulrii acestuia. Documentaia planificrii poate fi alctuit din: rapoarte grafice - cele mai folosite rapoarte sub form de text. O diagrama Gantt este o modalitate de reprezentare grafic a proiectului. Cu ajutorul barelor orizontale sunt prezentate activitile planificate. Lungimea barelor este proporional cu timpul alocat activitilor reprezentate. Se pot folosi diferite culori, umbre sau forme pentru a scoate n relief anumite activiti. Ceea ce s-a planificat i realizat, de asemenea, pot fi evideniate prin bare paralele de culori, forme sau umbre diferite. Diagramele Gantt nu indic ordinea activitilor (precedena lor), ci indic data nceperii i pe cea a finalizrii. Se recomand pentru descrierea proiectelor simple sau a unor componente ale proiectelor mari, sau a activitilor prestate doar de o singur persoan, precum i pentru monitorizarea modului n care se efectueaz activitile n comparaie cu cele planificate (ca dat) .

Dac profesorul poate pune la dispoziia cursanilor surse bibliografice (tradiionale sau electronice) se poate folosi metoda proiectului. Se formeaz tot attea grupe cte criterii de clasificare a metodologiilor de modelarea a sistemelor informatice exist (grupele pot fi inegale). Fiecrui subgrup i se d sarcina s se documenteze i s fac o descriere n faa clasei a metodologiei repartizate folosind tehnica dorit (prezentare Power Point, afi, expunere, pliant). Tema proiectului trebuie dat din timp.!

Probe orale i scrise practice care atest capacitatea candidatului de a descrie metodologiile de modelare a sistemelor informatice i de a identifica elementele diferitelor tipuri de metodologii de realizare a sistemelor informatice, aa cum se specific n criteriile de performan 2.a. i 2.b. cuprinznd toate elementele din condiiile de aplicabilitate.

Tema 5. Etapele, metodele i tehnicile de realizare a sistemelor informatice


Fia suport 5.1. Etapele, metodele i tehnicile de realizare a sistemelor informatice

ETAPE n tema anterioar am enumerate etapele ciclului de via a unui sistem informatic n modelul cascad. Aceste etape pot s difere de la un model la altul i de aceea n continuare vom mai da alte exemple, n urma crora se va observa c diferenele dintre etape sunt doar de suprafa. Tabelul 4. Etapele diverselor modele SSADM studiul de fezabilitate; analiza cerinelor; MERISE12 o studiul de evaluare; o modelarea global; ICI13 elaborarea realizare; temei de

specificarea cerinelor; o modelarea conceptual; specificarea logic; o modelarea organizaional;

proiectarea de ansamblu; proiectarea de detaliu; elaborarea programelor; implementarea mului. prosiste-

proiectare fizic (inclu-o modelarea logic; siv programarea); o modelarea fizic; o implementarea gramarea) (inclusiv

METODE De-a lungul anilor s-au evideniat o mulime de metode de realizare a sistemelor informatice, dintre care amintim urmtoarele: 12

Informaional Descendent

MERISE a fost dezvoltat n perioada 1978-1979 de ctre CTI (Centre Technique d'Informatique) i CETE (Centre d'Etudes Techniques de l'Equipement) i implementat n Aix-Frana la cererea ministerului industriei. 13 ICI a fost dezvoltat de Institutul Naional de Cercetare Dezvoltare n Informatic ICI Bucureti.

Ascendent Mixt, Orientat obiect Jakson Structural, Nestructural Compus

Denumirile acestor metode sunt motenite fie de la strategia de abordare a sistemului informaional fie de la caracteristica de baz a metodei folosite. Metode informaionale (orientate spre informaii sau date) Dou realizri importante n domeniu au dat tonul unei noi orientri n abordarea sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaie, de ctre Peter P. Chen (1976), ingineria informaiei, n viziunea lui James Martin. Metoda descendent Este o metod care se bazeaz pe strategia top-down n care sistemul informaional dat este divizat n uniti componente, care sunt supuse unor rafinri repetate, pentru a face trecerea lor la un sistem informatic. Metoda ascendent Este o metod care se bazeaz pe strategia bottom-up n care sistemul informatic construit este unul minimal care apoi este supus unui proces evolutiv. Metoda mixt Este o metod care mbin metoda descendent cu cea evolutiv (vezi metodologiile cu modele compozite). Metoda orientat-obiect Metodele OO constituie o categorie particular a metodelor de dezvoltare software, care privesc construirea sistemelor pentru care clasa reprezint unitatea arhitectural fundamental. Clasa este o grupare logic a obiectelor care au aceeai structur i un comportament similar.

Metoda Jackson (descompunerii funcionale / orientate spre funcii) . Dintre autorii remarcabili care au abordat descompunerea funcional i enumerm pe civa cum ar fi DeMarco, Yourdon i Constantine, Jackson, PageJones, Warnier-Orr, Dahl, Marco&Gowan. Metoda structural n cadrul acestei metode sistemul informaional este descompus n subsisteme pn cnd se obin subsisteme uor de implementat apoi se face legtura dintre ele (se bazeaz pe principiul programrii structurate). Metoda nestructural Este o metoda care se bazeaz pe programarea nestructurat. Metoda compus n cadrul acestei metode se poate apela att la principiile programrii structurate ct i la cele nestructurate.

TEHNICI Chiar dac tehnicile reprezint un mixaj dintre cunotinele despre metode i miestria personal a analistului de sistem chemai s aplice metodele i s utilizeze instrumentele adecvate s-au impus cteva linii directoare ale acestora: - descompunerea modelului general n submodele (n funcie de caracteristici, activitate, timp etc.); - specificarea modului n care interacioneaz variabilele controlabile i noncontrolabile pentru fiecare submodel (utilizarea analizei regresionale, modele econometrice, estimri subiective); - elaborarea de previziuni pentru toate variabilele noncontrolabile folosind abordri intuitive, subiective sau matematice (analiza regresional, utilizarea seriilor de timp, etc.); - stabilirea restriciilor care limiteaz valorile variabilelor controlabile. n funcie de condiionrile asupra activitilor persoanelor ce urmeaz a fi observate, tehnicile de investigare a sistemelor se mpart n tehnici controlate i tehnici necontrolate. A. Tehnicile controlate se caracterizeaz prin faptul c informaiile sunt colectate direct de la persoanele care desfoar activitile ctre care se ndreapt studiul respective, observarea se desfoar la faa locului sau ntr-un mediu care poate fi

controlat i prin care se ncearc simularea unor diverse sarcini (observarea de laborator). Exemple: analiza activitii, analiza de protocol. 1. Analiza activitii vizeaz observarea unei activiti prin intermediul celor care lucreaz la ea, se urmrete identificarea nivelului muncii, a erorilor ce apar n timpul execuiei activitii i astfel a factorilor ce influeneaz n mod negativ performanele obinute, se vor identifica frecvena de execuie, materialele i informaiile necesare execuiei, dificultile ntmpinate, legturile cu celelalte activiti. Rezultatul fizic al acestei activiti se numete schema sau programul de observare. 2. Analiza de protocol se bazeaz pe statutul de observator-participant al executantului unei anumite activiti i are ca scop identificarea comportamentului contient al persoanei ce desfoar respectiva activitate. Se pot urmri deciziile pe care executantul le ia, opiunile pe care acesta le are, cauzele erorilor aprute i nu n ultimul rnd atitudinea manifestat de observator fa de activitatea pe care o desfoar. B. Tehnici necontrolate pot fi clasificate n funcie de subiectul observaiei n tehnici individuale, de grup i informaionale. B.1. Tehnici individuale cuprind interviul, chestionarul i agenda. B.1.1. Tehnica interviului reprezint o tehnic de investigare personal, care poate fi desfurat n timp real sau retrospectiv. Primul pas al unui interviu este investigarea, proces care vizeaz stabilirea unui set de ntrebri care s aib relevan pentru obiectivul urmrit prin analiza sistemului i s acopere ntreaga problematic studiat. Al doilea pas const n obinerea informaiilor, apoi n etapa urmtoare ele vor fi nregistrate, apoi reprezentate i la final evaluate.. B.1.2. Tehnica de chestionarului se aseamn cu tehnica interviului, dar diferena major const n lipsa comunicrii dintre analist i chestionat. Procesul de chestionare presupune parcurgerea etapelor: o o o o o o o o stabilirea scopului, stabilirea bazei de eantionare, extragerea unui eantion reprezentativ, formularea ntrebrilor i proiectarea chestionarelor, expedierea chestionarelor, colectarea rspunsurilor primate, analiza datelor, ntocmirea raportului de investigare.

B.1.3. Tehnica agendei combin tehnica interviului cu cea a chestionarului, etapele acestei tehnici sunt: - stabilirea obiectivelor observrii, - stabilirea bazei de eantionare i selectarea eantionului, - crearea procedurilor observare. - proiectarea agendei. de autodistribuirea agendelor i colectarea acestora dup o perioad stabilit de observare analiza rspunsurilor primite i elaborarea unui raport referitor la culegerea datelor pe baza acestei tehnici.

B.2. Tehnici de grup au n vedere colectarea de date de la un ansamblu de persoane i se concretizeaz n interviul de grup, brainstorming i tehnica Delphi numite i de observare i participare. B.2.1. Interviul de grup este utilizat n cazul n care persoanele intervievate nu au o imagine clar asupra fenomenului analizat i eficiena unor tehnici individuale de observare ar fi mult redus. B.2.2. Brainstorming-ul ncearc obinerea unui volum ct mai mare de idei legate de soluia ce trebuie abordat n vederea nlturrii problemelor manifestate n cadrul sistemului. Desfurarea acestui proces conine trei etape: I. pregtirea - se stabilete problema ce urmeaz a fi soluionat i grupul participant la discuie. II. discuiile care presupun c membri grupului emit idei care vizeaz obinerea unei soluii viabile. III. selecia i evaluarea ideilor efectuat la sfritul discuiei de ctre fiecare membru n parte care va alege cele mai bune 5 soluii n viziunea sa. Pornind de la rezultatele obinute astfel va putea fi selectat un numr (2-3) soluii ce pot deveni ulterior subiecte ale unei noi edine. B.2.3. Tehnica Delphi apeleaz la un grup format din specialiti care prezint celorlali membri ideile care vor fi supuse votului si naintate spre reflecie. Procesul se va repeta pana cnd investigatorul se convinge de faptul ca au fost epuizate toate ideile ce se pot formula relativ la problema adusa in discuie. Prima etapa a acestei tehnici const n pregtirea si lansarea investigaiei, ea viznd definirea aspectelor ce urmeaz a fi studiate, condiia de continuare a investigaiei o reprezint obinerea unui acord minim de 50% pentru ideile prezentate, altfel se revine la prima faza, la final rspunsurile obinute sunt analizate si prelucrate pentru a evidenia soluia. B.3. Tehnici informaionale au ca principal scop urmrirea i analiza documentaiei, a mediului care stocheaz informaiile i care se identific ntr-o important resurs de informare. Din cadrul acestor tehnici fac parte analiza

documentelor i diagramelor, concordana decizie/reprezentare, analiza i organizarea datelor.

intrare-ieire,

tabele

de

B.3.1. Analiza documentelor urmrete fluxul de informaii, stabilind care sunt sursele de date pentru fiecare cmp, cantitatea de informaii, rapoartele utilizate, destinaiile lor dar i probabilitatea de apariie a unor erori. Procesul de realizare a unei astfel de analize ntmpin greuti datorit numrului mare de formulare i rapoarte utilizate n cadrul unei uniti economice. De aceea se recomand ca ea s fie nsoit de interviuri, analiza de protocol sau simularea. B.3.2. Analiza diagramelor are drept scop construirea de modele plecnd de la o anumit situaie. Aceste modele vor surprinde legturile dintre subsisteme, procesele de baza ale sistemului sau fluxurile de materiale. Proiectarea sistemelor informatice nseamn s ti CE i CUM trebuie fcut n cadrul fiecrei etape a ciclului de dezvoltare a sistemului. Rspunsul la aceste ntrebri l ofer metodologiile. Pentru a realiza o modelare eficient a unui sistem informatic persoanele care au un anumit rol n acest proces i entitile care opereaz n sistem (de exemplu documentele de intrare), trebuie incluse n model mpreun cu funciile pe care le ndeplinesc, cu comportamentul lor, cu datele referitoare la ele i dependenele dintre ele. Prin comportament se nelege c ceea ce fac ei n anumite mprejurri, n contextul funciilor lor, are efecte asupra datelor. Iar n ceea ce privete datele, exist date care determin starea comportamentelor, date de care persoanele implicate au nevoie pentru a-i ndeplini funciile (respectiv procesul n care sunt implicate) i date sunt modificate sau sunt produse prin activitatea lor. Diversitatea metodelor de abordare a sistemelor informaionale are de a face i cu nevoia de a surprinde funciile, comportamentul i datele implicate n sistem, n sensul c unele metode surprind mai uor funciile, altele redau mai uor comportamentul, iar altele evideniaz mai bine datele. Dac am imagina un spaiu cu cele trei dimensiuni ce caracterizeaz o entitate (funcia, comportamentul sau datele de care este legat), atunci poziia oricrei entiti n acest spaiu va depinde de ponderea pe care o au n existena acelei entiti, funcia, comportamentul i datele de care este legat. Cnd analitii ncep s studieze un sistem informaional, n vederea automatizrii acestuia, ei trebuie s identifice care este trstura dominant a sistemului (coordonata cu valoarea cea mai mare) i s aleag metoda de abordare, respectiv metodologia cea mai potrivit. Odat aleas metoda de abordare a sistemului informaional, ar trebui identificat ciclul de via al dezvoltrii sistemului (ciclul asociat metodologiei respective), aa cum apare el n literatura de specialitate i ar trebui efectuate operaiile specificate n cadrul metodologiei, pentru fiecare etap. Pentru a preciza CE trebuie fcut, n metodologie sunt enumerate obiectivele urmrite n cadrul fiecrei etape, iar pentru a preciza CUM trebuie fcut, este precizat forma sub care se consider c se poate prezenta fiecare din aceste obiective, n cadrul documentaiei de faz. Uneori aceast form de prezentare poate fi una grafic,

dar nu una oarecare ci respectnd forme i nscrisuri tipizate, prevzute n metodologie. O astfel de form tipizat se numete formalism. Formalism, n sensul de mai sus, nseamn un set de definiii i reguli, combinat cu un set de tipuri de diagrame i/sau de tabele numite reguli de formalizare. Cele mai sofisticate formalisme le conine metoda Merise, dar i diagramele de flux ale datelor (DFD) sau cele de tip entitate_relaie (DER) sunt tot nite formalisme. Numai dup ce proiectantul aplic situaiei concrete, oferit de sistemul analizat, formalismul specific etapei, el poate ndeplini cerinele de proiectare privind documentaia de faz. Documentaia de faz are pe de o parte rolul de a valorifica constatrile etapei curente pentru a putea fi folosite ca punct de plecare pentru etapa urmtoare, iar pe de alt parte ea are i un rol comunicativ n relaia cu beneficiarul pentru c prin consensul dintre proiectant i beneficiar, proiectantul trebuie s aib garania c a neles cerinele beneficiarului i beneficiarul trebuie s aib garania c proiectantul va realiza un sistem care s satisfac aceste cerine. Legat de acest aspect, documentaia de faz mai are i o utilitate juridic, n sensul c ea poate constitui baza legal pentru plata muncii efectuate de proiectant, iar n caz de litigii ulterioare ntre proiectant i beneficiar, documentaia de faz poate constitui un factor care nclin balana n favoarea uneia sau alteia dintre pri, dup cum situaia din teren corespunde sau nu cu ceea ce s-a aprobat de ctre beneficiar prin avizarea documentaiei de faz. Avizarea documentaiei de faz are loc nainte de a se trece la faza urmtoare. Foarte rar ciclul de via al dezvoltrii sistemului informatic se deruleaz secvenial i o singur dat. De cele mai multe ori ciclurile se reiau din diferite puncte (un du-te vino) i uneori chiar de mai multe ori i din puncte diferite. Motivul pentru care se complic lucrurile n acest fel este acela c de cele mai multe ori, prima variant a softului produs iniial nu este satisfctoare. Cauzele acestei situaii sunt multiple. Iat doar cteva dintre ele: pe timpul elaborrii unei variante, n sistemul analizat pot s intervin schimbri de structur sau de funcionare; este mai greu s perfecionezi o aplicaie care nc nu funcioneaz, aflat doar pe hrtie, dect una care a nceput s funcioneze; ca urmare ncepem cu ceva care urmeaz a fi perfecionat; cnd ai dat primul program n funciune, ncepe comunicarea adevrat cu beneficiarul, care s-ar putea s constate c n-a fost bine neles, sau ceea ce a primit nu era ceea ce i dorea.

Sugerm folosirea jocului de rol n care o parte din membri unui grup s fie reprezentanii beneficiarilor unei organizaii care dorete implementarea unui sistem informatic, iar ceilali s reprezinte o organizaie specializat n implementarea sistemelor informatice. Beneficiarii vor trebui s-i defineasc cerinele pentru sistemul informatic, iar analitii vor elabora i aplica una sau mai multe din tehnicile enumerate

pentru a determina caracteristica dominant a sistemului informatic solicitat i alegerea metodologiei corespunztoare.

Se poate cere fiecrei echipe de analiti s realizeze un referat despre metodologia aleas, iar echipei de beneficiari s fac o analiz critic a acesteia pe baza cerinelor exprimate iniial.

Tema 6. Laborator pentru cunoaterea metodologiile de realizare a sistemelor informatice.


Fia suport 6.1. Metodologiile de realizare a sistemelor informatice. n orice metodologie de realizarea a sistemelor informatice prima etap poate fi numit generic definirea strategiei de analiza-proiectare. 1. Definirea strategiei de analiz-proiectare n cadrul acestei etape se realizeaz o analiz detaliat, complet a organizaiei. n figura 13 se pot urmrii etapele pe care trebuie s le parcurg analistul n aceast etap.

Figura 13. Schema definirii strategiei de analiz - proiectare Subetape acestei etape sunt: - Definirea direciilor de analiza: obiective, prioriti, limite, factori de influenta; - ntocmirea diagramei entitate - relaie; - Definirea ierarhiei de funcii; - Recomandri de proiectare; - Problemele organizaionale si tehnologice; - Definirea limitelor sistemului;

- Definirea unei posibile arhitecturi a sistemului; - Aproximarea necesarului de resurse. Pentru obinerea studiului (raportului) strategic pe baza cruia se va alege strategia poate fi aplicat o metod "top-down", ilustrat n figura 14. n aceast figur se poate vedea c plecnd de la obiectivele organizaiei i aplicnd tehnici specifice de obinere a modelelor de realizare a unui sistem informatic exist posibilitatea/necesitatea revenirii n cadrul procesului pn cnd se va ajunge la raportul strategic.

Figura 14. Scenariu pentru obinerea raportului strategic

2. Analiza de sistem n aceast etap se pleac de la strategia definit anterior parcurgnd subetapele: - Detalierea diagramei entitate - relaie; - Detalierea funciilor la acest nivel;

- ntocmirea matricelor de corelaie funcie-entitate, funcie-sistem i entitate-sistem; - ntocmirea modelelor pentru fluxul de date, dependena funciilor i tranziia strilor; - Aproximarea volumelor de date, a frecvenei funciilor i a performanelor sistemului; - Definirea modului de lucru. n figura 15 se poate vedea schema derulrii analizei de sistem.

Figura 15. Derularea analizei de sistem

3. Proiectarea sistemului informatic n faza de proiectare a sistemului informatic vor fi preluate specificaiile detaliate elaborate n faza de analiz i se vor definitiva structura bazei de date, modulele i procedurile funcionale, formatele de intrare/ieire i ecranele aplicaiei. Subetapele acestei etape sunt: - Arhitectura sistemului; - Proiectarea modulelor; - Proiectarea fiierelor i a bazei de date; - Detalierea dimensiunilor sistemului; - Definirea modului de testare a sistemului; - ntocmirea documentaiei aproape de forma final; - Revizuirea planului de dezvoltare a sistemului. De asemenea, proiectarea este un proces predominant iterativ, cu posibilitatea revenirii pe subetape cnd modul de finalizare a acestora nu este acceptat de ctre echipa de analiza-proiectare.

Figura 16. Proiectarea - proces iterativ La sfritul acestei etape, att baza de date, ct i modulele aplicaiei sunt pregtite pentru implementare, iar dac sistemul trebuie s fie distribuit, se va definitiva i arhitectura reelei de calculatoare. 4. Construirea sistemului informatic Etapa de construire presupune codificarea i testarea programelor, utiliznd instrumente adecvate, depinznd de echipamentele tehnice i de complexitatea programelor respective. Procesul constructiv implic modelarea i proiectarea structurii programelor, codificarea, testarea buttom-up i/sau top-down (la nivel de sistem). n urma fazei de documentare se obin manualele de prezentare i utilizare a aplicaiei, documente necesare fazei de implementare a sistemului. La realizarea acestei documentaii vor fi folosite specificaiile de documentare elaborate nc din etapele de definire a strategiei si analiz a sistemului. Documentaia va conine descrierea funciilor sistemului, a ecranelor i rapoartelor, a mesajelor de eroare i a altor informaii generale, necesare pentru nelegerea modului de funcionare a sistemului i asistarea utilizatorilor. 5. Implementarea si exploatarea sistemului informatic Implementarea va fi precedat de o etap de tranziie care are rolul de a minimiza disfuncionalitile vechiului sistem i pregtirea utilizatorilor pentru exploatarea celui nou.

Figura 17. Implementarea sistemului informatic Exploatarea presupune utilizarea sistemului implementat cu minim de intervenii din partea operatorilor i monitorizarea permanent a performanelor acestuia. Eventualele modificri care vor fi aduse sistemului nu trebuie s conduc la ntreruperea procesului de exploatare. Pe parcursul acestei faze va fi asigurat realizarea unor copii de siguran pentru fiiere i baza de date, precum i construirea de arhive pentru acestea.

Se propune analizarea fiecrei etape n cte o or de laborator, folosind activiti de nvare predare cu caracter activ, interactiv i centrate pe elev/cursant. De exemplu se mparte clasa n 5 grupe i se ofer spre studiu fiecrei grupe una din etape, fiecare grup avnd obligaia s realizeze un raport cu cele mai importante caracteristici ale etapei, sau cu dificultile de nelegere ntmpinate, urmnd ca n ora urmtoare prima grup s paseze propria etap celei de a doua grupe i s primeasc etapa de la cea de a cincia grup. n ultima or alocnd cte 10 minute pentru prezentarea, de ctre un purttor de cuvnt al fiecrei grupe, concluziilor emise pe baza rapoartelor ntocmite n cele cinci ore anterioare.

Se poate evalua gradul de implicare n al fiecrui membru, pertinena concluziilor, capacitatea de sintez etc.

Tema 7. Modelarea sistemelor informatice.


Fia suport 7.1. Elaborarea modelului logic i a celui fizic.

Realizarea unui sistem informatic presupune o proiectare prealabil a acestuia, n concepia majoritii managerilor i a analitilor de sistem aceast activitate se desfoar pe dou direcii att proiectarea logic ct i cea fizic. Modelul logic al unui sistem informatic n etapa de proiectare a modelului logic se urmrete atingerea urmtoarelor obiective: determinarea cerinelor logice ale noului sistem. reproiectarea sistemului informaional cu precizarea zonelor unde va interveni prelucrarea automat a datelor, dac este cazul. ntocmirea specificaiilor de definire a sistemului care vor sta la baza proiectrii fizice.

Definirea modelului logic al noului sistem presupune executarea unei succesiuni de activiti n care se urmrete: Stabilirea conceptului general de funcionare a sistemului i precizarea zonelor acestuia n care prelucrarea datelor se va executa automat. Proiectarea structurii generale a bazei de date i precizarea msurilor de securitate n procesul de prelucrare a datelor pe care le va asigura noul sistem. Se evideniaz astfel fiierele permanente, istorice i temporare prin intermediul crora se va asigura prelucrarea datelor asistat de calculator. Codificarea datelor care poate influeneaz decisiv acurateea funcionrii subsistemelor informatice. Principiile generale de realizare a unei bune codificri, literatura de specialitate menioneaz urmtoarele: codificarea trebuie fcut astfel nct s ofere posibilitatea unei interpretri ct mai uoare a semnificaiei fiecrui cod; s nu existe ambiguiti, s se respecte unicitatea codificrii; reactualizarea codurilor trebuie s poat fi fcut uor i ori de cte ori este nevoie; structura codurilor trebuie definit astfel nct o eventual extindere a acesteia sa nu afecteze ntreg procesul de codificare;

codurile folosite n noul sistem este bine s poat face legtura ntre diversele elemente ce apar n sistem (compartimente, persoane, produse, materiale etc.)

Precizarea circuitelor informaionale existente n noul sistem prin care se va asigura transferul de informaii i decizii ntre subdiviziunile organizaiei. Proiectarea ieirilor fiecrui subsistem cu evidenierea tipurilor i a coninutului acestora, frecvena de obinere, volumul de date, tipurile de suport, criterii de control-validare a datelor de ieire. La proiectarea rapoartelor finale, obinute n noul sistem n mod automat sau manual, proiectantul trebuie s aib n vedere urmtoarele aspecte: cui i este destinat i cnd, n special pentru a putea determina nivelul de detaliere al informaiilor (mare pentru nivele inferioare de conducere i sintetic pentru conducerea superioar a societii); dac conine toate informaiile necesare utilizatorilor raportului; dac se manifest fenomenul de redundan i, n caz afirmativ, cauza acestuia; dac exist posibilitatea gruprii coninutului mai multor rapoarte ntr-unul singur.

Proiectarea intrrilor n fiecare subsistem cu evidenierea documentelor primare, coninutul acestora, volumul datelor, frecvena fiecrui document, tipuri de suport, criterii de validare a datelor ce urmeaz a fi supuse prelucrrii. Rezultatul proiectrii logice este un pachet de documente care cuprinde:

a) b)

Diagramele fluxurilor de date care sprijin funciile sistemului Dicionarul de date n care sunt descrise caracteristicile fluxurilor de date i a celor stocate Specificaiile proceselor Documentele de intrare Documentele de ieire Cerinele de securitate i control Nivelul performanelor sistemului Condiiile de conversie a sistemului

c) d) e) f) g) h)

Diagramele fluxurilor de date permit ilustrarea grafic a proceselor din sistem i a fluxurilor de date generate de acestea. n desenarea acestor diagrame se folosesc patru simboluri de baz. Vezi tabelul de mai jos. Tabelul 5. Simbolurile de baz ale diagramelor Fluxuri de date Stocarea datelor Proces Entiti externe

Fluxurile de date configureaz traseul datelor ntre procese, entitile externe ale sistemului i punctele de stocare a datelor/informaiilor. Aceste fluxuri sunt etichetate cu tipul datelor i pot fi constituite din rapoarte, documente sau fiiere. Procesele din sistem transform fluxurile de date de intrare n fluxuri de date de ieire. Convenional, procesul este identificat prin asocierea unei etichete cu denumirea lui. Denumirea se formeaz pe baza combinaiei dintre o aciune i obiectul acesteia. De exemplu, se poate denumi procesul de calculare a salariilor calcularea salariilor". Stocarea datelor se poate realiza manual sau automat i const din fiiere de calculator sau baze de date, fie, dosare, microfie sau teancuri (stive) de rapoarte etc. Entitile externe iniiaz sau primesc fluxurile de informaii. Ele constau din clieni, furnizori, agenii guvernamentale, angajai sau departamente din interiorul organizaiei aflate n afara sistemului informatic existent. n figura de mai jos este dat un exemplu de diagram de flux referitor la comanda unui client cu trei niveluri de detaliere.

a.

nivelul 1 de detaliere

b. nivelul 2 de detaliere

c.

nivelul 3 de detaliere

Figura 18. Diagrama de flux referitor la comanda clientului Modelul fizic al unui sistem informatic n aceast etap se elaboreaz sistemul informatic i subsistemele acestuia, care vor ndeplini cerinele stabilite n etapa precedent (modelul logic). Proiectarea (modelarea) fizic are urmtoarele trei faze: I ntocmirea specificaiilor de realizare a soluiilor prezentate n etapa logic la nivelul ntregului sistem. proiectarea componentelor sistemului specificaiilor pe componente. (subsisteme i/sau aplicaii) i a

II

III

alegerea i dimensionarea echipamentelor de calcul i de comunicaie.

Principalele categorii de informaii ce trebuiesc avute n vedere n elaborarea modelului fizic sunt urmtoarele: a. Categoriile de proceduri automate folosite, cu precizarea la nivelul fiecruia a urmtoarelor aspecte: funciuni, variante funcionale, informaii de intrare-ieire, mod de exploatare, mod de tratare a erorilor de operare etc. Specificaii pentru fiiere i/sau baza de date, care se refer la:

b.

- lista fiierelor, modul lor de organizare i accesare a nregistrrilor, supori de memorie folosii, dimensiuni etc.; - descrierea structurii nregistrrilor cu precizarea atributelor, a naturii i mrimii acestora; - structura detaliat a documentelor primare i a situaiilor informaionale - proceduri de protecie a datelor. c. Specificaii corespunztoare procedurilor manuale ce se vor executa n noul sistem i modul de corelare al acestora cu cele automate. Implicaiile noului sistem asupra sistemului de management al societii, cu detalierea modificrilor impuse. Modaliti de implementare a noului sistem i msuri de familiarizare a personalului utilizator cu modul su de lucru. Graficul de elaborare i testare a subsistemelor componente.

d.

e.

f.

g. criteriile de nivel tehnic (utilitate i eficien) i cele de nivel economic (costuri) n alegerea echipamentelor de calcul i de comunicaie. n tabelul de mai jos sunt prezentate principalele patru variante ale unui sistem informatic cu punctele tari i punctele slabe aferente.

Tabelul 6. Analiza diverselor variante de implementare a sistemelor informatice Varianta de Descrierea variantei computerizare Computerizarea centralizat

Puncte tari

Puncte slabe

Presupune conectarea Asigur o securitate unor terminale la un ridicat, deoarece calculator central, care toat procesarea efectueaz toate calcueste controlat la o lele i controleaz toate locaie central perifericele.

ntreaga siguran depinde de calculatorul central; dac acesta se defecteaz, tot sistemul va fi afectat.

Computerizarea individual

Flexibilitate mare Colaborare dificil pentru utilizatori. ntre utilizatori. Fiecare birou, sau individ utilizator dispune de un Un impact minim calculator, fr a fi co- determinat de ceea ce ali utilizatori nnectat n reea. tmpin n timpul lucrului Echipamentele pot avea timpi mori care nu se pot compensa de la un calculator la altul.

Computerizarea distribuit

Diversele posturi de lucru sunt interconectate pentru a profita de resurse comune (calculatoare mai mari, imprimante, programe)

Posibiliti superioare de folosire n comun a resurselor. Sistemul nu este afectat dac o parte a reelei se defecteaz.

Administrare complicat. Datorit distribuirii operaiilor de calcul i a datelor, securitatea se asigur dificil.

Computerizare n reea.

Posibiliti de folosiO mulime de computere re n comun a resur- Dependena de un server central. sunt conectate la un selor. server central, care le Este mult mai uor La computerul utilicontroleaz operaiile i de administrat dect zatorului abilitatea conecteaz reeaua la un sistem cu com- de procesare este alte servere puterizare distribui- limitat. t.

Se recomand ca locul de desfurare a acestei activiti de predare s fie un laborator/cabinet echipat cu calculatoare, iar pentru asigurarea instruirii interactive se recomand prezena unui videoproiector.

Probe practice din care s reias c elevul tie s realizeze diagrama fluxului de date, descrierea proceselor, descrierea entitilor, descrierea intrrilor/ieirilor, structura logic a datelor, descrierea entitilor, descrierea relaiilor dintre entiti, i aciunile necesare proiectrii fizice a cerinelor din modelul logic.

Tema 8. Instrumente software (CASE, IPSE, PSE, SEE).


Fia suport 8. 1. Aspecte generale, avantaje i prezentri comparative ale instrumentelor software. Obiectivele i faciliti de utilizare a instrumentelor CASE tim c informatica se ocup de aspectele teoretice ale dezvoltrii software. tiina aprut n 1968, numit Software Engineering, numit la noi Ingineria Programrii (IP), se ocup de aspectele practice ale dezvoltrii software, deoarece teoriile dezvoltate de informatic sunt, n prezent, insuficiente pentru a constitui o fundamentare complet pentru IP. Instrumentele software care s-au impus de a lungul timpului sunt: CASE (Computer-Aided Software Engineering) primul software de acest tip a fost fabricat de Nastec Corporation Southfield, Michigan n 1982. IPSE (Integrated Programming Support Environment) PSE (Programming Support Environment) SEE (Support Software Engineering )

Importana i avantajele utilizrii CASE-urilor n realizarea pachetelor, sistemelor de programe de aplicaie poate fi rezumat la cteva aspecte: scurteaz durata de realizare a proiectelor i de implementare a aplicaiilor, asigur din punct de vedere calitativ produsul software i crete ncrederea utilizatorului n calitatea acestuia, asist realizarea fiecrei etape i mbuntete calitatea procesului de realizare, dezvoltarea software-ului se face conform unor metodologii care specific pe lng etapele de dezvoltare, coninutul i ieirile fiecrei etape, n mod difereniat dup natura produsului sau dup domeniul su de aplicaie, obinerea de specificaii de definiie complete, acurateea specificaiilor de realizare (de proiectare), obinerea unei ci uor de ntreinut i dezvoltat (n ideea c un produs software nu este niciodat n mod real terminat, dezvoltarea sa fiind prelungit de operaiile de mentenan).

Obiectivele pe care trebuie s le ndeplineasc o colecie de instrumente ca s fie calificat drept un produs de tip CASE sau un mediu CASE sunt:

s ofere faciliti grafice puternice pentru a descrie i documenta software-ul (simplificarea proiectrii ) s fie integrat, astfel nct s permit transmiterea uoar a datelor ntre componente (simplificarea implementrii i testrii) s stocheze informaiile referitoare la software ntr-un depozit computerizat, care s permit accesarea informaiilor de ctre toi membrii echipei de elaboratori printr-o interfa prietenoas (corectitudine, exactitate, acuratee), s poat fi utilizat ca baz pentru automatizarea procesului de producere a software-ului utiliznd una sau mai multe metode de analiz-proiectare (standardizarea proiectrii), s fie reutilizabil pentru dezvoltarea de noi sisteme, aplicaii i programe (reutilizare) s poat fi utilizat pe orice platform hardware ncepnd cu calculatoare personale pn la mainframe-uri (flexibilitate), s permit realizarea uoar a interfeei cu utilizatorul final i expandarea interaciunii cu acesta (prezentare vizual a specificaiilor) s asigure dezvoltarea de aplicaii n limbaje de programare evoluate (eficien) s asigure din punct de vedere calitativ software-ul realizat (calitate).

Utilizarea instrumentelor CASE genereaz o serie de faciliti, i anume: - pot deveni suport pentru mai multe metode de analiz, - sprijin conducerea proiectului, - ajut la realizarea de prototipuri, - genereaz documentaia, - genereaz automat coduri.

Instrumentele CASE ofer sprijin utilizatorului prin metodologiile prestabilite, pe care acesta le poate urma n cadrul proiectului de modelare/implementare a sistemului informatic dorit. Instrumentele acestuia ofer sprijin n realizarea diagramelor pentru: activitii, care reprezint comportamentul operaiilor ce utilizeaz seturi de aciuni; clasele, care exprim structura static a unui sistem relativ la clase i relaiile dintre ele; colaborrile, care ilustreaz interaciunile dintre obiectele utilizate: structur spaial ce reprezint domeniul fizic. componentele, care descriu componentele software ale unei aplicaii n mediul de

implementare; distribuire, care prezint locaiile componentelor software pe componente hardware; obiecte, care exprim structura static a unui sistem n funcie de toate obiectele sale i relaiile dintre ele; secvene, care ilustreaz interaciunile dintre obiecte utiliznd o structur temporal de reprezentare a proceselor; tranziiile strilor, care reprezint comportamentul claselor utiliznd maini de stri; cazurile de utilizare, care sunt reprezentri ale funcionalitii unui sistem, din punctul de vedere al utilizatorilor si.

Structura unui mediu CASE poate fi reprezentat ca n figura de mai jos:

Figura 19. Componentele unui produs CASE Editorul de diagrame - este componenta obligatorie a oricrui produs de tip CASE i permite construirea i modificarea tuturor tipurilor de diagrame utilizate de metodologia / metodologiile implementate prin CASE. Introducerea informaiilor n editor poate fi fcut n dou moduri: - de ctre utilizator, prin intermediul unei interfee, - din repository, atunci cnd acesta este actualizat prin reverse engineering. Editorul de diagrame trebuie s satisfac urmtoarele condiii: o s permit introducerea i modificarea uoar a tuturor entitilor grafice descrise de metoda de proiectare;

suprafaa grafic s fie de calitate, s permit operaii de zoom, de grupare i aliniere a elementelor diagramei; s permit tiprirea eficient a documentelor i paginarea lor precum i selectarea informaiilor ce vor fi tiprite; s dea posibilitatea de a decide entitile ce vor fi cuprinse ntr-o pagin fr a trunchia informaiile; s permit construirea automat a unor tipuri echivalente de diagrame.

Pentru realizarea acestor faciliti i deoarece opiunile i comenzile de editare a diferitelor diagrame sunt foarte numeroase editorul de diagrame folosete n general bare de comenzi, cutii de dialog sau meniuri senzitive de context. Baza de informaii (repository) - este, de asemenea, o component obligatorie care are drept rol acumularea i stocarea n maniera organizat a tuturor informaiilor introduse de persoane diferite la momente diferite, eventual n locuri diferite. Repository-ul este elementul central, inima unui CASE, care trebuie s memoreze toate informaiile despre proiecte i s permit ca pornind de la acestea s se creeze informaie nou care s fie la rndul ei plasata n repository. Pentru un proiect sunt verificate i corelate toate informaiile existente n repository cu scopul de a asigura integritatea i consistena lor. Mai exact diferitele tipuri de diagrame reprezint aceeai informaie privit din diferite puncte de vedere, deci trebuie s aib o legtur logic ntre ele. Datele introduse n anumite diagrame pot fi utilizate si n alte tipuri de diagrame si depozitul de date este cel care asigura consistenta informaiei ntre diferitele diagrame. Modificrile efectuate asupra unei entiti dintr-o diagrama sunt automat reflectate n reprezentarea ulterioar a aceleiai entiti n orice alt diagram. Dintre caracteristicile i n acelai timp avantajele oferite de acest instrument sunt urmtoarele: documentaia de realizare a oricrui proiect, n totalitatea ei, se gsete n repository, de unde poate fi tiprit integral sau parial i la cerere, documentaia final a produsului software este realizat pe baza informaiilor despre proiect, coninute n repository, creterea preciziei i a acurateei documentaiei fa de cazul n care aceasta este realizat pe hrtie, deoarece sunt detectate erorile, inconsistenele i omisiunile, tiut fiind c mai cu seam n cazul aplicaiilor i produselor software complexe elaborate n cadrul unei echipe aceste aspecte sunt greu de controlat, asigur lucrul n echip i n reea, pe de-o parte prin accesul controlat al membrilor echipei la componente de diferite nivele ale proiectului, pe de alt parte prin gestionarea legturilor dintre componentele ce formeaz arhitectura unei aplicaii, a unui proiect.

Analizorul de structur - este componenta care are drept rol depistarea i eliminarea unor erori dificil de localizat i tratat n fazele ulterioare celei de introducere a informaiilor. Analizorul este n strns legtur cu editorul de diagrame i cu repository i funcia lui este de a compara ultimele date introduse cu cele existente pe repository, i de a semnala: introducerea n acelai domeniu de vizibilitate (diagram, dicionar de date, etc.) a dou entiti de acelai tip, cu acelai nume, verific dac toate entitile referite sunt definite, semnaleaz relaii de motenire definite circular, verific corectitudinea semantic i sintactic a adnotrilor formale.

Instrumente pentru reverse engineering (inginerie invers) au rolul de a reveni din fazele de sfrit ale realizrii aplicaiei n fazele de nceput, adic actualizarea diagramelor n raport cu modificrile efectuate n cod. Acest lucru permite dezvoltarea interactiv a unui produs software prin bascularea ntre proiectare i implementare. Generatorul de cod - permite transformarea n cod, ntr-un anumit limbaj de programare, a diagramelor realizate n faza de proiectare. Browser specializat - este instrumentul pentru vizualizarea informaiilor unei mulimi de entiti cu structur complex, entiti ntre care exist o multitudine de relaii. El permite accesul direct al utilizatorului la diagramele care descriu proiectele, coninute n repository i pentru a facilita accesul la informaii dispune de opiuni de filtrare i cutare. Aceste posibiliti fac posibil regsirea rapid a resurselor unui proiect i reutilizarea unor module n cadrul diferitelor proiecte n curs de dezvoltare Generator de documentaie - conine modele de documente i ofer utilizatorului posibilitatea de a-i concepe propriile documente n mod flexibil. Fiind legat de repository, furnizeaz informaii la zi referitoare la proiect. Orice modificare a unei diagrame dintr-un proiect induce modificarea automat a documentului asociat. Pot fi generate rapoarte standard pentru monitorizarea unui proiect si pentru evaluarea informaiilor de dezvoltare, dar pot fi realizate i rapoarte proprii ale utilizatorului. Gestiunea configuraiei - configuraia nsemnnd proiectul aplicaiei, codul i documentaia, toate putnd fi gestionate global. Acest lucru permite membrilor echipei de dezvoltare s lucreze n paralel i n acelai timp s foloseasc informaia coninut n modelul global pentru a dezvolta orice proiect nou.

Se recomand ca locul de desfurare a acestei activiti de predare s fie un laborator/cabinet echipat calculatoare pentru fiecare elev, conectate la internet i un

videoproiector. Se poate ncepe lecia folosind metoda documentrii elevii fiind cei care pot descoperi nelesul acronimelor din titlul temei i soft-ul open source.

Probe orale i practice din care s reias c elevul cunoate i poate utiliza facilitile i obiectivele instrumentelor CASE.

Tema 9. Limbaje de modelare


Fia suport 9.1. Modelarea orientat obiect. Noiuni de baz, componentele limbajului.

Modelarea orientat obiect a aprut n aceeai perioad cu primele limbaje de programare orientate obiect. n cadrul acesteia sistemul informatic este perceput ca un ansamblu de obiecte autonome care se organizeaz i care coopereaz ntre ele. n conceptul de obiect se cuprind att structurile de date ct i prelucrrile i deci obiectul are propriul su comportament. OBIECT A structuri de date MESAJ Metode Figura 20. ncapsularea n obiecte a structurilor de date i a metodelor (operaiilor) Elementele de baz ale limbajelor de modelare sunt blocurile de construcie (building blocks), simbolurile de reprezentare (projections) i pachetele (packages). Mecanismele de baz ale limbajelor de modelare conin: stereotipuri (stereotypes), valori etichetate (tagged values), note (notes), constrngeri (constraints), dependene (dependencies), dihotomii (dichotomies) tip/instaniere (type/instance) i tip /clas (type / class). Tipurile de date (data types) grupeaz toate abstractizrile fundamentale ale limbajului. n tabelul de mai jos sunt enumerate tipurile de date ale UML. Tabelul 7. Tipurile de date n UML Denumire tip dat Boolean Expresie ntreg Multiplicare ir de caractere Descriere Tip de dat care poate lua valorile true sau false ir de caractere a crui sintax se afl n afara domeniului UML Tip primitiv care este un element al unui set infinit de numere reale pozitive sau negative Set nenul de numere ntregi pozitive Tip primitiv care este o secven de caractere referite printr-un nume OBIECT B OBIECT C

Timp Nume Neinterpretat

ir de caractere care reprezint o durat absolut sau relativ de timp ir de caractere care permite specificarea unui element Un element thing a crui semnificaie depinde de domeniu

Pachetele sunt un mecanism de divizare a modelelor i de grupare a elementelor acestora.

Modelarea cazurilor de utilizare n aceast faz de modelare sistemul este vzut ca o cutie neagr, care trebuie s poat realiza anumite sarcini, fr a ne interesa cum le face, cum vor fi implementate, sau cum lucreaz intern. Scopul principal al construirii acestui tip de diagram este: o S decid i s descrie cerinele funcionale ale sistemului, cerine care au fost deduse dup o discuie ntre client i/sau utilizatorii sistemului i viitorii dezvoltatori ai acestuia. S ofere o descriere clar i consistent a ce va trebui s fac sistemul, prin urmare modelul este folosit pentru comunicarea cerinelor tuturor persoanelor implicate n construirea sistemului i s constituie un punct de plecare n realizarea muncii viitoare (alte modele, design arhitectural, implementarea propriu-zis). S constituie o baz pentru realizarea testelor de verificare dac funcionalitatea final a sistemului concord cu cerinele iniiale ale acestuia. S permit o transformare uoar a cerinelor funcionale n viitoare clase i operaii. Un model use case este descris folosind una sau mai multe diagrame use case. Acestea conin urmtoarele elemente de modelare: actori, cazuri de utilizare i diferite relaii ntre aceste elemente: generalizare, asociere, dependen. Actorul poate fi orice sau oricine interacioneaz cu sistemul, adic trimite sau recepioneaz mesaje de la sistem sau schimb informaii cu acesta. Actorul joac un rol n cadrul sistemului, nu este un utilizator individual al acestuia, prin urmare reprezint un

tip (o clas) nu o instan. Studentul Popescu vrea s mprumute o carte de la bibliotec, rolul lui este de abonat al bibliotecii. Orice mesaj trimite actorul sistemului este un caz de utilizare, cteodat numit i stimul. Un actor poate fi: I. Dup utilizarea sistemului Actor primar, dac folosete funcionalitatea de baz a sistemului, de exemplu ntrun sistem de bibliotec, bibliotecarul Actor secundar, dac folosete funcionalitatea secundar, cum ar fi gestionarea unei baze de date, comunicare, backup i alte operaii administrative. II. Dup rolul avut n iniierea cazului de utilizare Actori activi, care iniiaz cazurile de utilizare, Actori pasivi, care particip numai n unul sau mai multe cazuri de utilizare. Operaia de identificare a actorilor revine la a stabili care sunt entitile interesate de utilizarea sistemului sau de interaciunea cu acesta. Pentru aceasta putem s ne folosim de urmtoarele ntrebri: Cine va folosi funcionalitatea principal a sistemului (acetia vor fi actorii principali)? Cine va avea nevoie de sistem n munca de zi cu zi? Cine va administra i ine n stare de funcionare sistemul (acetia vor fi actorii secundari)? Ce uniti (device-uri) hardware vor avea nevoie de sistem? Cu ce alte sisteme va interaciona? Aceste pot fi mprite n sisteme (sisteme de calculatoare, aplicaii) care vor iniia un contact cu sistemul sau sisteme pe care acesta le va contacta. Cine este interesat de rezultatele (valorile) generate de sistem? Modul de reprezentare a actorilor n cadrul diagramelor de modelare UML este prezentat n Figura 1.

Figura 21. Reprezentarea actorilor n UML. Un caz de utilizare reprezint o funcionalitate complet a sistemului, aa cum este ea perceput de un actor. Caracteristicile cazurilor de utilizare sunt: Un caz de utilizare este iniiat ntotdeauna de un actor ; actorul trebuie s cear direct sau indirect sistemului realizarea unui caz de utilizare; Un caz de utilizare furnizeaz o valoare unui actor ; Un caz de utilizare trebuie s fie complet. O greeal frecvent ntlnit este s mprim un caz de utilizare n altele mai mici i s le implementm ca apeluri de funcii n limbajele de programare. Un caz de utilizare nu este complet pn cnd nu este produs valoarea final, chiar dac pentru aceasta sunt necesare cteva dialoguri. Un caz de utilizare este o clas nu o instan a acesteia. Clasa descrie funcionalitatea ca un ntreg, incluznd alternative posibile, erori i excepii care pot s apar pe parcursul execuiei. O instaniere a unui caz de utilizare se numete scenariu i reprezint o utilizare actual a sistemului, de exemplu Studentul Popescu cere bibliotecarului sa-i fac o rezervare pentru cartea de UML care n momentul respective nu este disponibil . Cazurile de utilizare sunt conectate cu actorii prin asocieri, numite i asocieri de comunicare. n mod normal acestea sunt relaii unu-la-unu nedirecionate ceea ce nseamn ca o instan actor comunic cu o instan a cazului de utilizare i c aceast comunicare este n ambele sensuri. Procesul de identificare a cazurilor de utilizare ncepe de la actorii deja identificai. Pentru fiecare actor se vor pune urmtoarele ntrebri: Care sunt funciile pe care actorul le ateapt de la sistem? Ce trebuie s poat face actorul? Are nevoie actorul s citeasc, s creeze, s modifice, s distrug sau s pstreze anumite tipuri de informaii n sistem? Trebuie s tie actorul de apariia unui anumit eveniment n sistem? Ce funcionalitate reprezint aceste evenimente?

Poate actorul s-i simplifice munca de zi cu zi sau s lucreze mai eficient folosind funcii noi ale sistemului? Sau alte ntrebri care nu presupun un actor curent: Ce intrri/ieiri sunt necesare n sistem? De unde vin acestea i unde merg? Care sunt problemele majore n implementarea curent a acestui sistem? Poate fi nlocuit un sistem manual cu unul automat?

Figura 22. Reprezentarea cazurilor de utilizare Relaii ntre cazurile de utilizare Sunt trei tipuri de relaii ce pot fi definite ntre cazurile de utilizare: extindere, utilizare i incluziune. Relaia de extindere este o generalizare a unui use case prin adugarea de aciuni noi. Un extend poate include comportamentul use case-ului extins, n funcie de condiiile de extindere. Un use case extins poate gestiona excepiile specifice cazurilor din use case-ul general care nu sunt uor de tratat n acesta, sau care apar n sistem pe msura dezvoltrii lui. O relaie de extindere ntre cazuri de utilizare este vzut ca o generalizare, se folosete stereotipul <<extend>>. Relaia de utilizare. Cnd mai multe cazuri de utilizare au un comportament comun, acesta poate fi modelat ntr-un singur caz de utilizare i apoi folosit i de altele. Dac use case-ul nu este folosit niciodat direct se numete caz de utilizare abstract. O relaie de utilizare folosete stereotipul <<uses>>. Relaia de incluziune se stabilete atunci cnd un caz de utilizare include comportamentul altui caz de utilizare, folosete stereotipul <<include>>. Dac mai multe cazuri de utilizare gestioneaz funciuni similare sau sunt ntr-un fel legate unul de altul, acestea pot fi grupate n pachete UML. Pachetele nu au un neles semantic.

Descrierea cazurilor de utilizare Descrierea cazurilor de utilizare se face de obicei printr-un text care conine o specificare simpl dar consistent a modului de interaciune ntre actori i cazurile de utilizare ale sistemului. Aceasta va surprinde comportamentul sistemului i va ignora modul n care acesta va fi implementat n sistem. Descrierea va conine: Obiectivele cazurilor de utilizare; Cum este iniiat un caz de utilizare? Ce actori iniiaz execuia i n ce situaii? Care este fluxul de mesaje ntre actori i cazurile de utilizare; Fluxul alternativ n cazurile de utilizare; Un caz de utilizare poate s aib o execuie alternativ n funcie de anumite condiii sau excepii; Cnd un caz de utilizare este considerat terminat, i care va fi valoarea transmis actorului; Un caz de utilizare poate fi descris printr-o diagram de activitate, care va permite vizualizarea secvenelor de activiti, ordinea lor i opional deciziile luate pentru a specifica operaia care urmeaz a fi realizat. Trebuie s reinem un lucru important: modelul cazurilor de utilizare trebuie s fie uor de comunicat utilizatorului/clientului. Dup ce au fost descrise cazurile de utilizare vor trebui specificate relaiile existente ntre acestea. ntrebrile care vor trebui puse n aceast faz sunt: Toi actorii implicai comunic cu cazuri de utilizare? Sunt asemnri ntre actori, poate fi descris o clas actor de baz? Sunt asemnri ntre cazurile de utilizare existente? Exist un flux comun de activiti care s poat fi descris ca o relaie de utilizare a unui caz de utilizare? Exist cazuri de utilizare care s poat fi descrise ca extend-uri? Sunt actori sau cazuri de utilizare fr asocieri de comunicare? Dac exist aa ceva este greit! Sunt cerine funcionale nc necuprinse n cazuri de utilizare? Dac da, vor trebui rezolvate. Cazurile de utilizare sunt folosite i la testarea sistemului; sunt dou tipuri de teste care se pot realiza: verificarea, n care se confirm sau nu dac sistemul a fost dezvoltat corect, n acord cu specificaiile cerute i respectiv validarea, care verific dac sistemul construit este util pentru client i utilizatorul final.

Modelarea structurii statice Cu ajutorul diagramei claselor i cea a obiectelor se modeleaz structura static a sistemului informatic. n figura 23 se pot vedea simbolurile cu care opereaz limbajul de modelare.

Figura 23. Simbolurile Diagrama claselor (class diagrams) prezint ntr-un mode general structura static a sistemului sub forma claselor i relaiilor dintre acestea. Clasa (class) primete un nume care trebuie s permit nelegerea a ceea ce este clas i nu ce face ea, acest nume aezndu-se n primul compartiment. n urmtoarele compartimente se vor trece atributele, respective operaiile clasei. Interfaa (Interface) folosete un tip (type) pentru a descrie funcionalitatea vizibil a unei clase, componente sau pachet. Asocieri (Association) reprezint relaiile structurale dintre clasele de obiecte. Captul end al unei asocieri este numit rol. Rolul descrie modul n care o clas vede cealalt clas. De exemplu ntre clasele Persoan i Organizaie capetele end ale asocierii dintre aceste clase sunt: Pentru asocierea dintre Persoan si Organizaie rolul este angajator, pentru ca persoana vede organizaia ca pe angajatorul sau Pentru asocierea dintre Organizaie i Persoan rolul este salariat.

Fiecrui rol i se asociaz un ordin de multiplicitate care poate fi unul dintre cele descrise n tabelul de mai jos.

Tabelul 8. Ordinul unei asocieri Ordinul de multiplicitate Valoarea asociat 1 0..1 M..N * 0..* 1..* Semnificaia valorii asociate Unu i numai unu Zero sau unu De la M la N (ntreg natural) De la orice la orice (numr ntreg pozitiv) De la zero la orice numr ntreg pozitiv De la unu la orice numr ntreg pozitiv

Unei asocieri i se poate defini o categorie de constrngeri, care sunt reprezentate prin expresii delimitate de acolade. Tipurile de constrngeri sunt: {ordered}, {subset}, {exclusive or}, Clasa de asocieri (AssociationClass ) Dac dorim s adugm unei asocieri un atribut atunci aceasta trebuie reprezentat ca o clas. Asocierile pot fi i n-are, acestea vor fi reprezentate printr-un romb ndreptat ctre diferitele componente ale asocierii. Agregri (Aggregation) reprezint o asociere asimetric, n care unul din capete joac un rol mai important dect cellalt capt, de aceea ea se aplic unui singur capt. Aplicarea unei agregri se poate face ntr-unul dintre cazurile de mai jos: - o clas este o parte a unei alte clase, - valorile atributelor unei clase se propag la valorile atributelor altei clase, - o aciune a unei clase implic o aciune a altei clase, - obiectele unei clase sunt subordonate altei clase. Diagrama obiectelor (object diagrams) utilizate n primul rnd, pentru a prezenta un context nainte sau dup o interaciune. Reprezentarea unui obiect n cazul diagramei obiectelor (object diagrams) se face printr-un dreptunghi care conine numele obiectului i clasa obiectului separate prin semnul :. Numele clasei poate conine o cale complet (clas subclas .a.m.d.), n care elementele cii sunt separate cu semnele ::. Stereotipul unei clase se poate

specifica ntre i se noteaz de obicei deasupra numelui obiectului Dreptunghiurile care simbolizeaz obiecte pot include un al doilea compartiment care va conine valorile atributelor. Obiectele compuse din subobiecte pot fi reprezentate utilizarea unui obiect compus (composite object), ca cel din figura de mai jos.

Figura 24. Reprezentarea unui obiect compus Etichetele folosite n diagrama claselor pot fi, n majoritatea cazurilor, utilizate i n diagrama obiectelor. Dac numele unui obiect nu conine clasa din care face parte este obligatoriu s fie precedat de semnul :.

Diagrame pentru modelarea structurii dinamice Diagrama activitilor (Activity Diagrams) reprezint starea de execuie (structura dinamic) a unui mecanism prin secvene de pai grupate sau ramificate. Activitatea este reprezentat printr-un dreptunghi cu lateralele rotunjit. Fiecare activitate reprezint o stare particular n procesul de execuie a unei metode care o include. Activitile sunt legate prin tranziii automate. Starea este reprezentat printr-un dreptunghi cu colurile rotunjite. Tranziiile automate sunt reprezentate prin sgei. Tranziiile pot fi protejate de condiii booleene reciproc exclusive prin definirea unui stereotip opional pentru afiarea deciziilor (decisions). Reprezentarea grafic a unei decizii este un romb de la care pleac tranziiile corespunztoare opiunii. Vezi figura 25.

Figura 25. Reprezentarea explicit a unei decizii

Diagramele activitilor pot s cuprind i bare de sincronizare a fluxurilor de control. Bara de sincronizare poate deschide sau nchide ramificaiile paralele din cadrul fluxului de execuie sau a unui caz de utilizare. Tranziiile care sunt conectate la o bar de sincronizare sunt declanate simultan. Vezi figura 26.

Figura 26. Deschiderea/nchiderea ramificaiilor paralele pentru sincronizarea fluxurilor Reprezentarea responsabilitilor din cadrul unui mecanism sau unei organizaii se poate face prin mprirea diagramelor de activiti n culoare (swimlanes). Vezi figura 27.

Figura 27. Reprezentarea culoarelor ntr-o diagram a activitilor Pentru reprezentarea explicit a informaiilor de tranziie se definesc stereotipuri de simbolizare a semnalelor transmise/recepionate printr-un pentagon convex, respectiv un pentagon concav legat printr-o sgeat punctat de obiectul care va primi/transmite semnalul. Vezi figura 28.

Figura 28. Simbolizarea semnalelor Diagrama tranziiilor strii (Statechart diagrams)- folosete descrierea formal a comportamentului obiectelor prin intermediul unei maini de stri (state machine). n cazul n care obiectele au aceeai stare ele nu dein o main a strilor. Modurile de colaborare dintre obiecte se descriu prin intermediul scenariilor. Mainile de stare i scenariile sunt complementare. Strile sunt reprezentate n dreptunghiuri cu colurile rotunjite. O stare iniial este marcat cu ajutorul unui punct mare negru, iar ce final cu un punct mare negru nconjurat de un cerc. Strile sunt legate unidirecional de tranziii, tranziiile sunt declanate de evenimente, n urma unei tranziii obiectul trece de la o stare la alta. Specificarea complet a unui eveniment se face prin: Numele evenimentului, Lista parametrilor, Obiectul expeditor, Obiectul int, Descrierea i semnificaia evenimentului.

Diagramele domeniului i proceselor Diagrama colaborrilor (Collaboration Diagrams) ilustreaz interaciunile dintre obiecte utiliznd structura static definit anterior. Contextul unei interaciuni cuprinde argumentele, variabilele locale i legturile (links) dintre obiecte. Interaciunea este implementat de un grup de obiecte care colaboreaz prin schimb de mesaje, care sunt reprezentate de a lungul legturii, care conecteaz obiectele. Direcia mesajului este indicat printr-o sgeat ndreptat ctre destinatarul mesajului. ntr-o diagram a colaborrilor mesajele sunt numerotate pentru a indica ordinea de trimitere. Constrngerile la care pot fi supuse interaciunile sunt: {new}, {deleted}, {transient}, adic nou, ters sau temporar. Diagrama colaborrilor poate include i actori. O interaciune exprim comportamentul rezultat din colaborarea unui grup de instaniei. O interaciune poate fi reprezentat lund n considerare caracteristica timp (prin diagrame ale secvenelor) sau caracteristica spaiu (prin diagrame ale colaborrilor). Interaciunile conin urmtoarele elemente; o o mesaje. o o Instane (Instances) sunt exemple concrete ale unui tip. Legturi (Links) conecteaz instanieri i reprezint transmiterea de

Mesaje (Messages) declaneaz operaii Roluri (Roles) evideniaz rolurile asignate la capetele unei legturi.

Diagrama secvenelor (Sequence Diagrams) prezint interaciunile dintre obiecte din punct de vedere temporal. Exist dou categorii principale de transmitere a mesajelor: - transmiteri sincrone - transmiteri asincrone Structurile de control pot fi centralizate sau descentralizate, pot simula structuri repetitive, condiionale sau recursive.

Diagramele de implementare Diagrama componentelor (Component Diagrams) prezint componentele software i relaiile acestora n cadrul mediului de implementare.

Diagrama distribuirilor (Deployment Diagrams) prezint schema fizic a diferitelor componente hardware care compun un sistem informatic. Fiecare resurs hardware este numit nod i este reprezentat printr-un cub.

Se recomand ca locul de desfurare a acestei activiti de predare s fie un laborator/cabinet echipat calculatoare pentru fiecare elev.

Probe practice care atest capacitatea de a utiliza componentele limbajului de modelare n modelarea sistemului informatic, aa cum este specificat n criteriul de performan 3 (d).

Tema 10. Aplicaii practice


Fia suport 10.1. Elaborarea modelului logic pentru un sistem informatic dat.

Sugerm profesorilor care predau acest modul s pregteasc cursanilor proiecte bine structurate, cu teme clare prin care acetia s fie obligai s obin modelul logic/fizic al unui sistem informatic. Limbajul folosit poate fi StartUML care este un software open source. Pe parcursul orelor de instruire practic alocate acestei teme profesorul poate oferi sprijin i ndrumare, dar poate juca i rolul beneficiarului n faa cruia echipa care se ocup de elaborarea sistemului informatic trebuie s respecte termene de livrare i s ofere soluiile care s satisfac cerinele utilizatorului. n elaborarea temelor va trebui s se in cont de necesarul de software i hardware care va fi necesar pentru implementarea acestui model, astfel nct acest lucru s fie posibil.

Sugerm evaluarea conform criteriilor de performan din SPP,.

Unitatea de nvmnt __________________

IV. Fia de observaie


Clasa ________________Profesor______________________________________________ __Modulul_________________________ Nr. Nume i crt. prenume Popescu Ion 14 Competena 1 1a
7

Competena 2 1d 2a 2b 2c

Competena 3 Observaii 3a 3b 3c 3d

1b 1c

/20X

Nr.
14

Nume

i Competena 1

Competena

Competena 3

Observaii

Exemplu de folosire a fiei. La fiecare competen se poate da not sau calificativ. Fiecare elev trebuie s dovedeasc dobndirea acestor competene.

crt.

prenume

2 1a 1b 1c 1d 2a 2b 2c 3a 3b 3c 3d

V. Bibliografie
1. Bdu M. [1999]. Informatica pentru manageri. Bucureti. Editura Teora. 2. Bocu D., Bocu R. [2006]. Modelare obiect orientat cu UML . Cluj-Napoca. Editura Albastr. 3. Bia V., Antonescu C., Iosep M, Trandafir I. [1977]. Sisteme informatice. Bucureti. Editura Didactic i Pedagogic. 4. Drgan C.M. [1975]. Sistemul informaional n domeniul costurilor de producie . Cluj. Editura Dacia. 5. Filip F.G. [2004]. Sisteme suport pentru decizii. Bucureti. Editura Tehnic. 6. Hrin GR., Anghel LE., David A. [2007]. UML pe nelesul tuturor. Bucureti. Editura Fin Watch. 7. Militaru, G. [2004]. Sisteme informatice pentru management. Bucureti. Editura All. 8. Miloescu M. [2006]. Tehnologia informaiei i a comunicaiilor manual pentru clasa a XII-a ruta direct i a XIII-a ruta progresiv. Bucureti. Editura Didactic i Pedagogic. 9. Radu I., [1996]. Informatic managerial. Bucureti. Editura Economic. ***, http://en.wikipedia.org/wiki/Computer-aided_software_engineering ***, http://www.webopedia.com/TERM/C/Computer_Aided_Systems_Engineering.htm ***, http://www.npd-solutions.com/case.html ***, http://www.sei.cmu.edu/legacy/case/case_whatis.html ***, http://www.selectbs.com/adt/analysis-and-design/computer-aided-software-engineering-case-tool