Arquitectura de Software. Juan Bernardo Quintero

Transcripción

1 Arquitectura de Software Juan Bernardo Quintero

2

3

4 Catálogo de Patrones Nombre Corto Nombre Completo Propósito Básico Autor Año GoF Gang of Four Solución de problemas del diseño POSA J2EE PoEAA GRASP Pattern-Oriented Software Architecture Java 2 Enterprise Edition Patterns of Enterprise Application Architecture General Responsibility Assignment Software Patterns Definición de estrategias arquitectónicas Diseño de aplicaciones para esta plataforma Definición de los contenidos de las capas Tránsito entre el análisis y el diseño Gamma, et al. Buschmann, et al. Alur, et al. (Sun) Fowler 2003 Larman 2005

5 Catálogo GoF Propósito Creación Estructural Comportamiento Ámbito Clase Factory Method Adapter Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsability Command Iterator Mediator Memento Observer State Strategy Visitor

6 Catálogo POSA Estrategia Del fango a la estructura Sistemas distribuidos Sistemas interactivos Sistemas adaptables Capas Tubería-filtros Pizarra Nombre del Patrón Broker (Por ejemplo CORBA, DCOM, Web Services, WWW) Model-View-Controller Presentation-Abstraction-Control Reflection: metanivel que hace al software consciente de sí mismo. Microkernel: núcleo de funcionalidad mínima.

7 Catálogo J2EE (1 Edición)

8 Catálogo J2EE (2 Edición)

9 Catálogo PoEAA (1) Pattern Type Domain Logic Data Source Architectural Object-Relational Structural Transaction Script Domain Model Table Module Service Layer Pattern Name Table Data Gateway Row Data Gateway Active Record Data Mapper Identity Field Foreign Key Mapping Association Table Mapping Dependent Mapping Embedded Value Serialized LOB Single Table Inheritance Class Table Inheritance Concrete Table Inheritance Inheritance Mappers

10 Catálogo PoEAA (2) Pattern Type Object-Relational Behavioral Object-Relational Metadata Mapping Web Presentation Distribution Unit of Work Identity Map Lazy Load Metadata Mapping Query Object Repository Pattern Name Model View Controller Page Controller Front Controller Template View Transform View Two-Step View Application Controller Remote Façade Data Transfer Object

11 Catálogo PoEAA (3) Pattern Type Offline Concurrency Session State Base Pattern Name Optimistic Offline Lock Pessimistic Offline Lock Coarse Grained Lock Implicit Lock Client Session State Server Session State Database Session State Gateway Mapper Layer Supertype Separated Interface Registry Value Object Money Special Case Plugin Service Stub Record Set

12 Catálogo GRASP Pattern Name Creator Information Expert Controller Low Coupling High Cohesion Polymorphism Pure Fabrication Indirection Protected Variations Related Topic Factory pattern Information hiding Model view controller Loose coupling Cohesion (computer science) Polymorphism in object-oriented programming Service (systems architecture) Delegation pattern Delegation pattern

13

14 Arquitectura de Aplicaciones Web FRENTE FÍSICO Cliente/Servidor Especificación Arquitectónica Usuario FRENTE LÓGICO M-V-C Patrón Front-End Vista T I E R S Middleware RIA Controlador L A Y E R S Back-End Modelo

15 Las Layers de cada Tier

16 Frameworks en las Tiers

17 Costos de la invocación entre Tiers Interfaces $$$... Patrón MVC? Lógica de presentación Coordinación Aplicación Lógica del Negocio Lógica de Persistencia Clases Dominio Esquema Persistencia José Pérez: Cliente Materialización / Desmaterialización de objetos $$$ Patrón DAO? T-cliente

18

19 MVC Consulta de Estado Modelo Agrupa los estados de la aplicación Responde a los requerimientos Muestra la funcionalidad de la aplicación Notifica los cambios a la Vista Cambios de Estado Notificaciones de Cambios Vista Interpreta el modelo Solicita actualizaciones del modelo Envía las acciones del usuario al Controlador Permite al Controlador seleccionar las Vistas Invocación de Métodos Eventos Selección de Vista Acciones de Usuarios Controlador Define el comportamiento de la aplicación Mapea las acciones del Usuario a actualizaciones del Modelo Selecciona la Vista de respuesta Uno por cada funcionalidad

20 Funcionamiento Flujo de ver información: LADO DEL CLIENTE LADO DEL SERVIDOR Petición 1 Controlador Datos Persistentes Respuesta 8 7 Vista 3 6 Modelo

21 Funcionamiento Flujo de actualizar información: LADO DEL CLIENTE LADO DEL SERVIDOR Petición 1 Controlador Redirección 7 Modelo 3 4 Datos Persistentes Petición 8

22

23 Variantes arquitectónicas de MVC En el Controlador: - Use Case Controller - Front Controller - Page Controller En la Vista: - Enfoque Push - Enfoque Pull En el Modelo: - Modelo Activo - Modelo Pasivo

24 Use Case Controller El patrón Use Case Controller coordina e itera secuencias entre el sistema y sus usuarios con el fin de llevar a cabo un proceso específico. Un ejemplo es el estilo de interface Wizard, donde el usuario pasa a través de una secuencia de pantallas en un orden definido. Ellos pueden ser capaces de dar marcha atrás y hacia delante, o saltar a un paso específico, pero el enfoque general sugiere un definido "avance en el proceso

25 Use Case Controller

26 Page Controller Este patrón: - Intercepta la llamada a la página solicitada. - Interpreta la acción. - Ejecuta la acción. - Determina la vista correcta para mostrarle los resultados al usuario. - Separa la lógica de despacho de cualquiera de las vistas. Cuando se implementa de forma adecuada, crea una base común para todos los controladores para evitar la duplicación de código e incrementar la consistencia y facilidad de prueba.

27 Page Controller Estructura: Usando ControllerBase para eliminar duplicación de código:

28 Front Controller El patrón se relaciona con el diseño de aplicaciones web. Ofrece un punto de acceso centralizado para el tratamiento de todas las solicitudes. Este patrón: - Canaliza todas las peticiones en un único controller. - El controller se implementa en dos partes: un handler y una jerarquía de comandos.

29 Front Controller Estructura: Escenario típico:

30 Controlador Frontal View Controller Model Browers JSP / HTML Form 1 Struts ActionServlet Struts Action 3 2 struts-config.xml 6 Business Logic using Struts Custom Tags 4 5 Struts ActionForm Database 1. Todas las solicitudes del navegador son enviadas al Struts ActionServlet. 2. El Struts ActionServlet determina cual subclase Action enrutar usando el archivo de mapeo predeterminado struts-config.xml. 3. El ActionServlet pasa el control a la subclase Action. 4. Cuando el formulario HTML es enviado, la subclase ActionForm es automáticamente poblada con los datos del formulario. 5. La subclase Action puede acceder a los datos del formulario que están almacenados en la subclase ActionForm. Esta subclase es pasada al back-end del Business Logic para futuras acciones. 6. La subclase Action invoca el back-end del Business Logic.

31 Enfoques MVC Push/Pull Hace referencia a cómo son accesibles los objetos de la capa de negocio desde la capa de presentación. MVC Push es cuando los datos son seteados en la vista. En este escenario, generalmente un objeto de la capa de negocio está asociado a una página. MVC Pull es cuando la vista pide los datos (por ejemplo, mediante métodos accesores). En este escenario, generalmente uno o varios objetos están disponibles para todas las páginas. La mayoría de frameworks sigue un enfoque MVC Push.

32 Enfoques MVC Push/Pull ENFOQUE PUSH CLASE DE NEGOCIO public class{ varvista = 5; } PLANTILLA DE LA VISTA <div class="grid"> <com:tliteral ID= varvista" /> </div> ENFOQUE PULL OBJETO DE NEGOCIO n:negocio atributo1 = 3 atributo2 = Dato atributo3 = 50 CLASE DE LA VISTA public class{ varvista = getatributo3(); }

33 Enfoque MVC Push ENFOQUE PUSH CLASE DE NEGOCIO class { this.totaldatos= ; } PLANTILLA DE LA VISTA <div class="grid"> <com:tliteral ID= totaldatos" /> </div>

34 Enfoques MVC Push/Pull ENFOQUE PULL OBJETO DE NEGOCIO GestionarPersonasController cedula = nombre = Luis Carlos Velez Blanco = lcvb@hotmail.com CLASE DE LA VISTA class extends View{ varvista = getcedula() ; }

35 Modelo Pasivo El model no reporta cambios de estado El controller es el único que manipula el modelo. Cuando el controller modifica el modelo, le informa a la vista que este ha cambiado y que ya se puede refrescar. En este escenario el modelo es completamente independiente.

36 Modelo Pasivo Modelo update Vista Eventos Totalmente desacoplado Vistas escuchan y responden a los eventos de notificación de sus respectivos modelos (si les interesa) Modelo desconoce qué pasa, sólo responde a los mensajes recibidos (comandos y consultas)

37 Modelo Activo El Modelo reporta cambios de estado a vistas Este es usado cuando el modelo cambia su estado sin intervención del controller. Esto ocurre cuando otras fuentes cambian los datos y estos cambios debes ser reflejados en las vistas. Patrón Observer (Publish/Subscribe)

38 Modelo Activo Modelo update Observador Vista 4 Vista 3 Vista 2 Vista 1 Observadores / Vistas Asociadas - Modelo conoce la existencia de observadores o vistas asociadas - Les envía activamente un mensaje de notificación (sin información) - Fácil de implementar, pero limitado en flexibilidad - El controlador también puede observar al modelo

39 Modelo Activo CONTROLADOR MODELO <<interface>> Observer VISTA

40 Funcionamiento input Controlador register Vista Vista Vista update Modelo update

41

42 Clases participantes del patrón DAO

43 Responsabilidades de las clases Client: Cualquier objeto que requiera acceder a la fuente de datos para obtener algún dato. DataAccessObject: Implementación de la las operaciones de acceso a datos (CRUD o CRUDEL) DataSource: Implementación de la fuente de datos ResultSet: Interfaz ResultSet que proporciona acceso a una tabla de datos. Data Transfer Object: Almacena los datos que deseemos insertar a una tabla y almacena los datos que saquemos de una tabla.

44 Interacción entre las clases

45

46 Uso de una capa lógica transversal Tabla (HTML) C O L E C C I O N D E DataGrid Array Capa de presentación Capa de lógica de negocios DTO s (Value Objects) D A T O S RecordSet Cursor Capa de acceso a datos Tabla (SQL) Bases de datos

47 Flujos en el patrón DAO Flujos de un registro: manipulan un solo registro de la fuente de datos y no necesitan ResultSet. Flujos de múltiples registros: manipulan mas de un registro de la fuente de datos usando para ello un ResultSet. ** En el patrón MVC los flujos se separan en: - Flujos para actualizar información - Flujos para mostrar información

48 Flujo de un registro

49 Flujo de múltiples registros

50 Evaluar uso del Active Record Un objeto que contiene una fila en una tabla de base de datos o vista, encapsula el acceso a bases de datos, y agrega la lógica de dominio en esos datos. Person lastname firstname numberofdependents insert update getexemption isflaggedforaudit gettaxableearnings Un objeto que lleva los datos y el comportamiento. Gran parte de estos datos es persistente y tiene que ser almacenado en una base de datos. Active Record utiliza el enfoque más obvio, poner la lógica de acceso a datos en el objeto de dominio. De esta manera todas las personas saben cómo leer y escribir sus datos hacia y desde la base de datos.

51 Evaluar uso de un Framework ORM El Mapeo Objeto-Relacional (Object-Relational Mapping o ORM) es una técnica de programación para convertir datos entre una base de datos relacional y el sistema de tipos utilizado en un lenguaje de programación orientado a objetos.

52

53 Referencias Gamma, Eric; Helm, Richard; Johnson, Ralph; and Vlissides, John. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerland, Peter; and Stal, Michael. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Wiley & Sons, Alur, Deepak; Crupi, John and Malks, Dan. Core J2EE Patterns: Best Practices and Design Strategies. 2.ed. Prentice Hall / Sun Microsystems Press, Fowler, Martin. Patterns of Application Architecture. Addison- Wesley, Larman, Craig. Uml y Patrones: Introducción al análisis y diseño orientado a objetos. 2 ed. Prentice Hall, 2005.