Escenarios. Diapositiva 1. Ingeniería de Requerimientos: Escenarios

Transcripción

1 Escenarios Diapositiva 1. Ingeniería de Requerimientos: Escenarios Diapositiva 2. Uso de lenguaje natural Debido a que uno de los objetivos de la Ingeniería de Requisitos es aumentar el conocimiento del dominio del problema, la comunidad de Ingeniería de Software ha desarrollado diversas estrategias para elicitar y especificar los fenómenos propios de cada Universo de Discurso. Algunos autores proponen la utilización de aproximaciones basadas en el lenguaje natural; otros se inclinan por los lenguajes artificiales y las representaciones. Diapositiva 3. a 9 Unos pocos recomiendan la construcción de un vocabulario que capture la jerga usada por los expertos del dominio [Arango93] [Leite90]. La mayoría de ellos ([Anton01] [Benner93], [Carroll95], [Gough95], [Jacobson92], [Potts94], [Potts95], [Rubin92] [van Lamsweerde01] y [Zorman95] ) adhiere al uso de escenarios o casos de uso para describir el comportamiento del macrosistema. Otro uso muy difundido de los escenarios está orientado a modelar el comportamiento del sistema en una etapa posterior al diseño. En este caso, suelen confundirse con los casos de uso. Éstos están destinados a representar las funciones del sistema para el caso general. Los escenarios, en cambio, ejemplifican el uso del sistema. En la práctica, sin embargo, la distinción entre ambos es menos clara y los términos suelen ser usados como sinónimos [Allenby01]. Diapositiva 10. Uso de lenguaje natural En cualquier caso, el propósito del uso de los escenarios es asegurar un buen entendimiento y una mayor colaboración entre todos los participantes del proceso de definición de requisitos. Los ingenieros de requisitos entenderán, modelarán y analizarán el dominio de la aplicación donde el software se utilizará y los clientes/usuarios validarán si la visión de los ingenieros es correcta o no [Hadad99]. Los escenarios pueden ser un medio de lograr este objetivo, puesto que proveen un atractivo medio de comunicación entre los stakeholders del Universo de Discurso. Y es en este punto donde los escenarios se vuelven importantes, puesto que pueden mantener mucha información en una forma que dichos stakeholders podrían reconocer. El uso de lenguaje natural para describir situaciones cumple con el objetivo de mejorar la comunicación con los stakeholders. Los usuarios finales y otros stakeholders de sistemas encuentran más fácil relacionar las funciones provistas por un sistema con ejemplos de la vida real que con descripciones abstractas. Por ello, resulta útil desarrollar un conjunto de

2 escenarios con el objeto de utilizarlos para modelar el comportamiento del sistema. Diapositiva 11. LEL y Escenarios El uso del LEL y Escenarios para la elicitación de requisitos y su utilización a través de todo el proceso de desarrollo de software permite la validación con el cliente/usuario. El propósito principal del léxico es capturar el vocabulario de la aplicación y su semántica, posponiendo la comprensión de la funcionalidad de la aplicación. Los escenarios son usados para entender la aplicación y su funcionalidad: cada escenario describe una situación específica de la aplicación centrando la atención en su comportamiento [Leite00]. Diapositiva 12. Concepto de escenario 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. Diapositiva 13. Objetivos de un escenario Los escenarios logran diferentes objetivos dependiendo de la fase donde se usen durante el proceso de desarrollo de software. En la fase de Ingeniería de Requisitos, los objetivos del escenario son: - capturar los requisitos, - proveer un medio de comunicación entre los stakeholders, - proveer un soporte para trazabilidad Diapositiva 14. Información contenida en un escenario Los escenarios pueden ser escritos de diferentes maneras, pero deberían incluir al menos, la siguiente información: - Una descripción del estado del sistema antes de entrar al escenario - El flujo normal de eventos en el escenario - Excepciones al flujo normal de eventos - Información acerca de otras actividades que podrían estar sucediendo al mismo tiempo)

3 - Una descripción del estado del sistema después de completar el escenario Diapositiva 15. Componentes El modelo de escenario que se utiliza en esta metodología es una estructura compuesta por las siguientes entidades: Título, Objetivo, Contexto, Recursos, Actores, Episodios y Excepciones y el atributo restricción. Diapositiva 16. Modelo de Escenario Un escenario, identificado por un título, debe satisfacer un objetivo que se alcanza mediante la ejecución de los episodios. Éstos representan el curso de acción principal, pero incluyen también variaciones o alternativas posibles. Cada episodio representa una acción realizada por los actores y la utilización de recursos. Mientras se ejecutan los episodios puede surgir una excepción, que señala un obstáculo para lograr el objetivo. El contexto se describe detallando una ubicación geográfica, una ubicación temporal y precondiciones. El atributo restricción es usado para caracterizar requisitos no funcionales aplicados a contexto, recursos y episodios. La comprensión de un escenario se ve facilitada por el uso de lenguaje natural, situaciones bien limitadas y el uso de subescenarios. Estos permiten manejar el problema de la explosión de escenarios. Un subescenario es usado cuando: - se detecta comportamiento común en varios escenarios, - aparecen cursos de acción condicionales o alternativos complejos en un escenario, y - se detecta en un escenario la necesidad de mejorar una situación con un objetivo concreto y preciso Diapositiva 17. Escenario Sintaxis. Diapositiva 18. Título Sintaxis. Diapositiva 19. Objetivo Sintaxis. Diapositiva 20. Contexto Sintaxis. Diapositiva 21. Recursos, Actores Sintaxis. Diapositiva 22. Episodios. Diapositiva 23. Episodios Sintaxis. Diapositiva 24. Excepciones Sintaxis. Diapositiva 25. Restricciones Sintaxis.

4 Diapositiva 26. Ejemplo de Escenario Diapositiva 27. Jerarquía de Escenarios Durante el proceso de construcción de escenarios algunas partes comunes de diferentes escenarios se factorizan para crear subescenarios. Los subescenarios también son generados cuando uno o más episodios de un escenario merecen un tratamiento independiente. Este último paso muestra un comportamiento descendente, así esta parte del proceso puede verse como top-down. En este punto, surge como una fuerte necesidad de los ingenieros tener una visión global de los escenarios y un nuevo paso, ahora bottom-up, es requerido. En este paso se construyen los escenarios integradores, mencionando en sus episodios situaciones concretas descriptas por los escenarios obtenidos previamente. Este proceso no es ni top-down ni bottom-up. Un verdadero proceso bottom-up comenzaría descubriendo episodios, luego armando subescenarios y finalmente integrándolos en escenarios. Mientras un proceso top-down comenzaría armando uno o muy pocos escenarios representando todo el sistema, refinándolos más tarde para obtener una sucesión de escenarios con un creciente nivel de detalle, y eventualmente un creciente número de escenarios. Diapositiva 28. Subescenarios Los subescenarios son escenarios que describen con mayor detalle un episodio de otro escenario. Diapositiva 29. Usos de subescenarios Un subescenario es usado cuando: - se detecta comportamiento común en varios escenarios, - aparecen cursos de acción condicionales o alternativos complejos en un escenario, y - se detecta en un escenario la necesidad de mejorar una situación con un objetivo concreto y preciso Diapositiva 30. Escenarios integradores Los escenarios integradores son escenarios que agrupan escenarios relacionados para ofrecer una visión global del macrosistema Diapositiva 31. Ejemplo de escenario integrador Diapositiva 32. Manejo de anomalías La importancia del manejo de anomalías por parte de los artefactos de software y el impacto que aquéllas provocan en el desarrollo de los mismos es ampliamente reconocida. El ingeniero de software no sólo debe esforzarse por lograr la máxima confiabilidad del sistema en condiciones de uso normal, sino también tratar de proteger a la aplicación de los inconvenientes que surgen del uso de la misma

5 bajo condiciones adversas. Sin embargo, las circunstancias anómalas en las que se va a desempeñar el software son muy poco percibidas en la elicitación de requisitos del Universo de Discurso (UdeD). La Ingeniería de Requisitos se interesa en la elicitación, refinamiento y especificación de las características que el sistema a desarrollar debe presentar. La falta de anticipación de contextos excepcionales da por resultado requisitos no realistas, inalcanzables y/o incompletos. Como consecuencia, el software desarrollado a partir de esos requisitos no será lo suficientemente robusto, con consecuencias a menudo críticas. Diapositiva 33. Anomalías a nivel episodio Si el punto del inconveniente puede precisarse en términos del episodio en que se produce, entonces la anomalía se representa como episodio condicional o como restricción al episodio. Episodios condicionales: Cuando existe un tratamiento específico para la anomalía, se lo modela con episodios condicionales, utilizando la siguiente estructura: SI no se produce la anomalía ENTONCES PROCESO NORMAL SI se produce la anomalía ENTONCES PROCESO ESPECIAL Diapositiva 34. Ejemplo En este caso, se espera que haya al menos un ejemplar disponible siempre, por lo cual la no disponibilidad representa una anomalía. Como puede verse en el ejemplo, existen tratamientos diferentes para la situación normal y para la anómala. En muchos casos, sin embargo, sólo aparece representada la anomalía, y queda implícito que el proceso normal implica la finalización del escenario. No todo episodio condicional proviene de una anomalía. Muchos de ellos son efectivamente alternativas del proceso normal. Si se tuviera que determinar, en forma retrospectiva, si un episodio condicional proviene de una anomalía, bastaría con analizar su condición. Si la misma implica un impedimento sobre un recurso, actor o contexto, entonces puede decirse que se trata de una anomalía. Diapositiva 35. Anomalías a nivel episodio Restricciones: Cuando no existe un tratamiento específico para la anomalía, se lo modela por medio de restricciones al episodio en cuestión, utilizando la siguiente estructura:

6 Episodios: Episodio 1... Episodio n Restricción: no debe producirse la anomalía Episodio n En este caso, si las restricciones se cumplen, continúa el procesamiento normal del escenario. En caso contrario, es decir, cuando se presenta la anomalía, el escenario se interrumpe, ya que no existe un tratamiento especial para la misma. Diapositiva 36. Ejemplo Ejemplo de escenario correspondiente al caso de estudio Almacén de una Fábrica, que ejemplifica este tipo de anomalías. En este caso, pueden producirse dos inconvenientes diferentes en el mismo episodio. Diapositiva 37. Anomalías a nivel escenario Cuando el punto del inconveniente es impreciso, en el sentido que puede ocurrir en más de un episodio del escenario, entonces se modela como una Excepción. En este caso, también puede darse que exista o no un tratamiento para la anomalía. Ejemplo de escenario correspondiente al caso de estudio Pasaportes, con una excepción sin tratamiento. En este caso, como no existe un tratamiento especial para la anomalía, en caso de producirse, se cancelará el escenario. El efecto neto es idéntico al no cumplimiento de una restricción en un episodio sin tratamiento especial. Diapositiva 38. Taxonomía Taxonomía para los diferentes tipos de inconvenientes presentados y las diferentes maneras de representarlos en un escenario, según exista o no tratamiento para los mismos: Cuando existe un tratamiento especial para una anomalía a nivel escenario, dicho tratamiento puede presentar tres formas diferentes. Es posible que se preserve el objetivo del escenario, es decir que el tratamiento implique la ejecución de una acción alternativa que logre el mismo efecto final que el comportamiento normal del escenario. Puede suceder, también, que el tratamiento de la anomalía contenga una acción cuyo objetivo sea diferente al del escenario donde se originó. Y, finalmente, el tratamiento puede ser una mera secuencia de actividades destinadas a restaurar las condiciones iniciales, es decir que se ejecutarán

7 acciones que irán deshaciendo las actividades que se habían llevado a cabo hasta el momento en que se produjo el inconveniente.