Modelo de Casos de Uso 

El modelo de casos de uso captura los requisitos de un sistema. Los casos de uso son un medio de comunicación con los usuarios y otros interesados acerca de lo que se piensa hacer del sistema. 

Actores 

Un diagrama de casos de uso muestra la interacción entre el sistema y entidades externas al sistema. Estas entidades externas se referencian como actores. Los actores representan los roles que pueden incluir usuarios humanos, un hardware externo u otros sistemas. 

Un actor usualmente se dibuja como una figura o alternativamente como una clase con la palabra clave "actor".


sistemasconocimiento


Los actores pueden generalizar otros actores como se detalla en el siguiente diagrama. 

analisis de sistemas

Casos de Uso 

Un caso de uso es una sola unidad de trabajo significativo. Este provee una vista de alto nivel de comportamiento observable para alguien o algo fuera del sistema. La notación por un caso de uso es una elipse. 


caso de uso

La notación para usar un caso de uso es una línea de conexión con una punta de flecha opcional mostrando la dirección del control. 
El siguiente diagrama indica que el actor Customer (cliente) usa el caso de uso withdraw (retirar). 

Resumen Casos de Uso (Use Case)


El conector “use” (usar / asociar) puede tener opcionalmente valores múltiples en cada final, como en el siguiente diagrama que muestra que el cliente puede tener solo una sesión de “withdraw” (retiro) a la vez, pero un banco puede tener cualquier cantidad de clientes haciendo retiros concurrentemente. 

tecnologia

Definiciones de Casos de Uso 
Un Caso de Uso normalmente incluye: 

  • Nombre y Descripción
  • Requisitos
  • Restricciones
  • Escenarios
  • Diagramas de escenarios
  • Información adicional.

Nombre y Descripción 
Un caso de uso normalmente se nombra como una frase verbal y se le da una descripción textual informal. 

Requisitos 
Los requisitos definen los requisitos funcionales formales que un caso de uso debe proveer al usuario final. Estos corresponden a las especificaciones funcionales encontradas en las metodologías estructuradas. Un requisito es un contrato o promesa de que el caso de uso realizará una acción o proveerá algún valor al sistema. 

Restricciones
 
Una restricción es una condición o restricción bajo la cual opera un caso de uso y que incluye pre, y post condiciones y condiciones invariantes. Una pre condición especifica las condiciones que se necesitan cumplir antes de que el caso de uso pueda proceder. Una post condición se usa para documentar el cambio en condiciones que deben ser verdaderas después de la ejecución del caso de uso. Una condición invariante especifica las condiciones que son verdaderas a través de la ejecución del caso de uso. 

Escenarios 
Un escenario es una descripción formal del flujo de eventos que ocurren durante la ejecución de una instancia de casos de uso. Este define la secuencia específica de eventos entre el sistema y los actores externos. Este normalmente se describe en el texto y corresponde a la representación textual del diagrama de secuencia. 

Incluyendo Casos de Uso 

Resumen Casos de Uso (Use Case)

Los casos de uso pueden contener la funcionalidad de otro caso de uso como parte de su proceso normal. En general se asume que cualquier caso de uso incluido se llamará cada vez que se ejecute una ruta básica. Un ejemplo de esto tiene la ejecución de Caso de uso <Card Identification> para ejecutar como parte de un caso de uso <Withdraw>. 


Los casos de uso se pueden incluir por uno o más casos de uso, ayudando a reducir el nivel de duplicación de la funcionalidad realizando un factoreo del comportamiento común en casos de uso que se usan muchas veces. 

Casos de Uso extendidos 

informacion

Un caso de uso se pude usar para extender el comportamiento de otro, esto normalmente se usa en circunstancias. Por ejemplo, si antes de modificar un tipo particular de orden del cliente, un usuario debe obtener la aprobación de una autoridad superior, luego el caso de uso <Get Approval> puede opcionalmente extender el caso de uso <Modify Order>. 


Puntos de extensión 
El punto al cual un caso de uso extendido se agrega se puede definir por medio de un punto de extensión. 

- Include: Cuando se relacionan dos casos de uso con un include, el primer caso (caso de uso base) incluye al segundo (caso de uso incluido). Es decir, que el segundo es parte esencial del primero, sin el segundo el primero no podría funcionar.
Extend: Se utiliza cuando un caso de uso base incorpora el comportamiento de otro caso de uso y “extiende” su funcionamiento.

conocimiento

Límite del sistema 
Usualmente se usa para mostrar casos de uso dentro del sistema y actores fuera del sistema. 
conceptos basicos


Descargar DOCx Hora 6 y 7.

.


Descargar DOCx Hora 4.
Descargar DOCx Hora 5.
17/08/2018 Preparación 75 Aniversario Escuela

20/08/2018  Festejos "Paso a la inmortaldad del Gral. San Martín" 

Ejercicio dispositiva 13 - Hora 2



Descargar DOCx Hora 3.
Descargar PPTx Clases
El diagrama de clases pertenece a la categoría de diagramas de estructura de UML, este debe ser capaz de ofrecer los mecanismos necesarios para capturar y modelar la abstracción de un sistema desde diferentes puntos de vista ya que representa la definición estática del sistema. 

Se puede presentar de diferentes maneras entre las cuales tenemos el modelo conceptual donde se definen las características del problema, especificación donde se definen las interfaces del diagrama para simplificarlo e implementación donde se muestran tal y como aparecen las clases en el entorno de programación. 

Dentro de un diagrama de clases se pueden relacionar las clases con una asociación que define un vínculo que puede darse entre ciertas clases, composición donde las clases son fundamentales para la implementación de otra clase, agregación donde se utilizan clases que no son esenciales para su funcionamiento y la herencia que es la relación de generalización que se utiliza para heredar características de una clase a otra. 

Generalización / Herencia

La herencia es la típica relación de generalización/especialización entre clases. En UML la herencia se representa mediante una flecha, cuya punta es un triángulo vacío. La flecha que representa a la herencia va orientada desde la subclase a la super clase. 

Asociación 

Las asociaciones representan las relaciones más generales entre clases, es decir, las relaciones con menor contenido semántico. Para UML una asociación va a describir un conjunto de vínculos entre las instancias de las clases. Las asociaciones pueden ser binarias (conectan dos clases) o n-arias (conectan n clases), aunque lo más normal en un modelo es utilizar sólo relaciones binarias (en general, y sin entrar en detalles, se puede afirmar que una relación n-aria puede modelarse mediante un conjunto finito de relaciones binarias). 

La forma de representar las asociaciones binarias en UML es mediante una línea que conecta las dos clases. En general, las asociaciones son bi direccionales, esto es, no tienen un sentido asociado. 

Composición 

La composición implica que los componentes de un objeto sólo pueden pertenecer a un solo objeto agregado, de forma que cuando el objeto agregado es destruido todas sus partes son destruidas también.

Descargar DOCx Hora 2.
Descargar PPTx Clases
 
|