jira_ortin893.pdf

7/29/2019 jira_ortin893.pdf

1/15

El Modelo del Negocio como basedel Modelo de Requisitos 1

Mara Jos Ortn, Jess Garca Molina, Begoa Moros, Joaqun NicolsGrupo de Investigacin de Ingeniera del Software

Departamento de Informtica y SistemasFacultad de Informtica. Universidad de MurciaC.P. 30071 Campus de Espinardo, Murcia, Spain

Resumen. En este trabajo se presenta una estrategia para obtener de modo sis-

temtico el modelo de casos de uso y el modelo conceptual, a partir del mode-lado del negocio basado en diagramas de actividades UML. Despus de deter-minar los procesos del negocio de la organizacin bajo estudio, y de describirsus flujos de trabajo mediante diagramas de actividades, los casos de uso sonidentificados y estructurados a partir de las actividades de cada proceso, mien-tras que los conceptos del modelo conceptual se obtienen a partir de los datosque fluyen entre las actividades. Adems, las reglas del negocio son identifica-das e incluidas en un glosario, como parte de la especificacin de datos y acti-vidades. Un aspecto destacable de nuestra propuesta es el hecho de que el mo-delado conceptual y el de casos de uso son realizados en paralelo, haciendo msfcil la identificacin y especificacin de casos de uso adecuados. Tanto el mo-delado de casos de uso como el modelado conceptual forman parte de la fase deanlisis de requisitos de un modelo de proceso completo en cuya definicin es-tamos trabajando y cuya primera etapa es el modelado del negocio. Este proce-so est siendo completado y adaptado a la tecnologa web dentro de un proyectoPROFIT en cooperacin con una empresa de desarrollo de software.

1 Introduccin

Desde que UML [1] fue adoptado por el OMG como el lenguaje estndar para elmodelado, se ha definido un buen nmero de modelos de proceso para el desarrollo deaplicaciones orientadas a objetos (OO), que utilizan este lenguaje como medio deexpresin de los diferentes modelos que se crean durante el desarrollo. Estas pro-puestas suelen estar guiadas por los casos de uso, de manera que stos se empleanpara definir los requisitos funcionales del sistema, y todas las etapas del proceso (pla-nificacin de las iteraciones, anlisis, diseo y pruebas) se articulan en torno a loscasos de uso identificados.

Actualmente, en muchas discusiones sobre casos de uso se coincide en sealar quecon frecuencia son mal interpretados, y que no hay guas precisas para resolver los

1 Esta ponencia es una revisin del trabajo De los procesos de negocio a los casos de uso,

presentado en las V Jornadas de Ingeniera del Software y Bases de Datos celebradas en Va-lladolid en noviembre de 2000.

La revisin ha sido subvencionada por el Proyecto PROFIT FIT-070000-2000-411 y por laRed Temtica de Investigacin en Ingeniera del Software TIC 2000-2052-E.


2/15

aspectos que tienen que ver con su organizacin. En este sentido, se han publicadodiferentes propuestas (por ejemplo [2, 5, 6]) en las que se discuten cuestiones talescomo 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.

En la actualidad trabajamos en la definicin de un proceso basado en UML orien-tado a sistemas de informacin de gestin y en su adaptacin al desarrollo de aplica-ciones web, dentro de un proyecto PROFIT2 en cooperacin con la empresa de con-sultora y desarrollo de software Sinergia Tecnolgica. Este proceso incluye una faseinicial de modelado del negocio, que describe los procesos del negocio de la organi-zacin bajo estudio de manera que se puedan construir, de forma sencilla y directa,versiones iniciales de los modelos conceptual y de casos de uso, propios de la etapade modelado de requisitos. En este trabajo describimos cmo realizar el modelado delnegocio y su conexin con el modelo de requisitos.

La estructura del trabajo es la siguiente: en el apartado 2 comentamos brevementela problemtica asociada a la utilizacin del concepto de caso de uso, y ofrecemos unavisin general de nuestra propuesta; en el apartado 3 presentamos la manera de abor-dar el modelado del negocio; en el apartado 4 mostramos cmo realizar la transicindesde 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 sedefinen como guiados por los casos de uso. Un caso de uso puede ser definido comouna secuencia de acciones, incluyendo variaciones, que el sistema puede ejecutar yque produce un resultado observable de valor para un actor que interacta con elsistema [1]. Aunque el xito de los casos de uso se suele justificar con el hecho de queconstituyen una tcnica simple e intuitiva, algunos autores (ver por ejemplo [2, 5, 6])sealan las dificultades que entraa la obtencin y la especificacin de casos de usoverdaderamente 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 conjuntode guas para la identificacin, descripcin y organizacin de los casos de uso.

Algunas discusiones interesantes acerca del manejo de casos de uso son las propor-cionadas por T. Korson y A. Cockburn. Korson [5] defiende que los requisitos (y portanto los casos de uso) han de ser organizados jerrquicamente y establece que i) cadanivel de casos de uso no debe aadir nuevos requisitos, sino refinar los del nivel supe-rior, y ii) la jerarqua de casos de uso no debe ser el resultado de una descomposicinfuncional, y ha de ser desarrollada de manera iterativa e incremental.

Por otro lado, Cockburn [2] utiliza el concepto de objetivo (goal) para organizar je-rrquicamente los casos de uso. Distingue bsicamente entre objetivos estratgicos(losprocesos del negocio de la organizacin) y objetivos de usuario (las funciones delsistema). Los objetivos estratgicos se corresponden con un conjunto de objetivos de2 Proyecto PROFIT Definicin y Aplicacin de un Proceso Software basado en UML para el

desarrollo de Aplicaciones web FIT-070000-2000-411.


3/15

usuario y, de igual modo, un objetivo de usuario puede ser descompuesto, a su vez, enun conjunto de objetivos de usuario.

Otra cuestin importante es la ubicacin del modelado de casos de uso dentro delmodelo de proceso. Normalmente se concibe el modelado de casos de uso como unpaso previo al modelado conceptual. Sin embargo, Korson [6] argumenta que no esposible crear casos de uso adecuados y tiles (ni implementarlos correctamente) sincomprender el dominio, y por tanto, el modelado de casos de uso y el modelado con-ceptual deben ser actividades realizadas en paralelo.

2.2 Nuestra Propuesta

Normalmente, los casos de uso son elicitados de forma intuitiva a partir de la especi-

ficacin del sistema y, posteriormente, las entidades del modelo conceptual se extraena partir de las especificaciones de los casos de uso. En las siguientes secciones pre-sentamos una propuesta para obtener de forma sistemtica tanto el modelo de casos deuso como el modelo conceptual, a partir de un modelo del negocio, de acuerdo con elesquema mostrado en la Fig.1.

Modelado

del Negocio

0 2 ' ( / 2 ' ( 5 ( 4 8 , 6 , 7 2 6

Diagrama de Casosde Uso del Sistema

Diagrama de Roles Diagrama de Secuencia Diagrama de Proceso

0 2 ' ( / 2 ' ( / 1 ( * 2 & , 2

GlosarioAnlisis de

Requisitos

Modelo Conceptual

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

Explicaremos, por tanto, cmo el modelo del negocio puede ser la base para la es-pecificacin de los requisitos ms importantes del sistema que dar soporte al nego-cio, siendo por tanto el propio negocio lo que determine los requisitos.

Una vez identificados los procesos de negocio de la organizacin, y descritos susflujos de trabajo mediante diagramas de actividades, los casos de uso se elicitan yestructuran a partir de las actividades de cada proceso, mientras que las entidades delmodelo conceptual se obtienen de los datos que fluyen entre tales actividades. Ade-ms, se identifican las reglas del negocio y se incluyen en un glosario como parte dela especificacin de los datos y las actividades. Un aspecto notable de nuestra pro-puesta es que el modelado de casos de uso y el modelado conceptual se realizan almismo tiempo, facilitando, por tanto, la identificacin y especificacin de los casos deuso adecuados.


4/15

3 Modelado del Negocio

Para conseguir sus objetivos, una empresa organiza su actividad por medio de unconjunto deprocesos de negocio. Cada uno de ellos se caracteriza por una coleccinde datos que son producidos y manipulados mediante un conjunto de tareas, en lasque ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdoa un flujo de trabajo determinado. Adems, estos procesos se hallan sujetos a unconjunto de reglas de negocio, que determinan la estructura de la informacin y laspolticas de la empresa. Por tanto, la finalidad del modelado del negocio es describircada proceso del negocio, especificando sus datos, actividades (o tareas), roles (oagentes) y reglas de negocio.

3.1 Identificacin de Procesos de Negocio

El primer paso del modelado del negocio consiste en capturar los procesos de negociode la organizacin bajo estudio. La definicin del conjunto de procesos del negocio esuna tarea crucial, ya que define los lmites del proceso de modelado posterior.

Nos basamos en el concepto de objetivo estratgico, introducido por Cockburn [2],para identificar de manera adecuada los diferentes procesos de negocio de una organi-zacin a partir de la determinacin y estructuracin de sus objetivos.

En primer lugar, por tanto, identificamos los objetivos estratgicos de la empresa.Teniendo en cuenta que estos objetivos van a ser muy complejos y de un nivel deabstraccin muy alto, cada uno de ellos puede ser descompuesto en un conjunto desubobjetivos ms concretos, que debern cumplirse para conseguir el objetivo estrat-gico original. Estos subobjetivos pueden a su vez ser descompuestos en otros, demanera que se defina una jerarqua de objetivos. En nuestro estudio, hemos experi-mentado que dos o tres niveles de descomposicin son suficientes. Para cada objetivoque no ha sido descompuesto en otros, definimos un proceso del negocio cuyo prop-sito ser dar soporte a dicho objetivo, es decir lograrlo o realizarlo. Representamoscada proceso del negocio mediante un caso de uso del negocio.

En el resto del trabajo, ilustramos el proceso mediante el ejemplo de una compaaque fabrica productos bajo demanda (siguiendo un esquema just in time). Los objeti-vos 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 talescomoRegistrar Pedido de Cliente, Fabricar Producto Pedido, Gestionar Almacn y

Realizar Pedidos a Proveedores. stos sern los objetivos que utilizaremos para defi-nir nuestros procesos del negocio.

Un enfoque muy similar, presentado posteriormente a nuestra propuesta, es utiliza-do por H. Eriksson y M. Penker [4], donde se propone la construccin de un modelode objetivo/problema que facilita la identificacin de los procesos de negocio. En [4]tambin se define el patrn de negocio Business Goal Decomposition que puede serutilizado como gua para la descomposicin de los objetivos de la organizacin.


5/15

3.2 Identificacin de Roles del Entorno del Negocio

Una vez se han identificado los procesos de negocio, es preciso encontrar los agentesinvolucrados en su realizacin. Cada uno de estos agentes o actores del negocio de-sempea cierto papel (juega un rol) cuando colabora con otros para llevar a cabo lasactividades que conforman dicho caso de uso del negocio. De hecho, identificaremoslos roles que son jugados por agentes de la propia empresa (que incluyen trabajadores,departamentos y dispositivos fsicos) o agentes externos (como clientes u otros siste-mas). Por el momento nos centraremos en este ltimo tipo de roles, con los que laorganizacin interacta para llevar a cabo sus procesos de negocio. En nuestro ejem-plo tenemos los roles Cliente y Proveedor, claramente externos al sistema.

Para tener una visin general de los diferentes procesos de negocio de la organiza-cin, 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 loslmites y el entorno de la organizacin bajo estudio. Por esta razn, slo aparecern eneste diagrama los actores del negocio correspondientes a los roles externos al sistema,de forma que los procesos de negocio en los que slo tomen parte roles internos a laorganizacin no estarn conectados a ningn actor. En la Fig. 2 se muestra el diagra-ma de casos de uso del negocio para nuestro ejemplo; es un diagrama de casos de usoUML formado por casos de uso del negocio y actores. En el diagrama se muestraadems que el agente Cliente arranca la realizacin del caso de uso relacionado,mientras que Proveedorsimplemente participa en el caso de uso asociado.

Registrar pedido

Cliente

initiator

Fabricar producto

Gestionar almacen

Generar pedidos a proveedores Proveedor

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

3.3 Descripcin de los Casos de Uso del Negocio

El siguiente paso dentro del modelado del negocio es introducirse en cada uno de loscasos de uso del negocio identificados, para describirlo en detalle. Inicialmente serellena una plantilla de descripcin, y despus, a partir de la informacin reflejada endicha plantilla, se construye un conjunto de diagramas que describen completamenteel caso de uso del negocio. Nos centraremos en uno de los casos de uso del negociode nuestro ejemplo, Registrar Pedido, cuya descripcin se muestra en la Fig. 3. La

plantilla de descripcin de casos de uso del negocio inspirada en el conjunto devalores etiquetados utilizados en [4] para describir un proceso de negocio, contienelos campos objetivo (qu se intenta conseguir), descripcin (especificacin informalde lo que hace el proceso), prioridad (importancia del proceso, por ejemplo si esfundamental o bsico, de administracin, o de soporte), riesgos (por ejemplo errores o


6/15

fallos que pueden ocurrir al ejecutar este proceso), posibilidades (cambios o mejorasfuturas del proceso), y por ltimo, tiempo y coste aproximados de ejecucin. Estadescripcin puede ser validada fcilmente por los usuarios.

A continuacin, hemos de determinar los agentes internos que juegan un rol en elcaso de uso del negocio. Hasta el momento hemos identificado los roles que pertene-cen al entorno de la organizacin. Ahora es necesario estudiar laDescripcin (ver Fig.3) de cada caso de uso del negocio, y observar el conjunto completo de roles involu-crados, tanto externos como internos a la organizacin. Los roles del caso del uso delnegocio Registrar pedido son Cliente, Comercial, JefeTecnico, y JefeProduccion(siendo los tres ltimos internos al sistema).

Proceso de Negocio Registrar PedidoObjetivo Registrar Pedido de ClienteDescripcin 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 depar-tamento comercial quien introduzca el pedido, a peticin de un cliente que reali-z su pedido por telfono o lo envi por fax o correo ordinario al dpto. comercialde la empresa.

2. El empleado revisa el pedido (completndolo, si es necesario), y comienza suprocesamiento envindolo al jefe tcnico, encargado de su anlisis.

3. El jefe tcnico analiza la viabilidad de cada producto 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 es-tudia 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 pro-ducto pedido;

Si todos los productos de un pedido han sido aceptados, se crea una ordende trabajo para cada producto, a partir de una plantilla de fabricacin (laestndar si el producto estaba catalogado, o una nueva, especficamente

diseada para el producto, si ste no estaba en el catlogo). Cada orden detrabajo es enviada al jefe de produccin, y queda pendiente de su lanza-miento.

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

Prioridad BsicoRiesgos ...Posibilidades ...Tiempo Ejecucin ...

Coste de Ejecucin ...

Fig. 3. Descripcin parcial del caso de uso del negocioRegistrar pedido

El aspecto estructural de la colaboracin entre los roles para llevar a cabo un casode uso del negocio, puede ser representado en un diagrama de roles, en el que cadarol (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 queunos roles tienen de otros, as como las caractersticas (como la multiplicidad) de cadarelacin entre roles. Adems, este diagrama permite tambin mostrar las caractersti-cas de los roles identificados, tales como sus atributos y responsabilidades. Ortn yGarca Molina discuten con ms detalle el modelado de roles con UML en [8].


7/15

RoleJefeTecnico

*

*

RoleJefeProduccion

RoleComercial

RoleCliente

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

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

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 flujosalternativos (por ejemplo, rechazo o cancelacin de un pedido). Para mejorar la legi-bilidad, es conveniente asociar varios escenarios a un mismo caso de uso del negocio,en lugar de mostrar en una nica secuencia todas las posibilidades.

darCursoPedido()estudiarPedido()

* analizarFabricacProducto()

informarAnalisisPedido()planificarFabricacion()

aceptarPedido()

: JefeTecnico: Cliente : Comercial : JefeProduccion

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

Para mostrar de forma ms detallada el flujo de trabajo que realiza cada procesodel negocio, utilizaremos diagramas de actividades con calles (swimlanes), que llama-remos 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 actividadesque realiza dicho rol. El diagrama tambin muestra la informacin que necesita yproduce cada actividad, y la sincronizacin requerida entre las diferentes actividades.Los datos aparecen como objetos que fluyen entre las actividades y pueden tener unestado. Por ejemplo, la actividad Cursar pedido recibe un pedido propuesto e inicia surevisin (ver Fig. 6). Nos referimos a estos objetos como objetos de informacin.

Durante la descripcin de un proceso del negocio mediante un diagrama de proce-so, es posible encontrar una actividad cuya complejidad sea tal que sea necesariodescribirla mediante otro diagrama de proceso adicional. Por tanto, este nuevo dia-grama de proceso describir un subobjetivo en relacin con el objetivo ligado al pro-ceso del negocio original. De este modo los procesos de negocio se organizan jerr-quicamente. Tambin es posible mostrar en diferentes diagramas de proceso el flujonormal y los flujos alternativos.


8/15

Rellenar Pedido

Cursar pedido

Fin OK

Notificar rechazode pedido

Fin KO

Analizar viabilidad

Viable ?[ NO ]

Planificar produccion

[ SI ]

: JefeProduccion: JefeTecnico: Comercial: Cliente

p:Pedido[propuesto]

p:Pedido[rechazado]

p:Pedido[aceptado]

:Orden deTrabajo

[pendiente]

:Plantilla deProduccion

:Catalogo

:ProductoEspecial

p:Pedido[en_evaluacion]

p:Pedido[evaluado]

:Plantilla deProduccion

Ordenar fabricacionNotificar aceptacionde pedido

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

3.4 Especificacin de Reglas del Negocio

En una organizacin, tanto los procesos como los datos que estos manejan, estnrestringidos por las reglas del negocio. Estas reglas aseguran que la actividad de laempresa se lleva a cabo de acuerdo a restricciones impuestas desde el entorno (leyes onormas) o desde dentro de la propia organizacin.

Como afirma B. Whitenack [9], las reglas del negocio rara vez son capturadas deforma explcita durante el desarrollo del producto, a pesar de que suelen ser impor-tantes restricciones sobre el comportamiento del sistema. El hecho de que no exista unmarco de trabajo bien definido en el que situar las reglas, unido a la existencia de unagran variedad de tipos de reglas de difcil comprensin, hace que a menudo las reglasdel negocio sean ignoradas hasta la fase de implementacin.

Con el fin de tener en cuenta todos los tipos de reglas que aparecen en la especifi-cacin de requisitos, hemos utilizado la clasificacin descrita por J. Odell [7]. Estaclasificacin es sencilla pero completa, cubriendo prcticamente todos los tipos dereglas del negocio. Las categoras de reglas del negocio son las siguientes: Reglas de Restriccin: especifican polticas o condiciones que restringen la es-

tructura y comportamiento de los objetos y procesos. Estas reglas pueden ser divi-didas en reglas de estmulo-respuesta (que restringen el comportamiento y especi-fican las condiciones que deben cumplirse para activar una operacin), reglas derestriccin de operacin (que especifican condiciones que deben cumplirse antes ydespus de ejecutarse una operacin) y reglas estructurales (que especifican res-tricciones sobre los tipos de objetos y las asociaciones).


9/15

Reglas de Derivacin: especifican polticas y condiciones para inferir o calcularhechos (informacin) a partir de otros hechos existentes en el negocio.

Por otro lado, Eriksson y Penker [4] introducen otro tipo de reglas del negocio, lasReglas de Existencia, que establecen cundo puede existir un determinado objeto.

De acuerdo con esta clasificacin, recogemos de manera explcita cada tipo de re-gla en el modelo del negocio mediante la especificacin de las actividades y objetosde informacin que aparecen en los diagramas de proceso. Estas especificaciones serenen en un glosario. La Fig. 7 muestra la especificacin del objeto de informacinPedido y de las actividades Ordenar fabricacin yNotificar aceptacin de pedido.

...

Objeto de Informacin: PedidoAtributosCdigo de pedidoFecha de solicitudFecha de creacinFecha mxima de entregaConjunto de {Producto}ClienteImporte totalEstado actualRestricciones- El cdigo de pedido identificar unvoca-

mente el pedido, y ser asignado automti-camente por el sistema.

- Las fechas de solicitud y de creacin sernprevias 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 ysolamente un cliente

- El importe total del pedido ser calculado apartir del precio y unidades pedidas de cadaproducto incluido.

...

Clase del Dominio: -pendiente de especificar-...

...

Actividad: OrdenarfabricacinOrigen: Analizar viabilidadAgente: Jefe TcnicoPrecondiciones:- El estado del pedido es evaluado- La fabricacin de todo producto en el pedido es viable- Existe una plantilla de fabricacin para cada uno de

dichos productos.Postcondiciones:

- Ha sido creada una orden de trabajo para cada pro-ducto solicitado;

- El estado de cada orden de trabajo es pendiente.- Cada orden de trabajo ha sido enviada al jefe de pro-

duccin para su planificacin.Caso de Uso del sistema: -pendiente de especificar-

Actividad: Notificar aceptacin de pedidoOrigen: Analizar viabilidadAgente: ComercialPrecondiciones:- La fabricacin de todos sus productos es viable.Postcondiciones:- Se ha comunicado al cliente la aceptacin de su pe-

dido.- El estado del pedido es aceptado.Caso de Uso del Sistema: -pendiente de especificar-

...

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

Cada objeto de informacin se describe mediante un conjunto de atributos y susrestricciones de integridad (si las tuviera); por tanto, establecemos explcitamente lasreglas estructurales, de derivacin y de existencia. Por otro lado, la especificacin dela semntica de cada actividad contendr: origen (actividades que la preceden),agente (responsable de llevar a cabo la actividad), y pre ypost-condiciones (que esta-blecen qu tiene que cumplirse antes y despus de la actividad). Estos dos ltimos

campos recogen las reglas de operacin, mientras que las reglas de estmulo-respuestaquedan reflejadas mediante el origen, donde se expresa el orden entre las actividades,as como mediante aquellas precondiciones que representan las condiciones necesa-rias para ejecutar la actividad. El glosario tendr una estructura de hipertexto (referen-cias-cruzadas) con el objeto de mantener las relaciones de trazabilidad entre los pro-cesos del negocio y las clases y los casos de uso que especifican la funcionalidad delsistema.


10/15

4 Modelado de Requisitos: Modelos Conceptual y de Casos de Uso

Iniciales

A partir del modelo del negocio descrito en la seccin anterior, es posible obtener demanera sistemtica y directa, tanto la coleccin inicial de casos de uso del sistemacomo el modelo conceptual preliminar. A continuacin vamos a describir de maneraseparada cmo obtener cada modelo.

Los requisitos elicitados y especificados en esta fase sern incluidos en un docu-mento de especificacin de requisitos del software (ERS). Recomendamos el uso deuna plantilla de ERS estndar, como la IEEE 830-1998, pero siempre particularizadaal contexto de trabajo, marcado por el tipo de proyecto y la cultura de equipo de desa-rrollo.

4.1 Obtencin del Modelo Inicial de Casos de Uso del Sistema

Segn nuestra experiencia, las actividades del diagrama de proceso tienen el nivel degranularidad adecuado para ser asociadas a un caso de uso del sistema. De esta mane-ra, crearemos un caso de uso del sistema por cada actividad del diagrama de procesoque deba ser soportada por el sistema software. Por tanto, el rol que lleva a cabo laactividad ser el actor principal del caso de uso. Ntese que, de acuerdo con la defini-cin de caso de uso, no todas las actividades del diagrama de proceso sern conside-radas 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 (me-diante un formulario web, por ejemplo), sino que comunicara todos los datos por fax,telfono, o cualquier otro medio, como resultado de la actividad Rellenar pedido (verFig. 6). Como esta actividad se llevara a cabo fuera del sistema software, no aparece-ran en el diagrama de casos de uso del sistema ni la actividad Rellenar pedido, ni elrol Cliente (puesto que no interactuara con el sistema software). La Fig. 8 muestra eldiagrama de casos de uso del sistema obtenido para el proceso del negocioRegistrarPedido, correspondiente al diagrama de proceso de la Fig. 6, considerando que todaslas actividades sern soportadas por el sistema software.

Debemos sealar que algunos casos de uso no se obtendrn directamente a partirde los diagramas de proceso. Estos nuevos casos de uso se detectaran al describir loscasos de uso identificados y adquirir un mayor conocimiento sobre los requisitos quedeben ser soportados, y representaran funciones que debe llevar a cabo el sistemapara lograr algn objetivo asociado con algn caso de uso ya existente. Normalmentelos casos de uso detectados de esta manera sern casos de uso de soporte, puesto queno surgen directamente de la descripcin de los procesos de negocio. En nuestro

ejemplo, para Analizar viabilidad es necesario buscar en el catlogo de productos siun producto solicitado existe y, por tanto, este catlogo debe mantenerse actualizado.En consecuencia, aadimos el caso de uso Mantener Productos del Catlogo. Otroejemplo de un nuevo caso de uso seraMantener Plantillas de Fabricacin.

De este modo, el modelo del negocio permite obtener los casos de uso ms impor-tantes dentro de cada proceso del negocio, y adems facilita la determinacin delconjunto adecuado de pasos incrementales en el proceso iterativo de desarrollo, tal ycomo defiende Korson [5].


11/15

Analizar Viabilidad

Ordenar Fabricacion

JefeTecnico

Rellenar Pedido

Cliente

Notificar Aceptacion Pedido

Cursar Pedido

JefeProduccionPlanificar Produccion

Comercial

Notificar Rechazo Pedido

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 modela-do del negocio.

Cada caso de uso se describir mediante una plantilla que puede rellenarse a partirde la especificacin de la actividad asociada, que se encuentra recogida en el glosariocomo ya hemos visto. La plantilla que proponemos est basada en la de Coleman [3],a la que hemos aadido un campo para las postcondiciones del caso de uso, tal comose muestra en la Fig. 9.

Caso de Uso Ordenar Fabricacin

Descripcin Crear rdenes de trabajo para cada producto solicitado en el pedido, y enviar-las al jefe de produccin para dar comienzo a la planificacin de su fabricacin.

Actores Jefe tcnicoAsunciones - El estado del pedido es evaluado.

- Es viable la fabricacin de cada producto solicitado en el pedido.- Existe una plantilla de fabricacin para cada producto solicitado.

Postcondiciones - Ha sido creada una orden de trabajo para cada producto solicitado.- El estado de cada orden de trabajo es pendiente.- Cada orden de trabajo ha sido enviada al jefe de produccin

Pasos 1 REPETIR1.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.1.5 Enviar la orden de trabajo al jefe de produccin

Variaciones --

Req. No Funcionales --

Cuestiones --

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

Una vez descrito el caso de uso, se conectar a la especificacin de la actividadasociada en el glosario, con el objeto de mantener la trazabilidad entre los casos de

uso del negocio y los del sistema.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 expresarcaminos opcionales o alternativos en un caso de uso. No obstante, estamos de acuerdocon las recomendaciones ampliamente extendidas de no abusar de estas relaciones yno mostrarlas en los diagramas de casos de uso.


12/15

4.2 Obtencin del Modelo Conceptual Inicial

Los objetos de informacin que fluyen entre las actividades de un caso de uso delnegocio representan datos del dominio, por lo que suponen una buena base para crearel modelo conceptual inicial. Este modelo incluir los conceptos y sus relaciones y sedescribir mediante un diagrama de clases UML, en el que los conceptos se repre-sentan mediante clases (clases del dominio). La Fig. 10 muestra el diagrama de clasesque describe el primer modelo conceptual de nuestro ejemplo.

El modelo conceptual inicial ser refinado posteriormente gracias a la experienciadel modelador. Creemos que este es un buen punto de partida, en lugar de abordar laconstruccin del modelo conceptual partiendo de la nada.

As, cada objeto de informacin del diagrama de proceso se convertir ahora en unconcepto (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 cada objeto de infor-macin obtendremos la definicin del concepto asociado, es decir, sus atributos, rela-ciones con otras clases y restricciones. Por ejemplo, a partir de la especificacin dePedido mostrada en la Fig. 7, podramos obtener: i) los atributos codigo, fechaSolici-tud, fechaCreacion, fechaMaxEntrega, importeTotal, estadoActual; ii) las relacionesCliente-Pedido y Pedido-Producto, y iii) restricciones que podran ser expresadastextualmente o bien mediante OCL (Object Constraint Language), como {fechaMa-

xEntrega>fechaCreacion}.Ntese adems que cuando un modelo conceptual evoluciona hacia un diagrama de

clases, algunas responsabilidades se pueden obtener a partir de ciertas restricciones yaespecificadas en el glosario. Por ejemplo, la clase Pedido podra tener responsabilida-des como obtenerProductos, calcularFechaMaxEntrega, calcularImporteTotal ocambiarEstado.

Orden de Trabajo

Cliente

Producto Especial

Pedido 0..*genera

1..*

Producto

1..*

0..*

Plantilla de Fabricacion

0..*es la base de

Producto Catalogado

Catalogo

tiene

1..*

1 1

1

1

1

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

En esta etapa del desarrollo, es aconsejable centrarse ms en la identificacin y es-pecificacin de los conceptos que en las relaciones entre ellos, puesto que stas sernrefinadas en fases posteriores. Por el momento, podemos concentrarnos en las asocia-ciones del tipo debe-conocer y en la generalizacin para identificar las relacionesentre conceptos ms importantes. Por ejemplo, a partir del glosario podemos estable-cer que un pedido debe conoceral cliente que lo realiza y los productos que lo com-ponen (ver Fig. 7).

Por otro lado, alguno de los roles identificados en el modelo del negocio, y portanto especificado en el modelo de roles, podra ser incluido como una clase en elmodelo conceptual. Es el caso de la clase Cliente en nuestro ejemplo.


13/15

De igual forma que conectamos en el glosario las actividades con los casos de usodel sistema, vincularemos cada objeto de informacin con la clase del dominio que lorepresenta en el sistema.

El modelo del negocio permite adems identificar aquellas clases cuyo comporta-miento depende de un conjunto no trivial de estados alcanzables. En estos casos, serainteresante definir una mquina de estados mediante un diagrama statechartUML.Estas clases se detectan con facilidad en los diagramas de proceso, puesto que secorresponden con objetos de informacin etiquetados con varios estados diferentes.En nuestro ejemplo, Pedido sera candidato para construir una mquina de estadosque mostrase los estados de un pedido (propuesto, en_evaluacin, evaluado, aceptado

y rechazado) y los eventos que producen los cambios entre estados.

4.3 Representacin de las Reglas del Negocio

En este apartado comentaremos con ms detalle cmo son llevadas al modelo derequisitos las diferentes reglas del negocio que han sido recogidas en el glosario du-rante el modelado del negocio.

Las reglas de negocio estructurales, de derivacin y de existencia quedan plena-mente expresadas en el modelo conceptual. La propia sintaxis del diagrama de clasesde UML permite representar los atributos de los conceptos y sus relaciones, mediantelos atributos de las clases correspondientes y asociaciones entre stas. Las reglas dederivacin pueden ser especificadas mediante expresiones OCL dentro de constraintsde UML colocadas en el diagrama cerca del elemento derivado, o bien dentro de notasconectadas a dicho elemento. La multiplicidad de las asociaciones permite por ejem-plo representar las reglas del tipo de un pedido ser solicitado por uno y slo un

cliente. Otras restricciones pueden expresarse en OCL utilizando constraints cercanasa los elementos a los que restringen, como {fechaMaxEntrega>fechaCreacion} parala clase Pedido. Tambin es posible utilizar OCL o lenguaje natural para expresar unarestriccin dentro de una nota conectada a los elementos afectados por dicha restric-cin. Las reglas de existencia estn implcitas en el modelo conceptual, por ejemploen el caso de un objeto agregado, como Catlogo, cuya existencia no es posible amenos que existan los objetos que lo componen.

Por otro lado, las reglas de negocio de operacin quedan expresadas en la plantillade descripcin de los casos de uso, puesto que las precondiciones y postcondicionesde las operaciones especificadas en el glosario se recogen respectivamente en loscampoAsunciones y Postcondiciones.

Por ltimo, las reglas de estmulo/respuesta, expresadas mediante los campos ori-gen yprecondiciones de la especificacin de las actividades, quedarn recogidas en elcampoAsunciones de las plantillas de casos de uso.

4.4 Identificacin de Requisitos No Funcionales

Para completar esta fase debemos establecer los requisitos no funcionales, relacio-nados por ejemplo con el rendimiento, la disponibilidad o la seguridad. Cuando estnasociados a un caso de uso, podrn especificarse en la plantilla de caso de uso pro-puesta. Los requisitos no funcionales que afecten a varios casos de uso o sean globa-


14/15

les a toda la organizacin, sern recogidos en el apartado correspondiente de la plan-tilla de ERS elegida.

El modelo del negocio puede ayudar a encontrar requisitos no funcionales, tal ycomo se indica en [4], pues por ejemplo los campos tiempo de ejecucin y coste deejecucin de la plantilla de descripcin de casos de uso del negocio expresan necesi-dades no funcionales que deben ser trasladadas a la plantilla de ERS y asociadas a loscorrespondientes casos de uso del sistema. Por otro lado, el que los procesos del ne-gocio sean el resultado del anlisis de los objetivos de la organizacin, permite quelos requisitos (funcionales y no funcionales) del sistema puedan ser validados y veri-ficados contra los objetivos.

5 Conclusiones

Este trabajo presenta una estrategia para abordar el modelado del negocio y el anlisisde requisitos, en la que una primera versin del modelo de casos de uso y del modeloconceptual se obtienen de forma sencilla, a partir del modelo del negocio basado en eluso de diagramas de actividades UML.

Con las guas proporcionadas, el modelador dispone de un modo sistemtico deidentificar y organizar casos de uso, y de identificar y definir las clases del modeloconceptual. Los procesos de negocio de la organizacin se identifican partiendo desus propios objetivos, y se describen mediante flujos de actividades que se represen-tan mediante diagramas de actividades UML. De este modo, los casos de uso delsistema se obtienen a partir de las actividades de los procesos del negocio, se organi-zan jerrquicamente y se facilita su desarrollo iterativo e incremental, de acuerdo con

lo indicado por Korson [5].Las clases del modelo conceptual se obtienen a partir de los objetos de informacinque fluyen entre las actividades. Nos gustara subrayar, como una caracterstica im-portante de nuestro enfoque, que el modelado de los casos de uso del sistema y elmodelado conceptual se realizan en paralelo, de acuerdo con Korson [6], quien esta-blece que esto es crucial para obtener casos de uso correctos, puesto que es necesarioentender 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, las reglas delnegocio de la organizacin se recogen en un glosario, en forma de especificacin delas actividades y de los casos de uso asociados, as como de los objetos de informa-cin y de las clases que los implementan. Esto permite mantener las correspondientesrelaciones de trazabilidad entre los diferentes artefactos del modelado.

En este trabajo hemos expuesto cmo el modelado del negocio puede facilitar laidentificacin de los requisitos tanto funcionales como no funcionales del sistema.Adems, el hecho de que tales requisitos surjan de la descripcin de los procesos delnegocio, y que stos sean el resultado del anlisis de los objetivos de la organizacin,posibilita que los requisitos del sistema sean validados y verificados contra los objeti-vos del negocio


15/15

Referencias

1. Booch, G., Rumbaugh, J., Jacobson, I.: The Unified Modeling Language User Guide. Addi-son-Wesley (1999)

2. Cockburn, A.: Using Goal-Based Use Cases. JOOP, Vol. 10, No. 7 (Nov/Dec 1997) 56-623. Coleman, D.: A Use Case Template: Draft for discussion.

http://www.bredemeyer.com/use_case.pdf. (1998)4. Eriksson, H.E., Penker, M.: Business Modeling with UML. Business Patterns at Work. John

Wiley & Sons, Inc. (2000)5. Korson, T.: Misuse of Use Cases.

http://software-architects.com/publications/korson/korson9803om.htm. (1998)6. Korson, T.: Constructing Useful Use Cases.

http://software-architects.com/publications/korson/usecase3. (1999)7. Martin, J. Odell, J.J.: Object-Oriented Methods: A Foundation. Prentice Hall. (1997)8. Ortn, M.J., Garca-Molina, J.: Modelado con Roles en UML. IV Jornadas de Ingeniera del

Software y Bases de Datos. Cceres, Spain (1999)9. Whitenack, B.: RAPPeL: A Requirements Analysis Process Pattern Language for Object-

Oriented Development. In: Coplien, J.O., Schmidt, D.C. (eds.): Pattern Languages of Pro-gram Design. Addison-Wesley (1995) 259-291

jira_ortin893.pdf

Documents