ingenieria requisitos
TRANSCRIPT
Tema 1
Requisitos de Software:
Conceptos, Tipos y Propiedades
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
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
¿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 documentadade una condición o capacidad que debe mostrar la aplicación en desarrollo
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
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
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 de l Negocio
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
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
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
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
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
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
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
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
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
Tipos de Requisitos NO-Funcionales
18
Atributos de Calidad del Software (según norma ISO 9126)
Atributos deCalidad del
Software (ISO9126)
FuncionalidadUtilidad
(Usability)
Confiabilidad
Eficiencia
Portabilidad
Mantenibilidad
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
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
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
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
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
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
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
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
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
Niv
el
de
l U
su
ari
oN
ive
l d
el
Pro
du
cto
Niv
el
de
l N
eg
oc
io
Requisitosdel Negocio
Requisitos deUsuarios
Requisitosdel Sistema
Requisitos deComportamiento
Reglas delNegocio
Atributos deCalidad
Requisitos deInterfaces
Restricciones
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
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
Tema 2
Los problemas de los requisitos y sus soluciones
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
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
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 delProyecto
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
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
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
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
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
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
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
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 delProblema
Espacio de laSolución
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 deRequisitos
Espacio de la Solución
Espacio del
ProblemaNecesi-dades
Aspectos(Features)
Requisitos de Software
Procedimientos de PruebasDiseño Doc. del
Usuario
LaSolución(software)
Adaptado de [Rational Requirements Management with Use Cases v5.5, 2000]
El Problema
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
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 lasmejoresprácticas
Prácticas
Gestionar eldesarrollo
como unproyecto
Proyecto
Usar unproceso dedesarrollo efectivo
ProcesoEmplearel mejor personal
Personas
Problema Entender primero el problemaantes de modelar la solución
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
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
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
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
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
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
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
Tema 3
La Ingeniería de Requisitos:
Productos, Procesos y Actores
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
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
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
La Ingeniería de Requisitos
• Los tres elementos fundamentales de la IR:
56
Agreedrequirements
Systemspecification
Systemmodels
Requirementsengineering process
Stakeholderneeds
Organisationalstandards
Domaininformation
Regulations
Existingsystems
information
El proceso:¿cómo
hacerlo?
Los productos:
¿qué se hace?
El grupo: ¿quienes lo hacen?
Los Productos de la Ingeniería de Requisitos
¿Qué productos se elaboran durante el proceso de
Ingeniería de Requisitos?
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
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
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
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
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
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..*
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
Los Productos de la Ingeniería de Requisitos
1. Introducción1. Propósito2. Convenciones utilizadas3. Audiencia y lecturas sugeridas4. Alcance del proyecto5. Referencias
2. Descripción general1. Perspectiva del producto2. Aspectos del producto3. Tipos de usuarios y sus características4. Ambiente operativo5. Restricciones de diseño e
implementación6. Documentación del usuario7. Supuestos y dependencias
3. Aspectos de la aplicación1. Aspecto A
1. Descripción y prioridad2. Estímulo/respuesta3. 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
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
Esp
acio
de
l Pro
ble
ma
Espacio
de
la Solu
ción
Los Procesos de la Ingeniería de Requisitos
¿Qué procesos requiere la Ingeniería
de Requisitos?
67
El proceso de la Ingeniería de Requisitos
68
Ingeniería deRequisitos (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»
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 deRequisitos
Descubrimientode Requisitos
Análisis deRequisitos
Especificación deRequisitos
Validación deRequisitos
Gestión deRequisitos
Desarrollo deRequisitos
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
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
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
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
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
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
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
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
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
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
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
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
Los Actores de la Ingeniería de Requisitos
83
¿Quienes participan en el proceso IR?
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
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
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
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
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
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
Retirar efectivo
Validar tarjeta
Transferir entrecuentas
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 tarjetaActor: UsuarioFlujo de eventos:1.- El usuario introduce la tarjeta2.- El sistema valida la tarjeta3.- El sistema presenta el menú
de opciones
Descripción Textual
Diagrama de Casos de Uso
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
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
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
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
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
ActorCaso de Uso
ActorCaso de Uso
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»
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
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»
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ónRegistrar el
vuelo«incluye»
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
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
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
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
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»
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
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
Flu
jo p
rincip
al
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>
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
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
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
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
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
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 propiedades Mapa
representa
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
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
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ónClases de Objeto
**
**
UML: Diagramas de Clases
• Una CLASE representauna colección de entidades u objetos quetienen un conjuntocomún de propiedades
• Es un constructo quedefine la estructura(atributos) y el comportamiento(operaciones) de un conjunto de objetosdenominados instancias
117
Avión
+id
+nombre
+marca
+modelo
+capacidadMax
+estado
+...
+cambiarEstado()
+actualizarDatos()
+obtenerDatos()
+obtenerEstado()
+...()
Nombre dela clase
Atributos(estructura)
Métodos u Operaciones(comportamiento)
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
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
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
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
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
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
Estudianteparte
todo
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
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
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
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
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
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
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
UML: Diagramas de clases
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
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ón2. Identifique las relaciones entre estas clases3. Identifique los principales atributos de cada clase4. Elabore y valide el Modelo Estructural de su aplicación
133
Tema 6
Modelado Dinámico
Diagramas de Actividad y Estado
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
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
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
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 ordenCierre
de la orden
Factura
Llenarorden
Enviarorden
Enviarfactura
Hacerpago
Aceptarpago
[ordenaceptada]
[ordenrechazada]
Orden derequerimiento
138
DiseñarEstructura del
Producto
DiseñarForma delProducto
EspecificarComponentes
«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ñarEstructura del
Producto
DiseñarForma delProducto
EspecificarComponentes
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ñarForma delProducto
«información»Estructura
del Producto
«información»Forma
del Producto
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
UML: Diagramas de Actividad
• Formato de un diagrama de actividad
Pre y postcondiciones
Ejes de actividadNodos de actividad
Parámetro de la actividad
Nombre de la actividad
Nodos de parámetros
…
…
…
Nombre de la actividad o proceso <<precondición>> restricciónNombre del parámetro: Tipo <<poscondición>> restricción
142
UML: Diagramas de Actividad
• Ejemplo 1: “Procesar Ordenes de Compra”
Orden decompra
Nota dedespacho
Revisar ordende compra
Rechazar orden
Actualizar inventario
Elaborarnota de despacho
Verificar existenciade producto
A
A
[Ordencompleta]
[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ámetrode salida
Pre y postcondiciones
Nodo objeto parámetrode entrada
Join
Fork
Nodo de mezcla
Nodo de decisiónConector
Nodo fin de
actividad
Acción
Nodoinicio deactividad
143
Nodos de parámetros
Anotación deflujo continuo
Anotaciones deexcepción
Materiales de producción
Computadores Ensamblados
Tableros de circuitos impresos
Computadoresaceptados
ComputadoresrechazadosProducir tableros
de circuitosimpresos
Ensamblarcomputadores
Probar computadores
{flujo}
UML: Diagramas de Actividad
• Ejemplo 2: Flujo de objetos de la actividad “Producir computadores”
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
Entregarorden
Notificar alCliente
Cancelarorden
Solicitudde cancelación
de orden
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)
Cancelarservicio
Cancelartransacción
Notificarinactividad
Notificarrechazo
Rechazar
Aprobarservicio
Sometera aprobación
Aprobarautomáticam
Cronometrarinactividad
[cantidad<200]
[cantidad>=200]
[decisión=rechazar]
[decisión=aceptar]
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”
No
mb
re d
ep
arti
ció
n
ParticiónNombre-4
Par
tici
ón
No
mb
re-1
Par
tici
ón
No
mb
re-2
c) Partición usando la notación“swimlane” jerárquica y multidimensional
Nombre de dimensión
No
mb
re d
e d
imen
sió
n
ParticiónNombre-3
b) Partición usando la notación “swimlane” jerárquica
No
mb
re d
e d
imen
sió
n
No
mb
re d
e p
arti
ció
n
No
mb
re d
esu
bp
arti
ció
n
No
mb
re d
esu
bp
arti
ció
n
147
UML: Diagramas de Actividad
• Ejemplo 1: Partición de actividadesC
lien
te
<<ex
tern
a>>
<<at
rib
uto
>> d
pto
Ejec
uto
r : D
epar
tam
ento
Dp
to. d
e O
rden
esD
pto
. d
e C
on
tab
ilid
ad
Recibirorden
Cerrarorden
Factura
Llenarorden
Enviarorden
Enviarfactura
Hacerpago
Aceptarpago
[ordenaceptada]
148
UML: Diagramas de Actividad
• Ejemplo 2: Partición de actividades usando carriles multidimensionales
Mérida Caracas
<<cl
ase>
>D
pto
. de
Co
nta
bili
dad
<<
clas
e>>
Dp
to. d
e V
enta
s
Recibirorden
Cerrarorden
Factura
Solicitar despacho
Despacharorden
Enviarfactura
Recibirpago
Confirmarpago
[ordenaceptada]
149
UML: Diagramas de Actividad
• Ejemplo 3: Otra manera de particionaractividades 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)
Recibirorden
(Dpto. Orden)
Cerrarorden
Factura
(Dpto. Orden)
Llenar orden
(Dpto. Orden)
Enviar orden
(Contabilidad)
Enviar factura
<<externa>>
(Cliente)Hacer pago
(Contabilidad)
Enviar pago
[ordenaceptada]
anotación
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íneaRecibirorden
Cierrede orden
Solicitar Despachode orden
Despacharorden
Enviarfactura
Hacerpago
Aceptarpago
[ordenaceptada]
Clie
nte
<<e
xte
rno
>>
Dep
to. d
e V
en
tas
Sist
. de
Fact
ura
ció
n
Factura
<<u
nid
ad o
rgan
izac
ion
al>>
Ge
ren
cia
de
Ve
nta
s
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 > 0cantidad <= 0
<<producto>>
Pedido
<<información>>
Notificación
Cliente Sistema Ordenes de Compra Sistema Inventario Almacén
152
Diagramas de actividad
• Ejemplo 3: Un cajero automático
153
[Borland, 2002]
UML: Diagramas de Actividad
• Ejemplo 4: Descomposición funcional en diagramas de actividad
Descomposiciónde la actividad
Usarparte
RequerirID parte
Buscarparte
Proveerparte requerida
[else]
[encontrada]
[no encontrada]
[proveída]
Ingenieríade Diseño
Ingenieríade Estándares
Ejecutarflujo detrabajo
[flujo][flujo]
Investigarposibilidades
de producción
[acepta]
[rechaza]
Proveerinformación
adicionalMod. parte
Búsquedaexperta
de la parte
Asignaringeniero
Revisarrequerimiento
Especificarflujo detrabajo
Mod. parte
Planificarflujo detrabajo
Mod. parte
Clarificarrequerimientos
Revisarplan
[cancelar]
[replanificar][OK]
[flujo][flujo]
[no encontrada]
[encontrada]
Proveer parte requerida Ingenieríade Diseño
Ingenieríade Estándares
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
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
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
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
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
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
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
suspendidaCuenta activada
pago realizado [saldo < 0]
pago realizado [saldo >=0]/eliminarSuspension
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ónencendido
clave correcta
clave incorrecta[t > 30 seg]
movimiento detectado
clave correcta[t <= 30 seg]
clave incorrecta
clave correcta[t > 30 seg]
162
UML: Diagramas de Estado
• Ejemplo 2: Diagrama de Estado de los objetos de la clase Reservación del Sistema de Reservaciones
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
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
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
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. WileyPublishing. 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
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 [email protected]
http://e-praxis.biosoftca.com