El modelado de dominio se entiende como modelado abstracto. un modelo de sitio podría ser una ilustración de las ideas u objetos que se muestran dentro del dominio de inconvenientes. Además, captura las relaciones aparentes entre estos objetos. Las muestras de tales objetos abstractos se encuentran en el libro, el registro de libros, el registro de miembros, el miembro de la biblioteca, etc. La estrategia sugerida es producir rápidamente un modelo abstracto aproximado donde el estrés es encontrar las ideas aparentes expresadas en las necesidades mientras se pospone una investigación en profundidad. Posteriormente, a lo largo del método de eventos, el modelo abstracto se refina y amplía de forma incremental. Los 3 tipos de objetos se conocen a través del análisis de dominio. Los objetos conocidos a lo largo del análisis de dominio se clasifican en 3 tipos:
- Objetos de contorno
- Objetos de controlador
- Objetos de entidad
Los objetos de límite y controlador se conocen consistentemente a partir del diagrama de casos de empleo, mientras que se debe aplicar la identificación de objetos de entidad. Entonces, el quid de la actividad de modelado de dominio es detectar los modelos de entidad.
El propósito de varios tipos de objetos conocidos a través del análisis de dominio y la forma en que estos objetos se mueven entre sí.
Los diferentes estilos de objetos conocidos a lo largo del análisis de dominio y el área de su unidad de relación son los siguientes:
- Objetos de frontera: El área de objetos de frontera une aquellos con los que se mueven los actores. Estos incluyen pantallas, menús, formularios, diálogos, etc. La unidad de área de objetos de contorno es principalmente responsable de la interacción del usuario. Por lo tanto, normalmente no adoptan ninguna lógica de proceso. Sin embargo, serán responsables de verificar las entradas, el formato, las salidas, etc. Los objetos de límite se conocían anteriormente como objetos de interfaz. Sin embargo, el término categoría de interfaz se usa para Java, COM/DCOM y UML con medios completamente diferentes. Una recomendación para la identificación inicial de las categorías de límite es delinear una categoría de límite por intento de actor/caso de uso.
- Objetos de entidad: por lo general, contienen información como tablas de información y archivos que requieren durar más que la ejecución del caso de uso, por ejemplo, Book, BookRegister, LibraryMember, etc. varios de los «servidores tontos» de la unidad de área de objetos de entidad. normalmente son responsables de almacenar información, obtener información y realizar algunos estilos básicos de operación que no suelen cambiar.
- Objetos de controlador: Los objetos de controlador coordinan las actividades de una colección de objetos de entidad y se interconectan con los objetos de límite para producir el comportamiento general del sistema. Las responsabilidades asignadas a una unidad de área de objeto de controlador están estrechamente asociadas con la creencia de un caso de uso particular. Los objetos del controlador desacoplan efectivamente los objetos de límite y de entidad entre sí creando un sistema tolerante a los cambios en el programa de computadora y la lógica del proceso.
Los objetos del controlador incorporan la mayor parte de la lógica comprometida con la realización del caso de empleo (esta lógica puede modificarse de vez en cuando). A continuación (figura) se muestra una interacción típica de un objeto de controlador con objetos de límite y de entidad. Normalmente, cada caso de uso es una victimización completa de un objeto de controlador. Sin embargo, algunos casos de uso están completos sin victimizar a ningún objeto controlador, es decir, a través de objetos límite y de entidad únicamente. A menudo, esto es cierto para los casos usados que ganan solo una manipulación fácil de la retención de información.
Por ejemplo, tomemos en cuenta el caso de uso de «disponibilidad del libro de consulta» del sistema de datos de la biblioteca (LIS). La realización del caso de empleo implica únicamente comparar el nombre del libro dado con los libros ofrecidos en el catálogo. casos de uso complicados adicionales pueden necesitar un objeto controlador para comprender el caso de empleo. un caso de uso elegante tendrá muchos objetos de controlador como el administrador de acciones de grupo, el organizador de recursos y el controlador de errores. hay otra situación en la que un caso de uso tendrá un único objeto controlador. en general, los casos de empleo necesitan que el objeto del controlador transite por una variedad de estados. En tales casos, es posible que sea necesario crear un objeto de controlador para cada ejecución del caso de empleo.