Proceso Unificado de Desarrollo de Software Fase de …ci3715/teoria/html/cla_0005.pdf · 4 7 Fase...
Transcript of Proceso Unificado de Desarrollo de Software Fase de …ci3715/teoria/html/cla_0005.pdf · 4 7 Fase...
1
1
Proceso Unificado de Desarrollo de Software
Fase de Inicio
A. Soriano (UCV-USB)Septiembre 2005
2
Proceso Unificado: Referencia Básica
Craig Larman
“Applying UML and Patterns: An Introduction to Object. Oriented Analysis and Design and the Unified Process”
Prentice-Hall, Inc. 2002 ISBN 0-13-092569
Descripción del Problema: Cap. 3 Fase de Inicio Cap. 4 -5 - 6 y 7 Modelo de Casos de Uso: Cap. 6 - 25
2
3
Proceso Unificado:Referencias“El Proceso unificado de desarrollo de Software”I. Jacobson, G. Booch y J.RumbaughAddison Wesley - Pearson Education 1999
“Applying UML and Patterns: An Introduction to Object. Oriented Analysis and Design and the Unified Process”Craig LarmanPrentice-Hall, Inc. 2002 ISBN 0-13-092569
“The Rational Unified Process”Ph. KruchtenAddison Wesley 2000
4
Proceso Unificado:Referencias
“El Lenguaje Unificado de Modelado: Manual de Referencia”J.Rumbaugh, I. Jacobson y G. BoochAddison Wesley - Pearson Education 2000
“RUP”Herramienta de Rational
3
5
Proceso Unificado
Modelado del Negocio
ImplementaciónPrueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requerimientos
Gerencia de ProyectoAmbiente
Fases
Iteraciones
Elaboración Construcción Transición
Gerencia de Configuración y Cambio
Inicio
6
Proceso Unificado: Fase de Inicio
tiempo
Inicio Elaboración Construcción Transición
Hito del Ciclo de Vida:Define el alcance y la
factibilidad del proyecto
4
7
Fase de Inicio: ¿Para qué?
Modelado del Negocio
ImplementaciónPrueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requerimientos
Gerencia de ProyectoAmbiente
Fases
Iteraciones
Elaboración Construcción Transición
Gerencia de Configuración y Cambio
Inicio
¿Cuál es la visión y caso del negocio?
¿Es factible el proyecto?
¿Comprar o Construir el software?
¿Orden de precio?
¿Seguir adelante?
8
Fase de Inicio: ¿Cuántas iteraciones?
Iteración ... Iteración Iteración ... Iteración ...
Versiones Versiones Versiones Versiones Versiones Versiones Versiones Versiones
Inicio Elaboración Construcción Transición
5
9
Fase de Inicio: ¿Qué Actividades realizar?
• Formular el alcance del proyecto.Capturar los requerimientos y restricciones mas importantes, de los cuales pueda depender la finalización del producto
• Preparar el caso del negocio, identificar riesgos
y evaluar alternativas para su manejo, personal,
tiempos, estimar costos y beneficios
• Sintetizar una arquitectura candidata
10
Modelo de Casos de Uso
Glosario
Visión, Requerimientosy Caso del Negocio
Fase de Inicio: ¿Qué Artefactos producir?
Visión general (problema, usuarios, producto, restricciones)
Requerimientos principales
6
11
Modelo de Casos de Uso
Glosario
Visión, Requerimientosy Caso del Negocio
Fase de Inicio: ¿Qué Artefactos producir?
Describe la terminología clave
Describe los requerimientos funcionales y aquellos no funcionales relacionados
12
EspecificacionesSuplementarias
Modelo de Casos de Uso
Glosario
Visión y Caso del Negocio
Fase de Inicio: ¿Qué Artefactos producir?
Describe otros requerimientos
7
13
Plan de Iteración
Lista de Riesgos y
Plan de Manejo
EspecificacionesSuplementarias
Modelo de Casos de Uso
Glosario
Visión y Caso del Negocio
Fase de Inicio: ¿Qué Artefactos producir?
Describe y prioriza los riesgos
Describe cómo mitigar los riesgos
Describe qué hacer en la primera iteración de la Fase de Elaboración
14
Modelo del Dominio
Plan de Iteración
Lista de Riesgos y
Plan de Manejo
EspecificacionesComplementarias
Modelo de Casos de Uso
Glosario
Visión y Caso del Negocio
Fase de Inicio: ¿Qué Artefactos producir?
Prototipo
- del comportamiento del sistema
- de la estructura del sistema
Conceptos básico del dominio y relaciones entre ellos
8
15
¿Demasiada Documentación?
NO!
sólo deberá construir los
artefactos que considere necesarios
para alcanzar
el hito de la fase
16
Especificador de caso de uso
Caso de uso
Diseñador de interfaz de usuario
Prototipo de interfaz de usuario
Arquitecto
Descripción de la arquitectura
Analista de sistemas
Modelo de casos de uso
Actor Glosario
Fase de Inicio: ¿Quién es responsable de producir Qué?
9
17
ArquitectoPriorizar los casos de uso
Analista de sistemasEncontrar actores
y casos de usoEstructurar el modelo
de casos de uso
Diseñador de interfaces de usuario
Prototipo de la interfaz de usuario
Especificador de casos de usoDetallar un caso de uso
Fase de Inicio: ¿Cuándo debe producirse un artefacto?
18
Artefactos de la Fase de Inicio: ¿En qué disciplina debe producirse un artefacto?
Modelado del Negocio
ImplementaciónPrueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requerimientos
Gerencia de ProyectoAmbiente
Fases
Iteraciones
Elaboración Construcción Transición
Gerencia de Configuración y Cambio
Inicio
- Caso del Negocio
- Modelo del Negocio
10
19
Artefactos de la Fase de Inicio: ¿En qué disciplina?
Modelado del Negocio
ImplementaciónPrueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requerimientos
Gerencia de ProyectoAmbiente
Fases
Iteraciones
Elaboración Construcción Transición
Gerencia de Configuración y Cambio
Inicio
-Visión
- Modelo de Casos de Uso
- Especificaciones Complementarias
- Glosario
20
Artefactos de la Fase de Inicio: ¿En qué disciplina?
Modelado del Negocio
ImplementaciónPrueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requerimientos
Gerencia de ProyectoAmbiente
Fases
Iteraciones
Elaboración Construcción Transición
Gerencia de Configuración y Cambio
Inicio
- Modelo Conceptual
- Análisis y Diseño de
Interfaces
11
21
Artefactos de la Fase de Inicio: ¿En qué disciplina?
Modelado del Negocio
ImplementaciónPrueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requerimientos
Gerencia de ProyectoAmbiente
Fases
Iteraciones
Elaboración Construcción Transición
Gerencia de Configuración y Cambio
Inicio
Codificación de Prototipos
22
Artefactos de la Fase de Inicio: ¿En qué disciplina?
Modelado del Negocio
ImplementaciónPrueba
Entrega
Análisis y Diseño
Disciplinas
Fundamentales
Requerimientos
Gerencia de ProyectoAmbiente
Fases
Iteraciones
Elaboración Construcción Transición
Gerencia de Configuración y Cambio
Inicio
Plan de Desarrollo del Software
12
23
¿Entendió la Fase de Inicio?
•¿Es una fase que no puede realizarse en unas pocas semanas,
excepto para proyectos pequeños y simples?
•¿Debemos capturar la mayor parte de los requerimientos?
•¿La planificación deberá ser estricta?
•¿ Se define completamente la arquitectura del sistema?
•¿Se debe primero levantar requerimientos, luego diseñar la
arquitectura y finalmente implementar?
•¿Es el documento Visión un documento superfluo?
•¿Es superfluo identificar actores y casos de uso?
•¿Debemos describir en detalle todos los casos de uso?
FALSO
FALSO
FALSO
FALSO
FALSO
FALSO
FALSO
FALSO
24
Los Requerimientos
¿Qué son?
¿Para qué sirven?
¿Cómo se clasifican?
¿A través de qué artefactos pueden describirse?
13
25
Los Requerimientos: ¿Qué son?
¿Qué deberá hacer el sistema?¿En qué condiciones deberá hacerlo?
¿Qué cualidades o atributos deberá poseer el sistema?
26
Los Requerimientos: ¿Para qué sirven?
Requerimientos
14
27
Los Requerimientos: Tipos
28
Los Requerimientos: Categorías FURPS+
15
29Req
u erim
ien t
o s o
A
trib u
tos d
e C
alid
adLos Requerimientos:
Categorías FURPS+
30
Func
iona
les
No
Func
iona
les
Los Requerimientos: Clasificación de uso común
16
31
Los Requerimientos: Artefactos
Los Requerimientos Funcionales
32
¿ Caso de Uso ?
Actor
¿Qué representa la figura?
Sistema
17
33
¿ Caso de Uso ?
¿Qué hace el actor?¡Usa el sistema !El actor interactúa con el sistema.
Se realiza una secuencia específica de acciones
Escenario Instancia de Caso de Uso
34
¿ Caso de Uso ?
• Representa una colección de escenarios de éxito y falla relacionados, que describe actores usando el sistema
• Define una funcionalidad del sistema
18
35
Caso de Uso: Definición en RUP
“Un conjunto de instancias de caso de uso, en el que cada instancia es una secuencia de acciones realizadas por el sistema y que conducen a un resultado de valor observable para un actor particular”
Appliyng UML and patterns. 2° edición
C. Larman
Prentice Hall. 2002
36
Caso de Uso: Definición en RUP
“Un conjunto de instancias de caso de uso, en el que cada instancia es una secuencia de acciones realizadas por el sistema y que conducen a un resultado de valor observable para un actorparticular”
Appliyng UML and patterns. 2° edición
C. Larman
Prentice Hall. 2002
19
37
Caso de Uso: Recomendación
1. Responder a la pregunta:
¿Qué puede hacer el sistema para producir resultados de valor para un actor en particular?
38
Computador,
Lector de código de barra
Software del Sistema
registrar ventas
y manejar los pagos
Caso de Estudio: Sistema de Punto de Venta
Punto de Venta para ventas al detal: POS (Point of Sale)
Uso principal:
Compuesto por: Ilustración extraída de:
Appliyng UML and patterns.
2° edición
C. Larman
Prentice Hall. 2002
20
39
Ejemplo: POSManejar devoluciones
Principal Escenario de éxitoUn cliente llega a la caja con productos para su devolución. El cajero usa el sistema POS para registrar cada producto .....
Escenarios AlternativosEl cliente pagó con tarjeta de crédito y la transacción de reembolso es rechazada, se le informa al cliente y ....
.....
40
¿Cómo determinar los Casos de Uso?
SISTEMA
¿Sistema?
21
41
¿Cómo determinar los Casos de Uso?
SISTEMA
¿Límite del Sistema?
42
¿Cómo determinar los Casos de Uso?
SISTEMA
Límite del Sistema
¿Actores?
22
43
¿Cómo determinar los Casos de Uso?
SISTEMA
Actor
¿Qué quiere el actor? ¿metas? ¿objetivos?
44
¿Cómo determinar los Casos de Uso?
SISTEMA
Actor
Esto, esto, esto
y esto
23
45
¿Cómo determinar los Casos de Uso?
SISTEMA
Actor
Ah!, ahora defino los casos de uso.
46
Casos de Uso:Descripción
Breve
Casual
Completo
Un párrafo resumen correspondiente al escenario principal
Formato informal, los escenarios se presentan en múltiples párrafos
Formatos
Formato elaborado. Todos los pasos y variaciones se describen en detalle; incluye secciones de soporte tales como postcondiciones ...
24
47
Caso de uso en formato breveEjemplo: POS Manejar Devoluciones
Manejar devolucionesUn cliente llega a la caja con productos para su devolución. El cajero usa el sistema POS para registrar cada producto .....
48
Caso de Uso: Manejar DevolucionesPrincipal Escenario de éxito
Un cliente llega a la caja con productos para su devolución. El cajero usa el sistema POS para registrar cada producto .....
Escenarios Alternativos
El cliente pagó con tarjeta de crédito y la transacción de reembolso es rechazada, se le informa al cliente y ....
.....
Caso de uso en formato casualEjemplo: POS Manejar Devoluciones
25
49
Caso de uso en formato completowww.usecases.org
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito ( Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Actor que invoca al sistema
solicitando un servicio con un propósito
particular
50
Caso de uso en formato completoEjemplo: POS Procesar Venta
Actor Principal: Cajero
26
51
Actor Principal
Participantes e Intereses
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito (Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Posibles participantes en el
Caso de Uso y sus intereses
Caso de uso en formato completowww.usecases.org
52
Caso de uso en formato completoEjemplo: POS Procesar Venta
Participantes e Intereses:
Cajero: Desea garantizar registro rápido y sin errores en los pagos
Vendedor: Desea que su comisión se registre adecuadamente
...
27
53
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito (Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Aquellas premisas que deben ser ciertasantes de la ejecución
del caso de uso
Caso de uso en formato completowww.usecases.org
54
Caso de uso en formato completoEjemplo: POS Procesar Venta
Precondiciones: El Cajero está identificado y autorizado
28
55
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito (Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Establece lo que debe cumplirse
en caso de haber sidocompletado con éxito
el caso de uso.Escenario principal o algún curso alterno
Caso de uso en formato completowww.usecases.org
56
Caso de uso en formato completoEjemplo: POS Procesar Venta
Postcondiciones:
La venta fue registrada.
El impuesto fue correctamente calculado.
El inventario fue actualizado.
Las comisiones fueron registadas.
Se generó un recibo.
29
57
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito (Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
También llamado escenario“happy path”.Describe el curso típico que satisface el interés
de aquellos relacionados con el caso de uso
Caso de uso en formato completowww.usecases.org
58
Caso de uso en formato completoEjemplo: POS Procesar Venta
Escenario Principal de Éxito (Flujo Básico):
El escenario registra principalmente tres tipos de pasos:1. Interacción entre actores2. Validación (generalmente hecha por el sistema)3. Cambio de estado del sistema
(ejemplo: registrar o modificar información)
30
59
Caso de uso en formato completoEjemplo: POS Procesar Venta
1) El Cliente llega al POS de salida con artículos a comprar
2) El Cajero inicia una nueva venta
3) El Cajero introduce la identificación del producto
4) El sistema registra cada línea de venta y presenta la descripción y el total acumulado
El Cajero repite los paso 3 y 4 hasta que se indique hecho
Escenario Principal de Éxito (Flujo Básico):
60
Caso de uso en formato completoEjemplo: POS Procesar Venta
Escenario Principal de Éxito (Flujo Básico):1) El Cliente llega al POS de salida con artículos a comprar
2) El Cajero inicia una nueva venta
3) El Cajero introduce la identificación del producto
4) El sistema registra cada línea de venta y presenta la descripción y el total acumulado
El Cajero repite los paso 3 y 4 hasta que se indique hecho
FORMATO DE UNA COLUMNA
31
61
Caso de uso en formato completoEjemplo: POS Procesar Venta
Acción del Actor Respuesta del Sistema
1) El Cliente llega al POS de
salida con artículos a comprar
2) El Cajero inicia una nueva venta
3) El Cajero introduce la
identificación del producto 4) Registra cada línea de venta ypresenta la descripción y el total acumulado
El Cajero repite los paso 3 y 4 hasta
finalizar de introducir los productos
...
Escenario Principal de Éxito (Flujo Básico):
FORMATO DE DOS COLUMNAS
62
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito ( Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Indican otos escenarios o ramas, tanto de éxito
como de falla.Generalmente son más
extensos y complejos que el curso normal
Caso de uso en formato completowww.usecases.org
32
63
Caso de uso en formato completoEjemplo: POS Procesar Venta
Extensiones (Cursos Alternos):3a. Identificación inválida:
1. El Sistema señala el error y rechaza la entrada
3b. Hay diferentes clases del mismo producto:
1. El Cajero puede introducir la categoría y la cantidad
...
64
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito (Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Requerimientos no funcionalesasociados conel caso de uso
Caso de uso en formato completowww.usecases.org
33
65
Caso de uso en formato completoEjemplo: POS Procesar Venta
Requerimientos Especiales:
- Pantalla Táctil en un gran monitor plano. El
texto debe ser visible a 1 metro.
- La respuesta sobre la autorización de la
tarjeta toma 30 segundos el 90% de las veces
...
66
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito (Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Detalles técnicos quedeben ser considerados
en el caso de uso
Caso de uso en formato completowww.usecases.org
34
67
Caso de uso en formato completoEjemplo: POS Procesar Venta
Tecnología y Lista de Variaciones de Datos:
3a. La identificación del producto se introduce por
una lectora laser o por el teclado.
3b. La identificación del producto se introduce en
diferentes esquemas de codificación (UPC, EAN,
JAN o SKU)
68
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito (Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Indica la frecuencia de ocurrencia del caso de uso
Caso de uso en formato completowww.usecases.org
35
69
Caso de uso en formato completoEjemplo: POS Procesar Venta
Frecuencia de Ocurrencia:
Puede ser casi contínuo
70
Actor Principal
Expertos e Interesados
Precondiciones
Éxito Garantizado (Postcondiciones)
Escenario Principal de Éxito (Curso Básico)
Extensiones (Cursos Alternos)
Requerimientos Especiales
Tecnología y Lista de Variaciones de Datos
Frecuencia de Ocurrencia
Preguntas abiertas
Apectosno consideradosque se mantienen
como preguntas abiertas
Caso de uso en formato completowww.usecases.org
36
71
Caso de uso en formato completoEjemplo: POS Procesar Venta
Preguntas Abiertas:
-¿Qué variantes hay en la ley de impuestos?
-¿Puede el cliente directamente usar el lector de
tarjetas de crédito, o es indispensable que lo haga
el cajero?
...
72
Caso de uso:Descripción
¿Qué formato usar?
Breve
Casual
Completo
37
73
Lenguaje de Modelación Unificado
UnifiedModelingLanguage
74
Use CaseDiagramsUse Case
DiagramsDiagrama de Casos de Uso
ScenarioDiagramsScenario
DiagramsDiagrama de Actividad
ScenarioDiagramsScenario
DiagramsDiagrama de Secuencia
Use CaseDiagramsUse Case
DiagramsDiagrama de Estados
StateDiagramsState
DiagramsDiagrama de Clases
Diagrama de Colaboración
Diagramas
StateDiagramsState
DiagramsDiagrama de Objeto
ComponentDiagramsComponent
DiagramsDiagrama deComponentes
ComponentDiagramsComponent
DiagramsDiagrama de Despliegue
UML 1.x: Vistas y Diagramas
38
75
UML 2.0 (Unified Modeling Language)
Diagramas Dinámicos
Múltiples vistasSintaxis y semántica precisas
Diagramas deActividad
Diagramas
Diagramas Estáticos
Diagramas de Secuencia
Diagramas de Comunicación
Diagramas deMáquina de
Estado
Diagramas deDespliegue
Diagramas deComponentes
Diagramas deObjeto
Diagramas deClasesDiagramas de
Casos de Uso
76
Vistas y Diagramas
– Diagramas de Casos de Uso
Representa las funcionalidades
del sistema a partir de las interacciones del usuario
39
77
Diagrama de casos de uso
• Especifica el comportamiento de un sistema• Describe la secuencia de acciones que dan un
resultado observable a un actor• Captura el comportamiento del sistema (el qué)
omitiendo la implementación del comportamiento(el cómo)
• Identifica las funcionalidades visibles al usuario
78
• Representan los entes externos que interactúan con el sistema:
– tipos de usuarios– otros sistemas
• Inician la ejecución de los casos de uso
Diagrama de casos de uso: Actores
40
79
Diagrama de Casos de Uso: Componentes
• Actor: entidad externa que interactúa con el sistema activando o participando en la ejecución los casos de uso
• Caso de uso: secuencia de transacciones iniciadas por un actor y que constituye una funcionalidad del sistema
A
B
Actores Casos de uso
usuario2
usuario1
80
Diagrama de casos de uso: Relaciones
Relaciones entre actores y casos de uso
Relaciones entre casos de uso:
Relaciones entre actores:
Asociación
Extensión (<<extend>>)
Generalización
Inclusión (<<include>>)
Generalización
41
81
Diagrama de casos de uso: Relaciones entre Actores y Casos de Uso
• AsociaciónRelacionaun actor
con un caso de uso
Ir al cine
Actor
82
Diagrama de Casos de Uso: Componentes
nombre del caso de uso
número del caso de uso
nombre del sistema
Nombre del actor
Nombre del actor
nombre del caso de uso
número del caso de uso
Participación de un actor en un caso de uso
42
83
– En la relación de Asociación puede indicarse la cardinalidad (multiplicidad)
Ir al cine1 *
Una persona puede “Ir al cine” cero o muchas veces
Persona
Diagrama de casos de uso: Relaciones entre Actores y Casos de Uso
84
Diagrama de Casos de Uso: Relaciones entre Casos de Uso
• Extensión(<<extend>>)
• Generalización• Inclusión
(<<include>>)Relación que define uncurso alterno opcional
de otro caso de uso (base)
43
85
Diagrama de Casos de Uso: Relación extend
Ir al cine
Comprar cotufas
<<extend>>tengo dinero
• Relaciones extend:el caso de uso Ir al cine puedeincluir el comportamiento especificado en el caso de uso Comprar cotufas
86
Diagrama de Casos de Uso: Relación extend (extension points)
Comprar cotufas
<<extend>>tengo dinero• Extension points:
el caso de uso podrá ejecutarse una vez alcanzado el (los) extension point(s) indicado(s)
Ir al cineExtension points
requerimientos adicionales:despues de entrar al cine
44
87
Diagrama de Casos de Uso: Relación extend
• Es una asociación que describe un curso alterno opcional (la extensión) de otro caso de uso (base).
• ¿Cuándo usarla?– En partes opcionales de un caso de uso– Cursos alternativos que raramente ocurren– Cursos separados que son ejecutados bajo ciertas
condiciones– En situaciones donde se puede seleccionar entre diferentes
alternativas– Puede ser ejecutado directamente por el actor
88
Diagrama de casos de uso: Relaciones entre Casos de Uso
• Extend• Generalización• Include
Relación que define un caso de uso
como una generalización de otro caso de uso
45
89
Relaciones entre Casos de Uso : Generalización
• Relación Generalización: el caso de uso divertirse es una generalización del caso de uso ir al cine
Ir alcine divertirse
90
Diagrama de casos de uso: Relaciones entre Casos de Uso
• Extend• Generalización• IncludeRelación que define
una instancia de un caso de uso como un curso
obligatorio en otro caso de uso
46
91
Relaciones entre Casos de Uso: include
• Relación include: el caso de uso Ir al cine siempre incluye el comportamiento especificado en el caso de uso Comprar entrada
<<include>>Comprar entrada
Comprar cotufa
<<extend>>tengo dinero
Ir al cineExtension points
requerimientos adicionales:despues de entrar al cine
1 *
92
Relaciones entre Casos de Uso: include
• Es una asociación que relaciona cursos fuertemente acoplados que conforman el curso completo del caso de uso base
• ¿Cuándo usarla?– Para particionar un caso de uso complejo en los casos
de usos constitutivos– Separar una parte del caso de uso base que por si misma
constituye una funcionalidad (posible caso de uso abstracto)
47
93
Relaciones entre Casos de Uso: Comparación include/extend
Diferentes intenciones• Include
– permite extraer un comportamiento común o aislarfuncionalidades
– en general los actores no están relacionados con el casode uso aislado
• Extend– permite extraer variantes de un curso normal– el actor puede estar relacionado con el caso de uso
aislado
94
Relaciones entre Casos de Uso: Reacomode e Indique las relaciones
responder
exámen
ir al baño
colocar identificación
al exámen
pediraclaratoria
solicitar
exámen
Realizar la Prueba
leer
exámen
entregar
exámen
estudiante
Utilizar
calculadora
buscar Calificación
48
95
responder
exámen
ir al baño
colocar identificación
al exámen
pediraclaratoria
solicitar
exámen
Realizar la Prueba
leer
exámen
entregar
exámenestudiante
Utilizar
calculadora
Buscar Calificación
<<include>><<include>>
<<include>>
<<include>>
<<include>>
<<extend>>
<<extend>><<extend>>
Relaciones entre Casos de Uso: Reacomode e Indique las relaciones
96
Diagrama de casos de uso: Relaciones entre actores
• Generalización
Un actor es una “instancia”de otro actor
49
97
Relaciones entre actores: Generalización
• Relación de Generalización: una persona es una generalización de un estudiante
estudiantepersona
98
Ejemplo POS : Requerimientos Funcionales
1. Límites 2. Actores 3. Metas
Agente de Impuesto a las
Ventas
CajeroSistema
POSMeta:
Colectar impuestos
Meta:
Adquirir productos
Meta:
Analizar las ventas y producir reportes de eficiencia
Meta:
Procesar ventas
Cliente
Servicio de Ventas
Sistema de
Actividad de Ventas
Servicio de Entrega
50
99
Agente de Impuesto a las
Ventas
CajeroSistema
POSMeta:
Colectar impuestos
Meta:
Adquirir productos
Meta:
Analizar las ventas y producir reportes de eficiencia
Meta:
Procesar ventas
Cliente
Servicio de Ventas
Sistema de
actividad de Ventas
Servicio de Entrega
Cajero Sistema POS
Sistema de Actividad de Ventas
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
100
Cajero Sistema POS
Sistema de Actividad de Ventas
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Administrador del Sistema
Meta:
Procesar ventasMeta:
Analizar las ventas y producir reportes de eficiencia
Meta:
Garantizar seguridad y
Manejar Usuarios
51
101
Meta:
Analizar las ventas y producir reportes de eficiencia
Meta:
Garantizar seguridad y
Manejar Usuarios
Cajero Sistema POS
Sistema de Actividad de Ventas
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Administrador del Sistema
Meta:
Procesar ventas
Meta del Cajero:
Procesar Venta
102
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Meta del Cajero:
Procesar Venta
Procesar Venta Manejar Devoluciones
Cobrar
Alquilar
52
103
Meta:
Analizar las ventas y producir reportes de eficiencia
Meta:
Garantizar seguridad y
Manejar Usuarios
Cajero Sistema POS
Sistema de Actividad de Ventas
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Administrador del Sistema
Meta:
Procesar ventas
Meta del Sistema de Actividad de Ventas:
Analizar las ventas y producir reportes de eficiencia
104
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Meta del Sistema de Actividad de Ventas:
Analizar las ventas y producir reportes de eficiencia
Analizar Actividad
53
105
Meta:
Analizar las ventas y producir reportes de eficiencia
Meta:
Garantizar seguridad y
Manejar Usuarios
Cajero Sistema POS
Sistema de Actividad de Ventas
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Administrador del Sistema
Meta:
Procesar ventas
Meta del Administrador del Sistema:
Garantizar seguridad y
Manejar Usuarios
106
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Meta del Administrador del Sistema:
Garantizar seguridad y
Manejar Usuarios
Manejar Seguridad
Manejar Usuarios
54
107
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
POS
Cajero
Sistema de Actividad de Ventas
Administrador del Sistema
108
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
POS
Cajero
Administrador del Sistema
<<actor>> Sistema de
Actividad de Ventas
Representación alternativa con el
uso de un “estereotipo”
Sistema de Actividad de Ventas
55
109
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
POS
Cajero
Administrador del Sistema
<<actor>> Sistema de
Actividad de Ventas
Manejar Seguridad
Manejar Usuarios
Analizar Actividad
Procesar Venta
Manejar Devoluciones
Cobrar
Alquilar
110
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Servicio de Autorizaciones de Pago
<<actor>> Sistema de
Suscripciones
<<actor>> Sistema Calculador
de ImpuestosManejar Seguridad
Manejar Usuarios
Analizar Actividad
Procesar Venta
Manejar Devoluciones
Alquilar
POS
Cajero
Administrador del Sistema
<<actor>> Sistema de
Actividad de Ventas
Cobrar
......
56
111
Ejemplo POS : Requerimientos Funcionales
4. Casos de Uso
Casos de Uso y Formatos de Descripción
Procesar Venta
Manejar Devoluciones
...
Alquilar
Analizar Actividad de Ventas
Manejar Seguridad
...
Pagar
Cobrar
Manejar Usuarios
...
Completo Casual Breve
112
Ejemplo POS : Otros Requerimientos
UsabilidadFactores Humanos: el Cliente dispondrá de un monitor grande asociado a POS
- El texto debe ser visible a 1 metro
- Evitar colores poco visibles
...
57
113
Ejemplo POS : Otros Requerimientos
Usabilidad
Confiabilidad
Interfaz
Implementación
Documentación Legal
...