UML para el manejo de requerimientos
Ejemplo de una limitante de los Use Cases.
En este capítulo se explica brevemente lo que es el UML (en relación al manejo de requerimientos) y su historia. La información presentada esta basada en el documento referencia [A4]
El “Unified Modelling Languaje” (UML) provee a los analistas y arquitectos de sistemas que trabajan en el diseño y análisis de objetos de un lenguaje consistente para especificar, visualizar, construir y documentar los artefactos de un sistema de software, así también es útil para hacer modelos de negocios.
Esta especificación es la evolución del las tres anteriores tecnologías orientadas a objetos lideres (Booch, OMT y OOSE). El UML es la unión de estos lenguajes de modelos y aún mas ya que incluye expresiones adicionales para manejar problemas de modelaje que los métodos anteriores no cubrían plenamente.
El desarrollo de el UML empezó en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation iniciaron su trabajo para unificar los métodos de Booch y OMT. Debido a que los métodos Booch y OMT ya habían madurado independientemente y eran reconocidos como métodos líderes en el desarrollo orientado a objetos, Booch y Rumbaugh unieron fuerzas para forjar una unificación completa de los dos métodos. Una versión preliminar 0.8 de el “método unificado” fue dad a conocer en octubre de 1995. Poco después, Ivar Jacobson y su compañía “Objectory” se unieron a Rational y a su trabajo de unificación, uniendo el método OOSE (Object Oriented software engineering). El Nombre de Objectory es ahora dado mayormente para describir a el Proceso que acompaña al UML el “Rational unified process”
Los objetivos de la unificación fueron: el mantenerlo simple, el quitar elementos de los lenguajes de Booch, OMT y OOSE que no funcionaran en la práctica, el añadir elementos de otros métodos que fueran mas efectivos y el inventar nuevas construcciones solamente cuando la solución existente no estuviera disponible.
Varios nuevos conceptos existen en UML, incluyendo:
· Mecanismos de extensión (estereotipos, valores marcados y restricciones),
· Procesos y ramas de procesamiento
· Distribución y concurrencia
· Patrones y colaboración
· Diagramas de actividad
· Refinamiento (para manejar las relaciones entre los niveles de abstracción)
· Interfaces y componentes y
· Un lenguaje para restricciones
Aunque el UML define un leguaje preciso, no es una barrera para el desarrollo futuro en los conceptos de modelaje. Se han incorporado muchas técnicas líderes, pero se espera que técnicas adicionales influyan las versiones futuras del UML. Muchas técnicas avanzadas pueden ser definidas usando el UML como base. El UML puede ser extendido sin redefinir su núcleo.
En este trabajo nos enfocaremos principalmente a la notación usada para el manejo de requerimientos. Una descripción completa de la notación UML se encuentra en el documento [A4].
El UML posee varios tipos de diagramas y construcciones que pueden ser usadas para el diseño de sistemas, el artefacto específico para el manejo de requerimientos es el Use Case y los Actores.
¿Que es un "Use Case"?
Jacobsson en [A2] define a los use cases y a los actores como:
“Los Actores representan lo que interactúa con el sistema. Ellos representan a todo lo que necesita intercambiar información con el sistema. Las instancias de los actores son los usuarios del sistema, ellos llevan a cabo un numero de operaciones con el sistema y desarrollan una secuencia de transacciones en comunicación con el sistema. A esta secuencia de acciones se llama Use case.
..”
Los use cases se usan para especificar el comportamiento de el sistema sin definir su estructura, la forma de que un modelo de Use cases es realizado en términos de objetos que son definidos por clases dentro de el sistema se puede describir con diagramas de colaboración.
Un use case es un tipo de clasificador que representa una unidad coherente de funcionalidad dentro de un sistema, un subsistema, o una clase manifestada por una secuencia de mensajes intercambiados entre el sistema y uno o mas objetos externos (llamados actores) y por acciones que el sistema lleva a cabo.
Un Punto de extensión es una referencia a un punto dentro del use case en el que las secuencias de acciones de otros use cases pueden ser insertadas. Cada punto de inserción tiene un nombre único dentro de el use case y además cuenta con una descripción de el punto de inserción dentro de el comportamiento de el use case.
Un use case es mostrado como una elipse conteniendo el nombre de el use case. Opcionalmente, un estereotipo puede ser colocado arriba de el nombre y una lista de propiedades también puede ser incluida abajo de el nombre. Como es un clasificador, un use case también puede tener compartimentos mostrando atributos y operaciones.
Los puntos de extensión pueden ser listados en un compartimento de el use case con el encabezado puntos de extensión. La descripción de la localización de el punto de extensión se da de la manera mas adecuada, usualmente es en forma de texto, pero también puede ser dado de otras formas, como el nombre de un estado en una máquina de estados, o una precondición o postcondición
El comportamiento de un use case puede ser descrito de maneras muy diferentes, dependiendo de que es lo mas conveniente: texto libre es comúnmente usado, pero maquinas de estados además de es y métodos son ejemplos de otras formas de describir el comportamiento de el use case.
Un Actor define un conjunto coherente de roles los cuales pueden ser usados por los usuarios de una entidad cuando interactúan con esta entidad. Una actor se considera que juega un rol diferente con relación a cada use case con el cual actúa.
El icono estándar de un estereotipo de actor es la figura del “Mono de palo”, con el nombre del actor debajo de la figura. Un actor también puede ser representado como una clase con el estereotipo de “actor” con todos los compartimentos de esta.
Los diagramas de Use Case representan a los actores y a los use cases junto con sus relaciones. Los Use Cases representan la funcionalidad de un sistema o subsistema o clase, como es percibido por el exterior de el sistema, es decir por sus actores.
Un diagrama de use case es una gráfica de actores, un conjunto de use cases, posiblemente algunas interfaces y las relaciones entre estos elementos. Las relaciones son asociaciones entre los actores y los use cases generalizaciones entre los actores y generalizaciones, extensiones e inclusiones entre los use cases.
Ejemplo de Diagrama de use case
Hay varias relaciones estándar entre los use cases o entre los actores y los use cases.
· Asociación – La participación de un actor en el Use Case, i. e. instancias de el actor e instancias de el use case se comunican entre si. Esta es la única relación entre los actores y los Use cases.
· Extensión – una relación de extensión entre el use case A y el use Case B indica que una instancia de el use case B puede ser aumentada (Dependiendo de ciertas condiciones especificadas en la extensión) por el comportamiento de especificado en el Use Case B. El comportamiento es insertado el punto definido como punto de extensión del Use Case B, el cual es referenciado por la relación externa.
· Generalización – Una generalización de un use case A hacia el use case B indica que A es una especialización de B
· Inclusión – una relación de inclusión de el use Case A hacia el Use case B indica que una instancia de el use case A también contendrá el comportamiento especificado por B. El comportamiento es incluido en el punto definido en A
Ejemplo de diagrama de Use case y algunas de sus relaciones
Los use cases, como ya vimos explican el comportamiento requerido de un sistema en la perspectiva del actor. Si analizamos las características de los requerimientos propuestas en los capítulos anteriores. Podemos ver que los use cases pueden definir los requerimientos de:
· Entorno
Al definir quienes son los actores se está definiendo el entorno
· Funcionales
Lo que ejecuta el use Case son básicamente la funcionalidad requerida por el sistema.
· Interfases
La relación entre el actor y el use case puede ser refinada para especificar la interfase usada por el use case y el actor.
· Restricciones de diseño
Una norma oficial o el uso de cierto tipo de estructura de sistema puede ser especificado en el use case o en los diagramas de colaboración que realizan dicho use case.
· Materiales
El material que debe de ser usado puede ser definido como un atributo de el use case.
Pero no de desempeño, ni no funcionales, ni de entrenamiento.
