Introducción a los casos de uso

Ya hemos realizado una entrevista al director de la empresa Canteras S.L y tenemos un nuestro poder un documento que especifíca los requisitos funcionales que debe tener el sistema software que desarrollemos.

Casos de uso

Una buena manera de comprender los requerimientos es creando casos de uso.

Un caso de uso es un documento narrativo que describe el comportamiento de un sistema desde el punto de vista de un actor. El actor es una entidad externa del sistema que participa en el caso de uso, suelen ser seres humanos o cualquier tipo de sistema.

Para entenderlo mejor vamos a poner un ejemplo. En nuestro caso de estudio podemos identificar a partir de los requerimientos el caso de uso Registrar empresa y el actor Usuario que es el que registrará la empresa en el sistema mediante una interfaz gráfica.

Un error común es identificar las operaciones o transacciones individuales como casos de uso. Un ejemplo de esto en nuestro caso de estudio es identificar la operación de comprobar si la empresa está registrada en la cantera como un caso de uso. Esa operación forma parte del caso de uso Registrar empresa, pero no es un caso de uso en sí.

Los casos de uso son descripciones amplias de un proceso de negocios, esta descripción abarca muchos pasos o transacciones.

Podemos identificar los casos de uso de nuestro sistema software a partir de los actores. Para ello primero identificamos a los actores y para cada actor vemos los procesos de negocios que inicia o en los que participa.

Diagramas de casos de uso

UML no especifica un formato para describir casos de uso. UML utiliza diagramas de casos de uso para explicar gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre estos y los casos de usos.

Formatos de casos de uso

Narrativamente podemos escribir un caso de uso en diferentes formatos y con diferentes niveles de detalle:

- Formato de alto nivel: Un caso de uso de alto nivel describe un proceso de negocios del sistema muy brevemente. Utilizamos este tipo de formato durante el examen inicial de los requerimientos para entender rapidamente la funcionalidad del sistema.

Una muestra de un caso de alto nivel:

Caso de uso: Registrar empresa
Actores:  Usuario
Tipo: Primario
Descripción: El usuario registra una empresa en el sistema rellenando los datos de la empresa. El sistema comprueba si la empresa existe. Sino existe registra la empresa en el sistema.

- Formato expandido: Un caso de uso expandido describe un proceso de negocios más a fondo que el de alto nivel. Durante la fase del análisis conviene escribir en este formato solo los casos más importantes.

Una muestra de dos casos expandidos:

Caso de uso: Registrar empresa
Actores:  Usuario
Propósito: Registrar una empresa en el sistema.
Tipo: Primario
Descripción: El usuario registra una empresa en el sistema rellenando los datos de la empresa. El sistema comprueba si la empresa existe.  Sino existe registra la empresa en el sistema.
Curso normal de los eventos:
1.El usuario introduce los datos de la empresa que quiere registrar.
2.El sistema busca entre las empresas registradas si existe una empresa con el mismo identificador.
3.El sistema informa al usuario que la empresa se ha registrado satisfactoriamente.
Cursos alternos:
Línea 3: El sistema informa al usuario que ya existe una empresa con el mismo identificador registrada en el sistema.

Caso de uso: Registrar vehículo
Actores:  Usuario
Propósito: Registrar un vehículo en el sistema.
Tipo: Primario
Descripción: El usuario registra un vehículo a una empresa en el sistema rellenando los datos del vehiculo. El sistema comprueba si el vehiculo existe.  Sino existe registra el vehiculo en el sistema.
Curso normal de los eventos:
1.El usuario introduce los datos del vehículo que quiere registrar.
2.El sistema muestra una lista de empresas registradas en el sistema
3.El usuario selecciona una empresa.
4.El sistema busca la empresa seleccionada y muestra los datos de la empresa.
5.El sistema busca en los vehiculos registrados si el vehiculo ya esta registrado en el sistema.
6.El sistema registra el vehiculo en la empresa y muestra un mensaje satisfactorio al usuario.
Cursos alternos:
Línea 6: El sistema no registra el vehiculo y muestra un mensaje informando al usuario que el vehiculo ya está registrado.

Caso esenciales de uso y casos reales de uso

Los casos esenciales de uso son casos que se expresan de forma muy abstracta, sin detalles de implementación. Los detalles de diseño se dejan para la etapa del diseño.

En la etapa del diseño veremos los casos reales de uso. Estos casos de uso describen concretamente el proceso de negocios con detalles de diseño y sujeto a tecnologías de entrada y salida, como por ejemplo la interfaz gráfica.

Casos de uso dentro de un proceso de desarrollo

En la fase de planificación y especificación de requerimientos (en la que estamos ahora) después de haber definido los requerimientos del sistema software estamos preparados para identificar los casos de uso.

1. Identificamos los actores y los casos de uso.
2. Escribimos los casos de uso en el formato de alto nivel.
3. Relacionamos los casos de uso.
4. Dibujamos un diagrama de casos de uso.
5. Escribimos en el formato expandido los casos de uso más importantes.

En la fase de análisis escribimos los casos esenciales de uso en formato expandido para los que todavía no lo hemos hecho.

En la fase de diseño escribimos los casos reales de uso a partir de los casos esenciales de uso de la fase del análisis.

RESUMEN

Ya hemos visto la teoría de los casos de estudio y ya estamos preparados para identificar los casos de uso de nuestro caso de estudio y de dibujar un diagrama de casos de uso que muestre las relaciones de los actores y los casos de uso de nuestro caso de estudio.

Caso de estudio: Simulador de una cantera

El caso de estudio que vamos a tratar es un sistema simulador de una cantera. La empresa Canteras S.L (empresa totalmente ficticia) nos ha contratado para que le realizemos un sistema software que le permita integrar y sistematizar un conjunto de tareas que se llevan a cabo en su cantera.

Así que concertamos una entrevista para que el director de la empresa nos hable en persona un poco de como funciona su cantera y que funcionalidades debe incluir el sistema software que desarrollemos.

Nuestro analista, Francisco Belmonte va a ser el encargado de realizarle una entrevista para poder desarrollar una especificación de requerimientos que sirva como base para comenzar el proceso de análisis.

ENTREVISTA

Analista:
- Cuentéme un poco sobre su negocio.

Director:
- Bueno, somos una empresa que lleva más de 100 años en activo. Nos dedicamos a la explotación minera. Tenemos una cantera de donde extraemos piedra, greda y otros tipos de áridos. Estos áridos tienen distintas aplicaciones en la construcción ya sea para construir carreteras, paredes, hormigón, o en la industria para fabricar cemento, vidrio o acero.

Analista:
-Veo que el negocio ha funcionado muy bien ya que lleva activo mucho tiempo.

Director:
- Sí, la verdad es que funciona bastante bien, pero lo malo es que seguimos funcionando igual que hace 100 años cuando no existían sistemas que pudieran automatizarnos tareas. Cogemos cada día todas las solicitudes de las empresas que nos llaman y programamos explosiones para sacar los áridos en función a las toneladas que nos demandan. Lo que queremos es un sistema que permita automatizar todo este proceso.

Analista:
- Bueno, vayamos por partes. Por lo que he entendido para extraer áridos primero hay que programar una serie de explosiones. ¿Cuántas explosiones realizais al día?

Director:
- En la cantera cada día se suelen programar mínimo dos explosiones controladas de pólvora para extraer los áridos demandados. Una se programa a las 06:00 y se ejecuta a las 08:00. La otra se programa a la 13:00 para ser ejecutada a las 15:00.

Analista:
- ¿Que son los áridos demandados?

Director:
- Pues las empresas que tenemos registradas en la cantera pueden llamarnos por teléfono para solicitar una cantidad de toneladas de áridos.

Analista:
- Entonces, las empresas os llaman, os solicitan una cantidad de áridos y programais una explosión para extraer los áridos demandados. ¿Qué haceis con esos áridos cuando se han extraído?

Director:
- Le explico para que no se pierda. Nosotros no tenemos un servicio de entrega de áridos, así que las empresas que nos solicitan los áridos tienen que entrar dentro de la cantera con un vehículo que pueda cargar la cantidad de áridos seleccionados. Otra cosa, nosotros no programamos una explosión por cada solicitud, lo que hacemos es calcular las toneladas totales de todas las solicitudes que quieren cargar y programamos una explosión de cierta categoría para poder extraer los áridos.

Analista:
- ¿Que significa eso de explosión de cierta categoría?

Director:
- Clasificamos las explosiones que se pueden producir en cuatro categorías. Las explosiones de nivel uno permiten extraer 50 toneladas de áridos, las de nivel dos permiten extraer 30 toneladas de áridos, las explosiones de nivel tres permiten extraer 15 toneladas, y la de nivel 4 permite extraer 5 toneladas.

Analista:
- A ver si lo he entendido, calculais el total de toneladas y programais una explosión de una categoría que pueda cubrir los áridos demandados.

Director:
- Exacto, con una condición. Si la demanda de áridos es suficiente programamos las explosiones de menor nivel.

Analista:
- ¿Y qué pasa cuando las toneladas totales de áridos sobrepasa las 50 toneladas?

Director:
- En ese caso, programamos más de una explosión si quedan cuadrantes activos para explosionar.

Analista:
- ¿Qué es eso de cuadrantes activos para explosionar?

Director:
- Nuestra cantera está dividida en 4 secciones consecutivas: A,B,C y D, las cuales delimitan horizontalmente la superficie de la cantera. Verticalmente la cantera se delimita en filas: 1,2,3,4 y 5. Cada explosión se ejecuta en una sección y una fila determinada, es lo que se conoce como cuadrante.

Analista:
- Vale, vamos a hacer un pequeño resumen de lo visto hasta ahora. La cantera cuenta con una serie de cuadrantes donde realizais explosiones para extraer áridos. Esos áridos que extraeis os los demandan las empresas que tienen vehículos que pueden entrar en la cantera a cargar. Programais dos explosiones al día o más si hace falta de distintas categorías. Las explosiones de las 08:00 tienen en cuenta aquellas solicitudes que quieran cargar hasta las 15:00. Y las explosiones de las 15:00 tienen en cuenta las solicitudes que quieren cargar de 15:00 a 24:00. ¿No es así? ¿Se me pasa algo por alto?

Director:
- Es una buena forma de resumirlo. Tambien tiene que tener en cuenta que los clientes físicos pueden entrar en la cantera a cargar también.

Analista:
-¿No es lo mismo una empresa que un cliente físico?

Director:
- No. Hacemos distinción. Las empresas pueden solicitar áridos por teléfono. Los clientes físicos no pueden solicitar áridos, pero pueden entrar a la cantera a extraer áridos siempre que sobren.

Analista:
- Entendido. Ya hemos visto como funciona de forma general la cantera. ¿Qué funcionalidades desea que tenga el sistema que quiere que desarrollemos?

Director:
- Les he preparado un documento que especifica todas las funcionalidades que quiero que tenga el sistema software.

El director le acerca el documento a nuestro analista Francisco, que le echa un vistazo y lee lo siguiente:

ESPECIFICACIÓN DE REQUERIMIENTOS

El sistema software debe gestionar las siguientes tareas:

- Registro de Clientes (Empresas y Personas Físicas). De cada cliente se debe registrar su nombre y dirección. En el caso de las empresas también su CIF y teléfono. Para las personas físicas se registrará el DNI.

- Registro de Solicitudes. De cada solicitud se registrará: fecha, hora, cantidad toneladas solicitada y empresa cliente. Es necesario controlar el estado de la solicitud (en trámite, ejecutada, o desestimada).

- Registro de Entrada y Salida de Vehículos. Las cargas que se realicen en el sistema deberán quedar registradas, para ello es necesario identificar: matrícula del vehículo, fecha de entrada, hora de entrada, nombre conductor, fecha salida, hora salida, toneladas cargadas.

- Programación de Explosiones. Cada día a las 6:00 y a la 13:00 se programará una explosión. Los requisitos para programar las explosiones son:
1. El nivel y número de explosiones se determinará en función de la demanda de áridos. Para ello se deberá tener en cuenta las solicitudes en trámite que tiene la cantera.
2. La ubicación de la explosión se realizará teniendo en cuenta que es necesario ir rotando por los distintos cuadrantes.

- Facturación. El día 25 de cada mes se debe facturar a las empresas clientes las diferentes cargas que hayan realizado desde el día 25 del mes anterior.

- La interfaz gráfica debe mostrar el estado de todos los cuadrantes, así como los clientes registrados, las solicitudes, las cargas realizadas, los vehiculos registrados y las facturas facturadas.

FINAL DE  LA ENTREVISTA

Analista:
- Este documento nos servirá como especificación de los requerimientos funcionales del sistema que tenemos que desarrollarle. Iremos desarrollando diferentes versiones que vayan englobando funcionalidades, así podrá ir viendo que es lo que vamos creando.

Director:
- Pues muchas gracias por todo, Francisco. Un placer tratar con usted.

El analista se marcha. Reúne a su equipo de desarrollo y le explica como ha ido la entrevista, les entrega una copia de la documentación que les ha proporcionado el director de Canteras S.L y juntos comienzan el proceso de análisis.

Análisis y diseño orientado a objetos con UML siguiendo un caso de estudio. (II)

Creamos sistemas software para hacer frente a un problema de negocios que queremos solucionar. Lo que no podemos hacer es comenzar a escribir código sin tener una idea del sistema en general, eso está bien cuando el sistema es pequeño o cuando empezamos a aprender a programar pequeños ejercicos como una calculadora. Pero cuando queremos construir un sistema de tamaño mediano o grande necesitamos seguir un proceso de desarrollo. Existe una diversidad de modelos diferentes de procesos de desarrollo que podemos utilizar (RUP, programación extrema, etc). En este curso no vamos a dar mucha importancia al proceso de desarrollo porque lo que pretendo es aprender a realizar buenos análisis y diseños desde la perspectiva de los objetos independiente del proceso de desarrollo que sigamos.

La mayoría de procesos de desarrollo tiene una serie de actividades en común, dos de ellas son el análisis y el diseño.

El análisis se centra en la investigación del problema que queremos solucionar, no en la manera de definir una solución. La actividad principal del análisis es identificar los objetos dentro del dominio del problema al que nos enfrentamos.

El diseño refina y extiende los modelos desarrollados en el análisis para generar una especificación orientada a la solución del sistema software.

Como bien dice el libro de Craig Larman, la división entre el análisis y el diseño es poco clara. Cuando empezé estudiando este mundillo tenía la necesidad de saber diferenciar bien que pasos equivalían al análisis y que pasos al diseño, esto me llevaba a veces a no comprender bien los conceptos. Podemos ver las dos actividades como un continuo donde el análisis responde a la pregunta ¿qué es lo que queremos hacer? y el diseño a la pregunta ¿cómo lo vamos a hacer?

Vamos a utilizar UML para visualizar los diferentes modelos o artefactos que vamos a ir desarrollando para documentar nuestro caso de estudio. UML es un lenguaje gráfico que utilizamos para construir los modelos de nuestro sistema software. Cuenta con un conjunto de diagramas que iremos viendo cuando los vayamos necesitando.

El proceso de desarrollo va a ser como el del libro, uno iterativo dirigido por los casos de usos, muy similar al Proceso Unificado de Rational. Pero en este caso vamos a ir haciedo versiones cada vez con mayor funcionalidad debido al tamaño del caso de estudio que vamos a realizar. Sobre la marcha iremos definiendo los diferentes incrementos que vayamos realizando. Eso sí, el modelo conceptual del dominio lo vamos a ver completo desde el primer incremento.

Realmente podíamos haber elegido un proceso de desarrollo en cascada, porque en el caso de estudio que ahora veremos tenemos claramente los requerimientos y sabemos que no van a cambiar.

En el siguiente artículo os pondré la especificación de requerimientos y os explicaré un poco el caso de estudio que vamos a crear, en concreto, un simulador de una cantera de minerales, piedras y esas cosas.

Análisis y diseño orientado a objetos con UML siguiendo un caso de estudio.

Este va a ser uno de los proyectos más ambiciosos de este blog. Voy a tratar de redactar una serie de artículos que expliquen métodos y técnicas utilizadas en el análisis y diseño de sistemas software orientados a objetos utilizando un caso de estudio. La idea de realizar este proyecto surgió cuando estaba releyendo el libro UML y patrones de Craig Larman donde el autor utiliza un caso de estudio para explicar buenas prácticas de análisis y diseño orientado a objetos. El caso de estudio en cuestión es un sistema de punto de ventas utilizado en muchas tiendas. El autor mediante este caso de estudio planifica un proceso de desarrollo iterativo basado en los casos de uso y explica el papel de UML en las etapas de análisis y desarrollo comunes a casi todos los procesos de desarrollo. Además introduce el uso de patrones GRASP para asignar responsabilidades a los objetos, así como el uso de otros patrones de diseño incluidos en el libro de los 23 patrones de diseño que he recomendado antes.

UML es un lenguaje gráfico para construir modelos, no guía al desarrollador en la forma de realizar buenos análisis y diseños, ni le indica cual proceso de desarrollo adoptar. La idea de esta serie de artículos va más allá de aprender la notación UML utilizada para diseñar y construir sistemas software orientados a objetos de buena calidad independiente del proceso de desarrollo utilizado. Guiará al desarrollador principiante como yo a realizar buenos análisis y diseños orientados a objetos utilizando patrones de diseño.

El caso de estudio que vamos a tratar es el simulador de la cantera que he diseñado para las prácticas de la asignatura Ingeniería del software de la universidad. Voy a intentar realizarlo todo más o menos siguiendo la temática del libro UML y patrones de Craig Larman. De esta forma me sirve a mí mismo para mejorar la implementación y el diseño que realizé y afirmar todo lo aprendido. Como soy un novato principiante en este mundillo, si algún lector sigue mis artículos y encuentra alguna burrada sería recomendable que me avisara para rectificarlo. De todas formas este curso va a seguir una bibliografía recomendada así que me voy a basar en principios reales y no inventar conceptos nuevos.

En este curso, aprenderemos a crear modelos conceptuales del dominio del problema al que nos enfrentamos y a representarlos mediante diagramas de clases en UML.  Aprenderemos a extraer los casos de usos funcionales a partir de la especificación de requerimientos del sistema que vamos a desarrollar y a representarlos mediante diagramas de casos de uso en UML. Aprenderemos a realizar diagramas de secuencia, de colaboración y de estado en UML. Paralelamente a este curso voy a intentar redactar otros artículos dedicados exclusivamente a los patrones de diseño, esta vez sin seguir un caso de uso, sino a partir de ejemplos donde podamos aplicarlos.

Este proyecto puede durar mucho tiempo, debido a que paralelamente estoy redactando otros cursillos de PHP, y MySQL que incorporar al blog. Además en unas semanas empiezo a trabajar diseñando una aplicación de gestión inmobiliaria, así que no voy a tener mucho tiempo libre.

En breves os explicaré el caso de estudio y realizaremos una especificación de funcionalidades que incorporar a nuestro sistema software. La implementación la desarrollaremos en el lenguaje C#. Para este curso voy a presuponer que se tienen ciertos conocimientos de la metodología orientada a objetos, así como del lenguaje C# y de construcción de aplicaciones mediante formularios windows. No va a tener acceso a base de datos para simplificar un poco el desarrollo. Ya explicaré el sistema que realizaremos para cargar y guardar datos.

Hasta la próxima.