CAPITULO 13 CONCEPTOS Y PRINCIPIOS DEL DISEÑO El diseño es el proceso de aplicar distintas técnicas y principíos con el propósito de definir un dispositivo, un proceso o un sistema con suficientes detalle como para permitir su realización física. El objetivo del diseñador es producir un modelo o representación de una entidad que se va a construir posteriormente. El diseño del soft cambia continuamente a medida que evolucionan nuevos métodos, mejores análisis y perspectivas más amplias. 13.1 DISEÑO E INGENIERIA DEL SOFTWARE
El diseño del software es la primera de las tres actividades técnicas – diseño, codificación y prueba – necesarias para construir y verificar el software. Cada actividad transforma la información de manera que se obtenga finalmente un software válido. Cada uno de los elementos del modelo de análisis proporciona información necesaria para crear un modelo de diseño. Los requisitos del soft, manifestados por los datos y los modelos funcional y de comportamiento, componen la fase de diseño. Mediante el empleo de uno de los métodos de diseño, la fase de diseño produce un diseño de datos, un diseño arquitectónico, un diseño de interfaz y un diseño procedimental. - Diseño de datos: Transforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarias para implementar el software. Los objetos de datos y las relaciones definidas en el diagrama entidad – relación (DER) y el contenido detallado de datos del diccionario de datos proporciona la base para la actividad de diseño de datos. - Diseño arquitectónico: Define la relación entre los principales elementos estructurales del programa. Esta representación del diseño se puede obtener del modelo de análisis y de la interacción de subsistemas, definidos dentro del modelo de análisis. Diagrama de flujo de datos. - Diseño de interfaz: describe cómo se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean. Una interfaz implica un flujo de información, entonces los diagramas de flujo de datos y control con trol proporcionan información necesaria para el diseño de la interfaz. transform ormaa elemen elementos tos estruc estructur turale aless de la arquit arquitect ectura ura del progra programa ma en una - Diseño procedimental: transf descripción procedimental de los componentes de software. La información se obtiene de EP, EC y DTE sirve de base para el diseño procedimental. El diseño es el lugar donde se fomenta la calidad en el desarrollo del software. Sirve como fundamento para todas las fases posteriores de ingeniería y mantenimiento del software. 13.2 EL PROCESO DE DISEÑO
A lo largo de este este proceso de diseño, diseño, se evalúa evalúa la calidad calidad del diseño con una serie serie de revisiones técnicas formales. Tres características que sirven de directrices para la evaluación de un buen diseño: Debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acomodar todos los requisitos implícitos que desea el cliente. Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el software. Debería proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y de comportamiento desde la perspectiva de la implementación. Criterios técnicos para un buen diseño. Consejos: Con sejos: un diseño debería: 1
-
Presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software. Ser modular (partición lógica del soft en elementos que realicen funciones y subfunciones específicas). Contener abstracciones de datos y procedimentales. Producir módulos que presenten características funcionales independientes. Conducir a interfaces que produzcan la complejidad de las conexiones entre los módulos y el entorno exterior. Producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos del soft.
Todos los métodos para el diseño tiene unas características comunes: 1) Un mecanismo para la transformación de un modelo de análisis en una representación del diseño. 2) Una notación para representar componentes funcionales y sus interfaces. 3) Heurísticas para el refinamiento y la partición. 4) Consejos para valorar la calidad. 13.3 PRINCIPIOS DEL DISEÑO Principios básicos del diseño: -
-
-
El proceso del diseño no debería ponerse orejeras: considerar enfoques alternativos – recursos disponibles
– conceptos de diseño -. Se debería poder seguir los pasos del diseño hasta el modelo de análisis. El diseño no debe inventar nada que ya esté inventado: componentes de diseño reutilizables-. El diseño debería minimizar la distancia intelectual. El diseño debería presentar uniformidad e integración. El diseño debería estructurarse para admitir cambios. El diseño debería estructurarse para degradarse poco a poco, incluso cuando se enfrenta a datos, sucesos o condiciones operativas aberrantes El diseño no es escribir código y escribir código no es diseñar. Se debería valorar la calidad del diseño mientras se crea, no después de terminarlo. Se debería revisar el diseño para minimizar los errores conceptuales.
Cuando se aplican los principios de diseño señalados, se crea un diseño que muestra factores de calidad externos e internos. Externos: son aquellas propiedades del soft que pueden observar los usuarios (velocidad- fiabilidad – utilidad). Internos: son importantes para los ing del soft. Perspectiva técnica. 13.4 CONCEPTOS DEL DISEÑO Cada fase del proceso de ingeniería del software es un refinamiento en el nivel de abstracción de la solución software. A medida que nos movemos a través de diferentes niveles de abstracción, trabajamos para crear: - abstracción procedimental: es una secuencia dad de instrucciones que tienen una función específica y limitada. - Abstracción de datos: es una colección determinada de datos que describen un objeto de datos. - Abstracción de control: implica un mecanismo de control del programa sin especificar los detalles internos. Abstracción: permite al diseñador especificar procedimientos y datos y suprimir detalles de bajo nivel. Refinamiento: ayuda al diseñador a revelar detalles de bajo nivel a medida que progresa el diseño. 2
Modularidad: se divide al software en componentes identificables y tratables por separado denominados módulos, que están integrados para satisfacer los requisitos del programa. Cinco criterios para evaluar un método de diseño con respecto a su capacidad de definir un sistema modular eficaz: - capacidad de descomposición modular. - Capacidad de empleo de componentes modulares. - Capacidad de comprensión modular - Protección modular Un sistema puede desarrollarse modularmente aunque su implementación sea monolítica. Arquitectura del software: el diseño del software debe crear una versión arquitectónica de un sistema. Propiedades que deberían especificarse como parte de un diseño arquitectónico: - Propiedades estructurales: define los componentes de un sistema, la manera que se empaquetan estos componentes y como interactúan con los otros. - Propiedades extra-funcionales: el diseño arquitectónico debería ocuparse como consigue la arquitectura del diseño los requisitos de rendimiento, capacidad, fiabilidad, seguridad, etc. - Familias de sistemas relacionados: debería tener la capacidad de utilizar bloques de construcción arquitectónica reutilizados.
El modelo arquitectónico puede representarse usando uno o más modelos diferentes: - Modelos estructurales: colección organizada de componentes de programa. - Modelos dinámicos: aspectos del comportamiento de la arquitectura del programa. - Modelos de proceso: diseño del negocio o del proceso técnico que debe tener el sistema. - Modelos funcionales: pueden usarse para representar la jerarquía funcional de un sistema. Jerarquía de control: también denominada estructura de programa, representa la organización (a menudo jerárquica) de componentes del programa (módulos) e implica una jerarquía de control. No representa aspectos procedimentales del soft como consecuencia de procesos, ocurrencia / orden de decisiones o repetición de operaciones. Notación: diagrama de árbol.(superior/subordinado) Partición estructural: la estructura del programa debería partirse tanto horizontalmente como verticalmente. Partición horizontal: define ramas separadas de la jerarquía modular para cada función principal del programa. Los módulos de control se usan para coordinar la comunicación entre ellos y la ejecución de las funciones del programa. El enfoque más simple define 3 particiones: Entrada / transformación de datos y salida. Beneficios de esta partición: - Proporciona software más fácil de probar. - Lleva aun soft más fácil de mantener - Propaga menos efectos secundarios - Proporciona soft más fácil de ampliar •
Desventajas:
- causa a menudo el paso de más datos a través de interfaces de módulos y puede complicar el control global del flujo del programa Partición vertical: (factoring – descomposición en factores): sugiere que el control (toma de decisiones) y el trabajo se distribuyan descendentemente en la arquitectura del programa. Los módulos del nivel superior deberían realizar funciones de control y poco trabajo de procesamiento. Los módulos que residen en la parte baja deberían ser los trabajadores, realizando todas las tareas de entrada, cálculo y salida. Estas arquitecturas verticales tienen menos probabilidad de ser susceptibles a efectos secundarios cuando se hacen cambio y tendrán por lo tanto mejor capacidad de mantenimiento, un factor clave para la calidad. •
3
Estructura de datos: es una representación de la relación lógica entre los elementos individuales de datos. Dicta las alternativas de organización, métodos de acceso, capacidad de asociación y procesamiento de la información. Estructuras clásicas que forman la base para construir estructuras más sofisticadas: - elemento escalar – forma más simple de estructura de dato - vector secuencial (matriz) – elemento escalar como una lista contigua - lista enlazada – punteros - estructura de datos jerárquica (pila) – contiene: listas enlazadas con escalares, vectores y matrices – Procedimiento del software: se concentra en los detalles de procesamiento de cada módulo individualmente. El procedimiento debe proporcionar una especificación exacta del procesamiento, incluyendo secuencia de acontecimientos, puntos exactos de decisión, operaciones repetitivas e incluso la organización/estructura de los datos. Ocultamiento de la información: implica que se puede conseguir una modularidad eficaz definiendo un conj de módulos independientes que se comunican entre ellos sólo la información necesaria para conseguir la función del software. 13.5. DISEÑO MODULAR EFECTIVO Reduce la complejidad y facilita los cambios, hace más fácil la implementación. Independencia funcional: se consigue desarrollando módulos con una función única. Los módulos independientes son fáciles de mantener y probar por que los efectos causados por las modificaciones son limitados, la propagación de errores es reducida y se pueden utilizar módulos reutilizados. Se mide usando dos criterios cuantitativos: cohesión y acoplamiento. Cohesión: es una medida de fuerza relativa funcional de un módulo. Es una extensión del concepto de ocultación de información. Un módulo con cohesión realiza una sola tarea dentro de un procedimiento de soft, requiriendo poca interacción con los procedimientos que realizan en otras partes del programa. Idealmente, un módulo con cohesión debería realizar una sola tarea. - Coincidentalmente cohesivo: módulo que realiza un conj de tareas poco relacionadas pero que tiene algo que ver. - Cohesión lógica: módulo que contiene tareas relacionadas lógicamente. Cohesión temporal . módulo que contiene tareas relacionadas por el hecho que deben realizarse en el mismo intervalo. - Cohesión procedimental: Cuando los elementos de procesamiento están relacionados y deben ejecutarse en un orden específico. - Cohesión de comunicación: cuando todos los elementos de procesamiento se concentran en un area de la estructura de datos. Acoplamiento: es una medida de interdependencia relativa entre los módulos. Medida de la interconexión entre los módulos de una estructura de programa. Depende de la complejidad de la interfaz entre los módulos, el punto en el que se entra o se hace referencia al módulo y que datos pasan a través de la interfaz. En el diseño intentamos conseguir el menor acoplamiento. Las conexiones sencillas entre módulos son más fáciles de entender. 13.6 HEURISTICAS DE DISEÑO PARA UNA MODULARIDAD EFECTIVA.
La arquitectura del programa se manipula de acuerdo con un conj de directrices: 1) evaluar la primera iteración de la estructura del programa para reducir el acoplamiento y mejorar la cohesión. 4
2) Intentar minimizar las estructuras con mucho grado de salida: intentar concentrar a medida que aumenta la profundidad. 3) Mantener el alcance del efecto de un módulo dentro del alcance del control de ese módulo. 4) Evaluar las interfaces de los módulos para reducir la complejidad, la redundancia y mejorar la consistencia. 5) Definir módulos cuya función sea predecible, pero evitar módulos que sean demasiados restrictivos. 6) Intentar conseguir módulos de entrada controlada evitando conexiones patológicas 7) Empaquetar el soft basándose en las restricciones del diseño y los requisitos de portabilidad. 13.7 LA DOCUMENTACION DEL DISEÑO
I) II) III) IV) V) VI) VII) VIII) IX)
AMBITO. DISEÑO DE DATOS. DISEÑO ARQUITECTÓNICO DISEÑO DE INTERFAZ DISEÑO PROCEDIMENTAL REFERENCIA CRUZADA DE REQUISITOS. RECURSOS DE PRUEBAS NOTAS ESPECIALES APENDICE.
5
