UML - UML: Casos de uso en sistemas algorítmicos?

Hola a todos! Me encuentro realizando la documentación de mi proyecto de final de carrera y me ha surgido una duda en la cual me gustaría que me dieseis vuestra opinión.

Resulta que el sistema que estoy desarrollando es totalmente algorítmico, es decir, se lanza el programa y te devuelve una serie de resultados. Estoy siguiendo el proceso unificado (UP) junto a UML para la elaboración del documento y me planteo lo siguiente: ¿Es necesario realizar un modelo de casos de uso en un sistema algorítmico?

Solo habría un único actor (quien lanza la aplicación) y un caso de uso general (la obtención de resultados). Por una parte no le veo mucho sentido, pero también se podría desmenuzar ese caso de uso general y especificar algunos de los "subsistemas" que intervienen en el sistema general.

¿Qué pensáis?

Gracias de antemano.

Hola,

como no conozco los detalles de tu proyecto te comentaré lo que creo puede darte una idea para encontrar la mejor solución.

1º - Aunque en tu sistema no parece ser necesario, puede ser conveniente para delimitar el ámbito del sistema un caso de uso que exprese la acción principal y el usuario aplicación del que hablas. Gráficamente yo lo definiría como un paquete con el nombre de tu sistema y en su interior el CU. Exterior al paquete estaría el usuario (la aplicación con la que interactua). La especificación sería muy simple:

El CU comienza cuando el actor solicita su ejecución (es un ejemplo):
- El actor ejecuta la acción x proporcionandole los parámentros.
- El sistema procesa los datos y obtiene los resultados que devuelve al actor.
- Fin del CU.

Todo esto sería introductorio y a muy alto nivel. No creo que necesites más.

2º - No sé como de complejo es internamente tu sistema para realizar una división en subsistemas, pero eso es una decisión más de diseño que de lo que aqui se está tratando.

Un caso de uso no se puede dividir en subsistemas.

Un sistema puede ser necesario dividirlo en subsistemas según funcionalidad para facilitar su análisis, diseño y posterior desarrollo. Si durante la toma de requisitos, o el análisis posterior se detectan funcionalidades comunes a varios subsistemas expresadas en un caso de uso, éste puede ser usado, por los casos de uso de los demás subsistemas. Pero esto suele ocurrir a posteriori, p.e. el típico diálogo entre usuario y sistema para preparar la impresión de un documento, no depende del tipo de documento y siempre son los mismos pasos. Observa que la relación es entre casos de uso.

Y recuerda que el análisis y diseño de un sistema no son sólo casos de uso.
- Documento de requisitos no funcionales.
- Documento de definición de la interfaz.
- Documento de casos de pruebas.
...

Por favor, no querais meterlo todo en los CUs como he visto por ahí a algún que otro analista.

Espero que esto ayude,
Vicente.

Gracias Vicente por tomarte la molestia de contestar. Como dices en tu última línea, por supuesto que no he intentado meter todo en casos de uso, es más de momento los estaba ignorando y he empezado a construir todo el modelo de análisis y de diseño a partir de mi modelo de Requisitos (Requisitos funcionales + no funcionales).

Precisamente quería ver si era necesario añadir un caso de uso como el que comentas en tu primer punto. Pensaba que podría ser mejor obviarlo y comentar en la documentación del proyecto que solo me baso en el modelo de requisitos, pero bueno, como comentas puede ser buena idea incluir ese único modelo.

En cuanto a los subsistemas si que he dividido mi sistema en varios de estos, y la verdad que me ha servido de mucho. He estado siguiendo el libro "Programación UML2" para realizar todo el proceso del proyecto, y la verdad que me he enamorado del UP (Unified Process) y UML2.

En fin, muchas gracias y espero que esto sirva de ayuda a gente con la misma duda que yo.