Modelarea

Coninutul capitolului : Noiunea de modelare Modelul Cascad Modelul V Modelul Incremental Modelul Spiral Extreme Programming Obiective: a. b. c. d. e. nelegerea noiunii de modelare Aprofundarea modelului V. Aprofundarea modelului Incremental Aprofundarea modelului Spiral. Aprofundarea modelului Extreme Programming.

Recomandri privind studiul: Studierea modelelor prezentate n vederea utilizrii lor pe parcursul celorlalte capitole. Asimilarea conceptelor de baz legate de modele i de tipurile de modele care sunt necesare n capitolele urmtoare Rezultate ateptate: Studenii trebuie s fie capabili s i prezinte cunotinele teoretice de natur coerent i consistent. Studenii trebuie s poat prezenta orice model studiat. ntrebri:

a. Ce este un model?
b. c. d. e. Prezentai modelul V. Prezentai modelul Incremental Prezentai modelul Spiral. Prezentai modelul Extreme Programming. Realizai o paralel ntre oricare dou tipuri de modele i prezentai argumente pro i contrare n favoarea utilizrii unuia sau celuilalt.

f.

Modelarea
Modelarea: metod utilizat n tiin i tehnic constnd n reproducerea schematic a unui obiect sau sistem sub forma unui sistem similar sau analog n scopul studierii proprietilor i transformrilor sistemului original. Modelarea informaiilor = Obiecte + Atribute + Relaii + Supertipuri/Subtipuri +Obiecte asociative.

Modelul Cascadei
1) Cum a aparut Modelul Cascadei Modelul cascad este considerat ca fiind primul model introdus i folosit pe scar larg n ingineria soft. Inovaia introdus de acest model const n mprirea pentru ntia oar, a procesului de dezvoltare a programelor, n faze distincte. Modelul cascad impune o abordare sistematic, secvenial, a dezvoltrii softului, abordare care pornete de la sistem i parcurge etape de analiz, proiectare, programare, testare i ntreinere. Modelul are n vedere ntregul ciclu de via al produsului, exist evaluri pentru fiecare etap i posibiliti de revenire la etape sau de reluare a ciclului de via, ntr-o faz de evoluie ulterioar. Originea termenului cascad o gsim ntr-un articol publicat n anul 1970 de ctre W.W. Royce. Partea interesant este c Royce propunea n acel articol o abordare iterativ a dezvoltrii softului i nici mcar nu a folosit termenul de cascad, el descriind ceea ce azi cunoatem ca fiind modelul cascad ca fiind o metod riscant un adevrat magnet pentru erori. n ciuda inteniilor lui Royce de a modifica modelul cascad ntr-un model iterativ, utilizarea sa ca un proces pur secvenial este nc popular, iar pentru unii modelul cascad a ajuns s defineasc orice abordare inflexibil i non-iterativ de dezvoltare a produselor software. Majoritatea acestor persoane vd modelul cascad ca fiind naiv i nepotrivit pentru procesele din lumea real, i totui nu este chiar aa. 2) Fazele Modelului Cascad

DEFINIREA SI ANALIZA CERINTELOR

DESIGN-UL SISTEMULUI

Modelul Cascadei (The Waterfall Model)

DESIGN-UL SOFTWARE

IMPLEMENTAREA

INTEGRAREA VERIFICAREA SOFTWARE VERIFICAREA SISTEMULUI OPERAREA SI MENTINEREA

1. Definirea i analiza cerinelor (Requirement Analysis & Definition): Toate cerinele sistemului care trebuiesc ndeplinite sunt colectate n aceast faz. Ca i n alte modele de procese, cerinele sunt mprite n cerine funcionale i constrngeri pe care sistemul trebuie s le respecte. Cerinele trebuie s fie colectate prin analiza nevoilor clientului i verificarea lor pentru a fi valide i posibile de implementat. Scopul este generarea Documentului de Specificaie a Cerinelor care este utilizat ca i input pentru urmtoarea faz. 2. Design-ul sistemului (System Design): Sistemul trebuie s fie bine descris nainte ca implementarea s nceap. Aceasta implic un design arhitectural care definete i descrie principalele pri i componente ale sistemului, ale interfeei i interaciunilor. Cu aceasta hardware-ul necesar este definit i software-ul este mprit pe componente. Aceasta implic definirea sau selecia unei platforme, unui sistem de operare, a altor componente hardware periferice, etc. Componentele software trebuie s fie definite astfel inct s ntlneasc nevoile clienilor. Scopul acestei faze este de a genera un Document pentru Arhitectura Sistemului (System Arhitecture Document) care s serveasc ca i input pentru faza de design software a dezvoltrii, dar i ca input pentru design-ul hardware sau selecia activitilor. De obicei n aceast faz unele documente sunt generate, unul pentru fiecare disciplin, astfel nct software-ul va primi un document cu arhitectura software. 3. Design-ul Software (Software Design): Bazat pe arhitectura sistemului care a definit principalele pri software, design-ul software le va mpri n module de cod. Vor fi descrise interfeele i interaciunile modulelor precum i funcionalitile lor. Toate modurile sistemului (startup, shutdown, condiiile de eroare i diagnosticul) trebuie s fie luate in considerare dar i activitatea i strile acestuia trebuiesc definite. Output-ul acestei faze este un Document de Design Software care este i baza implementrii ce urmeaz a fi fcut. 4. Implementarea (Codarea=Coding): Bazat pe Documentul pentru Arhitectura Sistemului munca este de a seta modulele sau unitile definite i astfel procesul de codare ncepe. Sistemul este n primul rnd dezvoltat din pri mici numite unituri. Ele sunt independente, din punct de vedere funcional i sunt integrate apoi n pachetul software complet. 5. Integrarea i Verificarea Software (Software Integration & Verification): Fiecare unitate este prelucrat independent i poate fi testat pentru funcionalitatea sa. Aceasta se numete Testarea Unitii. Aceasta doar verific dac modulele sau uniturile se ncadreaz n specificaii. Aceasta implic teste funcionale la nivel de interfa a modulelor, dar i teste mai detailiate n structura intern a modulelor software. n timpul integrrii, uniturile care sunt prelucrate i testate pentru funcionalitile lor sunt combinate. Modulele sunt integrate ntr-un sistem complet i sunt testate pentru a vedea dac toate funcioneaz conform previziunilor. 6. Verificarea Sistemului (System Verification): Dup ce s-au obinut rezultatele bune la teste asupra sitemului complet acestea se confrunt cu cerinele iniiale. Aceasta va include hardware-ul i mediul original. 7. Operarea i meninerea (Operation & Maintenance): Sistemul este predat clientului care l va utiliza pentru prima dat. Clientul va verifica dac cerinele lui au fost implementate dar i dac acestea sunt cele iniiale. n cazul n care trebuie s se fac schimbri se vor face astfel nct sistemul s fie utilizabil i s ndeplineasc dorinele clientului. 3) Avantaje si Dezavantaje Avantaje: Controlul total asupra fazelor Uor de nsuit de ctre membrii echipei de proiectare Fiecare faz este nsoit de o documentaie complet Dezavantaje: Sistemul poate fi predat dup parcurgerea etapelor, deci necesit mult timp de lucru Nu corespunde inteniilor de abordare dinamic Nu este deschis schimbrilor ce apar pe parcurs

Este ntr-o contradicie flagrant cu procesul liber, prin ncercri, care este adesea vital pentru rezolvarea creativ a problemelor

4) Modele Cascada modificate.

Ca rspuns la problemele modelului cascad pur au fost introduse o serie de modele cascad modificate menite s nlture o parte din criticile aduse modelului original.

Aceste modele modificate folosesc aceleai faze ca i modelul cascad pur, ns nu ntr-un mod discontinuu. Acest fapt permite ca unele faze s se suprapun ori de cte ori este necesar. O alt funcionalitate nou introdus de aceste modele o constituie posibilitatea mpririi modelului pe mai multe subproiecte dup o anumit faz. Exemple de modele cascad modificate: Modelul sashimi Denumit aa deoarece suport suprapunerea fazelor, asemenea petelui japonez sashimi, a fost iniiat de ctre Peter DeGrace, i de cele mai multe ori este denumit simplu: modelul cascad cu faze suprapuse sau modelul cascad cu feedback. Deoarece fazele acestui model se suprapun descoperirea si tratarea erorilor este mai uoar i se poate realiza n cadrul fazelor modelului cascad.

Cascada cu prototipuri (Prototyping waterfall) Acest model se bazeaz pe crearea unui sistem de exemple, prototipuri, care s ajute la descoperirea rapid a erorilor. Un dezavantaj al acestui model l constituie faptul ca crearea unui astfel de prototip necesit un timp destul de ndelungat. Cascada cu borne (Milestone waterfall) Presupune crearea aplicatiilor pe mai multe faze, versiuni, n fiecare faz introducndu-se cte o funcionalitate cheie. Acest model este excelent pentru demonstrarea conceptelor n cazul folosirii unor tehnologii noi, reduce considerabil riscurile prin introducerea funcionalitilor cu cel mai mare grad de risc n primele versiuni.
Alte modele alternative Modelul cascad cu subproiecte si modelul cascad cu reducerea riscurilor sunt alte versiuni de modele cascad modificate. n unele privine chiar i modelul spiral poate fi privit ca un model cascad cu iteraie. 5) Argumente Pro si Contra Argumente pro modelul n cascad. Timpul petrecut n primele faze ale produciei de software poate duce la o mai mare economie n cadrul ciclului de viaa al unui produs soft. Este de preferat s depistm i s reparm o eroare n primele faze ale ciclului, dect mai trziu. McConnell estimeaz c un defect n faza de specificaie a cerinelor nedetectabil pn n faza de implementare sau de mentenan cost de 50 pn la 200 de ori mai mult dect ar fi costat n faza de specificare a cerinelor. Unul dintre principalele argumente pe care le au susintorii acestei metode este faptul c este mai uor de schimbat proiectul n cadrul fazei de proiectare dect s ateptm luni de zile i s vedem c ce am lucrat trebuie refcut datorit unui design greit. Unii specialiti prefer acest model pentru simplitate i pentru faptul c prezint o abordare mai structurat, progresnd liniar prin faze uor de neles. Datorit acestui fapt, modelul n cascad este folosit ca exemplu de nceput n multe cri i cursuri de inginerie soft. Modelul n cascad este folosit de o mulime de companii de mare anvergur ca de exemplu Departamentul de defensiv al SUA sau NASA n cadrul proiectelor de cercetare sau pentru alte scopuri. Argumente contra modelului n cascad. Modelul cascad este contestat de unii specialiti ca fiind greu de realizat n mod practic, pentru c este imposibil s realizezi perfect o faz a ciclului de via al unui produs software pentru a putea trece ulterior la urmtoarea. De exemplu, clienii nu tiu ntodeauna exact ce au nevoie nainte de a vedea un prototip funcionabil al programului. De asemenea, acetia pot s schimbe n orice moment cerinele sau s doreasc altceva, astfel nct programatorii i analitii nu au control deplin asupra situaiei, ei depinznd de client. Dac schimbm cerinele dupa ce am terminat faza de proiectare vom fi nevoii s refacem proiectarea din nou. Ideea ce st la baza modelului cascade este msoar de doua ori i taie o dat. Cei ce se opun modelului susin c ideea nu este bun datorit faptului c cerinele problemei msurate se schimb constant datorit modificrilor de cerin sau a altor factori. Principalele critici aduse acestui model sunt : multe programe software sunt supuse modificrii datorit factorilor externi (ex. clieni) astfel nct acestea trebuie sa fie adaptabile nevoilor acestora;

dac analitii i programatorii nu sunt foarte competeni este dificil de a tii exact de ce este nevoie n fiecare faza de dezvoltare a programelor, fiind necesar feed-back de la fazele superioare pentru a putea rezolva cerinele de la fazele inferioare; este dificil de estimat timpul i costurile necesare pentru fiecare faz de dezvoltare; este o pierdere de resurse de a avea doar personal specializat s rezolve anumite sarcini legate de exemplu de implementare, care s nu fac nimic n timpul fazei de proiectare.

Alte modele 1. Modelul V

Modelul V este o variant a modelului cascad, prin care se introduc conceptele de sistem i componente (subsisteme), aplicndu-se teste explicite la un sistem ierarhic pentru creterea controlului asupra modului n care se desfoar etapele. Tocmai aceast nlesnire constituie o latur a literei V. Prima este latura din stnga, parcurs descendent, i conine treptele propriu-zise, iar cea de-a doua latur, din dreapta, se parcurge ascendent, pe ea realizndu-se verificrile i validrile elementelor create anterior. Acest model puncteaz cu mai mult claritate separrile dintre ceea ce implic participarea utilizatorului, modelul arhitectural i cel al implementrii. Utilizatorul este implicat doar n fazele din partea superioar a V-ului. Arhitectura sistemului este surprins n partea de mijloc a literei, iar partea inferioar a ei se refer la faze de implementare, care ar putea consta fie din asamblarea componentelor soft, fie din codificarea unor componente. Modelul se preteaz i n mediul orientat-obiect, deoarece ncurajeaz prototipizarea, reutilizarea unor structuri superioare. El ofer un control puternic asupra sistemului n curs de realizare, prin structurile ierarhice i modulare pe care le promoveaz, ceea ce l face utilizabil i n cazul sistemelor complexe. Modelul devine i mai puternic dac promoveaz iteraia, adic reluarea unor faze, activiti sau subactiviti. De fapt, acesta este stilul adoptat de cei trei autori ai UML - (Booth, Jacobson i Rumbaugh), modelul iterativ-incremental, anunat de anumite performane ale modelului V. n cadrul acestui model se face, de asemenea, distincie evident ntre verificare i validare. Prima se refer la testarea sistemului, n diverse stadii ale lui, dac s-a construit corect din punct de vedere logic, n timp ce validarea va scoate n eviden faptul c sistemul, n forma lui final, rspunde sau nu cerinelor iniiale. Tocmai din aceast cauz, i se reproeaz c las validarea prea trziu, dup ce sistemul s-a construit, ceea ce l face ineficient. n forma lui consacrat, modelul i aparine lui Ould, care l lanseaz n 1990, anumite forme fiind folosite i de Rumbaugh, nc din 1991. El utilizeaz doar latura din stnga V-ului, fazele descendente, n care un lot esenial revine tratrii sistemului pe componente. Cea mai vdit preluare a filosofiei modelului V este regsit n modelul X (Hodgson). Definirea cerinelor Validare Testare sistem Testare subsistem

Proiectare sistem Proiectare subsistem

Codificare/asamblare componente

Figura 1. Modelul V 2. Modelul incremental

Modelul incremental este o alt variant a modelului cascad care promoveaz ideea proiectrii i realizrii independente a componentelor dup definirea arhitecturii globale a sistemelor informatice. Proiectarea i realizarea sistemelor informatice (SI) se face astfel n conformitate cu principiile metodelor topdown. Sistemul va putea fi livrat beneficiarului i structurat pe etape pe msura realizrii componentelor (n funcie de prioritile formulate de beneficiar) dar, ntr-o astfel de abordare pot aprea dificulti legate de integrarea componentelor

n sistemul final.

Definirea cerinelor Analiz

Proiectare component - 1 Implementare component - 1 Proiectare component - n Implementare component - n

Instalare component - 1 ntreinere component - 1 Instalare component - n ntreinere component - n

Arhitectura sistemului

Figura 2. Modelul incremental

Din figura de mai sus se observ faptul c primele dou etape definirea cerinelor i analiza - sunt identice cu cele dou etape de nceput ale modelului cascad, ns din momentul definirii arhitecturii SI fiecare component i urmeaz propriul ciclu de via. Spre deosebire de modelul n V care presupune integrarea componentelor, testarea i validarea acestora, de aceast dat se ofer i posibilitatea livrrii independente a componentelor sistemului ctre beneficiar fr a se exclude i posibilitatea livrrii sistemului final avnd toate componentele integrate. Din descrierea de pn acum rezult cteva dintre avantajele modelului: se ncadreaz n principiul arhicunoscut divide et impera", prin posibilitatea abordrii unor pri ale ntregului; sistemul poate fi livrat i pe componente realizate la perioade scurte de timp; proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorit modularizrii lui. Dintre dezavantaje pot fi enumerate: imposibilitatea aplicrii lui n toate cazurile, uneori neexistnd elementele necesare descompunerii ntregului; componentele pot fi realizate numai dup ce ntregului sistem i se definete arhitectura, totul derulndu-se dup principiile metodelor top-down, ceea ce nseamn nc o condiie dur: cunoaterea i formularea cerinelor din faza incipient de abordare a sistemului; fiind posibil de realizat pe pri, eforturile de integrare a acestora n ntreg sunt destul de mari, vorbindu-se chiar despre o aa-zis testare multipl de sisteme, cu trimitere la faptul c de fiecare dat cnd se adaug o nou component sistemul poate fi considerat unul nou.

3. Modelul spiral
Modelul spiral este lansat de unul dintre specialitii cu preocupri mai vechi legate de ciclul de via, B.W. Boehm. Acesta s-a ocupat de aa-zisele modele tradiionale nc din anul 1981, iar n 1986 anun modelul spiral i public rezultatele cercetrii sale n 198837. El se bazeaz pe dou convingeri: natura iterativ a dezvoltrii i nevoia de planificare i evaluare a riscurilor fiecrei iteraii; deficiena nregistrat la modelul V, n care validarea se efectueaz prea trziu, l face s propun, dimpotriv, realizarea acesteia ct mai devreme posibil, de ct mai multe ori, prin construirea prototipurilor, conform modelului simplificat din figura . Ciclul 1 Analiza preliminar 1. Obiective, alternative, constrngeri 2. Analiza riscului i prototipul 3. Conceperea operaiilor

6 Figura 3. Modelul spiral

4. Cerinele i planul ciclului de via 5. Obiective, alternative, constrngeri 6. 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 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 Modelul este mbuntit de R.G. Williams, R.F. Wirfs-Brock iar Ivar Jacobson l amelioreaz, n 1990, prin modelul spiral ierarhic i Rumbaugh, n 1992, prin modelul vrtej de ap (whirlpool-like). n varianta Boehm, echipa de dezvoltare i utilizatorii se angajeaz treptat n proiect, diminund riscurile la nivel de prototip. De asemenea, de bun augur este valorificarea experienei anterioare n planificarea activitilor din prototipul urmtor. Facem meniunea c modelul cascad se va regsi n fiecare iteraie. Deci dup cunoaterea cerinelor i efectuarea studiilor de fezabilitate, se realizeaz sistemul, se integreaz i instaleaz printr-o singur livrare, n varianta modelului cascad. Avantaje Se bazeaz pe ideea perfecionrii incrementale ale metodologiei secveniale Permite feedback-ul de la fiecare echip n ceea ce privete complexitatea sau corectitudinea cerinelor: exist etape n care pot fi corectate eventualele greeli Clientul poate arunca o privire asupra rezultatului i poate oferi informaii importante mai ales n faza dinaintea lansrii produsului Procesul de dezvoltare se poate adapta mai bine progresului tehnologic: pe msur ce apar noi soluii, ele pot fi ncorporate n arhitectura produsului Recunoate c problema principal a dezvoltrii programelor este riscul

Exemple de riscuri n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului sunt ignorate Clientul schimb cerinele firm concurent lanseaz un program rival pe pia Un dezvoltator/arhitect prsete echipa de dezvoltare echip nu respect un termen de livrare pentru o anumit component

Dezavantaje Fiecare ciclu produce un efort mai mare de munc pentru ciclul urmtor, ceea ce ncarc orarul planificat i poate duce la eliminarea unor funcii sau la o calitate sczut Lungimea sau numrul de cicluri poate crete foarte mult Scderea responsabilitii Nu exist termene limit precise; ciclurile continu fr o condiie clar de terminare Echipa de proiectare nu poate realiza o arhitectur complet Echipa de implementare poate fi pus n situaia nedorit n care arhitectura i cerinele sistemului sunt n permanen schimbate

4. Extreme Programming

Extreme Programming = programare extrem Metod de programare agil, potrivit dezvoltrii rapide de aplicaii

Figura 4. Modelul XP
Principiile metodelor agile Implicarea clientului Clientul trebuie implicat pe tot parcursul procesului de dezvoltare. Rolul su este de a fixa prioritile, cerinele i de a evalua iteraiile sistemului Livrarea incremental Programul este dezvoltat incremental, clientul indicnd cerinele care trebuie incluse la fiecare iteraie Oamenii nu procesul Abilitile echipei de dezvoltare trebuie recunoscute i exploatate. Echipa trebuie lsat s-i contureze propriile modaliti de lucru, fr a i se da reete Acceptarea schimbrii Echipa trebuie s se atepte ca cerinele s se schimbe iar proiectarea sistemului trebuie fcut astfel nct s se adapteze uor la aceste schimbri Meninerea simplitii Concentrare pe simplitate att n programele dezvoltate ct i n procesul de dezvoltare. Oricnd este posibil, trebuie eliminat complexitatea din sistem. Problemele metodelor agile Este dificil meninerea interesului clienilor implicai n proces Membrii echipei pot fi incapabili s se adapteze la implicarea intens caracteristic metodelor agile

Cnd exist mai muli factori de decizie, este dificil prioritizarea schimbrilor Meninerea simplitii necesit lucru suplimentar Contractele pot fi o problem n cazul dezvoltrii iterative

XP consider c dezvoltarea programelor nu nseamn ierarhii, responsabiliti i termene limit, colaborarea oamenilor din care este format echipa. Acetia sunt ncurajai s i afirme personalitatea, s ofere i s primeasc cunotine. XP consider c dezvoltarea de programe nseamn n primul rnd scrierea de programe, nu documente, edine i rapoarte. Carta drepturilor dezvoltatorului Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare de prioritate Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s i revizuieti estimrile n funcie de experien Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie atribuite Ai dreptul s faci treab de calitate n orice moment Ai dreptul la linite, distracie i la munc productiv i plcut Carta drepturilor clientului Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce pre Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se dovedete c funcioneaz trecnd teste repetabile pe care le specifici tu Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s schimbi prioritile Ai dreptul s fii informat de schimbrile n estimri, suficient de devreme pentru a putea reduce cerinele astfel ca munca s se termine la data prestabilit. Poi chiar s te opreti la un moment dat i s rmi cu un sistem folositor care s reflecte investiia pn la acea dat Echipa de dezvoltare nu are o structur ierarhic; fiecare contribuie la proiect folosind maximul din cunotinele sale Proiectul este n mintea tuturor programatorilor din echip, nu n documentaii, modele sau rapoarte Cerinele clientului sunt exprimate ca scenarii sau povestiri (user stories) Acestea sunt scrise pe bileele iar echipa de dezvoltare le mparte n sarcini de implementare (care stau la baza planificrii orarului de lucru i a estimrii costurilor) La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinelor Caracteristici Scrierea de cod este activitatea cea mai important La fiecare pas se face numai ce este absolut necesar n momentul urmtor Codul se scrie ct mai simplu i se optimizeaz (refactoring) de cte ori e posibil Se scrie mai nti cod de test Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se face fr mil Modificrile aduse codului sunt integrate continuu (de cteva ori pe zi) Se programeaz n echip (programare n perechi); echipele se schimb la sfritul unei iteraii (1-2 sptmni) Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar

Concluzii
Alegerea unei metodologii de dezvoltare trebuie s in seama de natura fiecrui proiect: Bugetul Mrimea echipei Tehnologia utilizat Instrumentele i metodele Termenele limit Procesele existente deja