capítulo 2 y 4: requerimientos y modelo funcionalci3715/teoria/clase3.pdf · requerimientos...
TRANSCRIPT
![Page 1: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/1.jpg)
Capítulo 2 y 4: Requerimientos
y Modelo Funcional
![Page 2: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/2.jpg)
Agenda
• ¿Qué es UML?
• Escenarios:• Una gran forma de establecer comunicación con el cliente
• Casos de Usos• Abstracciones de escenarios• Abstracciones de escenarios
• CU son un puente hacia la transición entre requerimientos funcionales y objetos.
![Page 3: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/3.jpg)
¿Qué es UML? Unified Modeling Language• Convergencia de diferentes notaciones usadas en métodos O.O., principalmente
• OMT (James Rumbaugh and collegues), OOSE (Ivar Jacobson), Booch (Grady Booch)
• Ellos también desarrollaron el Rational Unified Process, el cual llegó a ser Unified Process en 1999
25 años en GE Research, donde desarrolló OMT, junto con (IBM) Rational en 1994, herramienta CASE OMTool
En Ericsson hasta 1994, desarrolló los casos de uso y la herramienta CASE Objectory, en IBM Rational desde 1995, http://www.ivarjacobson.com
Desarrolló el método Booch (“nubes”), ACM Fellow 1995, y IBM Fellow 2003http://www.booch.com/
![Page 4: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/4.jpg)
UML
• Estándar no propietario para modelar sistemas
• Versión Actual: UML 2.2• Información en http://www.uml.org/
• Herramientas Comerciales:• Rational (IBM),Together (Borland), Visual Architect (Visual Paradigm), Enterprise Architect (Sparx Systems)
• Herramientas Software Libre • Herramientas Software Libre http://www.sourceforge.net/
• ArgoUML, StarUML, Umbrello (for KDE), PoseidonUML
• Ejemplo de herramientas de investigación: Unicase, Sysiphus
• Basadas en un modelo de proyecto unificado para modelación, colaboración y organización de proyecto
• http://unicase.org
• http://sysiphus.in.tum.de/
![Page 5: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/5.jpg)
Notación Básica en UML: Primer Resumen
• UML provee una amplia variedad de notaciones para modelar muchos aspectos de sistemas de software
• En la última clase, hicimos una primera pasada sobre:
• Modelo Funcional: diagramas de casos de uso•
• Modelo Objeto: diagramas de clases
• Modelo Dinámico: diagramas de secuencia, de estado
• Ahora veamos con mas detalle…
![Page 6: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/6.jpg)
Historia Reciente de UML
Marzo2003:
• UML 1.5
Julio 2005:
• UML 2.0
Noviembre2007:
• UML 2.1.2
Febrero2009
• UML 2.2• UML 1.5 • UML 2.0 • UML 2.1.2 • UML 2.2
![Page 7: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/7.jpg)
Un Ejemplo Típico de Actividades de Ciclo de Vida del Software
Diseño de Sistema
Diseño Detallado
Implemen-tación
TestingElicitación de Requerimien-
tosAnálisis
![Page 8: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/8.jpg)
Actividades de Ciclo de Vida del Software ...y sus modelos
Diseño de Sistema
Diseño Detallado
Implemen-tación
TestingElicitación de Requerimien-
tosAnálisis
Modelo de Caso de Uso
![Page 9: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/9.jpg)
Actividades de Ciclo de Vida del Software ...y sus modelos
Diseño de Sistema
Diseño Detallado
Implemen-tación
TestingElicitación de Requerimien-
tosAnálisis
Objetos de Dominio de Aplicación
Expresado en términos de
Modelo de Caso de Uso
![Page 10: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/10.jpg)
Actividades de Ciclo de Vida del Software ...y sus modelos
Diseño de Sistema
Diseño Detallado
Implemen-tación
TestingElicitación de Requerimien-
tosAnálisis
Sub-sistemas
Estructura-do por
Objetos de Dominio de Aplicación
Expresado en términos de
Modelo de Caso de Uso
![Page 11: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/11.jpg)
Actividades de Ciclo de Vida del Software ...y sus modelos
Diseño de Sistema
Diseño Detallado
Implemen-tación
TestingElicitación de Requerimien-
tosAnálisis
Sub-sistemas
Estructura-do por
Objetos del Dominio de
Solución
Realizado por
Objetos de Dominio de Aplicación
Expresado en términos de
Modelo de Caso de Uso
![Page 12: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/12.jpg)
Actividades de Ciclo de Vida del Software ...y sus modelos
Diseño de Sistema
Diseño Detallado
Implemen-tación
TestingElicitación de Requerimien-
tosAnálisis
Sub-sistemas
Estructura-do por
class...class...class...
Código Fuente
Implementado por
Objetos del Dominio de
Solución
Realizado por
Objetos de Dominio de Aplicación
Expresado en términos de
Modelo de Caso de Uso
![Page 13: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/13.jpg)
Actividades de Ciclo de Vida del Software ...y sus modelos
Diseño de Sistema
Diseño Detallado
Implemen-tación
TestingElicitación de Requerimien-
tosAnálisis
Sub-sistemas
Estructura-do por
class...class...class...
Código Fuente
Implementado por
Objetos del Dominio de
Solución
Realizado por
Objetos de Dominio de Aplicación
Expresado en términos de
Modelo de Caso de Pruebas
?
Verificado por
class....? Modelo de Caso de Uso
![Page 14: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/14.jpg)
Actividades de Ciclo de Vida del Software
Diseño de Sistema
Diseño Detallado
Implemen-tación
TestingElicitación de Requerimien-
tosAnálisis
Objetos de Dominio de Aplicación
Sub-sistemas
class...class...class...
Objetos del Dominio de Solución
Código Fuente
Modelo de Caso de Pruebas
?
Expresado en términos de
Estructurado por
Implementado por
Realizado por Verificado por
class.... ? Modelo de Caso de Uso
![Page 15: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/15.jpg)
Necesidad vs. Solución
![Page 16: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/16.jpg)
¿Qué deberá hacer el sistema?¿Con qué condiciones y restricciones deberá
hacerlo?¿Qué cualidades o atributos deberá poseer el
sistema?
¿Qué son los Requerimientos?
sistema?
Rational define requerimiento como:“Una condición o capacidad que el sistema (a
construir) debe cumplir”
![Page 17: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/17.jpg)
Determinación de Requerimientos
• Fuentes:• Documentación.
• Expertos.
• Técnicas• Cuestionarios• Cuestionarios
• Entrevistas
• Talleres
• Prototipos
![Page 18: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/18.jpg)
Tipos de Requerimientos
• Requerimientos Funcionales • Describe las interacciones entre el sistema y su ambiente, independiente de la implementación
“Un usuario debe ser capaz de definir un nuevo juego“
• Requerimientos No Funcionales • Aspectos no relacionados directamente al comportamiento funcional
“El tiempo de respuesta debe ser menor a 1 seg”
• Constraints• Impuesto por el cliente o el ambiente
“El lenguaje de implementación debe ser Java “
• También llamados “Pseudo-requerimientos”.
![Page 19: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/19.jpg)
Requerimientos Funcionales vs. No funcionales
Requerimientos Funcionales
• Describe tareas del usuario que el sistema necesita soportar
• Expresado como
Requerimientos No funcionales
• Describe propiedades del sistema o el dominio
• Expresado como • Expresado como acciones“Recomendar una nueva liga”
“Planificar un torneo”
“Notificar a un grupo de interés”
• Expresado como constraints o aserciones negativas“Todas las entradas de usuario deberían ser detectadas dentro de 1 seg”
“Una interrupción del sistema no debería resultar en perdida de datos”.
![Page 20: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/20.jpg)
Tipos de Requerimientos
![Page 21: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/21.jpg)
Requerimientos: Clasificación de uso común
![Page 22: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/22.jpg)
Requerimientos: Categorías FURPS+
![Page 23: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/23.jpg)
Requerimientos: Categorías FURPS+
![Page 24: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/24.jpg)
Tipos de Requerimientos No Funcionales
• Usabilidad
• Confiabilidad• Robustez
• Seguridad
• Rendimiento• Tiempo de Respuesta
• Implementación
• Interfaz
• Operación
• Packaging
• Legal• Tiempo de Respuesta
• Throughput
• Disponibilidad
• Soporte• Adaptabilidad
• Mantenibilidad
Requerimientos de Calidad
Constraints o Pseudo-Requerimientos
![Page 25: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/25.jpg)
Algunas Definiciones de Requerimientos de Calidad
• Usabilidad: Facilidad con la cual los actores pueden ejecutar una función en un sistema
• Usabilidad es uno de los términos mal usados frecuentemente (“El sistema es fácil de usar”)
• Usabilidad debe ser medible, de otra forma es mercadeo• Ejemplo: Especificación del número de pasos (la • Ejemplo: Especificación del número de pasos (la
medida ) para realizar una compra en internet con un navegador web
![Page 26: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/26.jpg)
Requerimientos: Categorías FURPS+
![Page 27: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/27.jpg)
Algunas Definiciones de Requerimientos de Calidad
• Robustez: La habilidad de un sistema de mantener una función
• Incluso si el usuario introduce una entrada errónea• Incluso si hay cambios en el ambiente
• Ejemplo: El sistema puede tolerar temperaturas hasta 90 C90 C
![Page 28: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/28.jpg)
•Frecuencia y severidad de fallas
•Facilidades de recuperación
Requerimientos: Categorías FURPS+
![Page 29: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/29.jpg)
Algunas Definiciones de Requerimientos de Calidad
• Disponibilidad: El radio del tiempo de funcionamiento esperado de un sistema con respecto al agregado del tiempo de funcionamiento e inactivo esperado
• Ejemplo: El sistema no está inactivo más de 5 min por semana
![Page 30: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/30.jpg)
Condiciones impuestas a otros requerimientos y son tales como:
•Velocidad•Eficiencia
Requerimientos: Categorías FURPS+
•Eficiencia•Disponibilidad
•Tiempo de Respuesta•Tiempo de Recuperación
•Uso de recursos
![Page 31: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/31.jpg)
•Adaptabilidad•Mantenibilidad•Compatibilidad
•Configurabilidad
Requerimientos: Categorías FURPS+
•Configurabilidad•Instalabilidad
![Page 32: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/32.jpg)
Requerimientos: Categorías FURPS+
![Page 33: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/33.jpg)
Especifica restricciones de codificación o de
construcción del sistema:•Estándares requeridos
Requerimientos: Categorías FURPS+
•Estándares requeridos•Lenguajes de
implementación•Políticas para la
integridad de Bases de Datos
![Page 34: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/34.jpg)
Requerimientos: Categorías FURPS+
Especifica:• Elemento externo con
el que el sistema debe interactuarinteractuar
• Restricciones o formatos, tiempos u
otros factores usados en tales interacciones
![Page 35: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/35.jpg)
Tarea
• Buscar las definiciones restantes de los requerimientos no funcionales e interiorizarlos
• Entender su significado y alcance (su aplicabilidad).
![Page 36: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/36.jpg)
Requerimientos No Funcionales: Ejemplos
• “Espectadores deben ser capaces de ver un juego sin registro previo y sin previo conocimiento del juego.”�Requerimiento de Usabilidad
• “El sistema debe soportar 10 torneos paralelos”�Requerimiento de Rendimiento�Requerimiento de Rendimiento
• “El operador debe ser capaz de añadir nuevos juegos sin modificaciones al sistema existente.”�Requerimiento de Soporte
![Page 37: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/37.jpg)
Escenarios: Incendio en una Tienda
• Bob, un policía, va manejando por la calle principal en su carro y nota que sale humo de una tienda. Su compañera, Alicia, reporta la emergencia desde una computadora portátil en el carro.
• Alicia introduce la dirección del edificio en su computadora, una breve descripción de su ubicación, y un nivel de emergencia.
Ella confirma su reporte y espera por la aprobación por • Ella confirma su reporte y espera por la aprobación por parte del sistema.
• Juan, el responsable, es alertado de la emergencia por un beep de su estación. El revisa la información enviada por Alicia y aprueba el reporte. Juan ubica una unidad y envía el Tiempo Estimado de LLegada (TELL) a Alicia.
• Alicia recibe la aprobación y el TELL.
![Page 38: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/38.jpg)
Observaciones sobre el escenario del incendio en la tienda
• Escenario concreto
• Describe una sola instancia de reporte del incidente.
• No describe todas las posibles situaciones en la cual un incendio es reportado.
• Actores Participantes
• Bob, Alicia y Juan
![Page 39: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/39.jpg)
Otras Posibilidades de escenarios para el Sistema de Manejo de Incidentes
• ¿Qué se necesita para reportar un incidente de un “Gato en un árbol”? (¿Pasa en Venezuela?)
• ¿Quién está involucrado en el reporte del incidente?
• ¿Qué hace el sistema, si ningún policía está disponible? Si el carro de policía se accidenta en disponible? Si el carro de policía se accidenta en el camino al incidente de un “Gato en un árbol”?
• ¿Qué necesitas hacer si el incidente “Gato en un árbol” se convierte en un incidente de “Abuela que ha caído por las escaleras”?
• ¿Puede el sistema lidiar con incidentes simultáneos reportando “Gato en un árbol” y “el incendio en la tienda?”
![Page 40: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/40.jpg)
Después que los escenarios son formulados• Encontrar todos los casos de uso en el escenario que especifica todas las instancias de cómo reportar un incendio y modelarlas en un modelo de caso de uso
• Ejemplo: “Reportar la Emergencia“ en el primer párrafo del escenario es un candidato para un caso de uso
• Luego añadir más detalles a cada uno de esos • Luego añadir más detalles a cada uno de esos casos de uso describiendo: 1.Nombre del caso de uso
2.Actores Participantes
3.Describir la pre-condición
4.Describir el flujo de eventos
5.Describir la post-condición
6.Describir excepciones
7.Describe requerimientos de calidad (requerimientos no funcionales).
![Page 41: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/41.jpg)
Modelo de Caso de Uso
• Un caso de uso es un flujo de eventos en el sistema, incluyendo la interacción con actores
• Un CU especifica una secuencia de acciones, incluyendo sus variantes, que el sistema puede realizar y que produce un resultado observable válido para un actor particular.
• Cada caso de uso tiene un nombre
• Cada caso de uso tiene una condición de finalización
• Notación gráfica: Un ovalo con el nombre del caso de uso
ReportEmergency
• Notación gráfica: Un ovalo con el nombre del caso de uso
Modelo de Caso de Uso: El conjunto de todos los casos de uso especificando la funcionalidad
completa del sistema
![Page 42: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/42.jpg)
Modelo de Caso de Uso para Manejo de Incidentes
FieldOfficer DispatcherOpenIncident
<<initiates>>
<<initiates>>
ReportEmergency
AllocateResources
<<initiates>>
![Page 43: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/43.jpg)
Modelo de Caso de Uso
• Describe lo que el sistema debe hacer y bajo que restricciones
• Captura los requerimientos funcionales y el ambiente del sistema
• Permite comprender y describir los requerimientos del sistema.sistema.
• Muestra un conjunto de casos de uso y actores con una asociación entre cada par actor/caso de uso.
• Rational define un caso de uso como unconjunto de escenarios de caso de uso, en el que cada escenario es una secuencia de acciones realizadas por el sistema y que conducen a un resultado de valor observable para unactor particular
![Page 44: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/44.jpg)
UML: Primer Paso
• Diagramas de casos de uso• Describe el comportamiento funcional del sistema como es visto por el usuario
• Diagramas de Clases• Describe la estructura estática del sistema: Objetos, atributos, asociaciones
• Diagramas de Secuencia• Diagramas de Secuencia• Describe el comportamiento dinámico entre objetos del sistema
• Diagramas de Estados• Describe el comportamiento dinámico de un objeto individual
• Diagramas de Actividad• Describe el comportamiento dinámico de un sistema, en particular el workflow.
![Page 45: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/45.jpg)
UML – Diagramas de Caso de Uso
Un Actor representa un rol, es decir, un tipo de usuario del sistemaPasajero
Usado durante la elicitación y análisis de requerimientos para representar comportamiento externo (“visible desde afuera del sistema”)
Un caso de uso representa una
ComprarTicket
Modelo de caso de uso:El conjunto de todos los casos de uso que describen completamente la funcionalidad del sistema.
Un caso de uso representa una clase de funcionalidad provista por el sistema
![Page 46: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/46.jpg)
Actores
• Un actor es una entidad externa que interactúa (comunica) con el sistema:
• Usuario
• Sistema Externo (Otro sistema)
• Ambiente físico (por ejemplo, clima)
• Un actor tiene un nombre único y • Un actor tiene un nombre único y una descripción opcional
• Ejemplos:
• Pasajero: Una persona en el tren
• Satélite GPS: Un sistema externo que provee las coordenadas GPS .
Pasajero
Nombre
Descripción Opcional
![Page 47: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/47.jpg)
Actores
• Usa el sistema cuando interactúacon el CU
• Inicia la ejecución del CU.Pasajero
ComprarTicket
![Page 48: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/48.jpg)
Caso de Uso • Un caso de uso representa una clase de
funcionalidad provista por el sistema
• Los casos de uso pueden ser descritos textualmente, con un enfoque sobre el flujo de eventos entre el actor y el sistema
• La descripción textual del caso de uso consiste de 7 partes:
1. Nombre únicoComprarTicket 1. Nombre único
2. Actores participantes
3. Pre-Condición
4. Post-Condición
5. Flujo de eventos
6. Excepciones
7. Requerimientos especiales .
ComprarTicket
![Page 49: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/49.jpg)
Ejemplo de la Descripción Textual del Caso de Uso
1. Nombre: Comprar ticket
2. Actor Participante :Pasajero
3. Pre-Condición:
5. Flujo de eventos:
1. El Pasajero selecciona el número de zonas a viajar
2. El Distribuidor del ticket muestra la cantidad a pagar
PasajeroComprarTicket
3. Pre-Condición:
• Pasajero permanece en frente del distribuidor del ticket
• Pasajero tiene suficiente dinero para comprar el ticket
4. Post-Condición:
• El pasajero tiene el ticket
pagar
3. El Pasajero inserta el dinero, al menos la cantidad a pagar
4. El Distribuidor del ticket devuelve el cambio
5. El Distribuidor del ticket emite el ticket
6. Requerimientos especiales: Ninguno.
![Page 50: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/50.jpg)
Los Casos de Uso pueden estar relacionados
• Relaciones entre actores y CU• Asociación
• Relaciones entre casos de uso• Relación Extends
• Para representar casos de uso algunas veces invocados o una funcionalidad excepcional invocados o una funcionalidad excepcional
• Relación Includes
• Para representar comportamiento funcional común a mas de un caso de uso.
• Relación de Generalización
• Relaciones entre actores• Generalización
![Page 51: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/51.jpg)
Relación <<extends>>• La relación <<extends>>modela casos excepcionales o algunas veces invocados
• La dirección de una relación <<extends>> es hacia el caso de uso extendido
• Los casos de uso que representan flujos excepcionales pueden
Pasajero
Comprar Ticket excepcionales pueden extender más de un caso de uso.
Comprar Ticket
Cancelar Compra
<<extends>>
![Page 52: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/52.jpg)
Ir al CineExtension Points
Después de entrar al cine
Relación <<extends>>
• Extension Points: el caso de uso podrá ejecutarse una vez alcanzado el (los) punto de extensión indicado(s).
Cliente
Comprar Cotufas
<<extend>>
![Page 53: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/53.jpg)
La relación <<includes>>
• La relación <<includes>>representa funcionalidad cómun necesaria es mas de un caso de uso
• <<includes>> permite reusar un caso de uso, no es porque es una excepción
• La dirección de una relación
Pasajero
Comprar Ticket
Comprar MultiAbono
• La dirección de una relación <<includes>> es contraria a la relación <<extends>> .
Comprar Ticket
<<includes>>
Recoger Boleto
<<includes>>
![Page 54: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/54.jpg)
Modelos de Caso de Uso pueden ser empaquetados
Actor.
Caso de UsoClasificador
Actor.
Límite del Sistema
![Page 55: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/55.jpg)
UML 1 usó paquetes
Instructor
PaqueteCourse
GiveLectureInstructor
HoldExercise
DoHomework
Student
Teaching Assistent
![Page 56: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/56.jpg)
Cómo encontrar Casos de Uso
• Seleccionar un escenario • Discutir en detalle con el usuario para entender la interacción del usuario con el sistema
• Seleccionar muchos escenarios para definir el alcance del sistema.
• Discutir el alcance con el usuario• Discutir el alcance con el usuario
• Usar prototipos ilustrativos (mock-ups) como soporte visual
• Descubrir que hace el usuario• Observación de tareas
• Cuestionarios
![Page 57: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/57.jpg)
Ejemplo de Caso de Uso: ReportEmergency1. Nombre de caso de uso: ReportEmergency
2. Actores Participantes:Oficial, Responsable
3. Pre-Condición:El oficial está conectado al Sistema FRIEND
4. Flujo de Eventos: próxima lámina
5. Post-Condición:5. Post-Condición:El oficial ha recibido una aprobación del sistema y la respuesta a la emergencia o el oficial ha recibido una explicación indicando porque no puede ser procesada la emergencia
6. Excepciones:• El oficial es notificado inmediatamente si la conexión entre el terminal y la central se pierde
7. Requerimientos de Calidad:• El reporte del oficial es aprobado dentro de 30 seg.
![Page 58: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/58.jpg)
Ejemplo de Caso de Uso: ReportEmergency
4. Flujo de Eventos:1. El oficial completa el formulario, seleccionando el nivel de
emergencia, tipo, ubicación, y una breve descripción de la situación. El oficial también describe una respuesta a la situación de emergencia. Una vez que el formulario es completado, el oficial envía el formulario, y el Responsable es notificado.
2. El responsable crea un Incidente en la base de datos 2. El responsable crea un Incidente en la base de datos invocando al caso de uso OpenIncident. El selecciona una respuesta y aprueba el reporte.
3. El oficial recibe la aprobación y la respuesta seleccionada.
![Page 59: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/59.jpg)
Otro Ejemplo: Ubicar un Recurso
• Glosario:• Supervisor de Campo: Este es el oficial en el sitio de emergencia
• Encargado de Ubicar Recursos: Es el responsable de asignar y liberar recursos manejados por el sistema FRIENDmanejados por el sistema FRIEND
• Responsable: Un Responsable introduce, actualiza, y elimina Incidentes de Emergencia, Acciones, y Solicitudes en el sistema. El Responsable también cierra Incidentes de Emergencia
• Oficial de Campo: Reporta accidentes desde el sitio de emergencia
![Page 60: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/60.jpg)
Ubicar un Recurso
1. Nombre de caso de uso: AllocateResources
2. Actores Participantes:Oficial de Campo, Responsable, Encargado de Ubicar Recurso,
Supervisor de Campo
3. Pre-Condición :El Encargado de Ubicar Recurso ha seleccionado un recurso
disponibledisponible
4. Flujo de Eventos :1. El Encargado de Ubicar Recurso selecciona un Incidente
2. El Recurso es asignado al Incidente
5. Post-Condición :El caso de uso termina cuando el recurso es asignado
El Recurso asignado no está disponible a otras solicitudes.
6. Requerimientos especiales:El Supervisor de campo es responsable de manejar los
Recursos.
![Page 61: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/61.jpg)
Orden de los pasos cuando se describen los casos de uso
• Primer paso: Nombre de caso de uso• Nombre de caso uso: ReportEmergency
• Segundo paso: Encontrar los actores• Generalizar los nombres concretos del escenario a actores participantesactores participantes
• Actores Participantes:
• Oficial de Campo (Bob y Alicia en el escenario)
• Responsable (Juan en el escenario)
• Tercer paso: Concentrarse en el flujo de eventos• Uso informal del lenguaje natural
![Page 62: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/62.jpg)
Otro Ejemplo de CU
Flujo de Eventos
• El Cliente del Banco especifica una Cuenta y provee las credenciales al Banco para probar que es la persona autorizada para acceder a la Cuenta del Banco
• El Cliente del Banco especifica la cantidad de • El Cliente del Banco especifica la cantidad de dinero que quiere retirar
• El Banco chequea si la cantidad es consistente con las reglas del Banco y el estado de la cuenta del Cliente. Si es el caso, el Cliente recibe el dinero en efectivo.
![Page 63: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/63.jpg)
Atributos de CU
Nombre de Caso de Uso: Withdraw Money Using ATM
Actor Participante: Cliente
Pre-condición:
• El Cliente ha abierto una Cuenta con el Banco Y• El Cliente ha abierto una Cuenta con el Banco Yel Cliente ha recibido una Tarjeta y un PIN
Post-condición:
• El Cliente ha solicitado efectivo O
el Cliente recibe una explicación del ATM del por qué el efectivo no pudo ser entregado.
![Page 64: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/64.jpg)
3. El cliente marca su PIN
Flujo de Eventos: A Request-Response Interaction between Actor and System
1. El Cliente introduce la tarjeta en el ATM
4. Si existen diferentes cuentas afiliadas en la tarjeta, el ATM ofrece
Pasos del Sistema
2. El ATM solicita la entrada de un PIN de cuatro dígitos
Pasos del Actor
7. El Cliente introduce una cantidad
5. El Cliente selecciona una cuenta
8. El ATM entrega el dinero y un recibo, y termina la interacción.
afiliadas en la tarjeta, el ATM ofrece una alternativas de los números de cuenta para la selección del Cliente
6. El ATM solicita la cantidad a ser retirada
![Page 65: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/65.jpg)
Excepciones de CU
Pasos del Actor
1.El Cliente introduce su tarjeta en el ATM.[Tarjeta Inválida]
3.El Cliente marca su PIN. [PIN Inválido]
1a) [Tarjeta Inválida]El ATM entrega la tarjeta y detiene la interacción.
3a)[PIN Inválido]El ATM notifica la falla y permite una segunda oportunidad así como cancelar el caso de uso completo. Después de 3 intentos, notifica la posible retención de la [PIN Inválido]
5. El Cliente selecciona una cuenta.
7. El Cliente introduce una cantidad. [Cuenta Sobregirada]
notifica la posible retención de la tarjeta. Después del 4to intento retiene la tarjeta y detiene la interacción.
7a)[Cuenta Sobregirada]El ATM notifica la falla y el limite disponible y permite un segundo intento así como cancelar el caso de uso completo.
![Page 66: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/66.jpg)
De CU a Objetos
CU Nivel TopNivel 1
CU Nivel 3Nivel 3 Nivel 3 Nivel 3
CU Nivel 2Nivel 2 Nivel 2
A y Bse denominan
Objetos Participantes
A B
CU Nivel 3Nivel 3 Nivel 3 Nivel 3
OperacionesNivel 4 Nivel 4
![Page 67: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/67.jpg)
CU usados por más de un Objeto
CU Nivel Top
CU Nivel 2
CU Nivel 3
Nivel 2
Nivel 1
Nivel 2
Nivel 3 Nivel 3 Nivel 3 CU Nivel 3
Operaciones
Objetos Participantes
Nivel 3 Nivel 3
Nivel 4 Nivel 4
Nivel 3
A B
![Page 68: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/68.jpg)
Guías para Expresar CU (1)
• Nombre• Usar el verbo en modo infinitivo para nombrar el CU
• Debe indicarse el complemento
• Ejemplos:
• “Solicitar Reunión”, “Planificar Reunión”, “Proponer Fecha Alternativa”
• Longitud• Una descripción de CU no debe exceder de 1-2 paginas. Si es mas larga, usar relaciones include
• Un CU debe describir un conjunto completo de interacciones.
![Page 69: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/69.jpg)
Guías para Expresar CU(2)
Flujo de eventos:
• Usar voz activa. Los pasos deben empezar con “El Actor” o “El Sistema …”
• La relación causal entre los pasos debe ser clara
• Todos los flujos de eventos deben estar descritos (No solamente el flujo principal del descritos (No solamente el flujo principal del evento)
• Los limites del sistema deben estar claros. Los componentes externos al sistema deben estar descritos como tal
• Definir los términos importantes en el glosario.
![Page 70: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/70.jpg)
3. El cliente marca su PIN
Flujo de Eventos: Usar Indentación para mostrar la Interacción entre el Actor y el Sistema
1. El Cliente introduce la tarjeta en el ATM
4. Si existen diferentes cuentas afiliadas en la tarjeta, el ATM ofrece una alternativas de los números de cuenta para la
2. El ATM solicita la entrada de un PIN de cuatro dígitos
7. El Cliente introduce una cantidad
5. El Cliente selecciona una cuenta
8. El ATM entrega el dinero y un recibo, y termina la interacción.
ofrece una alternativas de los números de cuenta para la selección del Cliente
6. El ATM solicita la cantidad a ser retirada
![Page 71: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/71.jpg)
Ejemplo de un CU mal escrito
“El conductor llega hasta la barra del estacionamiento, el conductor recibe un ticket del distribuidor, la barra se levanta, el conductor sigue manejando.”
¿Qué hay de malo con este CU?¿Qué hay de malo con este CU?
![Page 72: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/72.jpg)
Ejemplo de un CU mal escrito
“El conductor llega hasta la barra del estacionamiento, el conductor recibe un ticket del distribuidor, la barra se levanta, el conductor sigue manejando.”
• No está claro cual acción produjo que el ticket se emitieraemitiera
• Debido a la forma pasiva, no es claro quien levantó la barra: ¿El conductor? ¿El computador? ¿El responsable
de la barra?• No es una transacción completa
• Una transacción completa debe describir también el pago del estacionamiento y la salida del
estacionamiento.
![Page 73: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/73.jpg)
¿Como escribir un CU? (Resumen)
• Nombre de CU
• Actores • Descripción de los Actores involucrados en el CU
• Pre-condición• “Este CU comienza cuando …”
• Flujo de Eventos • Forma libre, lenguaje natural informal• Forma libre, lenguaje natural informal
• Post-condición • “Este CU termina cuando …”
• Excepciones • Describe que sucede cuando las cosas van mal
• Requerimientos de Calidad • Requerimientos No funcionales, Constraints
![Page 74: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/74.jpg)
Asociaciones de CU
• Dependencias entre los CU son representados con asociaciones de casos de uso
• Asociaciones son usadas para reducir la complejidad
• Descomponer un gran CU en CU mas cortos
• Separar flujos de eventos alternos• Separar flujos de eventos alternos
• Refinar casos de uso abstractos
• Tipos de asociaciones de casos de uso • Includes
• Extends
• Generalización
![Page 75: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/75.jpg)
<<include>>: Descomposición Funcional
• Problema: • Una función en el problema original es demasiado compleja
• Solución: • Describir la función como la agregación de un conjunto de funciones mas simples. El CU asociado es descompuesto en CU mas cortosdescompuesto en CU mas cortos
ManageIncident
CreateIncident HandleIncident CloseIncident
<<include>>
![Page 76: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/76.jpg)
<<include>>: Reusar Funcionalidad Existente• Problema: ¿Hay solapamientos entre CU?. ¿Cómo reusar flujos de eventos en vez de duplicarlos?
• Solución: La relación includes de un CU A a un CU B indica que una instancia del CU A ejecuta todo el comportamiento descrito en el CU B (“A delega a B”)
• Ejemplo: El CU “ViewMap” describe el comportamiento que es usado por el CU “OpenIncident” (“ViewMap” es factorizado)comportamiento que es usado por el CU “OpenIncident” (“ViewMap” es factorizado)
ViewMapOpenIncident
AllocateResources
<<include>>
<<include>>
CU Base
CU Proveedor
![Page 77: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/77.jpg)
<<extend>> Asociacion para CU
• Problema: La funcionalidad en el problema original necesita ser extendida.
• Solución: Una relación extend de un CU A a un CU B
• Ejemplo: “ReportEmergency” está completo por si mismo, pero puede ser extendido por el CU “Help” para un escenario en el cual el usuario requiere ayuda“Help” para un escenario en el cual el usuario requiere ayuda
ReportEmergency
FieldOfficerCheckHelp
<<extend>>
![Page 78: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/78.jpg)
Generalizacion en CU
• Problema: Se quiere factorizar comportamiento común (pero no idéntico).
• Solución: Los CU hijos heredan el comportamiento y el significado del CU padre y añade o sobrescribe algún comportamiento.
• Ejemplo: “ValidateUser” es responsable de verificar la identidad del usuario. El cliente podría requerir dos realizaciones: “CheckPassword” y la identidad del usuario. El cliente podría requerir dos realizaciones: “CheckPassword” y “CheckFingerprint”
ValidateUserCU Padre
CU Hijo
CheckPassword
CheckFingerprint
![Page 79: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/79.jpg)
Caso de Estudio: El Sistema de Revisión de Conferencias
• Presentado en IWWOST 2001
• El propósito del sistema es soportar el proceso de envío, evaluación y selección de trabajos para una conferencia.
![Page 80: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/80.jpg)
Actores I
• PC Chair• Crea la conferencia
• Determina tópicos y temas de la conferencia
• Establece el comité del Programa
• Define la lista final de trabajos aceptados y rechazados
• Define las fechas limites de la conferencia: envío, • Define las fechas limites de la conferencia: envío, revisión, y notificación.
![Page 81: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/81.jpg)
Actores II
• Miembro PC• Evaluar un conjunto de trabajos asignados
• Indicar otra persona como revisor de un trabajo
• Notificar al PC Chair de la lista final de trabajos aceptados
• Revisor• Responsable de revisar un trabajo• Responsable de revisar un trabajo
• Autor• Enviar un trabajo a la conferencia
• Miembros PC y Revisores pueden ser también Autores, y deben tener diferentes Ids para cada rol
![Page 82: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/82.jpg)
Funciones I: Envío de Trabajo
• Cualquier autor registrado puede enviar un trabajo
• El autor debe registrar: el titulo, el resumen, el tópico de la conferencia, y un conjunto de temas elegidos de una lista previamente determinada por el PC Chair
• El sistema, después de chequear los registros de los autores, asigna un ID al nuevo trabajo, y los autores, asigna un ID al nuevo trabajo, y permite al usuario enviarlo cargando un archivo
• En cualquier momento, un autor se le permite chequear los datos sobre sus trabajos enviados. Hasta la fecha limite de envío, el autor se le permite también sustituir el archivo ya cargado por uno nuevo, o cambiar cualquiera de los datos sobre el trabajo
![Page 83: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/83.jpg)
Funciones II: Asignación de trabajos a Miembros PC
• El PC Chair puede indicar conflictos de interés potencial entre miembros PC y trabajos enviados
• Una vez que la fecha limite de envío ha sido alcanzada
• Los miembros PC pueden indicar su interés y conflictos de interés con algunos trabajos
En caso de un conflicto de interés, el miembro PC • En caso de un conflicto de interés, el miembro PC no podrá ver ninguna información sobre el trabajo
• El PC Chair asigna trabajos a miembros PC para revisión, un mensaje de correo electrónico con la lista de trabajos, y un URL a una pagina donde puede acceder los trabajos asignados
![Page 84: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/84.jpg)
Funciones III: Introduciendo una Revisión• Un miembro PC, o un Revisor, puede introducir una revisión para un trabajo asignado
• La revisión es introducida accediendo un formulario que contiene todos ítems de evaluación
• Un miembro PC puede ver otras revisiones • Un miembro PC puede ver otras revisiones (introducidas por otros) para cualquiera de los trabajos que esta revisando, pero solo después que ha introducido su propia revisión
• El PC Chair tiene acceso completo a todos los trabajos y a todas las revisiones
![Page 85: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/85.jpg)
Funciones IV: Elección de Trabajos Aceptados y Rechazados
• Una vez que la fecha limite de revisión ha sido alcanzada, el proceso de revisión es cerrado
• El PC Chair, tomando en cuenta las recomendaciones de los miembros PC y revisores, elije los trabajos que serán aceptados y rechazadosrevisores, elije los trabajos que serán aceptados y rechazados
• Una vez que el proceso es marcado como finalizado por el PC Chair, el sistema envía un mensaje de notificación a los autores del trabajo, el cual incluye las partes apropiadas de las revisiones enviadas por los miembros PC y revisores
![Page 86: Capítulo 2 y 4: Requerimientos y Modelo Funcionalci3715/teoria/clase3.pdf · Requerimientos Funcionales vs. No funcionales Requerimientos Funcionales • Describe tareas del usuario](https://reader031.vdocuments.net/reader031/viewer/2022013114/5ba3f8df09d3f21e368c7f4e/html5/thumbnails/86.jpg)
Resumen
• Escenarios:• Una gran forma de establecer comunicación con el cliente
• Casos de Usos• Abstracciones de escenarios
• CU son un puente hacia la transición entre • CU son un puente hacia la transición entre requerimientos funcionales y objetos.