Scribd Logo
Upload

Welcome to Scribd!

  • Capítulo 14 221-237

    Uploaded by

    Douglas Díaz
    2 views17 pages

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    2 views17 pages

    Capítulo 14 221-237

    Uploaded by

    Douglas Díaz

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 17
    Parte V: cREeamEne : : Arguitectura Y disefio de software ; Contenido” oe A Objetivos + Aprénder ol eoncepto de diserio + Aarénder yullzar los erteros de bbuen disefio 1441 El proceso de GF nnn 14.2 Dosarllo del Caso Testign. 14.3 Conclsin . pe 14.4 Contenido de fa pgina web de apoyo... 7 aoe ee concent ds patronas eee + Practicarlos conceptos anteriores aplicdndotos al caso testigo Competencias — « * Establecer los criteios de disefto que se utiizarén en un proyecto.de desarrallo para consolidar y promover fos principios con que fue definica la erquitecture 222 14 - Disefio de Software En este capitulo presenteremos el disefio de algunos aspectos vinculados con el caso testigo que venimos desarrolando en los capitulos anteriores. Enfatizaremos las buenas précticas de disefio de software y las analizaremos desde la perspectiva de la Ingenieria de Software. En el capitulo anterior hemos definido la arquitectura cel sistema en desarrollo a partir del andlisls de las necesidacles de los usuarios en el contexto de la empresa. Es tiempo de disefiar el interior de los médulos concebidos como ejercicio de esa definicién, Cuelquier gerente de desarrollo desea que el disefio del software de sus proyectos se elabore con criterios. ue hagan a los productos generatios reusables, flaxibles para extendorlos, féciles de probar y mantener, sim- ples de documentary comunicar, y robustos. Las buenas précticas de disefio que presentaremos constituyen una buena parte del cuerpo de conool- miento de la Ingenieria de Software y los beneficios de trabalar utlizéndolas son: * _reusables para que los componantes de diferentes proyectos puedan ser comppartidos y por lo tanto. més robustos al haber sido probados en diferentes contextos; ‘+ féciles de probar para que cada aspecto o incumibencia pueda ser asociado a un test atémico & Independiente y la detecoién de falas faciltara el mantenimiento; ‘+ simples de documentar y comunicar pera evitar fallas y faciltar que los dasarrolladores los utlicen de la mejor manera a partir de la reutitzacién; ‘* robustos para que funcionen en los mas civersos contextos de ejecucién, Todos estos beneficios se convierten en atributos de calidad que califican a una empresa a partir de los productos por ella producidos, 14.1.1 Griterios de buen disefio Los criterios mencionados constituyen una guia a la hora de elaborar un disefio pare la solucién de un deter minado problema. Citamos a continuaciGn algunos mas generales y luego algunos més concretos. Criterios generales {1}, (2): 14, 1 Economia Flexibilided arbitrria por si misma, caracteristices inneceserias, compleiidad en el disefio, atributos fuera de roporcién con el problema a resolver y un enfoque en la reutiizacién en lugar ds la usabilided. Todos estos sintomes muestran ausencia de economia. 14.1.1.2 Visibilidad Este crterio esta directamente ligaco a le expresividad de los artefactos que describen la arquitectura. Este sintoma de escasa visiblidad dificutta la comunicacién del disefio a los desarrolladores. La utlizacién de patro- nes de cisefio es una forma de hacer més visible un cisefio, Alfaomega Ingenieria de Software - Pantaleo - Rinaudo 223 1411.3 Espaciamiento La seperacién de incumbencias es un claro ejemplo de buen especiamiento. La separacién en paquetes a partir de un criterio de cohesién determinado garantiza un buen espaciamiento, Si el criterio deriva del negocio, ‘tencremos un espaciamiento adecuado desde esa perspective, si deriva de cuestiones técnicas relacionadas alos servicios tendremos un buen espaciamiento en la infraestructura. 14.1.1.4 Simetria Un cisefo simétrico es més fécil de comunicar y entender. Ademds de expresar balance y consistencia, es intui- tiva, Un ejemplo de esto podrian ser los patrones creacionales de tipo factory, si se ocupan de la creacién sola- mente expresan asimetria. Si ademas de la creacién se ocupan de la destruccién, entonces expresan simetria, 14.1.1.5 Emergencia Forzar la estructura y el control de forma centralizada genera disefios que no son buenos. Es deseable que estas propiedades surian, emerian naturalmente de la alternativa seleccionada acorde al problema a resolver. Criterios especifices [3]: 14.1.1.6 Inversién en fa cadena de dependencia Este criterio de buen disefio establece que los médulos de alto nivel no deben depender de aquellos de mas bajo nivel y que ambos deben depender de abstracciones. 14.1.1.7 Cédigo clausurado ante cambios Este crterio establece que el cédigo de nusstras clases debe presentarse ablerto a la extensién pero cerrado ‘a moctficaciones, 14.1.1.8 Principio de substitucién Este criterio establece que los subtipos deben poder ser substituidos por sus tipos base. 14.1.1.9 Segregaci6n de interfaces Este criterio establece que los componentes cuyas interfaces carezcan de cohesién en sus métodos presen- tarén una desventaja que se manifestaré a través de su uso por clientes con muy diferentes intensiones. Este principio propone ante estos sintomas romper las interfaces en otras cuyos métodos estén agrupacios Por algtin critetio de cohesién y sean utllzados con una Unica intension. 14.1.1.10 Dependencias no ciclicas Este oriterio establece que no es deseable contar en un disefio con dependencias cicicas que generen depen- cdencias en ef desarrollo y las pruebas, ademés de limitar la posibilidad de reutllzacién. Ingenieria de Software - Pantaleo - Rinaudo Alfaomega 224 14 - Disofo de Software Puede verse que todos y cada uno de los crterios mencionads son la base para lograr los beneficios enu- ‘merados més arriba, Existen excetentas libros que tratan en detalle los aspectos del disefio de sottware, elos ‘son mencionados en las referencias de este capitulo [1] ~ [7]. 14.1.2 Patrones de disefio Hecia el afio 1995 tuvo lugar un sucaso de fundamental importancia en el érea del desarrollo de softwere, ‘ue la constitucién de una corriente de estudio tamada Patrones de Disefio, El primer libro de texto surgido de ese movimiento fue el libro de Gemma y otros [7]. La esencia que motorizé esta escuela de disefio de software fue la catalogacién de las diferentes soluciones propuestas a diversos problemas a Ie largo de afios en distintos contextos. A estas soluciones so las-lamé Patrones. Esta sistematizacién del cuerpo de ‘conocimiento relacionado al disefio fue una de las més importantes contribuciones a la Ingenierfa de Soft- ware de las citimas décadas. En estas soluciones estén presentes de forma basica los criterios de buen disefio listados en la seocién anterior. Las caracteristicas salientes de expresar los disefios a través de los ppatrones son: Representan la experiencia y conocimiento de un experio Expresen un dsefio con un nivel de abstraccién superior al de las clases Establecen un idioma compacto y expresivo entre los miamibros de un grupo de desarrollo Descomponen en micro arquiteciuras la arauitectura de un sistema (Cuando analicemos alguno de los aspactes del disefio del caso testigo apelaremos al uso de estos patrones. Desai ‘Como se deriva de la arquitectura definida en el capftulo anterior, una de las aplicaciones que forman parte del sistema en desarrollo es el Administrador de Cargas. Esta es una aplicacién de tipo enterprise, ‘como se dascribié en el capitulo anterior, e incluiré, entre otras, la funcionalidad de busqueda de car- gas a pattir de un conjunto de datos asociados tal como se describié en el capitulo de requerimientos, @ partir del caso de uso CU_O15 Buscar Orden carga, Para la realizacién de la busqueda, el usuario carga los datos en un formulario (ver figura 10.10) el cual fue implementaco en este desarrollo con el nombre de BusquedaCargaForm. La solicitud de busqueda es Implementada en la capa de presentacién 4 través de la clase BusquedaCargaAction. El acceso al negocio de las tuncionalidades asooladas a la administracién de cargas esta expresada por la interfaz de negocio |AminCarga e implementade por la clase AminCarga. 14.2.1 Presentacién En la implementacién de la capa de presentacién se definis Ia utilizacién de la plataforma Struts que debe ‘ser registrada en e! archivo de configuracién de la aplicacién. En el listado que sigue se muestra este registro, ol cual seré utlizado por el servidor web (Tomcat) para administrar el funcionamiento de esta capa [10]. Alfaomega Ingenieria de Software - Pantaleo - Rinaudo eBawoeyy ‘opneuy - o9feiued - arenyos ap eyaue6U) Un sa anb ous “jeurequ] ua opeoyde 00s se ou Wx “seladuuce seinjonnse Lod Soqep seuasardas B ODeUAHO ‘efenduay “eenduey droyuey 2191SueIXe) TWX O}EULIO) UB O}HOSE UD;oEINBYUOD ep OnIYOVe Cold UN $8 81S pt ‘OFSoT-834N778 /ANI~GaM/ ‘ PT3 ‘Weeq-£3N738 /ANT-THH/ PT9 * TWAY-S9N796 /ANI~BAM/ PTS * THHY-29038 /ANT-GaM/ dst99¢/tomuios/ 90S dBE+ HOF /uOMMOD / <9p09~30148/>$07 <9 T-2uooTeM/>dsf+xepuT x/uofaoe / 3u07ge703s T Tux" Bguco-s3nx38 /ANI-GaN/ Squos cuezed-31UT> 70TATOSUO ION" UOTIOE’ s9nz98* eyDede Sx0 7 <.PIp'e€ Z dde-qam/pyp/uos-uns-eael//7dqqy, wN@//€°% VOTICOTTadY Gen GUG//*OUT ‘sueIshsoI0TW UNg//-. OTTEAS : dde-qon gaxzo0qi> - K<éu8-JEN,=BUTPODUS ,9°T,mUOTSTOA TUKE> 3 226 14 Disefio de Software esténdar para et intercambio de informacién estructurada entre diferentes plataformas, Se puede usar en bases. de datos, editores de texto, hojas de céiculo y otros. 14.2.2 Acceso al negocio La capa de Acceso al Negocio est formada por un conjunto de clases que concebidas a partir de los casos. de uso implementan la dinémica de estas funcionalidades sobre e! negocio. Suele llamérsele Capa de Servi- ios 0 Servicios de Aplicacién. Es el nexo entre la Presentacién y el Negocio, Elistado de més abajo muestra el cédigo de la clase que a partir de Ia solcitud de bUsqueda invoca los servicios de aplicacién ((AdminCarge) para que se realice dicha busqueda. package com. libroIs.struts.carga.action; import javax. servlet .http.HttpServietRequest; import javax.serviet .http.HttpServletResponse; import javax. servlet .http.HttpSession; import org.apache.struts-action.Action; import org.apache. struts.action.ActionMapping; import org.apache.struts.action-ActionForn; import org.apache. struts .action.ActionForward; import com.1ibroIs.struts.carga. service .CargaException; import com, librols.struts.carga.service. IConstantes; import com. 1ibroTS.struts.carga.view.CargaView: import com, 1ibroIs. struts.carga. form.BusquedaCargaForm; ye * Este Action es invocada por el ActionServlet cuando el usuario * zealice una busqueda de cargas. El ActionForm es una instancia de * BusquedaCargaForm. ” Public class BusquedaCargaAction extends Action { Public ActionForward execute( ActionMapping mapping, ActionForm form, ttpServletRequest: request, HttpServletResponse response ) throws Exception [ ActionForward forward = null; Collection cargas = null; BusquedaCargaForm busquedaForm = (BusquedaCargaForn) form; String identificador = busquedaForm.getIdentificador( ); String fechaPartida = busquedaForm.getFechaPartida( ): String puertoOrigen = busquedaForm.getPuertoorigen( ); Alfaomega Ingenieria de Software - Pantaleo - Rinaudo 227 String puertodestino = busquedaForm.getPuertopestino( ) String tipoCarga = busquedaForm.getTipoCarga( ); String nonbreCliente = busquedaForm.getNombreCliente( ) // se accede al cédigo de acceso al negocio serviciosCarga = getServicioBusquedaCerga( )+ // se@ invoca un servicio de negocio cargas = serviciosCarga.find(identificador, fechaPartida, puertoOrigen, puertoDestino, tipoCarga, nombreCliente) + // se preparan los recursos de la sesién HttpSession session = request.getSession (false); if(session != null) { session. invalidate( ); d session = request.getSession (true) ; 71 se disponen los xecursos en la sesién session.setAttribute( IConstantes.CARGAS, cargas }; forward = mapping. findForward (IConstantes .SUCCESS_KEY )+ return forward; private IAdminCarga serviciosCarga; public void setiadminCarga (IAdminCarga serviciosCarga) { this.serviciosCarga = serviciosCarga; y public IAdminCarga getIAdmincarga().{ return serviciosCarga; y ‘Como se decicié utitzar como plataforma a Spring, enla confguracién de Struts se debe agregar la indica ‘én de que la solcitud serd delegada para su procesamiento a Spring, aclemés del registro del “action” corres- ondiente con informacién de la carga de datos para realizar la bisqueda asi como de la pagina de respuesta ‘con el resultado exitoso 0 erréneo. Enla configuracién de Spring se debe registrar el “action” y et servicio de negocio asociado para que Spring pueda Instancievla cuando sea invocada desde el controlador correspondiente y se realice la inyeccién de la dependencia del servicio. Alfaomega Ingenieria de Software - Pantaleo - Rinaudo 231 ‘Ademés este nexo debe especificar el modo en que estos componentes serén creados y relacionados, como se muestra en la figura 14.8 y el istado de configuracién que sigue. Glass Porsistoncla Plataforma Hibernate HbemateMapping HibemateSassionFactory Figura 14,3. Diagrama esquemético que muestra a Spring (LocalSessionFactoryBean) produciendo una Hiber- nateSessionFactory desde un archivo de mapeo ${hibernate.dialect} En ellistado que sigue se muestra la implementaci6n del DAO para la clase de negocio OrdenCarga, Ingenlerfa de Software - Pantaleo - Rinaudo Alfaomega 232, 14 - Disefio de Software public class HibernateOrdenCargaDao implements OrdenCargaDao { public HibernateOrdenCargapao() (} private HibernateTemplate hibernateTemplate; public void setHibernateTemplate (HibernateTemplate template) { this.hibernateTemplate = templates , A efectos de que se realice la inyecoién de dependencia del HibernateTemplate, se debe registrar en la cconfiguracién de Spring como sigue: La persistencia es administreda a través del componente inyectado, como se muestra en el listado que sigue: public void saveOrdenCarga (OrdenCarga ordenCarga) { hibernateTemplate. savedrUpdate (ordenCarga) ; y La bisqueda de las érdenes de carga por fecha y puerto de destino se realiza como se muestra a continuaciéa: public OrdenCarga findOrdenCargaFechaPuerto(Date fecha, String puerto) { List results = hibernateTemplate.find("from ™ + ORDEN_CARGA + “ where fechaPartida = ? and puertoDestino = 2", new Object{] (fecha, puerto})+ return results.size() > 0 ? (OrdenCarga) results.get(0) : null; d La bsqueda por identificador de un nico objeto se realiza asf: public Ordencarga find(Integer id) { return (OrdenCarga) hibernateTemplate.load (OrdenCarga.class, id); » Alfaomega Ingenieria de Software - Pantaleo - Rinaudo ‘lass Persistencl “interface= raencargaDAO HbemateTempate |__| HibematesessionFactory a aT 7 HbemateOrdenCargaDAO OrdenCarga (3) Figura 14.4, Relacién entre las clases de persistencia y la plataforma Spring La adminstracién de las transacciones serd delegada por la plataforma Spring a Hibernate a través de la clase HibernateTransactionManager que funciona como un patrén de disefio de tipo facade {7}. Para esto debe registrarse en la configuracién lo siguiente: Esta clase realiza la administracién de los commit y rollback a parti de delegaciones a la clase oxg.Nber- nate, Transaction. Las transacciones son definidas en forma declarative y administradas por la propiedad AOP (aspect orien- ted programming) de la plataforma Spring [9]. Se defn pare! la mayor parte de elas un nivel de aisiacién “read commited” y una poitica de ejecuctin entre "requires new’, “required” y “supports” [], lo que significa que ante conflictos por accesos concurrentes las diferentes transacciones no son visibles hasta después de realizado e! correspondiente commit y que los métodos a ejecutarse, algunos lo harén en una transaccién nueva, otros en tuna nueva o ya abierta mientras que otros lo harén sin importar si hay una transaccién ablerta o no, 14.2.5 Conexién con sistemas externos Como analizamios en capitulos anteriores, cuando la capacidad de carga de la empresa se ve saturada, las rdenes nuevas deben tercerizarse. A efectos de integrar el sistema en desarrolo con el sistema del proveedor actual se cuenta con una API entregada por esta otra empresa a efectos de faciitar el desarrollo del software de integrecién. Debido a la imposiblidad de mooiicar el sistema de transporte de este tercero se decidis inte- rato utiizando el modo propuesto por las interfaces deciaradas en la API. La conectividad con dicho sistema serd a través de un patrén broker implementado sobre el protocolo RMI (remote method invocation). En la figura 14.5 se muestra el disefo, el cual no incluye detalles de la conectivdad. Los objetos del laco del sistema ‘externos son remotos, Se decidié asta dicho sistema detrés de un patrén de tipo facade implementado por la clase TercerizaServiciosTiansporte. Esta clase define el protocolo (conjunto de métodos) a través del oval el Ingenieria de Software - Pantaleo - Rinaudo Altaomega 234 14-- Disefio de Software sistema en desarrollo solcitaré servicios al sistema externo. Debido a un desajuste entre ambos sistemes, se utilize un patrén de tipo adapter [7] para adaptar @ amibos el cual esta implementado por la clase Adaptador- ServicioTinasportetercero cuyes instancias resuelven las solicitudes adaptando la interiaz de! sistema externo al del facade dei sistema en desarrollo, 14.2.6 Web Service ‘Como se analizé en el capitulo anterior figura 13.10) es necesario que la apicacién que administra los elien- tes exporte-el servicio de bisqueda de clientes. Este servicio estard centrado en una interfaz que llamaremos (Cliente y cuya definicién se muestra en el istaclo que sigue en formato WSDL (web service defnition lenguage) [11], Puede verse que a partir de! nombre o niimero ce cliente se obtienen sus datos. ' > ' : - - ‘ ~wsdlsinput message" impl:buscaClienteRequest” name="buseaClienteReguest”?> < ~ - - < -

    You might also like