Facultatea Calculatoare, Informatic i Microelectronic

Catedra: Automatic i Tehnologii Informaionale

Disciplina: Analiza i Modelarea Sistemelor Informaionale

Lucrarea de laborator
Nr. 2
Tema: Familiarizarea cu tehnologiile, metodologiile i
principiile elaborrii modelelor n baza blocurilor constructive
ale limbajului UML i CASE Rational Rose

I. Scopul lucrrii:
1.Studierea prii teoretice i verificarea cunotinelor n mediul instrumentului CASE
Rational Rose.
2.Aprecierea imoprtanei tehnologiilor, metodologiilor i principiilor elaborrii modelelor n
ingineria softului, evideniind aspectele principale prin enumerare n ordine de importan.
3.Studierea notaiei i descrierea destinaiei elementelor/componentelor ale blocurilor
constructive UML.
4.nsuirea principiilor de creare, modificare i salvare a respectivelor modele-diagrame
elaborate.
5.Studierea i evidenierea respectrii cerinelor metodologice din exemplul reprezentat n
partea teoretic a acestui ndrumar.
6.Analiza propriului sistem i determinarea cerinelor i precedentelor, descriind succint i
elocvent scenariul (pas cu pas) cu exemple concrete.
7.Concluziile.
II. Consideraii teoretice generale.
Cerinele generale fa de metodologii i tehnologii n ingineria softului.
Metodologiile, tehnologiile si mijloacele instrumentale de proiectare (CASE- mijloace)
alcatuiesc baza proiectarii oricarui SI. Metodologia se realizeaza prin tehnologiile concrete si
standardele care le sustin, metode si mijloace instrumentale care asigura indeplinirea proceselor
ciclului vital.
Tehnologia proiectarii se defineste ca un intreg din trei componente:
- procedura pas-cu-pas, care defineste succesiunea operatiilor tehnologice de proiectare (fig.
1);
- criteriile si regulile, care se folosesc p/u aprecierea a rezultatelor de indeplinire a operatiilor
tehnologice;
- notatii (a mijloacelor grafice si textuale), folosite p/u descrierea sistemului proiectat.

Fig.1. Reprezentarea operatiei tehnologice de proiectare

Instruciile tehnologice, care alcatuiesc continutul general al tehnologiei, trebuie sa fie alcatuite
din descrierea succesiunii a operatiilor tehnologice, conditii, in dependenta de care se efectuiaza una
sau alta operatie, si descrierea insusi a operatiilor.
Tehnologia de elaborare: analiza, proiectare, dezvoltare si spriginul a SI ar trebui sa satisfaca
urmatoarele cerinte generale:
1.
Tehnologia ar trebui sa sprigine suport plin a ciclului vital al softului;
2.
Tehnologia ar trebui s furnizeze realizarea scopurilor garantat de dezvoltare a SI cu
calitatea fix si n timpul stabilit;
3.
Tehnologia ar trebui s furnizeze un prilej de realizare de proiectele mari pe msura ce
subsistemele (adica prilejul de decompozitie a proiectului pe componente, care au fost dezvoltate de
grupuri de executori de numr limitat cu integrarea ulterioara de componente). Experienta de elaborare
a SI mari, arata ca pentru sporire de eficient a lucrului este necesar de a separa proiectul pe parti slab
legate intre ei pe date si functii a unor subsisteme. Realizarea a subsistemelor ar trebui s fie
ideplinita de grupurile separate de experti. Astfel este necesar de a furniza coordonarea executarii a

proiectului comun pentru a exclude duplicatul intre grupuri de proiectare care poate sa apare din cauza
prezentei de datele comune si functii;
4.
Tehnologia ar trebui s furnizeze un prilej de dirijare a ocupatiei pe proiectare a
subsistemelor separate de grupurile mici ( 3-7 persoane). Aceasta este cauzat de principiile de
controlare a colectiveului, si sporirea de productivitate pe seama minimizatiei de numr de
comunicarile externe;
5.
Tehnologia ar trebui s furnizeze timpul minim de receptie a SI eficient. ntrebarea nu
este despre termene de realizare a intregului SI, ci despre termene de realizare a subsistemele separate.
Realizarea SI ca ntregul n timp scurt poate sa ceara atractie a numrului mare de programatori, astfel
incit efectul poate fi mai slab, dect la ndeplinirea ntr-un timp mai scurt a subsistemelor aparte cu un
numar mai mic de programatori. Practica arata, ce chiar la prezenta n ntregime a proiectului complet,
introducere merge consecvent pe subsisteme separate;
6.
Tehnologia ar trebui sa furnizeze un prilej unei configuratiei a proiectului, dirijnd
versiunile proiectului si a componentelor sale, un prilej de eliberarea automata a documentatiei de
proiect si sincronizarea ei cu versiuni a proiectului;
7.
Tehnologia ar trebui sa furnizeze independenta realizarilor de proiect de mijloacele
realizarii a SI (sisteme de gestiune a bazelor de date (SGBD), sisteme operaionale, limbaje si sisteme
de programare);
8.
Tehnologia ar trebui sa fie mentinuta cu complexul coordonat de Case-mijloace,
furnizatori de automatizarea proceselor care se indeplinesc pe toate scene ciclului vital.
Aplicatie reala de oricare tehnologie de proiectare, elaborarea si insotirea a SI n organizatie
concreta si proiectul concret este imposibila fara elaborarea a unui sir de standarde (reguli, ntelegeri)
care ar trebui sa fie observate de toti participanti a proiectului. La aceste standarde fac parte
urmatoarele:
- standardul proiectarii;
- standardul de inregistrare a documentatiei de proiectare;
- standardul interfeisului al utilizatorului.
Standard de proiectare ar trebui sa fondeze:
1.
Configuratii de modelele necesare (diagrame) pe fiecare scena a proiectului si gradul lor
de detalizare;
2.
Regulile de fixare a deciziilor de proiect pe diagrame, incluznd: reguli de denumire a
obiectelor
3.
(incluzind intelegeri pe terminologie), un set de atribute pentru toate obiecte si regulile
lor de oformare la fiecare nivel, regulile de oformare a diagramelor, incluyind cererile la forme i
dimensiunile a obiectelor, etc.
4.
Cererile privind configuraiile locurilor de munca a elaboratorilor, incluznd opiunile
sistemului de operare, opiunile mijloacelor CASE, opiunile generale a proiectului, etc.
5.
Mecanismul asigurarii lucrului in colaborare asupra proiectului, i desigur regulile de
integrare a subsistemelor a proiectului, regulile de intreinere a proiectului in starea similara pentru toi
elaboratori (reglamentul schimbului a informaiei de proiect, mecanismul fixrii a obiectelor comune,
etc), regulile de verificare a rezultatelor de proiect la noncontrazicere, etc.
Standardul oformrii documjentaiei de proiect trebuie sa stabileasc:
1.
Complectatea, componena i structura documentaiei pe fiecare nivel al proiectarii;
2.
Cerinele privid oformarea acestei documentaiei( incluznd cerinele la coninutul a
compartimentelor, subcompartimentelor, punctelor, tabelelor, etc.);
3.
Regulile de pregatire, de privire, inelegere i acceptare a documentaiei cu indicarea
limitelor maxime pentru fiecare nivel;
4.
Cerinele la setrile sistemului de editare, folosite n funcie de mijloc integrat pentru
pregatirea documentaiei;
5.
Cerinele la setrile a mijloacelor CASE pentru asigurarea pregatirii documentaiei n
corespundere cu cerinele stabilite.
Standardul interfeei a utilizatorului trebuie s stabileasc:

1.
Regulile de oformare a ecranului (rifturi i palitra de culori), componena i plasarea
ferestrelor i elementelor de rulare;
2.
Regulile de folosire a tastaturii i a mausului;
3.
Regulile de oformare a textelor de ajutor;
4.
Setul de mesaje standarde;
5.
Regulile de prelucrare a reaciei utilizatorului.
Una din inelegerile de baz a metodologiei de proiectare a SI este nelegerea ciclului vital a
softului ei. Ciclul vital a softului (CVS) e un proces nentrerupt, care se incepepe de la momentul
hotrrii despre necesitatea crerii lui i se termin n momentul excluderii lui totale din exploatare.
Documentul normativ de baz, care reglamenteaz CVS este standardul internaional
ISO/IEC 12207 [1,2] ( ISO International Organization of Standardization, IEC International
Electrotechnical Commision). El determin structura CV, care conine procese, acciuni i probleme,
care trebuie sa fie rezolvate in timpul crerii softului.
2. Analiza exemplului elaborrii modelelor serviciului bancar pentru clieni (ATM)
Diagrama variantelor de utilizare (Use Case)-- Diagrama ce descrie sistemul ca unul intreg,
integru. Aici se contin actori (care executa anumite roluri, functii) si precedente (functiile propriu-zise,
ce pot fi obinute) si relatii dintre actori.
Deseneaza PolyLine
Deseneaza Bezier

Deseneaza Spline

Deseneaza Rectangle

Deseneaza Arc

Utilizator
Deseneaza Circle

Deseneaza Line

Deseneaza Horizontall
Dimension

Deseneaza Ellipse
Deseneaza Verticall
Dimension

Figura 1 - Diagrama Use Case (Creeaz figur)

Descrierea cazurilor din diagrama Use Case Creaz figur, care reprezentat n figura 1.
Deseneaz Line ne permite de a desena o line;
Deseneaz Rectangle permite desenarea unui dreptunghi;
Deseneaz Bezier permite desenarea unei curbe bezier;
Deseneaz PoliLine permite desenarea unei consecutiviti de linii drepte;
Deseneaz Spline permite desenarea spline-urilor;
Deseneaz Arc permite desenarea unui arc;
Deseneaz Circle permite desenarea unui cerc;
Deseneaz Ellipse permite desenarea unei elipse;
Deseneaz Verticall Dimension permite desenarea unei cotri verticale;
Deseneaz Horizontall Dimension permite desenarea unei cotri horizontale;
Diagrama de activitatidescrie cursul functionalitatii sistemului.
Ele pot fi folosite pentru a ilustra cursul evenimentelor printr-o precedenta. Aceste diagrame
definesc unde incepe cursul lucrului si unde sfirseste, ce activitati au loc pe parcursul cursului de lucru,
si in ce ordine activitatile au loc.

Utilizator

Interfata de desenare

Stiv a de obiecte

Obiectul

Start

Initializarea toturor
obiectelor

Pornirea
aplicatiei

Selectarea obiectului
pentru desenare

Initializare

Prezentarea
obiectelor

Desenarea
obiectului

Trimiterea mesajului
de desenare

End

Analiza mesajului de
desenare

Deseneaza
obiectul

Afisarea grafica a
obiectului desenat

Fig.2 Diagrama de activitati pentru desenarea unui obiect

In aceasta diagrama putem veadea cursul obiectelor. Cursul obiectelor ne arata care obiecte
sunt folosite sau create de o activitate si cum obiectul isi schimba starea parcurgind cursul de lucru.
Liniile aici se numesc tranzitii, arata cum o activitate duce la alta in proces. Daca este nevoie putem
plasa mai multe detalii pe tranzitii, descriind circumstantele sub influenta carora tranzitia poate sau nu
poate avea loc si ce actiune va fi luata in timpul tranzitiei.
Diagrama de activitati nu este nevoie de creat pentru orice curs de lucru, dar ele(diagramele de
activitati) sun tun puternic instrument de comunicare, in special la cursu de lucru mare si complex.
Diagrama de secventaarata cursul functionalitatii intr-o precedenta.
Suprafata de
desenare : panel

Stiva de obiecte :
GraphicsCollection

Obiectul :
CadObject

: Sistemul
1: Mesaj de redesenare
2: Redesenare

3: Trimiterea mesajului de desenare

4: Procesare

5: mesajul de desenare
6: Redeseneaza
7: Deseneaza

Figura 3 Redesenarea suprafetei de lucru ( diagrama de secven )

Aceasta diagrama de secventa arata cursul procesarii intr-o precedenta Redesenare. Sus in
diagrama sunt obiectele de care are nevoie sistemul pentru a realiza precedenta. Fiecare sageata
reprezinta un mesaj transmis intre actori si obiect sau obiect si obiect pentru a indeplini
functionalitatea necesara. Utilizatori pot vedea in aceste diagrame specificul procesarii afacerii.
Analistii vad cursul procesarii. Dezvoltatorii vad obiectele ce trebuie create si operatiile pentru aceste

obiecte. Inginerii ce asigura calitatea pot vedea detaliile procesului si sa dezvolte teste pentru
procesare.
Diagrama de colaborarearata exact aceeasi informatie ca si cea de secventa. Totusi,
Diagrama de colaborare arata aceasta informatie in alt mod si cun scop diferit. Diagrama in fig.4 este o
diagrama de colaborare.
4: Procesare

2: Redesenare

Stiva de obiecte :
GraphicsCollection

Suprafata de
desenare : panel
3: Trimiterea mesajului de desenare

7: Deseneaza
5: Mesaj de desenare

1: Mesaj de desenare

6: Redeseneaza

Obiectul
CadObject

: Sistemul

Fig.4 diagrama de colaborare

Diagrama claselor arata interactiunea intre clase in sistem. Clasele pot fi vazute ca niste
prototipuri pentru obiecte. Clasele contin informatie si comportament care conduce cu aceasta
informatie
EventArgs

ISerializab
le

Serialization EventArgs
formatter : IFormatter
stream : Stream
fileName : string
errorFlag : bool

Persist Window State

ownerForm : Form
registryPath : string
windowState : FormWindowState
allowSaveMinimized : bool

SerializationEventArgs()

PersistWindowState()
OnResize()
OnMove()
OnClosing()
OnLoad()

DocData
updateTitle : bool
docName : string
fileDlgFilter : string
registryPath : string
size : Size

DocManager
_dirty : bool
fileName : string
docName : string
registryPath : string
fileDlgInitDir : string

DocData()
GetObjectData()

DocManager()
SetData()
Empty()
SetCaption()
NewDocument()
CloseDocument()
SaveDocument()
OpenDocument()
RegisterFileType()

Figura 5 Clasele pachetului Managerul Documentului

Aceasta diagrama Managerul documentului conine clasele destinate lucrului cu documentul,
clasa DocManager ne ofer acele funcii necesare de lucru cu documentul, clasa
SerializationEventArgs este destinat lucrului cu fluxul de date destinate serializrii (operaie necesar

la salvarea datelor ), clasa PersistWindowState ne ofer posibilitatea de a pstra starea ferestrei

sistemului si clasa DocData destinat pstrrii proprietilor documentului.
Diagrama de staredistribuie un mod de modelare variata a starilor in care un obiect poate
exista. In timp ce diagrma claselor arata imaginea statica a claselor si relatiilor dintre ele, diagrama de
stare sunt utilizate la modelarea comportamentul dinamic a sistemului. Aceste tipuri de diagrame sunt
folosite extensiv in construirea sistemelor in timp-real. Rational Rose poate chiar genera codul intreg
pentru un sistem in timp-real din diagramele de stare.
Start
Show Element
Draw

Edit
Cut

Copy

Paste

Modify

Save document
Load
image

Read
image

Save image
as a bmp

Zoom

End

Fig.6 diagrama de stare

In aceasta diagram noi putem vedea starile in care trece sistemul pentru realizarea functiilor.

Diagrama componentelorarata viziunea fizica a modelului, adica componentele software in

sitem si relatiile dintre ele. Sunt 2 tipuri de componente in diagrama: executabile si biblioteci.
program.exe

Edit obiect.h

Stiva de obiecte.h
Graphics.h

Windows.h

Edit obiect.cpp
Stiva de obiecte.cpp

Graphics.cpp

Windows.cpp

Fig.7 diagrama componentelor

Componentele hasurate sunt numite corpul pachetului. El reprezinta corpul fisierului (.cpp).
Componentele nehasurate sunt numite specificatia pachetului. Specificatia reprezinta fisierul antet (.h)
in C++.
Componentele sunt unite prin sageti intrerupte aratind relatiile de dependenta intre ele.
Diagramele componentelor este folosita de oricine e responsabil de compilarea sistemului.
Diagramele ii vor spune acelui individ in ce ordine componentele necesita a fi compilate.
Diagrama de amplasamentschema fizica a retelei si unde vor fi amplasate componentele
variate. Aceast diagrama este folosita de managerii de proiect, utilizatori, arhitecti, si echipa de
amplasament pentru a intelege amplasamentul fizic a sistemului si unde vor fi amplasate variate
subsisteme.
Scaner

Tastiera
Printer

Display

Calculatorul

Mouse

Figura 8 diagrama de amplasare

Toate aceste diagrame impreuna descriu sistemul din diferite perspective. Deci, aceste
diagrame sunt foarte importante in modelarea vizuala a sistemelor.

Concluzie UML este un limbaj foarte puternic daca este folosit de persoane, echipe bine
familiarizate cu el si modelarea vizuala. Instrumente ca R Rose pot genera scheletul codului
proiectului sau invers poate genera diagramele din cod(Re-Engineering).
Pachetele instrumentale UML(spre exemplu Rational Rose ) conin mijloace instrumentale ce
uor permit crearea modelelor UML i generarea codului n diferite limbaje de programare. Majoritatea
pachetelor arat informaia detailat despre obiectul ales. E necesar numai un click pe pictograma lui.
Intrnd n comand, se observ setul de operaii ce se pot efectua asupra obiectului i se observ
diagrama de aciuni consecutiv. Limbajele de modelare servesc i pentru proiectare invers a
sistemelor deja existente.
UML n continuu se dezvolt, de exemplu, n versiunea 1.3 s-au inclus o serie de mbuntiri,
la care se refer noile construcii semantice, citirea perfecionat a documentelor i de asemenea
susinerea interfeei XMI (XML Metadata Interchange). S-au exclus erorile detectate anterior. Mai
departe creatorii intenioneaz s propun interfee pentru tehnologiile CORBA, Enterprise JavaBeans
XML, mijloace de control asupra versiunilor modelelor i schimbul reciproc cu diagrame .
Una din cele mai importante tendine n lumea UML este stereotipizarea. Aceast metod
permite extinderea vocabularului fundamental al UML. Utiliznd blocurile de construcie n schema
UML se poate primi un nou cod ce descrie procese concrete. Codul stereotipic se folosete pentru
identificarea fiierelor executabile i fizice, pentru crearea i distrugerea exemplarelor claselor, pentru
generarea programelor trigger, ce reacioneaz la apariia unui eveniment. Programatorii pot lega
pictogramele la stereotipurile pentru modificarea modelului UML, innd cont de particularitile
operaiilor specifice.
Bibliografie:
1.
Saru Daniela, Ioni Anca D. Sisteme de programe orientate pe
obiecte.Buc.All.2000,/UTM:004.4:004.43;s24/
2.
Ioni Anca Daniela. Modelarea UML n ingineria sistemelor de programe. Buc.: All.
2003
3.
Analiza
si
gestiunea
sistemelor
informatice
complexe,http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme/
4.
UML Applied,Object Oriented Analysis and Design Using the UML,
www.ariadnetraining.co.uk
5.
http://www.interface.ru/fset.asp?Url=/rational/suite/Suite.htm