Sunteți pe pagina 1din 119

1

Arhitectura Sistemelor Informaionale face parte din una din cele 4 module din cadrul cursului de iniiere pentru managerii departamentelor TI. Acest modul este un modul fr de care un manager IT nu-i poate realiza pe deplin potenialul. tim cu toii c n actual exist diverse sisteme informatice, diferite modaliti de a le implementa, diferite tehnologii care se folosesc la implementarea lor, toate cu scopul rezolvrii anumitor probleme din lumea real. n cadrul acestui modul noi vom ncerca s vedem cum se mapeaz problemele pe care ncercm s le soluionm la soluiile tehnice. Cum arat o soluie tehnic i care sunt factorii care influeneaz construirea acestor soluii.

Referine:
1. PROGRAMUL STRATEGIC DE MODERNIZARE TEHNOLOGIC A GUVERNRII, Aprobat prin Hotrrea de Guvern Nr. 710 din 20 septembrie, 2011. 2. Daniel Minoli. Enterprise Architecure A to Z. Frameworks, Business Modeling, SOA, and Infrastructure Technology. CRC Press, 2008.

3. Georgescu Cristian. - "Analiza i proiectarea sistemelor informatice", Editura Radical, Galai, 1999.

4. The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson, Grady Booch, 1999
5. Todd Biske. SOA Governance. The key to successful SOA adoption in your organization, PACKT Publishing, 2008.

tim cu toii c n actual cea mai dinamic evoluie o nregistreaz Tehnologia Informaiei. ntreprinderile sunt constrnse s reacioneze la noile cerine ale

societii n timp real, n care scop trebuie s-i amplifice sau s-i restructureze procesele de business, s-i administreze activitile cu eficien sporit. n actual se utilizeaz din ce n ce mai mult tranzacii electronice pentru efectuarea plilor, ncasrilor, creditrilor i altor operaii. A crescut gradul de prelucrare a datelor, s-au automatizat procesele decizionale, se adopt soluii integrate pe scar larg.
Practic nu exist domeniu n economie (sfera social, energetic, educaie, aprare etc.) n care s nu existe cel puin un sistem informaional, care s controleze diferite elemente ale activitii acelor domenii. Sistemele Informaionale se compun din mai multe pri i vom vedea n continuare care sunt acestea. Dezvoltarea rapid al domeniului TIC, a dus i la apariia unor noi noiuni care de multe ori sunt ambiguie. Vom ncerca s definim clar ce vom nelege printr-un produs program, un sistem informatic i un sistem informaional. Cum se dezvolt un sistem informaional.

Sistemul informaional este ansamblul de elemente implicate in procesul de colectare, transmisie, prelucrare, etc. de informaii. Rolul sistemului informaional este de a transmite informaia intre diferite elemente. De exemplu, in cadrul unei uniti economice, rolul sistemului informaional este de a asigura persoanele din conducere cu informaii necesare pentru luarea diferitelor decizii economice sau de alta natura.

Sistemulul informaional - este proiectat ntotdeauna pe sistemul economic pe care il deservete. Sistemul informaional are n componena sa resurse materiale, umane i informaionale, sisteme informatice, care sunt destinate pentru rezolvarea sarcinilor pe care acesta le are de executat la un anumit moment, sau ntr-o perioad de timp.

Resursele materiale

ale sistemului informaional cuprind: cldirile i construciile destinate n acest scop, mijloace de calcul, inventarul de birou, rechizitele, documentele primare i centralizatoare necesare consemnrii datelor i informaiilor, precum i alte elemente materiale.

Resursele umane cuprind personalul tehnic, economic i de alt specialitate care


desfaoar activitate informaional n diverse compartimente ale organizaiei respective.

Resursele informaionale se compun din ansamblul datelor i informaiilor

nscrise n documentele primare i centralizatoare sau pe alte suporturi de date.


Sistem informatic o colecie de componente inter-conectate care funcioneaz mpreun pentru a atinge un anumit obiectiv comun. Un Sistem Informatic are exclusiv componente tehnice (software i hardware)

n afara elementelor menionate anterior SI mai conine i cadrul organizatoric, metodologic i legal pe baza cruia se desfoar activitile din sistemul informaional. ntre toate elementele date exist o strns interdependen care permite realizarea obiectivelor sistemului informaional.

Ciclu de via al unui SI reprezint intervalul de timp de la momentul deciziei de realizare i pna la retragerea sau nlocuirea total a acestuia cu un nou produs program. Din punct de vedere al utilizatorilor cele mai importante pri ale ciclului de via sunt utilizarea curent (operaionalitate) i mentenana produsului program. Procesul de dezvoltare al unui SI un set de reguli i activiti ce se aplic la specificarea, dezvoltarea, validarea i mentenana unui sistem informatic. Specificarea ce trebuie sistemul s fac i care sunt constrngerile sistemului Dezvoltarea producerea sistemului informatic (analiza cerinelor, arhitectura, proiectarea, testarea etc) Validarea verificarea daca sistemul dezvoltat corespunde ateptrilor clientului Mentenana meninerea i schimbarea sistemului n corespundere cu cerinele pieii Model de dezvoltare al unui SI o formalizare a procesului de dezvoltare al unui SI.

Exemple de modele
Cascad activiti desfurate n secven;

Dezvoltare iterativ activiti desfurate n iteraii;


Model spiral activiti desfurate dup principiul de sus n jos i de jos n sus

Costul unui SI totalitata costurilor pentur fiecare activitate din procesul de dezvoltare al SI. Aproximativ 60% din costuri sunt costuri de dezvoltare, 40% sunt costurile de testare. Pentru produse program particularizate, costurile de evoluie depesc adesea costurile de dezvoltare. Costurile variaz n funcie de tipul de sistem n curs de elaborare i cerinele nefuncionale ale sistemului, cum ar fi performana, securitatea sau fiabilitatea sistemului. Distribuia costurilor depinde de modelul de dezvoltare care este utilizat. Un SI trebuie s corespund unui set predefinit de atribute de calitate: fiabilitate, disponibilitate, mentenabilitate, uzabilitate, instalabilitate, funcionalitate, performan, suportabilitate, scalabilitate i alte ate SI bun: Este greu de spus ce este un sistem bun. Am putea spune ca un Sistem Informaional este bun daca el satisface toate prile interesate n SI dat.

n dezvoltarea unui SI exist ntodeauna mai multe persoane interesate (stakeholders). Fiecare persoana privete SI din punctul su de vedere. De exemplu Utilizatorul final vede ntr-un sistem informatic un instrument care s-l ajute n lucru de zi cu zi. Clientul sau beneficiarul vede ntr-un SI un instrument n care el este dispus s investeasc n scopul optimizrii lucrului i majorrii profitului. Un Dezvoltator vede un SI ca un set de cerine pe care el trebuie s le implementeze.

tim cu toii c exist strategia naional de dezvoltare a RM n care fiecare sector din economia naional are partea sa de strategie. Astfel, fiecare instituie/organizaie are o strategie care are mai multe obiective de business. Pentru a implementa aceste obiective organizaia are mai multe departamente: Resurse umane, Procurri, Contabilitate etc. Este bine tiut faptul c n ziua de azi calculatorul este utilizat practic de fiecare om i n cadrul fiecrui departament exist calculatoare care ntr-o msur oarecare contribuie la implementarea strategiei. Astfel, TIC (Tehnologii Informaionale i Comunicaii) este utilizat n cadrul fiecrui departament. TIC const din dou direcii: Tehnologii Informaionale (produse program i partea hardware) i Comunicaie (reele de comunicare, benzi de comunicare, telefonie, radio, televiziune etc.) TIC-ul formeaz baza unui Sistem informaional. Urmrind ordinea ideilor expuse putem spune c n actual Sistemele Informaionale reprezint partea principal n implementarea obiectivelor de business dintr-o strategie.

10

Exist trei lucruri de care depinde succesul dezvoltrii unui SI: Proces: un set de activitati si reguli destinate transformarii necesitatilor unui utilizator in produs softwar. Exemple de procese: ICONIX Process, RUP, Agile, MSF; Notatie: simboluri bazate pe un alfabet si un set de reguli cu ajutorul carora se pot formaliza etapele procesului. Exemple de notatii: UML, limbaje de programare Instrument: instrumente aplicate pentru a asista si automatiza anumite etape ale procesului de dezvoltare a unui produs soft numite si CASE Tools (Computer-aided software engineering) Exemple de instrumente: Rational Rose, Enterprise architect, Visio, VS Studio Team System

11

Exist mai muli factori ce influeneaz luarea deciziilor privind modul de dezvoltare al unui SI. Principalii factori sunt Costul de dezvoltare al SI, Timpul acordat i calitate ateptat. ntre aceti trei factori ntotdeauna exist o interdependen. Astfel nu putem avea un SI calitativ dezvoltat ntr-un timp scurt, calitativ i costuri reduse. Diminuarea oricrui factor va influena cu siguran ceilali factori.

12

Sistemele informatice sunt foarte diverse. Exist mai muli parametri care ii difereniaz cum ar fi: funcionalitile, etapele de implementare, persoanele implicate n implementare etc. Toi aceti factori influeneaz calitatea sistemului informaional. Dar, indiferent de aceti factori un Sistem Ce ar fi dac am construi un SI fr arhitectur?

13

Dac o organizaie vrea s fac schimbri fundamentale ale sistemelor informaionale, aceasta trebuie s schimbe n primul rnd arhitectura. O arhitectur corect poate adapta uor orice schimbri de obiective de business, indiferent dac asta nseamn mai muli utilizatori sau noi reguli de business.

14

Pentru cele mai multe sisteme informatice, arhitectura pe niveluri (N-tier Architecture) este un exemplu de arhitectura care permite cu uurina adaptare sistemului la schimbri.

15

Dezvoltarea unui SI este un proces iterativ i care const n 5 activiti de baz: Analiza cerinelor, Proiectarea sau elaborarea arhitecturii, Implementarea, Testarea i Evaluarea Fiecare dintre aceste etape i are rolul su n dezvoltare SI. Pe baza acestor activiti au fost elaborate diferite modelele de dezvoltare al SI

16

Una din activitile importante n dezvoltarea unui Sistem Informaional este definirea arhitecturii SI. Cum credei de ce este important aceasta activitate. O cuc poate fi construit de ctre o singur persoan. Nu necesit modelare, folosete un proces simplu i unelte simple. O cas sau o cladire poate fi construit cel mai eficient i n timp util de ctre o echip. Necesit modelare, proces bine definit i unelte puternice. Dac s facem o paralel cu Sistemele Informaionale putem spune c pentru a defini un sistem informaional simplu (sistem ce asigur gestiunea datelor dintr-un singur departament) s-ar putea sa nu necesite definirea unei arhitecturi, pe cnd un sistem informaional

17

Motenitoarea averii creatorului putii Winchester, Sarah Winchester a construit o reedin cu 160 de camere i 40 de dormitoare timp de 38 de ani, obsesie care a durat pan la moartea sa, la vrsta de 82 de ani. Lung i lat Casa Winchester a misterelor din San Jose are scri care nu duc nicieri, ui care se deschid nspre perei albi i alte anexe nesfrite toate construite n urma hotrrii lui Winchester de a extinde cldirea indiferent de costuri. Rezultatul este o privire aruncata n interiorul mintii unei femei obsedate, care dispunea de orict de muli bani pentru a-i aduce la ndeplinire obsesia. Casa a fost construit fr vre-un arhitect sau vre-o schi de arhitectur. Costul estimat al cldirii este de cca 5.5 milioane dolari SUA, achitai n perioada construirii casei date (pn n 1922), echivalentul a cca 70 mil n actual

18

Arhitectura de scar larg (sau a ntreprinderii) este rezultatul unui proces de modelare i de documentare a tuturor aspectelor legate de organizaie pentru a se garanta c serviciile, procesele, aplicaiile, informaiile, datele, tehnologiile, locaiile, personalul, evenimentele i termenii sunt toate aliniate cu obiectivele organizaiei. Scopul principal al EA este acela de a crea o hart a activelor TI i a proceselor de activiti, baza pentru definirea unui set de principii de guvernare. Aceste elemente la rndul lor determin strategia de activitate i modul n care aceasta poate fi exprimat prin intermediul TI.

19

EA const din patru niveluri: Business (Afaceri), Organization (Organizaional), Information (Informaional) i Technical (Tehnologic) Fiecare nivel const dintr-un set de principii ce in nemijlocit de nivelul dat. Structura stratificat arat c nivele sunt organizate n dependen de strategia adoptat la nivel de ntreprindere: se stabilesc principiile de afaceri, care la rndul lor, au consecine asupra principiilor de organizare, informaionale i nu n ultimul rnd tehnologice

Arhitectura de business definete principalele procese ale organizaiei; Arhitectura organizaional definete principiile de organizare a activitilor din cadrul proceselor de business; Arhitectura informaional definete aplicaiile, datele i modul de integrare a acestora; Arhitectura tehnologic definete tehnologiile care susin arhitectura informaional prin platforme de operare, reele, diverse aplicaii pentru colaborare, reprezentarea i manipularea datelor, integrare, securitate i managementul sistemelor.

20

Odat cu dezvoltarea sectorului TIC la nivel internaional au aprut mai multe modaliti de a reprezenta/formaliza viziunile unui sistem. Astfel cele mai raspndite sunt RUP: 4+1 viziuni, RM-ODP 5 viziuni, DODAF 3 viziuni, Zachman 36 viziuni, Microsoft 5 viziuni.

21

Rational propunere modelarea unui Sistem Informaional prin 4+1 perspective (Views): Logical View (Perspectiva Logic) Viziunea logic descrie sistemul din punct de vedere structural i arhitectural. Aici sunt descrise clasele i legtura ntre clase.

Process View (Viziune Proces) Viziunea proces descrie sistemul din punct de vedere al proceselor, interaciunii dintre obiecte implicate n sistem.
Deployment View (Viziune Desfurare) Viziunea desfurare descrie sistemul din punct de vedere al infrastructurii. Aici se arat cum componentele sunt instalate, cum are loc comunicare ntre diferite pri fizice ale sistemului. Implementation View (Viziune Implementare) Viziunea implementare descrie sistemul din punct de vedere al componentelor i interaciunii dintre aceste componente.

Viziunea +1 din cele 4+1 viziuni este viziunea utilizatorului Acest model descrie funcionalitile sistemului, cerinele funcionale i nefuncionale. Este cea mai important viziune, viziunea care descrie sistemul din exterior, aa cum l vede utilizatorul/beneficiarul final.
Pe baza acestei viziuni sunt dezvoltate celelalte viziuni. O eroare scpat la

22

interpretarea cerinelor se propag n toate cele 4 viziuni, astfel cu, ct mai trziu este depistat eroare cu att mai costisitoare este fixarea lui.

22

ODP-RM Architecture Overview - este orientat spre dezvoltarea sistemelor informaionale ce vor asigura infrastructura informaional al unei ntreprinderi. Metodologia propus introduce conceptul de perspective de modelare i presupune cinci perspective (view points): (1) de ntreprindere (motivaie, scop i politici ale acelui sistem); (2) informaional (semantica informaiilor); (3) computaional (descompunerea sistemului n obiecte care interacioneaz prin interfee); (4) de proiectare (se focalizeaz pe mecanisme i funcii necesare pentru a suporta interaciunea distribuit ntre obiectele sistemului); (5) tehnologic (alegerea tehnologiilor de implementare).

23

DoDAF (Department of Defense Architecture Framework Cadrul Arhitectural al departamentului de aprare al SUA) descrie sistemul din trei perspective, fiecare acoperind diferite aspecte ale arhitecturii: Operaional View (Perspectiva Operaional) descrie sarcinile, activitile, principalele noduri i schimbul de informaie asociat fiecrui nod. Systems View (Perspectiva Sisteme) descrie prile sistemului i conexiunea ntre aceste pri n contextul Perspectivei Operaional. Technical Standards View (Perspectiva standardelor tehnice) descrie portofoliul standardelor minime i a regulilor care guverneaz implementarea, interaciunea i interdependena sistemelor descrise in Perspectiva Sisteme.

24

Cadrul de lucru Zachman este un cadrul de lucru pentru Arhitecturi de scar larg care asigur un mod sigur de definire i reprezentare al unei arhitecturi. El const dintr-o matrice de clasificare bidimensional care descrie intersecia a 6 ntrebri de comunicare (Ce, Unde, Cnd, De ce, Cine i Cum) cu 6 rnduri corespunztoare modelelor (Domeniu, organizaie, Sistem, Tehnologie, Detalii i Funcionare) Cadrul de lucru Zachman nu este o metodologie de dezvoltare a sistemelor informaionale. El este o schem de organizare a activitilor i artefactelor din cadrul unui sistem informaional (cum ar fi: documente de arhitectur, specificaii, modele etc). Zachman ine cont de ambele aspecte: ce descrie fiecare artefact (de exemplu date i funcionaliti) i cui ii este adresat (de exemplu persoana responsabil)

25

26

Microsoft Solution Framework (MSF) este un cadru de gestiune a proiectelor, o metodologie, o colecie de principii i concepte aplicabile la realizarea sistemelor informatice. MSF include modele de baz cum ar fi modelul echipelor implicate n proiecte, modelul procesului de realizare al unui sistem informatic.

27

Rational a elaborat un proces iterativ unificat (RUP) de dezvoltare a sistemelor informaionale. Acest proces se aplic n special la dezvoltarea sistemelor informatice complexe. Procesul RUP presupune dezvoltarea unui sistem informatic n patru faze: Iniiere, Elaborare, Construire i Tranziie. n fiecare faz au loc un ir de activiti cum ar fi: specificarea cerinelor, analiza cerinelor, arhitectura i proiectarea, dezvoltarea codului testarea i asigurarea calitii, instalarea. n faza de Iniiere accentul se pune pe domeniul si constringerile proiectului. Se

definieste viziunea proiectului, se specific i analizeaz cerinele. Se definete un plan de dezvoltare a produsului. Scopul fazei de Elaborare este analiza detaliat a cerinelor, actualizarea planului de project, identificarea i eliminarea riscurilor. Deasemenea la aceast faz are loc elaborarea arhitecturii i proiectarea sistemului. Construirea este una din cele mai importante faze n procesul de dezvoltare a produsului. n aceasta faza n mare msur are loc scrierea nemijlocit a codului program, se aplica diferite standarde pentru a asigura o calitate cat mai inalta. Modulele elaborate sunt testate. Faza de Tranziie este faza n care produsul este finalizat si livrat clientului. n aceast faz nu se mai accepta cerine din partea clientului. mSe fac ultimele testari. Prdusul este livrat ctre client, iar la necesitate personalul este instruit.
Diagrama data ilustreaza ponderea fiecarei activitati n cadrul fiecarei faza. Diagrama data contine doar o parte din activitati. Aici nu sunt incluse activitatile de suport cum ar fi: Managementul schimbrilor, managementul proiectului i a infrastructurii care sunt prezente n egal msur pe parcursul intregului process. Important: Initierea nu este doar Analiz Elaborarea nu este doar Arhitectur i Proiectare Contruirea nu este doar Scrierea codului Tranzitia nu este doar Testarea i instalarea

28

Definiia UML al OMG (Object Management group consoriu de promovare i aprobarea a

conceptelor Orientate Obiect)


Limbajul Unificat de Modelare (The Unified Modeling Language UML) este un limbaj grafic pentru vizualizarea, specificarea, construirea i documentarea artefactelor unui sistem informatic. UML ofer un standard de a descrie particularitile unui sistem, inclusiv aspectele conceptuale cum ar fi procesele de business si funcionalitile sistemului precum i aspecte cum

29

ar fi instruciuni ale limbajelor de programare, scheme ale bazelor de date i componente reutilizabile.

29

UML prezint elemente care asigur descrierea unui sistem att din punct de vedere structural, ct i de comportament. Elementele de structur sunt: Actorii, clasele, componentele, nodurile. Un actor se reprezint printr-un omule etichetat cu numele actorului. O clas este reprezentat printr-un dreptunghi, un nod printr-un cub. Elementele de comportament sunt: cazurile de utilizare, activitile, strile. Un caz de utilizare se reprezint printr-o elips, iar activitile i strile prin dreptunghiuri care au colurile rotunjite. Elementele UML sunt conectate ntre ele utiliznd relaii. Mai multe elemente pot fi grupate n grupuri de elemente, formnd pachetele.

30

UML definete un mecanism de extindere al elementelor prin care se extind proprietile elementelor existente. Aceste mecanisme comune cuprind: - stereotipurile - specializeaz clasele metamodelului; - valori asociate - extind atributele claselor metamodelului; - notie ofer explicaii la elementele la care sunt ataate;

- constrngerile - extind semantica metamodelului;

31

O diagram ofer utilizatorului un mijloc de vizualizare i de manevrare a elementelor de modelare. Majoritatea diagramelor se prezint sub forma unor grafuri, compuse din elemente i arce. Diagramele pot arta o parte sau toate caracteristicile elementelor de modelare, conform nivelului de detaliu util n contextul unei diagrame date. Diagramele pot grupa informaii interdependente, pentru a arta, de exemplu caracteristicile motenite de o clas. n cadrul UML-ului diagramele sunt grupate n dou grupuri: diagrame de structur i diagrame de comportament. Diagramele de structur sunt: diagrama de clase (cea mai utilizat), diagrama de componente, diagrama de desfurare. Diagramele de comportament sunt: diagrama cazurilor de utilizare, diagrama de secven, diagrama de stri, diagrama de activiti.

32

Elementele mpreun cu relaiile ntre ele formeaz diagramele UML. Aa cum elementele sunt de structur i comportament avem i diagramele de structur i comportament. UML are 7 diagrame de baz. Diagrame de structur: Diagrama de clase, Diagrama de componente, Diagrama de desfurare Diagrame de comportament: Diagrama cazurilor de utilizare, Diagrama de secven, Diagrama de stri i diagrama de activiti

33

Fiecare diagram descrie sistemul dintr-o anumit perspectiv. Dac s asociem diagramele la cele 4+1 perspective atunci diagramele de clase descriu perspectiva Logic al sistemului, diagrama de componente pe cea de Implementare, Desfurare corespunztor Desfurare, Secven, Activitate, Stri Procese, iar diagramele cazurilor de utilizare descriu perspectiva utilizatorului asupra sistemului.

34

35

ntr-un model iterativ de implementare al unui sistem informaional orice cerina are un ciclu de via care ncepe cu un caz de business, caz care descrie cerina n mod narativ, dup care urmeaz un set de pai de analiz, proiectare, implementare, testare i evaluare a cerinei date.

36

O diagram a cazurilor de utilizare prezint o colecie de cazuri de utilizare i actori i este folosit n general pentru a indica sau caracteriza funcionalitile i comportamentul ntregii aplicaii a sistemului interacionnd cu unul sau mai muli actori. Utilizatorii i orice sistem ce poate interaciona cu sistemul sunt actori. Cazurile de utilizare sunt construite pe baza necesitilor pe care le au actorii. Aceasta asigur faptul c sistemul va produce ceea ce s-a dorit. Diagramele cazurilor de utilizare conin elemente ce pot reprezenta actori, relaii de asociere, relaii de generalizare, pachete i cazuri de utilizare. Se poate crea o diagram a cazurilor de utilizare de nivel nalt, pentru a vizualiza limitele i comportamentul sistemului. De asemenea, se pot crea una sau mai multe diagrame pentru a descrie o parte a aplicaiei sistemului. Cazurile de utilizare pot include alte cazuri de utilizare ca o parte a comportamentului su. O diagram a cazurilor de utilizare indic un set de actori externi i cazurile de utilizare ale sistemului n care particip respectivii actori.

37

Un actor este un stereotip al unei clase. Utilizatorii i orice sistem care poate interaciona cu sistemul n chestiune sunt actori. Astfel, un actor reprezint un rol jucat de o persoana sau o entitate care interacioneaz cu sistemul. Actorii se reprezint sub forma unor mici personaje avnd propriul su nume. Fiecare actor trebuie s aib un nume, iar numele acestuia descrie rolul jucat de ctre actor.

38

Un caz de utilizare este un set de aciuni realizate de sistem ca rspuns la evenimentele declanate de un actor al sistemului. Un caz de utilizare complet trebuie s ofere o valoare msurabil unui actor. Un caz de utilizare conine toate evenimentele care pot surveni n cadrul perechii actor - caz de utilizare, nu neaprat unul ce va apare n orice scenariu particular. Un caz de utilizare conine un set de scenarii care explic diferitele secvene ale interaciunii din interiorul tranzaciei.. Un caz de utilizare poate de asemenea descrie comportamentul unui set de obiecte, ca de exemplu o organizaie. Forma de baza a cazului de utilizare este o elips:

39

Modelul domeniului este un model care de obicei este elaborat de ctre un Analist de sistem sau un arhitect de sistem. Scopul principal al modelului este Identificarea entitilor i a claselor conceptuale Identificarea relaiilor ntre entiti Identificarea caracteristicilor entitilor

40

La reprezentarea modelului de domeniu sunt utilizate elemente de structura UML. Este importanta de menionat faptul ca la aceast etap se identifica i reprezint entitile i relaiile ntre entiti. ntre entiti pot exista doua tipuri de relaii: relaia de asociere (has a) i relaia de generalizare sau motenire (is a).

41

Diagramele de clase exprim la modul general structura static a unui sistem, n termeni de clase i de relaii ntre aceste clase. Aa cum o clas descrie un ansamblu de obiecte, o asociere descrie un ansamblu de legturi: obiectele sunt instane ale claselor, legturile sunt instane ale asocierilor. Diagramele de clase conin clase i diagramele de obiecte conin obiecte, dar se pot mixa clasele i obiectele atunci cnd este vorba de diferite tipuri de metadate. Diagramele de clas sunt mult mai relevante dect cele de obiecte. De obicei, se construiesc diagramele de clase i ocazional diagrame de obiecte pentru a ilustra structuri de date complicate ori transmiteri de mesaje.

42

Clase Entitate Pstreaz informaiile din sistem Folosite de obicei pentru reprezentarea conceptelor cheie Clase Frontier Clase de tip interfa utilizator: clase prin care utilizatorii comunic cu sistemul dat Clase de tip interfa sistem: clase prin care alte sisteme comunic cu sistemul dat Clase de tip interfa dispozitiv: clase ce asigur interfee de comunicare cu dispozitive externe cum ar fi imprimant, scanner etc. i care genereaz evenimente externe Clase Control Clase ce asigur comportamentul sistemului

43

Clasele de tip Entitate (Entity), Frontier (Boundary) i Control (Control) sunt folosite pentru a modela clasele ce interacioneaz n comunicarea utilizatorului cu sistemului. De exemplu daca un utilizator dorete s scoat bani dintr-un bancomat, atunci utilizatorul va fi reprezentata printr-un actor, iar o clas de tip Frontier va reprezenta interfaa de comunicare, prelucrarea datelor va fi modelat de ctre o clas de tip control, iar nsi tranzacia va fi modelat de ctre o clasa de tip Entitate.

44

Aplicaiile client-server reprezint o metod arhitectural care are ca scop furnizarea de informaii, stocate pe un server, ctre un utilizator client. Avantajele folosirii arhitecturilor pe nivele: 1. Separare clar a nivelurilor. Prin aceast separare mai muli clieni au acces la o mare varietate de aplicaii server. Principalele avantaje pentru aplicaiile client sunt: dezvoltare rapid prin re-utilizarea componentelor de algoritmi i o faz de testare mai scurt deoarece componentele server au fost deja testate; 2. Redefinirea strategiei de stocare a datelor nu afecteaz clientul, acesta accesnd datele printr-o interfa bine proiectat care ncapsuleaz toate detaliile de stocare; 3. Obiectele care manevreaz algoritmi de prelucrare a datelor trebuie s fie ct mai aproape fizic de mediul de stocare a datelor, ideal, pe aceeai main. n acest fel este redus ncrcarea reelei deoarece aceasta este zona de trafic intens;

4. n contrast cu modelul Client/Server n care doar datele erau accesibile publicului, acum utilizatorii au acces la servicii;
5. Serverele fiind sisteme mai sigure, protecia i securitatea datelor sunt mai simplu de obinut i ntreinut. Totui, fiind vorba practic de aplicaii distribuite, protecia datelor i controlul accesului sunt elemente importante.

45

ntr-o form simpl, nivel 0 de securitate, acestea sunt: autentificarea, autorizarea i criptarea; 6. Relativ la actualizarea (upgrade) sistemului, este mai uor s schimbi o component soft pe server dect de a furniza numeroilor clieni versiuni noi ale sistemului.

45

Teoretic ntr-o diagram de clase nu trebuie s existe clase izolate, clase care nu au relaii cu nici o alt clas. ntre clase pot exista 4 tipuri de relaii: dependena, asocierea i generalizarea

46

Dependena este cea mai general relaie ntre dou clase. Ea arat dependena obiectului de o anumit clasa de una sau mai multe obiecte de alt clas

47

Asocierea este o relaie general i art cum obiectele unei clase sunt conectate la obiectele altei clase. Poate fi identificat din cazurile de utilizare. Asocierile ntre clase se reprezint printr-o linie ce unete dou clase. Fluxul de date poate fi ntr-o direcie sau n ambele direcii. n momentul n care se cunoate direcia datelor linia de conexiune ntre clase se indic prin sgeat.

48

Uneori, relaia de asociere nu este suficient pentru reprezentare relaiei dintre dou clase. n cazul n care relaia n sine este definit de o entitate atunci aceast entitate se asociat cu relaia dintre cele doua clase.

February 2, 2002

49

Este un caz particular de asociere care modeleaz o relaie parte ntreg ntre un agregat (ntreg) i a prilor sale. Agregarea este utilizat atunci cnd o clas este definit ca o colecie a altor clase . Durata de via al uni obiect de clas parte nu depinde de durata de viaa al unui obiect de tip clas ntreg. Obiectul de tip clas ntreg are referin ctre obiectul de tip clas parte.

February 2, 2002

50

Este un caz particular de asociere care modeleaz o relaie parte ntreg ntre un agregat (ntreg) i a prilor sale. Compoziia este utilizat atunci cnd o clas este definit ca o colecie a altor clase, iar durata de via al uni obiect de clas parte depinde de durata de viaa al unui obiect de tip clas ntreg. Obiectul de tip clas ntreg conine obiectele de tip clas parte.

51

Relaia de motenire/generalizare este utilizat atunci cnd dintr-o clas de baz deriv una sau mai multe clase. Clasele derivate motenesc toate proprietile i comportamentul clasei de baz. Exist cazuri cnd din mai multe clase care au proprieti comune i comportament comun se generalizeaz o clas de baz care reprezint proprietile i comportamentul comun al claselor derivate.

52

Diagramele de secven prezint interaciunile ntre obiecte din punct de vedere temporal, contextul obiectelor, nefiind reprezentat n mod explicit ca n diagramele de colaborare, reprezentarea concentrndu-se pe exprimarea interaciunilor. O diagrama de secvena reprezint o interaciune ntre obiecte insistnd pe cronologia (ordinea temporal) a expedieri mesajelor Obiecte Simbolul grafic pentru un obiect este similar cu cel al unei clase cu diferena c numele obiectului este subliniat

53

54

Diagramele de stri reprezint vizual automatele cu numr finit de stri, din punctul de vedere al strilor i tranziiilor. O diagram de stare este utilizat pentru a reprezenta strile unei clase date, evenimentele ce cauzeaz tranziiile de la o stare la alta, i aciunile care rezult din schimbrile strilor.

Fiecare diagram este asociat unei clase sau unui nivel mai nalt din diagrama de stare. O diagram de stare este un graf bazat pe stri conectate prin tranziii. O diagram de stare descrie o istorie a vieii obiectelor sau clasei date.
O diagram de stare prezint o singur stare iniial, una sau mai multe stri, una sau mai multe stri finale i tranziiile ntre stri. Starea unui obiect reprezint istoria cumulativ a comportamentului respectivului obiect. Starea acoper toate proprietile statice ale obiectului i valorile curente pentru fiecare proprietate. Toate instanele ale aceleiai clase exist n aceeai stare. Numele unei stri trebuie s fie unic n clasa pe care o descrie, sau dac este imbricata unei stri, n interiorul acesteia. Grafic, starea n diagrama de stare se reprezint printr-un dreptunghi rotunjit n care scriem un nume i un compartiment:

55

56

O diagram de activitate este o extensie a unei diagrame de stri. Aceasta nseamn c o diagram de activitate va avea toate caracteristicile unei diagrame de stare, plus unele noi. Elementele componente ale unei diagrame de activitate sunt urmtoarele: 1) stri de aciune 2) Tranziii 3) bloc de decizii 4) linii de sincronizare 5) culoare

57

58

Diagramele de componente descriu elementele fizice (hardware) i relaiile lor n mediul de implementare. Diagramele de componente arat opiunile privind implementarea. Fiecare diagram de componente descrie modelul din punct de vedere fizic. Diagramele de componente conin urmtoarele elemente:

subsisteme;
componente: programe principale; module; subprograme; procese; dependene. Se pot crea una sau mai multe diagrame de componente pentru a descrie subsistemele i componentele la nivelul de top al modelului curent; unele diagrame de componente sunt coninute chiar ele n nivelul de top al modelului. De asemenea, se pot crea diagrame de componente pentru a arta subsistemele i componentele coninute n fiecare subsistem al modelului curent; unele diagrame de componente pot fi chiar ele coninute de subsistemele care cuprind subsistemele i componentele care le descriu.

59

60

61

Arhitectura infrastructurii pe care va fi implementat sistemul, calculatoarele, perifericele,(referite ca nodurile sistemului), mpreun cu conexiunile dintre ele, sunt prezentate n cadrul unei diagrame de desfaurare. Componentele i obiectele executabile sunt alocate n interiorul nodurilor, ceea ce permite o vizualizare a unitailor care se vor executa pe fiecare nod.

62

Deoarece diagramele de desfurare sunt tipul de diagrame care deseori trebuie aprobate de ctre beneficiar la construirea lor se pot utiliza stereotipuri, care asociaz fiecrui element UML o imagine mai sugestiv, ceea ce face diagrama mai uor citibil i ineleas.

63

64

65

66

67

68

69

Arhitectura Sistemelor Informaionale face parte din una din cele 4 module din cadrul cursului de iniiere pentru managerii departamentelor TI. Acest modul este un modul fr de care un manager IT nu-i poate realiza pe deplin potenialul. tim cu toii c n actual exist diverse sisteme informatice, diferite modaliti de a le implementa, diferite tehnologii care se folosesc la implementarea lor, toate cu scopul rezolvrii anumitor probleme din lumea real. n cadrul acestui modul noi vom ncerca s vedem cum se mapeaz problemele pe care ncercm s le soluionm la soluiile tehnice. Cum arat o soluie tehnic i care sunt factorii care influeneaz construirea acestor soluii.

Referine:
1. PROGRAMUL STRATEGIC DE MODERNIZARE TEHNOLOGIC A GUVERNRII, Aprobat prin Hotrrea de Guvern Nr. 710 din 20 septembrie, 2011. 2. Daniel Minoli. Enterprise Architecure A to Z. Frameworks, Business Modeling, SOA, and Infrastructure Technology. CRC Press, 2008.

3. Georgescu Cristian. - "Analiza i proiectarea sistemelor informatice", Editura Radical, Galai, 1999.

4. The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson, Grady Booch, 1999
5. Todd Biske. SOA Governance. The key to successful SOA adoption in your organization, PACKT Publishing, 2008.

70

71

De-a lungul timpului urmrim sisteme informaionale care din ce n ce necesit o comunicare, interacionare cu alte sisteme informaionale. Astfel iniial fiind ca sistem izolate, n actual sistemele informaionale sunt dezvoltate pe baza arhitecturilor SOA, care permit o interaciune cu alte sisteme in formaionale pe baza de servicii.

72

Pn recent interaciunea ntre dou organizaii (sisteme informaionale) se fcea prin trimitere de scrisori oficiale, telefon, dischete etc. Probleme: timp, calitate, cost (redundanta datelor, consistenta datelor, comunicare)

73

Odat cu apariia sistemelor distribuite sistemele informaionale pot interaciona ntre ele prin internet. Avandaje: comunicare mai rapida (internet), calitatea datelor mai inalta (se transmit prin canale electronice, se transmit digital) Problema: se implementeaza separat, nu intodeauna compatibile, reutilizabile, grad de autonomie redusa Exemplu: 2 organizaii, fiecare cu sisteme informaionale proprii. Sistemele sunt conectate in reea. Comunicarea se face prin internet. Problema: Nu toate sistemele au interfee de comunicare

74

Sistemele bazate pe Arhitectura orientat pe Servicii (SOA) asigur comunicarea ntre sisteme prin oferirea i consumul de servicii. Astfel, un sistem ofer i/sau consum serviii.

75

76

SOA ofer beneficii att n domeniul Business ct i domeniul TI

77

78

79

Descoperirea Serviciilor Descrierea serviciilor i meninerea lor devin o provocare Compoziia Serviciilor Serviciile sunt integrate n aplicaii

Provocare: Managementul tranzaciilor si conversiilor


Invocarea Serviciilor Serviciile sunt invocate, iar codul lor este executat Service Statelessness Service Discoverability Service Composability Service-Orientation and Interoperability

80

84

Observm n acest slide cum diferite sisteme informaionale comunic ntre ele prin servicii. Implicarea Pacientului este redus la minim.

85

86

87

88

Datele sunt active (bunuri): Datele sunt active care au valoare att pentru ceteni ct i pentru guvern i trebuie gestionate corespunztor. Datele sunt distribuite: Fiecare organizaie are propria baz de date Datele sunt partajate: Cetenii au acces la datele necesare pentru a rezolva

problemele lor. Prin urmare, datele sunt partajate ntre diferite organizaii.
Datele sunt accesibile: Datele sunt accesibile cetenilor pentru a rezolva problemele lor.
Disponibile schema cu redundanta nivelului de stocare al datelor (redundanta discurilor in cadrul unui server, si al mai multor servere in cadrul unui sistem informational) Datele sunt veridice: Datele oferite cetenilor sunt veridice i calitative. (Criptarea si decriptarea) Datele sunt securizate: Datele sunt protejate mpotriva utilizrii

neautorizate i dezvluirii lor.

Pentru digitizarea serviciilor publice nu doar datele sunt importante. PE lng date trebuie s existe procese i Sisteme Informaionale care s gestioneze aceste date

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

Istoria se repeta si anii 70 aveau o forma de cloud computing Asta am invatat la istorie si asta se intampla in cazul cloud computing-ului. Ne intoarcem in anii 1970 la acele mainframe-uri care ocupau un etaj intreg al unei cladiri si care contineau procesoare si benzi magnetice, pe post de memorie, pe care utilizatorii le bagau in server, iar la capatul lor erau, bineinteles, niste ecrane (terminale) unde se putea vizualiza procesul de calcul. Dupa acesta perioada, s-a trecut la micile servere, pe care fiecare companie sau chiar birou le aveau ascunse in spatele dulapului si pe care le administra un om din companie. Va imaginati ca mai multe astfel de mici servere intr-o companie rezulta un numar mare de oameni care ar trebui instruiti sa le administreze componentele hardware si software, servere care ocupa spatiu, curent si carora le trebuie un sistem bun de racire. Nu in ultimul rand necesita back-up-uri si sisteme de redundanta in caz ca se strica ceva. Situatia se schimba acum, companii specializate creaza adevarate infrastructuri de servere pe care le inchiriaza pentru hosting de aplicatii, pagini web si putere de calcul. Ei fac toata administratia in locul tau (depozitare servere, cooling, stocare, back-up), iar tu trebuie doar sa iti uploadezi aplicatia sau fisierele.

109

110

111

Hotarirea 710 din strategie. Utilizarea principiilor arhitecturii orientate spre servicii

(Service Oriented Architecture) n platforma tehnologic guvernamental comun care reprezint un nor informaional privat (private cloud) Arhitectura orientat pe servicii (SOA) ofer trei niveluri principale de prestare a serviciilor infrastructura ca serviciu, platforma ca serviciu i software ca serviciu metode testate pentru a atinge flexibilitate n prestarea serviciilor, a facilita colaborarea i reutilizarea serviciilor, precum i a sprijini procesele operaionale din sectorul public

112

113

MeGIF Moldova e-Government Interoperability Framework

114

NSB National Service Bus platforma ce asigura interoperabilitatea DVT Decript Validate Translate TE Translate Encript BPM Business Process Management

BRE Business Rules Engine


Business Processes procese sectoriale (interne) si tot odata intersectoriale. Ex. DMS sectorial si intersectorial

115

116

Autentificare User name i Parol utilizatorul se autentific prin nume i parol Autentificare eID utilizatorul dispune de un dispozitiv (smart card) cu un certificat digital pe el Autentificare mobile eID este similar celul eID cu diferena ca certificatul digital se afl pe telefonul mob, deci nu este necesitate de un dispozitiv special.

117

118