Sunteți pe pagina 1din 61

Cuprins

Introducere.........................................................................................................................................................
1. Iniierea n Ingineria Programrii...............................................................................................................
1.1

Atributele cheie ale unui produs........................................................................................................................

1.2

Faze fundamentale ale metodologiilor ingineriei programrii................................................................................

2. Limbajul UML...............................................................................................................................................
2.1

UML. Consideraii teoretice...................................................................................................................................

2.2

Reguli de proiectare a unui sistem..........................................................................................................................

2.3

Metodologia Spiral .................................................................................................................................

2.4

Limbajul unificat de modelare UML n decursul anilor........................................................................................

2.5

Modelarea n UML...................................................................................................................................

2.6

Analiza unei aplicaii implic realizarea mai multor categorii de modele..................................................

2.7

Principalele pri ale UML ..............................................................................................................................

3. Planul de dezvoltare a proiectului. Diagrama Gantt...............................................................................


4. Modelul de analiz.......................................................................................................................................
4.1

Documentul cerinelor..............................................................................................................................

4.2

Descriere general....................................................................................................................................

4.3

Cerine de sistem.....................................................................................................................................

4.4

Diagramele cerinelor sistemului..........................................................................................................................

5. Modelul Use-Case........................................................................................................................................
5.1

Cazurile de utilizare.................................................................................................................................

5.2

Diagrama Use-Case pentru sistemul ,,Portal literar de Poezii...............................................................

6. Modelul de domeniu....................................................................................................................................
7. Modelul de interaciune..............................................................................................................................
8. Modelul de activitate i de stare..............................................................................................................................
9. Modelul de componente..............................................................................................................................
10. Modelul de desfurare.............................................................................................................................
Concluzie..........................................................................................................................................................
Bibliografie.......................................................................................................................................................
Anexa A............................................................................................................................................................
Anexa B............................................................................................................................................................

Introducere
Un web site este o grup de Pagini web multimedia ( texte, imagini fixe,
animaii etc. ), accesibile n Internet conectate ntre ele prin elemente numite
hiperlinkuri. Site-urile web pot fi create de ctre organizaii, persoane particulare,
instituii publice i pot fi pe diferite teme, dedicate unei persoane n parte sau unui
grup mai larg de oameni, etc.
Site - ul web se actualizeaz automat i permanent pe baza unui Sistem de
gestiune a bazelor de date.
La nceputurile Internetului fiecare site-ul web se accesa prin indicarea adresei
specifice numerice ( IP Adresa ). Ulterior pentru a accesa site-urile web s-a introdus
i stampila de domenii, clasice, ce a permis indicarea adresei respective n mod
comod printr-un mod text (cuvinte) uor de reinut, ca de exemplu
www.wikipedia.org. Adresele de web site-uri trebuie s fie clar stabilite, unice pe
toat reeaua net, adic nu se pot repeta.

1. Iniierea n Ingineria programrii


3

Ingineria programrii (softului) se ocup de procesul de dezvoltare i


ntreinere a produselor soft. Multe dintre tehnicile care se aplic n acest domeniu
sunt similare celor utilizate de ingineri care lucreaz n industrie. IP(Ingineria
Programrii) are urmtoarele caracteristici importante:
- Este aplicabil n producerea de programe mari;
- Este o tiin inginereasc;
- Scopul final este ndeplinirea cerinelor clientului.
Clientul dorete ca produsul s fie finalizat cu costuri de producie ct mai mici,
de asemenea este de dorit ca aceast s aib performane ct mai bune, cu cost de
ntreinere ct mai mic, s fie livrat la timp i s fie simplu.
1.1 Atributele cheie ale unui produs
- Posibilitatea de a putea fi ntreinut, pentru aceasta avem nevoie de un produs cu un
ciclu de via lung, este supus modificrilor, de aceea el trebuie s fie foarte bine
documentat;
- Fiabilitatea produsul trebuie s se comporte dup cerinele utilizatorului i s nu
cad mai mult de ct e prevzut n specificaiile sale;
- Eficiena produsul nu trebuie s foloseasc n pierdere resurselor de sistem
(memoria);
- Interfaa potrivit pentru utilizator interfaa trebuie s in seama de capacitatea i
cunotinele utilizatorului;
- Fiabilitatea un program este fiabil dac funcioneaz i continu s funcioneze
fr ntreruperi un interval de timp. Aceast noiune exprim de fapt rezistena la
condiiile de funcionare.
1.2.Faze fundamentale ale metodologiilor ingineriei programrii
1) Analiza ce dorim s construim
2) Proiectarea cum vom construi
3) Implementarea construirea propriu zis
4) Testarea asigurarea calitii

2.Limbajul UML
4

2.1 UML. Consideraii teoretice


Limbajul UML (Limbajul Unificat de Modelare) este un standard acceptat
pentru modelarea orientat pe obiecte a sistemelor mari i complexe. UML este o
unificare a unui numr de limbaje de modelare care ofer o varietate larg de tipuri
de diagrame. Aceste diagrame pot fi utilizate la diferite faze de dezvoltare a
produselor software, a sistemelor sau a diferitor procese (ex. procese de producie).
Modelele UML au un rol foarte important n proiectarea sistemelor, acestea
ofer practic viziunea complet asupra componentelor i relaiilor existente n cadrul
unui sistem concret. Importana acestor modele impune i un anumit nivel sau
standard de calitate a ndeplinirii fiecrei diagrame. Calitatea modelelor poate fi
privit din mai multe puncte de vedere: logic de proiectare corect, consisten ,
semantic corect, eficien i notaie corect. Desigur c exist o mulime de alte
criterii dup care ar putea fi verificat corectitudinea modelelor, ns aceste criterii
depind de specificul fiecrui sistem n parte i de domeniul de proiectare.
Notaia UML este foarte pe larg utilizat la proiectarea produselor program,
prin urmare exist mai multe abordri de dezvoltare software bazate pe nota ia UML.
Aceste abordri determin fazele de dezvoltare a produsului soft i numrul de
diagrame construit la fiecare etap. Modelul definit la o anumit faza este un sistem
considerat la un anumit punct de vedere i const dintr-un set de diagrame UML
diferite. Diagramele pot fi considerate drept componente de baz ale modelelor pe
care nelege pe deplin aspectele statice i dinamice ale unui sistem de modelat. Cu
toate acestea, modelul poate fi incomplet. Programatorii se confrunt cu dou
probleme principale n timpul unui proces de construire a unui model: consisten a
ntre diagrame diferite a unui model i problema consistenei dintre dou modele
diferite. Prin noiunea de consisten a unui model se subnelege corectitudinea
modelului la nivel de semantic static. Consistena este o condiie necesar atunci
cnd este nevoie s se construiasc modele UML ntr-un proces de dezvoltare
software.

2.2 Reguli de proiectare a unui sistem


5

Pentru realizarea unui sistem eficient trebuie avute n vedere unele reguli de
baz, ce au fost deduse din practica.
Abordarea global modular - La proiectarea sistemului trebuie avut n vedere
legtura acestuia cu lumea exterioar, posibilitile de comunicare cu alte sisteme
similare, compatibilitatea cu sisteme de alt natur, posibilitatea includerii sistemului
ntr-un sistem mai complex, sau posibilitatea includerii altor sisteme.
Criteriul eficienei economice - Principalul criteriu ce st la baza realizrii
sistemului este cel economic. Cu alte cuvinte, la proiectare trebuie avut n vedere c
raportul dintre rezultatul sau rezultatele directe/indirecte obinute prin implementarea
i folosirea sistemului economic i totalitatea costurilor de realizare s fie ct mai
mare. Cu alte cuvinte, trebuie s fie rentabil.
Orientarea spre utilizatori - La realizarea sistemului trebuie s se aib n
vedere cerinele i preferinele utilizatorilor. n acest sens, trebuie purtata o discuie
cu utilizatorii n prealabil i pe baza sugestiilor i preferinelor lor s se treac la
proiectarea propriu zis.
Asigurarea unicitii introducerii datelor- De cele mai multe ori o serie de date
trebuie utilizate n mai multe locuri n cadrul sistemului informatic. La proiectarea
sistemului, trebuie ca datele s fie introduse o singur dat, iar sistemul s distribuie
automat datele n celelalte locuri n care este nevoie de ele.
Antrenarea beneficiarului la realizarea sistemului - Acest principiu decurge tot
din orientarea spre utilizator. Trebuie discutat cu utilizatorul nainte de a trece la
proiectare, pentru a nltura de la nceput o serie de neajunsuri .Trebuiesc discutate
modalitile de introducere a datelor i adaptarea aplicaiei la nevoile utilizatorului,
modul de calcul i prelucrare al datelor.
Soluie general - independena de configuraia actual a sistemului
informatizat. Sistemul proiectat nu trebuie, pe ct posibil, s fie dependent de dotarea
tehnic actual a beneficiarului, ci trebuie avute n vedere eventuale noi achiziii de
tehnic de calcul, o eventual schimbare a sistemului informatic.
Posibilitatea de dezvoltare ulterioar - trebuie avut n vedere posibilitatea ca
sistemul s poat fi mbuntit n raport de cerinele viitoare ale firmei beneficiare.

2.3 Metodologia Spiral


Metodologia spiral este un exemplu bine cunoscut de metodologie a ingineriei
programrii. Acest model ncearc s rezolve problemele modelului n cascad,
6

pstrnd avantajele acestuia: planificare, faze bine definite, produse intermediare. El


definete urmtorii pai n dezvoltarea unui produs:
-

studiul de fezabilitate;
analiza cerinelor;
proiectarea arhitecturii software;
implementarea.
Modelul n spiral recunoate c problema principal a dezvoltrii programelor

este riscul. Riscul nu mai este eliminat prin aseriuni de genul: n urma proiectrii
am obinut un model corect al sistemului, ca n modelul cascad. Aici riscul este
acceptat, evaluat i se iau msuri pentru contracararea efectelor sale negative.
Exemple de riscuri:
- n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului
-

sunt ignorate;
clientul schimb cerinele;
o firm concurent lanseaz un program rival pe pia;
un dezvoltator/arhitect prsete echipa de dezvoltare;
o echip nu respect un termen de livrare pentru o anumit component.

n modelul spiral se consider c fiecare pas din dezvoltare conine o serie de


activiti comune:
- pregtirea: se identific obiectivele, alternativele, constrngerile;
- gestionarea riscului: analiza i rezolvarea situaiilor de risc;
- activiti de dezvoltare specifice pasului curent (de exemplu analiza
specificaiilor sau scrierea de cod);
- planificarea urmtorului stadiu: termenele limit, resurse umane, revizuirea
strii proiectului.

Reprezentarea schematic metodologiei Spiral

Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri:


Ciclul 1 Analiza preliminar:
1.
2.
3.
4.
5.
6.

Obiective, alternative, constrngeri


Analiza riscului i prototipul
Conceperea operaiilor
Cerinele i planul ciclului de via
Obiective, alternative, constrngeri
Analiza riscului i prototipul

Ciclul 2 Analiza final:


7. Simulare, modele, benchmark-uri
8. Cerine software i validare
9. Plan de dezvoltare
10.Obiective, alternative, constrngeri
8

11.Analiza riscului i prototipul


Ciclul 3 Proiectarea:
12.Simulare, modele, benchmark-uri
13.Proiectarea produsului software, validare i verificare
14.Integrare i plan de test
15.Obiective, alternative, constrngeri
16.Analiza riscului i prototipul operaional
Ciclul 4 Implementarea i testarea:
17.Simulare, modele, benchmark-uri
18.Proiectare detaliat
19.Cod
20.Integrarea unitilor i testarea acceptrii
21.Lansarea produsului
Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o etap. Pe
msur ce spirala este parcurs, produsul se maturizeaz. Cu fiecare ciclu, sistemul se
apropie de soluia final. Dei este considerat ca un exemplu generic pentru
metodologia ciclic, metoda are i elemente secveniale, puse n eviden de evoluia
constant de la o etap la alta.
n proiect nu am folosit n totalmente aceast metodologie, cauzele fiind:
- sistemul nu este mare i pentru a uura munca nu am implementat complet
metodologia.
- n unele situaii am aplicat metodologia Abordarea Cedeaz i repar,

2.4 Limbajul unificat de modelare UML n decursul anilor


UML nu este un simplu limbaj de modelare orientat pe obiecte, ci n prezent,
este limbajul universal standard pentru dezvoltatorii software din toat lumea. UML
este succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare
orientate pe obiecte (Booch, OMT i OOSE). UML se constituie din unirea acestor
limbaje de modelare i n plus deine o expresivitate care ajut la rezolvarea
problemelor de modelare pe care vechile limbaje nu o aveau.
ncepnd cu mijlocul anilor 1970 i continund n anii 1980 au aprut diverse
limbaje de modelare, odat cu creterea experienei de lucru n cadrul paradigmei
9

orientate obiect. Astfel, numrul de limbaje de modelare ajunge de la 10 pn la mai


mult de 50 n perioada 1989-1994.
Limbajele de modelare de succes din aceast perioad sunt Booch (Grady
Booch), OOSE - Object-Oriented Software Engineering (Ivar Jacobson) i OMT Object Modeling Technique (James Rumbaugh). Aceste limbaje aveau propriile
puncte tari i slbiciuni, dup cum creatorii lor puneau accentul pe anumite idei de
modelare. Aadar, utilizatorii gseau tehnicile de modelare ce le erau necesare unui
proiect particular numai n anumite limbaje, fapt ce a alimentat "rzboiul metodelor".
La mijlocul anilor 1990, cnd este semnalat o nou generaie de limbaje de
modelare, a nceput un proces de omogenizare, prin ncorporarea n fiecare limbaj a
caracteristicilor gsite n celelalte limbaje.
Dezvoltarea UML a nceput n mod oficial n octombrie 1994, cnd Rumbaugh
s-a alturat lui Booch n cadrul companiei Rational Softwarei, ambii lucrnd la
unificarea limbajelor Booch i OMT. Versiunea preliminar 0.8 a Unified (Metoda
Unificat - aa cum era numit atunci) a fost publicat n octombrie 1995. Tot
atunci, Jacobson s-a alturat echipei de la Raional i scopul UML a fost extins pentru
a include i OOSE. n iunie 1996 a fost publicat versiunea 0.9 a UML. Pe parcursul
anului 1996, ca o consecin a reaciilor comunitii proiectanilor de sistem, a
devenit clar c UML este vzut de ctre multe companii ca o opiune strategic
pentru dezvoltarea produselor lor. A fost creat un consoriu UML format din
organizaii doritoare s aloce resurse pentru a obine o definiie final a UML. Dintre
aceste companii care au contribuit la crearea UML 1.0 au fcut parte: DEC, HewletPackard, IBM, Microsoft, Oracle, Rational, Texas Instruments etc.
UML 1.0 a fost propus spre standardizare n cadrul OMG (Object Management
Group)ii n ianuarie 1997. Pn la sfritul anului 1997 echipa care lucra la UML s-a
extins, urmnd o perioad n care UML a primit o specificare formal mai riguroas.
Versiunea UML 1.1 a fost adoptat ca standard de ctre OMG n noiembrie 1997.
Actualmente, UML este dezvoltat de ctre OMG Revision Task Force, condus de
Cris Kobryn.
Versiunea 1.2 a UML a fost o revizie editorial; versiunile 1.3 au fost publicate
ncepnd cu sfritul anului 1998.
n martie 2003 UML a ajuns la versiunea 1.5.
Versiunea 2.0 a fost intens dezbtut i a aprut pe pia n octombrie 2004.
Ultima versiune UML 2.1.2, aprut n noiembrie 2007, are modificri minore
fa de versiune UML 2.1.1 din 2006. Ultima versiune este format din dou
specificaii diferite Superstructure i Infrastructure. Tot n cadrul ultimei variante
10

sunt dou specificaii care sunt legate de specificaia UML 2.0 (Diagram Interchange
i Object Constraint Language).
Standardizarea limbajului UML s-a realizat n 2005, prin ISO/IEC
19501:2005iii ce descrie un limbaj grafic de vizualizare, specificare, construcie i
documentare a artefactelor ale unui sistem software intens. UML ofer o cale
standardizat de a scrie planurile (blueprints) unui sistem, incluznd elemente
conceptuale ca procesele de afaceri i funciunile sistemului, precum i elemente
concrete cum ar fi declaraiile din cadrul limbajelor de programare, schemele bazelor
de date sau componente software reutilizabile.
2.5.Modelarea n UML
Conceptele folosite n cadrul diagramelor UML se numesc elemente de
modelare. Un element de modelare are o semantic, o definiie formal a
elementului sau un neles exact aceea ce reprezint el ntr-un anumit context, i o
reprezentare grafic, sau un simbol grafic cu care se reprezint n cadrul diagramelor.
Un element poate fi regsit n mai multe tipuri de diagrame i pentru fiecare
context exist propriile reguli. A modela cu UML nseamn a construi mai multe modele
pentru diferitele faze ale dezvoltrii i pentru diverse scopuri.
Exist mai multe faze ce trebuie parcurse:
a) faza de analiz - surprinde necesitile sistemului i modeleaz clasele de baz
din "lumea real" i colaborrile dintre acestea.
b) faza de design - se detaliaz modelul din faza de analiz i se formuleaz o
soluie tehnic lund n considerare caracteristicile mediului n care acesta va
fie reprezentat.
c) faza de implementare - modelul este transpus n cod iar apoi compilat n
programe.
d) modelul de desfurare - se folosete o descriere care explic modul cum va fi
adaptat sistemul arhitecturii fizice concrete.

2.6.Analiza unei aplicaii implic realizarea mai multor categorii de modele


a) Modelul de utilizare - realizeaz modelarea problemelor i a soluiilor acestora n
maniera n care le percepe utilizatorul final al aplicaiei.
Diagram asociat: diagram de cazuri de utilizare
11

b) Modelul structural: se realizeaz pe baza analizei statice a problemei i


descrie proprietile statice ale entitilor care compun domeniul problemei.
Diagrame asociate: diagram de module, diagram de clase.
c) Modelul comportamental: privete descrierea funcionalitiilor i a succesiunii
n timp a aciunilor realizate de entitile domeniului problemei.
Diagrame asociate: diagrama(harta) de stri, diagrama de colaborare,
diagrama de interaciune.
2.7. Principalele pri ale UML
1) Vederile (View) - surprind aspecte particulare ale sistemului de modelat. Un
view este o abstractizare a sistemului, iar pentru construirea lui se folosete un
numr de diagrame.
2) Diagramele - sunt grafuri care descriu coninutul unui view. UML are nou
tipuri de diagrame, care pot fi combinate pentru a forma toate view-urile
sistemului.
3) Elementele de modelare - sunt conceptele folosite n diagrame care au
coresponden n programarea orientat-obiect, cum ar fi: clase, obiecte,
mesaje i relaii ntre acestea: asocierea, dependena, generalizarea. Un
element de modelare poate fi folosit n mai multe diagrame diferite i va avea
acelai neles i acelai mod de reprezentare.
4) Mecanismele generale -permit introducerea de comentarii i alte informaii
despre un anumit element.

3. Planul de dezvoltare a proiectului


Un instrument important n analiza i planificarea proiectelor complexe este
diagrama Gantt, care la rndul su realizeaz urmtoarele:
- Ajut la planificarea sarcinilor ce trebuie duse la bun sfrit.
- ntocmete un program referitor la perioada n care aceste sarcini vor fi
ndeplinite.
- Planific distribuirea resurselor necesare proiectului.
- Ajut la depirea momentelor critice ale unui proiect, atunci cnd acesta
trebuie finalizat pn la o anumit dat.
12

n timpul desfurrii unui proiect, diagrama Gantt ajut la monitorizarea


proiectului respectiv i arat dac acesta se ncadreaz n plan.

Diagrama Gant:

13

Estimrile lucrrilor
Estimarea proiectului reprezint planificarea timpului de dezvoltare a aplicaiei
pentru realizarea funcionalitii cerute de client.
Estimarea proiectului se va face avnd n vedere lista funcionalit ii care au
fost realizate n cadrul sistemului i timpul care a fost utilizat pentru a realiza
funcionalitile date.
Lista de riscuri:
a) Nencadrarea n termenii stabilii - stabilirea unui timp cu termenul mai devreme
fa de cel real.
b) Nemulumirile membrilor echipei cu privirea la sarcini - Fiecare membru alege
sarcina dorita dar i n caz de necesitate vor decurge la compromise.
c) Apariia unor erori necunoscute - erori care nu au fost descoperite la momentul
proiectrii care se pot dovedi a fi critice care mpiedic sistemulu s satisfac n
mod complet scenariile de utilizare.
d) Lipsa de experien a echipei de lucru la proiect
e) Atacurile rufctorilor atacurile asupra sistemului care poate provoca
tergerea sau modificarea informaiei din baza de date.

14

4. Modelul de analiz
4.1. Documentul cerinelor
Lucrarea dat presupune dezvoltarea produsului care este: Portal literar de
poezii. Adic, una din funcionalitile de baz a aplicaiei este accesul la un web
site cu tematica poeziei, unde utilizatorii vor avea posibilitatea de a citi poeziile
tinerilor autori, iar odat nregistrindu-se vor putea folosi toat performana site-ului
la maxim. ns sistemul nu se limiteaz doar la aceasta, utilizatorul se va loga prin
nume/mail i parola, au posibilitatea de ai alege un stil preferat(cum doresc s vad
site-ul).
Vor fi trei nivele de utilizatori: administrator, moderator i utilizator simplu,
avnd fiecare drepturi corespunztoare. Administratorul i moderatorul intrnd prin
name/email i parol pot asigura funcionalitile sistemului, corecta, verifica datele
i gestiunea permanent a performanei.
4.1.1. Scopul documentului
Acest document descrie cerinele de sistem ale proiectului PoeziiMd.Com. Sunt
descrise funcionalitile sistemului, interfaa cu utilizatorul, performanele cerute de
la sistem, detalii privind componentele sistemului i alte cerin e similare. Utilizatorii
nregistrai ct i oaspeii pot folosi acest document pentru testarea cerinelor descrise.
4.1.2. Scopul proiectului
Produsul realizat este un WEB-portal literar de poezii ce are ca scop
promovarea poeziei i a tinerelor talente. Avnd o interfa plcut i funcionalitate
bun, dar care e i n curs de performan, permite cu uurin utilizatorului att
oaspetelui ct i celui logat s dispun de drepturi ca: vizualizarea poeziei, like-uri,
comentarii, mesaje, postarea poeziei, etc. Dac utilizatorul intrat e un simplu oaspete
va putea folosi portalul dar nu la maxim, fiind restrns de cerin ele sistemului, dar
dac se va nregistra va fi un utilizator cu drepturi, cerine i funcionaliti
corespunztoare.
4.1.3. Definiii, acronime, abrevieri i notaii
Html - HyperText Markup Language: limbaj pentru descrierea paginii web.
PHP - HyperText Preprocessor. Limbaj de programare cu scop general folosit
intensiv pentru dezvoltarea aplicaiilor web. Un limbaj de programare utilizat pentru
a crea site-uri web dinamice.
15

CSS - Cascading Style Sheet: sunt etichete folosite pentru formatarea paginilor web
(de exemplu formatare text, background sau aranjare n pagina, etc.).
Browser - program de explorare ce permite accesul utilizatorilor la informa iile
(text, poze, video, audio) aflate pe pagina web.
HTTP -

Hyper Text Transfer Protocol,

Url

Uniform Resource Locator,

Site

Mai multe pagini web dinamice care mpreun constituie sistemul.

U1,U2....-

Cerinelor utilizatorului.

V1, V2 - cerinele vizitatorului


U1, U2 - cerinele utilizatorului
M1, M2 - cerinele moderatorului
A1, A2 - cerinele administratorului
S1, S2... cerinele fa de sistem nefuncionale
AJAX Asynchronous JavaScript and XML: reprezint o colecie de tehnologii
utilizate n dezvoltarea site-urilor web. Intenia este de a aduga o interactivitate mai
mare n paginile web i de a micora timpul de ncrcare al acestora.
MySQL - Administrarea MySQL se poate face din linia de comand sau folosind
browserul i accesnd aplicaia numit PHPMyAdmin scrisa n PHP.
JQuery - este un proiect Open-Source cu o echip de baz format din dezvoltatori
JavaScript de elit. Librria ofer registru larg de caracteristici, o sintax u or de
nvat i o robust compatibilitate ntre platforme ntr-un singur fiier compact.
4.1.4.Referinte
https://www.google.com/
http://jquery.com
http://css3.me

16

4.2. Descriere general


Interfaa aplicaiei va fi integrat prin intermediul unui website, cu domenul
http://www.poeziimd.com/ i pstrarea fiierelor i a bazei de date pe un hosting fiind
rulat de serverul web Apache.
Web site-ul va reprezenta un sistem online i gratuit pentru postarea poeziilor
personale. Prin intermediul acestui proiect, utilizatorul va putea s- i promoveze
talentul de a compune poezii n spaiul larg al internetului. Datorit simplit ii
interfeei vrsta nu va fi o piedic pentru a se realiza ca autor. n urma postrii
creaiilor personale utilizatorul va putea fi apreciat de restul utilizatorilor ct i de
vizitatori prin comentarii, like-uri, vizualizri i cele mai bune poezii/poe i vor fi n
top. Pe lng promovarea poeziilor personale, utilizatorii site-ului i vor face noi
prieteni i vor comunica nu doar prin comentariile poeziilor dar i prin mesaje
private.
4.3. Cerine de sistem
4.3.1. Cerine funcionale ale vizitatorului
V1 vizualizare poezii
V2 like poezii
V3 search
V4 nregistrare:
Introducerea informaie : email, parola, nickname, avatar
Autologare dup confirmarea email
4.3.2. Cerine funcionale ale utilizatorului
U1 Logare
a) Introducere login/email
b) introducerea parolei
U2 Postarea poeziei
a) postarea poeziei
b) modificarea poeziei
c) tergerea poeziei
d) adugare comentariu
17

U3 votarea autorilor
U4 like poezii
U5 delogare
U6 sortarea poeziilor cutate:
a) sortarea dup dat
b) sortarea dup nume
c) sortarea dup vizualizri
4.3.3. Cerine funcionale ale moderatorului
M1 acceptare / refuz poezie
M2 modific drepturile utilizatorului
M3 modific avatarul unui utilizator cu cel predefinit
M4 logare
M5 delogare
M6 Postarea poeziei
a) postarea poeziei
b) modificarea poeziei
c) tergerea poeziei
d) adugare comentariu
4.3.4. Cerine funcionale ale administratorului:
A1 Logare:
a) Introducere login/email
b) introducerea parolei
A2 Privilegii:
a) acceptare / refuz poezie
b) modific avatarul unui utilizator cu cel predefinit
c) modific drepturile utilizatorului
A3 Categorii:
a) crearea unei categorii noi
b) modificarea unei categorii existente
c) tergerea unei categorii existente
A4 tergere
a) nlturarea drepturilor de moderator
18

b) tergerea unei poezii


c) tergerea unei teme din forum
d) tergerea unui utilizator
e) tergerea unui comentariu
A5 Postarea poeziei
a) postarea poeziei
b) modificarea poeziei
c) tergerea poeziei
d) adugare comentariu
A6 delogare
4.3.5. Cerinele non-funcionale fa de sistem (restricii):
S1 acces la baza de date
S2 completarea cmpurilor obligatorii
S3 email unic
S4 fiabilitate
S5 securitate
S6 suport CROSS-Browser
S7 verificarea sesiunii

4.3.6. Constrngeri de Design


Cerine HARD: datorit internetului aplicaia s poat fi accesat oriunde n lume,
avnd un dispozitiv cu minim 64RAM, 100MB HDD, CPU 500MHz.
Cerine SOFT: Aplicaia va fi accesat din urmtoarele sisteme de operare: Windows,
Unix, Mac, Symbian, Android, iPhone cu CROSS-BROWSER.
4.3.7. Cerine funcionale ale utilizatorului
U1 Logare
a) Introducere login/email
b) introducerea parolei

19

U2 Postarea poeziei
a) postarea poeziei
b) modificarea poeziei
c) tergerea poeziei
d) adugare comentariu
U3 votarea autorilor
U4 like poezii
U5 delogare
U6 sortarea poeziilor cutate:
a) sortarea dup dat
b) sortarea dup nume
c) sortarea dup vizualizri

4.3.8. Cerine funcionale ale moderatorului


M1 acceptare / refuz poezie
M2 modific drepturile utilizatorului
M3 modific avatarul unui utilizator cu cel predefinit
M4 logare
M5 delogare
M6 Postarea poeziei
a) postarea poeziei
b) modificarea poeziei
c) tergerea poeziei
d) adugare comentariu
4.3.9. Cerine funcionale ale administratorului:
A1 Logare:
a) Introducere login/email
b) introducerea parolei
A2 Privilegii:
a) acceptare / refuz poezie
b) modific avatarul unui utilizator cu cel predefinit
c) modific drepturile utilizatorului
A3 Categorii:
a) crearea unei categorii noi
20

b) modificarea unei categorii existente


c) tergerea unei categorii existente
A4 tergere
a) nlturarea drepturilor de moderator
b) tergerea unei poezii
c) tergerea unei teme din forum
d) tergerea unui utilizator
e) tergerea unui comentariu
A5 Postarea poeziei
a) postarea poeziei
b) modificarea poeziei
c) tergerea poeziei
d) adugare comentariu
A6 delogare
4.3.10. Cerinele non-funcionale fa de sistem (restricii):
S1 acces la baza de date
S2 completarea cmpurilor obligatorii
S3 email unic
S4 fiabilitate
S5 securitate
S6 suport CROSS-Browser
S7 verificarea sesiunii
4.3.11. Constrngeri de Design
Cerine HARD
Datorit internetului aplicaia s poat fi accesat oriunde n lume, avnd un
dispozitiv cu minim 64RAM, 100MB HDD, CPU 500MHz.
Cerine SOFT:

21

Aplicaia va fi accesat din urmtoarele sisteme de operare: Windows, Unix, Mac,


Symbian, Android, iPhone cu CROSS-BROWSER.
4.3.12. Atributele sistemului software
ncredere:
Toate documentele html i php vor fi interpretate corect de browser.
Fiabilitate:
Aplicaia va fi accesat din orice colt al lumii la o viteza care va depinde de
conexiunea utilizatorului cu reeaua internet.
Toleranta la erori:
Url-urile introduse greit (intenionat sau nu) vor fi readresate paginii principale sau
prelucrate de sistem n modul corespunztor, urmnd ca apoi n caz de apari ie a unei
erori s fie prentmpinat de administrator.

4.4.Diagramele cerinelor sistemului


22

Diagrama de cerine funcionale i non-funcionale

Diagrama cerinelor funcionale


23

24

Diagrama cerinelor fa de administrator


moderator

Diagrama cerinelor fa de

25

Diagrama cerinelor fa de oaspei

Diagrama cerinelor fa de utilizatori

26

5.Modelul Use-Case
Diagrama variantelor de utilizare reprezint partea de la care se ncepe
modelarea unui sistem nou. Aici se reflect aciunile reciproce dintre variantele
posibile de utilizare i persoanele cointeresate sau sistem. Diagrama reflect cerin ele
ctre sistem din punct de vedere al utilizatorului. Variantele de utilizare snt func iile
efectuate de sistem.
Avantajul principal al variantelor de utilizare este c folosindu-le separm
implementarea sistemului de descrierea funciilor sale. Acest fapt ajut concentrarea
ateniei pe aa ntrebri ca satisfacerea cerinelor ctre sistem fr 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.
n cadrul sistemului figureaz actorii care sunt nu alt cineva dect administratorii i
userii ce folosesc sistemul.
uc Use Case Mo...

Admin

User

Pentru a face diferena dintre aceti doi actori din cadrul sistemului, vom face
descriere scurt a fiecare tip de utilizator posibil n sistemul dat.
Administratorul-este persoana autentificat n sistem ce la autentificare
introduce datele ce corespund nivelului de acces de administrator, care dispune de
maximum de funcionaliti n care intr posibilitatea manipulrii cu lista userilor.
Userul-clientul care la autentificare se nregistreaz, introduce datele ce
corespund nivelului de acces corespunztor. El dispune de un numr mai mic de
funcionaliti.
Diagrama cazurilor de utilizare reprezint un model iniial conceptual al unui
sistem n procesul de proiectare i exploatare. Diagrama descrie ceea ce va executa
sistemul n procesul de funcionare. Esena acestei diagrame const n faptul c
sistemul proiectat reprezint o colecie de actori care colaboreaz cu sistemul prin aa
numitele cazuri de utilizare.
Elementele componente ale diagramei cazurilor de utilizare sunt :
1. Sistemul
2. Actorii
27

3. Cazurile de utilizare
4. Relaiile
Sistemul. Notaia grafic a sistemului reprezint un dreptunghi cu numele
sistemului proiectat indicat n interiorul dreptunghiului.

<<Numele sistemului>>

Acest element seteaz limitele unui sistem n relaia actor (care sunt n afara
sistemului) i funcionalitile care trebuie s le ofere sistemul.
Scopurile principale ale construirii acestui tip de diagram este:
- s decid i s descrie cerinele care au fost deduse dup o discuie ntre clieni
i/sau utilizatori ai sistemului, i viitorii developeri ai acestuia;
- s ofere o descriere clar i consistent, ce va trebui s fac sistemul;
- s constituie o baz pentru verificarea testelor;
- s permit o transformare uoar a cerinelor funcionale n viitoare clase i operaii.
Un model use case este descris folosind 1 sau mai multe diagrame use case.
Descrierea diagramei USE CASE pentru Sistemul ,,Portal Literar de Poezii:
O dat stabilind cerinele funcionale i nefuncionale fa de sistem, conform
lucrrii de laborator nr.1 putem merge mai departe s interpretm un model grafic,
adic cum ar funciona sistemul nostru.
Avnd ca punct de plecare cerinele putem stabili urmtoarele elemente
pentru diagrama USE CASE:
a) Actorii - vizitatorii, utilizatorii, moderatorii, administratorul, baza de date i
servicii email.
b) Scenarii - n urma logrii n sistem, utilizatorul, uor i comod i poate
organiza poeziile sale pentru a le promova n spaiul larg al internetului cu
ajutorul cabinetului personal administrndu-i profilul. De asemenea are
posibilitatea de a urmri activitatea celorlali utilizatori, precum i aprecierea
creaiilor plasnd comentarii, like-uri, share pe alte site-uri de socializare,
adugarea n favorit. Portalul are un caracter social, dnd posibilitatea
comunicrii n privat ntre utilizatori prin intermediul mesajelor personale.

5.1. Cazurile de utilizare:


28

Trimite mesaj administratorului


nregistrare
Cutarea cutarea poeziei, utilizatorului i a temelor de pe forum
Sortarea poeziei dup dat, vizualizare i categorie
Vizualizarea poeziei
Like la poezie
Logarea autentificarea utilizatorului/moderatorului/administratorului
Delogare sfrirea sesiunii
Adugarea unei noi teme pe forum
Cabinet
personal

cabinetul
utilizatorului/moderatorului/administratorului

personal

Voteaz autorii posibilitatea de a vota un autor printr-o not


Adaug o poezie posibilitatea utilizatorului/moderatorului/administratorului de a
posta o poezie
terge poezia personal
Editeaz poezia personal
Accept poezii posibilitatea moderatorului i al administratorului de a accepta
poeziile postate de utilizatori
Modific avatar predefinit pot modifica avatarul oricrui utilizator doar
moderatorul i administratorul
Adaug comentarii adugarea comentariilor la poezie de ctre cei nregistrai
Cenzurarea comentariilor cenzurarea de ctre moderatori i administrator a
comentariului vulgar
tergerea comentariilor tergerea comentariului o poate face doar administratorul
Adaug categorii administratorul poate crea noi categorii de poezii
tergerea categoriei tergerea unei categorii de poezie de ctre administrator
Editarea categoriei editarea unei categorii de poezie de ctre administrator
Modificare drepturi posibilitatea administratorului de a oferi i de ai lua dreptul de
moderator utilizatorului
tergere tem tergerea oricrei teme de pe forum cu tot coninutul ei
29

terge utilizator
terge poezie - tergerea poeziei a oricrui autor

5.2. Diagrama Use-Case pentru sistemul ,,Portal literar de Poezii


30

6. Modelul de domeniu
31

Un caz de utilizare este o tehnic de modelare folosit pentru a descrie ce va


face un sistem nou, sau ce va face deja un sistem existent. Modelarea cazurilor de
utilizare a fost folosit pentru prima dat de ctre Ivar Jacobson n metodele de
modelare OOSE. Scopul urmrit n acest tip de modelare este descrierea
funcionalitii sistemului aa cum este acesta vzut din exterior de un numr de
actori i a conexiunilor acestora la cazurile de utilizare furnizate de sistem.
Pentru crearea modelului cazului de utilizare vor trebui identificai actorii,
cazurile de utilizare, relaiile dintre acestea, ct i relaiile cu actorii. Toate aceste faze
presupun discuii cu clienii, i eventual, cu persoanele care reprezint actorii. n
aceast faz de modelare sistemul este vzut ca o cutie neagr, care trebuie s poat
realiza anumite sarcini fr a ne interesa cum vor fi implementate.
Scopurile principale ale construirii acestui tip de diagram este:
- s decid i s descrie cerinele care au fost deduse dup o discu ie ntre clien i
i/sau utilizatori ai sistemului, i viitorii developeri ai acestuia;
- s ofere o descriere clar i consistent, ce va trebui s fac sistemul;
- s constituie o baz pentru verificarea testelor;
- s permit o transformare uoar a cerinelor funcionale n viitoare clase i operaii.
Clasa UML modeleaz componentele (entitile) de interes ale unui sistem.
Clasa are instane, sau realizri. Aceste instane sunt obiectele clasei. Prin conceptul
de clas se descriu structura i comportarea obiectelor clasei. Structura con ine
atributele fiecrui obiect din clas. Comportarea include operaiunile ce pot fi
executate pe o instan specific de obiect.
Atribute
Sintaxa de specificare a atributelor:
[stereotype] [visibility] [/] attributeName [multiplicity] : [type] [=initialValue], n
care:
stereotype este un stereotip UML, definit de utilizator, pentru a mbogii
semantica (nelesul!) unei definiii de atribut;
visibility folosete simbolurile:
+ pentru vizibilitate public (orice clas poate avea acces la atribut);
# pentru vizibilitate protejat (numai clasa respectiv i succesorii si pot avea acces
la atribut);
- pentru vizibilitate privat (numai clasa respectiv poate avea acces la atribut);
32

/ pentru a reprezenta un atribut derivat;


attributeName reprezint numele atributului;
multiplicity indic dac atributul este multi-valoare;
type este un nume de clas, sau un tip de date, care define te tipul valorii ce se
memoreaz n atribut
initialValue indic o valoare lips (default) care trebuie atribuit atributului.
Operaiuni
Sintaxa prin lips (default) pentru specificarea semnturii unei metode este:
[stereotype] [visibility] methodName ([parameterList]) : [returnType], n care:
stereotype este un stereotip UML sau definit de utilizator pentru a mbogii
semantica (nelesul) unei operaiuni;
visibility folosete simbolurile:
+ pentru vizibilitate public (orice clas poate executa metoda);
# pentru vizibilizate protejat (numai clasa i subclasele sale pot executa metoda);
- pentru vizibilitate privat (numai clasa poate executa metoda);
methodName reprezint numele metodei;
parameterList este o list de atribute, sau de perechi de tipuri, separate prin virgule,
pentru a indica parametrii formali ai metodei;
returnType este numele clasei sau tipul de date care indic tipul valorii returnate
(ntoarse) de o funcie.
Numele clasei
Numele clasei trebuie s fie unic n cadrul pachetului, care este descris de ctre
o totalitate de diagrame de clase. Numele se indic n prima sec iune de sus a
dreptunghiului. n completare la regula general de denumire a elementelor n
limbajul UML numele clasei se scrie n centrul seciunii cu caracter semigros (bold)
i trebuie s nceap cu majuscula. Se recomand n calitate de nume a claselor s fie
utilizate substantivele scrise fr spaii i a multiplicitile lor.

33

Diagrama de clase:

34

7. Modelul de interaciune
n limbajul UML colaborarea ntre elemente se cerceteaz n aspectul
informativ al comunicaiilor lor, adic obiectele care interacioneaz fac schimb de
informaie anumit. Pentru modelarea colaborrii ntre obiecte n limbajul UML se
utilizeaz diagramele de secven.
Colaborarea ntre obiecte poate fi cercetat n timp i atunci pentru
reprezentarea particularitilor temporale i modului de acceptare a mesajelor se
utilizeaz diagrama de secven.
n al doilea rnd pot fi cercetate particularitile structurale ale colaborrii ntre
obiecte. Pentru reprezentarea particularitilor de transmitere i acceptare a mesajelor
ntre obiecte se utilizeaz diagrama de colaborare.
Obiecte
n diagrama de secven se reprezint numai obiectele care ac ioneaz i nu se
reflect asocierile statice cu alte obiecte. Pentru diagrama de secven momentul
principal este dinamica colaborrii ntre obiecte n timp. Grafic fiecare obiect se
reprezint printr-un dreptunghi i se plaseaz n partea de sus a ciclului su de via
(fig. 54). n interiorul dreptunghiului se indic numele obiectului i numele clasei
desprite prin dou puncte. Totodat toat nregistrare se subliniaz, ce indic c
obiectul este exemplarul unei clase.
A dou msur a diagramei de secven este axa vertical de timp (din sus n
jos). Momentului iniial de timp i corespunde partea de sus al diagramei. Totodat
colaborarea obiectelor este realizat prin mesajele transferate. Mesajele se reprezint
sub forma de sgei drepte cu numele mesajelor, ele de asemenea sunt ntr-o ordine
anumit n timp. Cu alte cuvinte, mesajele plasate n diagrama de secven mai sus
sunt iniiate mai devreme dect cele din jos. Totodat propor iile pe axa temporal nu
se indic fiindc diagrama de secven modeleaz doar ordonarea n timp a
legturilor de tip mai devrememai trziu.
Linia de via al obiectului
Linia de via a obiectului (object lifeline) se reprezint printr-o linie vertical
punctat asociat cu un singur obiect n diagrama de secven. Linia de via
definete intervalul de timp n care obiectul exist i interacioneaz cu sistemul dat.
Obiecte aparte, dup terminarea activitii sale, pot fi distruse pentru eliberarea
resurselor alocate. Pentru aceste obiecte linia lor de via se rupe n momentul de
distrugere. Pentru reprezentarea momentului de distrugere al unui obiect n limbajul
35

UML se utilizeaz un simbol special sub forma de litera latin X. Mai jos de acest
simbol, linia punctat nu poate fi desenat fiindc obiectul n sistemul deja nu este i
acest obiect este exclus din toate interaciunile ulterioare.
Nu este obligatoriu a crea obiecte la momentul iniial de timp. Obiecte aparte
n sistemul dat pot fi create la necesitate, economisind resursele acestui sistem i
majornd randamentul lui. n acest caz dreptunghiul obiectului respectiv se
deseneaz n partea diagramei care corespunde momentului de creare a obiectului.
Focus control
n procesul de funcionare a sistemelor OO unele obiecte pot fi n stare activ
executnd aciuni anumite sau pot fi pasive ateptnd mesaje de la alte obiecte. Pentru
a evidenia obiectele active n limbajul UML se utilizeaz nota ia special focus
control (focus of control). Focus control se reprezint n form de dreptunghi sub ire,
latura de sus a cruia determin (reflect) nceputul activitii, latura de jos
terminaia focusului de control (activitii).
Mesaje
Scopul colaborrii n contextul limbajului UML const n specificarea
comunicaiei ntre o mulime de obiecte. Fiecare legtura se descrie cu o totalitate de
mesaje transferate cu care obiectele-participante se schimb. n acest sens mesajul
reprezint un fragment de informaie care este transferat de ctre un obiect altuia.
Totodat acceptarea mesajului iniializeaz anumite aciuni ndreptate spre rezolvarea
problemei de ctre obiectul cruia mesajul i este transferat.
Mesajele nu numai transmit informaia, ele presupun executarea aciunilor
ateptate de ctre obiectul acceptabil. Mesajele pot iniia executarea operaiilor de
ctre obiectul unei clase, dar parametrii acestor operaii sunt transferai mpreun cu
mesajul. n diagrama de secven toate mesajele sunt coordonate dup timpul de
apariie n sistemul modelat.
n context dat mesajul este destinat de ctre obiect care iniiaz sau transfer
mesajul ctre obiectul care l accept. Uneori expeditorul al unui mesaj este numit
client, dar destinatarul server. Totodat mesajul de la un anumit client este o cerin
a unui server. Reacia acestui server la cerina dup primirea mesajului presupune
executarea anumitor aciuni i transmiterea informaiei sub forma a unui mesaj ctre
client.

36

Stereotipuri de mesaje
n limbajul UML sunt presupuse numai aciuni standarde, care se execut la
primirea mesajului respectiv. Ele pot fi indicate n diagrama de secven sub forma de
stereotipuri lng mesaje respective. n acest caz ele se scriu n ghilimele. Se
utilizeaz notaiile urmtoare:
"call" invoc o operaie sau procedur a obiectului-destinatar;
"return" returneaz valoarea operaiei executate obiectului apelant;
"create" creaz alt obiect pentru executarea anumitor aciuni;
"destroy" distruge un obiect. Se transmite n caz dac este necesar a termina
aciunile din partea obiectului existent sau dac obiectul trebuie s elibereze resursele
alocate;
"send" trimite un semnal unui obiect care se iniializeaz asincron de ctre un
obiect i este acceptat de altul. Diferena ntre un semnal i un mesaj const n fapt c
semnalul trebuie s fie descris n clasa obiectul creia iniializeaz transmiterea lui.
Scopul lucrrii:
- Determinarea scenariilor;
- Obiectele ce interacioneaz;
- Mesajele (sincrone, asincrone);
- Elaborarea diagramei de secven;
- Utilizarea fragmentelor de reprezentare n diagrama de secven;
- Elaborarea diagramei de colaborare.

37

Diagrame de interaciune:
Acceptarea de ctre Moderator a cererii n ateptare

38

Postarea poeziei

39

Adugarea categoriei

Logarea

40

nregistrarea

Diagrama de colaborare

41

8. Modelul de activitate i de stare


Diagramele de activitate se folosesc pentru modelarea aspectelor dinamice ale
unui sistem, la diferite nivele: ncepnd de la nivelul business process, pana la
nivel de operaie a unei clase. Din acest motiv, n diagramele de activitate se folosesc
un numr mare de simboluri.
O diagrama de activitate poate reda paii unui proces de calcul, fluxul
controlului ntr-o operaie, execuia secvenial sau paralel a unor aciuni.
O aciune reprezint un singur pas ntr-o activitate: un calcul, gsirea unor
date, verificarea unor date, etc. O aciune se reprezint printr-un dreptunghi rotunjit
n care este nscris text (numele aciunii) n format liber.
Aciunile redate ntr-o diagrama de activitate pot fi executate de diferite
obiecte, care sunt active n acelai timp. Astfel, o diagrama de activitate poate reda, la
un nivel de detaliu mai ridicat, interaciunea dintre obiecte reprezentata printr-o
diagrama de secven.
Diagramele de tip statechart sunt utilizate pentru a specifica posibilele stri
prin care poate trece un obiect i modul n care se poate trece de la o stare la alta
(modelare work-flow-uri, modelare fluxuri de documente, diagrame de stri).
Trecerea de la o stare la alta este determinat de tranzaciile intermediare acestea corespund Aciunilor pe care le-am ntlnit la Activity Diagram (pn la
urm, Statechart Diagram reprezint un alt mod de a vedea un flux ce poate fi
modelat exclusiv prin Activity Diagram, inventat pentru a exprima mai elocvent
trecerile de la o stare la alta).

42

Diagrama de activitate trimite mesaj.

Diagrama de activitate a nregistrrii.

43

Diagrama de activitate a logrii:

Diagrama de stare a Poeziei.

44

45

Diagrama de activitate a postrii unui mesaj pe forum

46

Diagrama de activitate a adugrii unei poezii n favorite.

47

9. Modelul de componente
Proiectul complet al unui sistem al programului reprezint o totalitate de
modele ale reprezentrii logice i fizice care sunt coordonate ntre ele. n limbajul
UML, pentru reprezentarea fizic a unui model al sistemului sunt utilizate diagramele
de realizare care includ dou diagrame canonice: diagrama de componente i
diagrama de desfurare.
Pentru reprezentarea entitilor fizice, n limbajul UML se utilizeaz
componenta (component). Componenta realizeaz un set de interfee i desemneaz
elementele reprezentrii fizice ale unui model. Grafic, componenta se reprezint
printr-un dreptunghi. n interiorul acestui dreptunghi se indic numele componentei i
posibil informaia suplimentar. Reprezentarea acestui simbol variaz n dependen
de informaia asociat cu componenta dat.
Mai jos am reprezentat cteva fiiere importante a sistemul Portar literar de
poezii ce asigura funcionalitatea aplicaiei prin diagrama de componente.
Diagrama de componente:

48

10.Modelul de desfurare
Diagrama de desfurare descrie structura sistemului n momentul execuiei.
Ea prezint dispunerea fizic a diferitelor elemente hardware, numite noduri, care
intr n componena unui sistem i repartizarea programelor executabile pe aceste
elemente. n diagrama de desfurare se indic nodurile i conexiunile unui model.
Un nod este resursa care este disponibil n timpul execuiei unui sistem software i
reprezint un procesor sau un dispozitiv, pe care vor fi desfurate i executate
componentele sistemului.
Reprezentarea fizic a sistemului nu poate fi deplin, dac lipsete informaia
despre programele i metodele de realizare a calculului. Dac este elaborat un simplu
program care poate fi executat local la calculatorul utilizatorului fr introducerea
echipamentelor periferice i a resurselor, atunci nu este necesar elaborarea
diagramei adugtoare.
Pentru ca utilizatorul s poat accesa sistemul, adic aplicaia web, el are nevoie de
conexiune internet i o sistem de operare dotat cu browser. Aplicaia web este
situat pe un server web care este mereu activ mpreun cu baza de date care i
menine informaia necesar i d posibilitatea de a fi accesat oricnd i din orice loc
al lumii.
Diagrama de desfurare:

49

Concluzie:
Efectund lucrarea de curs am antrenat capacitile de dezvoltare a unui produs
software, trecnd prin toate etapele a procesului dat: analiz, arhitectur,
implimentare i testare.
Stabilind cerinele fa de aplicaia creat Portal literar de poezii, le-am
divizat n funcionale fa de vizitator, utilizator, moderator, administrator i nonfuncionale care rspund de restricii i vor aprecia funcionalitatea aplicaiei.
Cu ajutorul diagramei Use-case, am reprezentat vizualizarea logicocomportamental a funcionalitilor sistemului. Pe baza diagramei cazurilor de
utilizare am realizat clasele necesare pentru sistem stabilind relaiile dintre acestea,
de asemenea determinnd atributele i metodele claselor. Am atribuit legturi de
asociere, generalizare i agregare necesare, stabilind relaiile dintre acestea i
multiplicitile lor.
Deci am reprezentat structura i funciile sistemului ales. Fiecare diagram
ofer o perspectiv distinct a sistemului, dup cum sugereaz i denumirile lor. n
general toate diagramele ar permite implementarea sistemului i funcionarea
acestuia. Folosind instrumentul Enterprise Architect putem genera un aa zis schelet
al aplicaiei. Dezvoltarea sistemului a servit un bun nceput pentru iniierea n
abloanele de arhitecturi actuale.
50

Sistemul Portal literar de poezii nu este finalizat din punct de vedere c


el mai poate fi extins, adic pot fi adugate mai multe funcionaliti
suplimentare, care ar mri considerabil spectrul de utilizare a sistemului dat.
Astfel, tindem ca pe viitor s crem update-uri prin care va fi perfec ionat
aplicaia.

BIBLIOGRAFIE:
Ingineria Programrii E. Guuleac, D. Palii, I. urcanu.
ndrumar de laborator E. Guuleac.
Caiet de curs la Ingineria Programrii D. Palii
GOOGLE.COM Surse internet.
etc.

51

Anexa A Rezultatele obinute

52

Figura A.1 Pagina principal a site-ului

Figura A.2 Forma de autentificarea pe site

53

Figura A.3 Forma de nregistrare pe site

Figura A.4 Meniul din partea dreapt a site-ul (dup autentificare)

54

Figura

A.5
Forma de adugare a poeziei

55

Figura A.6 Categoriile de poezii

56

Figura A.7 Topul poeziilor (n dependen de vizualizri pe lun)

57

Anexa B Codul programului


Pagina index
header('Content-Type:text/html;charset=utf-8');
session_start();
include_once ("include/db_connect.php");
include_once ("include/func.php");
if(isset($_POST['langl'])) change_lang($_POST['langl']);
if($_SESSION['lang'] == '') {
$lang = 'ro';
$_SESSION['lang'] = $lang;
} else {
$lang = $_SESSION['lang'];
}
include_once('lang/'.$lang.'.php');
$view = empty($_GET['view']) ? 'index' : $_GET['view'];
switch($view)
{
case('index'):break;
case('categorii'):break;
case('categori'):break;
case('poezie'):break;
case('poezii'):break;
case('autori'):break;
case('autor'):break;
case('forum'):break;
case('tema'):break;
case('cabinet'):break;
case('reg'):break;
case('save_user'):break;
case('update_user'):break;
case('testreg'):break;
case('send_pass'):break;
case('search'):break;
case('posteaza'):break;
case('post'):break;
case('page'):break;
case('noi'):break;
case('meupo'):break;
case('mesaje'):break;
case('exit'):break;
case('drepturi'):break;
case('contact'):break;
case('all_users'):break;
case('adau_cat'):break;
case('accept'):break;
}
///title and meta key desk
if($view == "poezie"){ $desc = $_GET['poezie']; $nume = title_p($desc); }
else if($view == "tema"){ $desc = $_GET['f']; $nume = title_f($desc); }
else { $nume = 'PoeziiMd.Com - Poeziile inimii noastre'; }
include($_SERVER['DOCUMENT_ROOT'].'/views/layouts/index.php');
nregistrarea
class Inregistreaza_te{
58

public $loginn = NULL;


private $passwordn = NULL;
public $emailn = NULL;
public $avatarn = NULL;
public function inregistrare($loginn,$passwordn,$emailn,$avatarn) {
if (!empty($loginn) and !empty($passwordn) and !empty($emailn)){
$this->loginn = $loginn;
$this->passwordn = strrev(md5($passwordn))."b3p6f";
$this->emailn = $emailn;
$this->avatarn = $avatarn;
$result = mysql_query("SELECT id FROM users WHERE login='$this->loginn'");
$myrow = mysql_fetch_array($result);
if (!empty($myrow['id'])) {
return false;
} else {
$result2 = mysql_query ("INSERT INTO users
(login,password,avatar,email,date) VALUES('$this->loginn','$this->passwordn','$this>avatarn','$emailn',NOW())");
if ($result2=='TRUE'){
$result3 = mysql_query ("SELECT id FROM users WHERE login='$this>loginn'");
$myrow3 = mysql_fetch_array($result3);
$activation = md5($myrow3['id']).md5($this->loginn);
$subject = "1Confirmati inregistrarea";
$message = "1Salut, multumim pentru inregistrare ".$this->loginn."\n
Deschideti lincul pentru a confirma inregistrarea:\nhttp://curs/index.php?
view=activation&login=".$this->loginn."&code=".$activation."\nCu respect,\n
Administratorul curs";
mail($this->emailn, $subject, $message, "Content-type:text/plain;
Charset=utf-8\r\n");
return true;
} else {
return false;
}
}
} else {
return false;
}
}
}
Verificarea sesiei
class SesTrue{
protected static $seslogin = NULL;
protected static $sespassword = NULL;
protected static $loginvenit = NULL;
protected static $categorie = NULL;
//verificare sesie
static function sesie(){
if(!empty($_SESSION['login']) and !empty($_SESSION['password'])){
self::$seslogin = $_SESSION['login'];
self::$sespassword = $_SESSION['password'];
59

return self::$seslogin;
} else {
return false;
}
}
//selectare id user
static function idsesie(){
$log = self::sesie();
$res = mysql_query("SELECT id FROM users WHERE login='$log'");
$my = mysql_fetch_array($res);
return $my[id];
}
}
class AdmnTrue extends SesTrue{
//verificare admin moder user
static function adminmoderuser($loginvenit, $categorie){
self::$loginvenit = $loginvenit;
self::$categorie = $categorie;
if((SesTrue::sesie() == self::$loginvenit) and (isset(self::$loginvenit)) and
(isset(self::$categorie))){
if(self::$categorie == 1){
$activ = 1;
} else if(self::$categorie == 2){
$activ = 2;
} else if(self::$categorie == 3){
$activ = 3;
} else {
return false;
}
$log = self::$loginvenit;
$results = mysql_query("SELECT login, activation FROM users WHERE
login='{$log}' and activation='{$activ}' ");
if($rows = mysql_fetch_array($results)){
return true;
} else {
return false;
}
} else {
return false;
}
}
}
Sablonul sesiei
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>PoeziiMd.Com<?=titlu_p($view);?></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="keywords" content="<?=$nume;?>"/>
<meta name="description" content="<?=$nume;?>"/>
60

<? include($_SERVER['DOCUMENT_ROOT'].'/views/addpages/head.php'); ?>


</head>
<body>
<div id="lang">
<form action="" method="post">
<input type="hidden" name="langl" value="ro" />
<input type="image" name="change_lang" src='images/moldova.png'<?
if($_SESSION['lang'] == 'ro') echo "class='lang-active'";?> />
</form></div><div id="lang1">
<form action="" method="post">
<input type="hidden" name="langl" value="ru" />
<input type="image" name="change_lang" src='images/rusia.png' <?
if($_SESSION['lang'] == 'ru') echo "class='lang1-active'";?> />
</form>
</div>
<? include($_SERVER['DOCUMENT_ROOT'].'/views/addpages/header.php'); ?>
<section id="content">
<div class="container_12 top-1">
<? include($_SERVER['DOCUMENT_ROOT'].'/views/addpages/left.php'); ?>
<div class="grid_4"><div class="left-1">
<div class="wrap">
<? include($_SERVER['DOCUMENT_ROOT'].'/views/pages/'.$view.'.php');
?>
</div>
</div> </div>
<? include($_SERVER['DOCUMENT_ROOT'].'/views/addpages/right.php'); ?>
<div class="clear"></div>
</div>
</section>
<? include($_SERVER['DOCUMENT_ROOT'].'/views/addpages/footer.php'); ?>
</body>
</html>

61

i
ii
iii