Sin ttulo de diapositiva - PowerPoint PPT Presentation

1 / 18
About This Presentation
Title:

Sin ttulo de diapositiva

Description:

... de dados. Se tiene un juego de dados en que un jugador lanza dos dados. ... Descripci n: Este caso de uso comienza cuando el jugador recoge y tira los dados. ... – PowerPoint PPT presentation

Number of Views:66
Avg rating:3.0/5.0
Slides: 19
Provided by: lugu
Category:
Tags: dados | diapositiva | sin | ttulo

less

Transcript and Presenter's Notes

Title: Sin ttulo de diapositiva


1
Universidad de Chile Departamento de Ciencias de
la Computación CC61J - Taller de UML
Introducción al UML Casos de Uso
Luis A. Guerrero
2
Introducción
Definición UML (Unified Modeling Language) es un
lenguaje gráfico para visualizar, especificar,
construir y documentar los artefactos de un
sistema con gran cantidad de software. Cubre
tanto aspectos conceptuales (procesos de negocio,
funciones del sistema) como cosas concretas
(clases, esquemas de bases de datos, componentes
reutilizables, etc.).
3
Introducción
Historia de los lenguajes de modelamiento OO-
Aparecieron entre mediados de los 70's y fines de
los 80's - lenguajes orientados a objetos, -
aplicaciones cada vez más complejas. - En 1989
habían aprox. 10 métodos orientados a objetos. -
En 1994 más de 50 ("guerra de los métodos). -
Tres métodos destacados Método de Booch, OOSE
(Object-Oriented Software Engineering) de
Jacobson, y el OMT (Object Modeling Technique) de
Rumbaugh. - Otros métodos importantes Fusion,
Shlaer-Mellor y Coad-Yourdon.
4
Introducción
Historia de los lenguajes de modelamiento OO
(cont.) - Mediados de 90's Booch, Jacobson y
Rumbaugh toman ideas de los otros. - 1994
Rumbaugh se une a Booch (vers. 0.8 de Unified
Method) en Rational. - Jacobson se une a Rational
(versión 0.9 de UML, junio de 1996). - Versión
1.0 enero 1997, aprobación de OMG, Object
Management Group. - Versión 1.1 en noviembre de
1997 (con nuevas recomendaciones). - Versión 1.2
en junio de 1998. - Versión 1.3 a fines de
1998. - Versión 1.4 septiembre 2001.
5
Casos de uso
Definición Un caso de uso especifica el
comportamiento de un sistema o una parte del
mismo, y es una descripción de un conjunto de
secuencias de acciones, donde cada secuencia
representa la interacción de los elementos
externos del sistema (sus actores) con el propio
sistema. Un caso de uso representa un
requerimiento funcional del sistema.
6
Casos de uso
Ejemplo 1. Un caso de uso fundamental en un
banco, es el procesamiento de préstamos.
7
Casos de uso
Ejemplo 2 Un juego de dadosSe tiene un juego
de dados en que un jugador lanza dos dados. Si el
total obtenido es siete, el jugador gana, de lo
contrario pierde.
Caso de uso Jugar un juego.Participantes
(actores) Jugador.Descripción Este caso de uso
comienza cuando el jugador recoge y tira los
dados. Si los puntos suman siete, gana y pierde
si suman cualquier otro número.
8
Casos de uso
El formato para la descripción de los casos de
uso es el siguiente Caso de uso Nombre del
caso de uso. Actores Lista de actores (agentes
externos). Se indica quién inicia el caso de
uso. Propósito Intención del caso de
uso. Resumen Repetición del caso de uso de alto
nivel o alguna síntesis similar. Tipo Primario,
secundario u opcional. Esencial o
real. Referencias cruzadas Casos y funciones
relacionadas. Descripción Descripción del caso
de uso.
9
Casos de uso
Cada caso de uso debe tener un nombre que lo
distinga de otros casos de uso. Los nombres
pueden ser nombres simples o nombres de camino.
Ejemplo
10
Casos de uso
Un actor representa un conjunto coherente de
roles que juegan los usuarios de los casos de uso
cuando interactúan con éstos. Los actores pueden
ser personas o sistemas mecánicos. Se pueden
definir categorías generales de actores (como
cliente) y especializarlos (como
ClienteComercial) a través de relaciones de
generalización. Ejemplo
11
Casos de uso
Se pueden especificar relaciones de
generalización, inclusión y extensión.
Generalización significa que el caso de uso hijo
hereda el comportamiento y el significado del
caso de uso padre (el hijo puede agregar o
redefinir el comportamiento del padre). Las
relaciones de inclusión y extensión incluyen el
comportamiento de un caso en otro. Ejemplo
12
Casos de uso
Una relación de inclusión se representa como una
dependencia, usando la palabra include. Para
especificar la posición de una inclusión en un
flujo de eventos, se usa la palabra include
seguido del caso de uso que se quiere incluir.
Por ejemplo, para describir el flujo de Seguir
pedido Flujo de eventos principal Obtener y
verificar el número de pedido. include (validar
usuario). Examinar el estado de cada parte del
pedido. Preparar un informe para el usuario.
13
Casos de uso
La extensión se puede ver como que el caso de uso
que extiende, incorpora su comportamiento en el
caso de uso base. Los puntos de extensión son
etiquetas que pueden aparecer en el flujo del
caso de uso base. Por ejemplo, el flujo de Hacer
pedido podría escribirse así Flujo de eventos
principal include (Validar usuario). Recoger los
ítems del pedido del usuario. (establecer
prioridad). Enviar el pedido para ser procesado.
14
Casos de uso
Ejemplo 1 Sistema de ventas. Un sistema de
ventas debe interactuar con clientes, los cuales
efectúan pedidos. Los clientes pueden hacer un
seguimiento de sus propios pedidos. El sistema
envía los pedidos y las facturas a los clientes.
En algunos casos, según la urgencia de los
clientes, se puede adelantar parte del pedido
(realizar pedidos parciales).
15
Casos de uso
Ejemplo 2 Sistema de Validación de tarjetas de
crédito. Existen dos categorías de clientes
individuales y corporativos. Los clientes usan la
tarjeta para comprar artículos o servicios en
locales comerciales. Las tarjetas de crédito de
los clientes por lo general pertenecen a una
entidad bancaria, a quien el local comercial pide
autorización para procesar la venta y emitir el
boucher.
16
Casos de uso
Definición Un requisito es una característica de
diseño, una propiedad o un cierto comportamiento
de un sistema. Cuando se enuncian los requisitos
de un sistema, se establece un contrato que dice
lo que se espera que el sistema haga. Antes de
construir un sistema, debe existir un acuerdo
sobre qué debería hacer el sistema. La mayoría de
los requisitos funcionales de un sistema se
pueden expresar con diagramas de casos de uso.
17
Casos de uso
Al modelar los requerimientos funcionales, se
introducen en los diagramas casos de uso
adicionales, que pueden ser invisibles para los
actores, pero que son comportamientos
fundamentales del sistema. La siguiente figura
extiende el diagrama de casos de uso anterior del
ejemplo anterior.
18
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com