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

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

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

Fase d’inici. El diagrama de casos d’ús

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: El client arriba amb els seus productes El depenent comença una nova venda El depenent entra el codi de l’exemplar 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 El depenent diu al client el total i li demana per fer el pagament El client paga i el sistema emmagatzema el pagament El sistema genera un rebut El depenent dóna el rebut i el canvi al client

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à

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

Fase d’elaboració, 1ª iteració. Requeriments Fase d’elaboració, 1ª iteració. Requeriments. El Diagrama de Seqüència de Sistema

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

Fase d’elaboració, 1ª iteració. Requeriments. Model de domini

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

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

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

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

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

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 getPreu() a Producte

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

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)

Patrons GRASP: Creator Un exemple Qui ha de ser el responsable de crear una instància de LíniaVenda? Resposta: Venda

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. :VendaJFrame Interface Layer System event Domain Layer ???

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)

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

CRC cards Un exemple VENDA RESPONSABILITAT COL·LABORACIÓ Crear Línies Venda Línia Venda Afegir Línia Venda Get Subtotal ...

Altres patrons GRASP Pure Fabrication Indirection 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

Fase d’elaboració, 1ª iteració. Disseny Fase d’elaboració, 1ª iteració. Disseny. Diagrama d’interacció ferNovaVenda()

Fase d’elaboració, 1ª iteració. Disseny Fase d’elaboració, 1ª iteració. Disseny. Diagrama d’interacció introduirExemplar()

Fase d’elaboració, 1ª iteració. Disseny Fase d’elaboració, 1ª iteració. Disseny. Diagrama d’interacció completarVenda()

Fase d’elaboració, 1ª iteració. Disseny Diagrama de Classes de Disseny Inclou agregacions i composicions Generalitzacions Atributs Mètodes

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

Fase d’elaboració, 1ª iteració 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; ...

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

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

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