patrones de diseño de arquitecturas de software enterprise
Post on 01-Jan-2016
70 Views
Preview:
DESCRIPTION
TRANSCRIPT
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Patrones de Diseño de Arquitecturas
de Software Enterprise Tesista: Diego Fernando Montaldo Director: Profesor Ing. Guillermo Pantaleo Noviembre 2005
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Objetivo
• Analizar los problemas que se plantean en el desarrollo de sistemas con arquitecturas enterprise.
• Examinar los patrones de diseño conocidos como solución a este tipo de problemas.
• Proponer una arquitectura que utilice, adapte e integre a estos patrones, obteniendo un framework de trabajo, que permita el desarrollo de una aplicación de tipo enterprise, teniendo resueltos a estos problemas típicos, permitiendo focalizarse en el problema del dominio del negocio en sí.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Introducción
• Sistemas de Tipo Enterprise
Dentro de lo que se denomina “Desarrollo de Software” se abarca el desarrollo de muchísimos sistemas, con características totalmente diferentes.
Cada uno con distintas complejidades y distintos objetivos, y para cada tipo de sistema se utiliza una estrategia diferente para su resolución.
Se distinguen entre todos los sistemas, a los sistemas de tipo enterprise.
ObjetivoIntroducciónSistemas de Tipo Enterprise
ArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Características de los Sistemas de Tipo EnterpriseEntre las características salientes de un sistema de tipo enterprise, según [Rod Johnson, 2003], [Martin Fowler, 2003], [Marinescu 2002] se pueden mencionar las siguientes:
1. Datos masivos (gran volumen) y persistentes.2. Lógica de negocio, lo que implica procesamiento
de datos.3. Variedad de interfaces de usuario, lo que implica
diversidad en la funcionalidad brindada.
ObjetivoIntroducciónSistemas de Tipo Enterprise
ArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
4. Integración con otros sistemas, lo que implica que comparten funcionalidad y / o datos.
5. Acceso concurrente, lo que implica gran cantidad de usuarios.
6. Disonancia conceptual (modelo de datos con distintas visiones), debido a que poseen un modelo de negocio subyacente que abarca distintos aspectos de un área de negocio. Por lo tanto prestan distintas funcionalidades a distintos tipos de usuarios.
7. Por lo general deben ser sistemas escalables y robustos.
ObjetivoIntroducciónSistemas de Tipo Enterprise
ArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Arquitectura de Sistemas de Tipo Enterprise
Ha habido muchas formas de plantear una solución para este tipo de sistemas, y básicamente todo sistema enterprise tiene una estructura cliente / servidor, distribuido en capas verticales.
ObjetivoIntroducciónSistemas de Tipo Enterprise
ArquitecturaFrameworks
ArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Frameworks
Hoy en día existen muchos frameworks que resuelven problemáticas asociadas a este tipo de arquitecturas. Desde plataformas tecnológicas, como las implementaciones de las especificaciones J2EE, la plataforma .Net de Microsoft, hasta frameworks que atacan problemas parciales (persistencia, presentación, transporte, etc) permitiendo combinarlos para obtener una arquitectura completa.
ObjetivoIntroducciónSistemas de Tipo Enterprise
ArquitecturaFrameworks
ArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Algunos de ellos son:Persistencia
• EJB Entity beans• JDBC• SQLJ• TopLink• CocoBase• Hibernate / nHibernate• JPOX (JDO)• Versant (JDO)• OBJ• Object Spaces
Presentación• Struts • WebWork• Tapestry
ObjetivoIntroducciónSistemas de Tipo Enterprise
ArquitecturaFrameworks
ArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Definiendo la Arquitectura• Criterios de Diseño
Las aplicaciones del tipo Enterprise, poseen un dominio complejo, con lógica de negocio compleja y muchas reglas de negocio, las cuales varían con el tiempo. La idea central es modelar el dominio utilizando programación orientada a objetos, obteniendo así, un modelo del dominio, formado por objetos muy similares a la realidad, que se rigen según las reglas de negocio.
Para poder acompañar los cambios del negocio, actualizando así el modelo del dominio, se buscó la manera de mantener este dominio lo mas aislado posible del resto de la aplicación, éste es el objetivo principal en este trabajo, es decir se buscó desacoplar lo más posible al modelo de dominio del resto de la aplicación.
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Para ello la arquitectura elegida es una arquitectura basada en capas lógicas (Layer Pattern), donde una de estas capas es la capa de modelo del dominio (Domain Model Layer), y ésta es la capa que buscamos que tenga el menor acoplamiento posible.
Entonces partiendo de una arquitectura cliente servidor, el primer paso es quitar toda la lógica de negocio de la capa de presentación, y volcarla en la capa de modelo del dominio. Separando así muy bien todo lo que tiene que ver con obtención de información y presentación al usuario, de la lógica del dominio modelado.
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
cd Ev olución de Capas 1
DataSource Layer
Presentation Layer
Domain Model Layer
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
En una aplicación, vamos a encontrar lógica y reglas de negocio del dominio modelado, y lógica y reglas de negocio de la aplicación particular en sí, de acuerdo a como ésta hace uso del dominio.
Se busca que la lógica del dominio quede en la capa de dominio, pero no la lógica de aplicación, ya que ésta no es parte del dominio sino de la aplicación que hace uso de él.
Por lo que ingresamos otra nueva capa, la Service Layer, que haciendo uso del dominio, brinda los servicios necesarios para satisfacer los requerimientos de la aplicación.
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
cd Ev olución de Capas 2
DataSource Layer
Domain Model Layer
Serv ice Layer
Presentation Layer
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Aun vemos que la capa del modelo del dominio sigue teniendo cierto acople con la capa de datos. Queremos evitar este conocimiento desde el modelo a la capa de datos, es decir lo que ahora buscamos es que el modelo, no conozca la manera en que sus datos son persistidos o almacenados, en la capa de datos, ya que éste es un problema tecnológico que no tiene nada que ver con los problemas del dominio a resolver, lo que nos lleva a introducir una nueva capa entre ambas, ésta capa es la capa de persistencia.
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
cd Ev olución de Capas 3
Presentation Layer
Domain Model Layer
DataSource Layer
Serv ice Layer
Persistence Layer
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
cd Distribución de lógica sobre las Capas
DataSource Layer
Domain Model Layer
Persistence Layer
Presentation Layer
Serv ice Layer
Componentes de PresentaciónLógica de Presentación
Lógica de la AplicaciónReglas de negocio de la AplicaciónTransacciones de Negocio (Casos de Uso)
Modelo del DominioReglas de Negocio del Dominio
Logica de PersistenciaTransacciones del DBMS
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCriterios de Diseño
CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Capas LógicasDefinida la arquitectura se analiza la implementación de cada capa lógica
• Capa de Servicio – Service LayerTambién denominada Fachada de Servicio (Facade) [Martin Fowler, 2003] [Marinescu 2002], es la encargada de brindar los servicios necesarios a la capa de presentación.
Contiene la lógica de la aplicación, en forma de transacciones de negocio.
Todos los servicios necesarios para la capa de presentación referidos al dominio estan expuestos en la interfaz de servicio, lo que permite separar fisicamente ambas capas y jugar el papel de interfaz remota en dichos casos.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• La capa de presentación conoce las interfaces de servicio y cuenta con una Factory de servicios (ServiceFactory), para obtener una implementación de dicha interfaces.
• Los parámetros intercambiados entre ambas capas son objetos DTO (Data Transfer Object) [Martin Fowler, 2003] que son objetos simples (POJOs) utilizados para el intercambio de información.
ObjetivoIntroducciónArquitecuraCapasServicio
Modelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
cd Figura 5
presentation
+ fwk
(from framework)
fwk
+ ActionServlet
+ EntityController
+ Invoker
+ PageController
(from presentation)
Servidor de Presentación (Web) Servidor de Aplicaciones
serv ice
+ BaseService
+ pequi
(from framework)
pequi
+ clientes
+ ot
+ personas
(from service)
ot
+ ComponenteService
+ EstadoDeOrdenService
+ EstadoDeProcesoService
+ MaterialService
+ NotaService
+ ObservacionService
+ OrdenDeTrabajoService
+ ProcesoService
+ SolicitanteService
+ TipoDeProcesoService
+ TipoMaterialService
+ TurnoService
(from pequi)
iserv ice
+ IBaseService
+ dtoEntities
+ pequi
(from framework)
pequi
+ clientes
+ ot
+ personas
(from iservice)
ot
+ IComponenteService
+ IEstadoDeOrdenService
+ IEstadoDeProcesoService
+ IMaterialService
+ INotaService
+ IObservacionService
+ IOrdenDeTrabajoService
+ IProcesoService
+ ISolicitanteService
+ ITipoDeProcesoService
+ ITipoMaterialService
+ ITurnoService
(from pequi)
dtoEntities
+ CustomData
+ pequi
(from iservice)
ot
+ ComponenteDTO
+ EstadoDeOrdenDTO
+ EstadoDeProcesoDTO
+ MaterialDTO
+ NotaDTO
+ ObservacionDTO
+ OrdenDeTrabajoDTO
+ ProcesoDTO
+ SolicitanteDTO
+ TipoDeProcesoDTO
+ TipoMaterialDTO
+ TurnoDTO
(from pequi)
remoting
+ client
+ server
(from framework)
client
Service
+ ServiceFactory
(from remoting)
serv er
+ ServicePublisher
(from remoting)
Servidor de Remoting (RMI)
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Servicios Locales y/o Remotos La capa de servicio puede ser desarrollada para una arquitectura local y/o remota. Se quiere que ésto sea transparente a la capa de presentación.
Clases de servicios del dominio
Clases genéricas del Framework
RMI - jdk
UnicastRemoteObject
BaseService
ConcreteService
«interface» Remote
«interface» IBaseService
«interface» IConcreteService
«realize»
«realize»
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
cd Figura 7
Presentation Serv iceFactory RMI Registry Serv icePublisher
System Administrator
Serv ice Serv ice2
Escenario de creación y registración de servicios.
Escenario de obtención de servicios. Caso Servicio LocalServidor de Presentación es el mismo que servidor de Aplicaciones y no es necesario un servidor RMI
Escenario de obtención de servicios. Caso Servicio Remoto
SERVIDOR DE PRESENTACIÓN SERVIDOR RMI SERVIDOR DE APLICACIONES
runServices
getServicesInfo()
new
service
rebind(service)
new
service2rebind(service2)
getService(serviceName)
getServiceInfo(serviceName)
new
service2service2
getService(serviceName)
getServiceInfo(serviceName)
lookUp(serviceName)
serviceservice
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Capa de Modelo de Dominio - Domain Model LayerUno de los objetivos propuestos es que la capa de dominio este lo mas desacoplada posible del resto de las capas, por lo que no debe conocer a la capa de persistencia. La capa de persistencia es la que conoce al dominio y sabe como recuperar y alamacenar objetos de dominio.Sin embargo es necesario contar con cierta lógica relacionada a la persistencia, esta lógica puede estar ubicada en una clase base denominada DomainObject [Martin Fowler, 2003] como lo propone el patrón Domain SuperType, [Martin Fowler, 2003] donde cada objeto de dominio la extiende. Pero este esquema es un poco intrusivo ya que la clase de dominio debe sobrecargar ciertos métodos de DomainObject generando una fuerte dependencia de la capa de dominio a la capa de persistencia ya que DomainObject es una clase que forma parte de la capa de persistencia.
ObjetivoIntroducciónArquitecuraCapasServicioModelo del DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Para romper con esta dependencia recurrimos al uso del patrón de diseño Adapter.
cd Data Model
Serv ice Layer ClaseDominio
ClaseDominioAdaptada DomainObject
ObjetivoIntroducciónArquitecuraCapasServicioModelo del DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Sin embargo este patrón no alcanza a resolver completamente el problema ya que los objetos del dominio necesitan ser manipulados en la capa de Persistencia de una manera genérica, es decir la capa de persistencia espera una interfaz común a todos los objetos de dominio para poder manejarlos abstractamente sin saber que clase de dominio concreta es.
• Por esta razón fue introducida la interfaz IDomainObject.
ObjetivoIntroducciónArquitecuraCapasServicioModelo del DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Serv ice Layer ClaseDominio
ClaseDominioAdaptada DomainObject
«interface»
IDomainObject
«realize»«realize»
ObjetivoIntroducciónArquitecuraCapasServicioModelo del DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Capa de Persistencia – Persistence Layer
La capa de persistencia es la encargada de abstraer y resolver el acceso a datos a un motor de base de datos relacional.
Su objetivo es ser la única que conoce como son persistidos los objetos de dominio de la aplicación y como recuperarlos abstrayendo el choque de impedancias entre objetos y tablas relacionales.
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
La capa de persistencia, se expone a través de la interfaz IPersistenceBroker.La existencia de ésta interfaz es desacoplar como trabaja la capa de persistencia. Esta interfaz expone métodos como por ejemplo: crear un objecto de dominio, borrarlo, realizar búsquedas por clave y por distintos criterios.Para obtener una implementación de este broker de persistencia, se utiliza la factory PersistenceBrokerFactory. Con ella se obtiene a una instancia concreta del broker de persistencia. Este broker puede ser visto como un ORM, que se obtiene a través de una Factory de ORMs que cumplen con dicha interfaz.
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
cd Figura 10
Clase dePresentación
Clase deServ icio
PersistenceBrokerFactory PersistenceBroker
find(parámetros de búsqueda )
getInstance(PersistenceBrokerName)new
aPersistenceBrokeraPersistenceBroker
newUnitOfWork
findAll(Criterio, Parámetros)
aCollection
toDTO(aCollection)
commitUnitOfWorkDTOCollection
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Este PersistenceBroker es el único acceso a la capa de persistencia.
Para evitar el uso de código SQL que puede necesitarse para las búsquedas por criterio predefinidas, se utilizó un esquema de Finders. Un Finder recibe un nombre y define una sentencia SQL con parámetros en un archivo xml. Luego un método de servicio puede solicitar los objetos resultantes de un Finder y el DataMapper puede obtener la sentencia SQL asociada al mismo.Esto permite que el código SQL este agrupado en estos files xml, permitiendo que sean facilmente modificables y actualizables.
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Algunos de los requerimientos buscados para la capa de persistencia son los siguientes [Scott Ambler 1]
• Manejar distintos tipos de mecanismos de persistencia (Single, Concrect, y Table Inheritance)
• Encapsular los mecanismos de persistencia (utilizando métodos al estilo: save(obj), delete(obj), create(obj), retrieve(obj))
• Manejo de transacciones• Identificación de objetos• Utilización de Proxies• Posibilidad de realizar consultas
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Capa de Presentación – Presentation Layer
Esta es la capa que interactua con el usuario final, es la encargada de presentar la información y recolectarla para hacer uso de los servicios expuestos por la capa de servicio, para satisfacer los casos de uso de la aplicación.
En este trabajo se utilizó como tecnología principal una interfaz web, a través del uso de un browser. Pero la capa de servicio, puede ser consumida desde cualquier tecnología vinculada, como clientes ricos, dispositivos móviles, etc
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Para la obtención de vistas (páginas jsp) se utiliza el patrón PageController que permite obtener una vista perteneciente a un módulo.Las vistas pertenecen a un módulo y están definidas en un xml (modules.xml)Cada vista obtenida por el PageController mantiene un estándar de encabezado y pie de página, en el encabezado se visualiza un nombre para la vista y el pie de página contiene una sección destinada a visualizar mensajes al usuario y una botonera con botones que toman diferentes acciones sobre la vista. Toda esta información es configurada en el archivo xml perteneciente a la vista.
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
cd Figuras PageController
PageControllerBrowser Cliente
/servlet/PageController?module=moduleName&view=viewName
getViewInfo(Module, View)
buildHeaderFooter()
html Page
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Por otro lado vamos a ver que muchas de los casos de uso del negocio van a ser para el manejo de creación, modificación y borrado de entidades de negocio, (servicios básicos de abm de una entidad que expone la capa de servicio). Es decir vamos a tener muchas vistas relacionadas a los abms de entidades. Este manejo se generalizó a través de vistas para “Administración” (Managers) que permiten buscar la entidad a través del uso de filtros y eliminarla o editarla o crear una nueva, a través de la vistas para “Edición” y “Alta” (Editor y New) que permiten la modificación de la entidad, y la vista de Selección (Selector) que permite seleccionar una entidad para utilizarla en otra vista.Todas estas vistas para manejos de abm y selección son manejadas a través de un control llamado EntityManager, que a partir de un nombre de vista y tipo, presenta dicha vista para manejo de esa entidad a través de los métodos expuestos en la capa de servicio.
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
cd Figuras EntityController
Browser Cliente EntityController
/servlet/EntityController?entity=entityName&useCase=useCaseType
EntityInfo:= getEntityInfo()
buildPage(EntityInfo)
html Page
ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación
FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
cd Caso de Estudio - Pequi
presentation
+ fwk
(from framework)
fwk
+ ActionServlet
+ EntityController
+ Invoker
+ PageController
(from presentation)
iserv ice
+ IBaseService
+ dtoEntities
+ pequi
(from framework)
dtoEntities
+ CustomData
+ pequi
(from iservice)
serv ice
+ BaseService
+ pequi
(from framework)
pequi
+ clientes
+ ot
+ personas
(from iservice)
ot
+ IComponenteService
+ IEstadoDeOrdenService
+ IEstadoDeProcesoService
+ IMaterialService
+ INotaService
+ IObservacionService
+ IOrdenDeTrabajoService
+ IProcesoService
+ ISolicitanteService
+ ITipoDeProcesoService
+ ITipoMaterialService
+ ITurnoService
(from pequi)
domainModel
+ fwk
(from framework)
fwk
+ pequi
(from domainModel)
pequi
+ clientes
+ ot
+ personas
(from fwk)
ot
+ ComponenteFwk
+ EstadoDeOrdenFwk
+ EstadoDeProcesoFwk
+ MaterialFwk
+ NotaFwk
+ ObservacionFwk
+ OrdenDeTrabajoFwk
+ ProcesoFwk
+ SolicitanteFwk
+ TipoDeProcesoFwk
+ TipoMaterialFwk
+ TurnoFwk
(from pequi)
pequi
+ clientes
+ ot
+ personas
(from service)
ot
+ ComponenteService
+ EstadoDeOrdenService
+ EstadoDeProcesoService
+ MaterialService
+ NotaService
+ ObservacionService
+ OrdenDeTrabajoService
+ ProcesoService
+ SolicitanteService
+ TipoDeProcesoService
+ TipoMaterialService
+ TurnoService
(from pequi)
persistence
+ caseStudy
+ fwk
(from framework)
caseStudy
+ pequi
(from persistence)
pequi
+ clientes
+ ot
+ personas
(from caseStudy)
ot
+ ComponenteMapper
+ EstadoDeOrdenMapper
+ EstadoDeProcesoMapper
+ MaterialMapper
+ NotaMapper
+ ObservacionMapper
+ OrdenDeTrabajo_pequi_ot_MaterialDomainObjectCollectionRelation
+ OrdenDeTrabajo_pequi_ot_Observacion_mtmDomainObjectCollectionRelation
+ OrdenDeTrabajo_pequi_ot_ProcesoDomainObjectCollectionRelation
+ OrdenDeTrabajoMapper
+ ProcesoMapper
+ SolicitanteMapper
+ TipoDeProcesoMapper
+ TipoMaterialMapper
+ Turno_pequi_personas_PersonaFisica_mtmDomainObjectCollectionRelation
+ TurnoMapper
(from pequi)
utils
+ caseStudy
+ exceptions
+ helpers
+ log
+ persistence
(from framework)
caseStudy
+ NonPersistenceBroker
+ PersistenceBrokerFactory
+ StringHelper
+ IKey
+ IPersistenceBroker
(from uti ls)exceptions
+ ApplicationException
+ BusinessLogicException
+ ConcurrencyException
+ ExpiredSessionException
+ InvalidSessionException
(from uti ls)
helpers
+ CesarEncriptCryptographyHelper
+ ClassHelper
+ ConvertHelper
+ IOHelper
+ NonEncriptCryptographyHelper
+ PhpHelper
+ Serializer
+ TypeHelper
+ XmlHelper
+ ICryptographyHelper
(from uti ls)
log
+ ConsoleLog
+ FileLog
+ Logger
+ ILog
(from uti ls)
persistence
+ StorageMediumException
+ IReaderStorageMedium
+ IStorageMedium
+ db
(from uti ls)
db
+ BDatos
+ BDatosException
(from persistence)
pequi
+ clientes
+ ot
+ personas
(from dtoEntities)
ot
+ ComponenteDTO
+ EstadoDeOrdenDTO
+ EstadoDeProcesoDTO
+ MaterialDTO
+ NotaDTO
+ ObservacionDTO
+ OrdenDeTrabajoDTO
+ ProcesoDTO
+ SolicitanteDTO
+ TipoDeProcesoDTO
+ TipoMaterialDTO
+ TurnoDTO
(from pequi)
fwk
+ Context
+ DomainObject
+ DomainObjectCollection
- DomainObjectCollectionIterator
- DomainObjectCollectionIterator
+ DomainObjectCollectionRelation
+ IdentityMap
+ Key
+ KeyGenerator
+ Mapper
+ PersistenceBroker
+ Registry
+ UnitOfWork
+ IDomainObject
+ IFinder
+ IKeyGenerator
(from persistence)
remoting
+ client
+ server
(from framework)
client
Service
+ ServiceFactory
(from remoting)
serv er
+ ServicePublisher
(from remoting)
«xml»
Finder
«xml»
Regsitry
«xml»
Modules
«xml»
Actions
«xml»
Presentation Serv ices
Application Serv ices
«xml»
Entites
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetes
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Si se observa el código de la parte especializada se nota que la misma es repetitiva y que puede automatizarse.
Una opción de automatizarla es mediante reflection, es decir que en tiempo de ejecución las clases del framework agreguen el comportamiento dado, leyendo la información faltante desde archivos descriptores, y la otra opción es la de generación de código, es decir generar las clases necesarias que especializan al framework en tiempo de desarrollo.
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Aspectos Relacionados
Seguridad Autenticación y Autorización (Control de Acceso)
• Autenticación : Es el proceso por el cual se verifica que alguien (un sistema o un usuario) es quien dice ser.
• Autorización : Es el proceso por el cual se distingue si una persona, una vez autenticada, tiene o no permiso de acceso a un recurso. Seguridad al nivel Servidor de PresentaciónSeguridad al nivel Servidor de Aplicaciones
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
cd Control de Acceso
«interface»
caseStudy::IAccessControl
+ login( name, password) : Token+ logout(Token) : void+ checkValideSession(Token) : void+ checkPermission(Context) : void
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Concurrencia
La concurrencia al sistema se implementó a partir del manejo de threads que dispone el servidor web administrando servlets, mediante la generación de un nuevo thread frente a cada nuevo request.Para resolver los problemas generados por el acceso concurrente al sistema y evitar adaptaciones perdidas y lecturas inconsistentes se implementó un esquema de detección de estos escenarios.Para esto se balanceó la corrección de los datos y la responsibidad del sistema. Se utilizó un patrón que detecta errores y genera avisos de que la transacción tuvo problemas y hay que rehacerla. El patrón utilizado es Optimistic Lock.
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• TransaccionabilidadLa transaccionalidad del sistema se implementó mediante la administración de las transacciones de negocio por un patrón llamado Unit of Work. El mismo lleva un registro de los objetos que participaron en la transacción y de que forma lo han hecho, y frente a un comando commit, genera las acciones para mantener la consistencia entre dichos objetos y los de la base de datos.
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Sesiones
La sesión puede administrarse en el cliente, el servidor de aplicación, la base de datos, la memoria del web server
Se optó por utilizar sesión en el web server para mantener información de contexto vinculada a la seguridad, y si es necesario para vistas que necesiten hacer uso de ella, pero no compartir sesión entre distintas capas.
Compartir sesión entre las capas, hace que sea difícil escalar la aplicación mediante el uso de mas servidores, ya que si comparten sesión dos servidores, se genera un vínculo entre ellos, dificultando por ejemplo cambiar una petición (por balanceo de carga) a otro servidor de aplicaciones que se encuentra con menor carga de procesamiento en un instante dado.
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• AuditoríaLa auditoría del sistema debería incluirse en la capa de servicio, ya que este es el punto de acceso a los mismos, antes de ejecutar el servicio y justo despues de autorizar, podría loguearse que servicio y con que parámetros utilizó cierto usuario, mas información adicional como fecha, hora, ubicación física, etc
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Excepciones
Inicialmente se pueden clasificar las excepciones en dos grandes jerarquías, una orientada a excepciones de negocio, es decir infracciones a reglas de negocio y otra orientada a excepciones ocurridas por errores en runtime en la aplicación, como ser la indisponibilidad de la red, de la base de datos, etc.
• De Negocio : BusinessLogicException• De Aplicación : ApplicationException
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
cd Excepciones
exceptions::ApplicationException
- innerException: Exception
+ ApplicationException()+ ApplicationException(String)+ ApplicationException(Exception)
exceptions::BusinessLogicException
- innerException: Exception
+ BusinessLogicException()+ BusinessLogicException(String)+ BusinessLogicException(Exception)
exceptions::ConcurrencyException
+ ConcurrencyException(String)+ ConcurrencyException(Exception, String)
Toda excepción producida por fallos en la aplicación que no se deban a reglas de negocio heredan de ApplicationException
La capa de presentación puede visualizarun mensaje genérico de error, pidiendo al usuario que se comunique con el servicio técnico de la aplicación.Esta excepción generalmente es logueada y se notifica al administrador.
Toda excepción que ocurra debido a que no se cumple con una regla de negocio hereda de BusinnessLogicException y el cliente (capa de presentación) decidirá que hacer con ella.Normalmente le informa al usuario visualizando el mensaje de la regla de negocio que no se cumple.
ConcurrencyException es la excepción que ocurre cuando se quiera actualizar, oborrar un objeto cuya versión no es la versión con que el usuario estuvo trabajando, es decir alguien modificó algún objeto interviniente mientras el lo estaba usando. Esto es por el uso de OptimisticLock para el manejo de concurrencia.
Exception
UnAuthorizedException
+ UnAuthorizedException()+ UnAuthorizedException(String)+ UnAuthorizedException(Exception)
Inv alidSessionException
+ InvalidSessionException(String)
UnAuthenticatedException
+ UnAuthenticatedException()+ UnAuthenticatedException(String)+ UnAuthenticatedException(Exception)
ExpiredSessionException
+ ExpiredSessionException(String)
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Despliegue
El framework permite que la aplicación sea desplegada físicamente en un único servidor o en varios servidores. Esta propiedad permite separar fisicamente la capa de presentación de la capa de negocio (en un Servidor de Presentación y otro Servidor de Aplicaciones).En estos casos, puede utilizarse un firewall para poner la limitación de que sólo el Servidor de Presentación tenga acceso al Servidor de Aplicaciones.Del mismo modo, si se separa físicamente la capa de persistencia de la capa de datos (en un Servidor de Aplicaciones y otro Servidor de Datos) puede limitarse con un firewall el acceso al Servidor de Datos y permitirle acceder solo al Servidor de Aplicaciones.
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
dd Despliegue
Cliente (Browser)
Serv idor Web
Serv idor de Aplicaciones
Serv idor de Base de Datos
«library»
Componentes::Back.jar
«library»
Componentes::Front.war
«library»
Componentes::Common.jar
Componentes : FrontComponentes : Common Componentes : Back
<< TCP / IP >>
<< HTTP >>
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
dd Despliegue Logico
Serv idor Web
Cliente (Browser)
Serv idor de Aplicaciones
Serv idor de Base de Datos
Presentation Layer
Service Interface
Domain ModelLayer
Persistence Layer
Service Layer
Service Interface
Persistence InterfaceData Source Layer
Proxy Proxy
ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados
SeguridadConcurrencia
TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue
PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Patrones Utilizados
• Identidad - Identity FieldIdentity Field
Identity Map
Foreign Key
Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance
Compound Key
Simple o Compuesta
Unica por base o clase
Unica por base o clase ojerarquia de clasesUnica por base o clase
o jerarquía de clases
Unico por base o clase, Simple o Compuesto
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Clave Simple • Clave Numérica• Única por Base de Datos• Comportamiento en DomainObjectAdaptada• Manejo de Clave administrado por tablas
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Asociaciones
Se utilizaron los patrones Foreign Key Mapping, Association Table Mapping [Martin Fowler, 2003] para mantener las relaciones entre objetos.
En el caso de la asociación uno a uno, se añade el uso del patrón Lazy Load para evitar la carga transitiva de los objetos asociados. El mismo retrasa la carga de la instancia en forma transparente hasta el momento de ser utilizada. Esto está implementado en los getters de las clases DomainObjectAdaptadas ya que son redefinidos en ésta clase derivada para agregar este comportamiento.En las relaciones de uno a muchos, y muchos a muchos, se utilizó una AbstractDomainObjectCollection que es una variante del patrón Value List Holder.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Relación entre los patrones
cd Data Model
ForeignKey IdentityField
LazyLoad
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Mapeos de objetos a tablas
• Single Table Inheritance • Class Table Inheritance• Concrete Table Inheritance
Se seleccionó la de Class Table Inheritance como mapeo por defecto para el generador de código (pero puede utilizarse cualquiera en el framework). Se seleccionó este tipo de mapeo porque administra los datos en forma normalizada en la base de datos y es mas directa la analogía entre una clase y una tabla.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Identity Field
Identity Map
Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance
Inheritance Mapper
Compound Key
Unica por base o portabla
Unica por base o tabla ojerarquia de clasesUnica por base o tabla o
jerarquía de clases
Unico por base o tabla, Simple o Compuesto
Unico?
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Consistencia
Se garantiza la consistencia entre objetos cargados de la base de datos.Se debe asegurar una sola instancia de cada objeto en una misma transacción, a efectos de evitar inconsistencias al cambiarlo. Este problema se resuelve aplicando el patrón Identity Map
• ¿ Tipo de Clave ?• ¿ Identity Map explícito o genérico ?• ¿ Cúantos ?• ¿ Dónde ?
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
finder Identity Map base de
datosAlgun Objeto
find(1)
found = get(1)
[found is null] found = select where id = 1
[found not null] found
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Patrones Relacionados
Identity Field
Identity Map
Concrete Table Inheritance
Data Mapper (Cuantos ???)
Compound Key
Optimistic Offline
Unit of Work
Registry
Unica por base o tabla ojerarquia de clases
Donde ?
Unico por base o tabla, Simple o Compuesto
Clave compuesta ?
Unico?
Donde ?
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Unidad de Trabajo
Cuando existen transacciones en las cuales se crean y modifican objetos, es indispensable mantener la consistencia de los objetos en memoria sobre los que se opera, y los datos correspondientes en la base de datos. Se debe conocer cuales son los cambios realizados para hacerlos persistentes. Por lo tanto es importante saber cuales objetos son nuevos, cuales fueron cargados desde la base de datos y no fueron alterados y cuales sí. Este problema es resuelto con el patrón Unit of Work. [Martin Fowler, 2003]
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Ubicación, la Unit of Work puede estar en la sesión, puede pasarse como parámetro entre los objetos que la usan, o puede localizarse en la Registry. En este caso se optó de ponerlo en la Registry, la cual garantiza ser única por thread y facilita el acceso de la misma.
Session
UnitOfWork
New Objects DirtyObjects DeletedObjects
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Acceso a Servicios Comunes
Al existir un número grande de clases, de las cuales muchas de ellas hacen uso de determinados servicios comunes se implementó el patrón Registry al cual se accede para obtener determinados servicios, por ejemplo obtener un finder.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Acceso a los Datos Persistentes
Entre Table Data Gateway, Row Data Gateway, Active Record, Data Mapper se seleccionó al Data Mapper para acceso a los datos, ya que es el mas adecuado para trabajar con Domain Model.
:ClaseDominio :Mapper «Table»
:ClaseDominioTabla
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Control de Concurrencia
– Optimistic offline lock – Pessimistic offline lock
En el framework desarrollado se usó la variante Optimistic offline lock. Dicha implementación consta del versionado de los DomainObject y el control de la versión al momento del cierre de cada una de las transacciones del negocio. Si alguno de los objetos afectados dentro de dicha transacción no corresponde a la versión persistida, se genera una excepción de concurrencia.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Ajax – Active Front
Generalmente el usuario obtiene una vista y trabaja con los datos obtenido por ella, modificando agregando, filtrando la información que contiene. En un entorno Web, ante cada acción se vuelve a enviar una acción la servidor yse recarga la vista (aunque ésta sea la misma, pero con otros datos) Este patrón, una vez cargada una vista, permite invocar los servicios sin recargar la vista. Obteniendo los datos resultantes para luego impactar con dicho resultado en la vista actual.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field
AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front
GeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
• Relaciones entre los patronescd Relaciones Entre Patrones II
Use Case
Use CaseActor
DomainModel
TransactionScript TableModule
ActiveRecord
RowData Gateway
TableData Gateway
DataMapper
Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance
Inheritance Mapper
Pessimitic Offline Lock
Optimistick Offline Lock
Coarse-Grained Lock
Layer SuperType
Identity Field
ForeingKey Mapping
AssociationTable Mapping
Unit Of Work
Registry
IdentityMap Lazy Load
Service Layer
Remote Facade
Data Transfer Object
Assembler
Session
ubicada
Separated Interface
acceso a DB
Negocio Complejo
mapeo de jerarquía
Finders
optimizacion de consultas
admin proxy/holder
control de versión
modelo simple
mapeo de jerarquía
acceso a DB
soportedeherencia
modelo complejo
control de concurrencia
root de jerarquía de objetos
modelo simple
Negocio Intermedio
Negocio Simple
acceso a DB
implementado en términos de
ensambla
genera
desacoplar clases intercambiadas
objetos distribuidosmapeo de jerarquía
administrar relaciones
implementado en términos de
identificación de DomainObjects
admin y almacenar info de identidad
carga tardía al navegar al root
admin y almacenar info de versión
alberga
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Generador de Código
El generador de código genera, a partir de información de las clases de dominio, las clases que especializan a las clases base de frameworkPor ejemplo
cd Data Model
Mapper
# Save(IDomainObject) : void
PersonaMapper
# Save(IDomainObject) : void
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Caso de Estudio• Descripción del dominio
Una empresa gráfica administra sus trabajos en Ordenes de Trabajo. Cada Orden de trabajo esta compuesta por Procesos, por ejemplo la Orden de Trabajo con nombre “Revista Noticiero”, esta compuesta por 2 procesos, uno de “Filmación” y otro de “Ploteo”. Todos los procesos deben realizarse para poder terminar la orden de trabajo. Cada proceso esta asignado a un Turno de trabajo. Los turnos de trabajo son tres, “mañana”, “tarde” y “noche”. Cada Turno esta compuesto por empleados de la empresa. Cada proceso puede tener una nota asociada, un Solicitante, y posee un conjunto de componentes, los componentes del trabajo, por ejemplo, la “tapa”, el “interior”, sus “pliegos”, etc Cada proceso tiene un “estado”, cuando todos los procesos de una orden están terminados, entonces la orden de trabajo estará terminada. Cada proceso tiene un tiempo asignado para su resolución.La orden de trabajo es para un cliente dado y tiene asociados un conjunto de materiales. Se almacenan la información asociada a los clientes y empleados, como domicilio, cuit, y teléfono.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Transición del Análisis al diseño• Casos de Uso
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Modelo de Dominio
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Trabajo a Futuro Agregar otros protocolos de comunicación entre capas• Agregar otras formas de mapeo de herencia de objetos a
relacional Clustering Administración de pool conexiones• Mejorar administración de colecciones en el dominio Integración con herramientas estándar (IDEs, Eclipse,
EA, etc) Mejorar la dinámica de generación ( refactoring del
dominio y adaptación automática de la base) Auditoría Generación automática de otras interfaces de
presentación Optimización de interacción con el motor de base de
datos
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Conclusiones
• Separación en CapasSeparar problemas, trabajar en paralelo con diferentes roles.
• Uso de PatronesPermite hablar con mayor claridad y alto nivel a los participantes del desarrollo. No reinventar la rueda. Tener alternativas útiles a problemas conocidos.
• Uso de frameworksFacilitan el desarrollo de una aplicación, start up rápido, foco en el probleba del negocio.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
top related