archivo

Archivo de la etiqueta: 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.

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”.

En el artículo anterior vimos una posible forma de enfocar la gestión CRUD en los casos de uso. En este voy a añadir un par de posibles soluciones a circunstancias que se pueden dar en la definición de los casos de uso de un sistema de información:

1) Puede haber alguna tabla maestra que tenga alguna operación expecial como por ejemplo el duplicado de un registro (puede ser útil sobre todo en aquellos casos donde cada registro tengo un número elevado de atributos).

¿Cómo podemos llevar esto al modelo de casos de uso?

Seguiriamos teniendo la entidad donde se realiza esta operación con una relación de herencia sobre el caso de uso “Gestionar Entidad”. Al hacerlo entendemos que se hereda el comportamiento del mismo, así como las relaciones que tenga. Como se trata de una operación más, pues a nivel de diagrama de casos de uso bastará con incluir un nuevo caso de uso en el que se describa la interacción sistema/actores para la realización de la operación que extenderá al caso de uso de la entidad, el cual no será necesario describir ya que en nada varía su funcionamiento.

2) ¿Y si alguna operación tiene un comportamiento especial en la gestión de una entidad?

Una posible solución consiste en que se describa esa operación en un caso de uso y extienda al caso de uso de la entidad (que a su vez tiene una relación de herencia con el caso de uso genérico “Gestionar Entidad”).

Se entenderá que ese caso de uso “sobreescribe” al caso de uso definido para dicha operación en el caso de uso genérico.

3) A veces hay entidades más complejas que comparten parte del funcionamiento de una gestión CRUD (como por ejemplo el alta o la consulta), ¿cómo representarlo?.

Una posible solución sería aplicar una solución similar a la que he expuesto en el caso anterior, todo lo nuevo tendría relaciones extend con respecto al caso de uso de gestión de la entidad (no confundir con el caso de uso genérico).

Quiero dejar claro que estas soluciones o estratégicas no buscan una aplicación purista de UML o de la estrategia de diseños de caso de uso, se trata de una forma de aplicar los mismos con el objeto de no que los casos de uso no representen repetición de comportamientos y así poder invertir el esfuerzo en describir aquellas interacciones actores/sistema que tienen un comportamiento específico y que sí resultan interesantes ser descritas de la manera más exacta posible.

Supongamos que una aplicación gestiona 40 tablas maestras, ¿qué aportan los casos de uso de esas 40 entidades si el comportamiento será el mismo, teniendo en cuenta que lo más probable es que su gestión CRUD haya sido codificada por un generador de código? (variarán los atributos que componen las entidades, tal vez alguna requiera de algún tipo de tratamiento especial, pero serán excepciones).

Soy de la opinión de que en estos casos no hay que ser purista y sí práctico.

Una posible solución es crear un caso de uso genérico (por ejemplo denominado Gestionar Entidad) y que se relacionen con él en modo extend un caso de uso por cada operación CRUD. Después del caso de uso genérico heredarían un caso de uso por cada entidad que tenga gestión CRUD (estos casos de uso solo aparecerían en el diagrama de casos de uso y no se describirían).