MATERIAL DE ANÁLISIS DE SISTEMAS IV
Casos de Uso (Use Case)
UML, ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos de
análisis y diseño. Existen diferencias importantes entre un método y un
lenguaje de modelado.
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una
vista no es una gráfica, pero sí una abstracción que consiste en un número de
diagramas y todos esos diagramas juntos muestran una "fotografía" completa
del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o
procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:
Diagramas: Los diagramas son las gráficas que describen el contenido de una
vista. UML tiene nueve tipos de diagramas que son utilizados en combinación
para proveer todas las vistas de un sistema: diagramas de caso de uso, de
clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de
componentes y de distribución.
Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas
son los elementos de modelo que representan conceptos comunes orientados
a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos
conceptos incluyendo la asociación, dependencia y generalización. Un
elemento de modelo es utilizado en varios diagramas diferentes, pero siempre
tiene el mismo significado y simbología.
Reglas o Mecanismos generales: Proveen comentarios extras, información o
semántica acerca del elemento de modelo; además proveen mecanismos de
extensión para adaptar o extender UML a un método o proceso específico,
organización o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Análisis de
requerimientos, Análisis, Diseño, Programación y Pruebas.
Análisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del
cliente. A través del modelado de casos de uso, los actores externos que tienen
interés en el sistema son modelados con la funcionalidad que ellos requieren
del sistema (los casos de uso). Los actores y los casos de uso son modelados
con relaciones y tienen asociaciones entre ellos o éstas son divididas en
jerarquías. Los actores y casos de uso son descritos en un diagrama use-case.
Cada use-case es descrito en texto y especifica los requerimientos del cliente:
lo que él (o ella) espera del sistema sin considerar la funcionalidad que se
implementará. Un análisis de requerimientos puede ser realizado también para
procesos de negocios, no solamente para sistemas de software.
Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que están presentes en el dominio del problema. Las clases que
se modelan son identificadas, con sus relaciones y descritas en un diagrama de
clases. Las colaboraciones entre las clases para ejecutar los casos de uso
también se consideran en esta fase a través de los modelos dinámicos en
UML. Es importante notar que sólo se consideran clases que están en el
dominio del problema (conceptos del mundo real) y todavía no se consideran
clases que definen detalles y soluciones en el sistema de software, tales como
clases para interfaces de usuario, bases de datos, comunicaciones,
concurrencia, etc.
Diseño
En la fase de diseño, el resultado del análisis es expandido a una solución
técnica. Se agregan nuevas clases que proveen de la infraestructura técnica:
interfaces de usuario, manejo de bases de datos para almacenar objetos en
una base de datos, comunicaciones con otros sistemas, etc. Las clases de
dominio del problema del análisis son agregadas en esta fase. El diseño resulta
en especificaciones detalladas para la fase de programación.
Programación
En esta fase las clases del diseño son convertidas a código en un lenguaje de
programación orientado a objetos. Cuando se crean los modelos de análisis y
diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a
código.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
típicamente ejecutadas por el programador. Las pruebas de integración
integran componentes y clases en orden para verificar que se ejecutan como
se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y
validan que el sistema tenga la funcionalidad final que le usuario final espera.
Las pruebas de aceptación conducidas por el cliente verifican que el sistema
satisface los requerimientos y son similares a las pruebas de sistema.
El diagrama de casos de uso representa la forma en como un Cliente (Actor)
opera con el sistema en desarrollo, además de la forma, tipo y orden en como
los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicación.
Elementos
Actor:
Una definición previa, es que un Actor es un rol que un usuario juega
con respecto al sistema. Es importante destacar el uso de la palabra rol,
pues con esto se especifica que un Actor no necesariamente representa
a una persona en particular, sino más bien la labor que realiza frente al
sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de
ventas en que el rol de Vendedor con respecto al sistema puede ser
realizado por un Vendedor o bien por el Jefe de Local.
Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de
algún agente externo, sea desde una petición de un actor o bien desde
la invocación desde otro caso de uso.
Relaciones:
o Asociación
Es el tipo de relación más básica que indica la invocación desde
un actor o caso de uso a otra operación (caso de uso). Dicha
relación se denota con una flecha simple.
o Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual
una clase depende de otra, es decir, se instancia (se crea). Dicha
relación se denota con una flecha punteada.
o Generalización
Este tipo de relación es uno de los más utilizados, cumple una
doble función dependiendo de su estereotipo, que puede ser
de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relación esta orientado exclusivamente para casos de
uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar
a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de
características que son similares en más de un caso de uso y no
se desea mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en
diseño y modelamiento de clases, en donde esta la duda clásica
de usar o heredar.
Ejemplo:
Como ejemplo esta el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas.
El sistema debe controlar y/o aceptar:
Registrar el número de ítemes ingresados.
Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada item
c. Total
El usuario/cliente presiona el botón de comienzo
Existe un operador que desea saber lo siguiente:
a. Cuantos ítemes han sido retornados en el día.
b. Al final de cada día el operador solicita un resumen de todo lo
depositado en el día.
El operador debe además poder cambiar:
a. Información asociada a ítemes.
b. Dar una alarma en el caso de que:
i. Item se atora.
ii. No hay más papel.
Como una primera aproximación identificamos a los actores que interactuan
con el sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede
cambiar la información de un Item o bien puede Imprimir un informe:
Además podemos notar que un item puede ser una Botella, un Tarro o una
Jaba.
Otro aspecto es la impresión de comprobantes, que puede ser realizada
después de depositar algún item por un cliente o bien puede ser realizada a
petición de un operador.
Entonces, el diseño completo del diagrama Use Case es:
Diagrama de Interacción
El diagrama de interacción, representa la forma en como un Cliente (Actor) u
Objetos (Clases) se comunican entre si en petición a un evento. Esto implica
recorrer toda la secuencia de llamadas, de donde se obtienen las
responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático
de Clases o el de Casos de Uso (son diferentes).
Los componentes de un diágrama de interacción son:
Un Objeto o Actor.
Mensaje de un objeto a otro objeto.
Mensaje de un objeto a si mismo.
Elementos
Objeto/Actor:
El rectángulo representa una instancia de un Objeto en particular, y la
línea punteada representa las llamadas a métodos del objeto.
Mensaje a Otro Objeto:
Se representa por una flecha entre un objeto y otro, representa la
llamada de un método (operación) de un objeto en particular.
Mensaje al Mismo Objeto:
No solo llamadas a métodos de objetos externos pueden realizarse,
también es posible visualizar llamadas a métodos desde el mismo objeto
en estudio.
Ejemplo
En el presente ejemplo, tenemos el diagrama de interacción proveniente del
siguiente modelo estatico:
Aquí se representa una aplicación que posee una Ventana gráfica, y ésta a su
vez posee internamente un botón.
Entonces el diagrama de interacción para dicho modelo es:
En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos) y la
llamada a Paint() por el objeto Botón.