Dezvoltarea sistemelor informatice

Ce este un model? Simplificri sau abstractizri ale unor elemente reale

sau care se proiecteaz.

Evideniaz numai acele elemente care sunt importante pentru analist.

Sunt specificate folosind notaii grafice sau textuale precise, cu ajutorul unui anumit limbaj de simboluri.

O colecie de imagini i text care are o anumit semnificaie i intenioneaz s reprezinte ceva.

Metodologii de dezvoltare software

Instrumente de tip CASE

CASE = Computer Aided Software Engineering

Necesitate: lucrul cu modele vizuale poate fi o activitate dificil i

consumatoare de timp nevoia unui suport informatic atunci cnd vrem s

meninem integritatea modelelor posibilitatea de a genera cod

Visual Paradigm 11.2 http://www.visual-paradigm.com/download/archive/

Ce este UML?

UML = Unified Modeling Language

Limbaj de notaii pentru specificarea, construirea, vizualizarea i documentarea sistemelor software.

Combin cele mai bune practici n domeniul construirii diagramelor din ultimii 50 de ani.

Standardizeaz notaiile, dar nu stabilete modul n care acestea s fie folosite.

Nu este o metodologie, poate fi folosit ca vocabular pentru metodologii.

Ofer flexibilitate dezvoltatorilor, asigurnd n acelai timp consisten.

Este un standard dezvoltat i ntreinut de Object Management Group.

Elemente de baz ale UML2. Tipuri de diagrame

Perspective asupra sistemului

Diagrama de pachete structurare/modularizare

Diagrama de profile - extinderea limbajului

Static

Diagrame de:

Clase Obiecte Structur compus Componente Desfurare

FuncionalDiagrame de:

Cazuri de utilizare Activiti Interaciuni de ansamblu

Dinamic

Diagrame de: Stare Secven Comunicare Timp

Pasi pentru dezvoltarea unui SI

1. Specificarea cerintelor

2. Analiza

3. Proiectarea

4. Implementarea

5. Desfasurarea

6. Generarea de cod

1. Specificarea cerintelor Modelul cazurilor de utilizare

Reflecta o viziune din exterior asupra sistemului, dpdv al utilizatorului

Ilustreaza functionalitatile pe care le va realiza sistemul

Scop:

Delimitarea ariei de cuprindere a SI

Baza de discutii cu beneficiarul

Specificarea completa si detaliata a cerintelor

Elemente componente:

Cazul de utilizare

Actorul

Relatiile

Caz de utilizare Specific un set de aciuni executate de ctre un

sistem sau un subiect i care conduc la un anumit rezultat.

Rezultat, n mod normal, este important pentru un actor sau un beneficiar.

Trebuie verificata aparitia suprapunerilor sau duplicatelor.

Trebuie verificata completitudinea modelului.

Actori Un actor interacioneaz cu sistemul n contextul unui caz

de utilizare.

Actorii reprezint roluri care pot include factori umani, hardware extern sau alte sisteme.

Rspunde la ntrebri de genul: CINE solicit informaii din sistem

CINE modific informaiile din sistem

CINE interacioneaz cu sistemul

Se reprezint folosind simbolul specific al unui omule.

Diagrama cazurilor de utilizare Descrie relaiile dintre un set de cazuri de utilizare i

actorii care particip la realizarea acestor CU.

Diagramele de CU nu descriu comportamente sau fluxuri.

Poate delimita graniele sistemului analizat prin includerea CU n interiorul unui dreptunghi.

Relaii ntre actori

Sunt de tipul generalizare/specializare, ntre un actor abstract i unul sau mai muli actori concrei

Relaii ntre actori i cazuri de utilizare -1

Asocierile simple sunt folosite pentru a conecta un actor cu un caz de utilizare.

Aceasta reprezint o cale de comunicare ntre cei doi.

Comunicarea poate fi i unidirecional.

Relaii ntre actori i cazuri de utilizare -2 La acest nivel sunt permise multiplicitile.

multiplicitatea mai mare dect unu la captul: corespunztor CU actorul este implicat n mai multe cazuri de utilizare de

acel tip i poate iniia cazuri de utilizare: n paralel (concurent), la diferite momente de timp sau mutual exclusiv n timp.

corespunztor actorului mai multe instane ale actorului sunt implicate n

iniierea cazului de utilizare putnd realiza aciuni simultane sau succesive.

UML nu are notaii standard pentru situaiile de mai sus.

Relaii ntre cazuri de utilizare -1

ntre dou cazuri de utilizare care se refer la acelai subiect (sistem) nu pot exista relaii simple. Fiecare descrie un mod de utilizare complet al sistemului.

1. Generealizare Se folosete cnd exist dou sau mai multe CU care au n comun

comportament, structur i scop. Comportamentul CU printe poate fi suprascris. Se specific numai diferenele dintre cele dou n CU specializat.

Relaii ntre cazuri de utilizare -22. Includere Are ca scop integrarea unui CU n alt CU, primul devenind astfel o parte logic din acel CU. CU

care l include pe un altul nu este complet.

Se folosete atunci cnd: exist pri de comportament comune n mai multe CU. pentru a simplifica CU mari.

Este echivalent cu apelul unei subrutine n programare.

Denot un comportament obligatoriu, nu opional.

Nu se motenesc proprieti de la un CU la altul.

Se evit redundana prilor cu comportament identic.

Relaii ntre cazuri de utilizare -33. Extindere

Este folosit atunci cnd un CU are loc doar n anumite condiii sau opional.

CU extins este complet i independent de cel care l extinde.

Extinderea are loc n unul sau mai multe puncte de extindere, definite n cazul de utilizare extins.

Se pot asocia note sau constrngeri pe aceast relaie pentru a ilustra condiiile n care comportamentul extins trebuie executat.

Descrierea textual a unui CU

Element al cazului de utilizare

Descriere

Cod Un identificator unic asociat cazului de utilizareStare Stadiul de finalizare n care se gsete, de exemplu: schi,

finalizat sau aprobat Scop Sistemul (parte a sistemului) sau aplicaia creia i aparineNume Numele cazului de utilizare, ct mai scurt i reprezentativ Actor principal Beneficiarul care iniiaz cazul de utilizare i care urmrete un

anumit scopDescriere Prezentare scurt, in text liber, a cazului de utilizarePrecondiii Ce condiii trebuie satisfcute pentru ca scenariul s poat

ncepePostcondiii Ce condiii trebuie ndeplinite pentru a garanta un final reuit al

scenariuluiDeclanator Un eveniment sau o succesiune de evenimente care iniiaz

cazul de utilizareFlux de baz Fluxul de baz descrie niruirea evenimentelor atunci cnd

totul se petrece conform unui scenariu prestabilit; nu exist excepii sau erori

Fluxuri alternative Cele mai semnificative alternative i excepii ale scenariului de baz

Relaii Ce relaii are cu alte cazuri de utilizare (de tipul includes sau extends)

Frecvena utilizrii Ct de des se estimeaz c va fi folosit aceast funcionalitate a sistemului

Reguli ale afaceri Ce reguli guverneaz cazul de utilizare; ce prerogative trebuie s aib actorii

Lucru la seminar

S se ntocmeasc diagrama de cazuri de utilizare i descrierea textual a unui caz de utilizare pentru scenariul de mai jos.

Scopul proiectului este realizarea aplicaiei informatice pentru gestiunea activitii unei unitihoteliere. n vederea cazrii, un client poate solicita rezervarea uneia sau mai multor camereprin e-mail sau telefonic. Pentru aceasta furnizeaz recepionerului informaii privind perioadade cazare i tipurile de camere solicitate. Clienii vor beneficia de reduceri dac rezerv celpuin 3 camere sau dac perioada de cazare depete 5 zile. Recepionerul verificdisponibilitatea camerelor i l ntiineaz pe client de acest lucru precum i de costul estimatal cazrii. Dac nu exist camere disponibile conform solicitrii, recepionerul poate ofericlientului alternative. De asemenea, clientul poate solicita un discount (suplimentar sau nu),iar recepionerul va decide fezabilitatea discountului, fiind asistat obligatoriu de managerulhotelului. n situaia n care clientul este de acord cu preul propus, se va proceda la realizarearezervrii. Pentru clienii noi, recepionerul solicit datele de identificare, pe care le introducen aplicaie.

Odat ajuns la hotel, i dac a fcut n prealabil o rezervare, clientul va furniza datele deidentificare ale sale i/sau ale rezervrii i se face cazarea. Dac nu exist o rezervare, se vaverifica disponibilitatea camerelor pentru perioada cerut. Atunci cnd se gsete o astfel decamer, se face cazarea. La finalul sejurului, recepionerul ntocmete o list cu toate serviciilesolicitate de client i preul acestora. Lista trebuie validat de client, dup care se ntocmetefactura final. Factura poate fi pltit parial sau integral, prin transfer bancar, numerar saufolosind un card bancar. Totodat, nainte de a prsi hotelul, clientul este rugat s completezeun formular prin care s evalueze serviciile oferite de unitatea hotelier.

Diagrama claselor UML

Definirea unei clase Ansamblu de obiecte care au aceleai caracteristici i contrngeri.

Caracteristicile unei clase sunt atributele i operaiile.

Clasele abstracte nu pot fi instaniate. Rolul lor este de a permite altor clase s le moteneasc, n vederea reutilizrii caracteristicilor.

O interfa descrie un set de caracteristici i obligaii publice. Specific, de fapt, un contract. Orice instan care implementeaz interfaa trebuie s ofere serviciile furnizate prin contract.

Exemple de clase stereotipe uzuale

entitate () o clas pasiv, care nu iniiaz interaciuni;

control () iniiaz interaciuni, conine o component tranzacional i este separator ntre entiti i limite;

limit () este aflat la periferia sistemului, dar n interiorul su. Reprezint limita de legtur cu actorul sau cu alte sisteme informatice;

enumerare () - este folosit pentru definirea tipurilor de date ale cror valori sunt enumerate.

primitiv () - o form de clas care reprezint tipuri de date predefinite, cum ar fi tipul Boolean.

Atribute -1

Fiecare atribut este descris cel puin prin numele su.

Se pot aduga i informaii adiionale, iar forma general a

unui atribut este:

[vizibilitate][/]nume[:tip][multiplicitate][=valoare implicit] [{proprietate}]

Vizibilitatea poate fi:

+ public: poate fi vzut i folosit de oricine

- private: numai clasa nsi poate avea acces

# protected: au acces clasa i subclasele acesteia

~ package: numai clasele din acelai pachet pot avea acces

/ simbolizeaz un atribut derivat

Atribute -2

UML permite specificare multiplicitilor pentru atribute, atunci cnd dorim s

definim mai mult de o valoare pentru un atribut. Au urmtoarea semnificaie:

Multiplicitate Sens

1 Exact 1 (implicit)

2 Exact 2

1..4 De la 1 la 4 (inclusiv)

3, 5 3 sau 5

1..* Cel puin unul sau mai muli

* Nelimitat (inclusive 0)

0..1 0 sau 1

Proprietate indic o proprietate suplimentar care se aplic atributului:

{readonly}: atributul poate fi citit, dar nu modificat

{ordered}, {unordered}: o mulime ordonat sau neordonat

{unique}, {nonunique}: mulimea poate conine sau nu elemente identice

Operaii

Forma general a unei operaii este: [vizibilitate] nume ([direcie] lista parametri) [:tip returnat] [{proprietate}]

Vizibilitatea aceeai ca i la clase

Direcie - 'in' | 'out' | 'inout' | 'return'

Tip returnat dac operaia returneaz ceva, adic este o funcie

Un exemplu de proprietate a unei operaii: {query} - nu are efecte secundare, nu schimb starea unui obiect sau a altor obiecte, exemplu operaiile de tip get.

Exemple de atribute:

- varsta: Integer {varsta>18}

# nume:String[1..2]=Ioana

~ Id:String {unique}

/ sumaTotala:Real=0

Exemple de operaii:

+ setVarsta (out varsta: Integer)

+ getVarsta(in Id:String): Integer {query}

- schimbaNume(inout nume:String)

Constrngeri

O constrngere este o expresie care restricioneaz un anumit element al diagramei de clase.

Aceasta poate fi o expresie formal (scris n Object Constraint Language - OCL) sau o formulare semi-formal sau informal.

Acestea sunt reprezentate ntre acolade.

Pot fi scrise imediat dup definirea elementului sau ca un comentariu.

O constrngere poate avea i un nume, astfel:

{nume : expresie boolean }

Exemple de constrngeri OCL:context Organizatie

inv: self. departamenteisUnique (nume)inv: departamante.angajatiisUnique (cod)

Relaii ntre clase -1

1. Relaia de asociere implic stabilirea unei relaii ntre clase.

Este caracterizat prin:

denumire (opional)

multipliciti se trec la cele 2 capete ale asocierii;

roluri ale asocierii: se trec la fiecare capt al asocierii i conin o

descriere scurt i reprezentativ de (1 2 substantive)

direcie de navigare

tipuri de asocieri:

unare

binare

ternare

Relaii ntre clase -2Tipuri de asocieri:

Unare: conecteaz o clas cu sine nsi.

Binare: se realizeaz ntre dou clase.

Ternare: sunt transformate, de obicei, n asocieri binare.

Relaii ntre clase -3

Asocierea modelat ca o clas permite relaiei de asociere s aib artibute i operaii.

2. Relaia de agregare este o form de asociere binar

reprezentnd o relaie de tip parte/ntreg.

Poate fi de doua tipuri:

Agregare partajat (agregare)

Agregare compus (compunere)

Relaii ntre clase -4

Agregarea partajat este o form slab de agregare n care instanele prilor sunt independente de ntreg, astfel:

Aceleai pri partajate pot fi incluse n mai multe clase ntreg.

Dac clasa ntreg se terge, clasele parte vor exista n continuare.

Se reprezint sub forma unui romb gol plasat la captul clasei ntreg.

Relaii ntre clase -5

Agregarea compus este o form puternic de agregare n care instanele prilor sunt independente de ntreg, astfel:

Dac clasa ntreg se terge, clasele parte vor vor fi terse i ele.

Se reprezint sub forma unui romb plin plasat la captul clasei ntreg.

Atunci cnd se folosete pentru modelarea obiectelor dintr-un anumit domeniu, tergerea poate fi interpretat la figurativ, ca terminare, i nu ca o distrugere fizic.

Relaii ntre clase -6

Asociere

Obiectele tiu unele de existaa celorlalte i pot lucra mpreun.

Agregare

1. Protejeaz integritatea configuraiei.2. Funcioneaz ca un tot unitar.3. Control prin intermediul unui singur obiect.

Compunere

Fiecare parte poate fi membr a unui singur obiect agregat.

Relaii ntre asociere, agregare i compunere

Relaii ntre clase -73. Relaia de generalizare este folosit pentru a indica motenirea

dintre o clas general (superclas) i o clas specific (subclas). Se mai numete informal i relaie de genul este un tip de. Se reprezint sub forma unui tringhi gol plasat la captul

superclasei. Subclasele motenesc caracteristicile i constrngerile superclasei. Este permis motenirea multipl.

Relaii ntre clase -8

4. Relaia de dependen este folosit pentru a arta o gam larg de dependene ntre elementele unui model.

n atapa de analiz, tipul de dependen poate s nu fie specificat.

n proiectare, dependenele vor fi personalizate cu stereotipuri sau vor

fi nlocuite cu conectori specifici tehnologiei folosite.

Se reprezint sub forma unei linii punctate de la clasa dependent

client, pan la clasa furnizor, cu o sgeat la captul clasei

furnizor.

n diagramele de clase, cele mai importante dependene sunt relaiile

de utilizare i de abstractizare.

Lucru la seminar

S se ntocmeasc diagrama de clase pentru scenariul de mai jos.

Scopul proiectului este realizarea aplicaiei informatice pentru gestiunea activitii unei unitihoteliere. n vederea cazrii, un client poate solicita rezervarea uneia sau mai multor camereprin e-mail sau telefonic. Pentru aceasta furnizeaz recepionerului informaii privind perioadade cazare i tipurile de camere solicitate. Clienii vor beneficia de reduceri dac rezerv celpuin 3 camere sau dac perioada de cazare depete 5 zile. Recepionerul verificdisponibilitatea camerelor i l ntiineaz pe client de acest lucru precum i de costul estimatal cazrii. Dac nu exist camere disponibile conform solicitrii, recepionerul poate ofericlientului alternative. De asemenea, clientul poate solicita un discount (suplimentar sau nu),iar recepionerul va decide fezabilitatea discountului, fiind asistat obligatoriu de managerulhotelului. n situaia n care clientul este de acord cu preul propus, se va proceda la realizarearezervrii. Pentru clienii noi, recepionerul solicit datele de identificare, pe care le introducen aplicaie.

Odat ajuns la hotel, i dac a fcut n prealabil o rezervare, clientul va furniza datele deidentificare ale sale i/sau ale rezervrii i se face cazarea. Dac nu exist o rezervare, se vaverifica disponibilitatea camerelor pentru perioada cerut. Atunci cnd se gsete o astfel decamer, se face cazarea. La finalul sejurului, recepionerul ntocmete o list cu toate serviciilesolicitate de client i preul acestora. Lista trebuie validat de client, dup care se ntocmetefactura final. Factura poate fi pltit parial sau integral, prin transfer bancar, numerar saufolosind un card bancar. Totodat, nainte de a prsi hotelul, clientul este rugat s completezeun formular prin care s evalueze serviciile oferite de unitatea hotelier.