¿Debo poner a los actores en el modelo de dominio/clase-diagrama?

Question

Al diseñar tanto el modelo de dominio como los diagramas de clase, tengo algunos problemas para entender qué poner en ellos.

Daré un ejemplo de lo que quiero decir:

Estoy haciendo un programa de programador de vacaciones, que tiene un Administrator y End-Users. los Administrator hace un par de cosas como registrarse End-Users en el programa, cambiando sus previsores, etc. El End-User puede elegir sus días de vacaciones, etc.

Inicialmente definí un Administrator y End-User como conceptos en el modelo de dominio, y más tarde como clases en el diagrama de clase. En el diagrama de clase, ambas clases terminaron teniendo un par de métodos como

Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);

etc.

Solo después de un tiempo me di cuenta de que en realidad ambos Administrator y End-User Son actores, y tal vez me equivocé este diseño. En lugar de llenar las clases de administrador y usuario final con métodos para hacer lo que solicitan mis casos de uso, podría definir otras clases del dominio para hacerlos y hacer que los controladores manejen los casos de uso (en realidad, decidí hacer una para cada uno para cada uno Case de uso). Podría tener un UserDatabase.RegisterNewUser() y UserDatabase.UnregisterUser(int id);, por ejemplo, en lugar de tener esos métodos en el Administrator clase.

La idea sería tratar de pensar en todo el scheduler de vacaciones como un "programa cerrado" que tiene un conjunto de características y no se molesta con cosas como la autenticación, que debería ser interna/protegida, ya que el único público Las cosas que dejaría ver el mundo exterior serían sus controladores.

¿Es este el enfoque correcto? ¿O me estoy equivocando totalmente? ¿Es generalmente mala idea poner a los actores en el modelo de dominio/diagramas de clase? ¿Cuáles son las buenas reglas generales para esto?

Mi profesor está siguiendo Aplicar UML y patrones, que me parece horrible, por lo que me gustaría saber dónde podría buscar más información sobre esta situación de modelos de actores descritos.

Todavía estoy un poco confundido sobre todo esto, ya que este nuevo enfoque es radicalmente diferente de cualquier cosa que haya hecho antes.

Answer 1

No diría que su diseño, como especula, está totalmente equivocado, de hecho, el administrador y el usuario final son objetos de dominio válidos que deben representarse de alguna manera en los diagramas de clases. El hecho de que identifique esas dos entidades como actores no significa que deben ser excluidos del dominio, recuerde, su dominio es su alcance o "contexto relevante", es decir, el conjunto de objetos útiles que juegan un papel relevante en su solución.

Puede comenzar con objetos básicos que comprendan su modelo, simplemente escríbalos, sin más análisis, como la asalto del cerebro ...

• Vacaciones
• Ubicación
• Agente de viajes
• Calendario
• Usuario
• Reserva
• Servicio de reserva (esta puede ser una interfaz para acceder a las cosas de reserva de vacaciones)

Luego, trate de establecer las relaciones entre esos objetos, si no puede encontrar ninguna relación que signifique que no está eligiendo los objetos correctos, si son parte del mismo dominio del problema, entonces deben estar relacionados de alguna manera.

Después de un tiempo, descubrirá que faltan objetos, intente encapsular tanto como sea posible y representar las abstracciones correctas, los patrones de diseño pueden ayudarlo con eso.

Cuando cada objeto posible se representa con todas sus propiedades y métodos, entonces debe tener un diseño funcional completamente, aunque aún no terminado.

Sé que deberías tener mucha teoría en tu mente, así que ponte en marcha, sin miedo, yo mismo he usado este enfoque con éxito muchas veces en el trabajo.

Finalmente obtenga una copia de Uml destilado

Saludos,

Answer 2

Creo que debería aprender más sobre el modelado de dominio y el proceso de obtener de los casos de uso a los diagramas de clases. Los actores como clasificadores pueden ser parte de los diagramas de clases, sin embargo, para los diagramas de clase utilizados para el análisis y el diseño, modelan el sistema que desarrolla y un actor es una entidad externa. Cuando está utilizando casos de uso y diagramas de casos de uso, el objetivo es identificar las requisiciones funcionales y no funcionales, por lo tanto, definir el alcance del sistema para desarrollar y entidades externas, roles o sistemas, que interactúan con el sistema que está desarrollando. En los diagramas de casos de uso, puede encontrar a veces un cuadro que representa el límite del sistema, que abarca todos los casos de uso, que se realizarán en su sistema, pero los actores están fuera de la caja. Cuando se modela el dominio, generalmente se olvida del sistema por completo, porque desea capturar la forma en que funciona el dominio. A menudo, los diagramas especiales y los elementos de modelado se utilizan para el modelado de dominio. Como dije, el punto es comprender el dominio en el que se utilizará el sistema. Los diagramas de clases en la fase de análisis y diseño describen el sistema que está desarrollando, por lo que no pueden estar adentro actores.