Trabajo de Modelado

1. Modelado de Requerimientos:
Comportamiento, patrones y
web-Apps

2. ¿Cuántos diagramas son necesarios?
➔ Después de ver en el capítulo: 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 algunos sistemas, 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 de un Sistema.
➔ El objetivo es crear una representación que tenga claridad,
funcionalidad y simplicidad.
➔ 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. Diagramas 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 diagramar 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.

5. Diagramas de Flujo de Datos
➔ 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.

6. ¿Qué es el Diagrama de
Contexto?
➔ Es un caso especial del diagrama de flujo de datos, en
donde una sola burbuja representa todo el sistema.
➔ Muestra 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. (continuación)
Este diagrama debe de ser fácilmente comprensible:
No es posible representar todos los flujos de datos, sino más bien
debe representarse 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.

9. ¿Qué es un Diagrama de
Estado?
➔ Permite visualizar los cambios en un sistema.
➔ Es una especificación secuencial del comportamiento.

10. ¿Qué son: Herramientas para
Análisis?
➔ 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.

11. Herramientas UML.
1. Herramientas online: draw.io gliffy.com
2. Star UML: StarUML.io
3. Enterprise Architect UML modeling tools for Business
4. Rational Rose, desarrollada por IBM.
5. Microsoft Visio.

12. Modelo de Comportamiento
Indica cómo responderá el software a eventos externos.
Se recomienda:
1. Evaluar los casos de uso para entender el sistema.
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.

13. WebApps y móvil
Análisis de Requerimientos
➔ Es frecuente que los desarrolladores móviles expresen
dudas cuando se plantea la idea del análisis de
requerimientos.
➔ Acostumbran decir: “El desarrollo para dispositivos móviles
debe ser ágil y el análisis toma tiempo”.
➔ El análisis de los requerimientos lleva tiempo, pero resolver
el problema equivocado toma aún más tiempo.

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

15. Factores del Análisis de una
WebApp.
Depende de los factores siguientes:
1. Tamaño y complejidad de la aplicación.
2. Número de participantes en el proyecto.
3. Tamaño del equipo de desarrollo de la aplicación.
4. Grado en el que los miembros del equipo han trabajado juntos
antes.
5. Si el éxito de la organización depende directamente del éxito
de la aplicación web/móvil.

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

17. 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.
➔ Cada función del software que transforme datos es descrita
por la narrativa de un proceso.

18. Resumen y Conclusiones.
➔ El modelado para las webapps posee los mismos
elementos que una aplicación de escritorio, 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.