CAPÍTULO

CONCEPTOS DE DISEÑO
8
E
CONCEPTOS CLAVE l diseño de software agrupa el conjunto de principios, conceptos y prácticas que llevan al
abstracción . . . . . . . . . . . . . 189 desarrollo de un sistema o producto de alta calidad. Los principios de diseño establecen
arquitectura . . . . . . . . . . . . 190 una filosofía general que guía el trabajo de diseño que debe ejecutarse. Deben entenderse
aspectos. . . . . . . . . . . . . . . 194 los conceptos de diseño antes de aplicar la mecánica de éste, y la práctica del diseño en sí lleva
atributos de la calidad . . . . . 187 a la creación de distintas representaciones del software que sirve como guía para la actividad
buen diseño . . . . . . . . . . . . 187 de construcción que siga.
cohesión . . . . . . . . . . . . . . . 193 El diseño es crucial para el éxito de la ingeniería de software. A principios de la década de
diseño de datos. . . . . . . . . . 199 1990, Mitch Kapor, creador de Lotus 1-2-3, publicó en Dr. Dobbs Journal un “manifiesto del di-
diseño del software. . . . . . . 188 seño de software”. Decía lo siguiente:
diseño orientado a objeto . . 195
¿Qué es el diseño? Es donde se está con un pie en dos mundos —el de la tecnología y el de las perso-
división de problemas . . . . . 191 nas y los propósitos humanos— que tratan de unificarse...
independencia funcional . . . . 193 Vitruvio, romano crítico de arquitectura, afirmaba que los edificios bien diseñados eran aquellos
lineamientos de la calidad . . 186 que tenían resistencia, funcionalidad y belleza. Lo mismo se aplica al buen software. Resistencia: un
modularidad . . . . . . . . . . . . 191 programa no debe tener ningún error que impida su funcionamiento. Funcionalidad: un programa debe
ocultamiento de se apropiado para los fines que persigue. Belleza: la experiencia de usar el programa debe ser placen-
información. . . . . . . . . . . . . 192
tera. Éstos son los comienzos de una teoría del diseño de software.
patrones. . . . . . . . . . . . . . . 191
El objetivo del diseño es producir un modelo o representación que tenga resistencia, funciona-
proceso de diseño . . . . . . . . 186
lidad y belleza. Para lograrlo, debe practicarse la diversificación y luego la convergencia. Belady
rediseño . . . . . . . . . . . . . . . 195
[Bel81] afirma que “la diversificación es la adquisición de un repertorio de alternativas, materia
refinamiento . . . . . . . . . . . . 194
prima del diseño: componentes, soluciones con los componentes y conocimiento, todo lo cual

UNA
MIRADA ¿Qué es? El diseño es lo que casi todo inge- arquitectura del sistema o producto. Después se modelan
RÁPIDA
niero quiere hacer. Es el lugar en el que las las interfaces que conectan al software con los usuarios
reglas de la creatividad —los requerimientos de finales, con otros sistemas y dispositivos, y con sus propios
los participantes, las necesidades del negocio y componentes constitutivos. Por último, se diseñan los com-
las consideraciones técnicas— se unen para formular un ponentes del software que se utilizan para construir el sis-
producto o sistema. El diseño crea una representación o tema. Cada una de estas perspectivas representa una
modelo del software, pero, a diferencia del modelo de los acción de diseño distinta, pero todas deben apegarse a un
requerimientos (que se centra en describir los datos que se conjunto básico de conceptos de diseño que guíe el traba-
necesitan, la función y el comportamiento), el modelo de jo de producción de software.
diseño proporciona detalles sobre arquitectura del soft- ¿Cuál es el producto final? El trabajo principal que se
ware, estructuras de datos, interfaces y componentes que produce durante el diseño del software es un modelo de
se necesitan para implementar el sistema. diseño que agrupa las representaciones arquitectónicas,
¿Quién lo hace? Ingenieros de software llevan a cabo interfaces en el nivel de componente y despliegue.
cada una de las tareas del diseño. ¿Cómo me aseguro de que lo hice bien? El modelo
¿Por qué es importante? El diseño permite modelar el de diseño es evaluado por el equipo de software en un
sistema o producto que se va a construir. Este modelo se esfuerzo por determinar si contiene errores, inconsistencias
evalúa respecto de la calidad y su mejora antes de generar u omisiones, si existen mejores alternativas y si es posible
código; después, se efectúan pruebas y se involucra a implementar el modelo dentro de las restricciones, plazo y
muchos usuarios finales. El diseño es el lugar en el que se costo que se hayan establecido.
establece la calidad del software.
¿Cuáles son los pasos? El diseño representa al software
de varias maneras. En primer lugar, debe representarse la

183
184 PAR TE DOS MODELADO

está contenido en catálogos, libros de texto y en la mente”. Una vez que se reúne este conjunto
diversificado de información, deben escogerse aquellos elementos del repertorio que cumplan
los requerimientos definidos por la ingeniería y por el modelo de análisis (capítulos 5 a 7). A
medida que esto ocurre, se evalúan las alternativas, algunas se rechazan, se converge en “una
configuración particular de componentes y, con ello, en la creación del producto final” [Bel81].
La diversificación y la convergencia combinan la intuición y el criterio con base en la expe-
riencia en la construcción de entidades similares, un conjunto de principios heurísticos que
guían la forma en la que evoluciona el modelo, un conjunto de criterios que permiten evaluar la
calidad y un proceso iterativo que finalmente conduce a una representación del diseño defini-
tivo.
El diseño del software cambia continuamente conforme evolucionan los nuevos métodos,
surgen mejores análisis y se obtiene una comprensión más amplia.1 Incluso hoy, la mayor parte
de las metodologías de diseño de software carece de profundidad, flexibilidad y naturaleza
cuantitativa, que normalmente se asocian con las disciplinas de diseño de ingeniería más clási-
cas. No obstante, sí existen métodos para diseñar software, se dispone de criterios para el diseño
con calidad y se aplica la notación del diseño. En este capítulo, se estudian los conceptos y
principios fundamentales aplicables a todo el diseño de software, los elementos del modelo del
diseño y el efecto que tienen los patrones en el proceso de diseño. En los capítulos 9 a 13 se
presentarán varias metodologías de diseño de software, según se aplican en la obtención de
arquitecturas e interfaces en el nivel de componente, así como a enfoques de diseño basados
en patrones y orientados a web.

8.1 DISEÑO EN EL CONTEXTO DE LA INGENIERÍA DE SOFTWARE

El diseño de software se ubica en el área técnica de la ingeniería de software y se aplica sin

Cita: importar el modelo del proceso que se utilice. El diseño del software comienza una vez que se
“El milagro más común de la han analizado y modelado los requerimientos, es la última acción de la ingeniería de soft-
ingeniería de software es la ware dentro de la actividad de modelado y prepara la etapa de construcción (generación y
transición del análisis al diseño prueba de código).
y de éste al código.” Cada uno de los elementos del modelo de requerimientos (capítulos 6 y 7) proporciona infor-
Richard Due’ mación necesaria para crear los cuatro modelos de diseño necesarios para la especificación
completa del diseño. En la figura 8.1 se ilustra el flujo de la información durante el diseño del
software. El trabajo de diseño es alimentado por el modelo de requerimientos, manifestado por
elementos basados en el escenario, en la clase, orientados al flujo, y del comportamiento. El
empleo de la notación y de los métodos de diseño estudiados en los últimos capítulos produce
diseños de los datos o clases, de la arquitectura, de la interfaz y de los componentes.
El diseño de datos o clases transforma los modelos de clases (capítulo 6) en realizaciones de
CONSEJO
clases de diseño y en las estructuras de datos que se requieren para implementar el software.
El diseño del software siempre debe Los objetos y relaciones definidos en el diagrama CRC y el contenido detallado de los datos
comenzar con el análisis de los ilustrado por los atributos de clase y otros tipos de notación dan la base para el diseño de los
datos, pues son el fundamento de
datos. Parte del diseño de clase puede llevarse a cabo junto con el diseño de la arquitectura del
todos los demás elementos del
diseño. Una vez obtenido el software. Un diseño más detallado de las clases tiene lugar cuando se diseña cada componente
fundamento, se obtiene la del software.
arquitectura. Sólo entonces deben El diseño de la arquitectura define la relación entre los elementos principales de la estructura
realizarse otros trabajos del diseño. del software, los estilos y patrones de diseño de la arquitectura que pueden usarse para alcanzar

1 Aquellos lectores interesados en la filosofía del diseño de software pueden consultar el inquietante análisis de
Philippe Kruchen sobre el diseño “posmoderno” [Kru05a].
 CAPÍTULO 8 C O N C E PT O S D E D I S E Ñ O 185

FIGURA 8.1 Traducción del modelo de requerimientos al modelo de diseño

Elementos basados Elementos orientados Diseño en el nivel

en el escenario al flujo de componentes
Casos de uso - texto Diagramas de flujo de datos
Diagramas de casos de uso Diagramas de flujo del control
Diagramas de actividades Narrativas de procesamiento
Diagramas de canal Diseño de
la interfaz
Modelo de análisis
Elementos basados Elementos del
en clases comportamiento Diseño de la arquitectura
Diagramas de clases Diagramas de estado
Paquetes de análisis Diagramas de secuencia
Modelos CRC Diseño de datos o clases
Diagramas de colaboración

Modelo del diseño

los requerimientos definidos por el sistema y las restricciones que afectan la forma en la que se
Cita: implementa la arquitectura [Sha96]. La representación del diseño de la arquitectura —el marco
“Hay dos formas de construir un de un sistema basado en computadora— se obtiene del modelo de los requerimientos.
diseño del software. Una es El diseño de la interfaz describe la forma en la que el software se comunica con los sistemas
hacerlo tan simple que sea que interactúan con él y con los humanos que lo utilizan. Una interfaz implica un flujo de infor-
obvio que no hay deficiencias y mación (por ejemplo, datos o control) y un tipo específico de comportamiento. Entonces, los
la otra es hacerlo tan complica-
modelos de escenarios de uso y de comportamiento dan mucha de la información requerida
do que no haya deficiencias
obvias. El primer método es para diseñar la interfaz.
mucho más difícil.” El diseño en el nivel de componente transforma los elementos estructurales de la arquitec-
tura del software en una descripción de sus componentes en cuanto a procedimiento. La infor-
C. A. R. Hoare
mación obtenida a partir de los modelos basados en clase, flujo y comportamiento sirve como
la base para diseñar los componentes.
Durante el diseño se toman decisiones que en última instancia afectarán al éxito de la cons-
trucción del software y, de igual importancia, a la facilidad con la que puede darse manteni-
miento al software. Pero, ¿por qué es tan importante el diseño?
La importancia del diseño del software se resume en una palabra: calidad. El diseño es el
sitio en el que se introduce calidad en la ingeniería de software. Da representaciones del soft-
ware que pueden evaluarse en su calidad. Es la única manera de traducir con exactitud a un
producto o sistema terminado los requerimientos de los participantes. Es el fundamento de toda
la ingeniería de software y de las actividades que dan el apoyo que sigue. Sin diseño se corre el
riesgo de obtener un sistema inestable, que falle cuando se hagan cambios pequeños, o uno que
sea difícil de someter a prueba, o en el que no sea posible evaluar la calidad hasta que sea de-
masiado tarde en el proceso de software, cuando no queda mucho tiempo y ya se ha gastado
mucho dinero.
186 PAR TE DOS MODELADO

C ASA S EGURA
Diseño versus codificación
La escena: El cubículo de Jamie, cuando el equi- Jamie: ¿Qué?
po se prepara para traducir a diseño los requeri- Ed: Un lenguaje de programación es bueno para representar deta-
mientos. lles tales como estructuras de datos y algoritmos, pero no es tan
Participantes: Jamie, Vinod y Ed, miembros del equipo de inge- bueno para representar la arquitectura o la colaboración entre com-
niería de software para CasaSegura. ponentes… algo así.
La conversación: Vinod: Y una arquitectura complicada arruina al mejor código.
Jamie: Ustedes saben, Doug [el gerente del equipo] está obsesiona- Jamie (piensa unos momentos): Entonces, dicen que no
do con el diseño. Tengo que ser honesto, lo que realmente amo es puede representarse la arquitectura con código... eso no es cierto.
codificar. Denme C++ o Java y soy feliz. Vinod: Claro que es posible implicar la arquitectura con el código,
Ed: No… te gusta diseñar. pero en la mayor parte de lenguajes de programación, es muy difícil
Jamie: No me estás escuchando; codificar es lo mío. lograr un panorama rápido y amplio de la arquitectura con el análi-
sis del código.
Vinod: Creo que Ed quiere decir que en realidad no es codificar lo
que te gusta; te gusta diseñar y expresarlo en código. El código es el Ed: Y eso es lo que queremos hacer antes de empezar a codificar.
lenguaje que usas para representar el diseño. Jamie: Está bien, tal vez diseñar y codificar sean cosas distintas,
Jamie: ¿Y qué tiene de malo? pero aún así me gusta más codificar.

Vinod: El nivel de abstracción.

8.2 EL PROCESO DE DISEÑO

El diseño de software es un proceso iterativo por medio del cual se traducen los requerimientos
en un “plano” para construir el software. Al principio, el plano ilustra una visión holística del
software. Es decir, el diseño se representa en un nivel alto de abstracción, en el que se rastrea
directamente el objetivo específico del sistema y los requerimientos más detallados de datos,
funcionamiento y comportamiento. A medida que tienen lugar las iteraciones del diseño, las
mejoras posteriores conducen a niveles menores de abstracción. Éstos también pueden ras-
trearse hasta los requerimientos, pero la conexión es más sutil.

8.2.1 Lineamientos y atributos de la calidad del software

A través del proceso de diseño se evalúa la calidad de éste de acuerdo con la serie de revisiones
Cita: técnicas que se estudia en el capítulo 15. McGlaughlin [McG91] sugiere tres características que
funcionan como guía para evaluar un buen diseño:
“…escribir un fragmento inteli-
gente de código que funcione es • Debe implementar todos los requerimientos explícitos contenidos en el modelo de
una cosa; diseñar algo que dé
requerimientos y dar cabida a todos los requerimientos implícitos que desean los partici-
apoyo a largo plazo a una
empresa es otra muy diferente”. pantes.

C. Ferguson
• Debe ser una guía legible y comprensible para quienes generan el código y para los que
lo prueban y dan el apoyo posterior.

• Debe proporcionar el panorama completo del software, y abordar los dominios de los
datos, las funciones y el comportamiento desde el punto de vista de la implementación.

En realidad, cada una de estas características es una meta del proceso de diseño. Pero, ¿cómo
se logran?

Lineamientos de la calidad. A fin de evaluar la calidad de una representación del diseño,

usted y otros miembros del equipo de software deben establecer los criterios técnicos de un
buen diseño. En la sección 8.3 se estudian conceptos de diseño que también sirven como crite-
 CAPÍTULO 8 C O N C E PT O S D E D I S E Ñ O 187

rios de calidad del software. En este momento, considere los siguientes lineamientos para el
diseño:

? ¿Cuáles son las 1. Debe tener una arquitectura que 1) se haya creado con el empleo de estilos o patrones
características de un arquitectónicos reconocibles, 2) esté compuesta de componentes con buenas caracte-
buen diseño? rísticas de diseño (éstas se analizan más adelante, en este capítulo), y 3) se implemen-
ten en forma evolutiva,2 de modo que faciliten la implementación y las pruebas.
2. Debe ser modular, es decir, el software debe estar dividido de manera lógica en elemen-
tos o subsistemas.
3. Debe contener distintas representaciones de datos, arquitectura, interfaces y compo-
nentes.
4. Debe conducir a estructuras de datos apropiadas para las clases que se van a imple-
mentar y que surjan de patrones reconocibles de datos.
5. Debe llevar a componentes que tengan características funcionales independientes.
6. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los
componentes y el ambiente externo.
7. Debe obtenerse con el empleo de un método repetible motivado por la información ob-
tenida durante el análisis de los requerimientos del software.
8. Debe representarse con una notación que comunique con eficacia su significado.

Estos lineamientos de diseño no se logran por azar. Se consiguen con la aplicación de los prin-
cipios de diseño fundamentales, una metodología sistemática y con revisión.

I NFOR MACIÓN
Evaluación de la calidad del diseño. La revisión técnica
El diseño es importante porque permite que un equipo de revisión planea la reunión, establece la agenda y coordina la junta; el
software evalúe la calidad3 de éste antes de que se imple- secretario toma notas para que no se pierda nada; el productor es la
mente, momento en el que es fácil y barato corregir errores, omisio- persona cuyo trabajo (por ejemplo, el diseño de un componente del
nes o inconsistencias. Pero, ¿cómo se evalúa la calidad durante el software) se revisa. Antes de la reunión, se entrega a cada persona
diseño? El software no puede someterse a prueba porque no hay del equipo una copia del producto del trabajo de diseño y se le pide
nada ejecutable. ¿Qué hacer? que la lea y que busque errores, omisiones o ambigüedades. El obje-
Durante el diseño, la calidad se evalúa por medio de la realiza- tivo al comenzar la reunión es detectar todos los problemas del pro-
ción de una serie de revisiones técnicas (RT). Las RT se estudian con ducto, de modo que puedan corregirse antes de que comience la
detalle en el capítulo 15,4 pero es útil hacer un resumen de dicha téc- implementación. Es común que la RT dure entre 90 minutos y 2 horas.
nica en este momento. Una revisión técnica es una reunión celebrada Al final de ella, el equipo de revisión determina si se requiere de otras
por miembros del equipo de software. Por lo general, participan dos, acciones por parte del productor a fin de que se apruebe el producto
tres o cuatro personas, en función del alcance de la información del como porción del modelo del diseño final.
diseño que se revisará. Cada persona tiene un papel: el líder de la

Atributos de la calidad. Hewlett-Packard [Gra87] desarrolló un conjunto de atributos de la

Cita: calidad del software a los que se dio el acrónimo FURPS: funcionalidad, usabilidad, confiabili-

“La calidad no es algo que se dad, rendimiento y mantenibilidad. Los atributos de calidad FURPS representan el objetivo de
deje arriba de los sujetos y obje- todo diseño de software:
tos como si fuera el remate de
un árbol de navidad.”
2 Para sistemas pequeños, en ocasiones el diseño puede desarrollarse en forma lineal.
Robert Pirsig
3 Los factores de calidad que se estudian en el capítulo 23 ayudan al equipo de revisión cuando evalúa aquélla.
4 Tal vez el lector considere oportuno revisar el capítulo 15 en este momento. Las revisiones técnicas son una parte
crítica del proceso de diseño y un mecanismo importante para lograr su calidad.
188 PAR TE DOS MODELADO

• La funcionalidad se califica de acuerdo con el conjunto de características y capacidades

CONSEJO
del programa, la generalidad de las funciones que se entregan y la seguridad general del
Los diseñadores del software tienden sistema.
a centrarse en el problema que se va
a resolver. No olvide que los • La usabilidad se evalúa tomando en cuenta factores humanos (véase el capítulo 11), la
atributos FURPS siempre forman estética general, la consistencia y la documentación.
parte del problema. Deben tomarse • La confiabilidad se evalúa con la medición de la frecuencia y gravedad de las fallas, la
en cuenta.
exactitud de los resultados que salen, el tiempo medio para que ocurra una falla (TMPF),
la capacidad de recuperación ante ésta y lo predecible del programa.

• El rendimiento se mide con base en la velocidad de procesamiento, el tiempo de

respuesta, el uso de recursos, el conjunto y la eficiencia.

• La mantenibilidad combina la capacidad del programa para ser ampliable (extensibi-

lidad), adaptable y servicial (estos tres atributos se denotan con un término más común:
mantenibilidad), y además que pueda probarse, ser compatible y configurable (capacidad
de organizar y controlar los elementos de la configuración del software, véase el
capítulo 22) y que cuente con la facilidad para instalarse en el sistema y para que se
detecten los problemas.
No todo atributo de la calidad del software se pondera por igual al diseñarlo. Una aplicación tal
vez se aboque a lo funcional con énfasis en la seguridad. Otra quizá busque rendimiento con la
mira puesta en la velocidad de procesamiento. En una tercera se persigue la confiabilidad. Sin
importar la ponderación, es importante observar que estos atributos de la calidad deben to-
marse en cuenta cuando comienza el diseño, no cuando haya terminado éste y la construcción
se encuentre en marcha.

8.2.2 La evolución del diseño del software

La evolución del diseño del software es un proceso continuo que ya ha cubierto casi seis déca-
Cita: das. Los primeros trabajos de diseño se concentraban en criterios para el desarrollo de progra-
mas modulares [Den73] y en métodos para mejorar estructuras de software con un enfoque de
“Un diseñador sabe que alcanzó
la perfección no cuando no hay arriba abajo [Wir71]. Los aspectos de procedimiento del diseño evolucionaron hacia una filoso-
nada por agregar, sino cuando fía llamada programación estructurada [Dah72], [Mil72]. Los trabajos posteriores propusieron
no hay nada que quitar.” métodos para traducir el flujo de datos [Ste74] o la estructura de éstos (por ejemplo, [Jac75],
[War74]) a una definición de diseño. Los enfoques más nuevos (por ejemplo, [Jac92], [Gam95])
Antoine de Saint-Exupery
propusieron un enfoque orientado a objeto para diseñar derivaciones. En los últimos tiempos,
el énfasis al desarrollar software se pone en la arquitectura de éste [Kru06] y en los patrones de
diseño susceptibles de emplearse para implementar arquitecturas y niveles más bajos de abs-
tracciones del diseño (por ejemplo, [Hol06], [Sha05]). Se da cada vez más importancia a los
métodos orientados al aspecto (por ejemplo, [Cla05], [Jac04]), al desarrollo orientado al modelo
[Sch06] y a las pruebas [Ast04], que se concentran en llegar a una modularidad eficaz y a la
estructura arquitectónica de los diseños que se generan.

? ¿Qué características son

comunes en todos los
En la industria del software se aplican varios métodos de diseño, aparte de los ya menciona-
dos. Igual que los métodos de análisis presentados en los capítulos 6 y 7, cada método de diseño
métodos de diseño? de software introduce heurística y notación únicas, así como un punto de vista sobre lo que
caracteriza a la calidad en el diseño. No obstante, todos estos métodos tienen algunas caracte-
rísticas en común: 1) un mecanismo para traducir el modelo de requerimientos en una repre-
sentación del diseño, 2) una notación para representar las componentes funcionales y sus in-
terfaces, 3) una heurística para mejorar y hacer particiones y 4) lineamientos para evaluar la
calidad.
Sin importar el método de diseño que se utilice, debe aplicarse un conjunto de conceptos
básicos al diseño en el nivel de datos, arquitectura, interfaz y componente. En las secciones que
siguen se estudian estos conceptos.
 CAPÍTULO 8 C O N C E PT O S D E D I S E Ñ O 189

C ONJUNTO DE TAREAS
Conjunto de tareas generales para el diseño
1. Estudiar el modelo del dominio de la informa- Revise las clases de diseño y, si se requiere, modifíquelas.
ción y diseñar las estructuras de datos apropiadas 5. Diseñar cualesquiera interfaces requeridas con sistemas o dis-
para los objetos de datos y sus atributos. positivos externos.
2. Seleccionar un estilo de arquitectura que sea ade- 6. Diseñar la interfaz de usuario.
cuado para el software con el uso del modelo de análisis. Revise los resultados del análisis de tareas.
3. Hacer la partición del modelo de análisis en subsistemas de Especifique la secuencia de acciones con base
diseño y asignar éstos dentro de la arquitectura: en los escenarios de usuario.
Asegúrese de que cada subsistema sea cohesivo Cree un modelo de comportamiento de la interfaz.
en sus funciones. Defina los objetos de la interfaz y los mecanismos de control.
Diseñe interfaces del subsistema. Revise el diseño de la interfaz y, si se requiere, modifíquelo.
Asigne clases de análisis o funciones a cada subsistema. 7. Efectuar el diseño en el nivel de componente.
4. Crear un conjunto de clases de diseño o componentes: Especifique todos los algoritmos en un nivel
Traduzca la descripción de clases de análisis a una clase de abstracción relativamente bajo.
de diseño. Mejore la interfaz de cada componente.
Compare cada clase de diseño con los criterios de diseño; Defina estructuras de datos en el nivel de componente.
considere los aspectos hereditarios. Revise cada componente y corrija todos los errores
Defina métodos y mensajes asociados con cada clase que se detecten.
de diseño. 8. Desarrollar un modelo de despliegue.
Evalúe y seleccione patrones de diseño para una clase
de diseño o subsistema.

8.3 CONCEPTOS DE DISEÑO

Durante la historia de la ingeniería de software, ha evolucionado un conjunto de conceptos

fundamentales sobre su diseño. Aunque con el paso de los años ha variado el grado de interés
en cada concepto, todos han soportado la prueba del tiempo. Cada uno da al diseñador del
software el fundamento desde el que pueden aplicarse métodos de diseño sofisticados. Todos
ayudan a responder las preguntas siguientes:

• ¿Qué criterios se usan para dividir el software en sus componentes individuales?

• ¿Cómo se extraen los detalles de la función o la estructura de datos de la representación
conceptual del software?

• ¿Cuáles son los criterios uniformes que definen la calidad técnica de un diseño de
software?

M. A. Jackson [Jac75] dijo: “El principio de la sabiduría [para un ingeniero de software] es

reconocer la diferencia que hay entre hacer que un programa funcione y lograr que lo haga
bien”. Los conceptos fundamentales del diseño del software proveen la estructura necesaria
para “hacerlo bien”.
En las secciones que siguen, se da un panorama breve de los conceptos importantes del di-
seño de software, tanto del desarrollo tradicional como del orientado a objeto.

Cita: 8.3.1 Abstracción

“La abstracción es uno de los Cuando se considera una solución modular para cualquier problema, es posible plantear mu-
modos fundamentales con los
chos niveles de abstracción. En el más elevado se enuncia una solución en términos gruesos
que los humanos luchamos con
la complejidad.” con el uso del lenguaje del ambiente del problema. En niveles más bajos de abstracción se da
la descripción más detallada de la solución. La terminología orientada al problema se acopla
Grady Booch con la que se orienta a la implementación, en un esfuerzo por enunciar la solución. Por último,