RESUMEN
El uso del lenguaje de modelamiento unificado (UML) como
una notación que ayuda en el proceso de desarrollo del
software. Es por eso el empleo de los casos de uso, como parte
del UML. El propósito de los casos de uso es describir en
lenguaje amigable para la funcionalidad completa de un sistema a
desarrollar y su empleo se realiza en el proceso de
especificación de requisitos del sistema. Existen, 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
interpretación del estándar UML y la secuencia
incorrecta de actividades para la creación de casos de
uso.Representa la forma que un actor opera con el sistema en
desarrollo, además de la forma, tipo y orden en como los
elementos interactúan "operaciones o casos de uso". Como
resultado de las actividades de este flujo de trabajo, se
desarrolla la visión, el modelo de los casos de uso, los
casos de uso que en conjunto describen la herramienta a
desarrollar. En concreto, en el diagrama no muestra el orden en
el que se llevan a cabo los pasos para lograr los objetivos de
cada caso de uso. Los casos de uso solamente se utilizan para los
requisitos funcionales de un sistema.
Palabras clave: Actor, caso de uso y
UML.
ABSTRACT
The use of Unified language model (UML) as a standard
for software construction has spread in recent years. That is why
the use of use cases, it is as part of the UML standard. The
purpose of use cases is to describe the full functionality of a
system to develop in natural language and its use is in the
process of system requirements specification. Unfortunately
exists, many forms of implementing the use cases and not few the
times that its use is inappropriate. Some of the causes are
misinterpretation of the UML standard and incorrect sequence of
activities for the creation of use cases. Represents the shape of
a "actor" client operates with system in development, as well as
the shape, type, and order in how elements interact 'operations
or use cases. As a result of the activities of this workflow,
develops vision, model use cases use cases which together
describe the tool to develop. Also built a glossary and a
prototype of the user interface. In particular, the diagram does
not show the order in which the steps are performed to achieve
the objectives of each use case.
Key words: Actor, use case
y UML.
1.
INTRODUCCIÓN
Uno de los primeros procesos que se realizan en un
proyecto de construcción de software es la
especificación de requisitos. Los objetivos de este
proceso son identificar, validar y documentar los requisitos de
software; es decir determinar las características que
deberán tener el sistema o las restricciones que
deberá cumplir para que sea aceptado por el cliente y los
futuros usuarios del sistema de software. El modelo de casos de
uso debe servir como medio de comunicación y soporte,
entre clientes, usuarios y desarrolladores; proveyendo
funcionalidad "el cómo" a ser implementada.
El producto final de este proceso es el documento de
especificación de requisitos de software y en este se
señ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. El modelo se
compone de casos de uso y actores. Cada caso de uso en el modelo
es escrito en detalle, mostrando paso a paso la forma como los
actores interactúan con el sistema y como responde el
sistema.
Los objetivos es establecer y mantener la conformidad de
las necesidades de los clientes y usuarios acerca de
lo que el sistema debe hacer, proporcionar a los desarrolladores
una mejor comprensión de los requerimientos del sistema,
definir las fronteras del sistema. Proporcionar la base del
planeamiento de los contenidos técnicos de las
iteraciones, proporcionar la base de la estimación de
costos y tiempo de desarrollo del sistema, definir una interfaz
de usuario para el sistema centrada en las necesidades y metas de
los usuarios.
2. UML Y LA
ESPECIFICACIÓN DE REQUISITOS
Yourdon [1] Concuerda que para determinar la
funcionalidad de un sistema a desarrollar UML señala el
uso de dos elementos: el actor y el caso de uso. El actor
representa una entidad externa que interactúa 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. 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.
Grafica1.- Representación gráfica de
actor y caso de uso[1]
UML especifica que para representar gráficamente
la relación entre un actor y caso de uso se debe trazar
una línea que los una, a la que se le denomina
"relación de comunicación". Además, UML
señala que los casos de uso pueden tener relaciones entre
sí. Los tipos de relaciones que pueden ser: "include"
"extends" y "generalization"
¿QUÉ ES UN INCLUDE?
Bittner [2] Explica que son términos muy simples,
cuando relacionamos dos casos de uso con un "include", estamos
diciendo que el primero (el caso de uso base) incluye al segundo
(el caso de uso incluido). Es decir, el segundo es parte esencial
del primero. Sin el segundo, el primero no podría
funcionar bien, pues no podría cumplir su objetivo. Para
una venta en caja, la venta no puede considerarse completa si no
se realiza el proceso para cobrarla en ese momento.
¿QUÉ ES UN EXTENDS?
Una de las diferencias básicas es que en el caso
del "extend" hay situaciones en que el caso de uso de
extensión no es indispensable que ocurra, y cuando lo hace
ofrece un valor extra (extiende) al objetivo original del caso de
uso base.
¿QUÉ ES UNA
GENERALIZATION?
La Generalización especifica que un caso de uso
hereda las características y puede volver a especificar
algunas o todas ellas de una forma muy similar a las herencias
entre clases.
ACTIVIDADES PARA LA ESPECIFICACIÓN DE
REQUISITOS CON CASOS DE USO
Brown [3] Expresa que los resultados de la
especificación de requisitos son dos productos: el
catálogo de requisitos y el documento de
especificació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
catálogo de requisitos.
IDENTIFICAR Y CLASIFICAR REQUISITOS
Bruegge [4] Asume que esta actividad es el punto de
partida para las siguientes actividades del proceso de
obtención de requisitos y se refiere a la
identificación de los requisitos del sistema de software a
desarrollar. En esta actividad, deberemos responder a los
siguientes cuestionamientos: ¿Qué le
permitirá hacer, el sistema de software al usuario?
¿El cliente o usuario me solicita alguna
restricción para construir el sistema de
software?
Luego de ser contestadas las preguntas, se
clasificarán en dos grupos: requisitos
Funcionales y requisitos no funcionales.
Grafica2.- Especificación de
requisitos[1]
IDENTIFICAR CASOS DE USO
El caso de uso es el que especifica todos los escenarios
posibles para una parte de funcionalidad dada, es decir todos los
escenarios similares se agrupan en un solo caso de
uso.
IDENTIFICAR ACTORES
Para encontrar actores del sistema se puede buscar en
las categorías de personas.
Para un sistema de biblioteca, los actores
podrían ser: bibliotecario.
En el caso de un sistema de ventas, los actores
podrían ser: el cliente.
IDENTIFICAR ESCENARIOS
Un escenario es una descripción concreta,
enfocada e informal de una sola característica del sistema
desde el punto de vista de un solo actor, es decir, un escenario
muestra la secuencia de pasos que se produce cuando un actor
interactúa con el sistema en una situación
especifica y un tiempo determinado.
ERRORES EN LA IDENTIFICACIÓN DE CASOS DE
USO
Schneider [5] Señala que los casos de uso deben
mostrar lo que el usuario necesita del sistema y no mostrar las
funciones u opciones del menú que permitirán
realizar lo solicitado.
ERRORES EN LA IDENTIFICACIÓN DE
ACTORES
Los errores introducidos en esta etapa se deben
principalmente a no comprender quienes son los actores del
sistema.
En algunos casos se incluyen actores que realmente no lo
son por ejemplo, en un sistema en el que se realizan pedidos de
productos, se considera al cliente como un actor. Realmente quien
ingresa los pedidos en el sistema es el vendedor y no el cliente,
por lo tanto el vendedor seria el actor del
sistema[2].
APORTE SOCIAL
Los casos de uso se utilizan para tener una mejor
compresión del Software a realizar, nos muestra
además un panorama amplio, interactivo y objetivo del
funcionamiento del Software, de esa manera nosotros necesitamos
tener las cosas bien definidas, planteadas y fundamentales para
así contribuir con las organizaciones valores y
efectividad en la labor a desempeñar.
APORTE ESPIRITUAL
El requerimiento principal es creer en Dios. En la vida
cotidiana cada persona debe realizar diferentes acciones que lo
lleven a estar más en comunión con nuestro padre,
cuando nuestra vida esta aferrada a Dios podremos
desempeñarse bien en el área que estamos
laborando porque él nos brindó sabiduría e
inteligencia; sobre todo nuestro objetivo principal es tener la
vida eterna.
3.
CONCLUSIÓN
En este articulo se muestran las actividades que se
deben realizar para la especificación de requisitos
utilizando casos de uso. Estas actividades han permitido
minimizar los errores en la aplicación del estándar
UML y lo que es importante finalizar el proceso con un documento
de especificación de requisitos libre de errores y
útil para las etapas de análisis y diseño.
El uso de las relaciones de casos de uso es opcional y no es
necesaria para realizar un documento de especificación de
requisitos adecuado y detallado.
El presente trabajo es un inicio para el establecimiento
de patrones en la aplicación de casos de uso, de manera
que nos puedan ayudar a mejorar.
REFERENCIAS
1. Yourdon E., Analisis Estructurado Moderno,
Prentice Hall hispanoamericana, México, 1989.
2. Bittner, K., Why Use Cases Are Not
functions, http://www.therationaledge.com, USA,
2000.
3. Brown, W.J., AntiPatterns: Refactoring Software,
Architectures, and Projects in Crisis, John Wiley &
Sons, USA, 1998.
4. Bruegge B., Allen, S., Ingeniería de Software
Orientado a Objetos, Addison-Wesley, USA, 2002.
Ministerio de Administraciones Públicas, Analisis
del Sistema de Informacion-Metrica Version 3, Espan a,
2000.
5. Schneider, G., Winters, J.P., Applying Use Cases,
Second Edition, Addison-Wesley, Massachusetts, USA,
2001.
Autor:
Balverdi Cruz Luis Harley
Estudiante de la Universidad Peruana
Unión
Cachay Valdivia Jimy
Ing. Daniel Lévano
Rodríguez Mg
Asesor