Ingenieria en Software

1. Modelado basados en Escenarios
Diseñe y ofrezca atractivas presentaciones
fácilmente y con total confianza.

2. Escenarios
Un escenario es una descripción parcial y concreta del
comportamiento de un sistema en una determinada
situación. Es una descripción parcial, porque no
necesita describir todas las características de las
entidades involucradas, sólo se describe aquello que
está relacionado con un comportamiento particular del
sistema analizado. A pesar de estar acotados a un
determinado comportamiento, describen todo el
contexto que involucra a esa actividad: recursos del
sistema, objetivos de los usuarios, contexto social en
que se desarrolla, entidades involucradas. Proveen un
“retrato” de como esa actividad se lleva a cabo.
Los escenarios describen situaciones teniendo en cuenta
aspectos de uso, permitiendo: conocer el problema, unificar
criterios, ganar compromiso con clientes / usuarios, organizar los
detalles involucrados y entrenar a nuevos participantes.

3. Modelados Basados en Escenarios
El modelado basado en escenarios es una representación del
sistema desde el punto de vista del usuario.
Este modelo en simples palabras sirve para una interacción
más amena entre el sistema y el usuario, por lo tanto el
modelo de análisis con UML comienza con la creación de
escenarios en la forma de “los casos de uso, diagrama de
actividad y diagrama de carril”.

4. Casos de Usos
Caso de uso: Describe un
escenario de un caso
específico en un lenguaje
directo desde el punto de vista
de un actor definido.

5. Diagrama de Actividad
Diagrama de actividad: es un
modelo muy parecido al caso de
uso pero mucho mejor
complementado y proporciona una
representación del flujo de
interacción dentro de un escenario
específico.

6. Diagrama de Carril
Diagrama de carril: Consiste en
tomar el diagrama actividad y
situarlo en filas o en carriles. En
este modelo los actores son
fundamentales ya que en el
diagrama de carril se
especifica claramente, con un
carril, la responsabilidad a cada
actor.

7. Creación de un Caso preliminar de Uso
En esencia, un caso de uso capta las interacciones que ocurren entre los productores y
consumidores de la información y el sistema en sí.
Las dos primeras tareas de la ingeniería de requerimientos concepción e indagación dan la
información que se necesita para comenzar a escribir casos de uso.
Para comenzar a desarrollar un conjunto de casos de uso, se enlistan las funciones o
actividades realizadas por un actor específico.

8. Mejora de un caso de uso preliminar
La lista de extensiones desarrollada como consecuencia de preguntar y responder estas
preguntas debe racionalizarse con el uso de los siguientes criterios: una excepción debe
describirse dentro del caso de uso si el software la puede detectar y debe manejarla una vez
detectada. En ciertos casos, una excepción precipitará el desarrollo de otro caso de uso (el
de manejar la condición descrita).
Recomienda el uso de una sesión de “lluvia de ideas” para obtener un conjunto
razonablemente complejo de excepciones para cada caso de uso.

9. Escrituras de un caso de uso formal
Cuando un caso de uso involucra una actividad crítica o cuando describe un conjunto complejo
de etapas con un número significativo de excepciones, es deseable un enfoque más formal.
• La precondición describe lo que se sabe que es verdadero antes de que inicie el caso de uso.
• El disparador (o trigger) identifica el evento o condición que “hace que comience el caso de
uso”.
• El escenario enlista las acciones específicas que requiere el actor, y las respuestas apropiadas
del sistema.
• Las excepciones identifican las situaciones detectadas cuando se mejora el caso de uso
preliminar. Pueden incluirse o no encabezados adicionales y se explican por sí mismos en
forma razonable

10. Como cualquier otra forma de descripción escrita, un caso de uso es tan
bueno como lo sea(n) su(s) autor(es). Si la descripción es poco clara, el caso
de uso será confuso o ambiguo. Un caso de uso se centra en los
requerimientos funcionales y de comportamiento, y por lo general es
inapropiado para requerimientos disfuncionales. Para situaciones en las que
el modelo de requerimientos deba tener detalle y precisión significativos
(por ejemplo, sistemas críticos de seguridad), tal vez no sea suficiente un
caso de uso.

11. Muchas Gracias
El modelado basado en escenarios es
apropiado para la gran mayoría de todas las
situaciones que encontrará un ingeniero de
software. Si se desarrolla bien, el caso de
uso proporciona un beneficio sustancial
como herramienta de modelado.