El patrón Entity Control Boundary

El patrón Entity Control Boundary.

Para comenzar, el patrón Entity Control Boundary, es una variación del patrón de arquitectura de Software Modelo Vista Controlador (Siendo esté un estilo que separa los datos de una aplicación “Modelo”, la interfaz de usuario “Vista”, y la lógica de control en “Controlador”). Al igual que otras arquitecturas de software, estás son útiles para poder tener una guía concisa para estructurar las docenas de tecnologías, siendo así el patrón de diseño más ampliamente utilizado, debido a que permite modelar una aplicación muy grande o muy pequeña.

De igual manera, el patrón Entity Control Boundary fue fundado en los años 80’s por Ivar Jacobson, lo cual lo hace un patrón viejo que está basado en Diagramas de Robustez, en donde la idea básica es analizar los pasos de un caso de uso para validar la lógica de estos y asegurar que dicha lógica sea consistente con otros casos de uso.

Así mismo este patrón es comúnmente implementado en el lenguaje orientado a objetos Java, en donde se pueden implementar la cantidad de Entidades, Controles y Límites que sean necesarios, al igual que se pueden exportar y re implementar.

El patrón Entity Control Boundary, aunque es similar al Modelo Vista Controlador, este es apropiado no solamente para el manejo de interfaces de usuario, sino que le da al controlador un rol diferente, así como es más apropiado para usar estructurar toda la parte funcional de los sistemas. Para ver mejor las diferencias entre estos dos modelos podemos tener en cuenta lo siguiente:

• El patrón Entity Control Boundary tiene una relación lineal entre cada uno de sus elementos, mientras el patrón Modelo Vista Controlador tiene una relación triangular entre estos.
• La meta del patrón Entity Control Boundary es la distribución de responsabilidades a un grupo de elementos de diseño que interactúan, mientras que el patrón Modelo Vista Controlador tiene como meta implementar la interfaz de usuario con vistas selectivas, separadas del modelo y del controlador.

 A continuación, se puede encontrar la definición de cada elemento del patrón Entity Control Boundary:

• Elementos de Entidad (Entity):

Una entidad es un elemento que representa datos del sistema, y es responsable de una gran parte de la información, siendo considerado el modelo del componente, siendo representaciones de datos de la vida real. Lo anterior no quiere decir que estas sean datos, sino que realizan comportamientos organizados en torno a cierta cantidad de datos. Lo anterior significa que son orientados a los objetos o al procedimiento del dominio de dichos objetos.

De esta forma, como parte de este patrón, la identificación y diseño de las distintas entidades se puede realizar muchas veces en diferentes niveles de abstracción del código (descripción y/o especificación de que realiza el código, haciendo dicha descripción en relación con los distintos niveles que se posean), en diferentes niveles de granularidad de tamaño (reutilización, nivel de detalle de la base de datos, determinando su tamaño, jerarquía) y desde las perspectivas de diferentes contextos.

Se pueden usar los siguientes dos ejemplos:

1. Una entidad para una aplicación de servicio al cliente sería una entidad de Cliente que administra toda la información sobre un cliente. Un elemento de diseño para esta entidad incluiría datos sobre el cliente, el comportamiento para administrar los datos, el comportamiento para validar la información del cliente y realizar otros cálculos comerciales como "¿este cliente puede comprar el producto X?", "¿este cliente puede realizar el proceso Y?", etc.

1. Se podría hacer un análisis de un escenario de creación de una campaña de marketing e identificar el elemento del cliente con varios elementos de datos del cliente para mostrar los diferentes niveles de abstracción, la granularidad y las perspectivas. Los elementos de datos del cliente pueden ser el nombre y la dirección, además de diversos comportamientos necesarios, como la gestión del nombre y de los datos de la dirección y la capacidad de calificar el cliente que se basa en algún algoritmo (tal aplicación de este patrón sería abstracta del código, de grano grueso y no tendría un contexto específico). Más adelante, se podría realizar una aprobación en el mismo escenario aplicando un mecanismo de arquitectura para el acceso a la base de datos que rompe la dirección en su propio elemento, transfiere la responsabilidad de almacenar y recuperar clientes a un nuevo elemento de control e identifica algunas decisiones de base de datos específicas, como el uso de claves primarias en las entidades (tal aplicación de este patrón sería más cercana al código, más detallada y alineada con un contexto de base de datos).

Así mismo, se puede mostrar la forma en la cual se gráfica una entidad en este patrón:

[pic 1]

[pic 2]

Dicha entidad, también se puede graficar de una manera más sencilla y es la siguiente:

[pic 3]

Como podemos observar en lo anterior, podemos notar que el presente modelo va más allá que el patrón Modelo, Vista y Controlador, debido a que no sólo se enfoca en modelar los datos, y los diferentes procedimientos que hay, sino que permite un nivel más profundo de detalle y de entendimiento en relación con la aplicación o sistema que se está desarrollando, haciendo que de está manera, exista una mayor especificación en cada proceso o caso de uso realizado.

• Elementos de Control:

Un elemento de control gestiona el flujo de interacción del escenario, es decir, actúa como un intermediario entre los límites y las entidades, es decir, encapsula la lógica del componente. Un elemento de control podría gestionar el comportamiento de extremo a extremo de un escenario o podría gestionar las interacciones entre un subconjunto de los elementos, realizando la ejecución de comandos que provienen de los límites. El comportamiento y las reglas comerciales relacionadas con la información relevante para el escenario deben asignarse a las entidades; Los elementos de control son responsables solo por el flujo del escenario.

Así mismo, el controlador aporta diferentes funciones para manejar las entidades. Aportando de dicha manera, operaciones CRUD ( Crear, Leer, Actualizar y Borrar ) para dichas entidades.

Puede haber muchos pasos para la identificación de los elementos de control de un componente, pero la siguiente es una idea general de lo que estos pasos podrían ser:

Un primer paso podría ser un análisis en el cual se identifique un elemento de control para un escenario, con un comportamiento específico para asegurar de que el diseño pueda soportar el flujo de eventos. Un paso posterior al anterior podría ser el de encontrar controladores para administrar colaboraciones reutilizables de elementos de bajo nivel que se asignarán a una unidad de código específica que será escrita.

...