En los diagramas de clases UML, ¿qué son las clases de límites, las clases de control y las clases de entidad?

Ahora estoy usando NetBeans como mi IDE de elección, y tiene un complemento para el modelado UML. En el diagrama de clases, hay elementos modelo conocido como Boundary Class, Control Class, y Entity Class. Sin embargo, no puedo encontrar una buena definición de ellos, pero encontré este sitio en Diagramas de clases UML.

A menudo se usa con / como parte de OOAD y modelado de negocios. La definición de Neil es correcta, pero es básicamente idéntica a MVC, pero simplemente resumida para el negocio. El "buen resumen" está bien hecho, así que no lo copiaré aquí, ya que no es mi trabajo, más detallado pero en línea con los puntos de Neil.

Buen resumen - Conceito: Patrón Entidad-Control-Límite

OOAD

Los diagramas de robustez se escriben después de los casos de uso y antes de los diagramas de clases. Ayudan a identificar los roles de los pasos del caso de uso. Puede utilizarlos para asegurarse de que sus casos de uso sean lo suficientemente sólidos para representar los requisitos de uso del sistema que está creando.

Implican:

1. Actores
2. Casos de uso
3. Entidades
4. Límites
5. Control S

Mientras que el patrón Modelo-Vista-Controlador se usa para interfaces de usuario, el Patrón Entidad-Control-Límite (ECB) se usa para sistemas. Los siguientes aspectos de ECB se pueden comparar con una versión abstracta de MVC, si eso es útil:

Entidades (modelo)
Objetos que representan datos del sistema, a menudo del modelo de dominio.

Límites (vista / colaborador de servicios)
Objetos que interactúan con los actores del sistema (por ejemplo, un usuario o un servicio externo ). Las ventanas, las pantallas y los menús son ejemplos de límites que interactúan con los usuarios.

Controles (controlador)
Objetos que median entre fronteras y entidades. Estos sirven como el pegamento entre los elementos de frontera y los elementos de la entidad, implementando la lógica necesaria para gestionar los diversos elementos y sus interacciones. Es importante comprender que puede decidir implementar controladores dentro de su diseño como algo más que objetos; muchos controladores son lo suficientemente simples como para implementarse como un método de una entidad o clase de límite, por ejemplo.

Se aplican cuatro reglas a su comunicación:

1. Los actores solo pueden hablar con objetos delimitadores.
2. Los objetos de límite solo pueden hablar con controladores y actores.
3. Los objetos de entidad solo pueden hablar con controladores.
4. Los controladores pueden hablar con objetos de límites y objetos de entidad, y con otros controladores, pero no con los actores.

Comunicación permitida:

         Entity    Boundary   Control
Entity     X                     X
Boundary                         X
Control    X          X          X

Estos son estereotipos de clase que se utilizan en el análisis.

• Las clases de límite son las que se encuentran en el límite del sistema: las clases con las que usted u otros sistemas interactúan

• clases de entidad las clases son las entidades comerciales típicas como "persona" y "cuenta bancaria"

• las clases de control implementan alguna lógica empresarial u otra

El patrón de entidad de control de límites tiene dos versiones:
- estructura antigua, descrita en 127 (entidad como elementos del modelo de datos, control como una función, límite como interfaz de aplicación)
- nuevo patrón de objeto


Como patrón de objeto:
- Límite es una interfaz para " otro mundo "
- Control en cualquier lógica interna (como un servicio en patrón DDD)
- La entidad es un serwis de persistencia para objetos (como un repositorio en patrón DDD).
Todas las clases tienen operaciones
. Las reglas:
- Solo Boundary proporciona servicios para el "otro mundo"
- Boundary solo puede llamar a Controll
- Control puede llamar a cualquiera
- La entidad no puede llamar a nadie (!), Solo ser llamado.

jz

En realidad, los diagramas de robustez (o diagramas de análisis, como a veces se les llama) son simplemente diagramas de clases especializados. Son parte de UML, y lo han sido desde el principio (consulte el libro de Jacobson, El proceso de desarrollo de software unificado, parte de la serie de libros "Tres amigos"). El libro antes mencionado tiene una buena definición de estas tres clases en las páginas 183-185.