Ingeniería del Software

1. Modelado de Requerimientos:
Flujo, Comportamiento
y WebApps.
Ramiro Estigarribia Canese

2. Representaciones Gráficas
de un Sistema.
➔ Después de estudiar en el capítulo 6: casos de uso,
modelado de datos y modelos basados en clase, es
razonable preguntar:
¿No son suficientes representaciones gráficas?
La respuesta razonable es: “depende del sistema”.
➔ Para ciertos tipos de software, el caso de uso
puede ser la única representación necesaria.
➔ En cambio en otras situaciones, la complejidad
demanda mayor investigación.

3. Objetivo del Diseño.
➔ El objetivo es crear una representación que tenga
claridad, funcionalidad y belleza.
➔ Belady afirma que “la diversificación es la
adquisición de recursos del diseño: componentes,
soluciones y conocimiento”.
➔ Deben escogerse aquellos elementos que
representen mejor al sistema.
➔ A medida que esto ocurre, se evalúan las
alternativas, algunas se rechazan, y se converge
hacia la creación del producto final”.

4. Modelado orientado
al Flujo.
➔ Aunque algunos ingenieros perciben el modelado
orientado al flujo como una técnica obsoleta.
➔ No obstante sigue siendo una de las notaciones
más utilizadas para hacer el análisis de los
requerimientos.
➔ Para ciertos tipos de aplicaciones, el modelo de
datos y el diagrama de flujo de datos es todo lo que
se necesita para obtener una visión significativa de
los requerimientos del software.

5. Diagrama de flujo de datos.
➔ Es una representación gráfica del flujo de datos a
través de un sistema de información.
➔ Es una práctica común para un diseñador dibujar
un contexto a nivel de DFD que primero muestra la
interacción entre el sistema y las entidades
externas.
Niveles:
Nivel 0: Diagrama de contexto.
Nivel 1: Diagrama de nivel superior.
Nivel 2: Diagrama de detalle o expansión.

6. Diagrama de Contexto.
➔ Es un caso especial del diagrama de flujo de datos,
en donde una sola burbuja representa todo el
sistema.
➔ Muestra a través de flujos de datos las interacciones
entre los agentes externos y el sistema, sin describir
en ningún momento la estructura del sistema.
➔ En este tipo de diagrama, el sistema de información
debe representarse como un único proceso de muy
alto nivel con entradas y salidas hacia los agentes
externos que lo limitan, de forma equivalente a una
caja negra.

7. Diagrama de Contexto.
Este diagrama debe de ser fácilmente comprensible:
No es posible representar todos los flujos de datos del
sistema en él, sino más bien debe representarse en él
una visión general del sistema.
➔ Las personas, organizaciones y sistemas con los
que se comunica el sistema. Son conocidos como
terminadores.
➔ Los datos que el sistema recibe del mundo exterior
y que deben procesarse de alguna forma.
➔ Los datos producidos por el sistema y que se
enviarán al exterior.

8. Diagrama de Contexto.

9. Diagrama de Contexto.

10. Especificación de Control.
➔ Contiene un diagrama de estado que es una
especificación secuencial del comportamiento.
➔ También puede contener una tabla de activación
del programa, especificación combinatoria del
comportamiento.

11. Diagrama de Estado.

12. Especificación del Proceso.
➔ Se utiliza para describir todos los procesos del
modelo del flujo que aparecen en el nivel final de la
mejora.
➔ El contenido de la especificación del proceso
incluye el texto narrativo, una descripción del
lenguaje de diseño del algoritmo del proceso,
ecuaciones matemáticas, tablas o diagramas de
actividad UML, etc.

13. Análisis estructurado.
➔ Las herramientas de análisis estructurado permiten
que un ingeniero de software cree modelos de
datos, de flujo y de comportamiento en una forma
que permite la consistencia y continuidad con
facilidad para hacer la revisión, edición y
ampliación.
➔ Los modelos creados con estas herramientas dan
al ingeniero la perspectiva de la representación del
análisis y lo ayudan a eliminar errores antes de que
éstos se propaguen al diseño o, lo que sería peor,
a la implementación.

14. Modelo de Comportamiento
Indica la forma en la que responderá el software a
eventos o estímulos externos.
Deben seguirse los pasos siguientes:
1. Evaluar todos los casos de uso para entender la
secuencia de interacción.
2. Identificar los eventos que conducen la secuencia
de interacción con objetos específicos.
3. Crear una secuencia para cada caso de uso.
4. Construir un diagrama de estado para el sistema.
5. Revisar el modelo de comportamiento para verificar
la exactitud y consistencia

15. WebApps - Análisis
de Requerimientos
➔ Es frecuente que los desarrolladores web expresen
dudas cuando se plantea la idea del análisis de
requerimientos.
➔ Acostumbran decir: “El proceso de desarrollo en
web debe ser ágil y el análisis toma tiempo.
Nos hará ser lentos justo cuando necesitemos
diseñar y construir la webapp”.
➔ El análisis de los requerimientos lleva tiempo, pero
resolver el problema equivocado toma aún más
tiempo.

16. Requerimientos para
WebApps.
La pregunta que debe responder todo desarrollador en
web es:
¿Estás seguro de que entiendes los requerimientos
del problema?
➔ Si la respuesta es un “sí” inequívoco, entonces tal
vez sea posible omitir el modelado de los
requerimientos.
➔ Pero si la respuesta es “no”, entonces ésta debe
llevarse a cabo.

17. ¿Cuánto Análisis es
Suficiente en una WebApp?
Depende de los factores siguientes:
1. Tamaño y complejidad del incremento de la
webapp.
2. Número de participantes.
3. Tamaño del equipo de la webapp.
4. Grado en el que los miembros del equipo han
trabajado juntos antes.
5. El éxito de la organización depende directamente
del éxito de la webapp.

18. Modelos para WebApps
1. Modelo de contenido: identifica el espectro
completo de contenido que dará la webapp.
El contenido incluye texto, imágenes, video, etc.
2. Modelo de interacción: describe la manera en que
los usuarios interactúan con la webapp.
3. Modelo funcional: define las operaciones que se
aplicarán al contenido de la webapp.
4. Modelo de navegación: define la estrategia general
de navegación para la webapp.
5. Modelo de configuración: describe el ambiente e
infraestructura en la que reside la webapp.

19. Resumen y Conclusiones.
➔ Los modelos orientados al flujo se centran en el
flujo de objetos de datos a medida que son
transformados por las funciones de procesamiento.
➔ Derivados del análisis estructurado, los modelos
orientados al flujo usan el diagrama de flujo de
datos, notación de modelación que ilustra la
manera en la que se transforma la entrada en
salida cuando los objetos de datos se mueven a
través del sistema.
➔ Cada función del software que transforme datos es
descrita por la narrativa de un proceso.

20. Resumen y Conclusiones.
➔ Los patrones de análisis permiten utilizar el
conocimiento del dominio existente para facilitar la
creación de un modelo de requerimientos.
➔ El modelado de los requerimientos para las
webapps los mismos elementos de modelado.
Sin embargo, dichos elementos se aplican dentro
de un conjunto de modelos especializados que se
abocan al contenido, interacción, función,
navegación y configuración cliente-servidor en la
que reside la webapp.