Diagrama de casos de uso
Los diagramas de casos de uso describen las relaciones y las
dependencias entre un grupo de casos de uso y los actores participantes en el
proceso.
Es importante resaltar que los diagramas de casos de uso no están
pensados para representar el diseño y no puede describir los elementos internos
de un sistema. Los diagramas de casos de uso sirven para facilitar la
comunicación con los futuros usuarios del sistema, y con el cliente, y resultan
especialmente útiles para determinar las características necesarias que tendrá
el sistema. En otras palabras, los diagramas de casos de uso describen qué es
lo que debe hacer el sistema, pero no cómo.
Caso de uso
Un caso de uso describe,
—desde el punto de vista de los actores—, un grupo de actividades de un sistema
que produce un resultado concreto y tangible.
Los casos de uso son
descriptores de las interacciones típicas entre los usuarios de un sistema y
ese mismo sistema. Representan el interfaz externo del sistema y especifican
qué requisitos de funcionamiento debe tener este (recuerde, únicamente el qué,
nunca el cómo).
Cuando se trabaja con casos de
uso, es importante tener presentes algunas secillas reglas:
- Cada caso de uso está relacionado como mínimo
con un actor
- Cada caso de uso es un iniciador (es decir, un
actor)
- Cada caso de uso lleva a un resultado
relevante (un resultado con «valor intrínseco»)
Los casos de uso pueden tener relaciones con otros casos de uso. Los
tres tipos de relaciones más comunes entre casos de uso son:
- <<include>> que especifica una situación en la que un caso de uso tiene
lugar dentro de otro caso de uso
- <<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado
punto de extensión) un caso de uso será extendido por otro.
- Generalización que especifica que un caso de uso hereda las características
del «super» caso de uso, y puede volver a especificar algunas o todas
ellas de una forma muy similar a las herencias entre clases.
Elementos
Actor
Un actor es una entidad
externa (de fuera del sistema) que interacciona con el sistema participando (y
normalmente iniciando) en un caso de uso. Los actores pueden ser gente real
(por ejemplo, usuarios del sistema), otros ordenadores o eventos externos.
Los actores no representan a
personas físicas o a sistemas, sino su rol. Esto significa que cuando una
persona interactúa con el sistema de diferentes maneras (asumiendo diferentes
papeles), estará representado por varios actores. Por ejemplo, una persona que
proporciona servicios de atención telefónica a clientes y realiza pedidos para
los clientes estaría representada por un actor «equipo de soporte» y por otro
actor «representante de ventas».
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.
Descripción de casos
de uso
Las descripciones de casos de uso son
reseñas textuales del caso de uso. Normalmente tienen el formato de una nota o
un documento relacionado de alguna manera con el caso de uso, y explica los
procesos o actividades que tienen lugar en el caso de uso. - 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.- 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.- 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.
Diagrama de clases
Los diagramas de clases
muestran las diferentes clases que componen un sistema y cómo se relacionan
unas con otras. Se dice que los diagramas de clases son diagramas «estáticos»
porque muestran las clases, junto con sus métodos y atributos, así como las relaciones
estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases
«son parte» de otras clases, pero no muestran los métodos mediante los que se
invocan entre ellas.
Diagramas de secuencia
Los diagramas de secuencia
muestran el intercambio de mensajes (es decir la forma en que se invocan) en un
momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y
el momento en que se envían los mensajes a los objetos.
En los diagramas de secuencia,
los objetos están representados por líneas intermitentes verticales, con el
nombre del objeto en la parte más alta. El eje de tiempo también es vertical,
incrementándose hacia abajo, de forma que los mensajes son enviados de un
objeto a otro en forma de flechas con los nombres de la operación y los
parámetros.
Diagramas de colaboración
Los diagramas de colaboración
muestran las interacciones que ocurren entre los objetos que participan en una
situación determinada. Esta es más o menos la misma información que la mostrada
por los diagramas de secuencia, pero destacando la forma en que las operaciones
se producen en el tiempo, mientras que los diagramas de colaboración fijan el
interés en las relaciones entre los objetos y su topología.
En los diagramas de
colaboración los mensajes enviados de un objeto a otro se representan mediante
flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del
mensaje. Los diagramas de colaboración están indicados para mostrar una
situación o flujo programa específicos y son unos de los mejores tipos de
diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica
del programa.
Diagrama de estado
Los diagramas de estado
muestran los diferentes estados de un objeto durante su vida, y los estímulos
que provocan los cambios de estado en un objeto.
Los diagramas de estado ven a
los objetos como máquinas de estado o autómatas finitos que pueden estar
en un conjunto de estados finitos y que pueden cambiar su estado a través de un
estímulo perteneciente a un conjunto finito.
Diagrama de
actividad
Los diagramas de actividad describen la secuencia de las
actividades en un sistema. Los diagramas de actividad son una forma especial de
los diagramas de estado, que únicamente (o mayormente) contienen actividades.
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:
- Describe
lo depositado
- El
valor de cada item
- Total
- El
usuario/cliente presiona el botón de comienzo
- Existe
un operador que desea saber lo siguiente:
- Cuantos
ítemes han sido retornados en el día.
- 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:
- Información
asociada a ítemes.
- Dar
una alarma en el caso de que:
- Item
se atora.
- 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:
RESUMEN
Diagrama de casos de uso
Los diagramas de casos de uso describen las relaciones y las
dependencias entre un grupo de casos de uso y los actores participantes en el
proceso.
Caso de uso
Un caso de uso describe,
—desde el punto de vista de los actores—, un grupo de actividades de un sistema
que produce un resultado concreto y tangible.
Relaciones:
- 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.
- 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.
- 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).
Diagrama de clases
Los diagramas de clases muestran las diferentes clases que
componen un sistema y cómo se relacionan unas con otras. Se dice que los
diagramas de clases son diagramas «estáticos» porque muestran las clases, junto
con sus métodos y atributos, así como las relaciones estáticas entre ellas
Diagramas de secuencia
Los diagramas de secuencia
muestran el intercambio de mensajes (es decir la forma en que se invocan) en un
momento dado. Los diagramas de secuencia ponen especial énfasis en el orden y
el momento en que se envían los mensajes a los objetos.
Diagramas de colaboración
Los diagramas de colaboración muestran las interacciones que
ocurren entre los objetos que participan en una situación determinada.
Diagrama de estado
Los diagramas de estado
muestran los diferentes estados de un objeto durante su vida, y los estímulos
que provocan los cambios de estado en un objeto.
Diagrama de
actividad
Los diagramas de actividad describen la secuencia de las
actividades en un sistema. Los diagramas de actividad son una forma especial de
los diagramas de estado, que únicamente (o mayormente) contienen actividades.
SUMARY
Use case diagram
The use case diagrams describe the relationships and dependencies between a group of use cases and actors involved in the process.
Case of use
A use case describes, from the point of view of the actors, a group of activities in a system that produces a concrete, tangible result.
Relations:
• Association
It is the most basic type of relationship that indicates the invocation from an actor or use case to another operation (use case). This relationship is denoted by a single arrow.
• Unit or instantiation
It is a very particular form of relationship between classes, in which a class depends on another, ie, is instantiated (created). This relationship is denoted by a dotted arrow.
• Generalization
This type of relationship is one of the most used, does double duty depending on their stereotype, which can be use (you use << >>) or Inheritance (<< extends >>).
This type of relationship is geared exclusively for use cases (and not actors).
Class diagram
Class diagrams show the different classes that make up a system and how they relate to each other. It is said that class diagrams are "static" diagrams because they show the classes, along with their methods and attributes as well as the static relationships between them
Sequence Diagrams
Sequence diagrams showing the message exchange (ie the way call) at any given time. Sequence Diagrams put special emphasis in the order and the time that messages are sent to objects.
Collaboration Diagrams
Collaboration Diagrams show the interactions occurring between the objects participating in a specific situation.
State Diagrams
State Diagrams show the different states of an object during its life and the stimuli that cause state changes in an object.
Activity diagram
Activity Diagrams describe the sequence of activities in a system. Activity Diagrams are a special form of State Diagrams, that only (or mostly) contains Activities.
RECOMENDACIONES
Recomendaciones para desarrollar un Diagrama de Casos de Uso
Hemos recopilado consejos de varios autores y a continuación mostramos seis pasos para un buen desarrollo de un Diagrama de Casos de Uso.
Paso1: Identificar Requisitos
En esta actividad, deberemos responder a los siguientes cuestionamientos: ¿Qué le permite hacer, el sistema de software o negocio, al usuario? y ¿El cliente o usuario me solicita alguna restricción para construir el sistema de software? Contestando a esas preguntas se deberá realizar una lista que contendrá los requisitos del sistema, esta lista representará los servicios o funciones ofrecidos por el sistema.
Paso 2: Identificar Actores
Luego de identificar las funciones y servicios del sistema se procede a identificar actores del sistema. Se puede buscar en las categorías de personas, otro sistema o software, dispositivos de hardware o redes de computadoras.
Paso 3: Identificar Escenarios
Un escenario muestra la secuencia de pasos que se produce cuando un actor interactúa con el sistema en una situación específica y un tiempo determinado. Su propósito es servir en la identificación de casos de uso.
Paso 4: Desarrollar 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 todos los escenarios similares se agrupan en un solo caso de uso.
Paso 5: Especificar Casos de Uso Luego de haber identificado los casos de uso, se tiene que indicar la forma en que el actor interactúa con el sistema.
Paso 6: Identificar Relaciones entre Casos de Uso y entre Actores En esta actividad se identifican, en base a las especificaciones de casos de uso y de actores, las relaciones "incluye", "extiende" y "generaliza" entre casos de uso y actores respectivamente, Es importante resaltar que las relaciones para casos de uso es opcional.
RECOMENDACIONES
Recomendaciones para desarrollar un Diagrama de Casos de Uso
Hemos recopilado consejos de varios autores y a continuación mostramos seis pasos para un buen desarrollo de un Diagrama de Casos de Uso.
Paso1: Identificar Requisitos
En esta actividad, deberemos responder a los siguientes cuestionamientos: ¿Qué le permite hacer, el sistema de software o negocio, al usuario? y ¿El cliente o usuario me solicita alguna restricción para construir el sistema de software? Contestando a esas preguntas se deberá realizar una lista que contendrá los requisitos del sistema, esta lista representará los servicios o funciones ofrecidos por el sistema.
Paso 2: Identificar Actores
Luego de identificar las funciones y servicios del sistema se procede a identificar actores del sistema. Se puede buscar en las categorías de personas, otro sistema o software, dispositivos de hardware o redes de computadoras.
Paso 3: Identificar Escenarios
Un escenario muestra la secuencia de pasos que se produce cuando un actor interactúa con el sistema en una situación específica y un tiempo determinado. Su propósito es servir en la identificación de casos de uso.
Paso 4: Desarrollar 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 todos los escenarios similares se agrupan en un solo caso de uso.
Paso 5: Especificar Casos de Uso Luego de haber identificado los casos de uso, se tiene que indicar la forma en que el actor interactúa con el sistema.
Paso 6: Identificar Relaciones entre Casos de Uso y entre Actores En esta actividad se identifican, en base a las especificaciones de casos de uso y de actores, las relaciones "incluye", "extiende" y "generaliza" entre casos de uso y actores respectivamente, Es importante resaltar que las relaciones para casos de uso es opcional.
APRECIACIÓN
DEL EQUIPO
APRECIACIÓN
DEL EQUIPO
Para hacer el análisis, implementar un sistema, escribir la documentación, identificar las pruebas y vender el funcionamiento del sistema, por lo que el documento debe ser:
GLOSARIO
GLOSARIO
diagrama es un gráfico que
presenta en forma esquematizada información relativa e inherente a algún tipo
de ámbito, como ser la política o la economía de alguna nación o empresa y que
aparecerá representada numéricamente y en formato tabulado.
Entidad es toda colectividad que puede considerarse como una unidad. El concepto suele utilizarse para nombrar a una corporación o compañía que se toma como persona jurídica.
Dependencia es un término con
diversos usos que puede utilizarse para mencionar a una relación de origen o
conexión, a la subordinación a un poder mayor o a la situación de un sujeto que
no está en condiciones de valerse por sí mismo
Generalización es un elemento
esencial del proceso científico en general. En un mundo ideal, para poner a
prueba una hipótesis probarías una población entera
Linkografía
http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html
https://msdn.microsoft.com/es-pe/library/dd409432.aspx
http://es.slideshare.net/ktyk/uml-casos-de-uso
No hay comentarios:
Publicar un comentario