La entidad-control-límite ( BCE ), o -límite de control de entidad ( EBC ), o de control de límite-entidad ( BCE ) es un patrón de arquitectura utilizan en caso de uso impulsado diseño de software orientado a objetos que estructura las clases componer una software de acuerdo con sus responsabilidades en la realización del caso de uso.
Origen y evolución
El enfoque de Entidad-Control-Límite encuentra su origen en Ivar Jacobson impulsado caso de uso 's OOSE método publicado en 1992 [1] , . [2] Originalmente se llamaba Entity-Interface-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 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] Modelado ágil , [4] [5] y el proceso ICONIX [6] elaborado en la parte superior del patrón de arquitectura ECB con diagramas de robustez. [7]
Principio
El patrón ECB organiza las responsabilidades de las clases de acuerdo con su papel en la realización del caso de uso:
- una entidad representa información de larga duración relevante para las partes interesadas (es decir, deriva principalmente de objetos de dominio, generalmente persistente);
- un límite encapsula la interacción con actores externos (usuarios o sistemas externos);
- un control asegura el procesamiento requerido para la ejecución de un caso de uso y su lógica de negocios, y coordina, controla las secuencias de otros objetos involucrados en el caso de uso.
Las clases correspondientes se agrupan luego en paquetes de servicios, que son un conjunto indivisible de clases relacionadas que se pueden utilizar como unidades de entrega de software.
Las clases de ECB se identifican por primera vez cuando se analizan los casos de uso :
- cada caso de uso se representa 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 narrativa del caso de uso.
Luego, las clases se refinan y reestructuran o reorganizan según sea necesario para el diseño, por ejemplo:
- Factorizar comportamientos comunes en diferentes controles de casos de uso
- Identificar una clase de límite central para cada tipo de actor humano y para cada sistema externo que proporcionaría una interfaz coherente con el mundo exterior.
El patrón del BCE 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 solidez del diseño. [8] [9]
Diagrama de robustez
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:
Representación | Relación con | ||||
---|---|---|---|---|---|
Papel | Símbolo | Actor | Perímetro | Control | Entidad |
Actor | sí | sí | No | No | |
Perímetro | sí | Parte / todo | sí | No | |
Control | No | sí | sí | sí | |
Entidad | No | No | sí | sí |
Se aplican las siguientes restricciones de robustez:
- Los actores solo pueden conocer y comunicarse con límites
- Los límites solo pueden comunicarse con los actores y los controles.
- Los controles pueden conocer y comunicarse con los límites y las entidades y, si es necesario, con otros controles.
- Es posible que las entidades solo conozcan otras entidades, pero también podrían comunicarse con los controles;
En principio, las entidades no deberían conocer los límites y los controles. En la práctica, sin embargo, algunas variantes permiten que las entidades, los límites y los controles se suscriban como observadores a una entidad.
De manera similar, la restricción de una clase de límite que no conoce otras clases de límite solo se aplica al nivel más alto, y no entre clases que cooperan para implementar el mismo límite.
Relación con otros patrones arquitectónicos
Existe cierta similitud entre ECB y 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 controlador MVC, ya que encapsula también la lógica empresarial del caso de uso, mientras que el controlador MVC procesa la entrada del usuario que sería responsabilidad del límite en ECB. El control del BCE 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 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 coloca a las entidades en el núcleo y las rodea con un anillo de casos de uso (es decir, control del BCE) y un anillo con pasarelas y presentadores (es decir, límites del BCE). Sin embargo, una arquitectura limpia requiere una dependencia unidireccional desde el exterior hacia el interior, lo que requiere dividir los controles ECB en lógica de casos de uso y coordinación de objetos.
Ver también
notas y referencias
- ^ Jacobson, Ivar. (1992). Ingeniería de software orientada a objetos: un enfoque basado en casos de uso . [Nueva York]: ACM Press. págs. 130-133 . ISBN 0201544350. OCLC 26132801 .
- ^ a b "Aviso de lectura sobre ingeniería de software orientada a objetos, Ivar Jacobson, et al. (1992)" . tedfelix.com . Consultado el 14 de agosto de 2019 .
- ^ El proceso de desarrollo de software unificado . Jacobson, Ivar., Booch, Grady., Rumbaugh, Jim. Reading, Massachusetts: Addison-Wesley. 1999. págs. 44, 183–188, 202–205, 256–257, 439. ISBN 0201571692. OCLC 636807532 .CS1 maint: otros ( enlace )
- ^ a b Scott Ambler . "Diagramas de robustez: una introducción ágil" . agilemodeling.com . Consultado el 14 de agosto de 2019 .
- ^ Ambler, Scott W., 1966- (2004). La cartilla del objeto: desarrollo basado en modelado ágil con UML 2.0 (3ª ed.). Cambridge, Reino Unido: Cambridge University Press. ISBN 0521540186. OCLC 54081540 .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ "Cerrar la brecha entre análisis y diseño • El Registro" . www.theregister.co.uk . Consultado el 14 de agosto de 2019 .
- ^ Dugerdil, Philippe (2013). "Arquitectura de aplicaciones empresariales móviles: un enfoque de modelado para adaptar las aplicaciones empresariales al móvil" . Actas del taller de ACM 2013 sobre el ciclo de vida del desarrollo móvil - MobileDeLi '13 . Indianápolis, Indiana, EE.UU .: ACM Press: 9–14. doi : 10.1145 / 2542128.2542131 . ISBN 9781450326032.
- ^ "Directriz: Patrón Entidad-Control-Límite" . posomas.isse.de . Consultado el 14 de agosto de 2019 .
- ^ Daschner, Sebastián (2017). Diseño de aplicaciones Java EE modernas: diseño de aplicaciones empresariales ligeras y orientadas a los negocios en la era de la nube, los contenedores y Java EE 8 . Packt Publishing. pp. sección "Límite de control de la entidad". ISBN 9781788397124. OCLC 1008993521 .
- ^ "El Patrón Entidad-Control-Límite" . www.cs.sjsu.edu . Consultado el 14 de agosto de 2019 .
- ^ Martin, Robert, C. (12 de agosto de 2012). "La arquitectura limpia | Blog Clean Coder" . blog.cleancoder.com . Consultado el 12 de agosto de 2019 .
- ^ Martin, Robert C. (2017). Arquitectura limpia: una guía del artesano para la estructura y el diseño de software . Prentice Hall. ISBN 978-0-13-449416-6. OCLC 1004983973 .