Categorías de Patrones

Si hacemos una revisión cercana a patrones existentes podemos revelar que estos cubren diferentes rangos de escalas y niveles de abstracción. Algunos patrones ayudan a estructurar un sistema en subsistemas base. Mientras otros ayudan al afinamiento de subsistemas y componentes, o las relaciones entre estos. Mientras que otros ayudan en la implementación en aspectos de diseño particulares en un lenguaje de programación especifico. Los patrones también van desde aquellos independientes del dominio, como aquellos que desacoplan componentes que interactúan, hasta el manejo de aspectos específicos al dominio, como políticas de transacciones en aplicaciones de negocio, o el enrutamiento de llamadas en telecomunicaciones. Según lo anterior, se definen las siguientes tres categorías de patrones:

–          Patrones de Arquitectura

–          Patrones de Diseño

–          Patrones de Implementación (Idiomas)

Los Patrones de Arquitectura

Expresa un esquema fundamental de organización estructural para sistema de software. Donde provee una serie de subsistemas predefinidos, especificando sus responsabilidades, e incluye reglas y guías para organizar las relaciones entre ellos. Básicamente, un patrón de arquitectura es una plantilla para una arquitectura de aplicaciones. Estos especifican las propiedades generales a la estructura del sistema, y repercuten la arquitectura de sus subsistemas. La selección de un patrón de arquitectura es por lo tanto una decisión fundamental al desarrollar un sistema de software. El patrón Modelo-Vista-Controlador  (MVC) es uno de los ejemplos más conocidos de un patrón de arquitectura, y provee la infraestructura para sistemas interactivos. Por estas características, los patrones de arquitectura son utilizados durante la etapa de definición de arquitectura de un sistema.

Los Patrones de Diseño

Los subsistemas dentro de una arquitectura de software, al igual que sus interrelaciones, consisten normalmente de unidades arquitectónicas más pequeñas. Describimos estas unidades a través de Patrones de Diseño. Un Patrón de Diseño define un esquema de refinamiento de los subsistemas o componentes dentro de un sistema, o las relaciones entre estos. Este describe una estructura común y recurrente de componentes interrelacionados, que resuelve un problema general de diseño dentro de un contexto particular.

Los patrones de diseño trabajan a una escala intermedia. Son menores en escala que un patrón de arquitectura, pero logran ser independientes del lenguaje de programación. La aplicación de un patrón de diseño no tiene efectos sobre la estructura fundamental del sistema (arquitectura), pero puede tener una fuerte influencia sobre la arquitectura de un subsistema. Un ejemplo concreto de patrones de diseño es el de Singleton o Facade. Por lo anterior, los patrones de diseño son utilizados durante la fase de diseño de un sistema.

 Patrones de Implementación

Un patrón de implementación (también llamado Idioma ) es un patrón de bajo nivel específico a un lenguaje de programación. Este describe como implementar aspectos particulares de componentes o sus relaciones utilizando las características de un lenguaje dado. Los patrones de implementación representan el nivel más bajo de patrones, y manejan aspectos tanto de diseño como implementación, y son mayormente utilizados durante la fase de desarrollo de un sistema. Frecuentemente, el mismo patrón de implementación se ve diferente al ser implementado sobre lenguajes distintos, y algunas veces un patrón de implementación muy útil en un lenguaje no tiene sentido sobre otro. Por estas características, los patrones de arquitectura son utilizados durante la etapa de definición de arquitectura de un sistema.

 Patrón de Arquitectura por Capas

El patrón de arquitectura por capas es una de las técnicas más comunes que los arquitectos de software utilizan para dividir sistemas de software complicados. Esto se ve en arquitectura de hardware, redes (por ejemplo, FTP funciona encima de TCP, la cual a su vez funciona encima de IP, y esta sobre Ethernet). Al pensar un sistema en términos de capas, se imaginan los principales subsistemas de software ubicados de la misma forma que las capas de un pastel, donde cada capa descansa sobre la inferior. En este esquema la capa más alta utiliza varios servicios definidos por la inferior, pero esta última es inconsciente de la superior. Además, normalmente cada capa oculta las capas inferiores de las superiores a ésta. Aunque este último comportamiento algunas veces es válido obviar. La siguiente figura muestra un esquema básico de una arquitectura siguiendo este patrón.

 

Partir un sistema en capas tiene una cantidad importante de beneficios:

–          Se puede entender una capa como un todo sin considerar las otras.

–          Las capas se pueden sustituir con implementaciones alternativas de los mismos servicios básicos.

–          Se minimizan dependencias entre capas.

–          Las capas posibilitan la estandarización de servicios.

–          Luego de tener una capa construida, puede ser utilizada por muchos servicios de mayor nivel.

Sin embargo, un modelo de capas también trae consigo algunos inconvenientes que deben ser tenidos en cuenta en el diseño:

 –            No todo es encapsulado de la mejor manera en un modelo de capas. Como resultado se pueden generar algunas veces cambios en cascada.

–            Demasiadas capas pueden generar problemas de rendimiento.

Pero la parte más difícil de una arquitectura basada en este modelo es decidir que capas implementar y que responsabilidad debe tener cada una. A continuación la discusión se centra en describir las tres capas principales de un patrón de arquitectura por capas.

Capa de Presentación

Referente a la interacción entre el usuario y el software. Puede ser tan simple como un menú basado en líneas de comando o tan complejo como una aplicación basada en formas. Su principal responsabilidad es mostrar información al usuario, interpretar los comandos de este y realizar algunas validaciones simples de los datos ingresados.

Lógica de Negocios

También denominada Lógica de Dominio [FOWLER], esta capa contiene la funcionalidad que implementa la aplicación. Involucra cálculos basados en la información dada por el usuario y datos almacenados y validaciones. Controla la ejecución de la capa de acceso a datos y servicios externos. Se puede diseñar la lógica en la capa de negocios para su uso directo por parte de componentes de presentación o su encapsulamiento como servicio y llamada a través de una interfaz de servicios, que coordina la conversación con los clientes del servicio e invoca cualquier flujo o componente de negocio.

Lógica de Acceso a Datos

Esta capa contiene la lógica de comunicación con otros sistemas que llevan a cabo tareas por la aplicación. Estos pueden ser Monitores Transaccionales, otras aplicaciones, sistemas de mensajería, etc. Para el caso de aplicaciones empresariales, generalmente está representado por una base de datos, que es responsable por el almacenamiento persistente de información. Esta capa debe abstraer completamente a las capas superiores (negocio) del dialecto utilizado para comunicarse con los repositorios de datos (PL/SQL, Transact-SQL, etc.).

Tomado con fines Educativos de la Guia de Patrones, Practicas y Arquitectura .NET, Autores:  Ernesto Marquina, Jose David Parra.  Microsoft Services.

Autor: arevalomaria

Ingeniero de Sistemas, Magister en Gerencia y Tecnologia de la Informacion, Certificaciones: ITIL V3, CCNA, Microsoft Certified Professional.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s