lunes, enero 10, 2005

Casos De Uso - CRUD

Los casos de uso son la forma como los ingenieros de sistemas capturan los requisitos de sus clientes. Respecto a este tema y de acuerdo a mi experiencia considero que se debe al momento de identificar casos de uso, se debe tener claro cual cual es el dominio del problema, cuales son las palabras que nos ayudan a describir el problema de nuestro cliente y una manera básica para identifcar casos de uso es la utilización del CRUD
  • c: create
  • r: read
  • u: update
  • d: delete

Para identicar casos de uso basicos en nuestro sistema.. en mi criterio no se puede dejar funcionalidades ocultas detras de las palabras:

  • gestionar
  • administrar
  • controlar

Pues pueden lugar a suponer una cantidad de funcionalidades que pueden llevar a que el cliente quede insatisfecho por mal entendimiento de sus requisitos o que la empresa desarrolladora termine trabajando mas de lo que tenia estimado llevandola a costos onerosos en un proyecto inicialmente sencillo.
Si tomamos el ejemplo de un sistema de administracion de taxis, dentro del dominio del problema encontraremos palabras como:
  • TAXI
  • Conductor
  • Propietario
  • Servicio,
  • entre muchos otros, dependiendo del lo que signifique nuestro sistema de administracion de taxis.

Pero valiéndonos del crud podemos minimo identificar los siguientes casos de uso:
  • crear taxi (o lo que es lo mismo, ingresar taxi)
  • actualizar taxi
  • eliminar taxi
  • listar taxi
  • mostrar taxi
  • buscar taxi
quedandose por fuera casos de uso como:
  • suspender taxi
  • sancionar taxi
  • traspasar taxi
  • entre otros.

es claro entonces que el crud nos ayuda a poner todas las funcionalidades visibles al cliente y a los desarrolladores y desde ese punto de vista, se pueden encontrar, más casos de uso, considero la busqueda de casos de uso como una tarea exhaustiva en las primera fases de un proyecto de desarrollo, de manera que se logre un acuerdo sensato entre las partes de los casos de uso a desarrollar y de esa manera, ambas partes ganen

7 comentarios:

Anónimo dijo...

Es demasiado la fragmentación en:
Crear taxi,
Actualizar taxi,
.....
etc.

Todos estos casos de uso pueden ir perfectamente dentro de un caso de uso, como GESTIONAR O MANEJAR taxis. La idea es tener una representación mínima de casos de uso, de la forma ejemplificada habrá miles de casos de uso en el sistema.

Jorge Hernán Abad Londoño dijo...

Pienso que se le debe perder miedo a "LOS MILES" de casos de uso, entre menos huecos en los requisitos mas clara la definición del tamaño del proyecto

Anónimo dijo...

Yo estoy de acuerdo con Jorge. Una ERS(Especificación de req de Soft) reducida da la impresión de un sistema sencillo y da lugar a confusiones sobre la funcionalidad esperada del software.
Es más, me gustaría conocer otros artículos relacionados con el tema.
Mi mail es jeronimo@neunet.com.ar.
Saludos

Anónimo dijo...

Yo intento ceñirme mas a los postulados de Booch, Jacobson y Rumbaugh que expresen que existen 3 niveles de abstraccion para modelar con casos de uso (Tecnicas comunes de modelado): Contexto, Requistos y Comportamiento. Para el nivel de Requisitos el grado de granularidad de los casos de uso se debe centrar en lo QUE quiere el usuario (por esto encontramos frecuentemente palabras como gestionar, manajar, ect ), el detalle que se expresa en CRUD se ajusta mas a el nivel de comportamiento, siendo esta la tecnica menos usada de los casos de uso, pues este se emplean mas para modelar el contexto y los requisitos. De aqui se deriva la improcedencia de los casos de uso CRUD para un documento de Especificacion de Requisitos de Software (ERS).

Jorge Hernán Abad Londoño dijo...

yo pienso que todos sabemos de que hablamos, pero al momento de cotizar un proyecto, este no se puede ni se debe cotizar en funcion de los GESTIONAR, mi experiencia y mi bolsillo lo confirman. Mientras mas requisitos esten visibles mas facil sera facturarlos pues el acuerdo con el cliente estara mas claro.

Anónimo dijo...

Desde que Jacobson empezó a escribir fuertemente de los casos de uso, centró su atención en ayudar a definir la funcionalidad del producto. Es importante recalcar que la estimacion se centra en varias dimensiones, EL PROYECTO, EL PROCESO, EL PRODUCTO, entre otros. En cada dimension se enfoca en un aspecto diferente, definitivamente la dimension del producto no se fundamenta en tratar "El Bosillo", ésta se centra mas en la funcionalidad. Tecnicas de estimacion como los Puntos de Casos de Uso son buenas, pero como lo proponen las dimensiones de la estimacion no pueden verse afectadas por factores monetarios, estos deben dejarse a las otras dimensiones (el proyecto, el proceso...)

Anónimo dijo...

Es un error colocar dentro de un CU, la alta, baja y modificacion de clases de entidad. No deben incluirse baja un mismo nombre como "gestionar taxis" ya que un CU debe tener una funcionalidad única y facilmente identificable (es decir que deben ser altamente cohesivos). Pero también pienso que CRUD no te permite identificar los CU principales, solo aquellos de configuración del sistema o mantenimiento de la base de datos, pero no los que realmente le importan al cliente.
En la primera etapa de la identificación de los casos de uso, no hay que preocuparse por “cómo” se implementarán éstos, hay que buscar primero el “qué” va a hacer el sistema. Es decir, tratamos de identificar primero los casos de uso principales, dejando de lado las inclusiones y extensiones (estos últimos ya introducen una sutil idea del cómo).

Para identificarlos es útil suponer que alguien ajeno al proyecto y sin conocimientos de programación o diseño de sistemas nos pregunta “¿y que va a hacer el sistema?”, la mayoría de tus respuestas serán posiblemente casos de usos concretos (principales). Por ejemplo, si estás desarrollando un sistema de venta de pasajes y te hacen la pregunta, tus respuestas podrían ser:
“El sistema tiene que permitir reservar un pasaje, chequear disponibilidad para una determinada fecha, realizar la venta del pasaje, permitir devoluciones con una determinada fecha de anticipación, conocer los horarios de partida y destinos, etc.”
De esta forma se han identificado los casos de uso principales:
• Reservar pasaje.
• Chequear disponibilidad.
• Cobrar pasaje.
• Consultar viajes.  que incluiría la información de destinos, horarios, precios, etc.
• Etc.

Es muy útil para este proceso de identificación de los casos de usos concretos, realizar junto al equipo del proyecto (en especial aquellos que conocen los requerimientos del usuario) un brainstorming o tormenta de ideas en cuyo centro se anotará la pregunta “¿Qué VA A HACER EL SISTEMA?”, cualquier sugerencia se anota sin tildarla como errónea, ya que después se hará una selección.