El límite de control de entidad ( ECB ), o control de límite de entidad ( EBC ), o entidad de control de límite ( 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 según 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 rápidamente el término " límite " reemplazó a " interfaz " para evitar la posible confusión con la terminología del lenguaje de programación orientado a objetos .
Se desarrolla 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 los estereotipos UML . [3] Modelado ágil , [4] [5] y el proceso ICONIX [6] elaborado sobre el patrón de arquitectura ECB con diagramas de robustez. [7]
El patrón ECB organiza las responsabilidades de las clases según su rol en la realización del caso de uso:
Las clases correspondientes se agrupan luego en paquetes de servicios, que son un conjunto indivisible de clases relacionadas que pueden utilizarse como unidades de entrega de software.
Las clases de ECB se identifican por primera vez cuando se analizan los casos de uso :
Luego, las clases se refinan y reestructuran o reorganizan según sea necesario para el diseño, por ejemplo:
El patrón ECB asume que las responsabilidades de las clases también se reflejan en las relaciones e interacciones entre las diferentes categorías de clases con el fin de 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:
En principio, las entidades no deberían conocer los límites y controles. Sin embargo, en la práctica, algunas variantes permiten que las entidades, los límites y los controles se suscriban como observadores de una entidad.
De manera similar, la restricción de que una clase límite no conoce 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 pertenecen a los límites. Sin embargo, el papel del control ECB es muy diferente del del controlador MVC, ya que encapsula también la lógica empresarial de los casos de uso, mientras que el controlador MVC procesa la entrada del usuario que sería responsabilidad del límite en ECB. El control ECB aumenta la separación de preocupaciones en la arquitectura al encapsular la lógica empresarial que no está directamente relacionada con una entidad. [2]
El ECB se puede utilizar junto con la arquitectura hexagonal , siempre que los límites formen la capa adaptadora externa. [10]
El ECB es compatible con la arquitectura limpia, que fusiona los principios del ECB con otros paradigmas de diseño arquitectónico. [11] [12] La arquitectura limpia coloca las entidades en el núcleo y las rodea con un anillo de casos de uso (es decir, control del ECB) y un anillo con puertas de enlace y presentadores (es decir, límites del ECB). Sin embargo, la arquitectura limpia requiere una dependencia unidireccional de afuera hacia adentro, lo que requiere dividir los controles del ECB en lógica de casos de uso y coordinación de objetos.
{{cite book}}: CS1 maint: others (link){{cite book}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link){{cite web}}: CS1 maint: multiple names: authors list (link)