Procesos del Negocio a los Casos de Uso

De los Procesos del Negocio a los Casos de Uso1

Jesús García Molina, M. José Ortín, Begoña Moros, Joaquín Nicolás, Ambrosio Toval

Grupo de Investigación de Ingeniería del Software2

Departamento de Informática y Sistemas

Facultad de Informática. Universidad de Murcia

C.P. 30.071 Campus de Espinardo, Murcia, Spain

{jmolina, mjortin, bmoros, jnr, atoval}@um.es

Resumen.En este trabajo se presenta una estrategia para obtener de modo sistemático el modelo de casos de uso y el modelo conceptual, a partir del modelado del negocio basado en diagramas de actividades UML. Después de determinar los procesos del negocio de la organización bajo estudio, y de describir

sus flujos de trabajo mediante diagramas de actividad, los casos de uso son

identificados y estructurados a partir de las actividades de cada proceso, mientras que los conceptos que aparecen en el modelo conceptual se obtienen a partir de los datos que fluyen entre las actividades. Además, las reglas del negocio

son identificadas e incluidas en un glosario, como parte de la especificación de

datos y actividades. Un aspecto destacable de nuestra propuesta es el hecho de

que el modelado conceptual y el de casos de uso se realiza en paralelo, haciendo más fácil la identificación y especificación de casos de uso adecuados. Tanto

el modelado de casos de uso como el modelado conceptual forman parte de la

fase de análisis de requisitos de un modelo de proceso completo en cuya definición estamos trabajando. Este proceso está siendo experimentando en un organismo de tamaño medio de la Administración Autonómica.

1 Introducción

Desde que UML [1] fue adoptado por el OMG como el lenguaje estándar para el

modelado, se ha definido un buen número de modelos de proceso para el desarrollo de

aplicaciones orientadas a objetos (OO), que utilizan este lenguaje como medio de

expresión de los diferentes modelos que se crean durante el desarrollo. Estas propuestas suelen estar dirigidas por los casos de uso, de manera que éstos se emplean

para definir los requisitos funcionales del sistema, y todas las etapas del proceso (planificación de las iteraciones, análisis, diseño y pruebas) se articulan en torno a los

casos de uso identificados.

Actualmente, en muchas discusiones sobre casos de uso se coincide en señalar que

con frecuencia son mal interpretados, y que no hay guías precisas para resolver los

aspectos que tienen que ver con su organización. En este sentido, se han publicado

diferentes propuestas (por ejemplo [3, 7, 8]) en las que se discuten cuestiones tales

––––––––––

1

Parcialmente subvencionado por la CICYT, Ministerio de Educación y Ministerio de Industria. Proyecto de investigación MENHIR-OM TIC97-0593-C05-02.

2

Miembro de RENOIR (European Requirements Engineering Network of Excellence).

como la granularidad de los casos de uso, el nivel de detalle en que deben describirse,

o la conveniencia de crear una jerarquía de casos de uso.

Inspirados en la arquitectura de tres modelos de OOram [13] y en el método IDEA

[2], estamos definiendo un proceso basado en UML orientado a sistemas de información de gestión. Este proceso incluye una fase de modelado del negocio, que describe

los procesos del negocio de la organización bajo estudio de manera que se puedan

construir, de forma sencilla y directa, versiones iniciales de los modelos conceptual y

de casos de uso. Cada proceso del negocio se describe haciendo uso de un diagrama

de actividades UML con calles (swimlanes). Posteriormente, se identifican los casos

de uso del sistema a partir de las actividades y los conceptos(clases del dominio) a

partir de los datos (objetos de información que fluyen entre las actividades).

En este trabajo describimos nuestra propuesta para realizar el modelado del negocio y su conexión con el análisis de requisitos (modelos conceptual y de casos de

uso). Esta propuesta ha sido experimentada en el marco de un proyecto cuyo objetivo

ha sido proporcionar un modelo de proceso, basado en requisitos, para el desarrollo de

sistemas de información de gestión con uso intensivo de datos [10]. El ámbito de este

trabajo ha sido la DGSIC (Dirección General de Servicios de Información y de las

Comunicaciones) de la CARM (Comunidad Autónoma de la Región de Murcia).

Este trabajo está estructurado de la siguiente manera: en el apartado 2 comentamos

someramente la problemática asociada a la utilización del concepto de caso de uso, y

ofrecemos una visión general de nuestra propuesta; en el apartado 3 presentamos la

manera de abordar el modelado del negocio; en el apartado 4 mostramos cómo realizar la transición desde el modelo del negocio a los modelos de casos de uso y conceptual; finalmente, en la sección 5 exponemos nuestras conclusiones.

2 Motivación

2.1 Problemas en la Utilización de los Casos de Uso

Actualmente, la mayor parte de los modelos de proceso propuestos para UML se

definen como dirigidos por los casos de uso. Un caso de uso puede ser definido como

una secuencia de acciones, incluyendo variaciones, que el sistema puede ejecutar y

que produce un resultado observable de valor para un actor que interactúa con el

sistema[1]. Aunque el éxito de los casos de uso se suele justificar con el hecho de que

constituyen una técnica simple e intuitiva, algunos autores (ver por ejemplo [3, 7, 8])

señalan las dificultades que entraña la obtención y la especificación de casos de uso

verdaderamente útiles, y la falta de consenso sobre cómo organizarlos y manejarlos.

Estas son las razones que nos llevan a pensar que es necesario establecer un conjunto

de guías para la identificación, descripción y organización de los casos de uso.

Algunas discusiones interesantes acerca del manejo de casos de uso son las proporcionadas por T. Korson y A. Cockburn. Korson [7] defiende que los requisitos (y por

tanto los casos de uso) han de ser organizados jerárquicamente, y establece que i)

cada nivel de casos de uso no debe añadir nuevos requisitos, sino refinar los del nivel

superior, y ii) la jerarquía de casos de uso no debe ser el resultado de una descomposición funcional, y ha de ser desarrollada de manera iterativa e incremental.

Por otro lado, Cockburn [3] utiliza el concepto de objetivo (goal) para organizar jerárquicamente los casos de uso. Distingue básicamente entre objetivos estratégicos

(los

...