El documento proporciona directrices para el diseño de software de alta calidad. Indica que un buen diseño debe implementar todos los requisitos del análisis, ser comprensible, y proporcionar una visión completa del software. Además, debe presentar una arquitectura modular creada con patrones de diseño reconocidos y que facilite la implementación evolutiva. Finalmente, el diseño debe derivarse de forma controlada y repetitiva de los requisitos del análisis.

1. Diseño del Software Diseño de datos Diseño arquitectónico Diseño de interfaz

2. Guía para evaluar un buen diseño El diseño deberá implementar todos los requisitos explícitos del modelo de análisis, y deberán ajustarse a todos los requisitos implícitos que desea el cliente; El diseño deberá ser una guía legible y comprensible para aquellos que generan código y para aquellos que comprueban y consecuentemente, dan soporte al software; El diseño deberá proporcionar una imagen completa del software, enfrentándose a los dominios de comportamiento, funcionales y de datos desde una perspectiva de implementación.

3. Directrices sobre Calidad del Diseño Un diseño deberá presentar una estructura arquitectónica que (1) se haya creado mediante patrones de diseño reconocibles, (2) que esté formada por componentes que exhiban características de buen diseño y (3) que se puedan implementar de manera evolutiva, facilitando así la implementación y la comprobación. Un diseño deberá ser modular; ésto es, el software deberá dividirse lógicamente en elementos que realicen funciones y subfunciones específicas.

4. Directrices sobre Calidad del Diseño Un diseño deberá contener distintas representaciones de datos, arquitectura, interfaces y componentes (módulos). Un diseño deberá conducir a estructuras de datos adecuadas para los objetos que se van a implementar y que procedan de patrones de datos reconocibles. Un diseño deberá conducir a componentes que presenten características funcionales independientes.

5. Directrices sobre Calidad del Diseño Un diseño deberá conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y con el entorno externo. Un diseño deberá derivarse, mediante un método repetitivo y controlado, de la información obtenida durante el análisis de los requisitos del software.

6. Principios de Diseño del Software En el proceso de diseño no deberá utilizarse «orejeras». El diseño deberá poderse rastrear hasta el modelo de análisis. El diseño no deberá inventar nada que ya esté inventado. El diseño deberá «minimizar la distancia intelectual» entre el software y el problema como si de la misma vida real se tratara.

7. Principios de Diseño del Software El diseño deberá presentar uniformidad e integración. El diseño deberá estructurarse para admitir cambios. El diseño deberá estructurarse para degradarse poco a poco, incluso cuando se enfrenta con datos, sucesos o condiciones de operación aberrantes. El diseño no es escribir código y escribir código no es diseñar.

8. Principios de Diseño del Software El diseño deberá evaluarse en función de la calidad mientras se va creando, no después de terminarlo. El diseño deberá revisarse para minimizar los errores conceptuales (semánticos).

9. Heurísticas de Diseño para una modularidad efectiva Evaluar la “primera iteración” de la estructura de programa para reducir al acoplamiento y mejorar la cohesión. Intentar minimizar las estructuras con un alto grado de salida; esforzarse por la entrada a medida que aumenta la profundidad. Mantener el ámbito del efecto de un módulo dentro del ámbito de control de ese módulo.

10. Heurísticas de Diseño para una modularidad efectiva Evaluar las interfaces de los módulos para reducir la complejidad y la redundancia, y mejorar la consistencia. Definir módulos cuya función se pueda predecir, pero evitar módulos que sean demasiado restrictivos. Intentar conseguir módulos de «entrada controlada», evitando «conexiones patológicas».

11. Diseño de datos a nivel de Componentes Los principios del análisis sistemático aplicados a la función y al comportamiento deberían aplicarse también a los datos. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas. Se debería establecer un diccionario de datos y usarlo para definir el diseño de los datos y del programa. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño.

12. Análisis de las Transformaciones Pasos del diseño Revisar el modelo fundamental del sistema. ( DFD Nivel 0 y Nivel 1 del flujo de datos del software Hogar Seguro) . Revisar y refinar los diagramas de flujo de datos del software. ( DFD Nivel 2 ). Determinar si el DFD tiene características de flujo de transformación o de transacción.

13. DFD Nivel 1 del flujo de datos del software Hogar Seguro

14. DFD Nivel 0 del flujo de datos del software Hogar Seguro

15. DFD Nivel 2 que refina el proceso de Monitorizar Sensores

16. DFD Nivel 3 de Monitorizar Sensores con los límites de flujo

17. Análisis de las Transformaciones Aislar el centro de transformación especificando los límites de los flujos de entrada y salida. ( DFD Nivel 3 ). Realizar una «descomposición de primer nivel». ( Primer Nivel ). Realizar una «descomposición de segundo nivel». ( Segundo Nivel ). Refinar la estructura inicial de la arquitectura usando heurísticas para mejorar la calidad del software. ( Estructura Refinada ).

18. Descomposición de primer nivel para la monitorización de sensores

19. Descomposición de factores de segundo nivel de monitorización de sensores

20. Estructura refinada del programa para monitorizar sensores

21. Análisis de las transacciones Pasos del diseño Revisar el modelo fundamental del sistema. Revisar y refinar los diagramas de flujo de datos para el software. Determinar si el DFD tiene características de flujo de transformación o de transacción. ( DFD Nivel 2 ). Identificar el centro de transacción y las características de flujo a lo largo de cada camino de acción.

22. Nivel 2 de DFD para el subsistema de interación del usuario con límites de flujo

23. Análisis de las transacciones Transformar el DFD en una estructura de programa adecuada al procesamiento de la transacción. ( Análisis de transacción , Primer Nivel ). Descomponer y refinar la estructura de transacción y la estructura de todos los caminos de acción. ( Estructura del programa ). Refinar la primera arquitectura del programa usando heurísticas de diseño para mejorar la calidad del software.

24. Análisis de transacción

25. Descomposición en factores de primer nivel del subsistema interacción del usuario

26. Primera iteración de la estructura del programa del subsistema interacción del usuario