Casos de Uso. Una posible solución para la representación de maestros/detalle

Hace unas semanas comenté una posible solución para la representación de la gestión CRUD a través de casos de uso (es muy recomendable la lectura de los dos artículos que le dedico a esa solución porque la que planteo en este no es más que una adaptación o continuación de la misma y tal vez algún aspecto que exponga no se entienda de manera adecuada si no se toman como referencia ambos artículos).

En esta ocasión voy a realizar una propuesta para representar las relaciones maestro/detalle. De igual forma que en el caso anterior, no pretende dar una solución académica u ortodoxa, sino una solución que pretende ser práctica, sencilla y repetible que pueda ser adaptada a las características de la aplicación que se quiere representar o incluso al nivel de detalle al que queramos llegar en la definición de los casos de uso.

Como en el caso de la gestión CRUD, todo gira alrededor de los casos de uso de negocio y a través de ellos se orquestan las operaciones que se pueden hacer sobre el caso de uso.

En este caso creamos un caso de uso genérico al que podemos denominar Gestionar Maestro.

Sobre el maestro se realizarán normalmente las operación de consulta, inserción de nuevos registros, borrar registros (siempre y cuando no tengan registros asociados, salvo que se admita el borrado en cascada, cualquiera de las dos alternativas se tendrá que tener en cuenta en la definición del caso de uso que extiende al caso de uso principal y que representa a la operación de borrado) y actualizarlo.

Si se prefiere no sería necesario definir los casos de uso que representan a las operaciones de inserción y consulta, salvo que presenten alguna modificación respecto a las definidas en el caso de uso genérico del CRUD (Gestionar Entidad). Si se opta por esta opción, se tendría que poner el caso de uso Gestionar Maestro heredando de Gestionar Entidad.

Pues bien, sobre el caso de uso de actualización es donde extenderán los distintos casos de uso que se encargan de la gestión de los detalles. En la definición de este caso de uso genérico, valdrá con una relación de extend a otro caso de uso genérico que será Gestionar Detalle y que será el que se “sobreescribirá”, mediante una relación extend con el Maestro en cada representación particular de Maestro/Detalle.

Como estos casos de uso de detalle son mayoritariamente a su vez gestión CRUD o gestión maestro/detalle, también es posible simplificar su representación. Los que sean de gestión CRUD no será necesario definirlos, simplemente especificarlos y en todo caso lo único que habrá que hacer será reflejar las operaciones que se añaden o las que varían su comportamiento respecto a la definición inicial que se haga del CRUD (todo ello vendrá dado por la relación de herencia que habrá entre esta caso de uso y el caso de uso genérico “Gestionar Entidad”) y los que sean gestión de Maestro/Detalle podrán heredar a su vez del caso de uso “Gestionar Maestro”.

5 comentarios
    • jummp dijo:

      He escrito un artículo que he programado para su publicación a fin de mes, donde comento mis impresiones sobre lo que se indica en el enlace que has puesto.

      Básicamente vengo a decir que lo que se indica es una opción totalmente respetable y válida y si todas las partes que participan en el desarrollo están de acuerdo con no representar la gestión CRUD, pues me parece bien que no se haga.

      Ahora bien, también indico que desde mi punto de vista, en el caso de querer hacerse así, creo que resulta interesente, por lo menos representar dichos casos de uso en el diagrama, estereotipándolos de manera que sean distinguibles del resto y en la medida de lo posible, tener recogido el comportamiento de dicha gestión en un manual o guía, con el objeto de darle una uniformidad al comportamiento de la gestión CRUD ya que aunque puedan parecer similares, los distintos generadores de código le suelen dar una solución diferente (a nivel de comportamiento) a los mismos.

  1. Ricardo dijo:

    la verdad es que todo esto es muy interesante. Pero pensando sobre los CRUD, he estado leyendo como hacerlo con RoR y otros lenguajes y he llegado a la siguiente cuestión: ¿importa el lenguaje de programación en un documento de análisis? ¿importa como son los CRUD?.
    La respuesta es ‘No’. Creo que eso es una tarea del diseño de la aplicación. Más concretamente debe estar reflejado en el diseño del sistema y en el diseño de la GUI.
    1. Diseño: se deben definir la relación entre entidades, y como afecta el borrado entre ellas (on delete cascade, etc)
    2. GUI: una aplicación no debe permitir que se pueda borrar o no un registro por el resultado de la bbdd. Se debe definir en toda GUI cuando se puede borrar y bajo que circunstancias.

    Por lo tanto, creo que esto es hecho que no lleva a nada.

    Bueno, que no lleva a nada falso. Todo sería perfecto si como has comentado en una CASE prototipas los casos de uso, que luego te ayudan en el diseño y en la definición de la GUI. Pero sobre todo, si generas código mediante MDA. Desde los casos de uso, se puede generar tanto casos de uso de diseño (el CRUD) que sirva de apoyo para la generación de directa de código.
    Estos son dos pasos, que deben ser controlados, pero para evitar errores. De hecho, el documento de casos de uso de diseño, no debería ser ni siquiera evaluable, ya que debe ser un ‘output’ directo de los casos de uso de análisis.

    Por lo tanto, creo que los CRUD no deben estar ningún caso en los Casos de Uso, salvo que trabajemos en una organización “organizada” dónde todo la fase de proyecto/desarrollo/servicio esté bajo automatización de software. En pocas palabras, en una organización con ITIL en el servicio, y una alta madurez en todas las fases de proyectos (podría ser CMMI 3)

    • jummp dijo:

      El análisis tiene que ser lo más independiente posible del lenguaje de programación, eso es la teoría y la práctica también demuestra que análisis realizados de esta manera son posibles y efectivos. Ahora bien, cuando comenzamos un proyecto se sabe muy bien con que lenguaje se va a realizar e incluso se tendrá perfilada la metodología y se tendrá incluso definido un generador de código a utilizar, el framework de desarrollo, las normativas técnicas de construcción, las buenas prácticas a emplear, etc…, por lo que en la mayoría de los proyectos no tendría excesiva importancia que el lenguaje condicionara en cierto modo el análisis, ya que en pocas ocasiones se reutiliza un análisis de un proyecto a otro, entre otras cosas porque al cambiar los usuarios por mucho que se parezca un proceso a otro, cambian las reglas del juego.

      En cualquier caso soy partidario de que el análisis sea lo más aséptico posible en cuanto a la tecnología de desarrollo y así intento que sea en los proyectos en los que participo.

      Los casos de uso representan comportamientos a una petición realizada por un actor (directa o indirectamente a través de otro caso de uso) y esos comportamientos pueden ser repetibles, de ahí el interés de homogenizarlos como indicaba también que habría que hacer con el catálogo de validaciones y esto puede alcanzar a los CRUD, a los maestros/detalle, a la gestión de la identificación/autenticación/autorización, etc…. Otra cosa es que luego en fase de diseño se terminen de perfilar ciertos aspectos.

      Ahora bien todo lo anterior dependerá del nivel de detalle con que se quiera realizar el caso de uso, cuanto más abstracta sea su visión, más se deja para etapas posteriores. Aquí es donde la metodología de desarrollo utilizada o las pautas definidas en la organización entran en juego. Cuánto atacas en el análisis, cuánto en el diseño.

      Yo soy partidario de homogeneizar en lo posible cuanto más variedad tengamos más costoso será mantener los sistemas, incluso teniendo una deuda técnica decente (algo que desgraciadamente y, por regla general, no suele ser lo más habitual). ¿Dónde y cuándo la aplico? Creo que cada desarrollador tendrá su opinión al respecto, siendo la mayoría de ellas igual de válidas siempre y cuando se apliquen de manera adecuada.

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: