Uml Identificacion De Autores

La Especificacio n de Requisitos con Casos de Uso: Buenas y Malas

Practicas

Jose Antonio Pow Sang Portillo

Pontificia Universidad Cato lica del Peru

Av. Universitaria cdra. 18, San Miguel

Lima-32- PERU

japowsang@pucp.edu.pe

Resumen. El uso de UML como estandar para la construccio n de software se ha extendido en los

ultimos an os. Es por eso que el empleo de los casos de uso, como parte del estandar UML, se ha

incrementado.

El propo sito de los casos de uso es describir en lenguaje natural la funcionalidad completa de un

sistema a desarrollar y su empleo se realiza en el proceso de especificacio n de requisitos del sistema.

Lamentablemente, la bibliografıa existente, muestra muchas formas de aplicar los casos de uso y no

son pocas las veces en que su empleo es inadecuado. Algunas de las causas son: mala interpretacio n

del estandar UML y secuencia incorrecta de actividades para la creaci o n de casos de uso.

Este artıculo presenta un esquema de trabajo para afrontar el proceso en mencio n utilizando casos de

uso. Se incluye, en este esquema, las actividades que se deben realizar, la utilizacio n correcta de casos

de uso y los errores que se cometen frecuentemente en cada una de las actividades.

Cabe resaltar que este esquema de trabajo es aplicado en los proyectos que forman parte de los cursos

del area de Ing. de Software de la PUCP a nivel pre y post grado. Tambie n, es utilizado en las tesis

para optar el tıtulo de Ing. Informatico.

Palabras claves: Especificacio n de Requisitos de Software, Ingenierıa de Requisitos, Casos de Uso,

Escenarios.

Abstract. The use of UML as a standard to construct software has been increased over the last years.

For this reason, the utilization of use cases has been growing.

The purpose of the use cases is to describe software functionality using natural language. Use cases

are used in software requirement specification process.

Unfortunately, the authors show many ways to apply use cases and their use is not according to UML.

Sometimes people misunderstand UML standard and follow an inadequate sequence of activities to

obtain requirements with use cases.

This article shows a method to face requirements process with use cases. This article also includes the

correct use of use cases and common mistakes. The method is used in undergraduate and postgraduate

Software Engineering courses at PUCP.

Keywords: Software Requirements Specification, Requirements Engineering, Use Cases, Sceneries .

2

1. Introduccio n

Uno de los primeros procesos que se realizan en un proyecto de construcci o n de software es la especificacio n de

requisitos. Los objetivos de este proceso son identificar, validar y documentar los requisitos de software; es decir

determinar las caracterısticas que deberan tener el sistema o las restricciones que deberacumplir para que sea

aceptado por el cliente y los futuros usuarios del sistema de software.

El producto final de este proceso es el documento de especificacio n de requisitos de software y en e ste se sen ala,

con el detalle adecuado, lo que el usuario necesita del sistema de software. Es por ello, que el documento de

requisitos de software se considera como un contrato entre el cliente y el equipo de desarrollo del sistema.

Actualmente, el desarrollo de software orientado a objetos y el uso de UML se han incrementado. Es por ese

motivo que el empleo de casos de uso se estaimponiendo frente a otras te cnicas de especificacio n de requisitos.

Lamentablemente, la bibliografıa existente muestra muchas formas de aplicar los casos de uso y no son pocas las

veces en que su empleo es incorrecto. Algunas de las causas son: mala interpretacio n del estandar UML y secuencia

incorrecta de actividades para la creacio n de casos de uso.

Este artıculo muestra las actividades y la secuencia a seguir para realizar una especificaci o n de requisitos

empleando casos de uso. Ademas, se explicaran los errores comunes que se producen en cada una de esas

actividades.

2. UML y la Especificacio n de Requisitos

Para determinar la funcionalidad de un sistema a desarrollar, UML [8] sen ala el uso de dos elementos: el actor y el

caso de uso.

El actor representa una entidad externa que interactua con el sistema. Las entidades externas podrıan ser

personas u otros sistemas. Es importante resaltar que los actores son abstracciones de papeles o roles y no

necesariamente tienen una correspondencia directa con personas.

A diferencia del actor, el caso de uso hace referencia al sistema a construir, detallando su comportamiento, el

cual se traduce en resultados que pueden ser observados por el actor. Los casos de uso describen las cosas que los

actores quieren que el sistema haga, por lo que un caso de uso deberıa ser una tarea completa desde la perspectiva

del actor.

Los actores y los casos de uso forman un modelo al que se le denomina ” modelo de casos de uso„ . Dicho

modelo muestra el comportamiento del sistema desde la perspectiva del usuario y serviracomo producto de entrada

para el analisis y disen o del sistema. La figura 1 muestra la notacio n que se debe utilizar para representar un actor y

un caso de uso.

Figura 1. Representacio n grafica de actor y caso de uso

UML especifica que para representar graficamente la relacio n entre un actor y caso de uso se debe trazar una

lınea que los una a la que se le denomina ” relacio n de comunicacio n„ . Ademas, UML sen ala que los casos de uso

pueden tener relaciones entre sı. Los tipos de relaciones que pueden existir son: ” include„ , ” extends„ y

” generalization„ . La figura 2 muestra un ejemplo de casos de uso con relaciones de tipo ” generalization„ .

Actor Caso de Uso

3

Figura 2. Diagrama de casos de uso con relacio n ” generalizationí entre casos de uso.

3. Actividades para la Especificacio n de Requisitos con Casos de Uso

Los resultados de la especificacio n de requisitos son dos productos: el catalogo de requisitos y el documento de

especificacio n de requisitos de software. El primero de ellos contiene la lista de requisitos de software clasificada

por tipo y prioridad; y el segundo de ellos, especifica el comportamiento del sistema a un grado de detalle mayor al

del catalogo de requisitos. La figura 3, indica el contenido de los productos de la especificacio n de requisitos

...