Límite de control de entidad

El patrón entidad-control-límite ( ECB ), o entidad-límite-control ( EBC ), o límite-control-entidad ( BCE ) es un patrón arquitectónico utilizado en la programación orientada a objetos basada en casos de uso que estructura las clases que componen el código fuente orientado a objetos de alto nivel de acuerdo con sus responsabilidades en la realización del caso de uso.

El enfoque entidad-control-límite tiene su origen en  el método de ingeniería de software orientada a objetos (OOSE) impulsado por casos de uso de Ivar Jacobson , publicado en 1992. ^{[ 1 ] [ 2 ]}  Originalmente se llamaba entidad-interfaz-control ( EIC ), pero muy pronto el término " límite " reemplazó a " interfaz " para evitar la posible confusión con la terminología de los lenguajes de programación orientados a objetos .

Se desarrolla aún más en el Proceso Unificado , que promueve el uso de ECB en las actividades de análisis y diseño con el apoyo de estereotipos UML . ^{[ 3 ]} El modelado ágil ^{[ 4 ] [ 5 ]} y el proceso ICONIX ^{[ 6 ]} se elaboraron sobre el patrón de arquitectura ECB con diagramas de robustez. ^{[ 7 ]}      

El patrón BCE organiza las responsabilidades de las clases según su función en la realización del caso de uso:

• una entidad representa información de larga duración relevante para las partes interesadas (es decir, derivada principalmente de objetos de dominio, generalmente persistente);   
• Un límite engloba la interacción con actores externos (usuarios o sistemas externos);
• Un control garantiza el procesamiento necesario para la ejecución de un caso de uso y su lógica de negocio, y coordina, secuencia y controla otros objetos involucrados en el caso de uso.

Las clases correspondientes se agrupan posteriormente en paquetes de servicios, que son un conjunto indivisible de clases relacionadas que pueden utilizarse como unidades de entrega de software.

Las clases de BCE se identifican por primera vez cuando se analizan   los casos de uso :

• Cada caso de uso está representado como una clase de control;
• Cada relación diferente entre un caso de uso y un actor se representa como una clase límite;
• Las entidades se derivan de la descripción del caso de uso.

Luego, las clases se refinan y reestructuran o reorganizan según sea necesario para el diseño, por ejemplo:  

• Excluyendo comportamientos comunes en diferentes controles de casos de uso
• Identificar una clase límite central para cada tipo de actor humano y para cada sistema externo que proporcione una interfaz coherente con el mundo exterior.   

El patrón BCE asume que las responsabilidades de las clases también se reflejan en las relaciones e interacciones entre las diferentes categorías de clases para garantizar la robustez del diseño. ^{[ 8 ] [ 9 ]}

Los diagramas de robustez permiten representar visualmente la relación entre entidades, controles, límites y actores. ^{[ 4 ]} Utiliza estereotipos gráficos introducidos en los primeros trabajos de Jacobson:  

Se aplican las siguientes restricciones de robustez: 

• Los actores solo pueden conocer y comunicarse dentro de los límites.
• Los límites solo pueden comunicarse con los actores y los controles.
• Los controles pueden conocer y comunicarse con límites y entidades, y si es necesario, con otros controles.
• Las entidades pueden tener conocimiento únicamente de otras entidades, pero también podrían comunicarse con los controles;

En teoría, las entidades no deberían tener conocimiento de los límites y controles. Sin embargo, en la práctica, las entidades pueden publicar eventos que los límites y controles pueden observar sin que la entidad lo sepa. Esto posibilita la comunicación entre las entidades, los límites y los controles.

De manera similar, la restricción de que una clase límite no conozca a otras clases límite solo se aplica en el nivel más alto, y no entre clases que cooperan para implementar el mismo límite.

Existe cierta similitud entre ECB y el modelo-vista-controlador (MVC): las entidades pertenecen al modelo y las vistas a los límites. Sin embargo, el rol del control ECB es muy diferente al del controlador MVC, ya que también encapsula la lógica de negocio del caso de uso, mientras que el controlador MVC procesa la entrada del usuario, que en ECB sería responsabilidad del límite. El control ECB aumenta la separación de responsabilidades en la arquitectura al encapsular la lógica de negocio que no está directamente relacionada con una entidad. ^{[ 2 ]}

El BCE se puede utilizar junto con la arquitectura hexagonal , siempre que los límites formen la capa adaptadora exterior. ^{[ 10 ]}  

ECB es compatible con la arquitectura limpia, que fusiona los principios de ECB con otros paradigmas de diseño arquitectónico. ^{[ 11 ] [ 12 ]}  La arquitectura limpia sitúa las entidades en el núcleo y las rodea con un anillo de casos de uso (es decir, el control ECB) y un anillo con pasarelas y presentadores (es decir, los límites ECB). Sin embargo, la arquitectura limpia requiere una dependencia unidireccional de afuera hacia adentro, lo que exige dividir los controles ECB en lógica de casos de uso y coordinación de objetos.

• Patrones arquitectónicos
• Caso de uso
• Proceso unificado
• Análisis y diseño orientado a objetos