Sfaturi pentru realizarea proiectului

1 Introducere
Proiectul trebuie s ofere o soluie pentru urmtorul enun de problem. Echipa proiectului va folosi metodologia Agile Model Driven Development (AMDD) 1 descris mai jos. Figura 1 ilustreaz ciclul de via AMDD pentru dezvoltarea unui sistem software.

Figura 1 Activiti

Figura 2 Ciclul de dezvoltare: iteraii i jaloane (milestones)

Figura 2 arat cum se planific activitile AMDD i jaloanele (milestones) pe durata ciclului de dezvoltare a sistemului.
1

Scott W. Ambler. Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development . http://www.agilemodeling.com/essays/amdd.htm

2 Pornirea (Initial setup)

Activitile iniiale (de pornire) i de planificare se vor realiza n prima edin de laborator. Trebuie s se stabileasc urmtoarele roluri care vor fi scrise n documentele project vision (viziunea proiectului) i project plan (planul proiectului): Stakeholder (S) grupuri de oameni ale cror nevoi (interese) trebuie satisfcute prin realizarea proiectului (ex. conductorul de laborator); Project Manager (PM) conduce planificarea proiectului, coordoneaz interaciunea cu S i are grij ca echipa proiectului s fie bine focalizat pe realizarea obiectivelor acestuia. Developer (D) dezvolt (inclusiv proiectarea) o parte a sistemului, astfel ca aceasta s se ncadreze n arhitectura general; activiti posibile de specializat - prototipizarea interfeei cu utilizatorul, implementarea, testarea unitar i de integrare a componentelor (de interfa, de domeniu i de acces la date) care formeaz soluia. Team Leader (TL) are responsabilitile unui D i n plus coordoneaz o echip de D care lucreaz la un subsistem (strat); subsisteme posibile - interfaa cu utilizatorul, domeniu (business), acces la date. Pentru detalii suplimentare despre rolurile de mai sus, putei consulta documentaia OpenUP2 (Open Unified Process). Artefactele proiectului (documente i cod) vor fi gestionate folosind un SVN 3 Repository (version control system, sistem de control al versiunilor). Fiecare grup are propriul su depozit (repository): https://www.scs.ubbcluj.ro/svn/gr221a, https://www.scs.ubbcluj.ro/svn/gr221a, etc. Conductorii de laborator trebuie s comunice lista membrilor echipei proiectului d-lui lector dr. Ioan Lazr ilazar@cs.ubbcluj.ro pentru configurarea drepturilor de acces ale D la depozitele de date. D vor putea accesa depozitele SVN folosind numele de user i parolele SCS. Pentru gestiunea sarcinilor proiectului i a defectelor se va folosi sistemul de urmrire a defectelor Bugzilla4 (defect tracking system). Un document separat va descrie modul de accesare i folosire a acestui sistem.

3 Modelarea iniial (Initial Modeling)

Iteraia de modelare iniial se realizeaz n prima sptmn a proiectului sau n primele dou sptmni pentru proiecte mari. Scopul acesteia este s: Identifice obiectivul general al proiectului; Identifice lista iniial de cerine; Identifice o viziune arhitectural.

3.1 Modele de folosire (Usage Models)

Aceste modele descriu cum vor lucra utilizatorii cu sistemul software. O list de caracteristici (nevoi) este dat n enunul problemei. (A) [Lista de cerine Requirements list] Scriei o list de cerine plecnd de la lista de caracteristici Caracteristicile sunt pentru clieni/stakeholders, cerinele sunt pentru D.
2 3

OpenUP, http://epf.eclipse.org/wikis/openup/ Subversion, http://subversion.tigris.org/ 4 Bugzilla, http://www.bugzilla.org/

Definii o cerin la un moment dat. Evitai conjunciile (i, sau) care includ mai multe cerine ntr-o singur fraz. nainte de scrierea cerinei, definii toate entitile implicate i toi actorii implicai (substantive la singular). Cerina se exprim sub form de propoziie complet, cu subiect (entitate sau actor) i predicat (verb). Exemple: Profesor evalueaz o Tem; Un Student este nscris la mai multe Cursuri. (B) Capturai i cerinele de sprijin (supporting requirements, ex. Business Rules) dup cum se descrie n ablonul de cerine de sprijin. (C) [Modelul de cazuri de utilizare (Use Case Model)] Realizai modelul cazurilor de utilizare MCU MCU este un model al cazurilor de utilizare sistem, coninnd cazuri de utilizare, actori i relaiile dintre acestea (acetia). (D) Detaliai unele cazuri, scriind scenarii. Folosii urmtorul ablon de descriere a cazurilor de utilizare. Unele CU trebuie descrise mai detaliat pentru validarea sau mai buna nelegere a unei cerine i pentru a oferi D un punct de plecare n munca sa. n acest moment se detaliaz doar CU care sunt semnificative din punctul de vedere al arhitecturii sau cele considerate importante (li se d o prioritate mare) de ctre stakeholders. (E) [Modelul iniial al domeniului, MID Initial Domain Model] Definii un model conceptual dac acesta ajut la obinerea unei imagini de ansamblu (big picture) asupra entitilor din domeniul problemei (business entities) i a relaiilor dintre acestea. MID trebuie s fie uor de neles de ctre stakeholder. n acest moment MID conine doar entitile (obiectele) care reprezint elementele eseniale ale domeniului problemei i relaiile dintre ele.

3.2 Modelarea iniial a arhitecturii Initial (Architectural Modeling)

(F) Identificai o (un stil de) arhitectur care pare potrivit pentru sistem. Documentai architectura aleas folosind urmtorul ablon de arhitectur. Trebuie stabilit cel puin arhitectura logic organizarea n mare a claselor n pachete (sau namespaces), subsisteme i straturi (layers). Se recomand o arhitectur stratificat pentru arhitectura logic.

3.3 Planificarea proiectului (Project Planning)

(G) Planificarea iteraiilor. Mapai cerinele pe iteraii de dezvoltare (asociai fiecrei iteraii cerinele pe care le include). Documentai maparea n documentul de plan al proiectului.

4 Iteraii de dezvoltare (Development Iterations)

4.1 Modelarea iteraiilor (Iteration Modeling)
Scopul acestei activiti este determinarea sarcinilor aferente iteraiei curente i atribuirea acestor sarcini la D vezi Figura 4. La aceast activitate particip toat echipa. PM i TL atribuie

sarcinile la D. Informaia de proiectare obinut se trece n documentul ablon de proiect. (A) Rafinarea modelului domeniului (Refine the domain model). Modelai entitile implicate n scenariile din iteraia curent. (B) Determinarea comportamentului sistemului (Determine the system behavior). Desenai cte o diagram de secven sistem pentru fiecare scenariu (Write a system sequence diagram for each scenario) o Se identific operaiile sistem (system public interface). o Metodele trebuie scrise folosind obiectele din domeniu. Scriei contractele operaiilor sistem (Write system operation contracts) o Nume, descriere, pre/post condiii pentru each operation.

Figure 3 Modelarea iteraiilor Iteration Modeling

(C) Modelarea controlerelor i a serviciilor (Model controllers and services) Aplicai ablonul GRASP Controller i abloanele indicate de arhitectura logic stabilit. Atribuii operaiile sistem la obiectele Controler Stabilii serviciile folosite de obiectele Controler (D) Scrierea unei liste de sarcini de lucru dup ablonul de sarcini de lucru. Sarcinile de lucru se exprim folosind o obiectele Controller, serviciile i obiectele de domeniu proiectate o obiectele de acces la date (data access objects) asociate obiectelor de domeniu nou proiectate, n concordan cu arhitectura logic stabilit o ferestrele (vederile, views) necesare (proiectate) pentru iteraia curent vederile vor apela metodele obiectelor Controller Va fi nevoie de mai multe edine de mbuntire a modelului, deoarece dup o singur iteraie nu se produce un proiect complet.

4.2 edine de mbuntire a modelului (Model Storming Sessions)

(E) Dezvoltarea unei diagrame de secven pentru fiecsare operaie sistem (non-trivial) Develop a sequence diagram for each (non-trivial) system operation (operaie controller).

o Aplicai abloanele GRASP (General Responsibility Assignment Patterns). o D proiecteaz depozitele de date (repositories), regulile de validare i toate celelalte obiecte din domeniu necesare. o Proiectarea se face de ctre D care i s-a atribuit implementarea operaiei sistem n cauz. o Informaia de proiectare obinut se trece n documentul ablon de proiect. (F) Actualizarea diagramei de clase de proiectare (Update Software Class Diagram). o Se adaug metode la clasele existente o Se rafineaz asocierile

Figura 4 Extras din arhitectura logic pentru Model Storming

4.3 Dezvoltarea dirijat de teste (Test Driven Development TDD)

Figure 6 ilustreaz paii TDD. Recomandm citirea Spring MVC tutorial5 pentru detalii.

Thomas Risberg. Developing a Spring Framework MVC application step-by-step. 2005. http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step-by-step.html

Figura 5 TDD

5 Jaloane / Puncte de verificare (Milestones)

La jaloanele prevzute pentru proiect se vor verifica (i nota) urmtoarele criterii: o Jalonul Objectives: o Definirea obiectivului general (scope) o Estimri de orar de derulare o Definiii i prioriti pentru setul iniial de cerine o Riscurile identificate i strategiile de contingen propuse o Jalonul Architecture: o Viziunea, cerinele i arhitectura sunt stabile o Elementele majore de risc sunt identificate i rezolvate prin testarea i evaluarea prototipurilor executabile o Sunt de acord c viziunea curent se poate concretiza (realiza) dac planurile stabilite sunt respectate pentru dezvoltarea unui sistem complet peste (cu) arhitectura stabilit o Jalonul Operational Capability: o Versiunea realizat este stabil i suficient de matur pentru a fi distribuit utilizatorilor o Sistemul include toat funcionalitatea prevzut i testarea alfa s-a terminat cu succes o S-a scris un manual de utilizare i o descriere a versiunii curente o Jalonul Product Release: o Satisfacia utilizatoruilor i acceptarea produsului