Caiet de specificatii Versiunea A

Autor(i) : Iles Ovidiu Ioan

Borse Florentina Referinta : UML.doc
Cheregi Florin

Statut : Schita Versiune : A

Data : 01/10/2005 Modificari : -

Caiet de specificatii

Referinta :
UML 1/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

CUVINTE CHEIE

• UML
• View
• Diagrama

Istoricul actiunilor efecutate asupra documentului

Nume Data Versiune Actiune(i)
Iles Ovidiu Ioan 01/12/2005 A Creare
Toti 21/12/2005 B Verificare finala

Referinta :
UML 2/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

Cuprins

1. Aparitie si evolutie..............................................................................................4
2. Principalele părţi ale UML....................................................................................4
2.1. View-uri.......................................................................................................4
2.2. Diagrame.....................................................................................................6
3. Versiuni UML....................................................................................................11
4. Tool-uri pentru generarea diagramelor UML.........................................................12
In functie de interactiunea cu IDE (Integrated Development Environment).................12
4.1. Instalarea unui plugin in Eclipse....................................................................13
4.2. Generare cu aplicatia Altova Umodel 2009......................................................17
5. Diagrame statice vs. Dinamice............................................................................22
6. Notatii UML:.....................................................................................................24
7. Specificatii de gestiune a proiectului (Repartizarea sarcinilor si a taskurilor pe membrii
echipei)...............................................................................................................25
7.1. Working package – Management (Gestiune)...................................................25
7.2. Time Planning (planificare in timp)................................................................26
8. Specificatii administrative..................................................................................26
8.1. Datele de livrare ale aplicatiei/Documente administrative furnizate....................26
8.2. Bibliografie/Referinte/Documentatie..............................................................27

Referinta :
UML 3/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

1. Aparitie si evolutie

UML este un limbaj vizual de modelare.El nu este încă un limbaj vizual de programare,
deoarece nu dispune de întreg sprijinul semantic şi vizual pentru a înlocui limbajele de
programare. Limbajul este destinat vizualizării, specificării, construirii şi documentării
sistemelor de aplicaţii, dar are limitări în ceea ce priveşte generarea codului. UML reuneşte
cele mai bune tehnici şi practici din domeniul ingineriei programării, care şi-au dovedit
eficienţa în construirea sistemelor complexe.
UML este un element fundamental pentru Model-Driven Architecture ®, care reprezinta
legaturile dintre mediul de afaceri si mediul de programare, prin modelarea arhitecturala şi
aplicarea lor in dezvoltare, implementare, întreţinere şi evoluţie.

2. Principalele părţi ale UML

Principalele parti ale UML sunt:
• Vederile (View) – surprind aspecte particulare ale sistemului de modelat. Un view este
o abstractizare a sistemului, iar pentru construirea lui se folosesc un număr de
diagrame.

• Diagramele – sunt grafuri care descriu conţinutul unui view. UML are nouă tipuri de
diagrame, care pot fi combinate pentru a forma toate view-urile sistemului.

• Elementele de modelare – sunt conceptele folosite în diagrame care au corespondenţă

în programarea orientată-obiect, cum ar fi: clase, obiecte, mesaje şi relaţii între
acestea: asocierea, dependenţa, generalizarea. Un element de modelare poate fi folosit
în mai multe diagrame diferite şi va avea acelaşi înteles şi acelaşi mod de reprezentare.

• Mecanismele generale – permit introducerea de comentarii şi alte informaţii despre un

anumit element.

2.1. View-uri

Modelarea unui sistem poate fi o muncă foarte dificilă. Ideal ar fi ca pentru descrierea
sistemului să se folosească un singur graf, însă de cele mai multe ori acesta nu poate să
surprindă toate informaţiile necesare descrierii sistemului. Un sistem poate fi descris luând în
considerare diferite aspecte:
• Funcţional: este descrisă structura statică şi comportamentul dinamic al sistemului;
• Non-funcţional: necesarul de timp pentru dezvoltarea sistemului
• Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod;

Aşadar pentru descrierea unui sistem sunt necesare un număr de view-uri, fiecare
reprezentând o proiecţie a descrierii intregului sistem şi care reflectă un anumuit aspect al sau.
Fiecare view este descris folosind un număr de diagrame care conţin informaţii relative
la un anumit aspect particular al sistemului. Aceste view-uri se acoperă unele pe altele, deci

Referinta :
UML 4/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

este posibil ca o anumită diagramă să facă parte din mai multe view-uri.

Figura 1 View-urile din UML.

View-ul cazurilor de utilizare (Use-case View)

Acest view surprinde funcţionalitatea sistemului, aşa cum este ea percepută de actorii
externi care interacţionează cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme.
Cei interesaţi de acest view sunt deopotrivă clienţii, designerii, dezvoltatorii dar şi cei
care vor realiza testarea şi validarea sistemului.

View-ul logic (Logic View)

Spre deosebire de view-ul cazurilor de utilizare, un view logic “priveşte” înăuntrul
sistemului şi descrie atât structura internă a acestuia (clase, obiecte şi relaţii) cât şi
colaborările care apar când obiectele trimit unul altuia mesaje pentru a realiza funcţionalitatea
dorită.
Structura statică este descrisă în diagrame de clasă, în timp ce pentru modelarea
dinamicii sistemului se vor folosi diagramele de stare, de secventă, de colaborare sau de
activitate. Prin urmare, cei care sunt interesaţi de acest tip de vizualizare a sistemului sunt
designerii şi dezvoltatorii.
View-ul componentelor (Component View)
Componentele sunt module de cod de diferite tipuri. În funcţie de conţinutul lor acestea
pot fi: componente care conţin cod sursă, componente binare sau excutabile.
View-ul componentelor are rolul de a descrie componentele implementate de sistem şi
dependenţele ce există între ele, precum şi resursele alocate acestora şi eventual alte
informaţii administrative, cum ar fi de exemplu un desfaşurător al muncii de dezvoltare. Este
folosit în special de dezvoltatorii sistemului, iar în componenţa sa intră diagrame ale
componentelor.

View-ul de concurenţă (Concurent View)

Sistemul poate fi construit astfel încât să ruleze pe mai multe procesoare. Acest aspect,
care este unul nonfuncţional, este util pentru o gestionare eficientă a resurselor, execuţii
paralele şi tratări asincrone ale unor evenimente din sistem, precum şi pentru rezolvarea unor
probleme legate de comunicarea şi sincronizarea theadu-urilor.
Cei care sunt interesaţi de o astfel de vizualizare a sistemului sunt dezvoltatorii şi

Referinta :
UML 5/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare,
secventă, colaborare şi activitate) şi diagrame de implementare (ale componentelor sau de
desfăşurare).

View-ul de desfăsurare (Deployment View)

Desfăşurarea fizică a sistemului, ce calculatoare şi ce device-uri (numite şi noduri) vor
fi folosite pentru realizarea efectivă a implementării, cum sunt acestea conectate, precum şi ce
componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe
fiecare calculator), toate sunt surprinse în view-ul de desfăşurare.
Aceast tip de vizualizare a sistemului prezintă interes sunt dezvoltatori, integratorii de
sistem şi cei care realizează testarea sistemului, iar pentru construirea view-ului este folosită
diagrama de desfăşurare.

2.2. Diagrame

Diagramele sunt grafuri care prezintă simboluri ale elementelor de modelare aranjate astfel
încât să ilustreze o anumită parte sau un anumit aspect al sistemului. Un model are de obicei
mai multe diagrame de acelaşi tip. O diagramă este o parte a unui view specific, dar există
posibilitatea ca o diagramă să facă parte din mai multe view-uri, în funcţie de conţinutul ei. În
UML sunt nouă tipuri de diagrame pe care le vom prezenta în cele ce urmează.

Diagrama cazurilor de utilizare (Use Case Diagram)

Descrie modul de functionare al aplicatiei. Diagrama prezintă actorii externi (ex. client,
server) , cazurile de utilizare identificate precum şi conexiunile dintre actori. Nu descrie
modul interior de functionare al aplicatiei. Un exemplu de diagramă a cazurilor de
utilizare este prezentată în figura 2.

Figura 2 O diagrama a cazurilor de utilizare dintr-un sistem de asigurari.

Diagrama claselor (Class Diagram)

O diagramă a claselor prezintă structura fizică a claselor identificate în sistem. Clasele
reprezintă “obiecte” gestionate de sistem; clasele pot fi legate în mai multe moduri: asociate
(conectate între ele), dependente (o clasa depinde/foloseşte o altă clasă), specializate (o clasă
este specializarea altei clase) sau împachetate (grupate împreună în cadrul unei unitaţi). Toate
aceste relaţii se materializează în structura internă a claselor în atribute şi operaţii.

Referinta :
UML 6/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

Diagrama este considerată statică, în sensul că este validă în orice moment din ciclul de
viaţă al aplicatiei. Un exemplu de diagramă a claselor este prezentat în figura 3.

Figura 3 Diagrama a claselor.

Diagrama obiectelor (Object Diagram)
Acest tip de diagramă este un variant al diagramei claselor care în locul unei clase
prezintă mai multe instanţe ale ei. Diagrama obiectelor foloseşte aproape aceleaşi notaţii ca şi
diagrama claselor cu două mici diferenţe: obiectele sunt scrise subliniat şi sunt vizualizate
toate instantele relaţiei (vezi figura 4).
Deşi nu este la fel de importantă ca diagrama claselor, cea o obiectelor este folosită
pentru exemplificarea unei diagrame a claselor de complexitate mare, permiţând vizualizari
ale instanţelor actuale şi a relaţiilor exact aşa cum sunt ele realizate. Mai poate fi folosită ca o
parte a diagramelor de colaborare, în care sunt vizualizate colaborările dinamice existente în
cadrul unui set de obiecte.

Referinta :
UML 7/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

Figura 4 O diagrama a claselor si o diagrama a obiectelor (instantele claselor).

Diagrama de stare (State Diagram)
O stare este de obicei un complement al descrierii unei clase. O diagramă de stare
prezintă toate stările prin care trece un obiect al clasei precum şi evenimentele care-i cauzează
modificările de stare. Modificarea stării se numeşte tranziţie. Un exemplu de diagramă de
stare este prezentat în figura 5.

Figura 5 O diagrama de stare pentru un ascensor.

Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru
acelea care au un număr de stări bine definit iar comportamentul clasei este afectat şi
modificat de acestea.

Diagrama de secvenţă (Sequence Diagram)

O diagramă de secvenţă prezintă colaborarea dinamică între un număr de obiecte (vezi
figura 6), mai precis secvenţele de mesaje trimise între acestea pe măsura scurgerii timpului.
Obiectele sunt văzute ca linii verticale distribuite pe orizontală, iar timpul este
reprezentat pe axa verticală de sus în jos. Mesajele sunt reprezentate prin săgeţi între linile
verticale ce corespund obiectelor implicate în mesaj.

Referinta :
UML 8/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

Figura 6 Diagrama de secventa pentru un server de imprimanta.

Diagrama de colaborare (Collaboration Diagram)
Această diagramă surprinde colaborarea dinamică între obiecte, într-o manieră similară
cu a diagramei de secvenţă, dar pe lângă schimbul de mesaje (numit şi interacţiune) prezintă
obiectele şi relaţiile dintre ele (câteodată referite ca şi context).
Cum decidem ce tip de diagramă să folosim? Dacă cel mai important aspect este timpul
sau secvenţa de mesaje vom folosi diagrama de secvenţă, dar dacă trebuie scos în evidentă
contextul, vom apela la o diagramă de colaborare.
Desenarea unei diagrame de colaborare se face similar cu a unei diagrame a obiectelor.
Mesajele vor fi reprezentate prin săgeţi între obiectele implicate în mesaj şi pot fi însoţite de
etichete care specifică ordinea în care acestea vor fi transmise. De asemenea se pot vizualiza
condiţii, iteraţii, valori returnate, precum şi obiectele active care se execută concurent cu alte
obiecte active (vezi figura 7).

Figura 7 O diagrama de colaborare pentru un server de imprimanta.

Diagrama de activitate (Activity Diagram)
O diagramă de activitate prezintă fluxul secvenţelor de activitaţi, ca în figura 8, şi este
de obicei folosită pentru a descrie activitaţile realizate în cadrul unei operaţii, folosind dacă
este cazul decizii şi condiţii.
Diagrama conţine stări de acţiune (action states), şi mesaje care vor fi trimise sau

Referinta :
UML 9/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

recepţionate ca parte a acţiunii realizate.

Figura 8 O diagrama de activitate pentru un server de imprimanta.

Diagrama componentelor (Component Diagram)
O diagramă a componentelor prezintă structura fizică a codului în termenii
componentelor de cod, realizând o mapare de la view-ul logic la view-ul componentelor. O
componentă poate să conţină un cod sursă sau poate să fie într-o forma binară sau executabilă.
În cadrul diagramei vor fi ilustrate şi dependenţele dintre componente, ceea ce permite o
vizualizare simplă a componentelor care vor fi afectate de modificarea uneia dintre ele.

Figura 9 O diagrama a componentelor.

Diagrama de desfăşurare (Deployment View)

Arhitectura fizică pe care va fi implementat sistemul, calculatoarele, device-urile
(referite ca nodurile sistemului), împreună cu conexiunile dintre ele, vor putea fi prezentate în
cadrul unei diagrame de desfaşurare. Componentele şi obiectele executabile sunt alocate în
interiorul nodurilor, ceea ce ne va permite o vizualizare a unitaţilor care se vor executa pe

Referinta :
UML 10/27
WPMGT.Spec.001.C
 Caiet de specificatii Versiunea A

fiecare nod.

Figura 10 O diagrama de desfasurare care prezinta structura fizica a sistemului.

3. Versiuni UML
Versiune Data Aparitiei Descriere
a
1.4 09-2001 Cea mai importanta schimbare adusa de UML 1.4 consta in adaugarea profilurilor,
ceea ce permite colectarea unui grup de extensii intr-un ansmblu coherent.
Documentatia UML contine doua exemple de profiluri. Totdata , formalismul
definirii de stereotipuri a crescut si elementele modelului au putut avea mai multe
stereotipuri, in timp ce in UML 1.3 exista unul singur.
S-a lucrat asupra vizibilitatii pachetelor Java in metamodele si asupra marcarii
asincronismelor prin sageti in diagrame de secventa.
2.0 08-2005 Una din cele mai importante schimbari este cea legata de tipurile de diagrame.
Diagramele de obiecte si diagramele de pachete devin diagrame oficiale.
Diagramele de colaborare devin diagrame de comunicare. In aceasta versiune sunt
introduce, de asemenea, noi tip de asamblu a interactiunilor, timing si structuri
composite.
Atributurile si asocierile unidirectionare devin doua notatii esential diferite pentru
a reprezenta conceptul sub-adiacent de proprietate. S-au adaugat noi cuvinte cheie
pentru dependente. Cuvintele cheie <<parameter>> si <<local>> nu se mai
utilizeaza.
Diagrame de secventa:
Modificarea cea mai importanta este notatia cadrelor de interactiune, care permite
gestionarea structurilor interative, conditionale si a altor structuri de control a
comportamentului. Puteti exprima aproape in intregime algoritmii in diagramele
de secventa. Vechile marcaje de iteratii si notatiile lor au fost abandonate. Antetele
de linii de viata nu mai sunt instante, acestea fiind definite prin termenul
participant. Diagramele de colaborare se numesc acum diagrame de comunicare.

Referinta :
UML 11/27
WPMGT.Spec.001.C
 Caiet de specificatii Versiunea A

Referitor la diagramele de clase: concept avansate

Stereotipurile sunt definite de o maniera mai stricta. In consecinta, exista cuvinte
cheie pentru a define expresiile intre ghilimele, numai unele dintre acestea din
urma fiind stereotipuri. In diagramele de obiecte, instantele sunt acum specificatii
de instante. Clasele pot solicita interfete si le pot realiza. Clasificarea multipla
utilizeaza ansamblu de generalizare pentru a regrupa generalizarile. Componentele
nu mai sunt reprezentate printr-un simbol special. Obiectele active au linii duble
vertrical in loc de linii groase.
Diagramele de stare
Daca UML 1 facea distinctia intre actiuni si activitati, UML 2 numeste cele doua
activitati si utilizeaza acest termen in toate cazurile.
Diagramele de activitati
UML 1 trata diagramele de activitati ca pe un caz particular al diagramelor de
stare. UML 2 a rupt legatura intre acestea si a suprimat regulile de corespondenta a
ramificatiilor si jonctiunilor pe care le instaurase UML 1. Au aparut noi notatii,
printre care acelea de semnale temporare si de acceptare, paramatri, specificatii de
jonctiune, conectori, transformatori de fluxuri, greble de sub-diagrame, regiuni de
expansiune si terminatii de fluxuri. UML 1 considera mai multe fluxuri de intrare
intr-o activitate ca pe o fuziune implicita, in timp ce UML 2 le trateaza ca pe o
jonctiuni implicita. Pentru a evita confuziile, recomandam utilizarea fuziunilor si
jonctiunile explicite in diagramele de activitati.
2.1 04-2006 Modificari minore fata de versiunea UML 2.0 - corecţii şi îmbunătăţiri de
consistenţă.
2.1.1 02-2007 Modificari minore fata de versiunea UML 2.1
2.1.2 11-2007 Modificari minore fata de versiunea UML 2.1.1
2.2 02-2009 Imbunatatirea aduse numeroaselor probleme de consistenta si adaugarea unor
clarificari la UML 2.1.26

4. Tool-uri pentru generarea diagramelor UML

Exista mai multe tipuri de programe utilizate.

In functie de tipul licentei acestea se impart in :

• Freeware (soft gratuit) - care sunt puse la dispozitia tuturor utilizatorilor. Ex.:
StarUML, UMLet, ArgoUML .

• Commercialware (contra cost) – profesionale, prezinta un set mai mare de optiuni

pentru realizarea diagramelor. Ex.: Altova Umodel, Edraw UML Diagram.

In functie de interactiunea cu IDE (Integrated Development Environment)

• Independente de IDE. Ex.: Altova Umodel, StarUML.

 Altova Umodel - > OS: Microsoft Windows

- > v. 2011 Service Pack 1 (SP1)

 StarUML - > OS: Microsoft Windows

Referinta :
UML 12/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

- > v.5.0, 30 Decembrie 2005

• Pluginuri pentru IDE. Ex.: MaintainJ Plugin, SDE IntelliJ IDEA.

 MaintainJ Plugin -> OS: Cross-platform

- > IDE: min. Eclipse 3.2

- > v 2.9, 29 Martie 2010
 SDE IntelliJ IDEA - > OS: Cross-platform

- > IDE: min. Intelli JIDEA 9

- > v 4.0, 16 Octombrie 2010
Ultima vesiune de UML este 2.3.

4.1. Instalarea unui plugin in Eclipse

Pasi necesari:
1. Programele necesare pentru instalarea plugin-ului sunt disponibile pe site-ul
http://www.eclipse.org/modeling/mdt/downloads/?project=uml2tools. Prima data se
instaleaza programele din categoria Build Dependencies, ulterior cele din sectiunea UML2
Tools.

2. Din interiorul programului Eclipse se selecteaza categoria Help->Install new software. In

noua fereastra care se va deschide vom introduce cuvantul cheie “model” pentru a gasi
toate plugin-urile necesare modelarii diagramelor UML. Se vor selecta toate plugin-urile
mentionate in pasul anterior.

Referinta :
UML 13/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

3. Dupa instalarea plugin-urilor, diagramele UML se pot crea prin selectarea meniului File-
>New->Other->UML 2.1 Diagrams->Class Diagram.

Referinta :
UML 14/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

4. In continuare vom selecta proiectul a carui diagram o vom realiza.

Referinta :
UML 15/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

5. Selectam noul fisier .uml creat. Din cadrul sectiunii palette vom selecta tipul de element
pe care dorim sa il cream: clase, interfete, variabile, etc.

Referinta :
UML 16/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

6. In continuare se pot realiza diagramele dorite cu ajutorul elemetelor puse la dispozitie de

meniul “Palette”.

4.2. Generare cu aplicatia Altova Umodel 2009

Pasi necesari:
1. Descarcarea (contra cost) si instalarea aplicatie de pe sit-ul producatorului:
http://www.altova.com/download/umodel/uml_tool_enterprise.html

Referinta :
UML 17/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

2. Creeare proiect nou utilizand optiunea File -> New din meniu

3. Importarea fisierelor ce contin codul aplicatiei dupa care se vor genera diagramele.
(utilizand meniul Project -> Import Binary Tipes )

Se adauga fisierele necesare.

Referinta :
UML 18/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

4. Dupa adaugarea fisierelor din fereastra Model Tree se pot genera diagramele dorite.
(click dreapta pe numele pachetului ce contine fisierele aplicatiei -> Show in new
diagram -> content).

Referinta :
UML 19/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

Selctarea tipului de diagrama dorit.

Referinta :
UML 20/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

5. Exemplu de diagrame generate:

-Diagrama de clase

Referinta :
UML 21/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

-Analog in cazul in care aplicatia are mai multe pachete (diagrama de pachete).

5. Diagrame statice vs. Dinamice

• Diagrame statice: Prezinta structura statica a unui model, cu alte cuvinte elementele
care exista (clasele, atributele, metodele, etc.), structura interna a elementelor si
relatiile dintre ele. Sunt utilizate pentru a creea diagrame care reprezinta concepte din

Referinta :
UML 22/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

lumea reala si relatiile dintre ele sau diagrame de clase care descompun un sistem
software in partile sale componente.

• Diagrame dinamice: Sunt diagrame realizate la un moment dat in timpul rularii unui
program. Acestea descriu obiectele active la un moment dat si relatiile dintre ele si
difera in functie de momentul in care este surprins programul in timpul rularii (Ex.
diagrame de secventa, diagrame de stare, diagrame de activitate).

Referinta :
UML 23/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

6. Notatii UML:

Figura 11 Reprezentarea grafică în UML a unei agregări partajate

Figura 12 Reprezentarea grafică în UML a unei compoziţii

Figura 13 Reprezentarea grafică în UML a unei tranziţii

Figura 14 Reprezentarea grafică în UML a unei dependenţe

Figura 15 Reprezentarea grafică în UML a unei relaţii de derivare

Figura 16 Reprezentarea grafică în UML a unei relaţii de extensie

Referinta :
UML 24/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

Figura 17 Reprezentarea grafică în UML a unei relaţii de realizare

Figura 18 Simbolul folosit în UML pentru reprezentarea interfeţelor

Figura 19 Simbolul folosit in UML pentru reprezentarea interfetelor

Figura 20 Simbolul folosit în UML pentru reprezentarea claselor

7. Specificatii de gestiune a proiectului

(Repartizarea sarcinilor si a taskurilor pe
membrii echipei)

7.1. Working package – Management (Gestiune)

Denominare Realizare Relectura Validare

Caiet de sarcini
Caiet de specificatii
Exstras de reuniune
externa
Iles Ovidiu Ioan Ansamblu echipei de Clientul
proiect
Iles Ovidiu Ioan Ansamblu echipei de Ansamblu echipei de
proiect proiect
Iles Ovidiu Ioan Ansamblu echipei de Ansamblu echipei de
proiect proiect

Referinta :
UML 25/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

7.2. Time Planning (planificare in timp)

Nume Realizare Validare Numar

membru zile/ore
echipa lucrate
Toti membrii echipei Documentare Toti membrii echipei 1 zile / 10 ore
teoretica
(1 zi)
Cheregi Florin Redactarea partii Toti membrii echipei 2 zile / 16 ore
Borse Florentina teoretice
(2 zile)
Deaconu Alexandru Realizarea partii Toti membrii echipei 1 zile / 5 ore
practice
(1 zi)
Iles Ovidiu Ioan Intocmirea Toti membrii echipei 2 zile / 9 ore
documentelor:
Extras reuniune
Caiet de sarcini
Caiet de specificatii
(2 zile)

8. Specificatii administrative

8.1. Datele de livrare ale aplicatiei/Documente

administrative furnizate

24/11/2010 Predare Caiet de sarcini in versiunea A

24/11/2010 Predare Caiet de specificatii in versiunea A
24/11/2010 Predare Extras de reuniune in versiunea A
24/11/2010 Predare Prezentare Power Point

Referinta :
UML 26/27
WPMGT.Spec.001.C
Caiet de specificatii Versiunea A

8.2. Bibliografie/Referinte/Documentatie

 Eclipse:
• http://download.eclipse.org/modeling/mdt/updates/releases/
• http://www.vogella.de/articles/UML/article.html#uml_profiles
• http://www.ibm.com/developerworks/rational/library/content/
RationalEdge/sep04/bell/

 Altova:
• http://www.altova.com/umodel.html

 Documentatie

• http://www.uml-diagrams.org/

• http://books.google.com/books?
id=nHZslSr1gJAC&pg=PA158&lpg=PA157&ots=V69ZHQUx8B&dq=uml+1.4+type
+of+diagrams#v=onepage&q=uml%201.4%20type%20of%20diagrams&f=false

• http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?
topic=/com.ibm.xtools.modeler.doc/topics/r_uml_name_diffs.html

Referinta :
UML 27/27
WPMGT.Spec.001.C