- No debería ponerse “orejas” (considerar enfoques alternativos).
- Se debería poder seguir los pasos del diseño desde el modelo de análisis.
- No debe inventar nada que ya esté inventado.
- Debería “minimizar la distancia intelectual” entre el software y el problema tal y como existe en el mundo real.
- Debería presentar uniformidad e integración.
- Debería estructurarse para admitir cambios.
- Debería estructurarse para degradarse poco a poco, incluso cuando se enfrenta a datos, sucesos o condiciones operativas aberrantes.
- 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 (semánticos).
ABSTRACCIÓN
La noción psicológica de abstracción permite concentrarse en
un problema a un nivel de generalización independiente de los
detalles de nivel inferior, la abstracción también permite
trabajar con conceptos y términos que son familiares en el
entorno del problema sin tener que transformarlos en una
estructura poco familiar.
Cada fase del proceso de ingeniería del software es un
refinamiento en el nivel de abstracción de la solución software.
Finalmente se alcanza el nivel inferior de abstracción cuando
se construye el código.
Abstracción procedimental: es una secuencia dada de
instrucciones que tiene 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 detalles internos
REFINAMIENTO PASO A PASO
La arquitectura de un programa se desarrolla refinando
sucesivamente niveles de detalle procedimental.
Se desarrolla una jerarquía descomponiendo un enunciado
macroscópico de función (una abstracción procedimental) al
estilo paso a paso hasta que se llega a los enunciados del
lenguaje de programación.
La abstracción y el refinamiento son conceptos
complementarios.
MODULARIDAD.
Se divide el software en componentes identificables y tratables
por separado, denominados módulos, que están integrados
para satisfacer los requisitos del programa.
La modularidad es el atributo del software que permite a un
programa ser manejable intelectualmente. La complejidad
percibida de un problema que combina p’ y p’’; es mayor que
la complejidad percibida cuando cada problema se considera
por separado.
Hay un número m de módulos que resultarían en un costo de
desarrollo mínimo, pero no tenemos la sofisticación necesaria
para predecir m con seguridad.
Meyer define cinco criterios que permiten evaluar un método de diseño con
respecto a su capacidad de definir un sistema modular eficaz:
Capacidad de descomposición funcional: mecanismo sistemático de
descomposición del problema en sub-problemas.
Capacidad de empleo de componentes modulares: ensamblar
componentes de diseño existentes.
Capacidad de comprensión modular: entender un módulo como una
unidad por sí sola.
Continuidad modular: cambios en los módulos individuales, en vez de
cambios generalizados en el sistema.
Protección modular: los efectos se restringen dentro de ese módulo.
JERARQUIA DE CONTROL (estructura del programa).
Representa la organización (a menudo jerárquica) de
componentes del programa (módulos) e implica una jerarquía
de control
Profundidad y anchura: proporcionan una indicación del número de niveles
de control y el ámbito global de control, respectivamente.
El grado de salida: es una medida del número de módulos que son
controlados directamente por otro módulo.
Superior.
Subordinado.
Visibilidad: indica el conjunto de componentes de programa que pueden
invocarse o usarse sus datos por un componente dado, incluso cuando esto
se realiza indirectamente.
Conectividad: indica el conjunto de componentes que son invocados
directamente o usados sus datos por un componente determinado
PARTICIÓN ESTRUCTURAL.
Partición horizontal: define ramas separadas de la
jerarquía modular para cada función principal del
programa. El enfoque más simple de partición
horizontal define tres particiones: entrada,
procesamiento y salida. Es más fácil de probar y de
mantener, propaga menos efectos secundarios, el
software es más fácil de ampliar.
Partición vertical: o 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 de la arquitectura
deberían ser los trabajadores, realizando todos los trabajos de
entrada, cálculo y salida. Las arquitecturas de partición vertical tienen menos
probabilidad de ser susceptibles a efectos secundarios cuando
se hacen cambios y tendrán por tanto mejor capacidad de
mantenimiento, un factor clave para la calidad.
sacado de:
http://uvirtual.ufps.edu.co/ufpsvirtual/pluginfile.php/5930/mod_resource/content/1/Dise%C3%B1o%20de%20software.pdf
No hay comentarios:
Publicar un comentario