sábado, 28 de noviembre de 2015

Principios del Diseño de Software


  • 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