Ingenieria requisitos

  • 7,729 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,729
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
110
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Tema 1 Requisitos de Software: Conceptos, Tipos y Propiedades
  • 2. Tema 1: Requisitos: Conceptos, Tipos y Propiedades • El Modelado de Negocios (MN) y la Ingeniería de Requisitos (IR) son dos sub-disciplinas de la Ingeniería de Software (IS) – La primera – MN - está relacionada con el estudio del espacio del problema en IS – La segunda –IR- está asociada al problema de los requisitos y al espacio de la solución • Cuando se aplican al desarrollo de software como procesos, el MN precede a la IR 3 Modelado del Negocio Ingeniería de Requisitos
  • 3. Tema 1: Requisitos: Conceptos, Tipos y Propiedades • Una vez modelado el sistema de negocio donde se ubicará la aplicación, el proceso de Ingeniería de Requisitos se encarga de: – Especificar las características de la aplicación – Establecer los requisitos funcionales y no- funcionales que la aplicación debe satisfacer 4
  • 4. ¿Qué es un requisito de software? • Perspectiva del usuario – Un requisito es una condición o capacidad de la aplicación (o sistema de software) que necesita un usuario para resolver un problema o alcanzar un objetivo • Perspectiva del desarrollador: – Es una condición o capacidad que debe ser satisfecha o poseída por la aplicación, a fin de satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto • En ambos casos, es una representación documentada de una condición o capacidad que debe mostrar la aplicación en desarrollo 5
  • 5. ¿Qué es un requisito de software? • Los requisitos expresan lo que una aplicación debe hacer para satisfacer necesidades de información de su dominio – Este dominio puede ser: • Un sistema hardware/software – Dispositivo electrónico – Celular – Procesador dedicado, etc. • Un sistema de negocios – Empresa – Unidad organizacional – Proceso de negocio, etc. 6 Sistema de Negocios Sistema H/S Aplicación
  • 6. Requisitos de software • Los requisitos definen: – Lo que la aplicación debe hacer • Funciones que debe ejecutar • Datos que debe capturar y almacenar • Información que debe producir – Las interacciones usuarios-aplicación y aplicación-aplicación • Interfaz gráfica usuario-aplicación (GUI) • Interfaz de la aplicación con otras aplicaciones o sistemas – Las restricciones bajo las cuales la aplicación debe operar • Plataforma de operación de la aplicación(Hardware/Software) • Tecnología de información que debe usar – Los atributos de calidad que la aplicación debe satisfacer • Seguridad, facilidad de uso, documentación, utilidad, etc. 7
  • 7. Requisitos de Software • Clasificación de los requisitos [Wiegers, 2003] 8 Requisito Requisito Funcional Requisito No-Funcional Requisito del Negocio Requisito del Usuario Requisito del Sistema Requisito de Comportamiento Restricción Atributo de Calidad Requisito de Interface Regla del Negocio
  • 8. NO-FUNCIONALES – No están relacionados directamente con el comportamiento de la aplicación – Restringen el diseño de la aplicación (la solución) • Establecen las limitaciones para su desarrollo – Definen la calidad que la aplicación debe tener FUNCIONALES – Establecen: • los objetivos del negocio con respecto a la aplicación • los servicios que la aplicación debe proporcionarle al negocio – Determinan la funcionalidad de la aplicación • Qué funciones debe ejecutar la aplicación Tipos de requisitos de software 9
  • 9. NO-FUNCIONALES – Describen: • las restricciones que se le imponen a la aplicación • las cualidades o atributos de calidad que la aplicación debe satisfacer • Las reglas del negocio que la aplicación debe respetar o implementar • Las interfaces con otros sistemas FUNCIONALES – Describen lo que la aplicación deberá hacer, esto es: • Su comportamiento • Su interacción con los usuarios y su dominio de aplicación (negocio) • Sus respuestas a eventos Diferencias entre los tipos de requisitos 10
  • 10. Tipos de Requisitos Funcionales • Requisitos del Negocio – Se expresan desde la perspectiva de la empresa: • Describen porque la empresa o el cliente desea desarrollar la aplicación • Expresan que objetivos, metas o necesidades la empresa espera alcanzar con el uso de la aplicación 11
  • 11. Tipos de Requisitos Funcionales • Requisitos del Usuario – Se expresan desde la perspectiva del usuario: • Describen las necesidades que los usuarios tienen y las tareas que los usuarios realizarán con la aplicación • Expresan lo que el usuario será capaz de hacer con la aplicación – Se modelan mediante casos de uso – Ejemplos: • Hojear la mapoteca digital • Visualizar un mapa • Comprar un mapa 12
  • 12. Tipos de Requisitos Funcionales • Requisitos del Sistema – Están asociados a productos que tienen componentes de hardware y software – Asumen que la aplicación es parte de un sistema mayor, p.ej.: • Videojuegos, equipos de audio, etc. • Sistemas de información gerencial • Sistemas de control (Ej. Sensores/actuadores) – Ejemplos de requisitos del sistema: • El sistema de control deberá disparar una alarma cada vez que el sensor detecte una presión fuera del rango permisible • La interfaz del celular debe bloquearse cada vez que el usuario presione simultáneamente el botón “Llamar” y la tecla * 13
  • 13. Tipos de Requisitos Funcionales • Requisitos de Comportamiento – Se expresan desde la perspectiva del desarrollador: • Son requisitos funcionales propiamente dichos • Describen los servicios que la aplicación presta a todos sus usuarios directos • Expresan que hace la aplicación bajo ciertos estímulos o eventos (comportamiento del sistema) – Ejemplos: • mimapa.com deberá permitir que el cliente efectúe el pago de su pedido en línea usando tarjetas de crédito o un sistema de pagos en línea (Ej. paypal) • El sistema debe permitirle al usuario visualizar el mapa seleccionado por el usuario de aquellos contenidos en el catálogo de mapas 14
  • 14. Tipos de Requisitos NO-Funcionales • Restricciones: – Expresan las limitaciones que se le imponen al desarrollo la aplicación – Describen aspectos tales como: • Plataforma de desarrollo y operación (H/S) • Uso de estándares, prácticas, métodos de desarrollo, herramientas, etc. • Tiempo máximo de desarrollo • Costo máximo del proyecto – Ejemplos: • mimapa.com debe ser desarrollada: – Bajo una plataforma LAMP: Linux, Apache, MySQL y PHP – En un tiempo no mayor a seis meses – Con costo no superior a los Bs.F 300.000 15
  • 15. Tipos de Requisitos NO-Funcionales • Atributos de calidad – Son las cualidades o propiedades de calidad que la aplicación debe satisfacer, por ejemplo: • El rendimiento que la aplicación debe mostrar • La confiabilidad que debe poseer • La seguridad que debe proveer • La utilidad que debe garantizar – La calidad de una aplicación se mide en función de sus atributos de calidad 16
  • 16. Tipos de Requisitos NO-Funcionales • Atributos de calidad – Para facilitar su medición durante la verificación, deben expresarse cuantitativa o cualitativamente • Ejemplo: – mimapa.com debe tener una confiabilidad igual o mayor al 95% – Los atributos cualitativos se miden usando escalas cualitativas, tales como la Escala de LIKERT – 1: muy bajo, 2: bajo, 3:medio, 4: alto, 5: muy alto • Ejemplo: – mimapa.com debe ser fácil de usar: » Debe medir un mínimo de 4 puntos en una escala de 5 puntos 17
  • 17. Tipos de Requisitos NO-Funcionales 18 Atributos de Calidad del Software (según norma ISO 9126) Atributos de Calidad del Software (ISO 9126) Funcionalidad Utilidad (Usability) Confiabilidad Eficiencia Portabilidad Mantenibilidad
  • 18. Tipos de Requisitos NO-Funcionales • Atributos de Calidad asociados a la Funcionalidad • Grupo de atributos que permiten calificar si una aplicación maneja adecuadamente las funciones para las cuales fue diseñada – Adecuación: • Capacidad de la aplicación para realizar funciones apropiadas a las tareas o procesos del negocio que ejecutan los usuarios – Interoperabilidad: • Habilidad de la aplicación para interactuar con otros sistemas o aplicaciones – Seguridad: • Habilidad de la aplicación para prevenir el acceso no autorizado (accidental o premeditado) a sus programas y datos – Conformidad: • Evalúa si la aplicación se adhiere a estándares y regulaciones establecidas 19
  • 19. Tipos de Requisitos NO-Funcionales • Atributos de Calidad asociados a la Confiabilidad • Miden la capacidad de la aplicación para mantener un nivel de rendimiento aceptable bajo condiciones normales y en un tiempo establecido – Nivel de Madurez: • Mide la frecuencia de fallas ocasionada por errores en el software – Tolerancia a fallas: • Habilidad de la aplicación para mantener un nivel específico de funcionamiento en caso de fallas – Facilidad de Recuperación: • Habilidad de la aplicación para restablecer su nivel de operación y recuperar sus datos ante una falla 20
  • 20. Tipos de Requisitos NO-Funcionales • Atributos de Calidad asociados a la Utilidad • Permiten evaluar el esfuerzo que los usuarios invierten en utilizar el sistema – Comprensibilidad: • Capacidad que tiene la aplicación para que sus usuarios reconozcan la estructura lógica de la aplicación y los conceptos relativos a ella – Facilidad de Aprendizaje: • Capacidad que tiene la aplicación para que sus usuarios aprendan a usarlo – Operatividad: • Capacidad de la aplicación para que sus usuarios la operen y controlen 21
  • 21. Tipos de Requisitos NO-Funcionales • Atributos de Calidad asociados a la Eficiencia • Evalúan la relación entre el nivel de funcionamiento de la aplicación y la cantidad de recursos utilizados – Uso de recursos: • Mide la cantidad de recursos usados y la duración de su uso durante la ejecución de sus funciones – Rendimiento: • Especifican qué tan bien o tan rápido debe la aplicación ejecutar una función dada en términos de: – Velocidad (tiempo promedio de acceso a datos) – Volumen de transacciones por minuto – Capacidad (carga de uso concurrente) – Tiempo (demanda de tiempo real) 22
  • 22. Tipos de Requisitos NO-Funcionales • Atributos de Calidad asociados a la Mantenibilidad • Permiten medir el esfuerzo requerido para mantener la aplicación, bien sea debido a fallas o a mejoras – Facilidad de Modificación: • Capacidad que tiene la aplicación para que sus mantenedores puedan: – Modificar aspectos o funciones – Adaptar la aplicación a un ambiente diferente – Capacidad de análisis: • Capacidad de la aplicación para diagnosticar deficiencias o causas de fallas o identificar partes que han de ser modificadas – Facilidad de prueba: • Capacidad de la aplicación para permitir ser validada, una vez modificada 23
  • 23. Tipos de Requisitos NO-Funcionales • Atributos de Calidad asociados a la Portabilidad • Miden la habilidad de la aplicación para ser transferida de un ambiente (plataforma de operación) a otro – Facilidad de Instalación: • Habilidad de la aplicación para instalarse en su ambiente de operación – Adaptabilidad: • Capacidad de la aplicación para ser adaptada a diferentes ambientes de operación sin que se requiera modificarla más allá de lo requerido – Coexistencia: • Capacidad de la aplicación para coexistir con otras aplicaciones compartiendo recursos comunes 24
  • 24. Tipos de Requisitos NO-Funcionales • Requisitos de interfaz – Expresan las características de la interacción usuario- sistema o sistema-sistema – Se dividen en: • Requisitos de interfaz gráfica (GUI): – Describen las propiedades generales del interfaz gráfica que permitirá la interacción entre el usuario y la aplicación – Ej.: La interfaz de la aplicación mimapa.com debe ser implementada usando tecnología web • Requisitos de interfaces con otros sistemas: – Describen con qué o cómo la aplicación interactuará con otras aplicaciones de software o sistemas de hardware – Ej.: mimapa.com deberá interactuar con el sistema de pagos en línea paypal 25
  • 25. Tipos de Requisitos NO-Funcionales • Reglas del negocio – Expresan regulaciones que la aplicación debe acatar, p.ej.: • Regulaciones gubernamentales: – Leyes, decretos, providencias, etc. • Regulaciones de la empresa: – Políticas, normas, procedimientos, estrategias, etc. • Regulaciones propias de la aplicación: – Estándares y mejores prácticas de desarrollo que deben seguirse – Algoritmos que deben usarse, etc. – Ejemplos: • mimapa.com debe elaborarse siguiendo el método de WATCH adoptado por la empresa VECTOR C.A. • Un cliente puede descargar gratuitamente las actualizaciones de un mapa adquirido por el/ella durante los 12 meses siguientes a su compra 26
  • 26. Niveles de requisitos (adaptado de [Wiegers, 2003]) • Los requisitos tienen tres niveles asociados que determinan su origen y los aspectos que ellos tratan 27 Aspectos de la visión y alcance del producto Aspectos de diseño del producto Aspectos de uso del producto Requisitos No-funcionalesRequisitos Funcionales NiveldelUsuarioNiveldelProductoNiveldelNegocio Requisitos del Negocio Requisitos de Usuarios Requisitos del Sistema Requisitos de Comportamiento Reglas del Negocio Atributos de Calidad Requisitos de Interfaces Restricciones
  • 27. Propiedades de los requisitos • La calidad de los requisitos se mide por sus propiedades: – Cada requisito debe expresarse de una manera sencilla, clara y sin ambigüedades, usando: • Lenguaje natural (Español), • Lenguajes gráficos (Ej. UML) o • Lenguajes formales (Ej. Notación Z) – Preferiblemente, debe expresarse de manera cuantitativa • Uso de métricas que faciliten la verificación – Debe identificarse de manera única e inequívoca • Uso de un sistema de numeración para facilitar su búsqueda y manejo – Debe ser correcto • Debe estar validado por el cliente 28
  • 28. Propiedades de los requisitos • Propiedades (cont.): – Los requisitos deben ser consistentes entre sí • No debe haber conflictos o incompatibilidad entre requisitos – Deben ser completos • Deben describir toda la funcionalidad que la aplicación deberá implementar – Cada requisito debe ser factible (realista o alcanzable) – Debe describir algo que el cliente o usuario necesita • Resuelve algún problema del cliente – Debe ser verificable • Deben medibles y sin ambiguedad – Se le puede hacer un seguimiento a través de todo el desarrollo del sistema 29
  • 29. Tema 2 Los problemas de los requisitos y sus soluciones
  • 30. Tema 2: Problemas de los requisitos y sus soluciones • Los requisitos son elementos críticos y fundamentales del desarrollo de software – Requisitos incompletos, mal especificados e inconsistentes conducen al fracaso de un proyecto • Es importante analizar estos problemas para no caer en el error de desarrollar una aplicación mal fundamentada • Los objetivos instruccionales de este tema son: – Analizar los problemas que los requisitos presentan durante el desarrollo de aplicaciones – Describir las principales soluciones que la Ingeniería de Software ha establecido para resolver estos problemas 31
  • 31. Los problemas de los requisitos • De acuerdo a una encuesta realizada por el Standish Group, los principales factores que afectan a los proyectos de desarrollo de software son: • Requisitos incompletos (13.1%) • Falta de participación del usuario (12.4%) • Falta de recursos (10.6%) • Expectativas poco realistas (9.9%) • Falta de apoyo gerencial (9.3%) • Cambios en los requisitos y las especificaciones (8.7%) • Falta de planificación (8.1%) • El sistema dejó de ser necesario (7.5%) 32
  • 32. Los problemas de los requisitos • Requisitos mal definidos – No reflejan las necesidades reales de los actores del proyecto – Son inconsistentes – Son incompletos – No son factibles • El costo de cambiar los requisitos crece a medida que avanza el proyecto 33 Análisis Diseño Implementación Pruebas Operación Costo Fase del Proyecto
  • 33. Los problemas de los requisitos • El usuario o cliente no siempre sabe lo que quiere del sistema – Al inicio del proyecto, el usuario no sabe que esperar del sistema – Los requisitos tienden a surgir en la medida que el usuario se familiariza con: • las tecnología TIC • el sistema de información 34
  • 34. Los problemas de los requisitos • El usuario no tiene tiempo para participar en el proyecto – Evita participar en el proyecto – No está consciente de la importancia de su participación – No ve al sistema como algo que le pertenece 35
  • 35. Los problemas de los requisitos • Problemas de comunicación – El cliente o usuario no entiende el lenguaje informático de los analistas – Los analistas no entienden el lenguaje del dominio de la aplicación • Múltiples interpretaciones de los requisitos – El analista entiende y especifica de manera diferente los requisitos del cliente – El diseñador interpreta de otra manera los requisitos especificados por el analista 36
  • 36. Soluciones a los problemas de los requisitos • Ya hemos identificado los problemas de los requisitos, ahora bien: – ¿qué soluciones existen? – ¿Cómo podemos enfrentar estos problemas? • La Ingeniería de Requisitos (IR) es una sub-disciplina de la Ingeniería del Software que se encarga de: – estudiar los problemas asociados a los requisitos y – proponer soluciones a estos problemas • La IR establece métodos, modelos, técnicas, herramientas, prácticas, entre otros para resolver los problemas de los requisitos 37
  • 37. Soluciones a los problemas de los requisitos • ¿Cómo resolver los problemas de los requisitos? – Entender la naturaleza del software • La naturaleza del software promueve cambios frecuentes en los requisitos – Entender el espacio del problema antes de analizar el espacio de la solución • Modelar el negocio antes de identificar y especificar requisitos – Utilizar un proceso de Ingeniería de Requisitos bien definido y probado • Este proceso debe describir como identificar, analizar, documentar, verificar y gestionar requisitos • Debe ser parte del proceso de desarrollo de software 38
  • 38. Soluciones a los problemas de los requisitos • ¿Cómo resolver los problemas de los requisitos? – Utilizar prácticas reconocidas (mejores prácticas), p.ej.: • Incorporar al usuario en el desarrollo de la aplicación (participación activa) • Modelar los requisitos usando notaciones gráficas estandarizadas • Gestionar los requisitos – Emplear personal especializado que entienda los problemas de los requisitos • Analistas de Negocios • Analistas de Requisitos 39
  • 39. Espacio del problema vs. espacio de la solución • Los métodos tradicionales de desarrollo de software subestiman la importancia del problema y su análisis – Se centran en la solución y sus requisitos – Por lo que la solución, generalmente, no se alinea al negocio 40
  • 40. Espacio del problema vs. espacio de la solución • La separación del espacio del problema y el de la solución es crucial en toda Ingeniería • La Ingeniería de Sistemas Físicos establece una clara separación entre ambos espacios 41 Formulación del problema Diseño de la solución Selección de la mejor solución Búsqueda de soluciones Análisis del problema Implementación de la solución Espacio del Problema Espacio de la Solución
  • 41. Espacio del problema vs. espacio de la solución – Las necesidades ocurren en el espacio del problema – Los requisitos tienen lugar en el espacio de la solución 42 Modelado de Negocios Ingeniería de Requisitos Espacio de la Solución Espacio del Problema Necesi- dades Aspectos (Features) Requisitos de Software Procedimientos de Pruebas Diseño Doc. del Usuario La Solución (software) Adaptado de [Rational Requirements Management with Use Cases v5.5, 2000] El Problema
  • 42. Espacio del problema vs. espacio de la solución • Relaciones entre el Modelado de Negocios (MN) y la Ingeniería de Requisitos (IR) – MN se encarga del espacio del problema (el sistema de negocios) – Mientras que lR se encarga del espacio de la solución (la aplicación) 43 Modelado de Negocios (el problema) Objetivos Procesos Objetos Reglas Actores Eventos… Ingeniería de Requisitos (la solución) Requisitos No FuncionalesRequisitos Funcionales
  • 43. Soluciones a los problemas de los requisitos • El Modelo de las 6P contribuye, también, a resolver el problema de los requisitos • Este modelo identifica factores críticos de éxito del desarrollo de software 44 Entender la naturaleza del software Producto Utilizar las mejores prácticas Prácticas Gestionar el desarrollo como un proyecto Proyecto Usar un proceso de desarrollo efectivo Proceso Emplear el mejor personal Personas Problema Entender primero el problema antes de modelar la solución
  • 44. Mejores prácticas de Ingeniería de Requisitos • La Ingeniería de Requisitos (IR) propone un conjunto de mejores prácticas que han probado ser efectivas* • Prácticas asociadas al conocimiento de la IR – Capacitar a los analistas en los temas técnicos de la IR – Educar a los Representantes de Usuarios y Gerentes en la problemática y soluciones de los requisitos • Concientizar sobre la necesidad de una IR – Capacitar a los desarrolladores en el dominio de la aplicación (sistema de negocios) – Crear un glosario de términos del sistema de negocios * Adaptado de Wiegers (2003) 45
  • 45. Mejores prácticas de Ingeniería de Requisitos • Prácticas asociadas a la Gestión de Requisitos – Definir un proceso para controlar los cambios de los requisitos – Establecer un Comité encargado del control de cambios – Llevar a cabo el análisis del impacto que cada cambio en los requisitos tiene sobre el proyecto – Establecer una línea base de requisitos y llevar control de las versiones – Mantener históricos de cambios en los requisitos – Hacerle seguimiento a los requisitos • Llevar las matrices de trazabilidad – Medir la variabilidad de los requisitos – Usar herramientas para gestionar requisitos 46
  • 46. Mejores prácticas de Ingeniería de Requisitos • Prácticas asociadas a la Gestión del Proyecto – Seleccionar un ciclo de vida o método de desarrollo apropiado – Definir claramente el proceso de Ingeniería de Requisitos – Basar los planes en los requisitos • Planes iterativos – Renegociar los acuerdos de requisitos – Manejar los riesgos de los requisitos – Aprender de proyectos pasados (lecciones aprendidas) 47
  • 47. Mejores prácticas de Ingeniería de Requisitos • Prácticas asociadas al Descubrimiento de Requisitos – Definir la visión y el alcance del producto – Identificar los tipos de usuarios – Identificar casos de uso – Identificar los eventos y respuestas de la aplicación – Observar a los usuarios realizando sus actividades – Reutilizar requisitos de otros proyectos similares 48
  • 48. Mejores prácticas de Ingeniería de Requisitos • Prácticas asociadas al Análisis de Requisitos – Establecer el contexto de la aplicación • Definir las relaciones entre la aplicación y su dominio o sistema de negocios – Crear prototipos – Analizar la factibilidad de los requisitos – Establecer las prioridades de los requisitos – Modelar los requisitos • Crear modelos funcionales, estructural y dinámicos – Crear un diccionario de datos • Definir los elementos contenidos en los modelos – Asignar requisitos a los subsistemas de la aplicación • Relacionar los requisitos con la arquitectura de la aplicación 49
  • 49. Mejores prácticas de Ingeniería de Requisitos • Prácticas asociadas a la Especificación de Requisitos – Adoptar una plantilla para elaborar el Documento de Requisitos • Usar preferiblemente los estándares y adaptarlo a las necesidades de su organización – Identificar las fuentes de los requisitos • ¿Quién propuso este requisito? – Identificar cada requisito de manera única – Registrar las reglas del negocio – Especificar los atributos de calidad • Usar modelos de calidad para seleccionar los requisitos apropiados a la aplicación • Especificar las métricas para medir los atributos 50
  • 50. Mejores prácticas de Ingeniería de Requisitos • Prácticas asociadas a la Validación de Requisitos – Inspeccionar el Documento de Requisitos (DR) • Realizar la Revisión Técnica del DR – Probar los requisitos • Diseñar las pruebas funcionales basadas en los requisitos – Definir los criterios de aceptación • ¿Qué criterios usará el cliente o usuarios para aceptar la aplicación? 51
  • 51. Tema 3 La Ingeniería de Requisitos: Productos, Procesos y Actores
  • 52. Tema 3: IR - Productos, Procesos y Actores • La Ingeniería de Requisitos (IR) es una sub- disciplina de la Ingeniería de Software – Se encarga del estudio de los requisitos en sistemas automatizados (H/S) • La IR produce: – principios, modelos, métodos, mejores prácticas, técnicas y herramientas automatizadas que contribuyen a mejorar la identificación, análisis, especificación, validación y gestión de los requisitos 53
  • 53. La Ingeniería de Requisitos • La IR se ubica, junto al Modelado de Negocios, al comienzo de la cadena de valor del desarrollo de software Gestión del Proyecto: Alcance, Tiempos, Costos, Recursos y Contratos Gestión de Riesgos Gestión de la Configuración Gestión de la Calidad Modelado del Negocio Ingeniería de Requisitos Diseño Arquitectónico Programación & Integración Pruebas de la Aplicación Entrega de la Aplicación Diseño Detallado 54
  • 54. La Ingeniería de Requisitos • La aplicación de la IR al desarrollo de una aplicación conduce a: – Encontrar y definir las necesidades que tienen los interesados de la aplicación – Transformar la definición de necesidades en una descripción completa y precisa de requisitos, denominada: • Especificación de requisitos – Lograr un entendimiento común, entre clientes/usuarios y desarrolladores, de los requisitos que debe satisfacer la aplicación 55
  • 55. La Ingeniería de Requisitos • Los tres elementos fundamentales de la IR: 56 Agreed requirements System specification System models Requirements engineering process Stakeholder needs Organisational standards Domain information Regulations Existing systems information El proceso: ¿cómo hacerlo? Los productos: ¿qué se hace? El grupo: ¿quienes lo hacen?
  • 56. Los Productos de la Ingeniería de Requisitos ¿Qué productos se elaboran durante el proceso de Ingeniería de Requisitos? 57
  • 57. Los Productos de la Ingeniería de Requisitos • Principales productos generados por el proceso IR «programa» Prototipo de la Aplicación «documento» Documento de Especificación de Requisitos (DER) «documento» Documento de Definición de Requisitos (DDR) «documento» Plan de Gestión de Requisitos «modelo» Modelo Funcional (casos de uso + descripciones textuales) «modelo» Modelo Dinámico (diagramas de actividad, estado y/o secuencias) «modelo» Modelo Estructural (diagramas de componentes y de clases) «documento» Documento de Requisitos Producto IR 58
  • 58. Los Productos de la Ingeniería de Requisitos • El Plan de Gestión de Ingeniería de Requisitos – Es un documento de gestión elaborado por el Líder del Proyecto o el Líder del Grupo de Requisitos – Describe detalladamente las actividades, tiempos, costos y recursos requeridos en el proyecto para realizar los procesos IR • El Prototipo de la Aplicación – Es un programa que exhibe la interfaz gráfica de la aplicación y demuestra su funcionalidad – Es elaborado para verificar: • Los requisitos de los usuarios • Los requisitos de interfaz gráfica 59
  • 59. Los Productos de la Ingeniería de Requisitos • El Documento de Requisitos (DR) debe describir: – Los requisitos funcionales que debe cumplir la aplicación • Requisitos del negocio • Requisitos de los usuarios (servicios que ofrece) • Funciones de la aplicación y su comportamiento – Los requisitos no-funcionales de la aplicación • Reglas de negocio que debe implementar la aplicación • Restricciones bajo las cuales deberá operar la aplicación • Atributos de calidad que deberá cumplir la aplicación • Interfaces con otros sistemas – El dominio de la aplicación (sistema de negocios) y las relaciones entre ambos 60
  • 60. Los Productos de la Ingeniería de Requisitos • El Documento de Requisitos (DR) – Es un documento manual o electrónico que describe y comunica los requisitos de la aplicación – Es utilizado por dos tipos de audiencias: • Clientes, usuarios y gerentes • Desarrolladores de la aplicación • Es, también, denominado: – Especificación de Requisitos de Software (ERS) – Especificación del Sistema (ES) • Por lo general, se divide en dos partes: – Documento o Sección de Definición de Requisitos (DDR) – Documento o Sección de Especificación de Requisitos (DER) 61
  • 61. Los Productos de la Ingeniería de Requisitos • Documento de Definición de Requisitos (DDR) – Está dirigido a los clientes/usuarios – Identifica, describe, organiza y relaciona los requisitos desde la perspectiva de los clientes/usuarios – Cada requisito es debidamente identificado y documentado usando formatos especiales, p.ej.: • Plantilla VOLERE 62 «documento» Documento de Definición de Requisitos (DDR) «documento» Lista de Requisitos Identificados «modelo» Matriz Requisitos .vs. Requisitos «documento» Lista de Requisitos Seleccionados
  • 62. Los Productos de la Ingeniería de Requisitos • Documento de Especificación de Requisitos (DER) – Está dirigido a los desarrolladores del sistema – Describe gráficamente los requisitos contenidos en el DDR usando un lenguaje o notación de modelado, p.ej.: • UML, ER, SADT, Notación Z 63 «documento» Documento de Especificación de Requisitos (DER) «modelo» Modelo Funcional (o de Casos de Uso) «modelo» Modelo Dinámico (o de Comportamiento) «modelo» Modelo Estructural (o de Clases) «diag. UML» Diagrama de Casos de Uso «Document... Descripción Textual de Caso de Uso «diag. UML» Diagrama de Clase «diag. UML» Diagrama de Componentes «diag. UML» Diagrama de Actividad «diag. UML» Diagrama de Estado «diag. UML» Diagrama de Secuencia 1..* 0..* 0..* 0..* 0..*0..* 0..11 1 1..*
  • 63. Los Productos de la Ingeniería de Requisitos • Existen varios estándares y modelos (plantillas o patrones) que ayudan a elaborar el Documento de Requisitos – El estándar IEEE 830-1993 • Propuesto por el Institute of Electrical and Electronics Engineers (IEEE) • Agrupa los documentos DDR y DER en un sólo documento • Es, también, un estándar ANSI – Adaptaciones del estándar IEEE 830-1993 • Adaptación de Wiegers(2003) • Adaptación de Le Vie (2009) http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html 64
  • 64. Los Productos de la Ingeniería de Requisitos 1. Introducción 1. Propósito 2. Convenciones utilizadas 3. Audiencia y lecturas sugeridas 4. Alcance del proyecto 5. Referencias 2. Descripción general 1. Perspectiva del producto 2. Aspectos del producto 3. Tipos de usuarios y sus características 4. Ambiente operativo 5. Restricciones de diseño e implementación 6. Documentación del usuario 7. Supuestos y dependencias 3. Aspectos de la aplicación 1. Aspecto A 1. Descripción y prioridad 2. Estímulo/respuesta 3. Requisitos funcionales 2. Aspecto B … 4. Requisitos de Interfaces 1. Interfaces de usuarios 2. Interfaces de hardware 3. Interfaces de software 4. Interfaces de comunicación 5. Otros requisitos no-funcionales 1. Requisitos de rendimiento 2. Requisitos de seguridad 3. Atributos de calidad 4. … 6. Otros requisitos Apéndice A: Glosario Apéndice B: Modelos de Requisitos 1. Modelo Funcional 2. Modelo Estructural 3. Modelo Dinámico Estructura del Documento de Requisitos según Wiegers (2003) 65
  • 65. Modelo de Negocios BMM Modelo de Eventos Modelo de Actores/ Unidades Modelo de Objetos de Negocio Modelo de Reglas de Negocio Modelo de Procesos de Negocio Modelo de Objetivos Documento de Requisitos Vista General del Sistema Requisitos Funcionales Requisitos No Funcionales Modelo Funcional (Casos de Uso) Modelo Estructural (Clases) Modelo Dinámico • Relaciones de Dependencia entre el Modelo de Negocios y el Documento de Requisitos 66 EspaciodelProblema EspaciodelaSolución
  • 66. Los Procesos de la Ingeniería de Requisitos ¿Qué procesos requiere la Ingeniería de Requisitos? 67
  • 67. El proceso de la Ingeniería de Requisitos 68 Ingeniería de Requisitos (IR) «objetivo» Determinar los requisitos que la aplicación debe satisfacer «actor» Líder del Grupo de Análisis «actor» Grupo de Análisis «actor» Usuarios «recurso» Herramientas, técnicas, patrones, métricas, prácticas, plantillas para IR «Regla» Métodos, Modelos, Estándares y Procedimientos de Desarrollo de Software «modelo» Modelo del Negocio «documento» Plan del Proyecto «documento» Plan de Gestión de Requisitos «Documento» Plan del Proyecto actualizado «documento» Documento de Inicio del Proyecto Información de aplicaciones similares Necesidades de los usuarios «programa» Prototipo de la Aplicación «documento» Documento de Requisitos «documento» Caso de Negocios (Visión del Producto) «persigue» «ejecuta» «apoya» «regula» «controla» «apoya» «apoya»
  • 68. El proceso de la Ingeniería de Requisitos • La Ingeniería de Requisitos es un proceso compuesto por: – Procesos de Desarrollo de Requisitos • Se encargan de capturar, organizar, filtrar y documentar los requisitos – Procesos de Gestión de Requisitos • Planifican y controlan los procesos de desarrollo y controlan los cambios a los requisitos 69 Ingeniería de Requisitos Descubrimiento de Requisitos Análisis de Requisitos Especificación de Requisitos Validación de Requisitos Gestión de Requisitos Desarrollo de Requisitos
  • 69. El proceso de la Ingeniería de Requisitos • El proceso de Descubrimiento de Requisitos (DR) • Denominado, también, Captura de Requisitos – En qué consiste: • En la búsqueda y recolección de requisitos – Qué actividades principales requiere: • Establecer los objetivos de la aplicación – Analizar el Caso de Negocios, Documento de Inicio y Plan del Proyecto • Analizar el modelo de negocios – Analizar el problema que la aplicación debe resolver – Identificar a los usuarios • Recolectar los requisitos que tienen los usuarios – Usar la plantilla VOLERE y/o herramientas de gestión de requisitos • Organizar los requisitos recolectados 70
  • 70. 71
  • 71. El proceso de la Ingeniería de Requisitos • El proceso de Descubrimiento de Requisitos (DR) – Qué técnicas se utilizan para descubrir requisitos: • Entrevista • Prototipos • Reuniones • Observación directa • Reutilización de requisitos • Uso de modelos de negocios • Ingeniería en Reverso • Encuestas (cuestionarios) • Torbellino de ideas • Análisis de documentos 72
  • 72. El proceso de la Ingeniería de Requisitos • El proceso de Análisis de Requisitos (AR) – En que consiste: • En analizar los requisitos recolectados durante el proceso anterior (DR) a fin de: – Determinar y resolver posibles conflictos entre estos requisitos – Refinar los requisitos recolectados y establecer prioridades – Establecer acuerdos entre usuarios y desarrolladores sobre los requisitos que se pueden implementar 73
  • 73. El proceso de la Ingeniería de Requisitos • El proceso de Análisis de Requisitos (AR) – Qué actividades principales requiere: • Refinar y clasificar los requisitos – Verificar necesidad, consistencia, completitud y factibilidad • Negociar requisitos con el cliente y/o usuarios – Discutir, priorizar y acordar requisitos • Modelar los requisitos – Elaborar los modelos funcional, estructural y dinámico de la aplicación • Construir un prototipo de la interfaz gráfica 74
  • 74. El proceso de la Ingeniería de Requisitos • El proceso de Análisis de Requisitos (AR) – Qué técnicas se utilizan para analizar requisitos: • Análisis de los procesos del negocio • Análisis Orientado a Objetos – Modelado de funciones mediante Diagramas de Casos de Uso – Modelado de flujos de trabajo a través de Diagramas de Actividad – Modelado estructural de la aplicación usando Diagramas de Clases – Modelado del comportamiento mediante Diagramas de Secuencia • Análisis Estructurado de Sistemas – Modelado de procesos usando Diagramas de Flujo de Datos (DFD) – Modelado de transiciones empleando Diagramas de Estados – Modelado de entidades por medio de Diagramas Entidad-Interrelación (ER) • Prototipos • Técnicas de negociación 75
  • 75. El proceso de la Ingeniería de Requisitos • El proceso de Especificación de Requisitos (ER) – En que consiste: • En la documentación de los requisitos • Está relacionado con la estructura, calidad y verificabilidad del Documento de Requisitos • Premisa: – “La documentación de requisitos es la precondición fundamental para el manejo exitoso de requisitos” [Kotonya and Sommerville, 2000] – Que actividades principales requiere: • Seleccionar el estándar de documentación • Documentar los requisitos del cliente – Elaborar el Documento de Definición de Requisitos (DDR) • Documentar los requisitos del desarrollador – Elaborar el Documento de Especificación de Requisitos (DER) 76
  • 76. El proceso de la Ingeniería de Requisitos • El proceso de Especificación de Requisitos (ER) – Qué técnicas se utilizan para especificar los requisitos: • Uso de estándares de documentación de requisitos – IEEE P1233/D3 – IEEE 830-1998 – ISO/IEC 12119-1994 – IEEE 1362-1998 (ConOps) • Indicadores de calidad – Modelos de calidad del software • Lenguajes y notaciones – Lenguajes de modelado gráfico » Lenguajes OO: UML » Lenguajes estructurados: DFD, SADT, IDEF » Lenguajes dinámicos: Redes de Petri, Diagramas de Estado – Lenguajes formales de especificación » Notación Z 77
  • 77. El proceso de la Ingeniería de Requisitos • El proceso de Validación de Requisitos (VR) – En qué consiste: • En examinar los productos elaborados durante la Ingeniería de Requisitos para: – determinar si son válidas y aceptables las descripciones de los requisitos del sistema que se desea construir – Qué productos de la IR se validan en este proceso: • Lista de requisitos recolectados • Modelos de Requisitos – Modelos funcional, estructural y dinámico • Prototipo • Documento de Requisitos – Documento de Definición de Requisitos (DDR) – Documento de Especificación de Requisitos (DER) 78
  • 78. El proceso de la Ingeniería de Requisitos • El proceso de Validación de Requisitos (VR) – Los productos de la IR se validan para determinar si sus requisitos son: • Correctos – Satisfacen las necesidades reales de los usuarios • Completos – Incluyen todos los requisitos que los usuarios demandan • Consistentes – No hay conflictos entre requisitos • Libres de errores • Cumplen con los estándares establecidos • Precisos – No hay requisitos ambiguos 79
  • 79. El proceso de la Ingeniería de Requisitos • El proceso de Validación de Requisitos (VR) – Qué actividades y técnicas se utilizan para validar requisitos: • Revisar técnicamente los modelos y documentos – Inspección de modelos – Inspección de documentos • Validar el Prototipo – Evaluación de prototipos de interfaces gráficas • Diseñar pruebas funcionales – Definición de criterios de aceptación » Qué criterios emplearán los usuarios para aceptar la aplicación – Diseño de casos de pruebas para validar las funciones de la aplicación 80
  • 80. El proceso de la Ingeniería de Requisitos • El proceso de Gestión de Requisitos (GR) – En que consiste: • En establecer y mantener, a lo largo de todo el proyecto, un acuerdo con el cliente o usuarios sobre los requisitos de la aplicación – Qué actividades principales se requieren: • Planificar y controlar las actividades de Ingeniería de Requisitos • Controlar los cambios a los requisitos acordados – Definición de la línea base de requisitos – Control de cambios en requisitos • Manejar las relaciones entre requisitos • Manejar las dependencias entre el Documento de Requisitos y los otros documentos del desarrollo – Seguimiento o trazabilidad de requisitos 81
  • 81. El proceso de la Ingeniería de Requisitos • El proceso de Gestión de Requisitos (GR) – Qué técnicas se utilizan: • Planificación y control de proyectos • Control de cambios • Gestión del almacenamiento de requisitos – Identificación de requisitos – Uso de bases de datos para requisitos • Rastreo o trazabilidad de Requisitos 82
  • 82. Los Actores de la Ingeniería de Requisitos 83 ¿Quienes participan en el proceso IR?
  • 83. El grupo de requisitos • En la elaboración del Documento de Requisitos participan un conjunto de interesados o actores – Para garantizar el éxito del proceso IR, este grupo debe estar debidamente organizado y estructurado – A este conjunto organizado de actores se le denomina Grupo de Requisitos 84
  • 84. El grupo de requisitos • Responsabilidades y funciones del Grupo de Requisitos: – Seleccionar un modelo de procesos apropiado para ejecutar la IR – Adaptar el modelo de procesos IR a las características del proyecto y de la empresa – Planificar el proceso de requisitos – Elaborar el Documento de Requisitos siguiendo el proceso – Mantener actualizado el Documento de Requisitos – Hacerle seguimiento a los requisitos (mantener la trazabilidad) – Proporcionar soporte técnico al grupo de desarrollo del sistema en relación a los requisitos 85
  • 85. Tema 4: Modelado Funcional de Requisitos • La Identificación de Requisitos describe cada requisito separadamente – Sin embargo, para comunicar, analizar y validar los requisitos de una aplicación es más conveniente modelarlos gráficamente • Por esta razón, durante el Análisis de Requisitos se elaboran tres modelos de requisitos diferentes: – Modelo Funcional • Representa los requisitos funcionales de la aplicación – Modelo Estructural • Representa la estructura de la aplicación – Modelo Dinámico • Representa el comportamiento de la aplicación 86
  • 86. Tema 4: Modelado Funcional de Requisitos • Los modelos de requisitos son elaborados usando el lenguaje UML – UML provee las notaciones necesarias para modelar : • Los requisitos funcionales • La estructura y comportamiento de la aplicación • Los requisitos funcionales se modelan usando los Diagramas de Casos de Uso del lenguaje UML 87
  • 87. Modelado Funcional de Requisitos • El Modelado Funcional es un proceso mediante el cual se representa gráficamente la funcionalidad de una aplicación • La funcionalidad es el conjunto de funciones o servicios que una aplicación provee a sus usuarios – Determina que operaciones pueden los usuarios realizar con el sistema – La funcionalidad dice que hace el sistema, pero no dice como lo hace • El producto principal del Modelado Funcional de requisitos es un Modelo de Casos de Uso 88
  • 88. Modelado Funcional de Requisitos • Componentes de un Modelo de Casos de Uso – Un Modelo de Casos de Uso consta de uno o más Diagramas de Casos de Uso y un conjunto de descripciones textual • Una descripción textual está asociada a un caso de uso 89
  • 89. Retirar efectivo Validar tarjeta Transferir entre cuentas Consultar saldo Usuario ATM Cambiar clave Diagramas de Casos de Uso • Los Diagramas de Casos de Uso especifican requisitos funcionales – Cada requisito funcional es representado por un caso de uso – Cada caso de uso es documentado mediante una Descripción Textual 90 Caso de uso: Validar tarjeta Actor: Usuario Flujo de eventos: 1.- El usuario introduce la tarjeta 2.- El sistema valida la tarjeta 3.- El sistema presenta el menú de opciones Descripción Textual Diagrama de Casos de Uso
  • 90. uc CasoUsoPrincipal Servicio de Transporte Aéreo Gestionar Vuelos Gestionar reservaciones Consultar productos y servicios Administrar recursos UsuarioNoRegistrado Administrador Aerolinea Registrar usuarios Pasajero Diagramas de Casos de Uso • Los diagramas de casos de uso modelan: – Los actores de un sistema – Los casos de uso – Las relaciones entre actores – Las relaciones entre casos de uso – Las relaciones de comunicación entre actores y casos de uso – Los límites del sistema – El refinamiento o descomposición de los casos de uso 91
  • 91. Diagramas de Casos de Uso • Forma general de un diagrama de casos de uso 92 relación de extensión <<extiende>> relación de inclusión <<incluye>> asociación Caso de uso especializado relación de generalización límite del sistema Caso de uso Actor Caso de uso extendido Caso de uso incluido relación de extensión <<extiende>> relación de inclusión <<incluye>> asociación Caso de uso especializado relación de generalización límite del sistema Caso de uso Actor Caso de uso extendido Caso de uso incluido
  • 92. Diagramas de Casos de Uso • Actor – Símbolo usado para representar el rol que objetos externos, de una misma clase, juegan cuando interactúan con el sistema • Un objeto externo puede ser una persona interesada (stakeholder), un dispositivo u otro sistema • No se refieren a un individuo particular, sino a una clase de individuos que tienen un rol común – Representan a entes externos al sistema – Un actor intercambia señales y datos con el sistema – Un actor es un clasificador y no una ocurrencia 93 Icono creado por el modelador Clasificador con estereotipo «actor» rol rol Representación icónica Rol Icono creado por el modelador Clasificador con estereotipo «actor» rol rol Representación icónica Rol Representación icónica Rol
  • 93. Diagramas de Casos de Uso • Relaciones entre Actores – Se pueden establecer relaciones de generalización entre los actores – Un rol general puede ser heredado por uno o más roles específicos 94 uc Actores PasajeroPilotoAerolinea PasajeroFrecuente (PF) UsuarioNoRegistrado Administrador
  • 94. Diagramas de Casos de Uso • Relaciones entre Actores y Casos de Uso – Los actores se relacionan con los casos de uso mediante asociaciones – Un asociación modela la comunicación bidireccional entre un actor y un caso de uso • Envío de señales – Ej. activación del caso de uso • Envío de datos e información 95 Actor Caso de Uso Actor Caso de Uso
  • 95. Diagramas de Casos de Uso • Relaciones entre casos de uso – Los casos de usos se asocian entre sí usando tres tipos de relaciones: • Relaciones de extensión • Relaciones de inclusión • Relaciones de generalización 96 Caso Uso 1 Caso Uso 2 Caso Uso 3 Caso Uso 4 «incluye» «extiende» Caso Uso 1 Caso Uso 2 Caso Uso 3 Caso Uso 4 «incluye» «extiende»
  • 96. Diagramas de Casos de Uso • Relación de extensión – Modelan relaciones en las cuales un caso de uso base incluye el comportamiento de un caso de uso extendido en uno o más puntos de su flujo de eventos • Estos puntos se denominan puntos de extensión • Tienen asociado una condición que determina cuando el caso de uso extendido es invocado por el caso de uso base – El caso de uso extendido se activa cuando la condición se cumple 97
  • 97. Diagramas de Casos de Uso • Relación de extensión – Usadas para modelar separadamente el comportamiento excepcional del caso de uso base – Este tipo de relación es unidireccional y va desde el caso de uso extendido al caso de uso base usando el estereotipo <<extend>> o << extiende>> 98 uc CasosURelaciónExtensión Realizar reservación Reservar múltiples destinos Condición: {modo="multiples destinos"} Punto de extensión: Verificar modo Caso de uso base Caso de uso extendido «extiende»
  • 98. Diagramas de Casos de Uso • Relación de inclusión – Modelan relaciones en las cuales uno o más casos de uso incluyen (usan) el comportamiento de un caso de uso común – Son usados para compartir comportamiento común entre varios casos de uso – Este tipo de relación es unidireccional y va desde el caso de uso base al caso de uso incluido usando el estereotipo <<include>> o <<incluye>> 99 uc CasosUsoRelaciónInclusión Usar reservación Registrar el vuelo«incluye»
  • 99. Diagramas de Casos de Uso • Relación de generalización en casos de uso – Modela las relaciones en las cuales el comportamiento de un caso de uso general (padre) es heredado por uno o más casos de uso especializados (hijos) 100 uc CasosUsoRelaciónGeneralización Actualizar reservación Realizar reservación Modificar reservación Eliminar reservación Caso de uso General Casos de uso específicos
  • 100. Diagramas de Casos de Uso • Reglas de estilo para elaborar Diagramas de Casos de Uso – Cada actor y caso de uso debe tener un nombre único – Los actores deben tener nombres y/o íconos representativos • Los nombres deben indicar roles – El nombre de un caso de uso debe indicar acción y debe ser claro y conciso • Forma general: Verbo + predicado • Ejemplos: – Actualizar itinerarios – Realizar reservación – Gestionar vuelos 101
  • 101. Diagramas de Casos de Uso • Reglas de estilo para Diagramas de Casos de Uso – Los casos de uso de un diagrama deben estar todos a un mismo nivel de abstracción – Evite el cruce de líneas – Evite tener demasiados casos de uso en un mismo diagrama • Use la regla del 7 2: – El número apropiado de casos de uso por diagrama está en el rango de 5 a 9 – Evite el uso complejo de relaciones de extensión e inclusión • No más de tres niveles de relaciones consecutivas 102
  • 102. Diagramas de Casos de Uso • Ejemplos de Diagramas de Casos de Uso: Servicio de Transporte Aéreo 103 uc CasoUsoPrincipal Servicio de Transporte Aéreo Gestionar Vuelos Gestionar reservaciones Consultar productos y servicios Administrar recursos UsuarioNoRegistrado Administrador Aerolinea Registrar usuarios Pasajero uc Actores PasajeroPilotoAerolinea PasajeroFrecuente (PF) UsuarioNoRegistrado Administrador
  • 103. Diagramas de Casos de Uso 104 uc CasoUsoGestionarVuelos Actualizar Aerolineas Actualizar Aviones Actualizar itinerarios Actualizar Pilotos Actualizar Aeropuertos Aerolinea uc GestionarReservaciones Realizar reservación Modificar reservación Eliminar reservación Usar reservación Consultar promociones Actualizar reservación Registrar el vuelo Consultar promociones de PF Aerolinea Pasajero PasajeroFrecuente (PF) Consultar itinerarios Reservar múltiples destinos «extend» «incluye» «extiende»
  • 104. Descripción textual de casos de uso • La simplicidad de los diagramas de casos de uso tienen un costo asociado: – Baja expresividad: • Las acciones que ocurren entre un actor y el caso de uso no se pueden capturar con los símbolos de los casos de uso – Cada caso de uso tiene asociado un flujo de eventos que indica el orden en que sus acciones se ejecutan – Ejemplo: 1. El sistema presenta la forma “Registro de Cliente” 2. El usuario ingresa los datos de la forma y pulsa “enter” 3. El sistema valida el nombre de la empresa y el RIF 4. El sistema crea un nuevo registro de cliente en la base de datos 5. El sistema notifica al usuario el número de registro 105
  • 105. Descripción textual de casos de uso • El flujo de eventos establece los detalles de la comunicación entre el caso de uso y sus actores • Los flujos de eventos se describen separadamente usando Descripciones Textuales de Casos de Uso – Flujo de eventos principal (flujo feliz) – Flujos de eventos alternativos 106 Flujoprincipal
  • 106. Descripción textual de casos de uso • Plantilla para descripción de casos de uso 107 Caso de uso: <nombre del caso de uso> Actores participantes: <lista de actores que participan> Condiciones de entrada: <precondiciones> Flujo de eventos principal: <evento 1> (los eventos son del tipo: “El actor hace esto” o “El sistema hace aquello”) <evento 2> … <evento n> Flujos alternativos: <flujo alternativo asociado al flujo de eventos normal i> Condiciones de salida: <postcondiciones> Requisitos especiales: <requisitos no-funcionales asociados al caso de uso> Notas: <notas adicionales o aclaratorias>
  • 107. Descripción textual de casos de uso 108 Caso de uso: Realizar Reservación Actores participantes: Pasajero Condiciones de entrada: El pasajero es un usuario registrado Flujo de eventos principal: 1. El usuario selecciona la opción "Realizar reservación" 2. El sistema muestra un formulario con los criterios de búsqueda de vuelos 3. El usuario ingresa los criterios (modo, origen, destino, periodo y pasajeros) y pulsa la tecla "buscar vuelos" 4. El sistema busca todos los vuelos que cumplen con los criterios 5. El sistema muestra los vuelos (aerolínea, monto, tasa, impuestos) 6. El usuario selecciona el vuelo y pulsa la tecla "reservar" 7. El sistema muestra un formulario de ingreso de datos de los pasajeros 8. El usuario ingresa los datos de los pasajeros y pulsa la tecla "guardar" 9. El sistema agrega la reservación al vuelo de la aerolínea 10. El sistema emite un comprobante de la reservación Condiciones de salida: El pasajero obtiene la reservación mediante un comprobante de confirmación
  • 108. Descripción textual de casos de uso 109 Flujo de eventos alternativos:  3.1 El usuario ingresa los criterios de búsqueda incompletos 3.1.1 El sistema muestra un mensaje de advertencia  3.2 El usuario ingresa el modo: “múltiples destinos” 3.2.1 El sistema muestra un formulario para seleccionar múltiples destinos 3.2.2 El usuario selecciona los destinos y pulsa la tecla "continuar" 3.2.3 El sistema guarda los destinos y regresa al formulario de criterios del vuelo  4. El sistema no encuentra disponibilidad de vuelos 4.1 El sistema muestra un mensaje indicando que no existe disponibilidad de vuelos para los criterios seleccionados  6. El usuario no selecciona ningún vuelo 6.1 El usuario pulsa la tecla "Regresar" 6.2 El sistema regresa a la página anterior  8. El usuario ingresa los datos de los pasajeros incompletos 8.1 El sistema muestra un mensaje de datos de pasajeros incompletos Requisitos especiales: El sistema debe mostrar los resultados de vuelos en un tiempo no mayor a 10 segundos
  • 109. Descripción textual de casos de uso • Reglas para la descripción textual de casos de uso (1) – Narre el flujo de eventos usando voz activa, en tiempo presente y desde la perspectiva del actor • Evite el uso de voz pasiva: – “La clave es introducida por el usuario” • Prefiera el uso de la voz activa: – “El usuario introduce la clave” – “El sistema valida la clave” – Exprese cada paso del flujo usando la forma “llamada y respuesta”: • El texto debe reflejar el hecho de que el actor ejecuta algo y el sistema responde a la solicitud del actor – “El [actor] hace [esto]” y “El sistema hace [aquello]” 110
  • 110. Descripción textual de casos de uso • Reglas para la descripción textual de casos de uso (2) – El caso de uso que se describe debe expresar un solo requisito funcional • Pero, pueden haber uno o más requisitos no-funcionales asociados al requisito funcional descrito – Establezca el contexto inicial del actor • Especifique la ubicación del actor en el contexto de la interfaz de usuario del sistema – Ej. El Cliente introduce su clave de identificación en la ventana de identificación al inicio del sistema – Asegúrese que el caso de uso produzca un resultado visible y de valor para el cliente – Establezca todos los posibles flujos alternativos al flujo principal (flujo feliz) 111
  • 111. Tema 5: Modelado Estructural de Requisitos • Toda aplicación tiene una estructura asociada • La aplicaciones orientadas a objetos (OO) representan mediante objetos de software a los objetos del dominio de la aplicación (sistema de negocios) – Cada objeto relevante del sistema de negocios es representado en la aplicación por un objeto de software • Los objetivos instruccionales de este tema son: – Familiarizarse con el proceso de modelado estructural de requisitos – Adquirir habilidades en el modelado de la estructura de una aplicación usando Diagramas de Clases en UML 112
  • 112. Modelado Estructural de Requisitos • Una actividad importante del Análisis de Requisitos es la elaboración del Modelo Estructural de la aplicación • Un Modelo Estructural es una representación gráfica de la estructura que debe tener la aplicación – En aplicaciones OO, esta estructura se expresa en términos de clases de objetos y relaciones entre estas clases – Cada clase de objetos representa a un conjunto de objetos del dominio de la aplicación que tienen todos las mismas propiedadesMapa representa 113
  • 113. UML: Diagramas de Clases • Los Diagramas de Clases permiten representar diferentes aspectos de la estructura de un sistema o aplicación • En Ingeniería de Requisitos se usan para: – Facilitar la identificación y modelado de los requisitos estructurales de una aplicación, es decir • Las clases del negocio – Esto es, clases que representan a los objetos del negocio • Las relaciones entre estas clases 114
  • 114. UML: Diagramas de Clases • Los diagramas de clases se pueden elaborar mediante el análisis de los diagramas de casos de uso – Cada sustantivo del nombre de un caso de uso representa un tipo o clase de negocio 115 Comprar un mapa Mapa
  • 115. UML: Diagramas de Clases • Un Diagrama de Clase en UML consta de: – Una o más clases de objetos – Una o más relaciones entre clases 116 Operaciones (Métodos) Diagrama de Clases Agregación DependenciaComposiciónAsociaciónGeneralizaciónAtributos Relación Clases de Objeto ** * *
  • 116. UML: Diagramas de Clases • Una CLASE representa una colección de entidades u objetos que tienen un conjunto común de propiedades • Es un constructo que define la estructura (atributos) y el comportamiento (operaciones) de un conjunto de objetos denominados instancias 117 Avión +id +nombre +marca +modelo +capacidadMax +estado +... +cambiarEstado() +actualizarDatos() +obtenerDatos() +obtenerEstado() +...() Nombre de la clase Atributos (estructura) Métodos u Operaciones (comportamiento)
  • 117. UML: Diagramas de Clases • Una clase describe los atributos de sus instancias • Los atributos son las propiedades comunes que las instancias de una clase tienen • Formato de un atributo: • visibilidad / nombre: tipo [multiplicidad] = valor de defecto {propiedad} – La visibilidad puede ser pública (+), protegida(#), privada (-) o sólo para el paquete (~) – Las propiedades pueden ser: {readOnly}, {sequence}, {ordered} – / indica que el atributo es derivado o calculado a partir de otros • Ejemplos: – + capacidadMax: Integer = 45 – + estado: String = “activo” – - / edad: Integer {readOnly} 118
  • 118. UML: Diagramas de Clases • Una clase describe, también, las operaciones (métodos) que se le pueden aplicar a sus instancias • Formato de una operación: • visibilidad nombre (lista de parámetros): valor de retorno {propiedad} – La visibilidad puede ser pública (+), protegida(#), privada (-) o paquete (~) – Las propiedades pueden ser: {isQuery}, {sequential}, {concurrent},... – La lista de parámetros tiene el siguiente formato: » dirección nombre: tipo [multiplicidad] = valor de defecto » Dirección indica si el parámetro es de entrada (in), salida (out) o ambos (inout) • Ejemplos: – +obtenerEstado():String – +actualizarDatos( in marca: String, in modelo: String) – #cambiarCapacidad( in nueva: Integer) {sequential} 119
  • 119. UML: Diagramas de Clases • Entre las clases se establecen RELACIONES de varios tipos: – Generalización y herencia – Asociación – Agregación – Composición – Dependencia 120 A B A B+rol2+rol1 A B A B A B
  • 120. UML: Diagramas de Clases • Generalización y herencia • Establece una relación del tipo ”es_un” entre dos o más clases • Una o más clases específicas, denominadas subclases, heredan la estructura y comportamiento de una clase genérica • Las subclases tienen (heredan) los mismos atributos y operaciones que tiene su superclase 121 subclases superclase Persona Profesor Estudiante
  • 121. UML: Diagramas de Clases • Asociación – Establece una relación funcional y bidireccional entre dos o más clases – Cada instancia de una clase se asocia a cero, uno o más instancias de la otra clase asociada 122 CursoEstudiante inscribe +es_cursado+cursa 0..*0..* nombre de la asociación multiplicidad rol
  • 122. UML: Diagramas de Clases • Agregación – Establece una relación “todo-partes” en la cual una clase (el todo) está conformada por otra u otras clases (las partes) – La existencia de las instancias de las partes no depende de la existencia de las instancias de la clase agregada 123 Equipo de Trabajo Estudiante parte todo
  • 123. UML: Diagramas de Clases • Composición – Establece una relación “es_parte_de” entre dos clases – Es un tipo particular de agregación en la cual la existencia de las instancias de las partes depende de la existencia de la instancia compuesta 124 Curso Objetivo Contenido Actividad 1..* 1..* 0..* Clase compuesta Clases componentes
  • 124. UML: Diagramas de Clases • Dependencia – Establece una relación entre una clase dependiente y otra independiente – No establece un tipo específico de dependencia • Simplemente se indica que hay una dependencia entre dos clases 125 Curso Institución Clase independienteClase dependiente
  • 125. UML: Diagramas de Clases • Casos especiales 126 Clase de Asociación Clase Abstracta Paciente +id +nombre +... Médico +id +nombre +especialidad #consultorio +... Cita +fecha +hora 0..*0..* Equipo <<abstract>> +id +nombre +marca +modelo +serial +obtenerSerial() +...() PDA +memoria +tipoCPU PC +memoria +tipoCPU +capDD Teléfono +protocoloCOM
  • 126. UML: Diagramas de Clases • Casos especiales 127 Asociación Recursiva Actividad +id +nombre +descripción +duración +estructurada_por 0..* 1 Departamento Persona Proyecto Asociación Ternaria
  • 127. UML: Diagramas de Clases • Usos de los Diagramas de Clases – En la especificación de requisitos, se usan para representar: • Los objetos de negocio del dominio de aplicación y • Las relaciones entre estos objetos – Ejemplo 1: Modelo de Objetos de Negocio en un Sistema de Reservaciones Aéreas 128 Reservación Cliente Vuelo Aerolínea +reservado_por+reserva 0..*0..* +coordina+coordinado_por 11..* Avión asignación 1 1
  • 128. 129 Reservación +fecha +hora +localizador +estado Cliente +id +cédula +nombre +teléfono +e-mail +... Vuelo +id +número +origen +destino +cupoDisponible +estado +... Aerolínea +id +nombre +e-mail +estadoActual +... +reservado_por+reserva 0..*0..* +coordina+coordinado_por 11..* Avión +id +nombre +marca +modelo +capacidadMax +estado +... asignación 1 1 clase de negocio clase de asociación asociación atributo roles multipicidad Sistema de Reservaciones Aéreas
  • 129. UML: Diagramas de Clases • Ejemplo 2: Sistema de ordenes de compra – Identificación de objetos de negocios: • Cliente • Producto o ítem • Orden de compra – Encabezado – Líneas de pedido (ítems solicitados) • Pago – Pago en efectivo – Pago a crédito – Pago con cheque – Identificación de relaciones • Un Cliente coloca una o más Ordenes de Compra • Una Orden de Compra está compuesta por un Encabezado y una o más líneas de pedido • Una Orden de Compra es pagada en efectivo, cheque o a crédito 130
  • 130. UML: Diagramas de clases 131
  • 131. Resumen del Tema 5 • Qué es el Modelado Estructural de Requisitos • Porqué es importante modelar la estructura de la aplicación durante la IR • Cómo se elabora un Diagrama de Clases • Qué diferencias existen entre: – Clases y objetos – Atributos y métodos – Generalización y especialización – Composición y agregación – Clase de asociación y asociación recursiva 132
  • 132. Ejercicios Prácticos del Tema 5 • Objetivo de la actividad: – Elaborar el Modelo Estructural de los requisitos de su aplicación • Duración: – 15 minutos presenciales + 1-2 horas a distancia • Pasos a seguir: Usando el Modelo Funcional de Requisitos elaborado en durante el Tema 4: 1. Identifique las clases del negocio que debe manejar su aplicación 2. Identifique las relaciones entre estas clases 3. Identifique los principales atributos de cada clase 4. Elabore y valide el Modelo Estructural de su aplicación 133
  • 133. Tema 6 Modelado Dinámico Diagramas de Actividad y Estado
  • 134. Tema 6: Modelado Dinámico de Requisitos • Toda aplicación tiene una dinámica asociada – Esta dinámica está determinada por el comportamiento de la aplicación ante eventos – Los eventos hacen que la aplicación responda o reaccione – Estos eventos pueden ocurrir debido a: – La interacción del usuario con la aplicación – Una transición de estado en un objeto de la aplicación – Una falla de la aplicación • Los objetivos instruccionales de este tema son: – Familiarizarse con el modelado dinámico de una aplicación – Adquirir habilidades en el uso de diagramas de actividad y diagramas de estado del UML 135
  • 135. Modelado Dinámico de Requisitos • Para modelar la dinámica o el comportamiento de una aplicación existe un conjunto amplio de técnicas: – UML: • Diagramas de actividad • Diagramas de Interacción – Diagramas de secuencia – Diagramas de comunicación • Diagramas de estado – Otros: • Diagramas de flujo • Redes de Petri • Notación de Modelado de Procesos de Negocios BPMN 136
  • 136. Modelado Dinámico de Requisitos • Los diagramas de actividad del UML son útiles para : – modelar los flujos de trabajo en los que interviene la aplicación – Representar la interacción de la aplicación con los procesos del sistema de negocios • Los diagramas de estado del UML son útiles para modelar: – los eventos que ocasionan cambios en el estado de los objetos de una aplicación – las transiciones de estado que pueden tener los objetos de cierta clase en una aplicación • Los diagramas BPMN son una alternativa a los diagramas de actividad – Permiten modelar flujos de trabajo de una aplicación 137
  • 137. UML: Diagramas de Actividad • Los diagramas de actividad son usados para modelar flujos de trabajo (workflow) de una aplicación – Expresan que acciones se requieren y en que orden – Qué hacen estas acciones y/o que producen – Quien es responsable de ejecutarlas (partición de actividades) Recibo de la orden Cierre de la orden Factura Llenar orden Enviar orden Enviar factura Hacer pago Aceptar pago [orden aceptada] [orden rechazada] Orden de requerimiento 138
  • 138. Diseñar Estructura del Producto Diseñar Forma del Producto Especificar Componentes «información» Características del Producto «información» Estructura del Producto «información» Forma del Producto «información» Modelo del Producto UML: Diagramas de Actividad • Los diagramas de actividad capturan las acciones de un proceso del negocio y sus resultados – Enfatizan la secuencia de actividades (acciones) – Modelan dos tipos de flujos de un proceso del negocio: • el flujo de control y/o • el flujo de objetos Modelo de flujo de control Modelo de flujo de objetos Diseñar Estructura del Producto Diseñar Forma del Producto Especificar Componentes 139
  • 139. UML: Diagramas de Actividad • Concepto de “acción” o “tarea” en un diagrama de actividad – Una acción (o tarea) es la unidad fundamental de especificación de comportamiento – Una acción es atómica • No puede ser descompuesta en otras acciones – Una acción toma uno o más objetos de entrada (tokens) y las transforma en uno o más objetos de salida (tokens) tokens acción Diseñar Forma del Producto «información» Estructura del Producto «información» Forma del Producto 140
  • 140. UML: Diagramas de Actividad • Un diagrama de actividad es un grafo dirigido que está compuesto de: – Un conjunto de nodos de cuatro tipos: • Nodos de actividad que representan acciones – Transforman objetos que entran en objetos que salen • Nodos de control usados para controlar flujos • Nodos de objetos que representan objetos de datos • Nodos de señal que modelan eventos que activan la ejecución de acciones – Un conjunto de ejes • Cada eje conecta a dos nodos • A través de los ejes circulan objetos denominados tokens 141
  • 141. UML: Diagramas de Actividad • Formato de un diagrama de actividad Pre y postcondiciones Ejes de actividad Nodos de actividad Parámetro de la actividad Nombre de la actividad Nodos de parámetros … … … Nombre de la actividad o proceso <<precondición>> restricción Nombre del parámetro: Tipo <<poscondición>> restricción 142
  • 142. UML: Diagramas de Actividad • Ejemplo 1: “Procesar Ordenes de Compra” Orden de compra Nota de despacho Revisar orden de compra Rechazar orden Actualizar inventario Elaborar nota de despacho Verificar existencia de producto A A [Orden completa] [Orden incompleta] No Si Procesar Orden de Compra <<precondición>> Orden válida <<postcondición>> Orden atendida Nombre de la actividad o proceso Nodo Objeto parámetro de salida Pre y postcondiciones Nodo objeto parámetro de entrada Join Fork Nodo de mezcla Nodo de decisiónConector Nodo fin de actividad Acción Nodo inicio de actividad 143
  • 143. Nodos de parámetros Anotación de flujo continuo Anotaciones de excepción Materiales de producción Computadores Ensamblados Tableros de circuitos impresos Computadores aceptados Computadores rechazadosProducir tableros de circuitos impresos Ensamblar computadores Probar computadores {flujo} UML: Diagramas de Actividad • Ejemplo 2: Flujo de objetos de la actividad “Producir computadores” 144
  • 144. UML: Diagramas de Actividad • Nodos de señales – Permiten modelar eventos o señales que activan la ejecución de acciones nodos de señal de envío nodo de señal de aceptación (Ventas) Crear orden (almacén) Facturar orden Entregar orden Notificar al Cliente Cancelar orden Solicitud de cancelación de orden 145
  • 145. UML: Diagramas de Actividad • Los diagramas de actividad modelan flujos de trabajo mediante: • Secuencias de acciones (secuenciación) • Secuencias de acciones paralelas (paralelismo) • Secuencias de acciones alternativas (decisión) • Sincronización de acciones paralelas (concurrencia) Cancelar servicio Cancelar transacción Notificar inactividad Notificar rechazo Rechazar Aprobar servicio Someter a aprobación Aprobar automáticam Cronometrar inactividad [cantidad<200] [cantidad>=200] [decisión=rechazar] [decisión=aceptar] 146
  • 146. UML: Diagramas de Actividad • Partición de actividades y carriles (swimlanes) – Permiten agrupar las acciones de acuerdo a los actores o unidades organizacionales responsables de su ejecución – Útiles para establecer relaciones entre la aplicación y sus usuarios a) Partición usando la notación “swimlane” Nombrede partición Partición Nombre-4 Partición Nombre-1 Partición Nombre-2 c) Partición usando la notación “swimlane” jerárquica y multidimensional Nombre de dimensión Nombrededimensión Partición Nombre-3 b) Partición usando la notación “swimlane” jerárquica Nombrededimensión Nombredepartición Nombrede subpartición Nombrede subpartición 147
  • 147. UML: Diagramas de Actividad • Ejemplo 1: Partición de actividadesCliente <<externa>><<atributo>>dptoEjecutor:Departamento Dpto.deOrdenesDpto.deContabilidad Recibir orden Cerrar orden Factura Llenar orden Enviar orden Enviar factura Hacer pago Aceptar pago [orden aceptada] 148
  • 148. UML: Diagramas de Actividad • Ejemplo 2: Partición de actividades usando carriles multidimensionales Mérida Caracas <<clase>> Dpto.deContabilidad <<clase>> Dpto.deVentas Recibir orden Cerrar orden Factura Solicitar despacho Despachar orden Enviar factura Recibir pago Confirmar pago [orden aceptada] 149
  • 149. UML: Diagramas de Actividad • Ejemplo 3: Otra manera de particionar actividades es mediante la anotación – Cada acción tiene una anotación específica que indica el actor o unidad organizacional responsable de ejecutarla (Dpto.Orden) Recibir orden (Dpto. Orden) Cerrar orden Factura (Dpto. Orden) Llenar orden (Dpto. Orden) Enviar orden (Contabilidad) Enviar factura <<externa>> (Cliente) Hacer pago (Contabilidad) Enviar pago [orden aceptada] anotación 150
  • 150. UML: Diagramas de Actividad • Los Diagramas de Actividad modelan: – el flujo de trabajo de un proceso del negocio y – las relaciones entre los usuarios y la aplicación • Ejemplo 1: Sistema de Facturación en línea Recibir orden Cierre de orden Solicitar Despacho de orden Despachar orden Enviar factura Hacer pago Aceptar pago [orden aceptada] Cliente <<externo>> Depto.de Ventas Sist.deFacturación Factura <<unidadorganizacional>> GerenciadeVentas 151
  • 151. UML: Diagramas de Actividad • Ejemplo 2: Sistema de ordenes de compra Verificar datos cliente Verificar inventario Rechazar orden Procesar orden Empacar productos Ingresar orden Enviar pedido válido inválido cantidad > 0 cantidad <= 0 <<producto>> Pedido <<información>> Notificación Cliente Sistema Ordenes de Compra Sistema Inventario Almacén 152
  • 152. Diagramas de actividad • Ejemplo 3: Un cajero automátic o 153 [Borland, 2002]
  • 153. UML: Diagramas de Actividad • Ejemplo 4: Descomposición funcional en diagramas de actividad Descomposición de la actividad Usar parte Requerir ID parte Buscar parte Proveer parte requerida [else] [encontrada] [no encontrada] [proveída] Ingeniería de Diseño Ingeniería de Estándares Ejecutar flujo de trabajo [flujo] [flujo] Investigar posibilidades de producción [acepta] [rechaza] Proveer información adicional Mod. parte Búsqueda experta de la parte Asignar ingeniero Revisar requerimiento Especificar flujo de trabajo Mod. parte Planificar flujo de trabajo Mod. parte Clarificar requerimientos Revisar plan [cancelar] [replanificar] [OK] [flujo][flujo] [no encontrada] [encontrada] Proveer parte requerida Ingeniería de Diseño Ingeniería de Estándares 154
  • 154. UML: Diagramas de Estado • Las aplicaciones de software combinan tres procesos computacionales: – Comportamiento funcional (ejecución de funciones) – Manipulación de datos – Cambios de estado • Una aplicación en ejecución, generalmente, se encuentra en un determinado estado – P.ej., en espera, procesando, cerrada, etc. • Este estado es modificado cuando ocurre un cierto evento o condición predeterminada – La ocurrencia del evento o la presencia de la condición ocasiona una transición o cambio de estado en la aplicación 155
  • 155. UML: Diagramas de Estado • Los diagramas de estado son ideales para modelar las transiciones de estado que ocurren a nivel de: – Toda la aplicación, p.ej.: • Cambios de estado de una aplicación interactiva o una de tiempo real – Una aplicación interactiva pasa del estado inactivo al estado activo cuando el usuario selecciona cualquier opción de su interfaz – Objetos de la aplicación, p.ej.: • Cambios en el estado de un objeto de negocio en una aplicación empresarial – En la aplicación mimapa.com, los objetos de la clase Carro de Compras puede cambiar del estado “vacio” al estado “agregando” 156
  • 156. UML: Diagramas de Estado • Máquinas de Estado Finito – Tanto una aplicación como un objeto de ella pueden ser vistos como máquinas de estado – Una máquina de estado es un modelo que especifica las secuencias de estados que un objeto puede recorrer durante su existenciaEstado 1 Inicial Estado 2 Estado 3 Final evento A evento C[condición D] evento B 157
  • 157. UML: Diagramas de Estado • Máquinas de Estado Finito – Una máquina de estado tiene tres tipos de elementos: • Estados representados por rectángulos • Transiciones o cambios de estado representados por flechas entre estados • Eventos o condiciones que causan las transiciones entre estados Estado 1 Inicial Estado 2 Estado 3 Final evento A evento C[condición D] evento B 158
  • 158. UML: Diagramas de Estado • Estados – Un estado es una condición en la cual un objeto de una determinada clase puede estar en cierto momento de su existencia – El estado de un objeto es determinado por los valores de sus atributos y enlaces a otros objetos – Durante su estadía en un estado, el objeto puede ejecutar operaciones al momento de: • Entrada al estado (entry) • Permanencia en el estado (do) • Salida del estado (exit) <nombre del estado> entry/<operación> do/<operación> exit/<operación> 159
  • 159. UML: Diagramas de Estado • Transiciones (cambios de estado) – Una transición es un cambio de estado que ocurre en un objeto o sistema • El objeto (o sistema) pasa de un estado actual a otro estado • La transición se representa mediante un arco Estado actual Estado destino transición 160
  • 160. UML: Diagramas de Estado • Eventos – Una transición ocurre debido a un evento que la dispara • Un evento es algo que acontece en el sistema o en su entorno y que ocasiona una transición • Formato del evento: <nombreDelEvento> [<condición>] / <acción> Donde: <condición>: Expresión booleana. Debe ser verdadera para que ocurra la transición. Si la expresión es falsa, no hay transición <acción>: Operación que se ejecuta sobre el objeto en el momento en que ocurre la transición • Ejemplo: Cuenta suspendida Cuenta activada pago realizado [saldo < 0] pago realizado [saldo >=0] /eliminarSuspension 161
  • 161. UML: Diagramas de Estado • Ejemplo 1: Un Sistema de Seguridad Sistema activado + entry / encender sensores Sistema desactivado + entry / apagar alarma + entry / apagar sensores Alarma encendida + entry / encender alarma Inicial botón encendido clave correcta clave incorrecta [t > 30 seg] movimiento detectado clave correcta [t <= 30 seg] clave incorrecta clave correcta [t > 30 seg] 162
  • 162. UML: Diagramas de Estado • Ejemplo 2: Diagrama de Estado de los objetos de la clase Reservación del Sistema de Reservaciones 163
  • 163. Resumen del Tema 6 • Qué es el Modelado Dinámico de requisitos • Qué es el comportamiento de una aplicación • Qué aspectos dinámicos de una aplicación se modelan durante la IR • Cómo representar un flujo de trabajo usando diagramas de actividades • Cómo modelar los cambios de estado de un objeto del negocio 164
  • 164. Tema 6: Actividades Prácticas • Objetivo de la actividad: – Elaborar el Modelo Dinámico de los requisitos de su aplicación • Duración: – 30 minutos presenciales + 2-3 horas a distancia • Pasos a seguir: 1. Usando el modelo de negocios elaborado durante la Sesión 2.1: 1. Seleccione un proceso de negocio que sea apoyado por la aplicación que usted está especificando 2. Elabore un Diagrama de Actividad que muestre el flujo de trabajo que requiere el proceso y su relación con la aplicación 2. Usando el Modelo Estructural elaborado durante el Tema 5: 1. Seleccione una clase que tenga cambios de estado interesante 2. Elabore el diagrama de estado para la clase seleccionada 165
  • 165. Conclusiones • Un mal manejo de los requisitos de una aplicación puede ocasionar el fracaso del proyecto • La Ingeniería de Requisitos (IR) busca resolver los problemas asociados a los requisitos • La IR agrupa y organiza los procesos de: – Identificación, análisis, especificación, validación y gestión de requisitos • La IR está estrechamente relacionada con el Modelado de Negocios (MN) – El MN estudia el problema; mientras que la IR se encarga de especificar la solución, inmediatamente antes de diseñarla 166
  • 166. Referencias Bibliográficas • Le Vie, D. (2009). Writing Software Requirement Specifications. [on-line] http://www.techwr- l.com/techwhirl/magazine/writing/softwarerequirementspecs.html • Wiegers, K. E. (2003). Software Requirements. Microsoft Press. Redmond, Washington. • Scott, K. (2004). Fast Track UML 2.0. Spriger-Verlag, New York. • Eriksson, Penker, M, Lyons, B. and Fado, D. (2004). UML 2 Toolkit. Wiley Publishing. Indiana. • Montilva, J., Barrios, J. y Rivero, M. (2008). Gray Watch: Método de Desarrollo de Software para Aplicaciones Empresariales. Versión preliminar. Monografía disponible en www.methodius.org.ve 167
  • 167. Módulo 2 Fin de la Sesión 2.2 Derechos Reservados. Prohibida la reproducción total o parcial de este documento, por cualquier medio manual o electrónico, sin la autorización escrita de sus autores. © Jonás A. Montilva C. jmontilva@biosoftca.com http://e-praxis.biosoftca.com