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 proporcionan información necesaria para el diseño de la interfaz.
- Diseño procedimental: transforma elementos estructurales de la arquitectura del programa en una
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 proceso de diseño, se evalúa la calidad del diseño con una 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: 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) AMBITO.
II) DISEÑO DE DATOS.
III) DISEÑO ARQUITECTÓNICO
IV) DISEÑO DE INTERFAZ
V) DISEÑO PROCEDIMENTAL
VI) REFERENCIA CRUZADA DE REQUISITOS.
VII) RECURSOS DE PRUEBAS
VIII) NOTAS ESPECIALES
IX) APENDICE.