Modelando un sistema después de haber definido el caso de uso UML

Question

... ¿qué sigue?

Después de definir qué actores hacen qué acciones, en qué dirección vas? ¿Modela la base de datos o prefiere comenzar con las clases?

Pensé que el mejor enfoque era comenzar con un diagrama de modelado similar a una clase, para centrarse en las relaciones entre los objetos. Esto ha demostrado ser incorrecto porque profundicé demasiado en el detalle de las clases e, incluso si el sistema "parecía funcionar", cuando fui al modelado de la base de datos, todo no encajaría naturalmente en las posiciones que elegí en la fase anterior. .

Leí sobre personas que dicen que uno debería poner la lógica de la aplicación en una base de datos y aprovechar su velocidad para recuperar datos, en lugar de construir objetos grandes en la memoria que se consultan y proporcionan una abstracción de la base de datos subyacente. Siempre pensé que la base de datos está ahí para almacenar mis datos y proporcionar una forma rápida de acceder a ellos. Pero tal vez me equivoque, quiero decir, ¿realmente tengo que construir una base de datos que tenga la misma lógica que pondría en un grupo de clases? ¿No carece la base de datos de las herramientas para lograr esto?

Creo que estoy fallando en identificar el punto correcto donde comenzar, si elijo comenzar con la base de datos, me resulta difícil no solo pensar en él como un lugar para almacenar mis datos, hagamos la lógica de la aplicación en un nivel superior " Si empiezo con clases, la base de datos termina pareciéndose a una representación no natural de clases, siento la sensación de perder algo importante, algo así como no asignar el propósito correcto a la herramienta correcta.

¿Cómo lidias con esto? Cuando se trata de decidir si comenzar con el modelado de la base de datos o las clases, según su experiencia, ¿qué tipo de enfoque ha demostrado conducir a una implementación natural y limpia?

Gracias de antemano

Answer 1

He tenido éxito al utilizar Análisis de robustez .

  

Este artículo se centra en la robustez   análisis, que implica analizar la   texto narrativo de casos de uso y   identificar un conjunto de primera suposición de   Objetos que participarán en cada uno.   caso de uso, luego clasificando estos   objetos en tres tipos:

     

  
1. Objetos de límite, que los actores utilizan para comunicarse con el sistema.
  
2. Objetos de entidad, que generalmente son objetos del modelo de dominio   (el tema de " Diseño de conducción: El   Dominio del problema, " Enero de 2001).
  
3. Objetos de control (que generalmente llamamos controladores porque   a menudo no son objetos reales), que   servir como el " pegamento " entre el límite   Objetos y objetos de entidad. Figura 1   Muestra los iconos visuales de estos tres.   tipos de objetos.
  

Los objetos de entidad son aquellos que (generalmente) terminan en la base de datos /

En la asignación entre las clases y la base de datos, recomendaría El artículo de S.Lott sobre " The ORM Problem " (también es un participante en StackOverflow

Answer 2

Si está utilizando el desarrollo guiado por pruebas, escriba primero las pruebas unitarias. Tus clases se describirán a medida que vayas.

Puede elegir desarrollar su lógica empresarial sin una base de datos (objetos simulados o de código auxiliar) o desarrollar su base de datos a medida que avanza con sus pruebas.

Recuerde que su base de datos y su modelo de dominio no deben asignarse uno a uno entre sí.