Diseño del Software

Title: Diseño
Body: Entrada
Documento de requisitos del software
Actividades
Establecer una(s) estrategia(s) de solución
Análisis de alternativas. Formalizar la solución
Descomponer y organizar la aplicación
Fijar descripciones de cada módulo
Salida
Documento de diseño del software

Title: Diseño de Software
Body: Un diseño de software es un modelo de un sistema del mundo real que tiene muchas entidades participantes y relaciones entre ellas.
Debe ser posible visualizarlo a diferentes niveles de abstracción.
Traduce los requisitos del software a un conjunto de representaciones (gráficas, tabulares, basadas en lenguajes) que describen la estructura de datos, la arquitectura, el procedimiento algorítmico y las características de la interfaz.

Title: El diseño del SW
Body: El diseño debe actuar como base para la implementación.
Es un medio de comunicación entre los diseñadores de subsistemas
Provee información para el mantenimiento, a cerca de la intención original.

Title: El proceso de diseño involucra:
Body: Describir el sistema como un número de diferentes niveles de abstracción.
El diseño es descompuesto y se va refinando, errores y omisiones en etapas tempranas son descubiertos.
Las etapas que se muestran a continuación son arbitrarias pero muestran el proceso y permiten la administración del proceso:

Title: Capas del diseño
Body: El diseño se enfoca sobre cuatro atributos distintos del programa:
La estructura de los datos
La arquitectura del software
El detalle procedimental y
La caracterización de la interfaz.

Title: Principios del diseño
Body: El proceso de diseño no debe sugerir de "visión de túnel"
El diseño debe ser rastreable hacia el modelo de análisis
El diseño no debe "reinventar la rueda"
El diseño debe "minimizar la distancia intelectual" entre el software y el problema como en el mundo real.
El diseño debe exhibir uniformidad e integración.
El diseño debe estructurarse para soportar el cambio.
El diseño debe ser estructurado para acoplarse, aún cuando datos aberrantes, eventos o condiciones de operación se presenten.
El diseño no es codificación, codificar no es diseñar.
El diseño debe establecerse para calidad como será creado, no después de contruir el software.
El diseño debe ser revisado para minimizar errores conceptuales (semántica).

Title: Diseño orientado a objetos
Body: Descomposición y organización en partes
Partes = clases o abstracciones
Organización: estructura del conjunto
Relaciones entre clases
Agregación: objetos que contienen otros objetos
Uso: clases que utilizan otras clases
Herencia: clases especializadas
Otras relaciones: modelo de datos.
Ejemplo: paciente padece enfermedad

Title: Diagramas de clases
Clase
Atributos
Métodos
Herencia
Uso
Agregación

Title: Descomposición modular
Body: Módulo: agrupación de elementos
Clases, tipos, constantes, objetos, etc.
Acoplamiento
Ligaduras o interferencias entre módulos
Deseable bajo acoplamiento (independencia)
Ejemplo: No usar variables globales por su nombre
Cohesión
Relación entre los elementos de un módulo
Deseable alta cohesión
Ejemplo: Módulos que sean clases o TADs