subscripción
Ideas + Ingeniería del Software
Cuándo hacer el modelo de datos
Marzo 8th, 2009 - [Enlace local]
Si me preguntasen por el mínimo común denominador de la aplicación de las metodologías tradicionales que he visto en los últimos años, respondería sin dudar el modelo de datos. La gestión de los requisitos es muy variable, el diseño y la construcción varían enormemente... Sin embargo, el momento y la forma en que se hace el modelo de datos siempre era la misma. Una vez recogidos los requisitos, durante el análisis, el paso clave que marcaba, en cierto modo, el fin del trabajo del analista y el comienzo del resto, era la validación del modelo de datos.
En las metodologías tradicionales se hace en dos partes: en la fase de análisis se hace el modelo lógico, y en diseño se hace el físico. En la práctica siempre he visto que esto se fusionaba. Quizá por las herramientas, quizá por lo innecesario de la división, siempre se hace directamente el segundo.
Desde que uso Hibernate había querido aprovechar al máximo la potencia de su mapeo relacional, relegando el modelo de datos a un segundo plano en favor del modelo de clases. Esto, que parece un detalle menor, en mi opinión tiene una gran importancia práctica. Hacerlo implicaría que el analista/diseñador haría, en vez del modelo, directamente las clases, las cuales generarían el primero automáticamente. Expuse esta idea esgrimiendo una serie de ventajas:
- El trabajo de modelado aportaría más información, ya que los modelos Java más las anotaciones de persistencia aportan más información y valor que las tablas (se introducen validaciones de datos, propiedades calculadas, documentación...).
- Eliminaríamos el problemático trabajo de mapear tablas existentes.
- Adelantaríamos el trabajo de la programación de las entidades.
- Podríamos anticipar cosas como pruebas automáticas para verificar la corrección del modelo.
- Personalmente trabajo mejor con una herramienta de desarrollo que con una de modelado. Andar con el ratón, dobles clicks y diálogos me parece engorroso y lento, aunque esto ya son preferencias de cada uno.
- No renunciamos a la información gráfica, ya que podemos generar diagramas tanto de clases como de objetos mediante ingeniería inversa (NetBeans es realmente útil para esto).
Al pasar a metodologías ágiles, al desaparecer estas fases, toca decidir cuándo realizar este trabajo. Scrum obviamente no entra en esta decisión, así que, ya con la capacidad de decisión, me adherí al principio de diseño contínuo y además adopté las ideas anteriores. De esta forma, no se haría el trabajo explícito de modelado de los datos, sino que, a medida que se avanzase en la aplicación, se iría mejorando a través del propio diseño de las clases.
Ya con el proyecto en desarrollo, saco las siguientes conclusiones:
- No realizar análisis del modelo de datos, sino trabajar directamente en el diseño de las clases, es muy práctico: es mucho más tolerante a los cambios (hemos pasado de claves deferred a compuestas de forma trivial, por ejemplo), facilita el trabajo en equipo (no más "lanza de nuevo el script de base de datos, que he cambiado el esquema")... Me reafirmo, por tanto, en los puntos expuestos antes.
- Desaparece la mentalidad de "tenemos que ceñirnos al modelo de datos a cualquier coste". He visto auténticos malabarismos por parte de desarrolladores por querer respetar el modelo del analista por todos los medios. El hecho de no tenerlo tira esa barrera.
- Pese a esto, sigue siendo necesario hacer un trabajo previo de análisis. Comprender las clases y las relaciones entre ellas es fundamental para el desarrollo del proyecto. No es necesario especificar desde un principio cada propiedad de cada clase, sus longitudes máximas y sus validaciones, pero sí es importante tener claro lo antes posible el esquema general. Los desarrolladores tendemos a centrarnos en "pantallas", y en una no está la auténtica lógica de las relaciones entre los datos.
