3.3 Cerinte interfete intercomponente
1.1 Scopul documentului
Acest document descrie cerintele generale in cadrul proiectului yPortal. Documentul se adreseaza atat clientului acestui proiect cat si dezvoltatorului care pe baza acestui proiect va realiza documentul de specificatie.
In continuare se descrie proiectul (2.Descriere generala), apoi in sectiunea 3 se specifica cerintele.
Se doreste realizarea unui portal de informatii. Ca demonstratie a functionalitatii intregului framework, se va realiza si o aplicatie practica pentru acest portal: portal pentru toti oamenii dintr-o facultate (pentru inceput utlizatorii sa fie doar profesori-elevi).
Frameworkul pentru portal va avea denumirea yPortal.
Portalul implementat pentru facultate se va numi yUniversity.
2.3.1 La ora actuala nu exista un mod uniform de a accesa resursele unei facultati (cel putin nu pentru UPB).
2.3.2 Practica de a realiza pagini statice cu prezentari ale facultatii nu face fata ritmului dinamic de aparitie si disparitie a informatiilor ce circula in cadrul facultatii.
2.3.3 Deasemenea modul de prezentare a cursurilor si de folosire a web-ului pentru anuntarea temelor si preluarea lor este unul neuniform si de cele mai multe ori greoi.
Se doreste rezolvarea tuturor acestor probleme prin implementarea acestui portal. Acesta permite
2.4.1 Tratarea intr-un mod uniform a informatiilor care privesc studentii si profesorii din cadrul facultatii.
2.4.2 Diminuarea efortului pentru intretinerea acestor informatii.
2.4.3 Evolutia permanenta atat ca forma, cat si ca continut a intregului portal, deoarece dezvoltarea se va face usor prin intermediul acestor pluginuri care vor avea o specificatie standard si open, pentru care oricine va putea scrie noi functionalitati.
2.4.4 In timp se vor putea scrie si pluginuri (portleti) care sa poata face o customizare a contentului fiecarui utilizator al portalului.
Aplicatia va fi instalata pe un server de web care va avea urmatoarele aplicatii instalate: apache(server de web), tomcat(server de aplicatii), mysql(server de baza de date), java runtime (j2sdk1.4 si j2sdkee1.3). Aceste aplicatii exista atat in versiune de windows cat si de linux, alegerea sistemului de operare ramanand la latitudinea clientului.
In configuratie minimala trebuie sa existe un server pe care sa ruleze toate aceste aplicatii: un PC de nivel PIII la minim 800MHz.
Arhitectura de baza este una specifica web n-tier, cu nivelele: client, server web, server aplicatii, baza de date. In princpial clientul se conecteaza in acelasi punct mereu, continutul paginii fiind generat dinamic, in functie de configurarea portalului, de rolul userului, eventual de alte optiuni. Configurarea se face doar pentru a specifica ce portleti vor fi rulati, eventual in ce portlet de layout vor fi cuprinsi.
Exista mai multe roluri pentru utilizatorii portalului:
3.2.1 Administrator
Acesta este cel care instaleaza portalul si care va putea sa faca administrarea de la distanta. Anumiti portleti necesita un astfel de rol. De exemplu cei care modifica fisiere de configurare ale portalului.
3.2.2 Utilizator
Acesta este un utilizator obisnuit al portalului. Orice implementare de portal insa va putea sa-si creeze rolurile sale, asociate cu anumite drepturi. De exemplu pentru portalul yUniversity, se vor creea cel putin 2 roluri: profesor, student.
3.3 Cerinte interfete intercomponente
Nu sunt specificate cerinte suplimentare pentru containerul de portleti, in afara realizarii unei specificatii de interfata standard care sa permita configurarea, incarcarea, rularea la runtime a acestor portleti.
3.3.1 Acestia trebuie sa poata publica o serie de informatii despre ei:
- Identificator
- Nume
- Provider
3.3.2 Portletii pot functiona in mai multe moduri
- Configurare – Afiseaza un content care sa permita modificarea proprietatilor portletului. In lipsa acestuia portalul (containerul de portleti) va genera unul automat pe baza listei publice a proprietatilor portletilor. Acest modul trebuie sa permita si salvarea/incarcarea a unor configuratii mai vechi.
- Selectie/Afisare - Afiseaza continutul specific lor.
- Insert/Update/Delete - Prezinta datele intr-un format care sa permita adaugarea/modificarea/stergerea lor.
Pentru portal nu exista deocamdata nici o cerinta functionala. Din punctul de vedere al clientrului el trebuie sa fie un container care sa respecte interfetele cu portletii care vor fi ceruti pentru dezvoltare ulterior. Acestea se vor specifica intr-un mod oficial la cerinta expresa a clientului la inceputul unui ciclu de iteratie in care se cere realizarea respectivei interfete pentru un anumit portlet.
Totusi pentru o evaluare a timpului si resurselor necesare in ansamblu sunt specificati cativa portleti care ar putea fi ceruti de catre client:
3.4.1 portleti generici
-
portlet welcome
-
portlet contact
-
portlet login
-
portlet reclama
-
portlet meniu
-
portlet generic insert/update/select informatii din baza de date (i se
da doar tabela) - va fi folosit ca prim model pentru orice alt portlet, bazat
pe baza de date, customizat.
-
portlet anunturi1 ( specializare a portletului generic pe o tabela
anunturi )
-
portlet anunturi2 ( rescriere (alta interfata) pentru acces specific la
tabela anunturi )
-
portlet upload
-
portleti de layout
3.4.2 portleti specifici
-
portlet universitate (listeaza facultatile)
-
portlet facultate (listeaza specializarile)
-
portlet specializari (listeaza materii/pe ani)
-
portlet materie (curs/seminar/laborator)
-
contact
-
anunturi
-
note
-
referinte
-
portlet teme
-
enunturi
-
upload
-
note
Pentru portal nu exista deocamdata nici o interfata specificata. Acestea se vor specifica intr-un mod oficial la cerinta expresa a clientului la inceputul unui ciclu de iteratie in care se cere realizarea respectivei interfete pentru un anumit portlet.
Baza de date va fi mysql. Nu se prevede o schimbare a bazei de date folosite in viitorul apropiat. Totusi e posibil ca, in momentul cand aceasta baza de date nu va mai face fata incarcarii, sa fie folosita o alta baza de date tot cu acces prin sql (Oracle, SQLServer).
Unii portletii vor avea acces la baza de date. Containerul nu are nevoie de acces la baza de date.
Se va creea un model de bd in momentul in care clientul da un task pentru realizarea unui portlet care are un model de baza de date in spate.
3.7.1 Incarcare minima
Portalul trebuie sa poata suporta o incarcare minima de 100 de useri logati in sistem fara ca acest lucru sa scada semnificativ viteza de lucru.
3.7.2 Scalabilitate
Aplicatia trebuie sa poata fi rulata ulterior si pe mai multe servere in caz ca numarul de utilizatori creste.
3.7.3 Portabilitate
Aplicatia trebuie sa poata rula pe un server avand la baza un sistem de operare windows (win98,winnt,win2000) cat si unix/linux (redhat,suse).
3.7.4 Usurinta in exploatare
Aplicatia trebuie sa dispuna de un kit de instalare. Pentru inceput nu este necesara creearea unei interfete pentru administrarea integrala a aplicatiei. Dupa instalare prin intermediul kitului, aplicatia trebuie sa fie insa intr-o stare default care sa nu necesite absolut nici o configurare suplimentara.
3.8.1 Schimbarea cerintelor utilizator
Deoarece mediul in care se foloseste aceasta aplicatie este foarte dinamic, cerintele pot sa fie schimbate din mers. Deasemenea prioritatea acordata lor poate fi schimbata. Deasemenea se pot adauga sau/si anula altele. Acest lucru nu trebuie sa duca la penalizari sau costuri suplimentare mari atasate produsului.
3.8.2 Evolutie
Acest produs va evolua permanent, in principal prin dezvoltarea de noi pluginuri care vor trebui sa se integreze usor cu o aplicatie deja instalata. Se prevede si posibilitatea ca in viitor acestea sa poata fi uploadate de utiliztori, sau sa fie preluate automat de la anumite locatii de web.