TheUseCasemodelisaboutdescribingWHAT(asopposedtoHow) thesystemwilldoata high-level and with a user focus for the purpose of capturing system requirements. Use cases document user-system interactions required to perform tasks and define the user and system actions for each "user visible" task performed by the information system. As such they effectively define all user interfaces and the sequence of interactions within them. Use cases focus on "typical" interactions first, describing the case when, "everything goes right” and separately describe exception processing as necessary to accomplish the task. Use cases name the major "processes" and show the actors with which they interact. The process of developing use cases is iterative and begins by identifying the actors involved in the activity.

1. UP - UML
Taller de Casos de Uso y
Documento de Especificación de requerimientos
Javier González Sánchez, MCs
javiergs@acm.org
Departamento de Tecnologías de Información
ITESM, campus Guadalajara

2. javiergs@acm.org

3. Desarrollo de Software
Necesidad
Notación
requerimientos
modelos Proceso
(diagramas) metodología Herramientas
Producto
javiergs@acm.org

4. Ciclo de vida en RUP
fases
Fuente: Jacobson et al., 2000
javiergs@acm.org

5. Diagramas de UML
Los diagramas expresan gráficamente partes de un modelo desde cierta perspectiva
Diagramas de
Componentes
Modelo(s)
Estáticos
Dinámicos
De Estructura
De funcionalidad
De arquitectura
De Comportamiento
javiergs@acm.org

6. Relación entre los resultados
Modelo de
Casos de Uso verificado por
especificado por
realizado por
Modelo de
distribuido por Prueba
Modelo de
Análisis
Modelo de implementado por
Diseño
Modelo de
Despliegue
Modelo de
Implementación
javiergs@acm.org

7. Diagramas por Modelo (estático y dinámico)
javiergs@acm.org

8. Comenzamos
javiergs@acm.org

9. Ejemplo
javiergs@acm.org

10. Comenzamos
javiergs@acm.org

11. Relaciones: comunicación
UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
1. Comunicación
javiergs@acm.org

12. Relaciones: inclusión
2. Inclusión
una instancia del Caso de Uso origen incluye también el
comportamiento descrito por el Caso de Uso destino
<<include>> reemplaza a <<uses>>
javiergs@acm.org

13. Relaciones: extensión
3. Extensión
el Caso de Uso origen extiende el comportamiento del Caso de
Uso destino
javiergs@acm.org

14. Relaciones: herencia
4. Herencia
el Caso de Uso origen hereda la especificación del Caso de Uso destino
y posiblemente la modifica y/o amplía
javiergs@acm.org

15. Comenzamos
1. Id del documento
2. Titulo
3. Pre-condiciones
4. Post-condiciones
5. Flujo de acción
6. Flujos alternos
7. Comentarios / notas adicionales
javiergs@acm.org

16. Comenzamos
javiergs@acm.org

17. Ejemplo de diagrama de actividad
javiergs@acm.org

18. Resumen del día 1
Documento de Documento de Documento de
especificación de especificación de especificación de
casos de uso casos de uso casos de uso
Diagrama de Diagrama de Diagrama de
casos de uso casos de uso casos de uso
Proyecto
El
Cliente Documento de Diagrama Documento de
Y especificación de de especificación de
casos de uso
Sus casos de uso actividad
necesidades
Diagrama de Diagrama de
casos de uso
casos de uso
Modelo de casos de uso
El analista con los requerimientos
javiergs@acm.org

19. javiergs@acm.org

20. Caso de estudio
Sistema “Grafica”
Sistema
javiergs@acm.org

21. Caso de estudio (parte A)
javiergs@acm.org

22. Caso de estudio (parte B)
javiergs@acm.org

23. SRS
 Portada
<Project Name>
Software Requirements Specification
For <Subsystem or Feature>
Version <1.0>
javiergs@acm.org

24. SRS
 Histórico
Revision History
Version Description Author
Date
<dd/mmm/yy> <x.x> <details> <name>
javiergs@acm.org

25. SRS
 Introducción al documento: propósito, definiciones, referencias
 Descripción del producto: función, características, dependencias
 Requerimientos: funcional y no funcional
 Apéndices: función, características, dependencias
javiergs@acm.org

26. Gracias !
Javier González Sánchez, MCs
javiergs@itesm.mx
javiergs@acm.org