CuprinsIntroducere31. Iniierea n Ingineria Programrii41.1 Atributele cheie ale unui produs41.2 Faze fundamentale ale metodologiilor ingineriei programrii42. Limbajul UML52.1UML. Consideraii teoretice52.2Reguli de proiectare a unui sistem62.3 Metodologia Spiral 72.4Limbajul unificat de modelare UML n decursul anilor102.5Modelarea n UML112.6Analiza unei aplicaii implic realizarea mai multor categorii de modele122.7Principalele pri ale UML123. Planul de dezvoltare a proiectului. Diagrama Gantt134. Modelul de analiz154.1 Documentul cerinelor164.2Descriere general174.3 Cerine de sistem174.4Diagramele cerinelor sistemului235. Modelul Use-Case275.1 Cazurile de utilizare295.2Diagrama Use-Case pentru sistemul ,,Portal literar de Poezii316. Modelul de domeniu327. Modelul de interaciune358. Modelul de activitate i de stare429. Modelul de componente4710. Modelul de desfurare48Concluzie49Bibliografie50Anexa A51Anexa B56

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 programriiIngineria 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 programrii1) Analiza ce dorim s construim 2) Proiectarea cum vom construi 3) Implementarea construirea propriu zis 4) Testarea asigurarea calitii 2.Limbajul UML

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 notaia 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: consistena 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 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 SpiralMetodologia spiral este un exemplu bine cunoscut de metodologie a ingineriei programrii. Acest model ncearc s rezolve problemele modelului n cascad, 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. Obiective, alternative, constrngeri2. Analiza riscului i prototipul3. Conceperea operaiilor4. Cerinele i planul ciclului de via5. Obiective, alternative, constrngeri6. Analiza riscului i prototipulCiclul 2 Analiza final:7. Simulare, modele, benchmark-uri8. Cerine software i validare9. Plan de dezvoltare10. Obiective, alternative, constrngeri11. Analiza riscului i prototipulCiclul 3 Proiectarea:12. Simulare, modele, benchmark-uri13. Proiectarea produsului software, validare i verificare14. Integrare i plan de test15. Obiective, alternative, constrngeri16. Analiza riscului i prototipul operaionalCiclul 4 Implementarea i testarea:17. Simulare, modele, benchmark-uri18. Proiectare detaliat19. Cod20. Integrarea unitilor i testarea acceptrii21. Lansarea produsuluiProcesul 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 anilorUML 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 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 Software[endnoteRef:1], 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, Hewlet-Packard, IBM, Microsoft, Oracle, Rational, Texas Instruments etc. [1: ]

UML 1.0 a fost propus spre standardizare n cadrul OMG (Object Management Group)[endnoteRef:2] 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. [2: ]

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 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:2005[endnoteRef:3] 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. [3: ]

2.5.Modelarea n UMLConceptele 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 oreprezentare 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 cetrebuie parcurse:a) faza de analiz- surprinde necesitile sistemului imodeleaz clasele debaz din "lumea real" icolaborrile dintre acestea.b) faza de design - se detaliaz modelul din faza deanaliz i se formuleaz o soluie tehnic lund n considerare caracteristicile mediului ncare 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 modelea) Modelul de utilizare - realizeaz modelarea problemelor i asoluiilor acestora n maniera n care le percepe utilizatorul final al aplicaiei. Diagram asociat: diagramde cazuri de utilizareb) Modelul structural: se realizeaz pe baza analizei statice aproblemei i descrieproprietile statice ale entitilorcare compun domeniul problemei. Diagrame asociate: diagram de module, diagram de clase.c) Modelul comportamental: privete descrierea funcionalitiilor i a succesiunii ntimp a aciunilor realizate de entitiledomeniului problemei.Diagrame asociate: diagrama(harta) de stri, diagrama de colaborare, diagrama de interaciune.

2.7. Principalele pri ale UML1) 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 ntreacestea: asocierea, dependena, generalizarea. Un element de modelarepoate 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 proiectuluiUn 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.n timpul desfurrii unui proiect, diagrama Gantt ajut la monitorizarea proiectului respectiv i arat dac acesta se ncadreaz n plan.

Diagrama Gant:

Estimrile lucrrilorEstimarea proiectului reprezint planificarea timpului de dezvoltare a aplicaiei pentru realizarea funcionalitii cerute de client.Estimarea proiectului se va face avnd n vedere lista funcionalitii 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 proiecte) Atacurile rufctorilor atacurile asupra sistemului care poate provoca tergerea sau modificarea informaiei din baza de date.

4. Modelul de analiz4.1. Documentul cerinelorLucrarea dat presupune dezvoltarea produsului care este: Portal literar de poezii. Adic, una din funcionalitile de baz a aplicaiei este accesul la un website 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 documentuluiAcest 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 cerine similare. Utilizatorii nregistrai ct i oaspeii pot folosi acest document pentru testarea cerinelor descrise.4.1.2. Scopul proiectuluiProdusul 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 cerinele sistemului, dar dac se va nregistra va fi un utilizator cu drepturi, cerine i funcionaliti corespunztoare.

4.1.3. Definiii, acronime, abrevieri i notaiiHtml- 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.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 informaiile (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 vizitatoruluiU1, U2 - cerinele utilizatoruluiM1, M2 - cerinele moderatoruluiA1, A2 - cerinele administratoruluiS1, S2... cerinele fa de sistem nefuncionaleAJAX 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 uor de nvat i o robust compatibilitate ntre platforme ntr-un singur fiier compact.

4.1.4.Referintehttps://www.google.com/http://jquery.comhttp://css3.me

4.2. Descriere generalInterfaa 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 simplitii 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/poei 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 sistem4.3.1. Cerine funcionale ale vizitatoruluiV1 vizualizare poeziiV2 like poeziiV3 search V4 nregistrare:Introducerea informaie : email, parola, nickname, avatarAutologare dup confirmarea email4.3.2. Cerine funcionale ale utilizatoruluiU1 Logare a) Introducere login/email b) introducerea parolei

U2 Postarea poeziei a) postarea poeziei b) modificarea poeziei c) tergerea poeziei d) adugare comentariu U3 votarea autorilor U4 like poeziiU5 delogareU6 sortarea poeziilor cutate: a) sortarea dup dat b) sortarea dup nume c) sortarea dup vizualizri 4.3.3. Cerine funcionale ale moderatoruluiM1 acceptare / refuz poezieM2 modific drepturile utilizatoruluiM3 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 comentariu4.3.4. Cerine funcionale ale administratorului:A1 Logare: a) Introducere login/email b) introducerea paroleiA2 Privilegii: a) acceptare / refuz poezie b) modific avatarul unui utilizator cu cel predefinit c) modific drepturile utilizatoruluiA3 Categorii: a) crearea unei categorii noi 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 comentariuA6 delogare

4.3.5. Cerinele non-funcionale fa de sistem (restricii):S1 acces la baza de dateS2 completarea cmpurilor obligatoriiS3 email unicS4 fiabilitateS5 securitateS6 suport CROSS-BrowserS7 verificarea sesiunii

4.3.6. Constrngeri de DesignCerine 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 utilizatoruluiU1 Logare a) Introducere login/email b) introducerea parolei

U2 Postarea poeziei a) postarea poeziei b) modificarea poeziei c) tergerea poeziei d) adugare comentariuU3 votarea autorilorU4 like poeziiU5 delogareU6 sortarea poeziilor cutate: a) sortarea dup dat b) sortarea dup nume c) sortarea dup vizualizri

4.3.8. Cerine funcionale ale moderatoruluiM1 acceptare / refuz poezieM2 modific drepturile utilizatoruluiM3 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 comentariu4.3.9. Cerine funcionale ale administratorului:A1 Logare: a) Introducere login/email b) introducerea paroleiA2 Privilegii: a) acceptare / refuz poezie b) modific avatarul unui utilizator cu cel predefinit c) modific drepturile utilizatoruluiA3 Categorii: a) crearea unei categorii noi 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 comentariuA6 delogare

4.3.10. Cerinele non-funcionale fa de sistem (restricii):S1 acces la baza de dateS2 completarea cmpurilor obligatoriiS3 email unicS4 fiabilitateS5 securitateS6 suport CROSS-BrowserS7 verificarea sesiunii

4.3.11. Constrngeri de DesignCerine HARDDatorit 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.12. Atributele sistemului softwarencredere: 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 apariie a unei erori s fie prentmpinat de administrator.

4.4.Diagramele cerinelor sistemuluiDiagrama de cerine funcionale i non-funcionale

Diagrama cerinelor funcionale

Diagrama cerinelor fa de administratorDiagrama cerinelor fa de moderator

Diagrama cerinelor fa de oaspei Diagrama cerinelor fa de utilizatori

5.Modelul Use-CaseDiagrama 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 cerinele ctre sistem din punct de vedere al utilizatorului. Variantele de utilizare snt funciile 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.

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 3. Cazurile de utilizare 4. Relaiile Sistemul. Notaia grafic a sistemului reprezint un dreptunghi cu numele sistemului proiectat indicat n interiorul dreptunghiului.

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:Trimite mesaj administratoruluinregistrare Cutarea cutarea poeziei, utilizatorului i a temelor de pe forumSortarea poeziei dup dat, vizualizare i categorieVizualizarea poezieiLike la poezie Logarea autentificarea utilizatorului/moderatorului/administratoruluiDelogare sfrirea sesiunii Adugarea unei noi teme pe forumCabinet personal cabinetul personal a utilizatorului/moderatorului/administratorului Voteaz autorii posibilitatea de a vota un autor printr-o notAdaug o poezie posibilitatea utilizatorului/moderatorului/administratorului de a posta o poezieterge poezia personalEditeaz poezia personalAccept poezii posibilitatea moderatorului i al administratorului de a accepta poeziile postate de utilizatoriModific avatar predefinit pot modifica avatarul oricrui utilizator doar moderatorul i administratorulAdaug 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 administratorulAdaug categorii administratorul poate crea noi categorii de poezii tergerea categoriei tergerea unei categorii de poezie de ctre administratorEditarea categoriei editarea unei categorii de poezie de ctre administratorModificare 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 eiterge utilizator terge poezie - tergerea poeziei a oricrui autor

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

6. Modelul de domeniuUn 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 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.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 conine 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); / 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 definete 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 claseiNumele clasei trebuie s fie unic n cadrul pachetului, care este descris de ctre o totalitate de diagrame de clase. Numele se indic n prima seciune 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.

Diagrama de clase:

7. Modelul de interaciunen 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 acioneaz 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 proporiile 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 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 notaia special focus control (focus of control). Focus control se reprezint n form de dreptunghi subire, 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.

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.

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

Postarea poeziei

Adugarea categoriei

Logarea

nregistrarea

Diagrama de colaborare

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 tipstatechartsunt 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).

Diagrama de activitate trimite mesaj. Diagrama de activitate a nregistrrii.

Diagrama de activitate a logrii:

Diagrama de stare a Poeziei.

Diagrama de activitate a postrii unui mesaj pe forum Diagrama de activitate a adugrii unei poezii n favorite.

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:

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:

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 non-funcionale care rspund de restricii i vor aprecia funcionalitatea aplicaiei.Cu ajutorul diagramei Use-case, am reprezentat vizualizarea logico-comportamental 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. 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 perfecionat aplicaia.

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

Anexa A Rezultatele obinute

Figura A.1 Pagina principal a site-ului

Figura A.2 Forma de autentificarea pe site

Figura A.3 Forma de nregistrare pe site

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

Figura A.5 Forma de adugare a poeziei

Figura A.6 Categoriile de poezii

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

Anexa B Codul programuluiPagina indexheader('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');nregistrareaclass Inregistreaza_te{ 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 sesieiclass 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']; 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

PoeziiMd.Com