• Las clases e interacciones implementan los casos de uso
del sistema.
– Las interacciones
se expresan en diagramas de secuencia, colaboración y actividad, así, hay un
enlace entre las vistas funcional y dinámica del sistema.
– Las clases en la implementación de los casos de uso se
modelan y se describen en diagramas de clases y de estados.
• Los propósitos primarios de los casos de uso son:
– Decidir y describir los requerimientos funcionales del
sistema, dando lugar a un acuerdo entre el cliente (y/o usuario final) y los
programadores que desarrollan el sistema.
– Dar una descripción clara y consistente de lo que debería
hacer el sistema, de modo que el modelo se use a lo largo del proceso de
desarrollo. – Proporcionar una base para realizar verificaciones (tests) del
sistema que comprueben su funcionamiento.
– Proporcionar la capacidad para rastrear requerimientos
funcionales en clases y operaciones reales del sistema, verificando los casos
de uso afectados por cambios y extensiones al sistema.
• El modelado de casos de uso también
se utiliza cuando se desarrolla una nueva versión del sistema.
– Se añade la nueva funcionalidad al
modelo de casos de uso existente insertando nuevos actores y casos de uso, o
modificando la especificación de los casos de uso actuales
Diagrama de Casos
de Uso
• Un modelo de casos
de uso se describe en UML mediante un diagrama de casos de uso (use-case
diagram) y puede dividirse en varios diagramas de casos de uso.
• Un diagrama de casos de uso contiene elementos del modelo
para el sistema, los actores y los casos de uso, y muestra las diferentes
relaciones entre estos elementos.
– Estos diagramas dan una visión del modelo, pero las
descripciones reales de los casos de uso suelen ser textuales, usando el
lenguaje y terminología del cliente/usuario.
• Un sistema en un diagrama de casos de uso se describe
mediante un rectángulo que contiene el nombre del sistema y los símbolos de los
casos de uso en el sistema.
Actor
•Un actor es alguien o algo que interactúa con el sistema,
pero que es externo al sistema.
– El actor envía o recibe mensajes a y desde el sistema, o
intercambia información con el sistema.
– Un caso de uso
siempre es iniciado por un actor que le envía un mensaje o estímulo (stimulus).
Los actores llevan a cabo casos de uso.
– Cuando un caso de
uso se realiza, el caso de uso podría enviar mensajes a uno o más actores.
Estos mensajes también pueden ir a otros actores además del que inició el caso
de uso.
•Un
actor es una clase, no una instancia. El actor representa un papel, no a un
usuario individual del sistema.
– Por ejemplo, una persona puede ser
diferentes actores en el sistema, dependiendo de su papel en éste.
– Los papeles que una persona puede
tener en un sistema pueden estar restringidos. Por ejemplo, puede estar prohibido
que la misma persona registre una factura y la apruebe.
– Un actor tiene un nombre que debería
reflejar el papel del actor.
• Para identificar los actores, se establecen las entidades
interesadas en usar e interactuar con el sistema:
– Los usuarios de la funcionalidad principal del sistema
(actores primarios). Por ejemplo, en un sistema de seguros, un actor primario
podría ser uno que maneja el registro y administración de los seguros.
– Los que mantienen, administran y tienen el sistema en
funcionamiento (actores secundarios). Un ejemplo de actor secundario podría ser
una tarjeta que usa las funciones del sistema para recuperar estadísticas sobre
los negocios o la compañía. – Los dispositivos hardware que necesita manejar el
sistema.
– Los otros sistemas con que necesita interactuar, que
incluyen otros sistemas computadores, así como otras aplicaciones en el
computador en que operará este sistema.
– Los que tienen interés en los resultados que produce el
sistema.
• Un actor debe tener alguna asociación con uno o más casos
de uso.
– Aunque un actor podría no iniciar un caso de uso, ese
actor se comunicará con uno en algún punto.
– Un actor activo inicia un caso de uso, mientras que un
actor pasivo nunca inicia un caso de uso, sino que sólo participa en uno o más
casos de uso.
Relaciones entre actores
• Los actores en UML son clases con el estereotipo <<actor>>
y tienen un estereotipo icono estándar. El nombre de la clase es el nombre del
actor.
– Una clase actor
puede tener atributos y comportamiento.
– Los actores pueden
tener las mismas relaciones que las clases.
• Cuando varios actores, como parte de sus papeles, también
representan un papel más generalizado, se describe mediante una relación de
generalización.
– El comportamiento del papel general se describe en una
superclase actor. Los actores especializados heredan el comportamiento de la
superclase y extienden ese comportamiento de algún modo.
Representación de un Caso de Uso
•Un caso de uso se representa en UML
mediante una elipse que contiene el nombre del caso de uso, o con el nombre del
caso de uso debajo.
• Los casos de uso se conectan a los
actores mediante asociaciones, denominadas líneas de comunicación
(communication lines).
– Las asociaciones muestran con qué actores
se comunica el caso de uso, incluyendo el actor que inicia la ejecución del
caso de uso.
– La asociación normalmente es una relación
uno a uno sin dirección. Esto significa que una instancia de actor se comunica
con una instancia de caso de uso y que pueden comunicarse en ambas direcciones.
Relaciones entre casos de Uso
• Relación de extensión (extend): un caso de uso añade
acciones, que pueden ser opcionales, al comportamiento de un caso de uso general.
– El caso de uso extendido puede incluir comportamiento del
caso de uso que se extiende, aunque no tiene que incluir todo el
comportamiento.
• Relación de inclusión (include): un caso de uso incluye el
comportamiento completo de un caso de uso general.
– Permite la composición jerárquica de casos de uso, así
como la reutilización entre casos de uso.
• Relación de generalización: en el caso de uso
especializado se especifican los pasos extra que es necesario añadir al caso de
uso general, para representar una funcionalidad diferente a la original.
Tomado de:
No hay comentarios:
Publicar un comentario