capítulo 2 y 4: requerimientos y modelo funcionalci3715/teoria/clase3.pdf · requerimientos...

86
Capítulo 2 y 4: Requerimientos y Modelo Funcional

Upload: lybao

Post on 21-Sep-2018

252 views

Category:

Documents


0 download

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

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

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

¿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

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

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

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

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

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

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

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

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

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

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

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

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

¿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

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

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

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

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

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

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

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

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

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

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

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

•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

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

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

•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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿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

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

<<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

<<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

<<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

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

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

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

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

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

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

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

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

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.