Ministerul Educaiei al Republicii Moldova Universitatea Tehnic a Moldovei Facultatea Calculatoare Informatic i Microelectronic Catedra Automatica si Tehnologii Informaionale

Disciplina: Ingineria produselor program

Raport
Lucrarea de laborator Nr. 1

Tema: Studierea Stereotipurilor Boundary,Control i Entity utiliznd instrumentul UML

A efectuat:

st. grupei TI-091 Anghel Ivan

A verificat :

lector univ. Boleac Ruslan

Chiinu 2013

1 Scopul lucrrii Studierea prii teoretice legat de Studierea instrumentul UML. 2 Sarcina lucrarii a) De studiat la general Studierea Stereotipurilor Boundary,Control i Entity utiliznd instrumentul UML b) De creat diagrame UML. 3 Noiuni teoretice n aceast lucrare vom aborda subiecte legate de procesul de dezvoltare i ntretinere a unui produs software. Multe dintre tehnicile care se aplica n acest domeniu sunt similare celor utilizate de inginerii care lucreaza n industrie, de exemplu de catre constructorii de automobile, poduri sau televizoare. De altfel, domeniul poarta numele de inginerie software. Problema fundamental a ingineriei programrii este ndeplinirea cerinelor clientului. Aceasta trebuie realizat ntr-un mod flexibil i pe termen lung. Ingineria programrii se ocup cu toate etapele dezvoltrii programelor, de la extragerea cerinelor de la client pn la ntreinerea i retragerea din folosin a produsului livrat. Pe lng cerinele funcionale, clientul dorete (de obicei) ca produsul final s fie realizat cu costuri de producie ct mai mici. De asemenea, este de dorit ca aceasta s aib performane ct mai bune (uneori direct evaluabile), un cost de ntreinere ct mai mic, s fie livrat la timp, i s fie sigur.Cea mai frecventa eroare la selectarea claselor este acela de a reprezenta ceva ca pe un atribut n loc de concept, daca nu putem cere unei entitati dect valoarea sa, atunci 54 acea entitate este un atribut; daca i putem pune mai multe ntrebari, atunci avem de-a face cu un concept care are la rndul sau mai multe atribute i legaturi cu alte obiecte. Exist trei tipuri de clase (marcate n UML ca stereotipuri): Clase entiti (sau clase de domeniu) reprezint nucleul unei aplicaii, rein informaile legate de entitile persistente i captureaz serviciile ce conduc majoritatea interaciunilor in aplicaie. De obicei clasele entitate trebuie s: -inmagazineze i reda valori de atribute; -creeze i s tearg entiti; -furnizeze un comportament dependent de modificarea strii entitii. Clase de interfa reprezint grania dintre actorii care doresc s interacioneze cu aplicaia i clasele entitate. Majoritatea sunt componente ale interfeei utilizator (fiecare cutie de dialog este o clasa interfa), modeleaz comunicarea cu alte aplicaii sau reprezint clase wrapper peste anumite componente soft. Se determin studiind: -modul n care doresc actorii s creeze entiti; 2 Stereotipurilor Boundary,Control i Entity utiliznd

-interfaa ntre aplicaie i alte sisteme; -modalitatea de vizualizare a informaiilor (rapoarte). Clase de control (controller) coordoneaz activitatea n interiorul aplicaiei. Se ceeaz cte o clas controller pentru fiecare caz de utilizare. Pot juca unul din urmtoarele roluri: -modelarea unui comportament tranzacional; -secven de control specific unuia sau mai multor cazuri de utilizare; -serviciu ce separ obiectele entitate de obiectele de interfa. Planul de implementare i planul de test, descrise mai jos, pot fi incluse de asemea n fazele de implementare i respectiv testare. ns unul din scopurile fazei de proiectare este stabilirea unui plan pentru terminarea sistemului, de aceea cele douplanuri au fost incluse n paragraful curent. Planul de implementare stabilete programul dup care se va realiza implementarea i resursele necesare (mediul de dezvoltare, editoarele, compilatoarele etc.). Planul de test definete testele necesare pentru stabilirea calitii sistemului. Dac produsul trece toate testele din planul de test, este declarat terminat. Acoperirea testului este procentajul din produs verificat prin testare. n mod ideal, o acoperire de 100% ar fi excelent, ns este rareori ndeplinit. De obicei, un test cu o acoperire de 90% este simpl, ns ultimele 10% necesit o perioad de timp semnificativ. Faza de implementare. n aceast faz, sistemul este construit, ori plecnd de la zero, ori prin asamblarea unor componente pre-existente. Pe baza documentelor din fazele anterioare, echipa de dezvoltare ar trebui s tie exact ce trebuie s construiasc, chiar dac rmne loc pentru inovaii i flexibilitate. Echipa trebuie s gestioneze problemele legate de calitate, performan, biblioteci i debug. Scopul este producerea sistemului propriu-zis. O roblem important este ndeprtarea erorilor critice. Pentru analiza i proiectarea programelor s-au creat limbajele de modelare. Unul din aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling Language). UML nu este un simplu limbaj de modelare orientat pe obiecte, ci n prezent, este limbajul universal standard pentru dezvoltatorii software din toata lumea. UML este succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare orientate pe obiecte (mrtoda Booch creata de Grady Booch, OMT Object Modeling Techniques, i OOSE Object Oriented Software Engineering). UML se constituie din unirea acestor limbaje de modelare i n plus deine o expresivitate care ajuta la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau. Limbajul este destinat vizualizrii, specificrii, construirii i documentrii sistemelor de aplicaii, dar are limitri n ceea ce privete generarea codului. UML reunete cele mai bune tehnici i practici din domeniul ingineriei programrii, care i-au dovedit eficiena n construirea sistemelor complexe. 3

UML este un limbaj de modelare care ofera o exprimare grafica a structurii i comportamentului software. Pentru aceasta exprimare grafica se utilizeaza notatiile UML. UML este un limbaj de modelare vizual, orientat obiect, care descrie (reprezint) proprietile structurale i dinamice ale unui sistem software. Fiecare tehnic de modelare d o vedere diferit, static sau dinamic, a unei aplicaii. n Figura 1, am reprezentat diagrama generala de lucru a unei aplicaii radio care lucreaz pe baza conectrii la internet. Interaciunea noastr a aplicaiei va fi reprezentat n 4 etape. Deci un utilizator, este reprezentat prin actor, acceseaz aplicaia, dupa care aplicaia urmrete versiunile noi care posibil au aprut pe pagina web a aplicaiei. Aplicaia caut radiostaia cerut de utilizator prin aplicarea serviciilor oferite de saiturile officiale ale radiilor ascult online. Dup care informaia i sunetul primit de la saitul oficial este redat la calculator prin conexiunile cu saitul staiilor radio .
uc Use Case Mo...

Accesarea statiei

Vizualizarea skin-urilot Setarea EQ

Lista de selectie include extend Selectarea statiei radio Salv area v ersiunilor noi extend extend Urmarirea v ersiunilor noi extend Efectuarea setarilor extend extend

extend

Accesarea aplicatiei

include

Efectuarea conexiunii

include

Conexiunea cu WWW al statiei

include Deschiderea exploratorului

User

Figura 1- Diagrama general a lucrrii unui radiou online. Selectarea setrilor Figura 2 este compus din Selectarea Equalizer-ului, o opiune care ne va permite s mregistrm piesa care la moment se va reda, selectarea ntr-o list aparte a staiilor favorite i opiunea de a skimba interfaa aplicaiei (se subnelege c vom putea schimba culorile interfeei, unele teme ale aplicaiei, etc.). Singura interfaa programului va fi mprit n 2 pri. n una din ele este reprezentat informaia general despre programul radio care la moment este accesat. Iar alt fereastr va afia o list de programe radio care le putem accesa i asculta. De asemenea vor fi i nite submeniuri mici cu ajutorul caror vom putea schimba setarile sunetului, un help, si un meniu care ne ajuta la crearea unei liste de radiostaii favorite. 4

uc Use Case Mo...

Selectarea formatului

Selectaria directoriului

User

include

include Introducerea denumirii

Inregistrarea pieseiinclude

Super Bass

extend extend Selectarea la lista de fav orit

Lista de skin-uri

Rap

extend

extend Selectarea EQ extend

extend

include

include Selectarea setarilor extend

Jazz

Selectarea Skin-urilor

extend

Rock

User

Figura 2 Diagrama Selectrii setrilor Setarea versiunii Figura 3, se efectueaz de aplicaie la accesarea acesteia. Aplicaia de la accesare verific daca pe pagina oficial nu a aprut o versiune mai noua. n caz c este o versiune mai nou, atunci este propus utilizatorului s o salveze i s o renoiasc, aceasta poate fi neglijat.

uc Use Case Mo...

Deschiderea paginii Web

include Legatura app cu brow serul Salv area v ersiunii extend

include

Setarea v ersionarii

User

Figura 3 diagrama Setrii versiunii Selectarea programului radio Figura 4 de se efectueaz de ctre utilizator prin fereastra principal din interfaa aplicaiei.
uc Use Case Mo...

Denumirea statiilor

Fereastra cu info de pe WWW

extend

include Selectarea statiei radio

User

Figura 4 Diagrama de Selectare a staiei radio.

Efectuarea sunetului Figura 5 este una din cele mai importante funcii ale aplicaiei pentru c redarea sunetului se va efectua numai dup ce se conecteaz aplicaia noastr la saitul staiei radio.
uc Use Case Mo...

Efectuarea conexiunii User

include

Conexiunea cu WWW al statiei

Figura 5 Diagrama Efectuare a conexiunii

4 Modelul structural Cu ajutorul modelului structural va fi reprezentat structura sistemului de control a versiunilor. La reprezentarea modelului structural va fi folosit diagrama claselor . Diagrama claselor Un obiect este o reprezentare a unei entiti din lumea real sau conceptual. Un obiect este un concept, o abstracie sau un lucru ce are un neles i limite bine definite n cadrul unei aplicaii. ntr-un sistem informatic, obiectele au trei caracteristici: stare; comportament; identitate. Starea unui obiect este una dintre condiiile posibile n care un obiect poate exista. Starea obiectului se modific n timp, i este definit de o mulime de atribute / proprieti, valorile acestor proprietilor i relaiile pe care obiectul le are cu alte obiecte din sistem. Identitatea reprezint faptul c fiecare obiect este unic, chiar i atunci cnd starea unui obiect este identic cu starea altui obiect. Clas reprezint descrierea unui grup de obiecte care au: proprieti/atribute; comportament; relaii cu alte obiecte; semantic comune. Clasele sunt abloane de creare a obiectelor. Fiecare obiect este o instan a unei clase. Obiectele vor avea o valoare pentru atributele definite de clas i accesul la operaiile sale se va realiza n maniera specificat de clasa. Diagramele de clase Figura 6 fac parte din categoria diagramelor statice. Ele descriu structura intern a sistemului informatic prin identificarea claselor, a atributelor i operaiilor acestora i a relaiilor dintre clase. Construcia diagramelor de clase are loc n faza de elaborare a sistemului informatic fiind cele mai importante din aceasta faz.

class Class Mo...

Options Adaugarea la favorit: int Select la favorit: int Selectarea EQ: int Skmbul de skin-uri: int

Selectarea statiilor radio Alegerea programului radio: int Interfata programului Efectuarea conexiunii Conexiunea cu WW al statiai: int Conection: int New Version: int Option: int Select: int

Urmarirea Versiunei Accesarea Explorer: int Salvarea & reinoirea aplicatiei: int

Figura 6 Diagrama claselor a aplicaiei RadioOnline

n diagrama claselor Figura 6, pot fi vzute cele 4 clase de baz a sistemului, aceste clase conin operaiile i opiunile care ne le ofer programul. Stereotipuri n timpul analizei, este necesar (dar nu n toate cazurile) de plasat pe categorii clasele proiectului n dependen de scopul acestora i funcia lor n sistem. Exist trei categorii primare, trei stereotipuri n UML care sunt utilizate la etapa de analiz: Boundary, Entity i Control. Clase de tip Boundary sunt clasele care sunt prezente ntre mediul extern al sistemului i mecanismul intern al sistemului. Servete ca o punte, ce leag aceste 2 nivele de abstractizare diferit. n timpul proiectrii sistemului, este necesar de ntrebat dac alte sisteme vor folosi printr-o invocare specific clasele din sistem. i dac da, atunci va fi necesar de preconizat interfee la aceste clase, din motive de ascundere a business logicii sistemului. n UML acest tip de stereotip se reprezint ca in Figura 3.2.

Figura 3.2 Stereotipul Boundary Clase de tip Entity sunt clase care dein informaia. Acestea eventual pot fi mapate ctre o tabela sau ctre cmpuri din baz de date (DB). O mare parte dintre substantivele gsite n evenimentele din cadrul diagramelor cazurilor de utilizare pot fi identificate ca clase Entity. n UML acest tip de stereotip se reprezint ca in Figura 3.3.

Figura 3.3 Stereotipul Entity Clase de tip Control sunt opionale, dar uneori necesare, sunt clase/obiecte care controleaz fluxul de date determinat de diagrama claselor. Acestea nu au nici o legtur cu business logica programului. Acestea coordoneaz alte obiecte prin intermediul fuxului de date. Pentru exemplu s presupunem c, un obiect de control va ti c nivelul de securitate al utilizatorilor trebuie verificat nainte de ca raportul s fie rulat. Obiectul Control nu va verifica nivelul de securitate sau va rula raportul, acesta va conine n sine secvena logic i regulile determinate de scenariu. El va spune unui alt obiect sa verifice nivelul de securitate al utilizatorului, i apoi va spune s ruleze raportarea. Obiectele Control nu vor aprea n secvena de evenimente. n UML acest tip de stereotip se reprezint ca in Figura 3.4.

Figura 3.4 Stereotipul Control Deci, Entity va conine informaia, clasele Control vor rspunde de business logic, iar clasele boundary trebuie s afieze i s primeasc informaia, pe lng toate acestea trebuie s minimizeze procesarea business. Urmnd aceste informaii voi construi diagrama (diagramele) claselor utiliznd stereotipuri.

10

analysis Business Process Mo...

Selectarea programului Radio

Selectarea setarilor

Urmarirea versiunii noi

Accesarea aplicatiei

Conexiunea cu www

User

Figura 7 Diagrama de clase a aplicaiei

n figura 7 sunt prezentate opiunile i posibilitile de baz a aplicaiei Radio on Line.

analysis Business Process Mo...

Inregistrarea piesei

Adauga la favorit

Select EQ

Selectarea skin-ului Selectarea setarilor

User

Figura 8 Diagrama de clase a Selectarea setrilor

n aceast diagram din Figura 8 am reprezentat opiunile care le putem accesa dac vom apela la Selectarea setrilor. Astfel aici vom putea influena la modul de redare a sunetului, la nregistrarea unor piese pe care vom dori, adaugarea in favorit a unor programe radio i sigur s schimbam vizualizrile interfeei.

11

analysis Business Process Mo...

Legatura app cu www

Setarea versiunii

Salvarea versiunii

User

Figura 9 Diagrama de clase Setarea versiunii

n Figura 9 vedem diagrama care explic setarea versiunii. n aplicaia noastr se face conexiune automat cu saitul oficial al aplicaiei pentru a verifica apariia unor noirii a versiunii. Dup care User0ul decide dac dorete renoirea.
analysis Business Process Mo...

Denumirea Statiilor

Selectarea programului radio

Info cu publicitate

User

Figura 10 Diagrama de clase Selectarea programului radio

n aceast diagram din Figura 10 este redat Selectarea programului radio din care se vede ca se alege programul dorit dintr-o list de programe. Odata accesat staia dorita pe fereastra interfeei va aparea i publicitate.

12

analysis Business Process Mo...

Efectuarea conexiunii User

Conexiunea cu www

Figura 11 Diagrama de clase Efectuarea conexiunii

n Figura 11 este reprezentat diagrama de clase Efectuarea conexiunii, n care am dorit s prezint ca aplicaia menine o conexiune cu saitul programului radio pentru a reda sunetele.

13

Concluzie: Realizarea acestei lucrri de laborator mi-a permis studierea Stereotipurilor Boundary,Control i Entity utiliznd instrumentul UML. n urma analizei acestui algoritm, am determinat paii care trebuie urmai pentru a efectua corect o diagrama UML. Efectund aceast lucrarea de laborator am analizat sistemul din mai multe puncte de vedere, astfel descoperind noile posibiliti ale sistemului. Stereotipurile n-ea permis s extindem, lrgim semantica UML, folosind stereotipurile este mai uor de neles lucrul i logica aplicaiei. La folosirea stereotipurilor nu trebuie s uitm de unele reguli cele mai importante fiind comunicarea ntre boundary, entity i control, adic actorul poate comunica doar cu boundary; boundary poate comunica doar cu control i actor; entity poate comunica doar cu control, control poate comunica cu toate cu excepia actor-ului. Aceste informaii m vor ajuta pe viitor la crearea unor diagrame mai corecte si mai precise in descrierea subiectului.

14

Bibliografie: Surs electronic : http://www.codeproject.com/Articles/8058/Applying-Robustness-Analysis-on-theModel-View-Con Surs electronic: http://members3.jcom.home.ne.jp/daruma_kyo/en/aboutooa/variousClasses.html Surs electronic: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/entity_control_ boundary_pattern_C4047897.html Surs electronic: http://calc.fcim.utm.md/upload/Ingineria%20Programarii.%20Indrumar%20de %20laborator.pdf Surs electronic: http://www.itzone.ro/articolDisplay.php?id=38&categorie_id=0

15