Por dónde empezar cuando se hace un modelo de dominio?

Question

Digamos que he hecho una lista de conceptos voy a utilizar para dibujar mi modelo de dominio. Además, tengo un par de casos de uso de la que hice un par de diagramas de secuencia del sistema.

En la elaboración del modelo de dominio, nunca sé dónde empezar:

1. Diseñar el modelo, ya que creo que el sistema sea. Esto es, si yo estoy modelando un cuerpo humano, que se inicia mediante la adición de los conceptos de clase del corazón, cerebro, intestinos, estómago, ojos, cabeza, etc.
2. Para comenzar, el diseño de lo que necesitan los casos de uso que hacer. Esto es, si tengo un caso de uso, que se trata de hacer el cuerpo humano golondrina algo, me gustaría llamar la primera clase los conceptos de la boca, garganta, stomatch, intestinos, etc.

El orden en que hago las cosas es irrelevante? Yo diría que probablemente sería mejor intentar diseñar a partir de los conceptos de casos de uso, ya que son generalmente lo que quiere trabajar con él, no otro tipo de conceptos que si bien ayuda a describir todo el sistema así, gran parte de la fuerza de tiempo ni siquiera se necesitarán para el proyecto actual. ¿Hay algún otro método que no estoy tomando en consideración aquí? ¿Cómo suele acercarse a este?

Gracias

Answer 1

Yo empezaría por un dibujo de un diagrama de clases con todas las relaciones e implementar sólo las clases que son necesarias de acuerdo a los requerimientos de su aplicación.

Puede utilizar un enfoque anémica (atributos, además de captadores y definidores) para mantener las cosas simples y evitar el paso de escribir la lógica de negocio en el mismo paso. Con un modelo de anemia, la lógica sería entrar en una clase de servicio correspondiente. De esa manera se puede considerar casos de uso más adelante.

Sé que algunas personas no aprecian esta forma de hacer las cosas, pero sí ayuda con el mantenimiento y evita algunos problemas de dependencia.

respuesta a la pregunta de Elysium devorado por debajo de

En términos de análisis, a partir de casos de uso (Lo) y luego proceder con el diagrama de clases (cómo) suena como una regla bien del pulgar. En lo personal, me gustaría hacer el diagrama de secuencia (cuándo y quién?) Después, como se necesitaría saber entre qué procesos / objetos mensajes deben ser enviados.

Más allá de que mi opinión sobre las cosas es que UML es simplemente una manera de modelar un sistema / proyecto y no una metodología por sí mismo (a diferencia de Merise, RAD, RUP, Scrum, etc.). No hay nada que impida a alguien de comenzar con cualquier diagrama, siempre y cuando tengan la información suficiente para completarlo. De hecho, ellos deben hacerse simultáneamente, ya que cada uno de los diagramas es una perspectiva diferente del mismo sistema / proyecto.

Así que, en general, depende de cómo se va sobre el análisis. Durante mis estudios me enseñaron el enfoque en cascada rígida, en el que hacer un análisis completo de principio a fin antes de producir algo de código. Sin embargo, las cosas pueden ser diferentes en la práctica, como el imperativo podría ser la de producir una aplicación de trabajo en el menor tiempo posible.

Por ejemplo, me presentaron a la metodología Scrum recientemente para un ejercicio que implica la creación de un sitio web donde los usuarios pueden publicar sus ficciones. Como había una limitación de tiempo y una visión clara de lo que debe lograrse, comenzamos de inmediato con un diagrama de clases esqueleto para representar la modelo de dominio . Los casos de uso A continuación, se deducen de una serie de pantallas simuladas que habíamos producido.

De memoria, las clases eran historia, capítulo, usuario y categoría. Esta última clase fue eliminado a favor de una clase Tag más flexible. Como era de imaginar, el diagrama de clases completo del proyecto existente sería mucho más complejo debido a la aplicación del diseño de dominio impulsada y las especificidades del lenguaje de programación Java.

Este enfoque podría ser visto como descuidado. Sin embargo, un sitio web como este podría ser fácilmente hecho en un par de semanas usando un proceso iterativo y todavía estar bien diseñado. La ventaja de un proceso iterativo tiene sobre el enfoque en cascada es que se puede ajustar continuamente los requisitos a medida que avanza. requisitos cambiantes frecuentes es una realidad, ya que la gente suele cambiar de opinión y la posibilidad de producir una aplicación de trabajo después de cada iteración le permite a uno mantenerse en curso por así decirlo.

Por supuesto, cuando usted está presentando un proyecto para un cliente, un análisis completo con los diagramas UML y algunas pantallas simuladas sería preferible para que tengan una idea de lo que está ofreciendo. Aquí es donde entra en juego el UML. Una vez que ha explicado algunas de las convenciones visuales, la persona debe ser capaz de entender los diagramas.

Para terminar, si estás en la situación en la que estamos tratando de determinar lo que un cliente quiere, que es probablemente una buena idea para construir gradualmente un cuestionario que puede llevar con usted. Entrevistando a una persona es la única manera de determinar qué conceptos / características son realmente necesarios para una aplicación, y usted debe esperar para volver con el fin de aclarar algunos aspectos. Otro consejo sería hacer una investigación rápida en la web cuando usted se enfrenta con un tema que importa no está familiarizado con.

En su example, esto sería ir a través de los fundamentos de la anatomía. Entre otras cosas, esto le ayudará a decidir cuál es el modelo debe contener y lo granularidad que debe tener (lo que debe considerarse grupo de órganos? ¿Cómo precisa qué necesita ser? Hacer sólo los órganos necesitan modelado o deberían ser descompuesto en sus constituyentes como tejidos, células, composición química, etc.?).

Answer 2

Ya sea DDD, o no, que se lo recomendaría con la determinación de la lengua ubicua (UL) entrevistando al propietario del producto (s). El establecimiento de la comunicación de una manera que va a tener usted y los propietarios de productos de hablar el mismo idioma, no sólo los ayudantes en la comunicación, pero ser capaz de discutir el proyecto en términos comunes tiende a ayudar al modelo de dominio definirse a sí misma.

Por lo tanto, mi respuesta es básicamente para hablar, escuchar y aprender. Software sirve una necesidad. Comprender el modelo desde el punto de vista de los expertos pondrá la base sólida para la aplicación.

Answer 3

Creo que el lugar para empezar sería lo que se siente lógico y cómodo. Es probable que sea mejor empezar con los casos de uso, ya que le dan dirección y metas claras, y ayuda a evitar situaciones YAGNI. Teniendo en cuenta que usted debe estar tratando de desarrollar un modelo de dominio fuerte, no debe realmente importan, como el cuadro completo del dominio es importante.

Answer 4

Me gustaría compartir mi experiencia para este tipo de situaciones. Por lo general comienzan con la escritura de ensayos y código. Y tratar de cubrir un extremo a otro caso de uso. Esto me da bastante idea clara acerca de un problema y al final también tengo algo de trabajo conmigo que puedo mostrar el caso de mi cliente. La mayoría de las veces las historias posteriores construir una encima de la anterior, pero también me pasa que las historias posteriores requieren cambios en el modelo anterior que se me ocurrió. Pero esto no me impacto como ya tengo una buena cobertura de la prueba. De esta manera se me ocurrió con el modelo que va bien para el problema actual, no el modelo que mapea el mundo real.

Answer 5

Se inicia con los requisitos empresariales que pueden formalizarse o no. Si formalizado que usaría Los diagramas de casos.

Por ejemplo, aquí son diagramas de casos de uso para una aplicación de comercio electrónico: http://askuml.com/blog/e-commerce/

http://askuml.com/files/2010 /07/e-commerce-use-case.jpg http://askuml.com/files/2010/07/ comercio electrónico-uso-case2b.jpg

A partir de estos casos de uso, se puede deducir de forma natural las entidades de negocio:. De productos, categorías de productos, carrito de compras, ... que es empezar a preparar diagramas de clases

Esta es la mejor práctica en muchas metodologías pero esto también es de sentido común y natural.

Answer 6

Respuesta corta

Escoja un caso de uso, sacar algún diagrama de colaboración (y un diagrama de clases) para darse cuenta de dominio objetos involucrados. Concentrado sólo en aquellos objetos participó con el fin de alcanzar el objetivo de casos de uso. TDD caso de prueba de escritura para establecer la expectativa y poco a poco modelar sus clases de dominio para cumplir con las expectativas. TDD es muy útil para entender los comportamientos esperados y ayuda a conseguir el modelo de dominio más limpio. Verá su dominio evolucionar gradualmente junto con las expectativas de TDD.

Long respuesta

Mi experiencia personal con DDD no fue fácil. Eso era porque no teníamos bases necesarias en el primer lugar. Nuestro equipo tenía muchos puntos débiles en diferentes áreas; requisitos no fueron capturados adecuadamente y que sólo tenía un representante del cliente que no es realmente útil (no involucrados) era. No teníamos un plan de lanzamiento apropiado y desarrolladores tenido una falta de conceptos orientados a objetos, los mejores principios y así sucesivamente. El principal problema que tuvimos fue pasando tanto tiempo en tratar de entender la lógica de dominio. Esbozamos muchos diagramas de clases y nunca tuvimos la derecha modelo de dominio, por lo que dejamos de hacer eso y descubrimos lo que salió mal. El problema era que tratamos demasiado duro para entender la lógica de dominio y en lugar de comunicar hicimos supuestos sobre los requisitos. Decidimos cambiar nuestro enfoque, hemos aplicado TDD, empezamos a escribir el comportamiento esperado y codificados modelo de dominio para cumplir con las expectativas del TDD. A veces llegamos casos de prueba de escritura TDD atascados porque no entendemos el dominio. Nos enseguida hablamos con el representante de los clientes y tratamos de obtener más de entrada. Cambiamos nuestra estrategia de liberación; aplicado la metodología ágil y liberación con frecuencia para que llegamos retroalimentación real del usuario final. Sin embargo, es necesario para garantizar la expectativa usuario final se fijó en el nivel adecuado. Refactorizamos basado en la retroalimentación, y de esa manera el modelo de dominio evolucionado gradualmente. Posteriormente, se aplicó patrones de diseño para mejorar la capacidad de reutilización y facilidad de mantenimiento. Mi punto aquí es que DDD por sí sola no puede sobrevivir, tenemos que construir el ecosistema que abarca el dominio, los desarrolladores deben tener fuertes conceptos de POO y debemos apreciar TDD y prueba unitaria. Yo diría DDD se sienta encima de todas las técnicas y prácticas de programación orientada a objetos.