1. Fundamentos del diseño de software.
Los conceptos, nociones y terminología presentados aquí forman una base subyacente para
comprender el papel y el alcance del diseño de software.
1.1. Conceptos generales de diseño.
En sentido general, el diseño puede verse como una forma de resolución de problemas. Por ejemplo,
el concepto de un problema perverso, un problema sin solución definitiva, es interesante en
términos de comprender los límites del diseño. Varias otras nociones y conceptos también son de
interés para comprender el diseño en su sentido general: objetivos, restricciones, alternativas,
representaciones y soluciones.
1.2. Contexto del diseño de software.
El diseño de software es una parte importante del proceso de desarrollo de software. Para
comprender el papel del diseño de software, debemos ver cómo encaja en el ciclo de vida del
desarrollo de software. Por lo tanto, es importante comprender las principales características del
análisis de requisitos de software, diseño de software, construcción de software, pruebas de
software y mantenimiento de software.
1.3. Proceso de diseño de software.
El diseño de software generalmente se considera un proceso de dos pasos:
El diseño arquitectónico (también conocido como diseño de alto nivel y diseño de nivel superior)
describe cómo se organiza el software en componentes.
El diseño detallado describe el comportamiento deseado de estos componentes.
El resultado de estos dos procesos es un conjunto de modelos y artefactos que registran las
principales decisiones que se han tomado, junto con una explicación del fundamento de cada
decisión no trivial. Al registrar la justificación, se mejora la capacidad de mantenimiento a largo plazo
del producto de software.
1.4. Principios de diseño de software.
Un principio es “una ley, doctrina o suposición integral y fundamental”. Los principios de diseño de
software son nociones clave que proporcionan la base para muchos enfoques y conceptos de diseño
de software diferentes. Los principios del diseño de software incluyen la abstracción; acoplamiento y
cohesión; descomposición y modularización; encapsulación / ocultación de información; separación
de interfaz e implementación; suficiencia, plenitud y primitividad; y separación de preocupaciones.
La abstracción es “una vista de un objeto que se enfoca en la información relevante para un
propósito particular e ignora el resto de la información”. En el contexto del diseño de
software, dos mecanismos clave de abstracción son la parametrización y la especificación. La
abstracción por parametrización se abstrae de los detalles de las representaciones de datos
al representar los datos como parámetros con nombre. La abstracción por especificación
conduce a tres tipos principales de abstracción: abstracción procedimental, abstracción de
datos y abstracción de control (iteración).
Acoplamiento y cohesión. El acoplamiento se define como “una medida de la
interdependencia entre módulos en un programa de computadora”, mientras que la
cohesión se define como “una medida de la fuerza de asociación de los elementos dentro de
un módulo”.
Descomposición y modularización. Descomponer y modularizar significa que el software
grande se divide en varios componentes con nombre más pequeños que tienen interfaces
bien definidas que describen las interacciones de los componentes. Por lo general, el
objetivo es colocar diferentes funcionalidades y responsabilidades en diferentes
componentes.
Encapsular y ocultar información significa agrupar y empaquetar los detalles internos de una
abstracción y hacer que esos detalles sean inaccesibles para entidades externas.
Separación de interfaz e implementación. Separar la interfaz y la implementación implica
definir un componente especificando una interfaz pública (conocida por los clientes) que
está separada de los detalles de cómo se realiza el componente (ver encapsulación y
ocultación de información arriba).
Suficiencia, integridad y primitividad. Lograr la suficiencia e integridad significa asegurarse
de que un componente de software capture todas las características importantes de una
abstracción y nada más. Primitividad significa que el diseño debe basarse en patrones que
sean fáciles de implementar.
Separación de intereses. Una preocupación es un “área de interés con respecto al diseño de
un software”. Una preocupación de diseño es un área de diseño que es relevante para una o
más de sus partes interesadas. Cada vista de arquitectura enmarca una o más
preocupaciones. Separar las preocupaciones por puntos de vista permite a las partes
interesadas centrarse en unas pocas cosas a la vez y ofrece un medio para gestionar la
complejidad.
3. Estructura y arquitectura del software.
En sentido estricto, una arquitectura de software es “el conjunto de estructuras necesarias para
razonar sobre el sistema, que comprende elementos de software, relaciones entre ellos y
propiedades de ambos”. Sin embargo, a mediados de la década de 1990, la arquitectura de software
comenzó a surgir como una disciplina más amplia que involucraba el estudio de estructuras y
arquitecturas de software de una manera más genérica. Esto dio lugar a una serie de conceptos
interesantes sobre el diseño de software en diferentes niveles de abstracción. Algunos de estos
conceptos pueden ser útiles durante el diseño arquitectónico (por ejemplo, estilos arquitectónicos)
así como durante el diseño detallado (por ejemplo, patrones de diseño). Estos conceptos de diseño
también se pueden utilizar para diseñar familias de programas (también conocidas como líneas de
productos). Curiosamente, la mayoría de estos conceptos pueden verse como intentos de describir
y, por lo tanto, reutilizar el conocimiento del diseño.
3.1. Estructuras arquitectónicas y miradores.
Se pueden describir y documentar diferentes facetas de alto nivel de un diseño de software. Estas
facetas a menudo se denominan vistas: "Una vista representa un aspecto parcial de una arquitectura
de software que muestra propiedades específicas de un sistema de software". Las vistas pertenecen
a distintos problemas asociados con el diseño de software, por ejemplo, la vista lógica (que satisface
los requisitos funcionales) frente a la vista del proceso (problemas de concurrencia) frente a la vista
física (problemas de distribución) frente a la vista de desarrollo (cómo se realiza el diseño).
desglosado en unidades de implementación con representación explícita de las dependencias entre
las unidades). Varios autores utilizan diferentes terminologías, como vistas de modelado de datos,
funcionales, funcionales, estructurales y de comportamiento. En resumen, un diseño de software es
un artefacto multifacético producido por el proceso de diseño y generalmente compuesto por vistas
relativamente independientes y ortogonales.
3.2. Estilos arquitectónicos.
Un estilo arquitectónico es “una especialización de tipos de elementos y relaciones, junto con un
conjunto de restricciones sobre cómo se pueden usar”. Por tanto, se puede considerar que un estilo
arquitectónico proporciona la organización de alto nivel del software. Varios autores han
identificado varios estilos arquitectónicos importantes:
Estructuras generales (por ejemplo, capas, tuberías y filtros, pizarra).
Sistemas distribuidos (por ejemplo, cliente-servidor, tres niveles, intermediario).
Sistemas interactivos (por ejemplo, Model-View Controller, Presentation-Abstraction-
Control).
Sistemas adaptables (por ejemplo, microkernel, refection).
Otros (por ejemplo, lote, intérpretes, control de procesos, basado en reglas).
3.3. Patrones de diseño.
Descrito de manera sucinta, un patrón es "una solución común a un problema común en un contexto
dado". Si bien los estilos arquitectónicos pueden verse como patrones que describen la organización
de alto nivel del software, se pueden usar otros patrones de diseño para describir detalles en un
nivel inferior. Estos patrones de diseño de nivel inferior incluyen lo siguiente:
Patrones de creación (por ejemplo, constructor, fábrica, prototipo, singleton).
Patrones estructurales (por ejemplo, adaptador, puente, compuesto, decorador, faoade,
fyweight, proxy).
Patrones de comportamiento (por ejemplo, comando, intérprete, iterador, mediador,
recuerdo, observador, estado, estrategia, plantilla, visitante).
3.4. Decisiones de diseño arquitectónico.
El diseño arquitectónico es un proceso creativo. Durante el proceso de diseño, los diseñadores de
software deben tomar una serie de decisiones fundamentales que afectan profundamente al
software y al proceso de desarrollo. Es útil pensar en el proceso de diseño arquitectónico desde una
perspectiva de toma de decisiones más que desde una perspectiva de actividad. A menudo, el
impacto en los atributos de calidad y las compensaciones entre los atributos de calidad en
competencia son la base de las decisiones de diseño.
3.5. Familias de programas y marcos.
Un enfoque para permitir la reutilización de diseños y componentes de software es diseñar familias
de programas, también conocidas como líneas de productos de software. Esto se puede hacer
identificando los puntos en común entre los miembros de dichas familias y diseñando componentes
reutilizables y personalizables para tener en cuenta la variabilidad entre los miembros de la familia.
En la programación orientada a objetos (OO), una noción clave relacionada es la de un marco: un
sistema de software parcialmente completado que puede extenderse creando instancias adecuadas
de extensiones específicas (como complementos).
5. Análisis y evaluación de la calidad del diseño de software.
Esta sección incluye una serie de temas de análisis y evaluación de la calidad que están
específicamente relacionados con el diseño de software.
5.1. Atributos de calidad.
Varios atributos contribuyen a la calidad de un diseño de software, incluyendo varias "-ilidades"
(mantenibilidad, portabilidad, capacidad de prueba, usabilidad) y "-osidades" (corrección, solidez).
Existe una distinción interesante entre los atributos de calidad discernibles en tiempo de ejecución
(por ejemplo, rendimiento, seguridad, disponibilidad, funcionalidad, usabilidad), aquellos que no se
pueden discernir en tiempo de ejecución (por ejemplo, modificabilidad, portabilidad, reutilización,
capacidad de prueba) y los relacionados con la arquitectura. cualidades intrínsecas (por ejemplo,
integridad conceptual, corrección, integridad).
5.2. Técnicas de análisis y evaluación de la calidad.
Varias herramientas y técnicas pueden ayudar a analizar y evaluar la calidad del diseño del software.
Revisiones de diseño de software: técnicas informales y formalizadas para determinar la
calidad de los artefactos de diseño (por ejemplo, revisiones de arquitectura, revisiones de
diseño e inspecciones; técnicas basadas en escenarios; rastreo de requisitos). Las revisiones
de diseño de software también pueden evaluar la seguridad. Se pueden revisar las ayudas
para la instalación, operación y uso (por ejemplo, manuales y archivos de ayuda).
Análisis estático: análisis estático (no ejecutable) formal o semiformal que se puede utilizar
para evaluar un diseño (por ejemplo, análisis de árbol de fallas o verificación cruzada
automatizada). El análisis de vulnerabilidad de diseño (por ejemplo, análisis estático de
debilidades de seguridad) se puede realizar si la seguridad es un problema. El análisis de
diseño formal utiliza modelos matemáticos que permiten a los diseñadores predecir el
comportamiento y validar el rendimiento del software en lugar de tener que depender
completamente de las pruebas. El análisis de diseño formal se puede utilizar para detectar
especificación residual y errores de diseño (quizás causados por imprecisión, ambigüedad y,
a veces, otros tipos de errores).
Simulación y creación de prototipos: técnicas dinámicas para evaluar un diseño (por
ejemplo, simulación de rendimiento o prototipos de viabilidad).
5.3. Medidas.
Las medidas se pueden utilizar para evaluar o estimar cuantitativamente varios aspectos de un
diseño de software; por ejemplo, tamaño, estructura o calidad. La mayoría de las medidas que se
han propuesto dependen del enfoque utilizado para producir el diseño. Estas medidas se clasifican
en dos amplias categorías:
Medidas de diseño (estructuradas) basadas en funciones: medidas obtenidas mediante el
análisis de la descomposición funcional; generalmente representado usando un diagrama de
estructura (a veces llamado diagrama jerárquico) en el que se pueden calcular varias
medidas.
Medidas de diseño orientadas a objetos: la estructura de diseño se representa normalmente
como un diagrama de clases, en el que se pueden calcular varias medidas. También se
pueden calcular medidas sobre las propiedades del contenido interno de cada clase.
7. Estrategias y métodos de diseño de software.
Existen varias estrategias generales para ayudar a guiar el proceso de diseño. A diferencia de las
estrategias generales, los métodos son más específicos en el sentido de que generalmente
proporcionan un conjunto de notaciones que se utilizarán con el método, una descripción del
proceso que se utilizará al seguir el método y un conjunto de directrices para utilizar el método.
Estos métodos son útiles como marco común para los equipos de ingenieros de software.
7.1. Estrategias generales.
Algunos ejemplos de estrategias generales útiles en el proceso de diseño que se citan a menudo
incluyen las estrategias divide y vencerás y las estrategias de refinamiento paso a paso, las
estrategias de arriba hacia abajo frente a las de abajo hacia arriba, y las estrategias que utilizan
heurísticas, el uso de patrones y lenguajes de patrones, y el uso de un enfoque iterativo e
incremental.
7.2. Diseño (estructurado) orientado a funciones.
Este es uno de los métodos clásicos de diseño de software, donde la descomposición se centra en
identificar las principales funciones del software y luego elaborarlas y refinarlas de manera
jerárquica de arriba hacia abajo. El diseño estructurado se utiliza generalmente después del análisis
estructurado, produciendo así (entre otras cosas) diagramas de flujo de datos y descripciones de
procesos asociados. Los investigadores han propuesto varias estrategias (por ejemplo, análisis de
transformación, análisis de transacciones) y heurísticas (por ejemplo, fan-in / fan-out, alcance de
efecto versus alcance de control) para transformar un DFD en una arquitectura de software
generalmente representada como un diagrama de estructura.
7.3. Diseño orientado a objetos.
Se han propuesto numerosos métodos de diseño de software basados en objetos. El campo ha
evolucionado desde el diseño temprano orientado a objetos (OO) de mediados de la década de 1980
(objeto sustantivo; método verbo; atributo adjetivo), donde la herencia y el polimorfismo juegan un
papel clave, al campo del diseño basado en componentes, donde la metainformación se puede
definir y acceder (a través de la reflexión, por ejemplo). Aunque las raíces del diseño OO se derivan
del concepto de abstracción de datos, el diseño impulsado por la responsabilidad se ha propuesto
como un enfoque alternativo al diseño OO.
7.4. Diseño centrado en la estructura de datos.
El diseño centrado en la estructura de datos comienza con las estructuras de datos que manipula un
programa en lugar de la función que realiza. El ingeniero de software primero describe las
estructuras de datos de entrada y salida y luego desarrolla la estructura de control del programa
basándose en estos diagramas de estructura de datos. Se han propuesto varias heurísticas para
tratar casos especiales, por ejemplo, cuando hay un desajuste entre las estructuras de entrada y
salida.
7.5. Diseño basado en componentes (CBD).
Un componente de software es una unidad independiente, que tiene interfaces y dependencias bien
definidas que se pueden componer e implementar de forma independiente. El diseño basado en
componentes aborda cuestiones relacionadas con la provisión, el desarrollo y la integración de
dichos componentes para mejorar la reutilización. Los componentes de software reutilizados y listos
para usar deben cumplir los mismos requisitos de seguridad que el software nuevo. La gestión de la
confianza es una preocupación de diseño; los componentes tratados como si tuvieran un cierto
grado de confiabilidad no deberían depender de componentes o servicios menos confiables.
7.6. Otros métodos.
También existen otros enfoques interesantes (consulte Modelos y métodos de ingeniería de
software KA). Los métodos iterativos y adaptativos implementan incrementos de software y reducen
el énfasis en los requisitos y el diseño rigurosos del software.
El diseño orientado a aspectos es un método mediante el cual el software se construye utilizando
aspectos para implementar las preocupaciones transversales y las extensiones que se identifican
durante el proceso de requisitos del software. La arquitectura orientada a servicios es una forma de
crear software distribuido utilizando servicios web ejecutados en computadoras distribuidas. Los
sistemas de software a menudo se construyen utilizando servicios de diferentes proveedores porque
los protocolos estándar (como HTTP, HTTPS, SOAP) se han diseñado para soportar la comunicación
de servicios y el intercambio de información de servicios.
