patrones de diseño de arquitecturas de software enterprise
DESCRIPTION
Patrones de Diseño de Arquitecturas de Software Enterprise. Tesista:Diego Fernando Montaldo Director:Profesor Ing. Guillermo Pantaleo Noviembre 2005. Objetivo. Analizar los problemas que se plantean en el desarrollo de sistemas con arquitecturas enterprise. - PowerPoint PPT PresentationTRANSCRIPT
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í.
• Implementar el framework y permitir la construcción de una aplicación base completa sobre el mismo a partir del conocimiento del dominio.
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Introducción
• 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).
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• Frameworks
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
1. Programación orientada a objetos2. Desacoplar lo más posible al modelo de
dominio del resto de la aplicación3. Arquitectura basada en capas lógicas (Layer
Pattern)
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
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
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ógicas
Capa de Servicio – Service Layer
• Introducción• ServiceFactory• Data Transfer Object• Servicios Locales y/o Remotos • Unidad de Trabajo (Unit Of Work)
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso 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
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 Layer
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
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
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, Class 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
– Interfaz IPersistenceBroker– PersistenceBroker– Factory PersistenceBrokerFactory– Finders
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 LayerEn 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
– Introducción– PageController– EntityManager
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.
– Reflection– Generación de código
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• Autorización
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
• ConcurrenciaImplementación
Detección de errores
• Transaccionabilidad Unit of Work
• Sesiones• Auditoría• Excepciones
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
Desplieguedd 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 Field• Asociaciones – Foreing Key Mapping• Lógica de Negocio – Domain Model• Mapeos de objetos a tablas
– Single, Class , Concrete Table Inheritance– Inheritance Mappers
• Consistencia– Identity Map
• Unidad de Trabajo– Unit Of Work
• Acceso a Servicios Comunes – Registry
• Acceso a los Datos Persistentes– Data Mapper – Separated Interface, Lazy Load
• Control de Concurrencia – Optimistic offline lock
• Remote Façade, Data Transfer Objects• Ajax – Active Front - PageController
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
ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones
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
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo
Demo