De los Procesos del Negocio a los Casos de Uso

Jess Garca Molina, M. Jos Ortn, Begoa Moros, Joaqun Nicols, Ambrosio Toval jmolina@um.es, mjortin@um.es, bmoros@um.es, jnr@um.es, atoval@um.es

Grupo de Investigacin de Ingeniera del Software 2 Departamento de Informtica y Sistemas Facultad de Informtica. Universidad de Murcia

Resumen
En este trabajo se presenta una estrategia para obtener de modo sistemtico el modelo de casos de uso y el modelo conceptual, a partir del modelado del negocio basado en diagramas de actividades UML. Despus de determinar los procesos del negocio de la organizacin 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. Adems, las reglas del negocio son identificadas e incluidas en un glosario, como parte de la especificacin 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 ms fcil la identificacin y especificacin de casos de uso adecuados. Tanto el modelado de casos de uso como el modelado conceptual forman parte de la fase de anlisis de requisitos de un modelo de proceso completo en cuya definicin estamos trabajando. Este proceso est siendo experimentando en un organismo de tamao medio de la Administracin Autonmica.

Palabras Clave:

Sistemas de Informacin, modelo de casos de uso, anlisis 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.

Keywords:

Information sistems, use cases model, requirements analysis, UML

1 Introduccin
Desde que UML [1] fue adoptado por el OMG como el lenguaje estndar para el modelado, se ha definido un buen nmero de modelos de proceso para el desarrollo de aplicaciones orientadas a objetos (OO), que utilizan este lenguaje como medio de expresin 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 (planificacin de las iteraciones, anlisis, diseo y pruebas) se articulan en torno a los casos de uso identificados. Actualmente, en muchas discusiones sobre casos de uso se coincide en sealar que con frecuencia son mal interpretados, y que no hay guas precisas para resolver los aspectos que tienen que ver con su organizacin. 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 jerarqua de casos de uso. Inspirados en la arquitectura de tres modelos de OOram [13] y en el mtodo IDEA[2], estamos definiendo un proceso basado en UML orientado a sistemas de informacin de gestin. Este proceso incluye una fase de modelado del negocio, que describe los procesos del negocio de la organizacin 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 informacin que fluyen entre las actividades ). En este trabajo describimos nuestra propuesta para realizar el modelado del negocio y su conexin con el anlisis 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 informacin de gestin con uso intensivo de datos [10]. El mbito de este trabajo ha sido la DGSIC (Direccin General de Servicios de Informacin y de las Comunicaciones) de la CARM (Comunidad Autnoma de la Regin de Murcia). Este trabajo est estructurado de la siguiente manera: en el apartado 2 comentamos someramente la problemtica asociada a la utilizacin del concepto de caso de uso, y ofrecemos una visin general de nuestra propuesta; en el apartado 3 presentamos la manera de abordar el modelado del negocio; en el apartado 4 mostramos cmo realizar la transicin desde el modelo del negocio a los modelos de casos de uso y conceptual; finalmente, en la seccin 5 exponemos nuestras conclusiones.

2 Motivacin
2.1 Problemas en la Utilizacin 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 interacta con el sistema [1]. Aunque el xito de los casos de uso se suele justificar con el hecho de que constituyen una tcnica simple e intuitiva, algunos autores (ver por ejemplo [3, 7, 8]) sealan las dificultades que entraa la obtencin y la especificacin de casos de uso verdaderamente tiles, y la falta de consenso sobre cmo organizarlos y manejarlos. Estas son las razones que nos llevan a pensar que es necesario establecer un conjunto de guas para la identificacin, descripcin y organizacin 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 jerrquicamente, y establece que i) cada nivel de casos de uso no debe aadir nuevos requisitos, sino refinar los del nivel superior, y ii) la jerarqua de casos de uso no debe ser el resultado de una descomposicin funcional, y ha de ser desarrollada de manera iterativa e incremental. Por otro lado, Cockburn [3] utiliza el concepto de objetivo (goal) para organizar jerrquicamente los casos de uso. Distingue bsicamente entre objetivos estratgicos (los procesos del negocio de la organizacin) y objetivos de usuario (las funciones del sistema). Los objetivos estratgicos 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 estratgico. Otra cuestin importante es la ubicacin 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 especificacin 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 sistemtica 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 organizacin, 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. Adems, se identifican las reglas del negocio y se incluyen en un glosario como parte de la especificacin 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 ms fcil, por tanto, la identificacin y especificacin de los casos de uso adecuados.

3 Modelado del Negocio

Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una coleccin de datos que son producidos y manipulados mediante un conjunto de tareas, en lasque ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo determinado. Adems, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan las polticas y la estructura de la informacin de la empresa. Por tanto, la finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de negocio. El primer paso del modelado del negocio consiste en capturar los procesos de negocio de la organizacin bajo estudio. La definicin del conjunto de procesos del negocio es una tarea crucial, ya que define los lmites del proceso de modelado posterior. De acuerdo con el concepto de objetivo estratgico de Cockburn [3], capturamos los procesos del negocio a partir de los objetivos principales de la empresa. En primer lugar, consideramos los objetivos estratgicos de la organizacin. Teniendo en cuenta que estos objetivos van a ser muy complejos y de un nivel de abstraccin muy alto, sern descompuestos en un conjunto de subobjetivos ms concretos, que debern cumplirse para conseguir el objetivo estratgico. Estos subobjetivos pueden a su vez ser descompuestos en otros, de manera que se defina una jerarqua de objetivos. En nuestro estudio, hemos experimentado que dos o tres niveles de descomposicin son suficientes. Para cada uno de estos subobjetivos de segundo nivel definimos un proceso de negocio que deber dar soporte a dicho subobjetivo. Representamos cada proceso del negocio como un caso de uso del negocio, que inicialmente ser descrito deforma textual. En el resto del trabajo, ilustramos el proceso mediante el ejemplo de una compaa que fabrica productos bajo demanda (siguiendo un esquema just in time). Los objetivos estratgicos de dicha compaa podran incluir Satisfacer un pedido de un cliente, Incrementar en un 25% las ventas, o Disminuir el tiempo de fabricacin en un 15%.El objetivo Satisfacer un pedido de un cliente puede ser dividido en subobjetivos tales como: Registrar Pedido de Cliente, Fabricar Producto Pedido, Gestionar Almacn y Realizar Pedidos a Proveedores. stos sern los objetivos que utilizaremos para definir nuestros procesos del negocio. 3.1 Identificacin de Roles del Entorno del Negocio

Una vez se han identificado los procesos de negocio, es preciso encontrar los agentes involucrados en su realizacin. Cada uno de estos agentes o actores del negocio desempea cierto papel (juega un rol) cuando colabora con otros para llevar a cabo las actividades que conforman dicho caso de uso del negocio. De hecho, identificaremos los roles que son jugados por agentes de la propia empresa (que incluyen trabajadores, departamentos y dispositivos fsicos) o agentes externos (como clientes u otros sistemas). Por el momento nos centraremos en este ltimo tipo de roles, con los que la organizacin interacta para llevar a cabo sus procesos de negocio. En nuestro ejemplo tenemos los roles Cliente y Proveedor, claramente externos al sistema. Para tener una visin general de los diferentes procesos de negocio de la organizacin, puede construirse un diagrama de casos de uso del negocio, en el cual aparece cada proceso del negocio como un caso de uso. Este diagrama permite mostrar los lmites y el entorno de la organizacin bajo estudio. Slo se mostrarn en este diagrama los actores del negocio correspondientes a los roles externos al sistema, deforma que los procesos de negocio en los que slo tomen parte roles internos a la organizacin no estarn conectados a ningn actor. En la Fig. 2 se muestra el diagrama de casos de uso del negocio para nuestro ejemplo; es un diagrama de casos de uso UML formado por casos de uso del negocio y actores. En el diagrama se muestra adems que el agente Cliente arranca la realizacin del caso de uso relacionado, mientras que Proveedor simplemente participa en el caso de uso asociado.

Fig. 2. Diagrama de casos de uso del negocio para el sistema de produccin just in time

3.2 Descripcin de los Casos de Uso del Negocio El siguiente paso dentro del modelado del negocio es introducirse en cada uno de los casos de uso del negocio identificados, para describirlo en detalle. Nos centraremos en uno de los casos de uso del negocio de nuestro ejemplo, Registrar Pedido, cuya descripcin se muestra en la Fig. 3. Esta descripcin puede ser validada fcilmente por los usuarios. A continuacin, hemos de determinar los agentes internos que juegan un rol en cada caso de uso del negocio. Hasta el momento hemos identificado los roles que pertenecen al entorno

de la organizacin. Ahora es necesario estudiar la descripcin de cada caso de uso del negocio, y observar el conjunto completo de roles involucrados, tanto externos como internos a la organizacin. Los roles del caso del uso del negocio Registrar pedido son Cliente, Comercial, Jefe_Tcnico, y Jefe_Produccin (siendo los tres ltimos internos al sistema).

1. El cliente enva una orden de pedido, que debe incluir la fecha de solicitud, datos del cliente y productos solicitados. Es posible que sea un empleado del departamento comercial quien introduzca el pedido, a peticin de un cliente que realiz su pedido por telfono o lo envi por fax o correo ordinario al depto. comercial de la empresa. 2. El empleado revisa el pedido (completndolo, si es necesario), y comienza su procesamiento envindolo al jefe tcnico, que est encargado de su anlisis. 3. El jefe tcnico analiza la viabilidad de cada producto del pedido por separado: Si el producto pedido est en el catlogo, su fabricacin es aceptada. En caso contrario, es considerado un producto especial, y el jefe tcnico estudia su produccin: - Si es viable, la fabricacin del producto especial es aceptada; - Si no es viable, el producto especial no ser fabricado. 4. Una vez estudiado el pedido completo, el jefe tcnico... Informa al departamento comercial de la aceptacin o rechazo de cada producto pedido; Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo para cada producto, a partir de una plantilla de fabricacin (la estndar si el producto estaba catalogado, o una nueva, especfica-mente diseada para el producto, si ste no estaba en el catlogo). Cada orden de trabajo es enviada al jefe de produccin, y queda pendiente de su

lanzamiento. 5. El comercial comunica al cliente el resultado final del anlisis de su pedido.

Fig. 3. Descripcin del caso de uso del negocio Registrar pedido

El aspecto estructural de la colaboracin entre los roles para llevar a cabo un caso de uso del negocio, puede ser representado en un diagrama de roles, en el que cada rol (una clase UML estereotipada) aparece asociado con los roles con los que puede colaborar (ver Fig. 4). Por tanto, este diagrama permite expresar el conocimiento que unos roles tienen de otros, as como las caractersticas (como la multiplicidad) de cada relacin entre roles. Adems, este diagrama permite tambin mostrar las caractersticas de los roles identificados, tales como sus atributos y responsabilidades. Ortn y Garca Molina [11] discuten con ms detalle el modelado de roles con UML.

Fig. 4. Diagrama de roles para el caso de uso del negocio Registrar Pedido

Despus crearemos escenarios para mostrar el aspecto de comportamiento de la colaboracin. Para ello utilizaremos diagramas de secuencia UML (ver Fig. 5), en los que los objetos denotan las instancias de los roles que intervienen en la interaccin.

Fig. 5. Diagrama de secuencia para el caso de uso del negocio Registrar Pedido

En cada proceso podemos distinguir entre el flujo bsico o normal de la interaccin (en nuestro ejemplo, solicitud de un pedido que es aceptado) y los posibles flujos alternativos (por ejemplo, rechazo o

cancelacin de un pedido). Para mejorar la legibilidad, es conveniente asociar varios escenarios a un mismo caso de uso del negocio, en lugar de mostrar en una nica secuencia todas las posibilidades. En la arquitectura de tres modelos de OOram [13] se incluye un modelo del negocio representado mediante una vista proceso basada en el estndar IDEF0 [5], en la cual se muestra el flujo de trabajo a realizar para conseguir cierto objetivo de la organizacin, indicando qu roles realizan cada actividad y cules son los datos requeridos y producidos por cada actividad. Creemos que estos diagramas son muy tiles para modelar casos de uso del negocio, dado que son muy sencillos y expresivos, facilitando as la comunicacin con los usuarios. Estos diagramas pueden adaptarse a UML utilizando diagramas de actividades con calles (swimlanes). De esta manera, para mostrar de forma ms detallada el flujo de trabajo que realiza cada proceso de negocio crearemos diagramas de este tipo, que llamaremos diagramas de proceso. La Fig. 6 muestra el diagrama de proceso que incluye el escenario de la Fig. 4.Existe una calle por cada rol participante en el escenario, que incluye las actividades que realiza dicho rol. El diagrama tambin muestra la informacin que necesita y produce cada actividad, y la sincronizacin requerida entre las diferentes actividades. Los datos aparecen como objetos que fluyen entre las actividades y pueden tener un estado. Por ejemplo, la actividad Cursar pedido recibe un pedido propuesto e inicia su revisin (ver Fig. 6). Nos referimos a estos objetos como objetos de informacin.

Fig. 6. Diagrama de proceso para el caso de uso del negocio Registrar Pedido

Durante la descripcin de un proceso de negocio mediante un diagrama de proceso, es posible encontrar una actividad cuya complejidad sea tal que sea necesario describirla mediante otro diagrama de proceso adicional, por no complicar en exceso el diagrama en cuestin. Por tanto, este nuevo diagrama de proceso describir un subobjetivo en relacin al objetivo ligado al proceso de negocio original. De este modo los procesos de negocio se organizan jerrquicamente. Tambin es posible mostrar en diferentes diagramas de proceso el flujo normal y los flujos alternativos. 3.3 Especificacin de Reglas del Negocio En una organizacin, tanto los procesos como los datos que estos manejan, estn restringidos por las reglas del negocio. Con el fin de tener en cuenta todos los tipos de reglas que aparecen en la especificacin de requisitos, hemos utilizado la clasificacin descrita por James Odell [9], que distingue entre reglas de restriccin (reglas de estmulo-respuesta, reglas de restriccin de operacin y reglas estructurales) y reglas de derivacin. De acuerdo con esta clasificacin, recogemos de manera explcita cada tipo de regla en el modelo del negocio mediante la especificacin de las actividades y objetos de informacin que aparecen en los diagramas de proceso. Estas especificaciones se renen en un glosario. La Fig. 7 muestra la especificacin del objeto de informacin Pedido y de las actividades Ordenar fabricacin y Notificar aceptacin de pedido.

... Objeto de Informacin: Pedido Atributos Cdigo de pedido Fecha de solicitud Fecha de creacin Fecha mxima de entrega Conjunto de {Producto}Cliente Importe total Estado actual Restricciones El cdigo de pedido identificar unvocament e el pedido, y ser asignado automticam ente por el sistema. Las fechas de solicitud y de creacin sern previas a la fecha mxima de entrega. Un pedido contendr al menos un producto; no existe lmite mximo de productos. Un pedido siempre ser solicitado por un y solamente un cliente El importe total del pedido ser

... Actividad: Ordenar fabricacin Origen: Analizar viabilidad Agente: Jefe Tcnico Precondiciones: La fabricaci n de todo producto en el pedido es viable Existe una plantilla de fabricaci n para cada uno de dichos producto s. Ha sido creada una orden de trabajo para cada producto solicitado ; El estado de cada orden de trabajo es pendient e. Cada orden de trabajo ha sido enviada al jefe de producci n para

Postcondiciones:

calculado a partir del precio y unidades pedidas de cada producto incluido. ... Clase del Dominio: -pendiente de especificar...

su planificac in. Caso de Uso del sistema: - pendiente de especificarActividad: Notificar aceptacin de pedido Origen: Analizar viabilidad Agente: Comercial Precondiciones: La fabricaci n de todos sus producto s es viable. Se ha comunica do al cliente la aceptaci n de su pedido. El estado del pedido es aceptado .

Postcondiciones:

Caso de Uso del Sistema: -pendiente. de especificar...

Fig. 7. Extracto del glosario: objetos de informacin y actividades

Cada objeto de informacin se describir mediante un conjunto de atributos y sus restricciones de integridad (si las tuviera); por tanto, establecemos explcitamente las reglas estructurales y de derivacin. Por otro lado, la especificacin de la semntica de cada actividad contendr: origen (actividades que la preceden), agente (responsable de llevar a cabo la actividad), y pre y postcondiciones (que establecen qu tiene que cumplirse antes y despus de la actividad). Esta ltima parte se corresponde con las reglas de operacin, mientras que las reglas de estmulo-

respuesta quedan reflejadas mediante el origen, donde se expresa el orden entre las actividades. El glosario tendr una estructura de hipertexto (referencias-cruzadas) con el objeto de mantenerlas relaciones de trazabilidad entre los procesos del negocio y las clases y los casos de uso que especifican la funcionalidad del sistema.

4 Anlisis de Requisitos: Modelos Conceptual y de Casos de Uso Iniciales

A partir del modelo del negocio descrito en la seccin anterior, es posible obtener de manera sistemtica y directa, tanto la coleccin inicial de casos de uso del sistema como el modelo conceptual preliminar. A continuacin vamos a describir de manera separada cmo obtener cada modelo. Los requisitos elicitados y especificados en esta fase sern incluidos en un documento de especificacin de requisitos del software (ERS). Recomendamos el uso de una plantilla de ERS estndar, como la IEEE 830-1998. 4.1 Transicin al Modelo Inicial de Casos de Uso del Sistema Segn nuestra experiencia, las actividades del diagrama de proceso tienen el nivel de granularidad adecuado para ser asociadas a un caso de uso del sistema. De esta manera, crearemos un caso de uso del sistema por cada actividad del diagrama de proceso que deba ser soportada por el sistema software. Por tanto, el rol que lleva a cabo la actividad ser el actor principal del caso de uso. Ntese que, de acuerdo con la definicin de caso de uso, no todas las actividades del diagrama de proceso sern consideradas como casos de uso, sino solamente aquellas que sean de valor para algn actor. Por ejemplo, supongamos que el rol Cliente no rellenara l mismo el pedido (mediante un formulario web, por ejemplo), sino que comunicara todos los datos por fax, mediante una llamada telefnica, o por cualquier otro medio, como resultado de la actividad Rellenar pedido (ver Fig. 6). Como esta actividad se llevara a cabo fuera del sistema software, no apareceran en el diagrama de casos de uso del sistema ni el rol Cliente (puesto que no interacta con el sistema software) ni la actividad Rellenar pedido. En la Fig. 8 se muestra el diagrama de casos de uso del sistema para el proceso del negocio Registrar Pedido, correspondiente al diagrama de proceso de la Fig. 6,considerando que todas las actividades sern soportadas por el sistema software. El diagrama contiene los casos de uso ms importante desde el punto de vista de la arquitectura del sistema. Debemos sealar que algunos casos de uso no se obtendrn directamente a partir de los diagramas de proceso. Estos nuevos casos de uso se detectaran al describir los casos de uso identificados y adquirir un mayor conocimiento sobre los requisitos que deben ser soportados, y representaran funciones que debe llevar a cabo el sistema para lograr algn objetivo asociado con algn caso de uso ya existente. En nuestro ejemplo, para Analizar viabilidad es necesario buscar en el catlogo de productos si un producto solicitado existe y, por

tanto, este catlogo debe mantenerse actualizado. En consecuencia, aadimos el caso de uso Mantener Productos del Catlogo. Otro ejemplo de un nuevo caso de uso sera Mantener Plantillas de Fabricacin.

Fig. 8. Diagrama inicial de casos de uso del sistema

Los casos de uso se pueden organizar en varios niveles (recomendamos dos o tres como mximo) de acuerdo con la descomposicin jerrquica propuesta en el modelado del negocio. Cada caso de uso se describir mediante una plantilla que puede rellenarse a partir de la especificacin de la actividad asociada, que se encuentra recogida en el glosario como ya hemos visto. Hemos elegido la plantilla propuesta por Coleman [4] porque combina simplicidad y completitud, como se muestra en la Fig. 9.Una vez descrito el caso de uso, se conectar a la especificacin de la actividad asociada en el glosario, con el objeto de mantener la trazabilidad entre los casos de uso del negocio y del sistema.

Caso de Uso

Ordenar Fabricacin

Descripcin

Se crearn rdenes de trabajo para cada producto solicitado en el pedido, y sern enviadas al jefe de produccin para su planificacin. Jefe tcnico - Es viable la fabricacin de cada producto solicitado en el pedido. - Existe una plantilla de fabricacin para cada producto solicitado.

Actores Asunciones

Pasos

1 REPETIR 1.1 Obtener un producto del pedido.

1.2 Buscar la plantilla de fabricacin asociada al producto. 1.3 Crear la orden de trabajo. 1.4 Almacenar la orden de trabajo con el estado pendiente. Variaciones Req. No Funcionales Cuestiones -

Fig. 9. Descripcin del caso de uso del sistema Ordenar Fabricacin

Tambin podran encontrarse relaciones entre los casos de uso, tales como include, si se detectan aspectos comunes entre varios casos de uso, y extend, para expresar caminos opcionales o alternativos en un caso de uso. No obstante, estamos de acuerdo con las recomendaciones ampliamente extendidas de no abusar de estas relaciones y no mostrarlas en los diagramas de casos de uso. Para completar esta fase debemos establecer los requisitos no funcionales. Cuando estn asociados a un caso de uso, podrn especificarse en la plantilla de caso de uso propuesta. Los requisitos no funcionales globales se recogern en el apartado correspondiente de la plantilla de ERS elegida. 4.2 Obtencin del Modelo Conceptual Inicial Los objetos de informacin que fluyen entre las actividades de un caso de uso del negocio representan datos del dominio, por lo que suponen una buena base para crear el modelo conceptual inicial. Este modelo incluir los conceptos y sus relaciones y se describir mediante un diagrama de clases UML, en el que los conceptos se representan mediante clases (del dominio). As, cada objeto de informacin del diagrama de proceso se convertir ahora en un concepto (y en la etapa de diseo dar lugar a una clase si el sistema software debe dar soporte a dicho concepto). A partir de la especificacin de un objeto de informacin obtendremos la definicin del concepto asociado, es decir, sus atributos, relaciones con otras clases y restricciones. Por ejemplo, a partir de la especificacin de Pedido mostrada en la Fig. 7, podramos obtener: i) los atributos codigo, fechaSolicitud, fechaCreacion, fechaMaxEntrega, importeTotal, estadoActual; ii) las asociacionesClientePedido y PedidoProducto, y iii) restricciones que podran ser expresadas textualmente o bien mediante OCL (Object Constraint Language), como {fechaMax-Entrega>fechaCreacion}. Ntese adems que cuando un modelo conceptual evoluciona hacia un diagrama de clases, las responsabilidades se pueden obtener a partir de ciertas restricciones ya especificadas en el glosario. Por ejemplo, la clase Pedido podra tener responsabilidades como obtenerProductos, calcularFechaMaxEntrega, calcularImpor teTotal o cambiarEstado.

De igual forma que conectbamos en el glosario las actividades con los casos de uso del sistema, vincularemos cada objeto de informacin con la clase del dominio que lo representa en el sistema. La Fig. 10 muestra el diagrama de clases que describe el primer modelo conceptual de nuestro ejemplo.

Fig. 10. Modelo conceptual inicial para el caso de uso del negocio Registrar Pedido

En esta etapa del desarrollo, merece la pena detenerse en la identificacin de los conceptos y no tanto en las relaciones entre ellos. Deberamos concentrarnos en las asociaciones del tipo debe conocer. Por ejemplo, a partir del glosario podemos establecer que un pedido debe conocer al cliente que lo realiza y los productos que lo componen (ver Fig. 7). De esta forma, alguno de los roles identificados en el modelo del negocio, y por tanto especificado en el modelo de roles, podra ser incluido como una clase en el modelo conceptual. Es el caso de la clase Cliente en nuestro ejemplo. A partir del modelo del negocio, es posible identificar tambin qu clases tienen un comportamiento que depende de un conjunto no trivial de estados alcanzables. En estos casos, sera interesante definir una mquina de estados mediante un diagramas tatechart UML. Estas clases se detectan con facilidad en los diagramas de proceso, puesto que se corresponden con objetos de informacin etiquetados con varios estados diferentes. En nuestro ejemplo, Pedido sera candidato para construir una mquina de estados que mostrase los estados de un pedido (propuesto, en_evaluacin, evaluado, aceptado y rechazado) y los eventos que producen los cambios entre estados.

5 Conclusiones
Este trabajo presenta una estrategia para abordar el modelado del negocio y el anlisis de requisitos, en la que los casos de uso y el modelo conceptual se obtienen de forma sencilla, a partir del modelo del negocio basado en el uso de diagramas de actividades UML.

Con las guas proporcionadas, el modelador dispone de un modo sistemtico de identificar y organizar casos de uso, y de identificar y definir las clases del modelo conceptual. Los procesos de negocio de la organizacin se identifican partiendo de los objetivos propuestos por Cockburn [3], y se describen mediante flujos de actividades que se representan mediante diagramas de actividades UML. De este modo, los casos de uso del sistema se obtienen a partir de las actividades de los procesos del negocio y se organizan jerrquicamente, de acuerdo con lo indicado por Korson [7]. Las clases del modelo conceptual se obtienen a partir de los objetos de informacin que fluyen entre las actividades. Nos gustara subrayar, como una caracterstica importante de nuestro enfoque, que el modelado de los casos de uso del sistema y el modelado conceptual se realizan en paralelo, de acuerdo con Korson [8], quien establece que esto es crucial para obtener casos de uso correctos, puesto que es necesario entender bien el dominio para poder escribir casos de uso que sean realmente tiles. A la vez que se realiza el modelado del negocio y de los requisitos, la especificacin de las actividades y de los casos de uso asociados, as como de los objetos de informacin y de las clases que los implementan, se van recogiendo en un glosario, que permitir mantener las correspondientes relaciones de trazabilidad entre los diferentes artefactos del modelado. El Proceso Unificado de desarrollo de software (UP) definido por Rational para UML [6], incluye tambin el modelado del negocio como un paso ms dentro de las iteraciones necesarias que conforman el modelo del proceso. Jacobson et al.[6] presentan algunos pasos que son similares a los nuestros, pero no se considera la descomposicin jerrquica de los casos de uso de nivel superior, ni tampoco se proporciona una gua clara para detectar los casos de uso del sistema. Nuestro enfoque para el modelado del negocio constituye una gua completa y detallada, a diferencia de las indicaciones generales presentadas en el UP.

6 Bibliografa
1. Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modeling Language User Guide. Addison-Wesley (1999) 2. Ceri, S., Fraternalli, P.: Designing Database Applications With Objects and Rules. TheIDEA Methodology. AddisonWesley (1997) 3. Cockburn, A.: Using Goal-Based Use Cases. JOOP, Vol. 10, No. 7 (Nov/Dec 1997) 56-62 4. Coleman, D.: A Use Case Template: Draft for discussion. http://www.bredemeyer.com/use_case.p df. (1998)

5. Integration Definition for Function Modeling. Computer Systems Laboratory, NationalInstitute of Standards and Technology, FIPS Pub. 183. December 21 (1993) 6. Jacobson, I., Booch, G. Rumbaugh, J.: The Unified Software Development Process. Addison-Wesley Longman, Inc. (1999) 7. Korson, T.: Misuse of Use Cases. http://softwarearchitects.com/publication s/korson/korson9803om.htm. (1998) 8. Korson, T.: Constructing Useful Use Cases. http://softwarearchitects.com/publication s/korson/usecase3. (1999) 9. Martin, J. Odell, J.J.: Object-Oriented Methods: A Foundation. Prentice Hall. (1997) 10. Ortn, M.J., Garca-Molina, J., Martnez, A., Pellicer, A.: Combining OOram and IDEA forInformation Systems Modeling. Technical Report TR LSI 1-00. Facultad de Informtica.Universidad de Murcia. (December 1998). 11. .Ortn, M.J., Garca-Molina, J.: Modelado con Roles en UML. IV Jornadas de Ingeniera delSoftware y Bases de Datos. Cceres, Spain (1999) 12. Reenskaug, T.: Working with Objects: the OOram Software Engineering Method. Addison-Wesley / Manning Publications. (1996) 13. Reenskaug, T.:Working with Objects: a Three-Model Architecture for the Analysis ofInformation Systems. JOOP Vol. 10, No. 2 (May 1997) 22-30

Proceso dirigido por objetivos para anlisis de dominio bajo estndares de calidad1 Francisca Losavio2, Alfredo Matteo, Irma Pacilli 1 Este trabajo es parcialmente financiado por el Consejo de Desarrollo Cientfico y Humanstico (CDCH) de la Universidad Central de Venezuela, proyecto ADIRE, No. PG-03-7310-2008/1 2 Autor de correspondencia. Laboratorio MoST, Centro ISYS, Escuela de Computacin, Facultad de Ciencias, Universidad Central de Venezuela; Caracas, Venezuela.

Correo electrnico: francislosavio@gmail.com , almatteo@cantv.net ,pacilli_irma@hotmail. com. Resumen Una de las preocupaciones actuales de la Ingeniera de Software, es reducir la brecha entre la ingeniera de requisitos y la ingeniera del sistema de software; el creciente inters en la disciplina denominada Ingeniera del Dominio trata de lenar esta brecha. En particular, este trabajo se enmarca en el contexto de la identificacin temprana de requisitos no funcionales (RNF). El enfoque propuesto por Chung y otros, integra requisitos funcionales (RF) y RNF en el modelo de casos de uso y llega a una configuracin arquitectnica inicial utilizando el enfoque dirigido por objetivos de Yu y otros. Nuestro aporte consiste en incorporar al enfoque de Chung, un primer paso de anlisis del dominio basado en los estndares de calidad ISO/IEC9126-1,para la especificacin temprana de los RNF, mediante un modelo de calidad que representa una vista de calidad del conocimiento del dominio. Este nuevo paso de anlisis permite justificar con precisin los requisitos globales y los lmites del sistema, los cuales no son justificados por Chung, y reutilizar este conocimiento sobre los objetivos de calidad de estilos arquitectnicos y funcionalidades principales, para la obtencin de la arquitectura inicial de la aplicacin. Nuestra contribucin principal y resultado es el paso de anlisis del dominio como extensin al proceso de Chung, el cual puede ser aplicado en el contexto de mtodos de diseo de lneas de producto y de desarrollo de software centrados en la arquitectura, ofreciendo tambin un lenguaje unificado sobre la calidad del producto software, del cual se carece en general. Palabras clave: ingeniera de software, anlisis del dominio, diseo dirigido por objetivos, modelo de calidad, estndares de calidad, ISO/IEC 9126-1, RNF Recibido: 21-01-09 Aceptado: 23-09-09 Goal-oriented Process for Domain Analysis Using Quality Standards Abstract One of the present concerns of Software Engineering is to reduce the gap between the stages of requirements engineering and software system engineering; the growing interest in the discipline of Domain Engineering is justly to try to fillin this gap. This work is framed in the context of the early identificationof non functional requirements (NFR). Functional requirements (FR) and NFR are integrated into the use case model, according to the approach of Chung et al., where an initial architectonical configurationis achieved according to the goal-oriented approach of Yu etal.Our main contribution consists in adding to the Chung et al. a domain analysis step based on the ISO/IEC9126-1 quality standards, for the early specification of NFR, using a quality model representing a quality view of the domain knowledge. This domain analysis allows a precise justification of the systems global requirements and boundaries, which are not at all justifiedby Chung, reusing this knowledge on the quality goals of architectural styles and main functionality to obtain the initial architecture for the application. The main contribution and result is this extension step of domain analysis to the Chung et al. process; it can be applied in the context of software product lines design methods and in early stages of architecture centric software development methods. A unified language of software product quality which is generally missing is also provided by our approach.

Key words: Software Engineering, Domain Analysis, Goal oriented Design, Quality Model, Quality Standards, ISO/IEC 9126-1, NFR Introduccin Para la Ingeniera de Software, la calidad de un producto debe ser considerada en etapas tempranas del proceso de desarrollo. En este con- texto, la nocin de calidad de un producto puede definirse como el conjunto de caractersticas o propiedades deseadas que deben estar presentes en el producto, considerando el punto de vista del usuario y del producto en si (ISO/IEC 9126-1, 2001). Por lo tanto, todo proyecto de software debe considerar satisfacer estas caractersticas deseadas y una manera de validar gran parte de ellas es considerar una arquitectura documentada del sistema como elemento central, en vista de que sta debe responder a los requisitos exigidos por el sistema, tanto funcionales porque algunos componentes son introducidos para responder a es- tos requisitos, como no funcionales porque otros componentes son introducidos para responder a requisitos de calidad precisos. Esto slo se puede lograr siguiendo procesos que permitan verificar la satisfaccin de los requisitos iniciales y reutilizar soluciones ya probadas. Una arquitectura documentada se refiere a que cada decisin arquitectnica est justificada sobre las bases de haber verificado que se cumplen los requisitos de calidad exigidos. Por requisito de calidad nos referimos a las propiedades que caracterizan una solucin arquitectnica, por ejemplo interoperabilidad de los componentes. Los requisitos no funcionales a los cuales denotaremos RNF, tradicionalmente se han asociado a los requisitos de calidad pero no se ha desarrollado un marco en el cual se puedan representar e integrar fcilmente al proceso de di- seo de las aplicaciones tal y como ocurre con los requisitos funcionales, a los cuales denotaremos RF, que se representan comnmente a travs del modelo de casos de uso de Booch, Rumbaugh & Jacobson (1999). RF, RNF: el proceso de Chung y Supakkul (2004) Hay enfoques (Lamsweerde, 2001; Yu y Mylopoulos, 1998) en el proceso de desarrollo que consideran relacionar los RF con los requisitos de calidad u objetivos de calidad a los cuales stos responden. Existen propuestas donde se han logrado integrar RF y RNF en un modelo de casos de uso ex- tendido, como es el caso de Moreira, Brito y Arajo (2002); Sousa, Soares, Borba y Castro (2004) y Chung y Supakkul. (2004); pero sin llegar a ser un estndar especfico y comnmente aceptado. En la prctica, dentro del contexto de un desarrollo basado en aspectos tempranos early aspects (Brito y Moreira, 2004; Sousa, Soares, Borba y Castro, 2004), el enfoque de Chung resulta prometedor y parece ser de fcil aplicacin; es claro que esta afirmacin se podr comprobar en el curso de investigaciones futuras en el rea. El Grfico muestra1 el diagrama de actividades de este proceso. Grfico 1 Diagrama de Actividad describiendo el proceso de Integracin . Chung y Supakkul (2004)

Objetivo y enfoque del trabajo En este trabajo se extiende un proceso propuesto por Chung y Supakkul (2004), para inte- grar RF y RNF en el modelo de casos de uso y bajo un enfoque orientado a objetivo goal-oriented approach; Chung utiliza para esta integracin el framework NFR Non Functional Require- ments definido por Chung, Nixon, Yu y Mylopoulos (2000). Nuestra proposicin especifica los requisitos de calidad asociados a RF y RNF de acuerdo al estndar ISO/IEC 9126-1, que considera la calidad interna, externa y en uso del producto de software, tomando en consideracin la importancia de seguir estndares que permitan asegurar un lenguaje comn para el entendimiento de todos los involucrados en el proyecto de software. En particular, slo se tomar en cuenta el modelo de calidad interna/externa, ya que se trata del producto de software durante su proceso de diseo y no del software como producto final en uso. En nuestro enfoque, la extensin al proceso de Chung consiste en incluir como etapa inicial, el anlisis del dominio para la reutilizacin del conocimiento sobre la arquitectura y la identificacin de restricciones o propiedades globales sobre las familias de aplicaciones del dominio. Un dominio, segn Be- rard (1992), es el conjunto mnimo de propiedades que definen una familia de problemas para los cuales se requieren soluciones computacionales. El resultado de este anlisis es el punto de partida para la justificacin de los requisitos globales de la aplicacin o sistema a ser construido; Chung no justifica la obtencin de estos requisitos globales. El proceso de Chung es entonces complementado por nuestro enfoque con esta etapa inicial y con el uso de estndares (ISO/IEC9126-1,2001;Losavio F., Chirinos L., Matteo A. y Ramdane-Cherif A., 2004), para la especificacin de los RNF. El paso inicial de anlisis del dominio con estndares de calidad para determinar los requisitos globales del sistema, constituye el aporte principal de este tra- bajo. Estructura del trabajo Adems de esta introduccin y de las conclusiones, el presente documento contiene una segunda seccin donde se resean los estndares de calidad y la eleccin del modelo ISO/IEC 9126-1. En la tercera seccin, se presenta el enfoque orientado a objetivos. En la cuarta seccin se describe el framework NFR de anlisis y diseo orientado a objetivos propuesto en el proceso de Chung y Supakkul (2004), extendido con el anlisis del dominio como etapa inicial. Finalmente, en la quinta seccin se ilustra la aplicacin de la propuesta con un caso de estudio especfico al

dominio de las aplicaciones basadas en Servicios Web del World Wide Web Consortium (2004). Estndares de calidad del producto de software Normalmente las caractersticas de calidad inherentes al producto a construir, son directa- mente definidas como RNF, pero es bueno sealar que algunas de las funcionalidades del sistema llevan implcitas la aplicacin o cumplimiento de un requisito de calidad, que corresponde a un requi- sito no funcional (funcionalidad implcita), como por ejemplo la seguridad exigida por la funcionalidad control de acceso. Existen varios modelos de calidad en la literatura como son los propuestos por Dromey (1994), ISO/IEC 9126-1 (2001) y GQM (BerghoutE.,SolingenR.,1999)entreotros, para especificarla calidad de productos software; en este documento utilizaremos el estndar ISO/IEC 9126-1, representado en el Cuadro 1, donde puede notarse la representacin jerrquica de cada una de las seis caractersticas principales de calidad interna y externa presentadas. El modelo puede ser refinado para incluir nuevas sub sub caractersticas. Preferimos este estndar por su amplia difusin y aceptacin en la comunidad internacional. Cabe resaltar que el comit JTC1/SC7 WG6, encargado de la redaccin de los estnda- res ISO/IEC sobre la calidad del producto de software, debe decidir la aprobacin oficial del nuevo estndar ISO/IEC 25010 despus de un proceso complejo de votacin que sustituira el ISO/IEC 9126-1; esta votacin parece estar prevista para julio 2009, pero la aprobacin definitiva puede tardar an ms. El nuevo estndar aportara modificaciones menores al actual estndar ISO/IEC 9126-1 bsicamente en referencia a la caracterstica funcionalidad, respecto a sus sub caractersticas seguridad e interoperabilidad que pasaran a ser caractersticas de alto nivel, llevando de 6 a 8 las caractersticas del ISO/IEC 91261. Pensamos utilizar el estndar 25010 en el desarrollo de los trabajos futuros en esta lnea de investigacin en cuanto est oficialmente aprobado. Por los momentos, como el estndar 9126-1 es el vigente y re- presenta el consenso de la comunidad cientfica en un dominio particular, nos regimos con la ltima versin oficial de este estndar, para proporcionar as una mayor confiabilidad a la investigacin. Cuadro 1 Caractersticas y sub-caractersticas interna/externa del modelo de Calidad ISO/IEC 9126-1

Establecer el modelo de calidad para el dominio de la aplicacin ayuda a definirlos requisitos no funcionales globales del sistema, as como algunos requisitos de

calidad para las funcionalidades del usuario comunes a una familia de aplicaciones del dominio y representa una vista de calidad del conocimiento del dominio. Enfoque orientado a objetivos El en foque orientado a objetivos de software, denominados en la literatura objetivos blandos del ingls softgoals (Dardenne y Lamsweerde, 1993;Lamsweerde,2001;YuyMylopoulos,1998), se traduce en la satisfaccin de objetivos no funcionales, a travs de las contribuciones positivas de las operacionalizaciones, que son actividades de bajo nivel o mecanismos introducidos para la satisfaccin de un objetivo requerido por los mis- mos. Es decir, los softgoals, (Chung, Nixon, Yu, y Mylopoulos, 2000), son objetivos difciles de expresar ya que no son funcionalidades requeridas directamente por la interaccin del usuario con el sistema; un ejemplo es la seguridad, ilustrada en el Grfico 2. Estos objetivos se descomponen y refinan en una estructura de rbol llamado el Grafo de Interdependencia de Softgoals, denominado en la literatura Softgoal Interdependency Graph (SIG) (Chung, Nixon, Yu y Mylopoulos, 2000),el cual es un grafo que recoge el criterio del desarrollador sobre estos objetivos y que muestra la interdependencia entre ellos dividindolos en subobjetivos hasta alcanzar la operacionalizacin, que indica un componente de software que se introduce para satisfacer el objetivo, en un enfoque descendente o topdown. Luego, se comienza desde el componente que operacionaliza el objetivo, hacia arriba bottom up", evaluando las contribuciones de cada rama del rbol; aquellas que tengan mayor peso positivo sern las que se deben ir logrando para satisfacer el objetivo principal de ms alto nivel. En el Grfico 2tomado directamente de Sousa, Soares, Borba y Castro (2004), se observa un ejemplo de un SIG donde se descompone el RNF seguridad security, indicando que se deben satisfacer los RNFs integridad integrity, confidencialidad confidentiality disponibilidad availability para poder satisfacerlo. Framework NFR para el Anlisis y Diseo Orientado a Objetivos En el enfoque presentado en Chung y Supakkul (2004) se propone utilizar el framework NFR, definido por Yu y Mylopoulos (1998) junto con el enfoque basado en escenarios o casos de uso, sobre las bases de dos premisas principales: 1)integrar los RNFs a los diagramas de casos de uso, que expresan los requisitos funcionales principales respecto a los usuarios a travs de los denominados puntos de asociacin para clasificarlos RNF y 2)establecer el alcance de reglas de propagacin para relacionar las asociaciones propuestas con el modelo de casos de uso. Los puntos de asociacin se utilizan para realizar una taxonoma de los RNF y las relaciones de generalizacin/especializacin son utilizada s para propagar el RNF, es decir incluirlo en el diagrama de casos de uso como una especializacin del caso de uso base. Para los casos de uso por inclusin, denotados como <<include>> en el Lenguaje de Modelacin Unificado, abrevia- do UML del ingls Unified Modeling Language (OMG, del ingles Object Management Group; Booch, Rumbaugh & Jacobson, 1999), el RNF es propagado tambin al caso de uso incluido. Esto es debido al hecho de que UML no dispone an de elementos de modelacin aceptados para los RNF. Sin embargo, el enfoque de Brito y Moreira(2004) propone considerar los RNF como casos de uso de inclusin <<include>>, lo cual nos parece atractivo, en el sentido de que el RNF se expresa como un mecanismo que siempre deber estar presente en la ejecucin del caso de uso. Adems, a partir de tablas

de composicin (Brito y Moreira, 2004) es ms fcil identificarlas posibles incumbencias transversales en un contexto de diseo temprano de aspectos. Grfico 2 Grafo de Interdependencia del RNF seguridad security. Sousa et al. (2004)

Puntos de Asociacin: se proponen cuatro asociaciones de los RNF relacionados con: el proceso de desarrollo del sistema denominados globales, entidades externas actor, de acceso, comunicacin o intercambio de informacin de- nominados asociacin Actor-Caso de uso y final- mente los requisitos funcionales clsicos caso de uso; los tipos de RNF mencionados se aplican respectivamente en cuatro puntos del diagrama de casos de uso, especficamente en: la frontera del sistema, en el actor, en el caso de uso y en el enlace entre actor y el caso de uso. Estas asociaciones permiten una primera clasificacin de requisitos no funcionales, a un alto nivel. Se plantea un diagrama de actividades donde se esboza un proceso iterativo e incremental a travs del cual se integran los RF y RNFs, bajo las premisas plantea- das, como se muestra en el Grfico 3. Grfico 3 Diagrama de Actividad del Proceso de Integracin de RF y RNF, con anlisis del dominio

Un aporte especfico del presente trabajo es integrar, en la primera fase de ese proceso denominada en Chung y Supakkul(2004)definir lmites del sistema y requerimientos globales que se mostr en el Grfico 1, la actividad 1 en el diagrama del Grfico ,3un anlisis del dominio de la aplicacin, utilizando el estndar de calidad ISO/IEC 9126-1 para la especificacin de los requisitos de calidad asociados a los RNF, de tal manera de proporcionar una primera especificacin y justificacin razonada documentacin, de los requisitos que afectan al dominio y a cualquier familia de aplicaciones que se encuentre dentro de ste. Nuestro enfoque se centra en especificarlas propiedades de calidad utilizando el modelo estndar ISO/IEC 9126-1 para unificarla terminologa respecto a los requisitos de calidad. Anlisis del dominio en este contexto implica identificar aquellos requisitos funcionales o no, relativos a las familias de aplicaciones del dominio del problema a resolver. Para esta etapa, Losavio, Matteo y Rahamut (2008), proponen un proceso para una caracterizacin del dominio de aplicacio- nes basadas en servicios Web, a los cuales denominaremos WS, que ser aplicado en la siguiente seccin para el caso de estudio; este proceso ser generalizado aqu para cualquier dominio y constituye el principal aporte de este trabajo. Proceso de anlisis del dominio del problema Entrada: la descripcin textual del problema, para el cual se requiere como solucin un sistema o aplicacin de software; taxonoma de familias de aplicaciones del dominio y estilos o soluciones arquitecturales de alto nivel para estas familias. a) Definirla funcionalidad del dominio: listar las funcionalidades principales por cada tipo de familia b) Definir el modelo de calidad, utilizando el estndar ISO/IEC 9126-1 (ntese que otro estndar podra ser utilizado). b.1) se especifica la calidad arquitectural del dominio, utilizando los objetivos de calidad crticos de una solucin arquitectural genrica o estilo para cada familia de ese dominio b.2) se especifica la calidad funcional del dominio, donde por cada familia se identifican las funcionalidad es propias a la familia y a cada funcionalidad se asocian los requisitos de calidad, como objetivos que deben cumplirse para lograr las funcionalidades. Este paso se repite para cada familia del dominio

Salida: modelo de calidad para cada familia del dominio Caso de estudio: fijacin de precios para el suministro de servicios en lneas areas Paso 1. Anlisis del dominio Este paso es una propuesta original del presente trabajo, constituyendo uno de sus principales aportes y no es considerado en el proceso de Chung. Entrada: Descripcin del problema El problema del caso de estudio es propuesto por Chung & Supakkul (2004). El Sistema de Fijacin de Precios permitir a las aerolneas colaborar con sus proveedores a travs de internet para establecer los precios de los tems de servicio que se ofrecen en los vuelos, tales como: leche, bebidas, comidas y artculos de limpieza. La aerolnea se encarga de mantener ac- tualizado el sistema con los servicios que requiere. Cuando se crea o actualiza un servicio se le enva esa informacin a los proveedores, va internet, para que ellos enven su propuesta de precios. Si la propuesta es aceptada o rechazada, se le informa al proveedor y ste puede reenviar su propuesta hasta llegar a un acuerdo con respecto al precio del servicio. - Taxonoma de familias: Aplicacin basada en WS de tipo transaccional (contratacin de servicios va Internet);una transaccin se define como un conjunto de actividades agrupadas en una unidad; una transaccin es cumplida como un todo, si una actividad falla, toda la transaccin falla, World Wide Web Consortium (2004). - Estilo arquitectural para la familia de aplicaciones basadas en WS transaccionales: segn Carnegie Mellon-Software Engineering Institute (2003), Arquitecturas Orientadas a Servicios denotadas por SOA del ingls Service Oriented Architecture; estilo capas, siguiendo un modelo de comunicacin cliente/servidor (Losavio F., Matteo A. y Rahamut R., 2008). a) Identificar funcionalidades propias a la familia Para el tipo de aplicaciones basadas en WS transaccionales, se identifican las siguientes funcionalidades bsicas: intercambio de datos, control de acceso (Losavio F., Matteo A. y Rahamut R., 2008). b) Definir modelo de calidad b.1) Especificarla calidad arquitectural para la familia de aplicaciones basadas en WS transaccionales: la arquitectura SOA para estas aplicaciones debe responder a los objetivos de calidad. Losavio F., Matteo A. y Rahamut R.(2008), proponen: interoperabilidad, confiabilidad (disponibilidad), mantenibilidad (extensin),portabilidad (escalabilidad). Ntese que las sub caractersticas se han colocado entre parntesis a continuacin de la caracterstica principal de calidad. Debe observarse que SOA es parte del conocimiento del dominio; pueden existir otras soluciones arquitectnicas para ese dominio en par- ticular. La eleccin de

una solucin particular debe obedecer a un proceso de seleccin basado en la experticia, es decir es una solucin probada y aparece en un catlogo y en la satisfaccin de sus requisitos de calidad, respecto a los requisitos de la aplicacin particular. Este proceso de seleccin no es obvio y pertenece al rea de investigacin abierta de la evaluacin de arquitecturas, donde se han realizados numerosos trabajos previos (Losavio F., Chirinos L., Matteo A. y Ramdane-Cherif A., 2004). b.2)Especificar la calidad funcional para la familia de aplicaciones basadas en WS transaccionales: Para realizar intercambio de datos se requiere seguridad, precisin y eficiencia (tiempo de respuesta) en la transmisin de datos, adems de la interoperabilidad y confiabilidad (disponibilidad) por parte del servidor, que son aseguradas por la SOA. Para control de acceso se requiere seguridad. Salida: El modelo de calidad para el dominio de aplicaciones basadas en WS transaccionales, est constituido por las caractersticas y sub-caracters- ticas de calidad encontradas en b.1 y b.2, segn el Cuadro 1: mantenibilidad (extensin), eficiencia (tiempo de respuesta), confiabilidad (disponibilidad), portabilidad (escalabilidad), adems de las sub-caractersticas de funcionalidad, que son: interoperabilidad, seguridad y precisin. Los RNF globales, que deben ser cumplidos en general por todo el sistema, se derivan directa- mente del modelo de calidad del dominio, consi- derando los requisitos de calidad arquitecturales obtenidos en la actividad b.1, es decir: interoperabilidad, confiabilidad (disponibilidad), manteni- bilidad (extensin), portabilidad (escalabilidad). La calidad funcional, actividades a y b.2, ser utilizada en el paso 3, para justificarlos objetivos de calidad de los RF. Paso 2. Identificar actores y RNF Los actores humanos que se pueden detectar de la descripcin del problema son: Proveedor, Gerente de Item de Servicio, Gerente de Aprobacin de Propuesta. El Sistema de Facturacin de Materiales es tambin un actor, pero no humano. Se identifica un solo RNF, la usabilidad, asociado a cada uno de los actores humanos, como se muestra en el Cuadro 2. Cuadro 2 Lista de funcionalidades del Sistema de Fijacin de Precios

Paso 3. Identificar casos de uso (RF) y RNF Con la ayuda del marco NFR de Chung, Nixon, Yu, y Mylopoulos (2000), de la descripcin del problema y considerando las funcionalidades y sus propiedades de calidad, obtenidas en las actividades a y b.2 del paso 1, se obtienen todas las funcionalidades del Sistema de Fijacin de Precios, a las cuales correspondern los casos de uso y los objetivos de calidad asociados, en el Grfico 4. La mayora de los requisitos de calidad (RNF) son obtenidos observando la correspondencia con las funcionalidades principales detectadas en el paso 1, como se muestra en el Cuadro 2. Grfico 4 Modelo de Caso de uso y los RNF Asociados

El Grfico muestra4 el modelo de casos de uso, todos los RNF asociados, adems de los RNF globales del Sistema de Fijacin de Precios. Paso 4. Reestructurar los RNF comunes: De acuerdo a Chung, significa hacer uso de las relaciones de generalizacin/especializacin para reacomodar los RNF. Del Cuadro 2, se observa que el RNF usabilidad, se aplica a los tres casos de uso en donde intervienen actores humanos. En este caso, se decide crear el caso de uso Acceso en Lnea que generaliza Gestin de Item de Servicio, Enviar PP y Aprobar PP. Ntese que el caso de uso Acceso en Lnea implica tener control de acceso, funcionalidad detectada en la actividad a) del paso 1 y requiere seguridad en b.1. Esta generalizacin afecta a los actores por- que son diferentes para cada caso de uso, por lo tanto tambin se pueden generalizar los actores Proveedor, Gerente de Item de Servicio y Gerente de Aprobacin, en un slo actor llamado Usuario y asociar el RNF usabilidad a la asociacin entre el actor Usuario y el caso de uso Acceso en Lnea; cabe sealar, que por las reglas de propagacin, esto implica que el RNF usabilidad se propaga a los casos de usos incluidos, en el Grfico 5Por. otra parte, tambin los RNF tiempo de respuesta, seguridad y precisin intervienen en todas las transmisiones de datos: Enviar RP, Enviar PP y Aprobar PP; y por lo tanto se asocian ahora a la comunicacin entre Usuario y Acceso en Lnea, que es el punto de entrada de todos los actores al sistema. Grfico 5 Reestructuracin de los RNF comunes en el Modelo de Casos de Uso

Paso 5. Refinar y satisfacer los softgoals RNF

Se realiza un SIG por cada RNF asociado al Modelo de casos de uso. Los RNF globales se expresan en un SIG para la arquitectura; el Grfico 6 muestra, el SIG para SOA determina- da tambin en el anlisis del dominio. Las partes a, b, c del Grfico 7 y la parte d.1 del Grfico 8 muestran los SIG para los RNF usabilidad, precisin, eficiencia (tiempo de respuesta) y seguridad respectivamente. Grfico 6 Grfico de interdependencia de objetivos (SIG) de SOA

Grfico 7 SIG de los RNFs asociados a las funcionalidades del sistema (partes a, b, c)

Paso 6. Satisfacer las operacionalizaciones de softgoals

En el SIG de seguridad se seleccionaron como ejemplo las operacionalizaciones Mantener control de Identificacin y Encriptacindedatos en la parte d.2 del Grfico 8, para obtener componentes de las soluciones arquitecturales para el RNF seguridad; se construyen de esta manera componentes para cada SIG, para as obtener una arquitectura inicial o baseline para el Sistemas de Fijacin de precios, dentro de un enfoque de lnea de producto. Ntese que el uso del modelo de calidad ISO/IEC 9126-1 ha modificado algunos SIGs del enfoque de Chung L., Supakkul S. (2004), en particular la seguridad en este estndar no incluye ni con fiabilidad ni precisin, que son tratadas aqu como SIGs separados. En el Grfico 6 muestra el SIG que corresponde a la arquitectura orientada a servicios (SOA) de la aplicacin. Grfico 8 SIG de los RNFs asociados a las funcionalidades del sistema (partes d.1 y d.2)

Paso 7. Diseo de casos de uso. Luego de determinar la satisfaccin de los softgoals y las decisiones de diseo, se elaboran los diagramas de colaboracin y secuencia para la implementacin de cada caso de uso, los cuales no se muestran aqu para facilitar la lectura del documento y consideraciones de espacio. Conclusin Se propone un proceso de anlisis del dominio a ser incluido en el proceso de Chung como primer paso, para la integracin de los RNF y los FR en los puntos de asociacin con los elementos del diagrama de casos de uso; se hace especial nfasis en el uso del estndar de calidad ISO/IEC 9126-1 para especificarlos RNF. La mayor contribucin de este trabajo consiste en reutilizar en el proceso de Chung, los resultados del anlisis del dominio del Paso 1, los cuales se reutilizan tambin en el paso 2, para definirlos RNF globales del sistema, no justificados en el proceso de Chung y en el paso 3, para justificarlos requisitos de calidad que deben ser satisfechos para las distintas funcionalidades de la aplicacin. La especificacin de

los re- quisitos de calidad por estndares internacionales (ISO/IEC 9126-1, 2001), comnmente aceptados por la comunidad, facilitan el entendimiento entre los grupos que desarrollan el proyecto de software, ofreciendo un lenguaje unificado sobre la calidad de software, del cual se carece. Nuestra contribucin principal y resultado es el paso de anlisis del dominio como extensin al proceso de Chung, el cual parece ser de fcil aplicabilidad en el contexto de mtodos de diseo de lneas de productos y de desarrollo de software centrados en la arquitectura, ofreciendo tambin un lenguaje unificado sobre la calidad del producto software, del cual se carece en general. En particular, pensamos utilizar el nuevo estndar ISO/IEC 25010 en el desarrollo de los trabajos futuros en esta lnea de investigacin, en cuanto est oficialmente aprobado. Por otra parte, definir un proceso general y reutilizable de anlisis del dominio que pueda ser incorporado a mtodos centrados en la arquitectura o de lneas de produccin, en un contexto de desarrollo de software orientado a aspectos, es un rea abierta de investigacin. Incorporar el proceso con anlisis de dominios basado en estndares de calidad para construir una arquitectura inicial, por ejemplo en las fases de Inicio y Elaboracin del Proceso Unificado, abreviado UP del ingls Unified Process (Booch, Rumbaugh y Jacobson, 1999), es una investigacin en curso. Se han hechos trabajos que contemplan procesos con estndares de calidad y UP (Losavio, Chirinos, Matteo, Lvy y Ramdane-Cherif,2004;Cooper,Abraham,Unnithan,Chung y Courtney, 2006), sin embargo no se considera all un enfoque de anlisis del dominio. Otros trabajos en curso son, por una parte la comparacin de enfoques similares, por ejemplo en BritoI.,Moreira A. (2004) de integracin de RNF y RF con escenarios con el enfoque orientado a objetivos y aplicar nuestro anlisis de dominio con estndares a los enfoques que resulten ms prometedores de la comparacin; debe tambin experimentarse con un mayor nmero de casos de estudios realistas. As mismo se est estudiando la especificacin de la vista de calidad del conocimiento del dominio mediante ontologas (Sancho P. P., Juiz C., Puigjaner R., Chung L. y Subramanian N., 2007), para facilitar la integracin de diferentes estndares, los cuales son utilizados en la prctica y la recuperacin de las mtricas correspondientes a los atributos de calidad. Bibliografa 1.Berard, E. (1992). Essays on Object-Oriented Software Engineering, Prentice Hal, New Jersey, U.S.A [ Links ] 2.Berghout, E., Solingen, R. (1999). The Goal/Question/ Metric Method (GQM) A practical method for quality improvement of software development. London, McGraw Hill [ Links ] 3.Booch,G.,Rumbaugh, J. y Jacobson, I. (1999).The Unified Modeling Language User Guide, Addison- Wesley, Boston, U.S.A. [ Links ] 4.Brito, I., Moreira, A. (2004). Integrating the NFR Framework in a RE Model. Early Aspects: Aspect-Oriented Requirements Engineering and Archi- tecture Design, Lancaster, UK. 2004 [ Links ] 5.Carnegie Mellon. Software Engineering Institute (2003). Client/ServerSoftwareArchitectures-An Overview. Disponible en http://web.simmons.edu/~benoit/LIS455/Client-Server1.doc

[ Links ]

6.Chung, L., Nixon B. A., Yu E., y Mylopoulos, J. (2000). Non-Functional Requirements in Software En- gineering. Kluwer Academic Publishers

[ Links ]

7.Chung, L., Supakkul, S. (2004). Integrating FRs and NFRs: A Use Case and Goal Driven Approach. 2nd Inter. Conference on Software Engineering (SERA04), pp 30 37 [ Links ] 8.Cooper, K., Abraham S. P., Unnithan R. S., Chung L. y Courtney, S.(2006). Integrating Goal Models in the Rational Unified Process. Journal of Visual Languages & Computing: 17(6), Dec. 2006, pp.551-583 [ Links ] 9.Dardenne, A., Lamsweerde A. Von (1993). Goal-Directed Requirements Acquisition. Science of Computer Programming, vol. 20, 179-190 [ Links ] 10.Dromey (1994). A Model for Software Product Quality. Disponible en www.sqi.gu.edu.au/docs/sqi/technical/Model_For_S_W_Prod_Qual.pdf [ Links ] 11.ISO/IEC9126-1(2001).International Organization for Standardization (ISO). Software engineering-Product quality - Part 1: Quality model.http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749 [ Links ] 12.Lamsweerde A. Von (2001). Goal-Oriented Require- ments Engineering: A Guided Tour. 5th Intl Symp. On RE, IEEE CS Press, pp. 249 -261 [ Links ] 13.Losavio, F., Matteo, A. y Rahamut, R. (2008). Web Services Domain Analysis Based on Quality Standards 2nd European Conference on Software Architecture, Cyprus, 2008, R. Morrison, D. Balasubramaniam, and K. Falkner (Eds.): ECSA 2008, LNCS Vol. 5292, 354358 Springer- Verlag Berlin Heidelberg [ Links ] 14.Losavio, F., Chirinos, L., Matteo, A. y Ramdane-Cherif, A. (2004). ISO quality standards for measuring architectures. The Journal of Systems and Soft- ware (JSS). Vol. 72 (2), 209-223 [ Links ] 15.Losavio, F., Chirinos, L., Matteo, A., Lvy, N. y Ramdane-Cherif, A. (2004). Designing Quality Architecture: Incorporating ISO Standards into the UnifiedProcess. Information Systems Manage- ment (ISYM), Auerbach Publications, Vol. 21(1),27-44 [ Links ] 16.Moreira, A., Brito, I. y Arajo, J. (2002). Crosscutting quality attributes for requirements engineering. The 14th. International Conference on Software Engineering and Knowledge Engineering (SE- KE02), Ischia, Italy, ACM Press, pp 167-174 [ Links ] 17.OMG. Object Management Group. Unified Modeling Language (UML). www.uml.org/ [ Links ] 18.Sancho, P. P., Juiz, C., Puigjaner, R., Chung, L. y Subramanian, N. (2007). An Approach to Ontology- aided Performance Engineering through NFR Framework. Proc. WOSP07, Buenos Aires, Argentina. ACM (Order No. 488073). Feb. 5 -8,2007. pp. 125-128 [ Links ] 19.Sousa, G., Soares, S., Borba, P. y Castro, J. (2004). Separation of Crosscutting Concerns from Requie- rements to Design: Adapting a Use Case Driven Approach. Early Aspects 2004: Aspect-Oriented [ Links ]

20.Requirements Engineering and Architecture Design. Workshop at International Conference on Aspect-Oriented Software Development (AOSD), Lancaster UK. pp 93-102 [ Links ] 21.World Wide Web Consortium (2004). Web Services Architecture Requirements.W3C Working Group Note 11 February. Copyright 2004 W3C (MIT,ERCIM,Keio).Disponible en http://www.w3.org/TR/wsa-reqs [ Links ] 22.Yu, E., Mylopoulos, J. (1998). Why goal-oriented requirements engineering, Proceedings of the Fourth International Workshop on Requirements Engi- neering: Foundations of Software Quality, Pisa,Italy, pp. 15-22 [ Links ] Agradecimiento Agradecemos altamente a los rbitros por la cuidadosa lectura del documento y las observaciones formuladas, las cuales redundan en beneficio de la calidad de este trabajo. As mismo, queremos agradecer al Sr. Jorgen Boegh, miembro activo del JTC 1/SC7 WG6 de la organizacin ISO/IEC por corroborar la informacin sobre la vigencia del estndar ISO/IEC 9126-1.