AMSI

MINISTERUL EDUCAŢIEI AL REPUBLICII MOLDOVA UNIVERSITATEA TEHNICĂ A MOLDOVEI

Facultatea ,,Calculatoare Informatica si Microelectronica” Catedra - Automatica și Tehnologii Informaționale

Teza de curs Tema: ,,Analiza si modelarea unui Content Management System”

A elaborat: Florea Andrei, gr. SI111 A verificat: Melnic Radu

Chişinău 2014

Cuprins: Introducere..................................................................................................................... 3 1.

UML – limbaj universal de modelare..............................................................................4

2.

Noţiunile şi blocurile costructive ale limbajului UML..........................................................5

3.

Elaborarea modelului................................................................................................ 13 3.1 Diagrama Use Case......................................................................................... 18 3.2 Diagrama de segventa si colaborare...............................................................21 3.4 Diagrama claselor........................................................................................... 31 3.5 Diagrama de stare........................................................................................... 33 3.6 Diagrama de activitate.................................................................................... 37 3.7 Diagrama de componente...............................................................................41 3.8 Diagrama de amplasare.................................................................................. 42

4.

Concluzii............................................................................................................... 43

5.

Bibliografie............................................................................................................ 44

2

Introducere

  

  

Un sistem informatic reprezintă un model fizic de simulare a comportamentului unei părţi din lumea reală sau conceptuală. Acest model fizic este definit prin intermediul unui limbaj de programare şi el se concretizează într-o aplicaţie (model executabil) ce poate fi rulata pe un sistem de calcul. Astăzi pentru realizarea aplicaţiilor de complexitate medie sau mare apare necesitatea de a utiliza diferite metode de analiză şi modelare (proiectare) a sistemelor informatice. Prin metode de analiză şi proiectare înţelegem o mulţime de procedee, tehnici şi recomandări utilizate în etapele timpurii ale ciclului de viaţă al unei aplicaţii având ca scop final crearea unui model al aplicaţiei care urmează a fi construite. Specificarea acestui model se realizează prin intermediul unui limbaj sau formalism vizual (notatie) compus dintr-un set de simboluri grafice şi adnotări textuale. Ciclul de viaţă al unei aplicaţii reprezintă totalitatea etapelor care sunt parcurse în procesul de dezvoltare a aplicaţiei respective. Cele mai importante etape sunt: Culegerea de specificaţii (analiza funcţională) – presupune definirea problemei; specificarea detaliata a functionalitatilor ce trebuiesc sa fie suportate de catre sistemul informatic; Analiza – în cadrul căreia se realizează identificarea caracteristicilor esenţiale tuturor soluţiilor corecte posibile; Modelarea – este necesară pentru înţelegerea sistemului, cu alte cuvinte este un proces de reprezentare a obiectului asociat printr-un model adecvat pentru obţinerea informaţiei necesare despre acest model. Pentru aceasta este necesară prelucrarea unei cantităţi mari de modele interconectate; Proiectarea – care adaugă modelelor de analiză noi elemente care definesc o soluţie particulară, pe baza optimizării anumitor criterii; Implementarea – în care se realizează un proiect executabil al soluţiei particulare modelată în faza de proiectare; Testarea – în care se verifică echivalenţa implementării cu modelul proiectat şi validează faptul că implementarea respectă criteriile de corectitudine identificate în etapa de analiză. Metodele de analiză şi proiectare orientate pe obiecte permit parcurgerea etapelor ciclului de viaţă a aplicaţiilor într-o manieră iterativă. Odată cu evoluţia metodelor de analiză şi proiectare orientate-obiect s-au dezvoltat o serie de instrumente care permit automatizarea procesului de realizare a aplicaţiilor având la bază aceste metode. Astfel de instrumente poartă numele de instrumente CASE (Computer Aided Software Engineering) şi ele sunt formate dintr-o 3

colecţie de componente care sprijină realizarea operaţiilor ce trebuie efectuate în cadrul uneia sau mai multor etape ale unei metode de analiză şi proiectare.

1. UML – limbaj universal de modelare În anii ’90 a apărut o serie de metode de dezvoltare a aplicaţiilor, fiecare dintre acestea introducând notaţii (grafice sau formale) particulare. Printre cele mai populare metode se numărau:  OMT (Object Modeling Technique) – James Rumbaugh  OOD (Object Oriented Design) – Greedy Booch  OOSE (Object-Oriented Software Engineering) – Ivar Jacobson Limbajul UML (Unified Modeling Language) s-a născut în 1997, din dorinţa de a unifica cele mai importante concepte introduse de fiecare dintre aceste metode precum şi pentru a găsi o notaţie standard de modelare a acestor concepte. UML s-a format având la bază cele trei metode amintite mai sus, la care se adaugă contribuţii notabile în diverse faze ale etapelor de analiză şi proiectare: clasificare, hărţi de stări, ciclu de viaţă al obiectelor, şabloane de proiectare ş.a. UML este un limbaj de vizualizare, specificare, construire şi documentare a artefactelor sistemelor informaţionale. El reprezintă un standard de notaţie introducînd un număr de 9 diagrame de descriere a unui sistem informatic şi semantică a acestor diagrame propunîndu-ne nu în ultimul rînd şi un proces de utilizare a acestor diagrame în construcţia unei aplicaţii. Permite construirea modelelor precise, bazînduse pe specificarea tuturor soluţiilor importante care se referă la analiza, proiectarea şi realizarea elaborării şi dezvoltării produsului soft. Astfel, stabilirea ierarhiei claselor poate fi înţeleasă studiind atent codul fiecăruiadintre ele, dar înţelegerea întregei structuri fiind imposibilă. În al treilea rînd, dacă autorul codului niciodată nu a concretizat într-o formă reală modelul gîndit, această informaţie riscă mult pentru a fi perdută pe totdeauna. În cel mai bun caz, informaţia ar putea fi parţial reconstruită reieşind din realizarea ei. Datorită faptului că UML este un limbaj grafic, aceasta permite de a rezolva problemele sus menţionate, întru-cît cu un limbaj textual de programare nu totdeauna ne permitem acest lucru, plus la aceasta UML nu este doar un simplu sistem de simboluri grfice; după fiecare din ele stă o semantică bine definită, astefl încît o idee concepută de un careva elaborator poate fi interpretată doar într-un singur sens de către altul sau chiar şi de un program. Modelele elaborate în baza lui pot fi traduse automat în diverse limbaje de programare, cum sunt C++, Java, Visual Basic, pentru construcţia diferitor aplicaţii WEB ţi chiar în tabele relaţionale ale bazelor de date. Noţiunele pe care dorim să le reprezentăm grafic sunt reprezentate în UML, cele textuale prin intermediul codului, asfel are loc realizarea proiwctării directe, adică generarea codului sursă în orice limaj de programare concret. Poate avea loc şi proiectarea 4

inversă, adică trecerea de la codul sursă la reconstruirea modelului. Dacă nu codificăm informaţia atunci această informaţie riscă de a fi pierdută la trecerea directă de la model la cod, deacea pentru proiectarea invesă sunt necesare atît mijloace instrumentale, cît şi intervenţia programatorului. Limbajul UML este destinat în primul rînd elaborării sistemelor informaţionale, însă sfera de aplicare a lui nu se limitează doar la modelarea produselor soft. Expresivitatea lui permite modelarea documentelor în sistemele juridice, modelarea structurii şi funcţionării sistemelor de deservire a pacienţiolor în spitale, aplicîndu-se în mare măsură în următoarele domenii: sisteme informaţionale de proporţiile unei întreprenderi, servicii bancare şi financiare, telecomunicaţii, transport, în diferite ramuri ale industriei, economie, electronica medicinală, ştiinţă, distribuirea sistemelor WEB, etc.

2. Noţiunile şi blocurile costructive ale limbajului UML Pentru început vom face cunoştinţă cu noţiunea de obiect. Obiect este o reprezentare a unei entităţi din lumea reală sau conceptuală. Un obiect este un concept, o abstracţie sau un lucru ce are un înţeles şi limite bine definite în cadrul unei aplicaţii. Într-un sistem informatic, obiectele au trei caracteristici:  Stare  Comportament  identitate Starea unui obiect este una dintre condiţiile posibile în care un obiect poate exista. Starea obiectului se modifică în timp, şi este definită de valorile luate de o submultime a mulţimii de proprietăţi (atribute) şi de relaţiile pe care obiectul le are cu alte obiecte din sistem. De exemplu: un obiect calculator se poate afla în starea conectat – dacă se află în realţie cu obiectul reţea electrică şi în starea deconectat dacă nu se află în relaţie cu acest obiect. Comportamentul determină modul în care un obiect reactionează la cererile altor obiecte din sistem. Comportamentul este implementat prin intermediul unei mulţimi de operaţii. Indentitatea reprezintă faptul că fiecare obiect este unic (chiar şi atunci când starea unui obiect este identică cu starea altui obiect). În UML obiectele sunt reprezentate printr-un dreptunghi, având numele obiectului subliniat şi centrat în cadrul dreptunghiului. Calculator 5

6

În limbajul UML sunt incluse trei blocuri de costruire: Esenţele – sunt abstracţii ale principalelor elemente de model Relaţiile – reprezintă legăturile dintre esnţe Diagramele – efectuează gruparea pe interese a ansamblurilor de interese. În UML sunt patru tipuri de esenţe: 1. Esenţele structurate – sunt numite substantive în model care de obicei reprezintă părţile statice, care corespund elementelor conceptuale sau fizice ale modelelor. Sunt prevăzute şapte tipuri de esenţe structurate: Clasa (Class) – descrierea mulţimei obiectelor cu aceleaş atribute, operaţii, relaţii şi semantică. Clasa poate reprezenta una sau mai multe interfeţe. Grafic se reprezintă cu ajutorul unui dreptunghi împărţit în trei secţiuni unde se indică respectiv numele clasei, atributele şi operaţiile. Numele clasei Atributele clasei Operaţiile clasei De expemplu clasa calculator poate avea următoarle caracteristici:  Atribute: perfomanţă, informaţie, rapiditate, gabarit  Operaţii: prelucarea infomaţiei, afişarea informaţiei, rularea programelor  Poate avea relaţii cu următoarele obiecte ale claselor: reţea, printer, scaner Fiecare clasă trebuie să aibă un nume ce o deosebeşte de restul claselor. Acest nume poate fi simplu şi compus. Vom avea un nume compus atunci cînd pe lîngă numele simplu al clasei se va indica şi pachetul căruia îi aparţine clasa dată. Sintaxa utilizată în acest caz este: :: Atributele sunt nume ale proprietăţilor clasei ce include şi mulţimea valorilor pe care le pot primi exemplarele acestora. O clasă poate să aibă mai multe attribute sau nici unul. Sintaxa utilizată pentru atribute este: < numele atributului> : type= 

Specificatorul de acces poate lua una din următoarele trei valori, care se reprezintă cu ajutorul simbolurilor speciale:

Simbolul “+” indică faptul că avem un atribut de tip public. Atributul este accesibil sau vizibil din oricare altă clasă a pachetului, în care este determinată diagrama  Simbolul “#”indică faptul că avem un atribut de tip protected. Atributul dat nu este vizibil şi nu poate fi accesat de toate clasele cu excepţia subclaselor clasei date. 7



Simbolul ”-“ indică faptul că avem un atribut de tip private. Atributul dat nu este vizibil sau accesibil nici unei alte clase (fără excepţii). Dacă specificatorul de acces lipseşte este vorba de faptul că vizibilitatea atributului nu este indicată. Operaţiile sunt nişte abstracţii ce ne indică acţiunele ce le putem efectua asupra obiectelor clasei date. O clasă poate avea mai multe operaţii sau nici una. Sintaxa utilizată pentru declararea operaţiilor este: (lista de parametri): Interfaţa (Interface) – reprezintă un asamblu de operaţii care determină setul de servicii, care poate să le asigure respectiv o clasă sau componentă.. În aşa mod interfaţa descrie compoentul văzut din exterior. Ea determină numai specificarea operaţiei semantice, dar niciodată exeutarea ei. Interfaţa este reprezentată grafic printrun cerculeţ; în formă desfăşurată îl putem reprezenta ca o clasă stereotip pentru dezvăluirea operaţiilor şi a altor atribute.

Interacţiune (Collaboration) – reprezintă un asamblu de roluri şi alte elemente care furnizează împreună, producînd un oarecare efect de colaborare. Astfel interacţiunea areaspect atît structural cît şi de comportament exprimat înschimbul mesajelor între o mulţime de obiecte într-un context oarecare, în rezultat fiind atins un scop anumit. Un mesaj este specificarea schimbului de date între obiecte, în timpul căruia este transmisă o informaţie oarecare contînd pe faptul că drept răspuns va rezulta o acţiune concretă. Una şi aceaş clasă poate să participe în mai multe interacţiuni, în aşa mod ea realizează imaginea de comprotament care la rîndul său furnizează sistema. Grafic interacţiunea se reprezintă în felul următor: Nume

8

Precedente (Use Case) - reprezintă o descrire, o succesiune de acţiuni pe care o efectuează sistemul şi produce rezultatul urmărit de un oarecare actor. Se foloseşte pentru structurizarea esenţelor comportamentale şi se rea lizeză prin intermediul comparării. Grafic precedentele se notează astfel: Nume

Clase active (Active class) – sunt clasele obiecte care sunt atrase în mai multe proceduri şi deacea ele pot să iniţializeze acţiuni de comenzi. Clasa activa se deosebeşte de cea obişnuită prin aceea că obiectele ei reprezintă elemente care acţionează paralel cu alte obiecte. Se notează asemenător cu clasa obişnuită, numai că liniile de contur sunt mai evidenţiate: Nume Atibute Operaţii Componenta - reprezintă părţile fizice ale sistemului care corespunde unui sistem de interfeţe. Componenta reprezintă prin sine o cutie fizică, care conţine elemente logice. În sistemă se pot întîlni aşa componente cum sunt: codurile sursă, fişiere executabile, fişiere binare. O componenta este un modul soft (cod sursa, cod binar, dll, executabil etc) cu o interfata bine definita. Un tip de componentă reprezintă o parte distinctă, realocabilă, a implementării unui sistem. Instanţa unei componente este o unitate de implementare în execuţie şi poate fi utilizată pentru reprezentarea unităţilor de implementare care au o identitate în momentul execuţiei. Reprezentarea grafică a componentelor în UML este dată mai jos. Un tip de componentă are asociat un nume, iar o instanţă a unei componente are asociate (opţional) un nume şi un tip. In general numele unei componente este numele fisierului reprezentat de componenta. Obiectele implementate de o instanţă de componentă se reprezintă grafic în interiorul simbolului instanţei de componentă. În mod analog se reprezintă grafic clasele implementate în componente. Componenta

9

Nodul (Node) este un element fizic care există în timpul funcţionării complexului de programe reprezentînd o resursă de calcul care de obiciei e dotată cu cel puţin un volum de memorie, iar de cele mai multe ori cu un procesor. Grafic se reprezintă sub forma unui cub care conţine numere. Elementele descise pînă aici sunt esenţele principale care sunt incluse în limbajul UML, ele însă pot fi modificate în alte elemente cum sunt: actori, documente, fişiere, biblioteci, pagini şi tabele. 1.

Esenţe de comportament: - sunt componente dinamice ale limbajului UML şi sunt verbe, care descriu componentul modelării în timp şi spaţiu. Interracţiune – reprezintă comportamentul , esenţa cărora constă în schimbul de mesaje dintre obiecte în cadrul unui cotext cocret. Cu ajutorul interacţiunii se poate descrie atît operaţia aparte, cît şi comportamentul unui asamblu de obiecte. Ea păropune un înalt set de obiecte cum sunt: comunicarea, consicutivitatea factorilor şi legăturilor. Grafic se reprezintă astfel: Nume Automatul (State machine) este descrierea succesiunii stărilor prin care trece obiectul pe parcursul ciclului său de vaiţă, reacţionînd la evenimente (inclusiv şi descrirea reacţiei la aceste elemente). Grafic se reprezintă printr-un dreptunghi în cadrul căruia este descrisă acţiunea Acţiune

Starea (State) este o situaţie din viaţa obiectului, pe parcursul căreia el satisface o condiţie oarecare, realizează o activitate sau se află în aşteptarea unei condiţii. Grafic starea reprezintă un dreptunghi cu colţurile rotungite în cadrul căreia este descrisă activitatea: Activitate

2.

Esenţele de grup - sunt părţile organizatorice ale limbajului UML. Acestea sunt blocurile pe care se poate baza modelul. Există numai o esenţă de grup – pachetul. Pachetul (Packejes) este principala funcţie de organizare a elementelor modelelor în limbajul UML. Numele pachetului trebuie să conţină un cuvuînt chee 10

care este determunat de UML şi preluat de stereotipe. În numele lui se poate conţine informaţie despre proprietăţi şi elemente. Pachetul poate să mai conţină şi subpachete şi înăuntrul fiecărui pachet se scrie numele sau conţinutul. Pachet Conţinut

Stereotipul (Stereotype) este extinderea dicţionarului UML care permite crearea noilor tipuri de blocuri constructive, analogice cu cele existente dar specifice pentru problema dată. El este reprezentat sub formă de nume luat în ghilimele şi amplasat deasupra numelui altui element.

Relaţiile În limbajul UML sunt definite patru tipuri de relaţii:  de dependenţă  de asociere  de generalizare  de realizare Aceste realaţi sunt unice şi îndeplinesc funcţia de interconexiune a blocurilor de construcţi ale libajului UML la crearea modelelor concrete. Dependenţă (depenecy)– reprezintă o releţie temetică dintre două esnţe, prima din ele fiind independentă, iar a doua dependentă de prima, adică modificarea primii esenţe va provoca modificarea celei de-a doua. Grafic se reprezintă astfel:

Asociere (association) – reprezintă o relaţie structurată care descrie un asamblu de legături dintre obiecte.

 Există mai multe tipuri de asocieri: agregare – modelează o relatie de tip ‘parte/intreg’ în care obiectul parte poate face parte din mai mulţi intregi (în momente de timp diferite). În reprezentarea grafică se adauga un romb gol la capatul corespunzator părţii ‘întreg’.  compunere – modeleaza o relatie de tip ‘parte/intreg’ in care obiectul parte compune un singur intreg pe toată perioada ciclului de viata şi se distruge în 11

momentul distrugerii întregului. În reprezentarea grafică se adauga un romb plin la capatul corespunzator partei ‘intreg’  legătură (clasă asociere) – reprezinta o colecţie de atribute care caracterizează o asociere. Clasele asociere apar atunci cand nu exista un mod logic de a plasa aceste atribute la nivelul unei clase aflate in sistem.  asociere reflexivă – asociere intre obiecte ale aceleasi clase.  Generalizare – reprezintă un raport dintre generalizare şi specializare, adică cînd un obiect al unui element specializat poate înlocui un alt element specializat, cu alte cuvinte modelează moştenirea proprietaţilor, operaţiilor si relaţiilor între două clase. Clasa generală poarta numele de superclasă, iar clasa specializată se numeşte subclasă. Generalizarea apare atunci când orice exemplu de obiect al unei clase este un exemplu valid de obiect al altei clase. Genealizare – reprezintă un raport dintre clasificatoare, unde un clasificator determină “contactul”, iar altul asigură îndeplinirea lui. Cel mai des realizarea se îndeplineşte între interfeţe şi componentele ce se realizează, şi între precedente şi cmponente. Diagramele Diagramele în UML sunt reprezentări grafice ale unui set de elemente. O diagramă în UML este analogică unui graf, vîrfurile căruia sunt esenţele, iar ramurile – realaţiile. Unul şi acelaş element poate fi reprezentat într-un număr mai mare de combinaţii, de aici rezultă mai multe tipuri de diagrame. Limbajul grafic UML permite elaborarea a nouă tipuri de diagrame: 1. diagrama claselor 2. diagrama obiectelor 3. diagrama precedentelor 4. digrama succesiunelor 5. diagrama interacţiunii 6. diagrama de stare 7. diagrama de acţiune 8. diagrama componentelor 9. diagrama de desfasurare Diagrama cazurilor de utilizare (Use case diagram)

12

Diagramele de cazuri de utilizare au rolul de a reprezenta într-o formă grafică funcţionalităţile pe care trebuie să le îndeplinească sistemul informatic în faza sa finală. Diagrama claselor (Class diagram) Diagramele de clase fac parte din categoria diagramelor statice. Ele descriu structura internă a sistemului informatic prin identificarea claselor, a atributelor şi operaţiilor acestora şi a relaţiilor dintre clase. Diagrama de secvenţă şi colaborare (Sequence diagram and Colaboration diagram) Un scenariu reprezintă o cale (un drum) prin fluxul de evenimente al unui caz de utilizare. Scenariile descriu o secvenţă de acţiuni concrete care pot avea loc la un moment dat în sistem. Scenariile se descriu prin intermediul aşa-numitelor diagrame de interacţiune. În UML avem două tipuri de diagrame de interacţiune: diagramele de secvenţă şi de colaborare. Fiecare dintre aceste diagrame reprezintă o vedere grafică diferită a unui scenariu. Diagramele de secvenţă prezintă interacţiunile care au loc între diverse obiecte ale unui sistem, ordonate cronologic. Ele determină obiectele şi clasele implicate întrun scenariu şi secvenţele de mesaje transmise între obiecte necesare îndeplinirii funcţionalităţii scenariului. Diagramele de secvenţă sunt asociate unui caz de utilizare. Deoarece diagramele de secvenţă oferă o imagine temporală a scenariului ele sunt utile în fazele timpurii ale analizei pentru identificarea obiectelor si claselor, pe când diagramele de colaborare surprind legăturile dintre obiecte, acestea sunt utile la faza de proiectare, atunci când se modelează implementarea relaţiilor. Diagrame de tranziţie a stărilor (State machine diagram) UML furnizează diagramele de tranziţie a stărilor şi diagramele de activităţi pentru modelarea comportamentului obiectelor în interiorul lor. Una din aceste diagrame este diagrama de tranziţie a stărilor. Diagrame de componente (Component diagram) O diagramă de componente prezintă dependenţele existente între diverse componente software (cod sursă, cod binar, executabile, librarii cu legare dinamica etc) ce compun un sistem informatic. Aceste dependenţe sunt statice (au loc in etapele de compilare sau link-editare) sau dinamice (au loc in timpul execuţiei).

13

Diagrame de exploatare (Deployment diagram) Diagramele de exploatare prezintă configuraţia elementelor de procesare din timpul execuţiei şi componentele, procesele şi obiectele care le conţin. Instanţele componentelor soft reprezintă manifestări a unor unităţi de cod în cadrul execuţiei. Instrumentul Rational Rose conţine un editor de diagrame de exploatare particulare.

3.

Elaborarea modelului

În lucrarea dată avem ca sarcină: Analiza principiilor implimentarii modelelor de desenare a curbelor shi suprafetelor, astfel vom încerca să facem un prototip al unui program de desemare MS Paint, elaborat de compania Microsoft Software. Pornind de la aceasta, vom elabora şi explica toate diagramele necesare acestui proiect pornind cu diagrama cazurilor de utilizare. Diagramele variantelor de utilizare Reprezintă interacţiunea dintre variantele de utilizare, care sunt funcţiile sistemului şi persoanele în acest sistem. Adică prezintă persoane sau sisteme, care primesc sau transmit informaţia în sistema dată. Pe diagramă sunt prezente acţiunile reciproce dintre variantele posibile de utilizare şi persoane. Ea reflectă cerinţele către sistemă din punct de vedere al utilizatorului. În aşa mod variantele de utilizare – este o funcţie efectuată de sistem, iar persoanele – sunt persoane cointeresate de sistemul elaborat. Diagrama arată care persoane iniţiază diagrama variantelor de utilizare. La fel din ea se vede când persoanele cointeresate primesc datele de la variantele de utilizare. Din diagramele variantelor de utilizare se poate de aflat multă informaţie referitor la sistemă. Acest tip de diagramă descrie funcţionarea sistemei la general. Utilizatorii, managerii proiectării, analiticii, specialiştii în domeniu şi toţi cei care sunt cointeresaţi în sistemul dat pot să înţeleagă ce poate face sistemul în cauză. Diagramele variantelor de utilizare conţin, firesc, variante de utilizare, actori şi legături între ei. Diagramele variantelor de utilizare conţin, firesc, variante de utilizare, actori şi legături între ei. Varianta de utilizare (Use Case) este prezentarea cea mai generală a funcţiilor sistemului. Actorul (Actor) – tot ceea ce interacţionează cu sistemul dat. Variantele utilizării şi actorii definesc cadrul de folosinţă pentru care este creată aplicaţia. Variantele utilizării definesc tot ceea ce se petrece în interiorul sistemului, iar actorii – ceea ce e în afara lui. Cum am mai menţionat mai sus, variantele de utilizare şi actorii răspund la întrebarea „Ce va face sistemul?”, însă nu şi la întrebarea „Cum o va face sistemul?”. Unul din avantajele folosirii diagramei variantelor este acela că ea ne permite să înţelegem ce din punct de vedere funcţional va face sistemul elaborat şi cu cine/ce va interacţiona. Încât informaţia este prezentată grafic şi este uşor inteligibilă, clienţii 14

care au comandat elaborarea sistemului nu trebuie să aibă nici un fel de cunoştinţe tehnice sau de un alt fel. Este larg practicată elaborarea a câtorva diagrame a variantelor pentru un sistem. Unele descriu grupele principale variantelor de utilizare, altele – legăturile între ele şi actori; numărul lor depinde de cel care le elaborează. De notat, însă, că ele trebuie să conţină un volum mare de informaţii utile încât astfel de diagrame sunt greu de înţeles. Scopul principal al diagramelor variantelor de utilizare este documentarea tuturor variantelor de utilizare (funcţiile sistemului), actorilor (ceea ce e în afara sistemului cu care el interacţionează) şi a legăturilor între ei. E bine de urmat următorii paşi în timpul elaborării diagramelor variantelor:  Nu modelaţi legături între actori. Din definiţie – actori sunt în afara sistemului, ce înseamnă că legăturile între ei nu sunt regulate de sistem  Nu conectaţi două diagrame variantelor(cu excepţia a câtorva exemple )  Fiecare varianta de utilizare este iniţializată de un actor, de aceea orice „săgeată” începe la un actor şi se termină la o variantă de utilizare(există excepţii)  Gîndiţi la baza de date ca la un strat de sub diagramă. Prontr-o variantă de utilizare datele sunt introduse în baza de date, iar scoase – printr-o altă. Varianta de utilizare este o prezentare generală a funcţionalităţii sistemului, cu alte cuvite ele arată cum sistemul poate fi folosit.

Avantajul principal a variantelor de utilizare este că folosindu-le separăm implementarea sistemului de descrierea funcţiilor sale. Acest fapt ajută concentrarea atenţiei pe aşa întrebări ca satisfacerea cerinţelor către sistem fără a avea nevoie de a defini cum sistemul va fi implementat. Diagramele variantelor ne arată ce sistemul va face şi cum poate fi utilizat încă la începutul proiectului. Metoda diagramelor variantelor de utilizare nu este cea standard şi diferă de ea foarte mult. Separând proiectul în diagramele variantelor noi atragem atenţia mai mult procesului de percepere a sistemului, nu şi felului de implementare a lui. Decompoziţia funcţională are ca scop devizarea poiectului în subprobleme cu care se va confrunta sistemul, apoi diagramele variantelor atrag atenţia asupra aspiraţiilor utilizatorului către sistem.

15

La începutul oricărui proiect apare întrebarea: „Care sunt variantele de utilizare pentru proiectul dat?”. Este preferabil de citit atent documentaţia clientului, luaţi în vedere opinia oricărui utilizator care va folosi acest sistem. Este bine să obţineţi răspunsuri la următoarele întrebări de la fiecare din viitorii utilizatori a sistemului:  Ce vrea să facă cu sistemul?  Va lucra cu informaţie(introducere, ştregere, etc)?  Va fi nevoie de a informa sistemul despre careva evnimente din afară?  Va fi nevoie ca sistemul să informeze utilizatorul despre careva evenimente? Setul de variante de utilizare creat ajută familiarizarea utilizatorilor cu funcţiile sistemului la nivelul cel mai general, de aceea dacă numărul lor este foarte mare elasticitatea şi uşurinţa de percepere se pierde; de obicei un proiect are 20-50 de variante de utilizare. Pentru a organiza schema mai bine variantele de utilizare pot fi strânse în pachete. Variantele de utilizare atrag atenţia asupra cererilor utilizatorilor către sistem. Fiecare variantă de utilizare prezintă o tranzacţie terminată între utilizator şi sistem. Denumirile variantelor de utilizare trebuie să fie alese din sfera de utilizare a sistemului, nu şi din cea tehnică, prin aceasta se ajunge la o mai bună înţelegere a sistemului de către utilizatori. De obicei variantele de utilizare sunt numite folosind verbe care descriu rezultatul tranzacţiei respective. Utilizator nu este curios să ştie cum se va face una sau alta varianta de utilizare, pe el îl interisează doar rezultatul final al tranzacţiei. Pentru a fi sigur că orice variantă de utilizare este prezentă în modelul respectiv este necesar de a: 1. controla că orice cerinţă funcţională este prezentă cel puţin într-o variantă de utilizare. 2. lua în consideraţie cum va interacţiona cu sistemul oricare din utilizatori finali 3. ce fel de informaţie va introduce/scoate din sistem utilizatori 4. cine va porni/opri sistemul dat 5. toate sistemele din afară cu care va interacţiona sistemul dat şi ce fel de informaţie va fi trimisă între ele. Actorii – sunt tot ceea ce interacţionează cu sistemul elaborat. În timp ce variante de utilizare descriu evenimente din interiorul sistemului, actorii descriu ceea ce este în afara lui. În limbajul UML actorii se reprezintă prin următoare figură

16

Există trei tipuri de actori: utilizatori, alte sisteme ce interacţionează cu sistemul dat şi timpul. În primul tip intră persoane fizice, ele sunt prezente în majoritatea sistemelor. Denumind actori folosiţi nume-rol şi nu profesia sau postul lor, încât un om concret la diferite momente de timp poate reprezenta diferiţi actori. Dimineaţa el poate fi lucrator din banca, iar la amiază – client care vrea să scoată bani din contul său. Folosind nume-rol nu va trebui să schimbaţi modelul de fiecare dată când apar noi posturi sau când drepturile şi obligaţiile unui post sunt schimbate. Tipul doi sunt alte sisteme, fie banca are o sistemă credit care prelucrează conturile de credit ale clienţilor. Încât sistemul elaborat trebuie să interacţioneze cu sistema credit, ultima devine un actor. Timpul devine un actor în cazuri când de el depind careva procese din sistem, de exemplu la o oră stabilită se încep procese de serviciu, încât noi nu putem controla timpul el devine un actor. Limbajul UML presupune un număr de legături între actori şi variante de utilizare. Aceste legături sunt de comunicaţie(communication), de utilizare(uses), de extindere(extends) şi de generalizare(actor generalization). Legăturile de comunicaţie descriu legăturile între actori şi variante de utilizare. Cele de utilizare şi de extindere – numai între variante de utilizare, iar cele de generalizare – între actori. Legături de comunicaţie Este legătura între un actor şi o variantă de utilizare. În limbajul UML este prezentată în forma unei săgeţi:

Direcţia săgeţii indică pe cel care a iniţializat comunicaţia. Legături de utilizare O legătură de utilizare (Uses relationship) oferă posibilitatea ca o variantă de utilizare să folosescă funcţionalitatea altei variante de utilizare. Cu ajutorul acestei legături se modelează comportamentul care se întîlneşte în mai multe variante de utilizare. Legătura de utilizare în limbajul UML este prezentată cu ajutorul unei săgeţi şi cuvîntului <> Legături de extindere Legături de extindere(Extends relations) sunt asemănătoare celor de utilizare, însă varianta concretă de utilizare poate şi să nu folosească funcţionalitatea varinatei de utilizare abstracte cu care este legată prin legătura de extindere. În limbajul UML astfel de relaţii se reprezintă printr-o săgeată cu cuvântul <>

17

Cu ajutorul relaţiei de generalizare noi accentăm atenţia asupra faptului că mai mulţi actori au calităţi comune. De exemplu clienţii pot fi de două tipuri: persoane fizice şi persoane juridice. De obicei acest fel de relaţii este util când comportamentul unui tip de actori diferă de cel a altui tip într-aşa fel încât cauzează acţiunile sistemei. De exemplu dacă un tip de actori poate iniţializa un fel de variantă de utilizare, iar al doilea – nu poate, atunci este bine să introducem ambele tipuri ca fiind generalizări a unui tip comun. Însă dacă tip A şi tip B iniţializează aceleaşi variante de utilizare cu mici diferenţe este mai preferabil să nu creăm 2 tipuri de actori generalizate, ci să implementăm prelucrarea în fluxul de evenimente a variantei de utilizare. Notiţe În timpul lucrului asupra proiectului este binevenită ataşarea unor notiţe scurte elementelor de pe diagramă. Mai târziu va fi uşor de a percepe destinaţia sau alte caracteristici ale elementului. Pachete În limbajul UML elementele de tipul variantelor de utilizare, actori, clase şi componente pot fi grupate în pachete (packages) şi se reprezintă în felul următor: Numărul pachetelor care pot fi create este nelimitat, este chiar posibil de a plasa un pachet în altul.

18

3.1 Diagrama Use Case

Fig.3.1 Diagrama caz de utilizare User In diagrama data sunt aratate cazurile de utilizare pentru un utilizator, ce nu este inregistrat in sistem. Un astfel de utilizator nu poate face nici un fel de modificare in system, el poate vizualiza doar continul paginilor site-ului vizitat. De asemeni el se poate inregistra pentru a primi anumite drepturi in sistem.

Fig .3.2 Diagrama caz de utilizare Author

19

In aceasta diagrama sunt prezentate cazurile de utilizare pentru un utilizator cu drepturile de autor. Acest utilizator poate vizualiza continutul paginilor site-ului, la fel ca si orice alt utilizator. Autorul mai are si alte drepturi: adaugarea unui content nou, editarea unui content existent sau stergerea unui content. Aceste actiuni pot fi efectuate doar dupa autentificarea in sistem.

Fig. 3.3 Diagrama caz de utilizare Moderator Diagrama data arata cazurile de utilizare pentru utilizatorul cu drepturi de moderator. Acest utilizator de asemeni poate vizualiza continutul paginilor siteului, la fel ca utilizator simpli sau autorii. Pe linga astea moderatorul mai are dreptul de aprobarea a contentului adaugat de autori. El verifica daca autorii au respectat regilile la adaugarea contentului, si doar dupa aprobare, contentului va fi vizibil pentru alti utilizatori.

20

Fig.3.4 Diagrama caz de utilizare AddContent Cazul de utilizare AddContent include citeva cazuri de utilizare. Pentru a adauga un content nou, trebuie de specificat titlul contentului, de introdus textul (continutul), imagini (la dorinta), si de formatat textul(font, color, font-size etc.).

Fig.3.5 Diagrama caz de utilizare EditContent Editarea contentului include mai multe actiuni: schimbarea titlului, modificarea continutului, reformatarea textului, adaugarea unor imagini noi sau stergerea celor existente. 21

3.2 Diagrama de segventa si colaborare

Fig. 3.6 Diagrama de Secventa Authentication

Fig.3.7 Diagrama de Colaborare Authentication Cind un autor incearca sa adauge sau sa editeze un content, serverul ii cere sa se autentifice. El trebuie sa introduca login si password, si daca in baza de date se gaseste un utilizator cu asa credentiale, se face logarea in sistem. 22

Fig 3.8 Diagrama de Secventa ContentVisualization

Fig.3.9 Diagrama de Colaborare Generate ContentVisualization Cind un utilizator acceseaza o pagina, serverul prelucreaza cererea, cautind pagina ceruta, in caz ca exista o asa pagina, se extrage din baza de data contentul pentru pagina data, si cu ajutorul Content Delivery Application se genereaza fisierul .html, care este trimis ca raspuns browser-ului si afisat utilizatorului 23

Fig 3.10 Diagrama de Secventa AddContent

24

Fig.3.11 Diagrama de Colaborare AddContent Pentru ca un autor sa poata adauga un content pe site, el trebuie mai intii sa fie autentificat. Accesind pagina de adaugarea a contentului, autorului i se ofera o forma pentru completare, in care el trebuie sa introduca titlul contentului si continul lui. Dupa ce forma este trimis catre server, acesta o prelucreaza si o salveaza in baza de date.

25

Fig 3.12 Diagrama de Secventa EditContent

26

Fig.3.13 Diagrama de Colaborare EditContent Pentru a edita un content, autorul trebuie sa acceseze pagina cu lista contenturilor existente si sa aleaga contentul ce doreste sa-l modifice. Lui i se ofera, ca si in cazul adaugarii, o forma, insa deja completata cu datele contentului ales. Dupa executarea modificarilor dorite, forma este trasmisa serverului, iar el salveaza contentul modificat in baza de date.

27

Fig 3.14 Diagrama de Secventa DeleteContent

28

Fig.3.15 Diagrama de Colaborare DeleteContent Ca si pentru orice alta operatie, este necesara autentificarea in sistem. Ca si in cazul editarii, utilizatorul acceseaza pagina cu lista content-urilor. Dupa alegerea contentul ce urmeaza sa fie sters, se transmite serverului o cerere de stergere, serverul cauta contentul in baza de date, si in cazul gasirii, in sterge. Utilizatorului i se afiseaza lista cu content-uri, deja fara contentul sters.

29

Fig 3.16 Diagrama de Secventa AproveContent

30

Fig.3.17 Diagrama de Colaborare AproveContent Dupa adaugarea sau editarea unui content, el trebuie sa fie verificat daca corespunde tutror regulilor. Un moderator acceseaza o pagina cu lista contenturilor neaprobare, alege un content, verifica daca acesta corespunde regulitor. Daca contentul corespunde regulilor, serverului este trimis o cerere, acesta modifica statutul de aprobare a content-ului, dupa care contentul va putea fi vizualizat de alti utilizatori.

31

3.4 Diagrama claselor

Fig.3.18 Diagrama de Clasa Users Aceasta diagrama arata tipurile de utilizatori din sistem, si modul de interactiune a lor cu sistemul. Avem 3 tipuri de utilizatori: User, Moderator si Author. Ultimii 2 tot pot fi tratati ca useri, deoare au si ei aceleasi drepturi ca userii. Toate tipurile de utilizatori interactioneaza cu sistemul prin intermediul unui browser.

Fig. 3.19 Diagrama de Clasa CMS 32

Diagrama precedenta, arata structura sistemului CMS, care este format dintr-un server, functia lui fiiind de primire, prelucrare si transmitere a cererilor; o baza de date, in care se pastreaza toata informatia; si o aplicatie care folosind informatia din baza de date, genereaza fisierele html, care ulterior vor fi transmise de catre server browser-ului utilizatorului.

Fig. 3.20 Diagrama de Clasa UserCMS Aceasta diagrama arata legatura dintre utilizator si CMS. Utilizatorii prin intermediul browser-erelor, fac legatura cu serverul. Dupa multitudinea relatiilor, se observa ca server, este doar unul, insa la el se pot adresa mai multi utilizatori. 33

3.5 Diagrama de stare

Fig. 3.21 Diagrama de Stare Authentication La autentificare sistemul trece prin citeva stari. Dupa deschiderea paginii de autentificare, sistemul asteapta ca utilizatorul sa introduca credentialele sale, dupa introducerea lor, sistemul se afla in stare de verificare a corectitudiinii lor. Daca ele nu sunt corecte, se trece in starea retry, si utilizatorul este nevoit sa le introduca din nou. In cazul in care credentialele sunt corecte, are loc logarea, si sitemul trece in starea user logged.

34

Fig. 3.22 Diagrama de Stare AddContent La adaugarea unui content sistemul trebuie sa treaca mai intii prin starea user authentificated. Dupa deschiderea paginii de adaugare, si inainte de transmiterea datelor, trebuie sa fie parcurse 3 stari: titlul introdus, textul introdus si imaginile ales. Salvarea contetului in baza de date se face dupa trimiterea formei de adaugare, dupa trecerea de starea content saved, se afiseza pagina cu contentul adaugat.

35

Fig. 3.23 Diagrama de Stare EditContent 36

La modificarea unui content, trebuie mai intii sa fie afisata lista content-urilor existent si sa fie ales contentul ce va fi editat. Dupa asta sistemul poate trece prin 3 stari paralele, insa ca nu sunt obligatorii, si anume: textul modificat, titlul modificat si imaginile modificate. Dupa trecerea prin una din ele, sau prin toate, are loc transmiterea datelor catre server, si dupa ce au fost salvate modificarile, are loc afisarea pagina cu content-ul editat.

Fig. 3.24 Diagrama de Stare DeleteContent Pentru stergerea unui content, trebuie afisata pagina cu content-urile existente, se alege contentul dorit, si se sterge. Dupa ce contentul a fost sters, se afiseaza iarasi lista de content-uri existente, si se poate repeta lantul de actiuni pentru un alt content, sau se poate parasi pagina.

37

3.6 Diagrama de activitate

Fig. 3.25 Diagrama de Activitate Authentication Pentru a se autentifica utilizatorul trebuia sa faca unele actiuni, si anume: sa deschida pagina de logare, sa introduca credentialele sale si sa transmita serverului cererea de logare. Serverul, primind cererea, va cauta in baza de date utilizatorul cu credentialele primite. Daca exista un astfel de utilizator, se deschide pagina principala

38

dupa logare, in caz ca nu exista asa ucredentiale, utilizatorul este nevoit sa le introduca din nou.

Fig. 3.26 Diagrama de Activitate ContentVisualization La vizualizarea unui pagini, serverul verifica daca exista pagina ceruta. Daca pagina nu exista, se va afisa un mesaj de eroare. Insa daca exista pagina data, se va extrage din baza de date contentul pentru pagina respectiva, se va genera fisierul html cu contentul scos din baza de date, si sa va afisa utilizatorului. Diagrama urmatoare reprezinta activitatile pentru adaugarea unui content pe site. Pentru aceasta trebuie sa se execute autentificarea si sa se deschida pagina de adaugarea a contentului. Dupa care se va introduce titlul contentului, textul continutului sau si imagine din el. La finisrea introducerii datelor respective, ele 39

trebuie trimiste catre server. Ultimul le va salva in baza de date si va afisa pagina cu contentul adaugat utilizatorului.

Fig. 3.27 Diagrama de Activitate AddContent Urmatoarea diagrama reprezinta activitatile pentru editarea unui content, care se aseamna cu cele din diagrama precedenta. Insa la editare, trebuie deschisa pagina cu 40

lista content-urilor existente si de ales contentul ce dorim sa-l modificam. Restul actiunilor sunt ca si la adaugarea contentului.

41

Fig. 3.28 Diagrama de Activitate EditContent 42

3.7 Diagrama de componente

Fig. 3.29 Diagrama de Componente Visualization Vizualizarea contentului unei pagini se face, evident, prin intermediul unui browser. Acesta depinde de fisierul html, ce il primeste de la server. Serverul depinde de aplicatia ce generea documentele html. Ultima depinde de baza de date, deoarece genereaza documentele in baza informatiilor extrase de acolo.

Fig. 3.30 Diagrama de Componente Content Fiecare pagina contine un content, cu alte cuvinte, un articol. Acesta trebuie sa aiba un titlu si un continut. Continul la rindul sau este compus din text si imagini.

43

Fig. 3.31 Diagrama de Componente Page Fiserele html sunt generate de catre Content Delivery Application, in baza unui Layout si unui Content (informatii extrase din baza de date).

3.8 Diagrama de amplasare

Fig.3.32 Diagrama de amplasare Diagrama de aplasare arata toate elemente ce sunt folosite in sistem, si legaturile dintre ele. Utilizatorul cu ajutorul calculatorului sau prin intermediul internetului face legatura cu serverul. Serverul se leaga cu baza de date, care se poate afla chiar pe server, sau poate aplasata si pe un alt server.

44

4.

Concluzii

Lucarea dată modelează şi analizează un produs soft – în cazul dat acesta fiind un CMS (Content Management System). La elaborarea modelului m-am bazat pe principiile limbajului UML, folosind ca instrument de lucru mediul Enterprise Architect. În procesul elaborării proiectului am căpătat deprinderi de abordare sistemică a problemelor de proiectare şi de programare a sistemelor complexe , prezentînd posibilităţile de modelare ale sistemelor pe exemplul CMS-ului, cu ajutorul mediului de programare Enterprise Architect. Limbajul UML uşurează elaborarea, vizualizarea şi documentarea modelelor, ceea ce permite o proiectare rapidă a sistemelor, prin accentuarea atenţiei aspra aspectelor necesare proiectării. Analizând sistemul dat în baza metodologiei APOO şi trecând prin etapele planificării, sincronizării şi analizei am dezvoltat modelul dat în diagramele de interacţiune şi diagrama claselor în care am descris fiecare caz de utilizare prin interacţiunea dintre obiecte. Datorită diagramelor utilizate modelul poate fi ilustrat din mai multe puncte de vedere. Diagrama cazurilor de utilizare descrie aplicaţiile principale ale CMS-ului. Diagrama claselor descrie structura unui sistemului în viziunea mea, adică arată toate secţiunele lui şi destinaţia fiecăreia. Diagramele interacţiunelor şi colaborărilor descriu cum se desfăşoară funcţiile unui astfel de sistem.

45

5.

Bibliografie

1.

Ovidiu Gheorghies,Ingineria programarii (UML),7octombrie 2002

2.

Prieto-Diaz, R. and Arango, G. 1991. Domain Analysis and Software Systems Modeling. Las Alamitos, California: Computer Society Press of the IEEE.

3.

Knoepfel, Andreas; Bernhard Groene, Peter Tabeling (2005). Fundamental Modeling Concepts - Effective Communication of IT Systems. 4.

Melnic Radu, AMSI conspectul, UTM (2010).

46