Enginyeria del SW II: Models d’aplicacions web Models d’aplicacions web Toni Navarrete Enginyeria del Software II – UPF 2007

Enginyeria del SW II: Models d’aplicacions web Pàgina 2 Problema Les aplicacions basades en JSPs sovint barregen en un únic JSP totes les capes, i per exemple, llegeixen dades d’un formulari, accedeixen a la base de dades, escriuen la resposta, generen missatges d’error... Objectiu: –Separar clarament els aspectes de presentació, de l’accés al repositori de dades, i també de la lògica de negoci

Enginyeria del SW II: Models d’aplicacions web Pàgina 3 Esquema Model 1 L’accés a la BD i part de la lògica de negoci està encapsulada mitjançant una sèrie de classes (JavaBeans) Encara hi ha una barreja de HTML i Java que dificulta la lectura i manteniment: no separació entre lògica i presentació

Enginyeria del SW II: Models d’aplicacions web Pàgina 4 Esquema Model 2 Un Servlet rep les peticions i instancia una o més classes que seran les que accedeixen a la BD El resultat final del procés és un JSP que s’envia al client Model 2 és en realitat una adaptació del MVC per a sistemes web

Enginyeria del SW II: Models d’aplicacions web Pàgina 5 Patró d’arquitectura Model-View-Controller (MVC) Podem veure qualsevol sistema amb una divisió en 3 àrees: –Controlador (controller), que manega l’entrada que canvia el sistema Exemple: el volant, l’accelerador, la palanca de marxes,... –Model, que són les dades o el model del sistema Exemple: el motor, suspensió, transmissió,... –Vista (view), que és la presentació de les dades, ja sigui de forma textual, gràfica... Exemple: el comptaquilòmetres, indicadors lluminosos,... MVC és típic en desenvolupaments GUI –A la web, la connexió “stateless” entre servidor i client no permet que un controller notifiqui els canvis al view de forma fàcil, com sí passa en una GUI “típica”

Enginyeria del SW II: Models d’aplicacions web Pàgina 6 MVC en entorns web (Model 2 o MVC 2) Estructura d’una aplicació web seguint MVC2: –Un servlet controller recull les dades necessàries típicament des d’un formulari –Hi ha una sèrie de classes (model) que fan una sèrie d’operacions relacionades amb la lògica del negoci, normalment accedint a una BD. És el servlet controller l’encarregat d’instanciar i inicialitzar aquestes classes –També el servlet controller centralitza la lògica de dispatching: selecció de la següent vista (un JSP), segons els paràmetres d’entrada i estat de l’aplicació Això fa que hi hagi una separació entre els JSPs de vista i el servlet de control A més, s’evita que les vistes tinguin referències d’altres vistes En resum, les aplicacions són més fàcils de mantenir i d’extendre

Enginyeria del SW II: Models d’aplicacions web Pàgina 7 MVC en entorns web (Model 2 o MVC 2)

Enginyeria del SW II: Models d’aplicacions web Pàgina 8 Estructura del controller: Lògica de dispatching Per despatxar una petició a una vista des del servlet controller s’utilitza: RequestDispatcher d = getServletContext().getRequestDispatcher(URLVista); // retorna un objecte RequestDispatcher //que actua com a un wrapper de la vista (a una URL concreta) //Normalment la vista és un JSP d.forward(request,response); // passa la petició a la vista NOTA: el servlet que fa el forward d’una petició no ha d’escriure res a la sortida, o en cas contrari es produirà una excepció D’aquesta forma el Controller està lligat a la vista (necessitem el path)

Enginyeria del SW II: Models d’aplicacions web Pàgina 9 Estructura del controller: Identificació de les operacions a realitzar 3 opcions: –Amb una variable oculta de formulari (POST) –Amb un paràmetre d’URL (GET) –Amb mappings (definint noms virtuals) myServlet *.do (típic amb frameworks)

Enginyeria del SW II: Models d’aplicacions web Pàgina 10 Estructura del controller: Invocació dels mètodes del model Una forma simple: if (op==1) { User u = new User( request.getAttribute("user"), request.getAttribute("pass")); } else if (op==2) {... }...

Enginyeria del SW II: Models d’aplicacions web Pàgina 11 Estructura del controller: Invocació dels mètodes del model Patró Command: –Es defineix una classe abstracta Action, per representar una acció, amb un mètode perform, per delegar-hi peticions –Es creen tantes subclasses com operacions concretes s’hagin identificat –El controller té una taula, on per cada operació, s’indica quina subclasse li correspon

Enginyeria del SW II: Models d’aplicacions web Pàgina 12 Estructura del controller: Invocació dels mètodes del model // Action.java: public abstract class Action { protected Model model; public Action(Model model) { this.model = model; } public abstract String getName(); public abstract Object perform(HttpServletRequest req); }

Enginyeria del SW II: Models d’aplicacions web Pàgina 13 Estructura del controller: Invocació dels mètodes del model // CreateUserAction.java: public class CreateUserAction extends Action { public CreateUserAction(Model model) { super(model); } public String getName() { return "createUser"; } public Object perform(HttpServletRequest req) { return model.createUser(req.getAttribute("user"), req.getAttribute("pass")); }

Enginyeria del SW II: Models d’aplicacions web Pàgina 14 Estructura del controller: Invocació dels mètodes del model public class ControllerServlet extends HttpServlet { private HashMap actions; public void init() throws ServletException { actions = new HashMap(); CreateUserAction cua = new CreateUserAction(model); actions.put(cua.getName(), cua); //... create and add more actions } public void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException { // First identify operation "op" from URL. // method getOperation() is defined elsewhere. String op = getOperation(req.getRequestURL()); // Then find and execute corresponding Action Action action = (Action)actions.get(op); Object result = null; try { result = action.perform(req); } catch (NullPointerException npx) {... } //determine next view result to determine next view }... }

Enginyeria del SW II: Models d’aplicacions web Pàgina 15 Estructura del controller: Lògica de dispatching Per evitar que el Controller estigui lligat a la Vista, el dispatcher pot estar separat del servlet controller. El controller delega la selecció de la següent vista en el dispatcher. –Patró Dispatcher View També és freqüent que una vista sigui múltiple, en el sentit de què és la composició de vàries vistes –Patró Multiple View o Composite View

Enginyeria del SW II: Models d’aplicacions web Pàgina 16 Dispatcher i CompositeView Model

Enginyeria del SW II: Models d’aplicacions web Pàgina 17 Dispatcher i CompositeView Model

Enginyeria del SW II: Models d’aplicacions web Pàgina 18 Observació El controller (Action) és qui típicament crearà les instàncies que calgui del model i li passarà a les vistes Aquestes només criden a mètodes de get d’aquestes instàncies Els mètodes de modificació/inserció típicament es criden des del controller

Enginyeria del SW II: Models d’aplicacions web Pàgina 19 Estructura del Controller Podem tenir un controller únic per a tot el sistema o un per a cada cas d’ús –Per exemple, en un framework com Struts només n’hi ha un únic servlet controller que ens el dóna el propi framework i que és configurable mitjançant fitxers XML Nota: sovint es parla de Front Controller per parlar del servlet controller (és el nom d’un patró J2EE)

Enginyeria del SW II: Models d’aplicacions web Pàgina 20 Estructura del Model El model de classes de domini és la base per al Model Al disseny cal assignar a les classes les responsabitats de dur a terme les operacions identificades en els SSD: –SSD: Diagrama de Seqüència de Sistema, on vegem com cada usuari interactua amb el sistema (representat com si fos un objecte) per a cada cas d’ús concret –Hem d’acabar creant els diagrames d’interacció per cada operació del SSD o bé un diagrama per a 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 (ja explicat anteriorment en el context web)

Enginyeria del SW II: Models d’aplicacions web Pàgina 21 Exemples de diagrama de casos d’ús i SSD per al cas d’ús “Processar venda”

Enginyeria del SW II: Models d’aplicacions web Pàgina 22 Exemple de diagrama de classes de domini

Enginyeria del SW II: Models d’aplicacions web Pàgina 23 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

Enginyeria del SW II: Models d’aplicacions web Pàgina 24 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

Enginyeria del SW II: Models d’aplicacions web Pàgina 25 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

Enginyeria del SW II: Models d’aplicacions web Pàgina 26 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

Enginyeria del SW II: Models d’aplicacions web Pàgina 27 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

Enginyeria del SW II: Models d’aplicacions web Pàgina 28 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)

Enginyeria del SW II: Models d’aplicacions web Pàgina 29 Patrons GRASP: Creator Un exemple Qui ha de ser el responsable de crear una instància de LíniaVenda? –Resposta: Venda

Enginyeria del SW II: Models d’aplicacions web Pàgina 30 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

Enginyeria del SW II: Models d’aplicacions web Pàgina 31 Patrons GRASP: Controller Un exemple Qui gestiona els esdeveniments de sistema –ferNovaVenda –introduirExemplar –finalitzarVenda –controlarPagament Dues opcions: –ProcessarVendaController –Façade (que gestiona tots els casos d’ús)

Enginyeria del SW II: Models d’aplicacions web Pàgina 32 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

Enginyeria del SW II: Models d’aplicacions web Pàgina 33 Estructura del Model És convenient separar els mètodes d’accés a la BD de les classes de domini. –En JDO, l’accés a la BD és transparent –En EJB, hi ha la possibilitat de què els EJBs d’entitat ho encapsulin tot Solució: Patró Data Access Object (DAO) –Un DAO abstreu i encapsula tots els accessos al magatzem de dades. –El DAO gestiona la connexió amb el magatzem i les operacions de selecció i modificació de dades –1 DAO per tot el sistema, o per a cada cas d’ús –1 DAO per classe (on tots els DAO hereten d’una classe abstracta DAO general que té els mètodes per establir la connexió a la BD): el més habitual

Enginyeria del SW II: Models d’aplicacions web Pàgina 34 Estructura del Model: Patró DAO En realitat DAO és un Adapter entre l’objecte de “negoci” i el magatzem de dades

Enginyeria del SW II: Models d’aplicacions web Pàgina 35 Estructura del Model: DAO i Factory Es pot emprar un Factory que construeixi diferents DAOs en funció del tipus de magatzem de dades: major flexibilitat front a canvis del tipus de magatzem (canvi de gestor o de paradigma)

Enginyeria del SW II: Models d’aplicacions web Pàgina 36 Model 2 web application frameworks Els anomentats web application frameworks (o web-tier frameworks) simplifiquen la implementació d’aplicacions basades en MVC2: –J2EE BluePrints Web Application Framework (WAF) –Apache Structs, és el més conegut –JavaServer Faces Inclouen un servlet controller configurable, i aporten unes classes abstractes que poden ser exteses per manegar la lògica de dispatching Alguns frameworks inclouen un llenguatge de macros o altres eines per simplificar la construcció de l’aplicació

Enginyeria del SW II: Models d’aplicacions web Pàgina 37 Unes notes sobre arquitectura... Arquitectura basada en capes –Capa de presentació –Capa de “negoci” –Capa de dades No confondre les capes d’arquitectura amb la separació entre model-vista-controlador Esquemes d’arquitectura general de l’aplicació: –D’una capa –De dues capes –De tres capes –“Mitja capa” (cas típic: 2,5 capes)

Enginyeria del SW II: Models d’aplicacions web Pàgina 38 Arquitectura d’una capa Capa de presentació Capa de negoci Capa de dades Web server File system Browser

Enginyeria del SW II: Models d’aplicacions web Pàgina 39 Arquitectura de dues capes Capa de presentació Capa de negoci Capa de dades Web server+CGI o Web server+servlet engine File system Browser HTTP Base de dades JDBC

Enginyeria del SW II: Models d’aplicacions web Pàgina 40 Arquitectura de tres capes Capa de presentació Capa de negoci Capa de dades Application server: components distribuïts File system Browser HTTP Base de dades JDBC Web server CORBA/RMI/ Web Services/...

Enginyeria del SW II: Models d’aplicacions web Pàgina 41 Arquitectura de dues capes i mitja Capa de presentació Web server+servlet engine File system HTTP Capa de dades JDBC Browser JavaScript HTML dinàmic

Enginyeria del SW II: Models d’aplicacions web Pàgina 42 Factors de determinació d’arquitectures de dues o tres capes Complexitat de l’aplicació Mantenibilitat Pressió de la planificació Experiència de l’equip de desenvolupament Aplicacions de 2 capes Aplicacions de 3 capes

Enginyeria del SW II: Models d’aplicacions web Pàgina 43 Algunes particularitats de les aplicacions web Aspectes tecnológics de l’ES per web Tecnologies –HTML –Llenguatges de script –Cookies –XML –CGIs, NSAPI, ISAPI, –Servlets –Pàgines amb codi incrustat (ASP, JSP, PHP) –EJB i altres models de components Web-services Arquitectura –Models de capes Servidors web Servidors d’aplicacions Clients thick i clients thin

Enginyeria del SW II: Models d’aplicacions web Pàgina 44 Algunes particularitats de les aplicacions web Especificació de requeriments Se sol basar en un model de casos d’ús (se solen utilitzar mètodes use-case driven) Se li dóna molta importància a la interfície d’usuari –Existeixen mètodes específics centrats en la interfície –La navegació pot ser un aspecte important de la interfície. Hi ha mètodes centrats en la navegació –Es habitual utilitzar prototipus no funcionals de la interfície (amb pàgines estàtiques o imatges)

Enginyeria del SW II: Models d’aplicacions web Pàgina 45 Algunes particularitats de les aplicacions web Especificació de requeriments Cal decidir el model de l’arquitectura –nombre de capes –clients thin o thick

Enginyeria del SW II: Models d’aplicacions web Pàgina 46 Algunes particularitats de les aplicacions web Disseny Decidir la tecnologia per a les vistes: –Pàgina estàtica HTML –Swing (en applets) –Servlets –JSP –Usant XML/XSL –... Extensió UML per aplicacions web

Enginyeria del SW II: Models d’aplicacions web Pàgina 47 Algunes particularitats de les aplicacions web Estensió web d’UML Estereotips per modelar –Server Page –Client Page –Form –Frameset –Target –ClientScript Object –Web Page –ASP Page –JSP Page –Servlet –Script Library

Enginyeria del SW II: Models d’aplicacions web Pàgina 48 Algunes particularitats de les aplicacions web Estensió web d’UML. Exemples d’estereotips JSP FormulariScript de clientLlibrería de scriptsPàgina web Servlet

Enginyeria del SW II: Models d’aplicacions web Pàgina 49 Algunes particularitats de les aplicacions web Estensió web d’UML. Un exemple

Enginyeria del SW II: Models d’aplicacions web Pàgina 50 Algunes particularitats de les aplicacions web Disseny Decidir la tecnologia per a les classes entitat (persistència) –JDBC, EJB amb BMP o CMP, JDO, altres frameworks... Gestor de connexions a la BD (si és el cas): –Un DAO global –Un DAO per classe Controller: servlet (frameworks MVC com Struts o Java Server Faces) Views: JSP

Enginyeria del SW II: Models d’aplicacions web Pàgina 51 Algunes particularitats de les aplicacions web Proves El model de contingut de l’aplicació web és revisat per descobrir errors El model de disseny per l’aplicació web és revisat per descobrir errors de navegació S’apliquen proves d’unitat als components de procés seleccionats i a les pàgines web Es construeix l’arquitectura, es realitzen les proves d’integració L’aplicació web ensamblada es prova per a aconseguir una funcionalitat global i un contingut L’aplicació web s’implementa en una varietat de configuracions diferents d’entorns; cal comprovar la compatibilitat amb cada configuració L’aplicació web es prova amb una població d’usuaris finals controlada i monitoritzada

Enginyeria del SW II: Models d’aplicacions web Pàgina 52 Més informació: patrons J2EE J2EE Patterns Catalog – Core J2EE Patterns. Best Practices and Design Strategies – J2EE Best Practices – Designing Enterprise Applications with the J2EE TM Platform, Second Edition – enterprise_applications_2e/index.htmlhttp://java.sun.com/blueprints/guidelines/designing_ enterprise_applications_2e/index.html

Enginyeria del SW II: Models d’aplicacions web Pàgina 53 Més informació: Struts Web d’Apache Struts – Curs de Struts a coreservlets.com – Llibre (en castellà) –Chuck Cavanness: Jakarta Struts. Anaya Multimedia - O’Reilly, 2005

Enginyeria del SW II: Models d’aplicacions web Pàgina 54 Més informació: ES per web Pressman: Ingeniería del Software, un enfoque práctico. 5ª edición. McGraw Hill, 2002.