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

Capítulo 2 y 4: Requerimientos

y Modelo Funcional

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.

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

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

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…

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

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

Actividades de Ciclo de Vida del Software ...y sus modelos

Diseño de Sistema

Diseño Detallado

Implemen-tación

tosAnálisis

Modelo de Caso de Uso

Diseño de Sistema

Diseño Detallado

Implemen-tación

tosAnálisis

Objetos de Dominio de Aplicación

Expresado en términos de

Diseño de Sistema

Diseño Detallado

Implemen-tación

tosAnálisis

Sub-sistemas

Estructura-do por

Diseño de Sistema

Diseño Detallado

Implemen-tación

tosAnálisis

Sub-sistemas

Estructura-do por

Objetos del Dominio de

Solución

Realizado por

Diseño de Sistema

Diseño Detallado

Implemen-tación

tosAnálisis

Sub-sistemas

Estructura-do por

class...class...class...

Código Fuente

Implementado por

Solución

Realizado por

Diseño de Sistema

Diseño Detallado

Implemen-tación

tosAnálisis

Sub-sistemas

Estructura-do por

Código Fuente

Implementado por

Solución

Realizado por

Modelo de Caso de Pruebas

Verificado por

class....? Modelo de Caso de Uso

Actividades de Ciclo de Vida del Software

Diseño de Sistema

Diseño Detallado

Implemen-tación

tosAnálisis

Sub-sistemas

Objetos del Dominio de Solución

Código Fuente

Modelo de Caso de Pruebas

Estructurado por

Implementado por

Realizado por Verificado por

class.... ? Modelo de Caso de Uso

Necesidad vs. Solución

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

Determinación de Requerimientos

• Fuentes:• Documentación.

• Expertos.

• Técnicas• Cuestionarios• Cuestionarios

• Entrevistas

• Talleres

• Prototipos

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

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

Tipos de Requerimientos

Requerimientos: Clasificación de uso común

Requerimientos: Categorías FURPS+

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

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

• 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

•Frecuencia y severidad de fallas

•Facilidades de recuperación

• 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

Condiciones impuestas a otros requerimientos y son tales como:

•Velocidad•Eficiencia

•Eficiencia•Disponibilidad

•Tiempo de Respuesta•Tiempo de Recuperación

•Uso de recursos

•Adaptabilidad•Mantenibilidad•Compatibilidad

•Configurabilidad

•Configurabilidad•Instalabilidad

Especifica restricciones de codificación o de

construcción del sistema:•Estándares requeridos

•Estándares requeridos•Lenguajes de

implementación•Políticas para la

integridad de Bases de Datos

Especifica:• Elemento externo con

el que el sistema debe interactuarinteractuar

• Restricciones o formatos, tiempos u

otros factores usados en tales interacciones

• Buscar las definiciones restantes de los requerimientos no funcionales e interiorizarlos

• Entender su significado y alcance (su aplicabilidad).

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

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.

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

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

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

• 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

Modelo de Caso de Uso para Manejo de Incidentes

FieldOfficer DispatcherOpenIncident

<<initiates>>

ReportEmergency

AllocateResources

<<initiates>>

• 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

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.

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

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

Actores

• Usa el sistema cuando interactúacon el CU

• Inicia la ejecución del CU.Pasajero

ComprarTicket

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

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

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.

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

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

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

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

Modelos de Caso de Uso pueden ser empaquetados

Actor.

Caso de UsoClasificador

Actor.

Límite del Sistema

UML 1 usó paquetes

Instructor

PaqueteCourse

GiveLectureInstructor

HoldExercise

DoHomework

Student

Teaching Assistent

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

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.

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.

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

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.

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

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.

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.

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

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.

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

CU Nivel 3Nivel 3 Nivel 3 Nivel 3

OperacionesNivel 4 Nivel 4

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

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.

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.

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

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?

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.

¿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

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

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

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

CU Base

CU Proveedor

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

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

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.

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.

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

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

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

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

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

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.

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

Documents

requerimientos funcionales ejemplo

clase3 nomencla

clase3 procesoweb

guía para el análisis de requerimientos funcionales de una...

e1.1. requerimientos técnicos y funcionales del...

clase3 curvas

clase3 calidad

torres clase3

requerimientos anexo a lista de requerimientos funcionales

especificación de requerimientosespecificación de ... ·...

ing. lisseth agüero mirabal requerimientos. ing. lisseth...

requerimientos funcionales

requerimientos funcionales generales - bancóldex€¦ ·...

cpfisi- estándar requerimientos funcionales y no...

clase3 parte3

e1.1. requerimientos técnicos y funcionales del sistema ·...

requerimientos funcionales-sem2

definiciÓn de requerimientos funcionales para el...

fisiologia clase3

informe de requerimientos funcionales y no …