Diseo de Patrones de Arquitecturas de Software Enterprise

1
Patrones de Diseño de Arquitecturas de Software
Enterprise

• Tesista Diego Fernando Montaldo
• Director Profesor Ing. Guillermo
  Pantaleo
• Noviembre 2005

2
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.

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

3
Introducción

• Características de los Sistemas de Tipo
  Enterprise
• Entre 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
• Datos masivos (gran volumen) y persistentes.
• Lógica de negocio, lo que implica procesamiento
  de datos.
• Variedad de interfaces de usuario, lo que implica
  diversidad en la funcionalidad brindada.

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

4

• 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.
• Disonancia conceptual (modelo de datos con
  distintas visiones).
• Por lo general deben ser sistemas escalables y
  robustos.

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

5

• 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

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitectura
• Frameworks
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

6
Definiendo la Arquitectura

• Criterios de Diseño
• Programación orientada a objetos
• Desacoplar lo más posible al modelo de dominio
  del resto de la aplicación
• Arquitectura basada en capas lógicas (Layer
  Pattern)

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

7

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

8

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

9

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

10

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

11

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

12
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)

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

13

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

14

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

15

• Capa de Modelo de Dominio - Domain Model Layer

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo del Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

16

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo del Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

17

• 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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

18

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

19

• Capa de Presentación Presentation Layer
• 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
• Introducción
• PageController
• EntityManager

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

20

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

21

• 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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

22
Aspectos Relacionados

• Seguridad Autenticación y Autorización (Control
  de Acceso)
• Autenticación
• Autorización
• Seguridad al nivel Servidor de Presentación
• Seguridad al nivel Servidor de Aplicaciones

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

23

• Concurrencia
• Implementación
• Detección de errores
• Transaccionabilidad
• Unit of Work
• Sesiones
• Auditoría
• Excepciones

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

24

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

25

• Despliegue

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

26

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

27
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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

28

• Relaciones entre los patrones

29

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

30
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 framework
• Por ejemplo

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

31

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

32
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.

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

33

• Transición del Análisis al diseño
• Casos de Uso

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

34

• Modelo de Dominio

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

35
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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

36
Conclusiones

• Separación en Capas
• Separar problemas, trabajar en paralelo con
  diferentes roles.
• Uso de Patrones
• Permite hablar con mayor claridad y alto nivel a
  los participantes del desarrollo. No reinventar
  la rueda. Tener alternativas útiles a problemas
  conocidos.
• Uso de frameworks
• Facilitan el desarrollo de una aplicación, start
  up rápido, foco en el probleba del negocio.

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

37
Demo