Arquitectura de Software

Juan Bernardo Quintero

Catálogo de Patrones

Nombre

CortoNombre Completo Propósito Básico Autor Año

GoF Gang of Four Solución de

problemas del

diseño

Gamma,

et al.

1995

POSA Pattern-Oriented

Software Architecture

Definición de

estrategias

arquitectónicas

Buschmann,

et al.

1996

J2EE Java 2 Enterprise

Edition

Diseño de

aplicaciones para

esta plataforma

Alur, et al.

(Sun)

2003

PoEAA Patterns of Enterprise

Application Architecture

Definición de los

contenidos de las

capas

Fowler 2003

GRASP General Responsibility

Assignment Software

Patterns

Tránsito entre el

análisis y el diseño

Larman 2005

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

Estrategia Nombre del Patrón

Del fango a la estructura • Capas

• Tubería-filtros

• Pizarra

Sistemas distribuidos • Broker (Por ejemplo CORBA, DCOM, Web

Services, WWW)

Sistemas interactivos • Model-View-Controller

• Presentation-Abstraction-Control

Sistemas adaptables • Reflection: metanivel que hace al software

consciente de sí mismo.

• Microkernel: núcleo de funcionalidad mínima.

Catálogo POSA

Catálogo J2EE (1° Edición)

Catálogo J2EE (2° Edición)

Catálogo PoEAA (1)

Pattern Type Pattern Name

Domain Logic • Transaction Script

• Domain Model

• Table Module

• Service Layer

Data Source Architectural • Table Data Gateway

• Row Data Gateway

• Active Record

• Data Mapper

Object-Relational Structural • 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

Catálogo PoEAA (2)

Pattern Type Pattern Name

Object-Relational Behavioral • Unit of Work

• Identity Map

• Lazy Load

Object-Relational Metadata Mapping • Metadata Mapping

• Query Object

• Repository

Web Presentation • Model View Controller

• Page Controller

• Front Controller

• Template View

• Transform View

• Two-Step View

• Application Controller

Distribution • Remote Façade

• Data Transfer Object

Catálogo PoEAA (3)

Pattern Type Pattern Name

Offline Concurrency • Optimistic Offline Lock

• Pessimistic Offline Lock

• Coarse Grained Lock

• Implicit Lock

Session State • Client Session State

• Server Session State

• Database Session State

Base • Gateway

• Mapper

• Layer Supertype

• Separated Interface

• Registry

• Value Object

• Money

• Special Case

• Plugin

• Service Stub

• Record Set

Catálogo GRASP

Pattern Name Related Topic

• Creator • Factory pattern

• Information Expert • Information hiding

• Controller • Model–view–controller

• Low Coupling • Loose coupling

• High Cohesion • Cohesion (computer science)

• Polymorphism • Polymorphism in object-oriented programming

• Pure Fabrication • Service (systems architecture)

• Indirection • Delegation pattern

• Protected Variations • Delegation pattern

FRENTE FÍSICO FRENTE LÓGICO

Especificación Arquitectónica PatrónUsuario

Cliente/Servidor M-V-C

Front-End

Middleware

Back-End

Vista

Controlador

Modelo

L

A

Y

E

R

S

T

I

E

R

S

RIA

Arquitectura de Aplicaciones Web

Las Layers de cada Tier

Frameworks en las Tiers

José Pérez: Cliente

Materialización /

Desmaterialización

de objetos

T-cliente

Interfaces

Lógica de

presentación

Lógica del

Negocio

Lógica de

Persistencia

$$$ ...

¿Patrón

MVC?

Costos de la invocación entre Tiers

$$$ …

¿Patrón

DAO?

Coordinación Aplicación

Clases Dominio

Esquema Persistencia

MVC

ControladorDefine el comportamiento de la

aplicación

Mapea las acciones del Usuario

a actualizaciones del Modelo

Selecciona la Vista de

respuesta

Uno por cada funcionalidad

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

Vista• Interpreta el modelo

• Solicita actualizaciones del modelo

• Envía las acciones del usuario al Controlador

• Permite al Controlador seleccionar las Vistas

Consulta de

Estado

Cambios de

Estado

Notificaciones

de Cambios

Acciones de Usuarios

Selección de Vista

Eventos

Invocación de Métodos

Funcionamiento

Flujo de ver información:

Vista Modelo

Datos

Persistentes

Petición

Respuesta

1

2

3

4 5

6

7

8

67

LADO DEL CLIENTE LADO DEL SERVIDOR

Controlador

Funcionamiento

Flujo de actualizar información:

Controlador

ModeloDatos

Persistentes

Petición

Petición

LADO DEL CLIENTE LADO DEL SERVIDOR

Redirección

1

2

3

4

56

7

8

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

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

Use Case Controller

http://www.developerfusion.com/article/9450/controller-patterns-for-aspnet/

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.

Page Controller

Estructura:

Page Controller

Usando ControllerBase para eliminar duplicación de código:

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.

Front Controller

Front Controller

Estructura:

Escenario típico:

Controlador Frontal

Browers

JSP / HTML

Form

using

Struts

Custom Tags

View Controller Model

Struts

ActionServlet struts-config.xml

Struts

Action

Struts

ActionForm

Business

Logic

Database

1

2

3

45

6

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.

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.

Enfoques MVC Push/Pull

Enfoques MVC Push/Pull

<div class="grid">

<com:TLiteral ID=“varVista" />

</div>

public class{…varVista = 5;…}

CLASE DE NEGOCIO PLANTILLA DE LA VISTA

public class{…varVista = getAtributo3();…}

OBJETO DE NEGOCIO

CLASE DE LA VISTA

ENFOQUE

PUSH

ENFOQUE

PULL

atributo1 = 3

atributo2 = ‘Dato’

atributo3 = 50

n:Negocio

Enfoque MVC Push

<div class="grid">

<com:TLiteral ID=“totalDatos" />

</div>

class … {…this.totalDatos= … ;…}

CLASE DE NEGOCIO PLANTILLA DE LA VISTA

ENFOQUE

PUSH

Enfoques MVC Push/Pull

class … extends View{…varVista = … getCedula() …;…}

OBJETO DE NEGOCIO

CLASE DE LA VISTA

ENFOQUE

PULL

cedula = 710982345

nombre = ‘Luis Carlos Velez Blanco’

email = ‘lcvb@hotmail.com’

GestionarPersonasController

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.

Modelo Pasivo

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)

Modelo Pasivo

updateVistaModelo

El Modelo reporta cambios de estado a vistas

Este es usado cuando el modelo cambia su estado sinintervención del controller.

Esto ocurre cuando otras fuentes cambian los datos y estoscambios debes ser reflejados en las vistas.

Patrón Observer (Publish/Subscribe)

Modelo Activo

Modelo Activo

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

Modelo Observadorupdate

Vista 4

Vista 3

Vista 2

Vista 1

MODELO<<interface>>

Observer

CONTROLADOR

VISTA

Modelo Activo

Controlador

Modelo

VistaVistaVista

input

update

register

update

Funcionamiento

Clases participantes del patrón DAO

http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm

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.

Responsabilidades de las clases

Interacción entre las clases

http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm

Capa de presentación

Capa de lógica de negocios

Capa de acceso a datos

DTO’s

(Value

Objects)

Uso de una capa lógica transversal

Tabla (HTML)

DataGrid

Array

RecordSet

Cursor

Tabla (SQL) Bases de datos

C

O

L

E

C

C

I

O

N

D

E

D

A

T

O

S

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

Flujo de un registro

Flujo de múltiples registros

http://martinfowler.com/eaaCatalog/activeRecord.html

Evaluar uso del Active Record

lastName

firstName

numberOfDependents

Person

insert

update

…

getExemption

isFlaggedForAudit

getTaxableEarnings

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.

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.

http://www.visual-paradigm.com/product/sde/ec/provides/codedbeng.jsp

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.

Gamma, Eric; Helm, Richard; Johnson, Ralph; and Vlissides,

John. Design Patterns: Elements of Reusable Object-Oriented

Software. Addison-Wesley, 1995.

Buschmann, Frank; Meunier, Regine; Rohnert, Hans;

Sommerland, Peter; and Stal, Michael. Pattern-Oriented Software

Architecture, Volume 1: A System of Patterns. Wiley & Sons,

1996.

Alur, Deepak; Crupi, John and Malks, Dan. Core J2EE Patterns:

Best Practices and Design Strategies. 2.ed. Prentice Hall / Sun

Microsystems Press, 2003.

Fowler, Martin. Patterns of Application Architecture. Addison-

Wesley, 2003.

Larman, Craig. Uml y Patrones: Introducción al análisis y diseño

orientado a objetos. 2 ed. Prentice Hall, 2005.

Referencias