Casos de uso. ¿Representamos los CRUD?

En el último artículo que publiqué sobre la temática de los casos de uso, un lector me dejó el siguiente enlace (en inglés): Cómo implementar operaciones CRUD en UML, en el que como respuesta se indica que si la representación en los diagramas/modelos no aportaba valor, tal vez la mejor solución pasaba por no representarlos.

Y me parece una buena propuesta, ¿por qué no?, sin embargo sí que soy partidario que cómo mínimo, en el caso de los casos de uso se estereotipen los que se correspondan a gestiones CRUD y que se haga referencia a un guía, libro blanco, etc…, de la organización en la que se especifique cómo debería ser el comportamiento en este caso, en los maestros/detalle o en cualquier otro tipo de figura que se quiera estandarizar.

Los generadores de código suelen resolver la problemática del CRUD, sin embargo, no todos la resuelven de la misma manera. Si existen diversas empresas que desarrollan para tu organización, te encontrarás con que utilizan diversos generadores y la solución de salida será distinta, algo que en la medida de lo posible resulta interesante evitar.

2 comentarios
  1. johann dijo:

    Creo que has dado en la clave. Los CRUD no aportan nada en los casos de uso. En todo caso en el diseño de casos de uso. Que, se debería generar automáticamente desde los casos de uso de análisis. Y posiblemente, al hacer el paso automático, se podría generar directamente el código desde los casos de uso.
    Y definir en una “ley orgánica(*)” como son los CRUD. De este modo, sólo hay un punto dónde modificar ante cambios. Y posiblemente en un documento distinto al análisis. Porque… si se cambia la forma de un CRUD ¿hay que cambiar el análisis de una aplicación? Yo creo que no. Sólo afecta al diseño.

    pd: lo de ley orgánica es un símil al cambio/estafa que nos van a hacer los políticos con la reforma constitucional.

    • jummp dijo:

      En mi organización vamos a tender muy probablemente a colocar determinados tipos de comportamiento en un manual (no tenemos todavía claro si será en el libro blanco o no) al igual que determinados tipos de validaciones. El objetivo como bien apuntas es tener una referencia de los mismos en los hitos documentales del proyecto de manera que se consiga por un lado unificar determinadas funcionalidades/comportamientos/validaciones en las aplicaciones y por otra que todo ello esté controlado en un punto único.

      Esta forma de trabajar, favorecerá también la reutilización de código.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: