Enginyeria del SW II: El procés de desenvolupament: Un exemple El procés de desenvolupament. Un exemple Toni Navarrete Enginyeria del Software II – UPF.

Presentación del tema: "Enginyeria del SW II: El procés de desenvolupament: Un exemple El procés de desenvolupament. Un exemple Toni Navarrete Enginyeria del Software II – UPF."— Transcripción de la presentación:

1 Enginyeria del SW II: El procés de desenvolupament: Un exemple El procés de desenvolupament. Un exemple Toni Navarrete Enginyeria del Software II – UPF 2007

2 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 2 Enunciat La llibreria LECTOR vol fer una petita aplicació web per controlar el seu stock i les vendes –Només la utilitzarà el venedor (per simplificar) A la llibreria es venen bàsicament llibres, però també altres tipus de documents, en concret CD-ROMs i revistes especialitzades S’han de tenir identificats els diferents exemplars que hi ha d’un mateix document Ens basarem en el mètode UP (en concret un subconjunt definit a [1]). [1] Craig Larman: Applying UML and patterns, 2nd edition. Prentice-Hall

3 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 3 Fase d’inici S’identifiquen els casos d’ús –Diagrama de casos d’us –Descripció de cada cas d’ús. Tres formes: Breu: un resum d’una línia (o paràgraf com a màxim) de l’escenari principal Casual: es dedica un paràgraf a cada escenari (tant el principal, com tots els alternatius) Fully dressed: el més elaborat. Tots els passos i variacions són escrits en detall, s’especifiquen les precondicions i postcondicions –En aquesta fase descripcions breus o casuals, potser més desenvolupat el que serà base per a la primera iteració de l’elaboració –S’especifiquen altres requeriments no funcionals

4 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 4 Fase d’inici. El diagrama de casos d’ús

5 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 5 Fase d’inici. Text de cas d’ús “Processar venda” (format fully dressed) Actor primari: Depenent Precondicions: el depenent s’ha autentificat Postcondicions: la venda es guarda, es genera un rebut i es gestiona el pagament Escenari principal: 1.El client arriba amb els seus productes 2.El depenent comença una nova venda 3.El depenent entra el codi de l’exemplar 4.El sistema guarda la línia de venda i presenta el títol del producte i el seu preu. Es repeteixen 3 i 4 mentre quedin exemplars 5. El sistema presenta el total amb l’IVA calculat 6.El depenent diu al client el total i li demana per fer el pagament 7.El client paga i el sistema emmagatzema el pagament 8.El sistema genera un rebut 9.El depenent dóna el rebut i el canvi al client

6 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 6 Fase d’inici. Text de cas d’ús “Processar venda” (format fully dressed) Escenaris (fluxos) alternatius: * En qualsevol moment, el sistema falla... 3a. Identificador invàlid 1. El sistema senyala l’error i rebutja l’entrada 3b. Múltiples exemplars del mateix producte, i no cal distingir entre ells 1. El depenent introdueix el codi del producte i la quantitat 4a. El sistema genera un preu que no és adequat 1. El depenent modifica el preu del producte 2. El depenent potser ha de calcular els imposts a mà...

7 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 7 Fase d’elaboració, 1ª iteració. Requeriments En la fase d’elaboració hem de poder passar dels casos d’ús als models estàtic i dinàmic de disseny. L’aproximació és diferent a la d’ICONIX En aquesta iteració desenvoluparem el cas d’ús “Processar venda” Dibuixar el Diagrama de Seqüència de Sistema (SSD) –És un diagrama de seqüència on vegem com cada usuari interactua amb el sistema (representat com si fos un objecte) per a cada cas d’ús concret

8 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 8 Fase d’elaboració, 1ª iteració. Requeriments. El Diagrama de Seqüència de Sistema

9 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 9 Fase d’elaboració, 1ª iteració. Requeriments Model de domini: –hem de determinar les classes que participen en el problema –les associacions –els atributs principals (ara o més tard) –No sol valer la pena entrar a distingir agregacions i composicions

10 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 10 Fase d’elaboració, 1ª iteració. Requeriments. Model de domini

11 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 11 Fase d’elaboració, 1ª iteració. Requeriments Contractes: –Per a cada operació en el Diagrama de Seqüència de Sistema, determinem les seves precondicions i postcondicions (quins efectes ha provocat aquesta operació) Exemple: Operació: ferNovaVenda() Referències creuades: Casos d’us: Processar venda Precondicions: cap Postcondicions: - una instància de venda v va ser creada - v va ser associada al Handler del cas dús - els atributs de v van ser inicialitzats

12 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 12 Fase d’elaboració, 1ª iteració. Disseny Al disseny cal assignar a les classes les responsabitats de dur a terme les operacions identificades en els SSD: –Crear els diagrames d’interacció per cada operació del SSD o bé un diagrama per tot el cas d´ús Utilitzem els patrons GRASP (i altres) per a l’assignació de responsabilitats Patrons GRASP: Patterns of General Principles in Assigning Responsabilities Els 3 més comuns: –Information Expert (o Expert) –Creator –Controller

13 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 13 Objectius de l’assignació de responsabilitats: 1. Baix acoblament Low coupling (baix acoblament) –L’acoblament és una mesura de com de fortament un element està connectat a, té coneixement de, o està relacionat amb altres elements –Un element amb baix acoblament no depèn de molts altres elements –No són desitjables classes amb alt acoblament perquè tenen els següents problemes: Els canvis en classes relacionades forcen canvis locals És difícil d’entendre aïlladament És difícil de reutilitzar, ja que requereix altres classes

14 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 14 Objectius de l’assignació de responsabilitats: 2. Alta cohesió High cohesion (alta cohesió) –La cohesió és una mesura de com fortament estan relacionades les responsabilitats que té un element –Si un element ha de fer moltes coses diferents entre elles, és poc cohesionat, la qual cosa no és desitjable –Els elements amb baixa cohesió tenen els següents problemes: Difícil de comprendre Difícil de reutilitzar Difícil de mantenir Patiran canvis constants

15 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 15 Patrons GRASP: Information Expert Principi general d’assignació de responsabilitats: –Assignar la responsabilitat al “Information Expert”, la classe que té la informació necessària per a dur a terme la responsabilitat

16 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 16 Patrons GRASP: Information Expert Un exemple Qui ha de ser el responsable de saber el total d’una venda? Venda sap el total de la venda: –Afegim l’operació getTotal() a Venda LíniaVenda sap el subtotal: –Afegim l’operació getSubtotal() a LíniaVenda Producte sap el preu del producte –Afegim l’operació getPreu() a Producte

17 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 17 Patrons GRASP: Information Expert Una excepció Una excepció a Information Expert és quan treballem amb bases de dades No convé afegir els mètodes per connectar amb la base de dades a cada una de les classes –Això donaria problemes de baixa cohesió i duplicació Millor separar la capa de “negoci” de la capa de la base de dades

18 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 18 Patrons GRASP: Creator Qui és el responsable de crear una nova instància d’una classe? –Assignar a la classe B la responsabilitat de crear una instància de la classe A si una o més de les següents condicions es compleix: B agrega objectes A B conté objectes A B guarda objectes A B usa objectes A B té les dades d’inicialització que s’han de passar a A per poder crear una instància (és a dir B és un expert respecte a la creació d’A)

19 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 19 Patrons GRASP: Creator Un exemple Qui ha de ser el responsable de crear una instància de LíniaVenda? –Resposta: Venda

20 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 20 Patrons GRASP: Controller Qui ha de ser el responsable de manegar un esdeveniment d’entrada al sistema? –Assignar la responsabilitat de rebre o manegar un esdeveniment de sistema a una classe que compleixi una de les següents alternatives: Representa el sistema complet o un subsistema: –Patró Façade Representa un controlador d’un escenari d’un cas d’ús. Domain Layer Interface Layer ??? :VendaJFrame System event

21 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 21 Patrons GRASP: Controller Un exemple Qui gestiona els esdeveniments de sistema –ferNovaVenda –introduirExemplar –fiVenda –pagament Dues opcions: –ProcessarVendaHandler –Facade (que gestiona tots els casos d’ús)

22 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 22 CRC cards CRC: Class-Responsability-Collaborator És una tècnica (manual o automàtica) que a vegades s’utilitza per portar el control de les responsabilitats Tenim una tarjeta per a cada classe on s’especifiquen les responsabilitats que li assignem i amb qui ha de col·laborar per satisfer cada responsabilitat

23 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 23 CRC cards Un exemple VENDA RESPONSABILITATCOL·LABORACIÓ Crear Línies VendaLínia Venda Afegir Línia VendaLínia Venda Get SubtotalLínia Venda...

24 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 24 Altres patrons GRASP Pure Fabrication –Problema: a vegades Information Expert no és adequat (exemple: Base de dades) –Solució: s’assignen un conjunt de responsabilitats a una classe artificial que no representa cap concepte del domini –Exemples GoF: Adapter, Command, Strategy... Indirection –Problema: a vegades no ens interessa acoblar dos elements determinats –Solució: s’assigna la responsabilitat a un objecte intermedi que media entre elements per tal de què no estiguin directament acoblats –La majoria dels Indirection són Pure Fabrications –Exemples GoF: Adapter, Bridge, Facade, Observer, Mediator

25 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 25 Fase d’elaboració, 1ª iteració. Disseny. Diagrama d’interacció ferNovaVenda()

26 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 26 Fase d’elaboració, 1ª iteració. Disseny. Diagrama d’interacció introduirExemplar()

27 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 27 Fase d’elaboració, 1ª iteració. Disseny. Diagrama d’interacció completarVenda()

28 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 28 Fase d’elaboració, 1ª iteració. Disseny Diagrama de Classes de Disseny –Inclou agregacions i composicions –Generalitzacions –Atributs –Mètodes

29 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 29 Fase d’elaboració, 1ª iteració. Implementació Suggeriment de Larman: –“For a two-week iteration, consider spending at least a half-day near the start or the iteration doing some viusal modeling design work, before moving on to programming. Use simple “tools” as a whiteboard and digital camera. If you find a UML CASE tool that is equally fast, easy, and convenient, excellent.” –En la mesura que es pugui, quan es programa, utilitzar eines de design-while-programming –Començar a escriure les classes menys acoblades

30 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 30 Fase d’elaboració, 1ª iteració. Implementació Exemple de codi: la classe Venda public class Venda { List liniesVenda = new ArrayList(); Date data = new Date(); public void afegirLiniaVenda(Produce p, int quantitat) { liniesVenda.add(new LiniaVenda(p,q)); } public real getTotal() { real total=0; Iterator i = linesVenda.iterator(); while (i.hasNext()) { LiniaVenda lv = (liniesVenda) i.next(); total+= lv.getSubtotal(); } return total; }... }

31 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 31 I també... Altres coses que es farien en aquesta iteració (o en d’altres): –Incloure en el disseny les classes relacionades amb la interfície (classes frontera), tenint en compte que és una aplicació web –Determinar l’arquitectura Patrons d’arquitectura –Refinar el model de disseny aplicant-hi eventualment altres patrons –Fer el disseny de persistència (usarem BDR) Mapeig O/R JDBC Per iteracions posteriors: –Tractar més casos d’ús, primer els de major risc

32 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 32 Resum final de les fases i artefactes comentats Inici –Diagrama de casos d’ús i text dels casos d’ús (un en format fully-dressed) Elaboració: –Requeriments: Diagrama de Seqüència de Sistema (SSD) Model de domini: diagrama de classes Contractes –Disseny Assignació de responsabilitats (potser amb CRC cards) Diagrames d’interacció Diagrama de classes de disseny Model d’arquitectura (no fet) Disseny de la persistència (no fet) –Implementació Passar a codi les classes del disseny, començant per les menys acoblades

33 Enginyeria del SW II: El procés de desenvolupament: Un exemple Pàgina 33 Bibliografia utilitzada Larman: Patterns and UML, 2nd edition. Jacobson, Ivar; Booch, Grady; Rumbaugh, James: El proceso unificado de desarrollo de software. Addison Wesley Kruchten, Philippe: The Rational unified process an introduction Philippe Kruchten. Addison-Wesley Campderrich: Enginyeria del programari I. UOC Campderrich: Enginyeria del programari III. UOC