Identicacin de Patrones de Reutilizacin de Requisitos de Sistemas de Informacin

A. Durn Toro, A. Ruiz Corts, R. Corchuelo Gil y M. Toro Bonilla

Departamento de Lenguajes y Sistemas Informticos, Facultad de Informtica y Estadstica, Universidad de Sevilla, Avda. Reina Mercedes s/n, 41012 Sevilla, Espaa {amador,aruiz,corchu,mtoro}@lsi.us.es

Resumen En este artculo se exponen algunos de los resultados de la aplicacin de las plantillas y patrones de requisitos presentadas en la edicin previa del WER [6]. Uno de los resultados ms interesantes de la normalizacin del formato de los requisitos ha sido la posibilidad de compararlos e identicar patrones de reutilizacin, tanto a nivel de requisitos de cliente (requisitosC, normalmente expresados en lenguaje natural) como a nivel de requisitos de desarrollador (requisitosD, habitualmente modelos conceptuales), que facilitan el desarrollo y mejoran la calidad de las especicaciones de requisitos. La relaciones de rastreabilidad entre requisitosC, requisitosD, e incluso elementos de menor nivel de abstraccin como componentes software, ha permitido tambin plantear la posibilidad de reutilizar estructuras complejas, desde requisitosC hasta cdigo, obteniendo as una reutilizacin vertical que abarque distintos niveles de abstraccin del desarrollo de software. Palabras clave: reutilizacin de requisitos, patrones de requisitos

1 Introduccin
El nmero de propuestas de reutilizacin en ingeniera de requisitos es an escaso [11, 12, 13], sobre todo a nivel de requisitos de cliente o requisitosC [17, 2], normalmente expresados en lenguaje natural. En nuestro caso, la utilizacin en ms de 80 prcticas acadmicas y en tres proyectos reales an en desarrollo de las plantillas y patrones lingsticos para requisitosC descritos en [6, 7], ha puesto de maniesto la posibilidad de aplicar tcnicas de reutilizacin durante la fase de ingeniera de requisitos. Como resultado de esta experiencia se han identicado requisitos que, con pequeas variaciones, aparecen en un elevado nmero de desarrollos. A dichos requisitos, una vez generalizados al eliminar los detalles especcos, los hemos denominado patrones de reutilizacin de requisitos, o abreviadamente, patronesR. La estructura del artculo es la siguiente. En las secciones 2 y 3 se describen algunos de los patronesR identicados de requisitosC y D respectivamente. En la seccin 4 se comentan algunos trabajos relacionados y, por ltimo, en la seccin 5 se exponen las conclusiones y el trabajo por realizar.
Este trabajo est nanciado por el proyecto "MENHIR" de la CICYT. TIC 970593C0501, Ministerio de Educacin y Ciencia de Espaa.

2 Patrones de reutilizacin de requisitosC

Las plantillas y patronesL para requisitosC descritas en [6] distinguen tres tipos de requisitos: Requisitos de informacin: describen qu informacin debe almacenar el sistema para satisfacer las necesidades de clientes y usuarios. Identican los conceptos relevantes sobre los que se debe almacenar informacin y los datos especcos que son de inters. Requisitos funcionales: describen los casos de uso [1] en los que los diferentes actores utilizan los servicios proporcionados por el sistema. Cada requisito funcional identica el evento de activacin, las pre y postcondiciones y los pasos que componen el caso de uso, as como las posibles excepciones. Requisitos no funcionales: describen aquellas caractersticas no funcionales que los clientes y usuarios desean que tenga el sistema a desarrollar. En las siguientes secciones se describen algunos de los patronesR identicados para los dos primeros tipos de requisitosC, es decir, patronesR . 2.1 PatronesR de requisitos de informacin

Dentro de los requisitos de informacin se han identicado varios patronesR . Por un lado se ha cuanticado el nmero de veces que cada patrnR ha aparecido (ver gura 1), y por otro lado, para cada patrn se ha cuanticado el nmero de veces que aparece cada dato especco.

90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00%

Cliente/Socio

Producto/Artculo

Empleado Venta/Factura

Proveedor Pedido a proveedor Albarn

Figura1. Frecuencia de aparicin de algunos patronesR de requisitos de informacin

RI Informacin sobre clientes/socios Descripcin El sistema deber almacenar la informacin correspondiente a tes/socios del negocio . En concreto: Datos Nombre y apellidos del cliente/socio (100%) Especcos Direccin del cliente/socio (93.75%) Nmero de identicacin scal del cliente/socio (90.63%) Nmeros de telfono del cliente/socio (84.38%) Cdigo del cliente/socio (53.13%) Fecha de alta/antigedad del cliente/socio (34.38%) Fecha de nacimiento/edad del cliente/socio (34.38%) Sexo cliente/socio (25%) Nmero de cuenta bancaria del cliente/socio (9.38%) Direccin de correo electrnico del cliente/socio (6.25%) Otros datos especcos del cliente/socio (81.25%) Figura2. PatrnR Cliente/Socio

los clien-

Siguiendo la clasicacin de reutilizacin descrita en [11] y [13], en la que los requisitos se clasican como no reutilizables, directamente reutilizables por composicin y basados en parmetros para reutilizar por generacin, los patronesR de requisitos de informacin seran directamente reutilizables, aunque probablemente necesitaran adaptaciones especcas en cada caso. Como ejemplo ms signicativo, en la gura 2 puede verse el patrnR correspondiente a los requisitos de informacin relativos a clientes/socios, en el que se han ordenado los distintos datos especcos segn su frecuencia de aparicin. Todos los patronesR de este tipo de requisitos presentan un porcentaje elevado de casos en el que se incluyen otros datos especcos del sistema que se est especicando que no pueden generalizarse, lo que indica claramente la necesidad de adaptacin a cada proyecto concreto. En nuestro caso, se han englobado como otros a aquellos datos especcos con una incidencia menor al 5%. Los patronesR de informacin identicados responden nicamente a un anlisis cuantitativo de su utilizacin en prcticas acadmicas. Lo ideal sera combinar estos datos cuantitativos, que pueden ayudar a descubrir patronesR que pasan inadvertidos, con informacin cualitativa proveniente de expertos en dominios de problemas especcos, de forma que se obtengan patronesR certicados de alta calidad que puedan estar a disposicin de los ingenieros de requisitos en algn tipo de repositorio. 2.2 PatronesR de requisitos funcionales

En el caso de los requisitos funcionales, dada la dicultad de su anlisis cuantitativo debido a su mayor complejidad y heterogeneidad, se ha optado por una anlisis cualitativo aunque reforzado cuantitativamente, ya que los 4 patronesR de requisitos funcionales identicados aparecen en todas las especicaciones estudiadas, aunque siempre con detalles especcos en cada caso. Aplicando la clasicacin de [11, 13], estos patronesR seran requisitos basados en parmetros, reutilizables por lo tanto mediante generacin al darles valores concretos

a los parmetros. En la terminologa de Jacobson [10, pgs. 126127], seran casos de uso parametrizados o plantillas de casos de uso. Estos cuatro patronesR corresponden a los tpicos conceptos de alta, baja, modicacin y consulta (CRUD, Create, Read, Update y Delete en ingls [1, pg. 401]) y describen los correspondientes cuatro casos de uso genricos, de los que los correspondientes a la creacin y a la modicacin pueden verse en las guras 3 y 4 y se describen en las siguientes secciones.

PatrnR Crear/Dar de alta/Registrar El patrnR Crear/Dar de alta/Registrar de la gura 3 describe el caso de uso tpico en que un actor proporciona nueva informacin al sistema como respuesta a una nueva situacin en el entorno del que el sistema debe mantener informacin. Siguiendo varias recomendaciones para redactar casos de uso de [3, 16], se han evitado referencias especcas a aspectos de implementacin o de interfaz de usuario. Ms concretamente, se ha utilizado el patrn Presentacin descrito en [4], que aconseja indicar qu datos debe mostrar o solicitar el sistema sin especicar cmo lo va a hacer. Las situaciones excepcionales habituales en este tipo de caso de uso suelen ser que el actor intente introducir como nueva una informacin ya existente o que cancele el proceso durante la introduccin de los datos que le solicita el sistema.

RF Descripcin

{ Crear, Dar de alta, Registrar } X El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando { un cliente realiza una compra por primera vez, una persona solicita su ingreso como socio, . . . } Precondicin La informacin correspondiente al nuevo X no est almacenada todava Secuencia Paso Accin normal 1 El actor solicita al sistema comenzar el proceso de {crear/dar de alta/registrar} un nuevo X 2 El sistema solicita los siguientes datos correspondientes al nuevo X : datos solicitados por el sistema 3 El actor proporciona los datos requeridos y solicita al sistema que los almacene 4 El sistema almacena los datos proporcionados e informa al actor de que el proceso ha terminado con xito Postcondicin El sistema ha almacenado la informacin correspondiente al nuevo X Excepciones Paso Accin 3 Si el sistema detecta que los datos proporcionados ya estn almacenados, el sistema informa de la situacin al actor permitindole modicar los datos proporcionados, a continuacin este caso de uso contina 3 Si el actor solicita cancelar la operacin, el sistema cancela la operacin, a continuacin este caso de uso termina Figura3. PatrnR Crear/Dar de alta/Registrar

PatrnR Modicar/Editar El patrnR correspondiente a la tpica modicacin o edicin de datos puede verse en la gura 4, en el que tambin se han aplicado los patrones Especicar y Presentacin de [4]. El patrnR indica explcitamente en los pasos 4 y 5 cules son los datos que muestra al actor y cules de los datos mostrados le deja modicar, ya que habitualmente ambos conjuntos de datos no coinciden. Una posible adaptacin del patrn puede consistir en identicar distintos conjuntos de datos mostrados y datos modicables en funcin del tipo de actor que est participando en el caso de uso, permitiendo de esta forma especicar requisitos de seguridad de forma integrada con los requisitos funcionales. Una posibilidad de excepcin en este caso de uso, aparte de la cancelacin por parte del actor, es que la informacin modicada viole alguna restriccin.

RF Descripcin

{ Modicar, Editar } X El sistema deber comportarse tal como se describe en el siguiente caso de uso cuando { un cliente/socio comunica un cambio de alguno de sus datos, . . . } Precondicin El sistema tiene almacenada la informacin correspondiente al X a { modicar, editar } Secuencia Paso Accin normal 1 El actor solicita al sistema comenzar el proceso de { modicar, editar } la informacin correspondiente a un X 2 El sistema solicita que se identique al X a { modicar, editar } 3 El actor identica el X a { modicar, editar } 4 El sistema muestra los siguientes datos correspondientes al X a modicar: datos mostrados por el sistema 5 El sistema permite al actor modicar los siguientes datos: datos que pueden modicarse 6 El actor modica los datos que el sistema le permite y solicita al sistema que los almacene 7 El sistema modica los datos correspondientes al X a modicar e informa al actor de que el proceso ha terminado con xito Postcondicin El sistema ha actualizado la informacin correspondiente al X { modicado, modicada } Excepciones Paso Accin 6 Si la modicacin de la informacin del X viola alguna restriccin , el sistema comunica la situacin al usuario y cancela la operacin, a continuacin este caso de uso termina 6 Si el actor solicita cancelar la operacin, el sistema cancela la operacin, a continuacin este caso de uso termina Figura4. PatrnR Modicar/Editar

3 Patrones de reutilizacin de requisitosD

Tambin es posible identicar patronesR en los requisitos orientados a los desarrolladores o requisitosD [17, 2], normalmente expresados mediante modelos conceptuales. Siguiendo las relaciones de rastreabilidad establecidas con los requisitosC, aquellos requisitosD que modelen los patronesR sern los patronesR de requisitosD correspondientes, abreviadamente patronesR . 3.1 PatronesR para requisitos de informacin

Los patronesR de requisitos de informacin estarn formados por aquellos tipos de objetos, con sus correspondientes atributos y asociaciones, que modelan la informacin que describen los patronesR . Por ejemplo, para modelar el patrnR Cliente/Socio se tendra el patrnR formado por el tipo de objetos Cliente/Socio que puede verse en la gura 5 asociado al patrnR citado mediante la correspondiente relacin de rastreabilidad.

<<Patrn-R>> Cliente/Socio

traced to

nombre : String apellidos : String direccin : String telfonos : Set( Integer ) fechaAlta : Date fechaNacimiento : Date sexo : enum { hombre, mujer } fax : Integer correoElectrnico : String

Figura5. PatrnR

Cliente/Socio

Aunque en el ejemplo la relacin entre patrnR y patrnR es 1:1, no siempre tiene porqu ser el caso. Puede que la estructura de rastreabilidad sea ms compleja y tenga la forma de una relacin : , de forma que un grupo de requisitosC pueda rastrearse hasta un grupo de requisitosD.

3.2 PatronesR

para requisitos funcionales

Los patronesR para requisitos funcionales estn compuestos por descripciones de operaciones del sistema, denominadas joint actions en [5], que modelan la funcionalidad descrita en los casos de uso correspondientes a los patronesR de requisitos funcionales. En estas descripciones, dado un tipo de objetos T, T.new se entender como el conjunto de objetos de tipo T que se crean durante la operacin, tal como se propone en la versin de OCL [14] descrita en [5]. Tambin se utilizar la palabra reservada respuesta para representar la respuesta que el sistema enva al actor como consecuencia de la realizacin de ciertas acciones.

Patrn-R Crear/DarDeAlta/Registrar El patrnR correspondiente al patrnR Crear/Dar de alta/Registrar puede verse en la gura 6. Este patrn admite diversas variaciones. Por ejemplo, puede que no todos los atributos del objeto que se crea se pasen como parmetros, algunos pueden tomar un determinado valor inicial. Tambin es posible que no se hayan identicado atributos clave para el tipo de objetos en cuestin, en cuyo caso no habra ninguna precondicin. Otra posibilidad sera crear ms de un objeto a la vez, bien varios de tipo X, bien uno de tipo X y otros de otros tipos que tengan alguna asociacin con los objetos del tipo X.

Operacin Sistema {Crear, DarDeAlta, Registrar} X Descripcin {Crea, Da de alta, Registra} un nuevo Parmetros p : Tipo
... p : Tipo k : Tipo -- parmetro clave ... k : Tipo -- parmetro clave

Precondiciones Precondiciones (OCL) Postcondiciones

pre : No existe un

en el sistema con el mismo valor de k , . . . , k

pre : not X .allInstances->exists( x | x.k = k and ... and x.k = x.k )

post : Existe un nuevo X cuyos atributos coinciden con los parmetros post : Slo se ha creado un nuevo X post : El sistema informa de que el proceso ha terminado con xito
post : X .new->exists( x | x.p = p and x.k = k ) -- i:1..q, j:1..r post : X .new->size = 1 post : respuesta = " X { creado, dado de alta, registrado } con xito"

Postcondiciones (OCL)

Excepciones Excepciones (OCL)

pre : El sistema informa de que ya existe un mismos datos

not pre : respuesta = "Error: X

en el sistema con los

ya existente"

Figura6. PatrnR

Crear X

Patrn-R Modicar/Editar El patrnR correspondiente al patrnR Modicar/Editar puede verse en la gura 7. Este patrnR tambin admite varias alternativas. Por ejemplo, crear varias operaciones de sistema para modicar determinada informacin sobre el objeto, en lugar de tener una nica operacin para modicar todas las caractersticas modicables, o permitir la modicacin de cierta informacin del objeto en funcin del tipo de usuario que realice la operacin.

Operacin Sistema {Modicar, Editar} X Descripcin {Modica, Edita } un X Parmetros x : X -- el X a eliminar

... p : Tipo

p : Tipo

Precondiciones Precondiciones (OCL) Postcondiciones Postcondiciones (OCL) Excepciones Excepciones (OCL)

pre : los parmetros no violan ninguna restriccin pre : x cumple las condiciones para poder ser modicado
pre : not p ... p violan alguna restriccin

post : Los atributos de x coinciden con los parmetros post : El sistema informa de que el proceso ha terminado con xito
post : x.p = p and ... x.p = p post : respuesta = " X { modificado, editado } con xito"

pre : El sistema informa de que los nuevos valores no son aceptables pre : El sistema informa de que el X no puede ser modicado
not pre : respuesta = "Error: los nuevos valores no son aceptables" not pre : respuesta = "Error: X no puede ser modificado"

Figura7. PatrnR Modicar X

4 Trabajos relacionados
A parte del ya citado [10], en [15, pgs. 222-231] se plantea tambin la idea de patrones de requisitos, aunque con un formato especco similar al que se usa para los patrones de diseo [9] e incluyendo los requisitosD asociados, de forma similar a la planteada en este artculo, aunque utilizando tcnicas estructuradas basadas en diagramas de ujo de datos. Sobre la reutilizacin de requisitos en familias de aplicaciones similares existen trabajos previos como [8], que se basa ms en modelos (requisitosD) que en requisitos en lenguaje natural (requisitosD). En [11] y [13] se estudia, dentro del dominio de problemas de los sistemas de planicacin de misiones de naves espaciales, la clasicacin de requisitosC en funcin de su reusabilidad como no reutilizables, reutilizables directamente (componentes) y parametrizados (generadores). Para hacer que los requisitos no reutilizables pasen a una de las otras dos categoras se proponen la tres siguientes heursticas bsicas: Eliminar referencias especcas: evitar hacer referencias especcas dentro de un requisito. Por ejemplo, si se est desarrollando el sistema , evitar usar frases como "El sistema X deber . . . " y usar en su lugar "El sistema deber . . . ", con lo cual podran reutilizarse requisitos similares en varios desarrollos. Usar trminos comunes: utilizar nombres lo ms comunes posibles dentro de un determinado dominio de problemas, relegando las diferencias especcas de cada proyecto a los respectivos glosarios de trminos. Separar lo especco de lo genrico: detectar qu partes de un requisito son generales y reutilizables y qu partes son especcas, y separar stas ltimas en uno o

ms requisitos aparte. Una idea parecida al patrn Especicar de [4] que se describe a continuacin. En [12] se exponen diez heursticas generales sobre la introduccin de la reutilizacin en el proceso de ingeniera de requisitos que han inuido en nuestros resultados. Bsicamente se propone: identicar familias de sistemas en los que los requisitos suelan coincidir desarrollar requisitos parametrizables abstractos (una idea similar a la presentada en este artculo) separar los aspectos especcos de los generales intentar identicar patrones de requisitos al trabajar en dominios especcos (es decir, patronesR) intentar reutilizar tambin los procesos de obtencin de ciertos tipos de requisitos, es decir las preguntas a realizar a los clientes y usuarios, las consideraciones a tener en cuenta a la hora de especicarlos, etc. En la bibliografa consultada tambin se han hallado patrones de requisitos a un nivel de abstraccin ms alto. En [4] se proponen los tres siguientes: Patrn Especicar: este patrn aconseja describir cmo puede el usuario de un sistema seleccionar (especicar) una determinada informacin (para modicarla, eliminarla o consultarla) en un requisito separado y hacer referencia a dicho requisito cuando sea necesario. Por ejemplo, un requisito X podra establecer que "el sistema deber permitir al usuario seleccionar a los clientes por su nmero de DNI, por sus apellidos o por su nmero de telfono" y posteriormente otro que dijera que "el sistema deber permitir a los usuarios modicar la informacin correspondientes a los clientes seleccionados mediante el procedimiento descrito en el requisito X". Abstrayendo y adaptando el patrn a las ideas expuestas en este artculo, podra reformularse para que aconsejara no especicar la forma en que un actor selecciona o identica una determinada informacin en los casos de uso en que fuera necesario, sino sacar dicho procedimiento factor comn en un caso de uso abstracto e incluirlo en los casos de uso que fuera necesario (ver gura 8). Otra posibilidad, que es la contemplada en los patronesR descritos previamente, es no indicar cmo puede el usuario seleccionar o identicar una determinada informacin, dejando este tipo de detalles para fases posteriores del desarrollo. Patrn Presentacin: este patrn, tambin aplicado en los patronesR presentados, recomienda limitarse a indicar qu datos debe solicitar o presentar el sistema sin entrar en detalles concretos de interfaz de usuario. Patrn Priorizar: este otro patrn sugiere que, en el caso de que el usuario desee poder ordenar (priorizar) la informacin presentada por el sistema, se separen las posibles formas de ordenar dicha informacin en un requisito aparte y se referencie desde los que sea necesario, de forma similar al patrn Especicar.

Gestin de X

Crear X

Modificar X

<<includes>> <<includes>>

Usuario

Eliminar X

<<includes>>

Identificar X

Consultar X

Figura8. Aplicacin del patrn Especicar en los casos de uso

5 Conclusiones y trabajo futuro

En este artculo se han presentado algunos de los resultados de la normalizacin de requisitos mediante plantillas y patrones lingsticos, principalmente los basados en la reutilizacin de requisitos o grupos de requisitos. Uno de los riesgos potenciales de los patrones de requisitos es intentar forzar la realidad del problema para que encaje dentro de los patrones identicados, lo que en general es un problema de la reutilizacin en cualquier fase del desarrollo de software. El ingeniero de requisitos debe utilizar los patrones conociendo este riesgo, y en cualquier caso, consultar con los clientes y usuarios la posibilidad de adaptar el problema a los patrones para reducir los costes del desarrollo. En un futuro esperamos identicar nuevos patronesR, sobre todo a partir de la disponibilidad del prototipo de herramienta CASE para ingeniera de requisitos (guras 9, 10) que se ha desarrollado como parte del proyecto CICYT MENHIR, lo que permitir el tratamiento automatizado de las especicaciones de requisitos as como el desarrollo de asistentes automatizados que ayuden a aplicar las ideas presentadas en este artculo o la aplicacin automtica de mtricas.

Referencias
[1] G. Booch, J. Rumbaugh, and I. Jacobson. The Unied Modeling Language User Guide. AddisonWesley, 1999. [2] J. W. Brackett. Software Requirements. Curriculum Module SEICM191.2, Software Engineering Institute, Carnegie Mellon University, 1990.

[3] A. Cockburn. Structuring Use Cases with Goals. JOOP, Sept. y Nov./Dic. 1997. [4] C. Creel. Requirements by Pattern. Software Development, Diciembre 2000. Disponible en http://www.sdmagazine.com/ breakrm/features/s9912f4.shtml. [5] D. F. DSouza and A. C. Wills. Objects, Components, and Frameworks with UML: The Catalysis Approach. AddisonWesley, 1999. [6] A. Durn, B. Bernrdez, A. Ruiz, and M. Toro. A Requirements Elicitation Approach Based in Templates and Patterns. In WER99 Proceedings, Buenos Aires, 1999. [7] A. Durn, B. Bernrdez, M. Toro, R. Corchuelo, A. Ruiz, and J. Prez. Expressing Customer Requirements Using Natural Language Requirements Templates and Patterns. In IMACS/IEEE CSCC99 Proceedings, Atenas, 1999. [8] A. Finkelstein. Reuse of Formatted Requirements Specications. Journal of Software Engineering, Septiembre 1998. [9] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [10] I. Jacobson, M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. AddisonWesley, 1997. [11] B. Keepence, M. Mannion, and S. Smith. SMARTRe Requirements: Writing Reusable Requirements. In Proceedings of the IEEE Symposium on Engineering of ComputerBased Systems, 1995.

Figura9. Vista de requisitosC de la herramienta CASE

Figura10. Vista de requisitosD de la herramienta CASE

[12] W. Lam, J. A. McDermid, and A. J. Vickers. Ten Steps Towards Systematic Requirements Reuse. Requirements Engineering Journal, 2:102113, 1997. [13] M. Mannion, H. Kaindl, and J. Wheadon. Reusing Single System Requirements from Application Family Requirements. In Proceedings of the International Conference on Software Engineering, 1999. [14] Rational Software Corporation. Object Constraint Language Specication, 1.1 edition, Septiembre 1997. Disponible en http://www.rational.com. [15] S. Robertson and J. Robertson. Mastering the Requirement Process. AddisonWesley, 1999. [16] C. Rolland and C. Ben Achour. Guiding the Construction of Textual Use Case Specications. Data & Knowledge Engineering Journal, 25(12), 1998. [17] H. D. Rombach. Software Specications: A Framework. Curriculum Module SEICM 112.1, Software Engineering Institute, Carnegie Mellon University, 1990.