Desarrollo De Casos De Usos

De los Procesos del Negocio a los Casos de Uso 1

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

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

Grupo de Investigación de Ingeniería del Software 2

Departamento de Informática y Sistemas

Facultad de Informática. Universidad de Murcia

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

Palabras Clave: Sistemas de Información, modelo de casos de uso, análisis de requisitos, UML

Towards Use Case and Conceptual Modelsthrough Business Modeling

Abstract

A guide to requirements modeling is presented in this paper, in which use cases and the conceptual model are directly obtained from a business modeling based on UML activity diagrams. After determining the business processes of the organization, and describing their workflows by means of activity diagrams, use cases are elicited and structured starting from the activities of each process, while the concepts of the conceptual model are obtained from the data that flow between activities. Furthermore, business rules are identified and included in a glossary, as part of the data and activities specification. One notable aspect of our proposal is that use case and conceptual modeling are performed at the same time, thus making the identification and specification of suitable usecases easier. Both use case and conceptual modeling belong to the requirements analysis phase, which is part of a complete process model on whose definition we are currently working. This process is being experimented in a medium sized organism of a Regional Public Administration.

Key-words: Information sistems, use cases model, requirements analysis, UML

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 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 procesos del negocio de la organización) y objetivos de usuario (las funciones del sistema). Los objetivos estratégicos se corresponden con un conjunto de objetivos de usuario y, de igual modo, un objetivo de usuario puede ser descompuesto, a su vez, en un conjunto de objetivos de usuario. Aparece, por tanto, el concepto de objetivo compuesto, que corresponde bien a un conjunto de objetivos de usuario, o bien a un objetivo estratégico.

Otra cuestión importante es la ubicación del modelado de casos de uso dentro del modelo de proceso. Normalmente se concibe el modelado de casos de uso como un paso previo al modelado conceptual. Sin embargo, Korson [8] argumenta que no es posible crear casos de uso adecuados y útiles (ni implementarlos correctamente) sin comprender el dominio, y por tanto, el modelado de casos de uso y el modelado conceptual deben ser actividades realizadas en paralelo.

2.2 Nuestra Propuesta

Normalmente, los casos de uso son elicitados de forma intuitiva a partir de la especificación del sistema y, posteriormente, las entidades del modelo conceptual se extraen a partir de las especificaciones de los casos de uso. En las siguientes secciones presentamos una propuesta para obtener de forma sistemática tanto el modelo de casos de uso como el modelo conceptual, a partir de un modelo del negocio, de acuerdo con el esquema mostrado en la Fig.1.

Fig. 1. Relaciones de trazabilidad entre los modelos de negocio y de requisitos

Inspirados en la Arquitectura de Tres Modelos de OOram [12, 13], el modelado del negocio se realiza mediante diagramas de actividades UML. Una vez determinados los procesos de negocio de la organización, y descritos sus flujos de trabajo mediante diagramas de actividades, los casos de uso se elicitan y estructuran a partir de las actividades de cada proceso, mientras que las entidades del modelo conceptual se obtienen de los datos que fluyen entre tales actividades. Además, se identifican las reglas del negocio y se incluyen en un glosario como parte de la especificación de los datos y las actividades. Un aspecto notable de nuestra propuesta es que el modelado de casos de uso y el modelado conceptual se realizan al mismo tiempo, haciendo

...