archivo

Archivos diarios: agosto 12, 2011

Si se consigue ganar tiempo a la planificación resulta muy interesante intentar mantener la ventaja, en un proyecto de desarrollo de software pasan muchas cosas y siempre es mejor tener un margen a favor que no tenerlo o tenerlo en contra.

En metodologías ágiles, con sprints periódicos de corta duración pueden tener menos importancia, sin embargo, ir varios metros por delante siempre es bueno tanto en carreras cortas, en el medio fondo y en el fondo.

En ciclos de vida clásicos o en cascada conseguir ventaja es un seguro de vida porque por la propia evolución de estos proyectos habrá contingencias que provocarán que el proyecto no avance como habría esperar o que retroceda (cambios en requisitos, comportamientos, interfaces en diversas fases del desarrollo).

Ahora bien, conseguir una ventaja no debe convertirse en una obsesión, tampoco mantenerla ya que puede provocar una pérdida del enfoque en los objetivos del proyecto, lo cual al final resultará perjudicial.

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