[Link].

me
 Ingeniería del software
UNE N F O Q U E P R Á C T I C O

SÉPTIMA EDICIÓN

Roger S. Pressman, Ph.D.

University of Connecticut

MÉXICO • BOGOTÁ • BUENOS AIRES • CARACAS • GUATEMALA • MADRID

NUEVA YORK • SAN JUAN • SANTIAGO • SÃO PAULO • AUCKLAND • LONDRES • MILÁN
MONTREAL • NUEVA DELHI • SAN FRANCISCO • SINGAPUR • ST. LOUIS • SIDNEY • TORONTO

[Link]
 vii

[Link]
 CAPÍTULO

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

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

[Link]
184 PARTE 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.1D I S E Ñ O EN EL C O N T E X T O DE LA I N G E N I E R Í A DE S O F T W A R E

Cita: El diseñ o de software se ubica en el á rea té cnica de la ingeniería de software y se aplica sin
“El milagro más común importar el modelo del proceso que se utilice. El diseñ o del software comienza una vez que se
de la ingeniería de han analizado y modelado los requerimientos, es la ú ltima acció n de la ingeniería de soft-
software es la transición ware dentro de la actividad de modelado y prepara la etapa de construcción (generació n y
del análisis al diseño y
prueba de có digo).
de éste al código.”
Richard Due’ Cada uno de los elementos del modelo de requerimientos (capítulos 6 y 7) proporciona
infor- 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.
CONSEJO El diseñ o de datos o clases transforma los modelos de clases (capítulo 6) en realizaciones de
El diseño del software siempre debe clases de diseñ o y en las estructuras de datos que se requieren para implementar el software.
comenzar con el análisis de los Los objetos y relaciones definidos en el diagrama CRC y el contenido detallado de los datos
datos, pues son el fundamento de ilustrado por los atributos de clase y otros tipos de notació n dan la base para el diseñ o de los
todos los demás elementos del
datos. Parte del diseñ o de clase puede llevarse a cabo junto con el diseñ o de la arquitectura del
diseño. Una vez obtenido el
fundamento, se obtiene la software. Un diseñ o má s detallado de las clases tiene lugar cuando se diseñ a cada componente
arquitectura. Sólo entonces deben del software.
realizarse otros trabajos del diseño. El diseñ o de la arquitectura define la relació n entre los elementos principales de la
estructura 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].

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 185

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

Elementos basados en Elementos orientados al Diseño en el

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

Modelo del diseño

Cita: los requerimientos definidos por el sistema y las restricciones que afectan la forma en la que se
“Hay dos formas de implementa la arquitectura [Sha96]. La representació n del diseñ o de la arquitectura —el
construir un diseño del marco de un sistema basado en computadora— se obtiene del modelo de los requerimientos.
software. Una es hacerlo
El diseñ o de la interfaz describe la forma en la que el software se comunica con los sistemas
tan simple que sea obvio
que no hay deficiencias que interactú an con él y con los humanos que lo utilizan. Una interfaz implica un flujo de infor-
y la otra es hacerlo tan mació n (por ejemplo, datos o control) y un tipo específico de comportamiento. Entonces, los
complica- do que no modelos de escenarios de uso y de comportamiento dan mucha de la informació n requerida
haya deficiencias obvias. para diseñ ar la interfaz.
El primer método es El diseñ o en el nivel de componente transforma los elementos estructurales de la arquitec-
mucho más difícil.”
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.

[Link]
 186 PARTE DOS MODELADO

C ASA S EGURA
Disefio versus codificación
La escena: El cubículo de Jamie, cuando el
Jamie: ¿Qué?
equi- po se prepara para traducir a diseño los
requeri- mientos. Ed: Un lenguaje de programación es bueno para representar deta-
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á
Jamie (piensa unos momentos): Entonces, dicen que no
obsesiona- do con el diseño. Tengo que ser honesto, lo que
puede representarse la arquitectura con código... eso no es cierto.
realmente amo es 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
Vinod: Creo que Ed quiere decir que en realidad no es codificar lo análi- sis del código.
que te gusta; te gusta diseñar y expresarlo en código. El código es Ed: Y eso es lo que queremos hacer antes de empezar a codificar.
el 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.2E L PR O C E S O DE D I S E Ñ 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

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

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 187

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

1. Debe tener una arquitectura que 1) se haya creado con el empleo de estilos o patrones
? ¿Cuáles son las
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 NFORMACIÓ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
nada ejecutable. ¿Qué hacer? pide que la lea y que busque errores, omisiones o ambigüedades. El
Durante el diseño, la calidad se evalúa por medio de la realiza- obje- tivo al comenzar la reunión es detectar todos los problemas del
ción de una serie de revisiones técnicas (RT). Las RT se estudian con pro- 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
nica en este momento. Una revisión técnica es una reunión celebrada horas. Al final de ella, el equipo de revisión determina si se requiere
por miembros del equipo de software. Por lo general, participan dos, de otras acciones por parte del productor a fin de que se apruebe el
tres o cuatro personas, en función del alcance de la información del producto como porción del modelo del diseño final.
diseño que se revisará. Cada persona tiene un papel: el líder de la

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

“La calidad no es algo calidad del software a los que se dio el acró nimo FURPS: funcionalidad, usabilidad, confiabili-
que se deje arriba de los dad, rendimiento y mantenibilidad. Los atributos de calidad FURPS representan el objetivo de
sujetos y obje- tos como todo diseñ o de software:
si fuera el remate de un
árbol de navidad.”
Robert Pirsig
2 Para sistemas pequeñ os, en ocasiones el diseñ o puede desarrollarse en forma lineal.
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.

[Link]
 188 PARTE DOS MODELADO

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

del programa, la generalidad de las funciones que se entregan y la seguridad general del
Los diseñadores del software tienden
a centrarse en el problema que se va sistema.
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
en cuenta. • La confiabilidad se evalú a con la medició n de la frecuencia y gravedad de las fallas, la
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

Cita: La evolució n del diseñ o del software es un proceso continuo que ya ha cubierto casi seis dé ca-
“Un diseñador sabe que das. Los primeros trabajos de diseñ o se concentraban en criterios para el desarrollo de progra-
alcanzó la perfección no mas modulares [Den73] y en métodos para mejorar estructuras de software con un enfoque de
cuando no hay nada por
arriba abajo [Wir71]. Los aspectos de procedimiento del diseñ o evolucionaron hacia una filoso-
agregar, sino cuando no
hay nada que quitar.” fía llamada programación estructurada [Dah72], [Mil72]. Los trabajos posteriores propusieron
Antoine de Saint- mé todos para traducir el flujo de datos [Ste74] o la estructura de éstos (por ejemplo, [Jac75],
Exupery [War74]) a una definició n de diseñ o. Los enfoques má s nuevos (por ejemplo, [Jac92], [Gam95])
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
métodos de diseño?
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.

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 189

Conjunto de tareas generales para el

diseño
1. Estudiar el modelo del dominio de la informa- C ONJUNTO DE TAREAS

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.3C O N C E P T O S DE D I S E Ñ 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:
“La abstracción es uno 8.3.1 Abstracción
de los modos
fundamentales con los Cuando se considera una solució n modular para cualquier problema, es posible plantear mu-
que los humanos chos niveles de abstracció n. En el má s elevado se enuncia una solució n en términos gruesos
luchamos con la con el uso del lenguaje del ambiente del problema. En niveles má s bajos de abstracció n se da
complejidad.”
Grady Booch
[Link]
la descripció n má s detallada de la solució n. La terminología orientada al problema se acopla
con la que se orienta a la implementació n, en un esfuerzo por enunciar la solució n. Por ú ltimo,

[Link]
190 PARTE DOS MODELADO

en el nivel de abstracció n má s bajo se plantea la solució n, de modo que pueda implementarse

directamente.
Cuando se desarrollan niveles de abstracció n distintos, se trabaja para crear abstracciones
CONSEJO tanto de procedimiento como de datos. Una abstracción de procedimiento es una secuencia de
Como diseñador, trabaje mucho para instrucciones que tienen una funció n específica y limitada. El nombre de la abstracció n de pro-
obtener abstracciones tanto de cedimiento implica estas funciones, pero se omiten detalles específicos. Un ejemplo de esto
procedimiento como de datos que sería la palabra abrir, en el caso de una puerta. Abrir implica una secuencia larga de pasos del
sirvan para el problema en cuestión. procedimiento (caminar hacia la puerta, llegar y tomar el picaporte, girar éste y jalar la puerta,
Será aún mejor si sirvieran para un
retroceder para que la puerta se abra, etcé tera).5
dominio completo de problemas.
Una abstracción de datos es un conjunto de éstos con nombre que describe a un objeto de
datos. En el contexto de la abstracció n de procedimiento abrir, puede definirse una abstracció n
de datos llamada puerta. Como cualquier objeto de datos, la abstracció n de datos para puerta
agruparía un conjunto de atributos que describirían la puerta (tipo, direcció n del abatimiento,
mecanismo de apertura, peso, dimensiones, etc.). Se concluye que la abstracció n de procedi-
miento abrir usaría informació n contenida en los atributos de la abstracció n de datos puerta.

8.3.2 Arquitectura

WebRef La arquitectura del software alude a “la estructura general de éste y a las formas en las que ésta
En la dirección da integridad conceptual a un sistema” [Sha95a]. En su forma más sencilla, la arquitectura es la
edu/ata/ata_init.html estructura de organizació n de los componentes de un programa (mó dulos), la forma en la que
hay un análisis profundo
é stos interactú an y la estructura de datos que utilizan. Sin embargo, en un sentido más amplio,
de la arquitectura del
software. los componentes se generalizan para que representen los elementos de un sistema grande y
sus interacciones.
Una meta del diseñ o del software es obtener una aproximació n arquitectó nica de un
sistema. É sta sirve como estructura a partir de la cual se realizan las actividades de diseñ o má s
detalla- das. Un conjunto de patrones arquitectó nicos permite que el ingeniero de software
resuelva problemas de diseñ o comunes.
Shaw y Garlan [Sha95a] describen un conjunto de propiedades que deben especificarse
Cita:
como parte del diseñ o de la arquitectura:
“Una arquitectura del
software es el producto Propiedades estructurales. Este aspecto de la representació n del diseñ o arquitectó nico define
del trabajo de desarrollo
los componentes de un sistema (mó dulos, objetos, filtros, etc.) y la manera en la que está n agrupados
que tiene la rentabili-
e interactú an unos con otros. Por ejemplo, los objetos se agrupan para que encapsulen tanto datos
dad más alta para una
inversión en cuanto a como el procedimiento que los manipula e interactú en invocando mé todos.
calidad, secuencia de Propiedades extrafuncionales. La descripció n del diseñ o arquitectó nico debe abordar la forma
actividades y costo.” en la que la arquitectura del diseñ o satisface los requerimientos de desempeñ o, capacidad, confiabi-
Len Bass et al.
lidad, seguridad y adaptabilidad, así como otras características del sistema.

Familias de sistemas relacionados. El diseñ o arquitectó nico debe basarse en patrones repeti-
bles que es comú n encontrar en el diseñ o de familias de sistemas similares. En esencia, el diseñ o debe
tener la capacidad de reutilizar bloques de construcció n arquitectó nica.

Dada la especificació n de estas propiedades, el diseñ o arquitectó nico se representa con el uso
de uno o má s de varios modelos diferentes [Gar95]. Los modelos estructurales representan la
CONSEJO
arquitectura como un conjunto organizado de componentes del programa. Los modelos de
No deje al azar la arquitectura. Si lo
hace, pasará el resto del proyecto marco aumentan el nivel de abstracció n del diseñ o, al tratar de identificar patrones de diseñ o
forzándola para que se ajuste al arquitec- tó nico repetibles que se encuentran en tipos similares de aplicaciones. Los modelos
diseño. Diseñe la arquitectura dinámicos abordan los aspectos estructurales de la arquitectura del programa e indican có mo
explícitamente. cambia la

5 Sin embargo, debe notarse que un conjunto de operaciones puede reemplazarse con otro, en tanto la funció n
que implica la abstracció n de procedimiento sea la misma. Por tanto, los pasos requeridos para implementar
abrir cambiarían mucho si la puerta fuera automá tica y tuviera un sensor.

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 191

estructura o la configuració n del sistema en funció n de eventos externos. Los modelos del
proceso se centran en el diseñ o del negocio o proceso té cnico al que debe dar acomodo el
sistema. Por ú ltimo, los modelos funcionales se usan para representar la jerarquía funcional de
un sistema.
Cita: Para representar estos modelos, se ha desarrollado cierto nú mero de lenguajes de
“Cada patrón describe un descripción arquitectónica (LDA) [Sha95b]. Aunque han sido propuestos muchos LDA
pro- blema que ocurre diferentes, la mayoría tiene mecanismos para describir los componentes del sistema y la
una y otra vez en manera en la que se conectan entre sí.
nuestro ambiente, por lo
Debe observarse que hay un debate acerca del papel que tiene la arquitectura en el diseñ o.
que describe el núcleo
de la solución de ese Algunos investigadores afirman que la obtenció n de la arquitectura del software debe
problema, en forma tal separarse del diseñ o y que ocurre entre las acciones de la ingeniería de requerimientos y las
que puede usarse ésta del diseñ o má s convencional. Otros piensan que la definició n de la arquitectura es parte
un millón de veces sin integral del pro- ceso de diseñ o. En el capítulo 9 se estudia la forma en la que se caracteriza la
repetir lo mismo ni una arquitectura del software y su papel en el diseñ o.
sola vez.”
Christopher
Alexander 8.3.3 Patrones
Brad Appleton define un patrón de diseño de la manera siguiente: “Es una mezcla con nombre
propio de puntos de vista que contienen la esencia de una solució n demostrada para un pro-
blema recurrente dentro de cierto contexto de necesidades en competencia” [App00]. Dicho de
otra manera, un patró n de diseñ o describe una estructura de diseñ o que resuelve un problema
particular del diseñ o dentro de un contexto específico y entre “fuerzas” que afectan la manera
en la que se aplica y en la que se utiliza dicho patró n.
El objetivo de cada patró n de diseñ o es proporcionar una descripció n que permita a un dise-
ñ ador determinar 1) si el patró n es aplicable al trabajo en cuestió n, 2) si puede volverse a usar
(con lo que se ahorra tiempo de diseñ o) y 3) si sirve como guía para desarrollar un patró n distinto
en funciones o estructura. En el capítulo 12 se estudian los patrones de diseñ o.

8.3.4 División de problemas

La división de problemas es un concepto de diseñ o que sugiere que cualquier problema
complejo puede manejarse con má s facilidad si se subdivide en elementos susceptibles de
resolverse u optimizarse de manera independiente. Un problema es una característica o
comportamiento que se especifica en el modelo de los requerimientos para el software. Al
separar un problema en sus piezas má s pequeñ as y por ello má s manejables, se requiere menos
esfuerzo y tiempo para resolverlo.
Si para dos problemas, p1 y p2, la complejidad que se percibe para p1 es mayor que la percibida
CONSEJO para p , entonces se concluye que el esfuerzo requerido para resolver p es mayor que el nece-
2 1

El argumento para separar los sario para resolver p2. Como caso general, este resultado es intuitivamente obvio. Lleva má s
problemas puede llevarse demasiado tiempo resolver un problema difícil.
lejos. Si se divide un problema en un
Tambié n se concluye que cuando se combinan dos problemas, con frecuencia la complejidad
número muy grande de problemas
percibida es mayor que la suma de la complejidad tomada por separado. Esto lleva a la
muy pequeños, será fácil resolver
cada uno de éstos, pero unificarlos estrategia de divide y vencerá s, pues es más fácil resolver un problema complejo si se divide en
en la solución (integración) será muy elementos manejables. Esto tiene implicaciones importantes en relació n con la modularidad
difícil. del software.
La divisió n de problemas se manifiesta en otros conceptos de diseñ o relacionados: modula-
ridad, aspectos, independencia de funcionamiento y mejora. Cada uno de é stos se estudiará en
las secciones siguientes.

8.3.5 Modularidad
La modularidad es la manifestació n má s comú n de la divisió n de problemas. El software se di-
vide en componentes con nombres distintos y abordables por separado, en ocasiones llamados

[Link]
módulos, que se
integran para
satisfacer los
requerimientos del
problema.

[Link]
192 PARTE DOS MODELADO

FIGURA 8.2
Modularidad y Costo total del software
costo del software
Costo de integración
Región de
costo mínimo

Costo del
M

Costo por módulo

Número de módulos

Se ha dicho que “la modularidad es el ú nico atributo del software que permite que un pro-
grama sea manejable en lo intelectual” [Mye78]. El software monolítico (un programa grande
compuesto de un solo mó dulo) no es fá cil de entender para un ingeniero de software. El
nú mero de trayectorias de control, alcance de referencia, nú mero de variables y complejidad
general haría que comprenderlo fuera casi imposible. En funció n de las circunstancias, el
diseñ o debe descomponerse en muchos mó dulos con la esperanza de que sea má s fá cil
entenderlos y, en consecuencia, reducir el costo requerido para elaborar el software.
Segú n el punto de vista de la divisió n de problemas, sería posible concluir que si el software
se dividiera en forma indefinida, el esfuerzo requerido para desarrollarlo ¡sería despreciable
por pequeñ o! Desafortunadamente, hay otras fuerzas que entran en juego y que hacen que esta
conclusió n sea (tristemente) invá lida. De acuerdo con la figura 8.2, el esfuerzo (costo) de desa-
rrollar un mó dulo individual de software disminuye conforme aumenta el nú mero total de mó -
dulos. Dado el mismo conjunto de requerimientos, tener má s mó dulos significa tamañ os indi-
viduales má s pequeñ os. Sin embargo, a medida que se incrementa el nú mero de mó dulos, el
esfuerzo (costo) asociado con su integració n también aumenta. Estas características llevan a
una curva de costo total como la que se muestra en la figura. Existe un nú mero, M, de mó dulos
que arrojarían el mínimo costo de desarrollo, pero no se dispone de las herramientas
necesarias para predecir M con exactitud.
Las curvas que aparecen en la figura 8.2 constituyen una guía ú til al considerar la modulari-
? ¿Cuál es el número
correcto de módulos dad. Deben hacerse mó dulos, pero con cuidado para permanecer en la cercanía de M. Debe
para un sistema dado? evitarse hacer pocos o muchos mó dulos. Pero, ¿có mo saber cuá l es la cercanía de M? ¿Cuá n
modular debe hacerse el software? Las respuestas a estas preguntas requieren la comprensió n
de otros conceptos de diseñ o que se analizan má s adelante en este capítulo.
Debe hacerse un diseñ o (y el programa resultante) con mó dulos, de manera que el
desarrollo pueda planearse con má s facilidad, que sea posible definir y desarrollar los
incrementos del software, que los cambios se realicen con má s facilidad, que las pruebas y la
depuració n se efectú en con mayor eficiencia y que el mantenimiento a largo plazo se lleve a
cabo sin efectos colaterales de importancia.

8.3.6 Ocultamiento de información

CLAVE El concepto de modularidad lleva a una pregunta fundamental: “¿Có mo descomponer una so-
El objetivo de ocultar la información lució n de software para obtener el mejor conjunto de mó dulos?” El principio del ocultamiento
es esconder los detalles de las de informació n sugiere que los mó dulos se “caractericen por decisiones de diseñ o que se ocul-
estructuras de datos y el
ten (cada una) de las demá s”. En otras palabras, deben especificarse y diseñ arse mó dulos, de
procesamiento tras una interfaz de
módulo. No es necesario que los forma que la informació n (algoritmos y datos) contenida en un mó dulo sea inaccesible para los
usuarios de éste los conozcan. que no necesiten de ella.

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 193

El ocultamiento implica que la modularidad efectiva se logra definiendo un conjunto de mó -

dulos independientes que intercambien só lo aquella informació n necesaria para lograr la fun-
ció n del software. La abstracció n ayuda a definir las entidades de procedimiento (o informativas)
que constituyen el software. El ocultamiento define y hace cumplir las restricciones de acceso
tanto a los detalles de procedimiento como a cualquier estructura de datos local que utilice el
mó dulo [Ros75].
El uso del ocultamiento de informació n como criterio de diseñ o para los sistemas modulares
proporciona los má ximos beneficios cuando se requiere hacer modificaciones durante las prue-
bas, y má s adelante, al dar mantenimiento al software. Debido a que la mayoría de los datos y
detalles del procedimiento quedan ocultos para otras partes del software, es menos probable
que los errores inadvertidos introducidos durante la modificació n se propaguen a distintos sitios
dentro del software.

8.3.7 Independencia funcional

El concepto de independencia funcional es resultado directo de la separació n de problemas y
de los conceptos de abstracció n y ocultamiento de informació n. En escritos cruciales sobre el
di- señ o de software, Wirth [Wir71] y Parnas [Par72] mencionan té cnicas de mejora que
promueven la independencia modular. Los trabajos posteriores de Stevens, Myers y
Constantine [Ste74] dan solidez al concepto.
La independencia funcional se logra desarrollando mó dulos con funciones “miopes” que
tengan “aversió n” a la interacció n excesiva con otros mó dulos. Dicho de otro modo, debe dise-
ñ arse software de manera que cada mó dulo resuelva un subconjunto específico de
requerimien- tos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura
del programa. Es ló gico preguntar por qué es importante la independencia.
El software con modularidad eficaz, es decir, con mó dulos independientes, es má s fá cil de
? ¿Por qué debe tratarse
de crear módulos desarrollar porque su funció n se subdivide y las interfaces se simplifican (cuando el desarrollo
independientes? es efectuado por un equipo hay que considerar las ramificaciones). Los mó dulos
independientes son má s fá ciles de mantener (y probar) debido a que los efectos secundarios
causados por el diseñ o o por la modificació n del có digo son limitados, se reduce la propagació n
del error y es posible obtener mó dulos reutilizables. En resumen, la independencia funcional es
una clave para el buen diseñ o y éste es la clave de la calidad del software.
La independencia se evalú a con el uso de dos criterios cualitativos: la cohesió n y el acopla-
miento. La cohesión es un indicador de la fortaleza relativa funcional de un mó dulo. El acopla-
CLAVE miento lo es de la independencia relativa entre mó dulos.
La cohesión es un indicador La cohesió n es una extensió n natural del concepto de ocultamiento de informació n descrito
cualitativo del grado en el que un
en la secció n 8.3.6. Un mó dulo cohesivo ejecuta una sola tarea, por lo que requiere interactuar
módulo se centra en hacer una sola
cosa. poco con otros componentes en otras partes del programa. En pocas palabras, un mó dulo co-
hesivo debe (idealmente) hacer só lo una cosa. Aunque siempre debe tratarse de lograr mucha
cohesió n (por ejemplo, una sola tarea), con frecuencia es necesario y aconsejable hacer que
un componente de software realice funciones mú ltiples. Sin embargo, para lograr un buen di-
señ o hay que evitar los componentes “esquizofré nicos” (mó dulos que llevan a cabo funciones
no relacionadas).
El acoplamiento es una indicació n de la interconexió n entre mó dulos en una estructura de
software, y depende de la complejidad de la interfaz entre mó dulos, del grado en el que se
CLAVE entra o se hace referencia a un mó dulo y de qué datos pasan a travé s de la interfaz. En el diseñ o
El acoplamiento es un indicador
de software, debe buscarse el mínimo acoplamiento posible. La conectividad simple entre
cualitativo del grado en el que un
módulo está conectado con otros y mó dulos da como resultado un software que es má s fácil de entender y menos propenso al
con el mundo exterior. “efecto de oleaje” [Ste74], ocasionado cuando ocurren errores en un sitio y se propagan por
todo el sis- tema.

[Link]
194 PARTE DOS MODELADO

8.3.8 Refinamiento
El refinamiento stepwise es una estrategia de diseñ o propuesta originalmente por Niklaus
CONSEJO Wirth [Wir71]. Un programa se elabora por medio del refinamiento sucesivo de los detalles del
Existe la tendencia a pasar de proce- dimiento. Se desarrolla una jerarquía con la descomposició n de un enunciado
inmediato a los detalles e ignorar los macroscó pico de la funció n (abstracció n del procedimiento) en forma escalonada hasta llegar a
pasos del refinamiento. Esto genera los comandos del lenguaje de programació n.
errores y hace que el diseño sea En realidad, el refinamiento es un proceso de elaboración. Se comienza con un enunciado de
mucho más difícil de revisar. Realice
la funció n (o descripció n de la informació n), definida en un nivel de abstracció n alto. Es decir,
refinamiento stepwise.
el enunciado describe la funció n o informació n de manera conceptual, pero no dice nada sobre
los trabajos internos de la funció n o de la estructura interna de la informació n. Despué s se tra-
baja sobre el enunciado original, dando má s y má s detalles conforme tiene lugar el
refinamiento (elaboració n) sucesivo.
La abstracció n y el refinamiento son conceptos complementarios. La primera permite espe-
cificar internamente el procedimiento y los datos, pero elimina la necesidad de que los “extra-
ñ os” conozcan los detalles de bajo nivel. El refinamiento ayuda a revelar estos detalles a
medida que avanza el diseñ o. Ambos conceptos permiten crear un modelo completo del diseñ o
con- forme éste evoluciona.

8.3.9 Aspectos

Cita: Conforme tiene lugar el aná lisis de los requerimientos, surge un conjunto de “preocupaciones”
“Es difícil leer un libro que “incluyen requerimientos, casos de uso, características, estructuras de datos, calidad del
sobre los principios de la servicio, variantes, fronteras de las propiedades intelectuales, colaboraciones, patrones y con-
magia sin echar una tratos” [AOS07]. Idealmente, un modelo de requerimientos se organiza de manera que permita
mirada de vez en cuando aislar cada preocupació n (requerimiento) a fin de considerarla en forma independiente. Sin
a la portada para
embargo, en la prá ctica, algunas de estas preocupaciones abarcan todo el sistema y no es fá cil
asegurarse de que no es
un texto sobre diseño de dividirlas en compartimientos.
software.” Cuando comienza el diseñ o, los requerimientos son refinados en una representació n de di-
Bruce Tognazzini señ o modular. Considere dos requerimientos, A y B. El A interfiere con el B “si se ha elegido una
descomposició n [refinamiento] en la que B no puede satisfacerse sin tomar en cuenta a A”
[Ros04].
Por ejemplo, considere dos requerimientos para la webapp [Link]. El
requerimiento A se describe con el caso de uso AVC-DVC analizado en el capítulo 6. Un refina-
miento del diseñ o se centraría en aquellos mó dulos que permitieran que usuarios registrados
accedieran al video de cá maras situadas en un espacio. El requerimiento B es de seguridad y
establece que un usuario registrado debe ser validado antes de que use
CLAVE CasaSeguraAsegurada. com. Este requerimiento es aplicable a todas las funciones
Una preocupación de interferencia es
alguna característica del sistema que disponibles para los usuarios regis- trados de CasaSegura. Cuando ocurre el refinamiento del
se aplica a través de muchos diseñ o, A* es una representació n del diseñ o para el requerimiento A, y B* es otra para el
requerimientos distintos. requerimiento B. Por tanto, A* y B* son re- presentaciones de las preocupaciones, y B*
interfiere con A*.
Un aspecto es una representació n de una preocupació n de interferencia. Entonces, la repre-
sentació n del diseñ o, B*, del requerimiento un usuario registrado debe ser validado antes de que
use [Link] es un aspecto de la webapp CasaSegura. Es importante identi-
ficar aspectos, de modo que el diseñ o les pueda dar acomodo conforme sucede el refinamiento
y la divisió n en mó dulos. En un contexto ideal, un aspecto se implementa como mó dulo
(compo- nente) separado y no como fragmentos de software “dispersos” o “regados” en
muchos compo- nentes [Ban06]. Para lograr esto, la arquitectura del diseñ o debe apoyar un
mecanismo para definir aspecto: un mó dulo que permita implementar la preocupació n en
todas aquellas con las que interfiera.

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 195

8.3.10 Rediseño
WebRef Una actividad de diseñ o importante que se sugiere para muchos mé todos á giles (véase el capí-
En la dirección tulo 3) es el rediseño, té cnica de reorganizació n que simplifica el diseñ o (o có digo) de un com-
[Link]. com, ponente sin cambiar su funció n o comportamiento. Fowler [Fow00] define el rediseñ o del
se encuentran recursos
excelentes para el modo siguiente: “Es el proceso de cambiar un sistema de software en forma tal que no se altera
rediseño. el comportamiento externo del có digo [diseñ o], pero sí se mejora su estructura interna.”
WebRef Cuando se rediseñ a el software, se examina el diseñ o existente en busca de redundancias,
En factoringPatterns, elementos de diseñ o no utilizados, algoritmos ineficientes o innecesarios, estructuras de datos
se encuentran varios
mal construidas o inapropiadas y cualquier otra falla del diseñ o que pueda corregirse para ob-
patrones de rediseño.
tener un diseñ o mejor. Por ejemplo, una primera iteració n de diseñ o tal vez genere un compo-
nente con poca cohesió n (realiza tres funciones que tienen poca relació n entre sí). Despué s de
un aná lisis cuidadoso, se decide rediseñ ar el componente en tres componentes separados, cada
uno con mucha cohesió n. El resultado será un software má s fá cil de integrar, de probar y de
mantener.

C ASA S EGURA
Conceptos de disefio
La escena: Cubículo de Vinod, cuando comienza
Jamie: He visto tu trabajo, Shak, y aplicas de manera natural
el modelado del diseño.
mucho de lo que se habló… ésa es la razón por la que
Participantes: Vinod, Jamie y Ed, miembros del equipo de inge- funcionan bien tus diseños y códigos.
niería del software de CasaSegura. También Shakira, nueva inte- Shakira (sonríe): Bueno, siempre trato de realizar la partición
grante del equipo. del código, hacer que se aboque a una cosa, construir interfaces
La conversación: senci- llas y restringidas, reutilizar código siempre que se pueda…
esa clase de cosas.
[Los cuatro miembros del equipo acaban de regresar de un semina-
rio matutino llamado “Aplicación de los conceptos básicos del dise- Ed: Modularidad, independencia funcional, ocultamiento, patro-
ño”, ofrecido por una profesora local de ciencias de la computación.] nes… ya veo.
Jamie: Todavía recuerdo el primer curso de programación que
Vinod: ¿Les dejó algo el seminario?
tomé… nos enseñaron a refinar el código en forma iterativa.
Ed: Sabíamos la mayor parte de lo que trató, pero creo que no fue
Vinod: Lo mismo puede aplicarse al diseño, ya sabes.
mala idea escucharlo de nuevo.
Vinod: Los únicos conceptos que no había escuchado antes fueron
Jamie: Cuando estudiaba la carrera de ciencias de la computación, los de “aspectos” y “rediseño”.
nunca entendí, en realidad, por qué era tan importante, como
Shakira: Eso se utiliza en programación extrema.
decían, ocultar información.
Ed: Sí. No es muy diferente del refinamiento, sólo que lo haces una
Vinod: Por… la línea de base… es una técnica para reducir la
vez terminado el diseño o código. Si me preguntan, diré que es algo
pro- pagación del error en un programa. En realidad, la
así como una etapa de optimización del software.
independencia funcional hace lo mismo.
Jamie: Volvamos al diseño de CasaSegura. Pienso que mientras
Shakira: Yo no estudié una carrera de computación, así que desarrollemos el modelo de su diseño, debemos poner estos concep-
mucho de lo que dijo el instructor fue nuevo para mí. Soy capaz de tos en nuestra lista de revisión.
generar buen código y rápido. No veo por qué es tan
Vinod: Estoy de acuerdo. Pero es importante que todos nos com-
importante todo eso.
prometamos a pensar en ellos al hacer el diseño.

8.3.11 Conceptos de diseño orientados a objeto

El paradigma de la orientació n a objeto (OO) se utiliza mucho en la ingeniería de software mo-
derna. El apéndice 2 está pensado para aquellos lectores que no esté n familiarizados con los
conceptos de diseñ o OO, tales como clases y objetos, herencia, mensajes y polimorfismo, entre
otros.

[Link]
196 PARTE DOS MODELADO

8.3.12 Clases de diseño

El modelo de requerimientos define un conjunto de clases de aná lisis (capítulo 6). Cada una
describe algú n elemento del dominio del problema y se centra en aspectos de é ste que son vi-
sibles para el usuario. El nivel de abstracció n de una clase de aná lisis es relativamente alto.
Conforme el diseñ o evoluciona, se definirá un conjunto de clases de diseño que refinan las
clases de aná lisis, dando detalles del diseñ o que permitirá n que las clases se implementen y
generen una infraestructura para el software que apoye la solució n de negocios. Pueden desa-
rrollarse cinco tipos diferentes de clases de diseñ o, cada una de las cuales representa una capa
distinta de la arquitectura del diseñ o [Amb01]:

Clases de usuario de la interfaz. Definen todas las abstracciones necesarias para la inte-
? ¿Qué tipos de clases •

crea el diseñador? racció n humano-computadora (IHC). En muchos casos, la IHC ocurre dentro del
contexto de una metáfora (por ejemplo, cuaderno de notas, formato de orden, máquina
de fax, etc.) y las clases del diseñ o para la interfaz son representaciones visuales de los
elementos de la metá fora.

• Clases del dominio de negocios. Es frecuente que sean refinamientos de las clases de
aná lisis definidas antes. Las clases identifican los atributos y servicios (mé todos) que se
requieren para implementar algunos elementos del dominio de negocios.

• Clases de proceso. Implantan abstracciones de negocios de bajo nivel que se requieren

para administrar por completo las clases de dominio de negocios.

• Clases persistentes. Representan almacenamientos de datos (por ejemplo, una base de

datos) que persistirá n má s allá de la ejecució n del software.

• Clases de sistemas. Implantan las funciones de administració n y control del software que
permiten que el sistema opere y se comunique dentro de su ambiente de computació n y
con el mundo exterior.

A medida que se forma la arquitectura, el nivel de abstracció n se reduce cuando cada clase de
aná lisis se transforma en una representació n del diseñ o. Es decir, las clases de aná lisis repre-
sentan objetos de datos (y servicios asociados que se aplican a éstos) que usan la terminología
del dominio del negocio. Las clases de diseñ o presentan muchos má s detalles té cnicos como
guía para su implementació n.
Arlow y Neustadt [Arl02] sugieren que se revise cada clase de diseñ o para asegurar que esté
“bien formada”. Definen cuatro características de las clases de diseñ o bien formadas:

Completa y suficiente. Una clase de diseñ o debe ser el encapsulado total de todos los
? ¿Qué es una clase de
diseño “bien formada”? atributos y mé todos que sea razonable esperar (con base en una interpretació n comprensi-
ble del nombre de la clase) y que existan para la clase. Por ejemplo, la clase Escena defi-
nida para el software de la edició n de video será completa só lo si contiene todos los atribu-
tos y mé todos que se asocian de manera razonable con la creació n de una escena de video.
La suficiencia asegura que la clase de diseñ o contiene só lo los mé todos que bastan para lo-
grar el objetivo de la clase, ni má s ni menos.
Primitivismo. Los métodos asociados con una clase de diseñ o deben centrarse en el cum-
plimiento de un servicio para la clase. Una vez implementado el servicio con un mé todo, la
clase no debe proveer otro modo de hacer lo mismo. Por ejemplo, la clase VideoClip para
el software de la edició n de video tal vez tenga los atributos punto-inicial y punto-final que in-
diquen los puntos de inicio y fin del corto (observe que el video original cargado en el sis-
tema puede ser má s extenso que el corto utilizado). Los métodos EstablecerPuntoInicial ( ) y
EstablecerPuntoFinal ( ) proporcionan los ú nicos medios para establecer los puntos de co-
mienzo y terminació n del corto.
Mucha cohesión. Una clase de diseñ o cohesiva tiene un conjunto pequeñ o y centrado de
responsabilidades; para implementarlas emplea atributos y mé todos de objetivo ú nico. Por

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 197

ejemplo, la clase VideoClip quizá contenga un conjunto de mé todos para editar el corto de
video. La cohesió n se mantiene en tanto cada método se centre só lo en los atributos aso-
ciados con el corto.
Poco acoplamiento. Dentro del modelo de diseñ o, es necesario que las clases de diseñ o
colaboren una con otra. Sin embargo, la colaboració n debe mantenerse en un mínimo
aceptable. Si un modelo de diseñ o está muy acoplado (todas las clases de diseñ o colaboran
con todas las demá s), el sistema es difícil de implementar, probar y mantener con el paso
del tiempo. En general, las clases de diseñ o dentro de un subsistema deben tener só lo un
conocimiento limitado de otras clases. Esta restricció n se llama Ley de Demeter [Lie03] y su-
giere que un mé todo só lo debe enviar mensajes a mé todos que está n en clases vecinas.6

C ASA S EGURA
Refinamiento de una clase de análisis en una clase de disefio
La escena: El cubículo de Ed, cuando comienza
Vinod: La clase de análisis sólo mostraba cosas en el dominio del
el modelado del diseño.
problema, bueno, en la pantalla de la computadora, visibles para el
Participantes: Vinod y Ed, miembros del equipo de ingeniería de usuario final, ¿de acuerdo?
software de CasaSegura.
Ed: Sí, pero para la clase de diseño PlanodelaPlanta, he tenido
La conversación: que agregar algunas cosas específicas para la implantación. Necesi-
[Ed está trabajando en la clase PlanodelaPlanta (véanse el té mostrar que PlanodelaPlanta es un agregado de segmentos
recuadro en la sección 6.5.3 y la figura 6.10) y la ha refinado —de ahí la clase Segmento— y que la clase Segmento está
para el modelo del diseño.] compuesta de listas para segmentos de pared, ventanas, puertas,
Ed: Entonces recuerdas la clase PlanodelaPlanta, ¿verdad? Se etc. La clase Cámara colabora con PlanodelaPlanta y, obvia-
usa como parte de las funciones de vigilancia y administración de la mente, hay muchas cámaras en el piso.
casa. Vinod: Ah… veamos la ilustración de esta nueva clase de diseño,
Vinod (afirma con la cabeza): Sí, recuerdo que la usamos PlanodelaPlanta.
como parte de nuestros análisis CRC para la administración de la [Ed muestra a Vinod el diagrama que aparece en la figura 8.3.]
casa.
Vinod: Bien, ya veo lo que tratas de hacer. Esto te permite modifi-
Ed: Así es. De cualquier modo, la estoy mejorando para el diseño.
car el plano de la planta con facilidad porque los nuevos temas se
Quiero mostrarte cómo implantaremos en realidad la clase Plano-
agregan, o eliminan de la lista (el agregado), sin problemas.
delaPlanta. Mi idea es implementarla como un conjunto de listas
ligadas [una estructura de datos específica] de modo que… tuve que Ed (asiente): Sí, creo que funcionará.
refinar la clase de análisis PlanodelaPlanta (véase la figura Vinod: También yo.
6.10) y, en verdad, simplificarla.

8.4E L M O D E L O DEL D I S E Ñ O

El modelo del diseñ o puede verse en dos dimensiones distintas, como se ilustra en la figura 8.4.
La dimensión del proceso indica la evolució n del modelo del diseñ o conforme se ejecutan las
tareas de éste como parte del proceso del software. La dimensión de la abstracción representa
el nivel de detalle a medida que cada elemento del modelo de análisis se transforma en un equi-
valente de diseñ o y luego se mejora en forma iterativa. En relació n con la figura 8.4, la línea
punteada indica la frontera entre los modelos de análisis y de diseñ o. En ciertos casos, es posi-
ble hacer una distinció n clara entre ambos modelos. En otros, el modelo de aná lisis se mezcla
poco a poco con el de diseñ o y la distinció n es menos obvia.
Los elementos del modelo de diseñ o usan muchos de los diagramas UML 7 que se utilizaron
en el modelo del aná lisis. La diferencia es que estos diagramas se refinan y elaboran como
parte

6 Una manera menos formal de la Ley de Demeter es: “cada unidad debe hablar só lo con sus amigas: no hablar
con extrañ os”.
7 En el apéndice 1 se encuentra un mé todo de enseñ anza sobre los conceptos y notació n bá sica del UML.

[Link]
198 PARTE DOS MODELADO

FIGURA 8.3
Clase de diseño PlanodelaPlanta
para tipo Cámara
PlanodelaPlanta
DimensionesExteriores
y composición 1 * tipo
del agregado AgregarCámara( ) identificación
para ella (véase el AgregarPared( ) VistaGeneral
análisis en el AgregarVentana( ) ÁngulodeVisión
recuadro) EliminarSegmento( ) PrepararAcercamiento
Dibujar( )
1
*
Segmento
ComenzarCoordenada
TerminarCoordenada
ObtenerTipo( )
Dibujar( )

SegmentodePared Ventana

del diseñ o; se dan má s detalles específicos de la implantació n y se hace é nfasis en la estructura

y en el estilo arquitectó nico, en los componentes que residen dentro de la arquitectura y en las
CLAVE interfaces entre los componentes y el mundo exterior.
El modelo de diseño tiene cuatro No obstante, debe observarse que los elementos del modelo indicados a lo largo del eje ho-
elementos principales: datos,
rizontal no siempre se desarrollan en forma secuencial. En la mayoría de los casos, el diseñ o
arquitectura, componentes e interfaz.
preliminar de la arquitectura establece la etapa y va seguido del diseñ o de la interfaz y del dise-

FIGURA 8.4Dimensiones del modelo de diseño

Alto

Modelo del análisis

Diagramas de clase Paquetes
Diagramas de clase Paquetes de análisis Modelos CRC
de análisis Modelos CRC Casos de uso - texto Diagramas de colaboración Requerimientos:
Diagramas de colaboración Diagramas de actividades Diagramas de flujo de datos Restricciones
Diagramas de flujo de datos Casos de uso - diagramas Narrativas del procesamiento Interoperabilidad
Diagramas de flujo del control Diagramas de canal Diagramas de estado Objetivos y
Narrativas del procesamiento Diagramas de Diagramas de secuencia configuración
Dimensión de la

colaboración Diagramas
de estado Diagramas de
secuencia
Realizaciones de
la clase de diseño
Subsistemas Diseño de la interfaz Diagramas de componentes
Realizaciones de la clase de
Diagramas de técnica Clases de diseño Diagramas
diseño
colaboración Diseño de la de actividades Diagramas de
Subsistemas
Modelo del diseño navegación secuencia
Diagramas de colaboración
Diseño de la interfaz
Refinamientos a: Diagramas de componentes
gráfica de usuario
Realizaciones de Refinamientos a: Clases de diseño
la clase de diseño Subsistemas Diagramas de componentes Diagramas de actividades
Diagramas de Clases de diseño Diagramas Diagramas de secuencia
Bajo
colaboración de actividad Diagramas de
Elementos de secuencia
Diagramas de despliegue
arquitectura Elementos Elementos en el nivel Elementos en el nivel
de la interfaz de componentes del despliegue
Dimensión del proceso

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 199

Cita: ñ o del nivel de los componentes, los cuales con frecuencia ocurren en paralelo. El modelo de
“Las preguntas acerca de despliegue por lo general se retrasa hasta que el diseñ o haya sido desarrollado por completo.
si el diseño es necesario Es posible aplicar patrones de diseñ o en cualquier punto de este proceso (vé ase el capítulo
o digno de pagarse están 12). Estos patrones permiten aplicar el conocimiento del diseñ o a problemas específicos del
más allá de la discusión:
dominio que han sido encontrados y resueltos por otras personas.
el diseño es inevita- ble.
La alternativa al buen
diseño es el mal diseño, 8.4.1 Elementos del diseño de datos
no la falta de diseño.”
Igual que otras actividades de la ingeniería de software, el diseñ o de datos (en ocasiones deno-
Douglas Martin
minado arquitectura de datos) crea un modelo de datos o informació n que se representa en un
nivel de abstracció n elevado (el punto de vista del usuario de los datos). Este modelo de los
datos se refina despué s en forma progresiva hacia representaciones má s específicas de la im-
plementació n que puedan ser procesadas por el sistema basado en computadora. En muchas
aplicaciones de software, la arquitectura de los datos tendrá una influencia profunda en la ar-
quitectura del software que debe procesarlo.
La estructura de los datos siempre ha sido parte importante del diseñ o de software. En el
nivel de componentes del programa, del diseñ o de las estructuras de datos y de los algoritmos
CLAVE requeridos para manipularlos, es esencial la creació n de aplicaciones de alta calidad. En el nivel
En el nivel de la arquitectura
de la aplicació n, la traducció n de un modelo de datos (obtenido como parte de la ingeniería de
(aplicación), el diseño de los datos
se centra en archivos o bases de los requerimientos) a una base de datos es crucial para lograr los objetivos de negocios de un
datos; en el de los componentes, el sistema. En el nivel de negocios, el conjunto de informació n almacenada en bases de datos
diseño de datos considera las incompatibles y reorganizados en un “data warehouse” permite la minería de datos o descubri-
estructuras de datos que se requieren miento de conocimiento que tiene un efecto en el é xito del negocio en sí. En cada caso, el diseñ o
para implementar objetos de datos
de los datos juega un papel importante. El diseñ o de datos se estudia con má s detalle en el ca-
locales.
pítulo 9.

8.4.2 Elementos del diseño arquitectónico

Cita: El diseño de la arquitectura del software es el equivalente del plano de una casa. É ste ilustra la
“Puede usarse una goma distribució n general de las habitaciones, su tamañ o, forma y relaciones entre ellas, así como las
en la mesa de dibujo o puertas y ventanas que permiten el movimiento entre los cuartos. El plano da una visió n gene-
un marro en el sitio ral de la casa. Los elementos del diseñ o de la arquitectura dan la visió n general del software.
construido.”
El modelo arquitectó nico [Sha96] proviene de tres fuentes: 1) informació n sobre el dominio
Frank Lloyd Wright
de la aplicació n del software que se va a elaborar, 2) los elementos específicos del modelo de
requerimientos, tales como diagramas de flujo de datos o clases de análisis, sus relaciones y
colaboraciones para el problema en cuestió n y 3) la disponibilidad de estilos arquitectó nicos
(capítulo 9) y sus patrones (capítulo 12).
Por lo general, el elemento de diseñ o arquitectó nico se ilustra como un conjunto de sistemas
interconectados, con frecuencia obtenidos de paquetes de aná lisis dentro del modelo de reque-
rimientos. Cada subsistema puede tener su propia arquitectura (por ejemplo, la interfaz grá fica
de usuario puede estar estructurada de acuerdo con un estilo de arquitectura preexistente para
Cita: interfaces de usuario). En el capítulo 9 se presentan té cnicas para obtener elementos
“El público está más
familiariza- do con el mal específicos del modelo arquitectó nico.
diseño que con el buen
diseño. En realidad, está 8.4.3 Elementos de diseño de la interfaz
condicionado para que
prefiera el mal diseño El diseñ o de la interfaz para el software es análogo al conjunto de trazos (y especificaciones)
porque es con el que detalladas para las puertas, ventanas e instalaciones de una casa. Tales dibujos ilustran el ta-
vive. Lo nuevo le parece mañ o y forma de puertas y ventanas, la manera en la que operan, la forma en la que llegan las
amenazador; lo viejo le instalaciones de servicios (agua, electricidad, gas, telé fono, etc.) a la vivienda y se distribuyen
da seguridad.”
entre las habitaciones indicadas en el plano. Indican dó nde está el timbre de la puerta, si se
Paul Rand
usará un intercomunicador para anunciar la presencia de un visitante y có mo se va a instalar el

[Link]
200 PARTE DOS MODELADO

sistema de seguridad. En esencia, los planos (y especificaciones) detallados para las puertas,
ventanas e instalaciones externas nos dicen có mo fluyen las cosas y la informació n hacia
dentro y fuera de la casa y dentro de los cuartos que forman parte del plano. Los elementos de
diseñ o de la interfaz del software permiten que la informació n fluya hacia dentro y afuera del
sistema, y có mo está n comunicados los componentes que son parte de la arquitectura.
Hay tres elementos importantes del diseñ o de la interfaz: 1) la interfaz de usuario (IU), 2)
las interfaces externas que tienen que ver con otros sistemas, dispositivos, redes y otros
CLAVE produc- tores o consumidores de informació n y 3) interfaces internas que involucran a los
Hay tres partes para el elemento de
distintos componentes del diseñ o. Estos elementos del diseñ o de la interfaz permiten que el
diseño de la interfaz: la interfaz de
usuario, las interfaces dirigidas hacia software se comunique externamente y permita la comunicació n y colaboració n internas entre
el sistema externo a la aplicación y los com- ponentes que constituyen la arquitectura del software.
las interfaces orientadas hacia los El diseñ o de la IU (denominada cada vez con má s frecuencia diseño de la usabilidad) es una
componentes dentro de ésta. acció n principal de la ingeniería de software y se estudia con detalle en el capítulo 11. El diseñ o
de la usabilidad incorpora elementos esté ticos (como distribució n, color, grá ficos, mecanismos
de interacció n, etc.), elementos ergonó micos (por ejemplo, distribució n y colocació n de la
infor- mació n, metá foras, navegació n por la IU, etc.) y elementos té cnicos (como patrones de la
IU y patrones reutilizables). En general, la IU es un subsistema ú nico dentro de la arquitectura
gene- ral de la aplicació n.
El diseñ o de interfaces externas requiere informació n definitiva sobre la entidad a la que se
envía informació n o desde la que se recibe. En todo caso, esta informació n debe recabarse du-
rante la ingeniería de requerimientos (capítulo 5) y verificarse una vez que comienza el diseñ o
de la interfaz.8 El diseñ o de interfaces externas debe incorporar la revisió n en busca de errores
y (cuando sea necesario) las medidas de seguridad apropiadas.
El diseñ o de las interfaces internas se relaciona de cerca con el diseñ o de componentes
(vé ase el capítulo 10). Las realizaciones del diseñ o de las clases de aná lisis representan todas
las operaciones y esquemas de mensajería que se requieren para permitir la comunicació n
y colaboració n entre las operaciones en distintas clases. Cada mensaje debe diseñ arse para que
contenga la informació n que se requiere transmitir y los requerimientos específicos de la fun-
ció n de la operació n que se ha solicitado. Si para el diseñ o se elige el enfoque clá sico de un
proceso de entrada-salida, la interfaz de cada componente del software se diseñ a con base en
las representaciones del flujo de datos y en la funcionalidad descrita en una narrativa de proce-
samiento.
WebRef En ciertos casos, una interfaz se modela en forma muy parecida a la de una clase. En el UML
En la dirección se se define interfaz del modo siguiente [OMG03a]: “Es un especificador para las operaciones visi-
encuentra información bles desde el exterior [pú blicas] de una clase, un componente u otro clasificador (incluso sub-
sumamente valiosa sobre
el diseño de la IU. sistemas), sin especificar su estructura interna.” En pocas palabras, una interfaz es un conjunto
de operaciones que describen alguna parte del comportamiento de una clase y dan acceso a
aquéllas.
Por ejemplo, la funció n de seguridad de CasaSegura hace uso del panel de control que
Cita: permite que el propietario controle ciertos aspectos de la funció n de seguridad. En una versió n
“Un error común que
avanzada del sistema, las funciones del panel de control podrían implementarse a travé s de un
comete la gente cuando
trata de diseñar algo a PDA ina- lá mbrico o un telé fono mó vil.
prueba de tontos es La clase PaneldeControl (vé ase la figura 8.5) proporciona el comportamiento asociado con
sub- estimar la un teclado, por lo que debe implementar las operaciones LeerTeclazo ( ) y DecodificarTecla ( ).
ingenuidad de los Si estas operaciones se van a dar a otras clases (en este caso, PDAInalámbrico y TeléfonoMó-
completamente tontos.”
vil), es ú til definir una interfaz como la de la figura. La interfaz, llamada Teclado, se ilustra
Douglas Adams
como un estereotipo <<interfaz>> o como un círculo pequeñ o con leyenda y conectado a la
clase

8 Las características de la interfaz pueden cambiar con el tiempo. Por tanto, un diseñ ador debe cerciorarse de que
la especificació n para ella sea exacta y completa.

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 201

FIGURA 8.5
TeléfonoMóvil
Representación
de la interfaz PDAInalámbric
para o
PaneldeControl

PaneldeControl
PantalladeCristalLíquido
IndicadoresLuminosos Teclado
CaracterísticasdeTeclado
Bocina
InterfazInalámbrica
LeerTeclazo( )
DecodificarTecla( )
DesplegarEstado( ) Teclado
EncenderIndicadoresLuminosos( ) <<interfaz>>
EnviarMensajedeControl( ) LeerTeclazo( )
DecodificarTecla( )

con una línea. La interfaz se define sin atributos y con el conjunto de operaciones que sean
necesarias para lograr el comportamiento de un teclado.
La línea punteada con un triá ngulo abierto en su extremo (en la figura 8.5) indica que la
clase PaneldeControl proporciona las operaciones de Teclado como parte de su
comportamiento. En UML, esto se caracteriza como una realización. Es decir, parte del
comportamiento de Pa- neldeControl se implementará con la realizació n de las operaciones
de Teclado. É stas se dará n a otras clases que accedan a la interfaz.

8.4.4 Elementos del diseño en el nivel de los componentes

El diseñ o en el nivel de los componentes del software es el equivalente de los planos (y especi-
ficaciones) detallados de cada habitació n de la casa. Estos dibujos ilustran el cableado y la
plomería de cada cuarto, la ubicació n de cajas eléctricas e interruptores, grifos, coladeras, rega-
deras, tinas, drenajes, gabinetes y closets. Tambié n describen el tipo de piso que se va a usar,
las molduras que se van a aplicar y todos los detalles asociados con una habitació n. El diseñ o
de componentes para el software describe por completo los detalles internos de cada compo-
nente. Para lograrlo, este diseñ o define estructuras de datos para todos los objetos de datos
locales y detalles algorítmicos para todo el procesamiento que tiene lugar dentro de un compo-
Cita: nente, así como la interfaz que permite el acceso a todas las operaciones de los componentes
“Los detalles no son los (comportamientos).
detalles. Constituyen el En el contexto de la ingeniería de software orientada a objeto, un componente se representa
diseño.” en forma de diagrama UML, como se ilustra en la figura 8.6. En é sta, aparece un componente
Charles Eames
llamado AdministracióndeSensor (parte de la funció n de seguridad de CasaSegura). Una fle-
cha punteada conecta al componente con una clase llamada Sensor, a él asignada. El compo-

FIGURA 8.6
Diagrama de
componente UML
AdministracióndeSensor Sensor

[Link]
202 PARTE DOS MODELADO

nente AdministracióndeSensor lleva a cabo funciones asociadas con los sensores de CasaSe-
gura, incluso su vigilancia y configuració n. En el capítulo 10 se analizan má s los diagramas de
componentes.
Los detalles del diseñ o de un componente se modelan en muchos niveles de abstracció n
diferentes. Se utiliza un diagrama de actividades UML para representar la ló gica del procesa-
miento. El flujo detallado del procedimiento para un componente se representa con seudocó -
digo (representació n que se parece a un lenguaje de programació n y que se describe en el capí-
tulo 10) o con alguna otra forma diagramá tica (como un diagrama de flujo o de cajas). La
estructura algorítmica sigue las reglas establecidas para la programació n estructurada (por
ejemplo, un conjunto de construcciones restringidas de procedimiento). Las estructuras de da-
tos, seleccionadas con base en la naturaleza de los objetos de datos que se van a procesar, por
lo general se modelan con el empleo de seudocó digo del lenguaje de programació n que se
usará para la implementació n.

8.4.5 Elementos del diseño del despliegue

Los elementos del diseñ o del despliegue indican la forma en la que se acomodará n la funciona-
lidad del software y los subsistemas dentro del ambiente físico de la computació n que lo apo-
yará. Por ejemplo, los elementos del producto CasaSegura se configuran para que operen
dentro de tres ambientes de computació n principales: una PC en la casa, el panel de control de
CasaSe- gura y un servidor alojado en CPI Corp. (que provee el acceso al sistema a travé s de

CLAVE internet).
Los diagramas de despliegue Durante el diseñ o se desarrolla un diagrama de despliegue que despué s se refina, como se
comienzan en forma de descriptor, ilustra en la figura 8.7. En ella aparecen tres ambientes de computació n (en realidad habría
donde el ambiente de despliegue se má s, con sensores y cá maras, entre otros). Se indican los subsistemas (funcionalidad) que
describe en términos generales. está n alo- jados dentro de cada elemento de computació n. Por ejemplo, la computadora
Después se utilizan formas de
personal aloja subsistemas que implementan características de seguridad, vigilancia,
instancia y se describen
explícitamente los elementos de la administració n del hogar y comunicaciones. Ademá s, se ha diseñ ado un subsistema de acceso
configuración. externo para manejar to- dos los intentos de acceder al sistema CasaSegura desde un lugar
externo. Cada subsistema se elaboraría para que indicara los componentes que implementa.

FIGURA 8.7
Diagrama de Panel de Servidor en
despliegue control CPI
Seguridad AccesodelPropietario

Computadora
personal
AccesoExterno

Seguridad Vigilancia

Administración Comunicación
delHogar

[Link]
 CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 203

El diagrama que aparece en la figura 8.7 es un formato descriptor. Esto significa que el
diagrama de despliegue muestra el ambiente de computació n, pero no indica de manera
explícita los detalles de la configuració n. Por ejemplo, no se da mayor identificació n de la
“computado- ra personal”. Puede ser una Mac o basarse en Windows, una estació n de trabajo
Sun o un sistema Linux. Estos detalles se dan cuando se regrese al diagrama de despliegue en el
formato de instan- cia en las etapas finales del diseñ o, o cuando comience la construcció n. Se
identifica cada ins- tancia del despliegue (una configuració n específica, llamada configuración
del hardware).

8.5R E S U M E N
El diseñ o del software comienza cuando termina la primera iteració n de la ingeniería de reque-
rimientos. El objetivo del diseñ o del software es aplicar un conjunto de principios, conceptos y
prá cticas que llevan al desarrollo de un sistema o producto de alta calidad. La meta del diseñ o
es crear un modelo de software que implantará correctamente todos los requerimientos del
usuario y causará placer a quienes lo utilicen. Los diseñ adores del software deben elegir entre
muchas alternativas de diseñ o y llegar a la solució n que mejor se adapte a las necesidades de
los participantes en el proyecto.
El proceso de diseñ o va de una visió n “panorá mica” del software a otra má s cercana que
define el detalle requerido para implementar un sistema. El proceso comienza por centrarse en
la arquitectura. Se definen los subsistemas, se establecen los mecanismos de comunicació n
entre é stos, se identifican los componentes y se desarrolla la descripció n detallada de cada uno.
Además, se diseñ an las interfaces externa, interna y de usuario.
Los conceptos de diseñ o han evolucionado en los primeros 60 añ os de trabajo de la ingenie-
ría de software. Describen atributos de software de computadora que debe presentarse sin im-
portar el proceso que se elija para hacer la ingeniería, los mé todos de diseñ o que se apliquen o
los lenguajes de programació n que se utilicen. En esencia, los conceptos de diseñ o ponen el
é nfasis en la necesidad de la abstracció n como mecanismo para crear componentes reutiliza-
bles de software, en la importancia de la arquitectura como forma de entender mejor la estruc-
tura general de un sistema, en los beneficios de la ingeniería basada en patrones como té cnica
de diseñ o de software con capacidad comprobada, en el valor de la separació n de problemas y
de la modularidad eficaz como forma de elaborar software má s entendible, má s fá cil de probar
y de recibir mantenimiento, en las consecuencias de ocultar informació n como mecanismo para
reducir la propagació n de los efectos colaterales cuando hay errores, en el efecto de la indepen-
dencia funcional como criterio para construir mó dulos eficaces, en el uso del refinamiento
como mecanismo de diseñ o, en una consideració n de los aspectos que interfieren con los
requeri- mientos del sistema, en la aplicació n del rediseñ o para optimizar el diseñ o obtenido y
en la importancia de las clases orientadas a objetos y de las características relacionadas con
ellos.
El modelo del diseñ o incluye cuatro elementos distintos. Conforme se desarrolla cada uno,
surge una visió n má s completa del diseñ o. El elemento arquitectó nico emplea informació n ob-
tenida del dominio de la aplicació n, del modelo de requerimientos y de los catá logos
disponibles de patrones y estilos para obtener una representació n estructural completa del
software, de sus subsistemas y componentes. Los elementos del diseñ o de la interfaz modelan
las interfaces internas y externas y la de usuario. Los elementos en el nivel de componentes
definen cada uno de los mó dulos (componentes) que constituyen la arquitectura. Por ú ltimo,
los elementos del diseñ o albergan la arquitectura, sus componentes y las interfaces dirigidas
hacia la configura- ció n física en la que se alojará el software.

PR O B L E M A S Y P U N T O S POR E V A L U A R

8.1. Cuando se “escribe” un programa, ¿se diseñ a software? ¿En qué difieren el diseñ o de software y la co-
dificació n?
[Link]
204 PARTE DOS MODELADO

8.2. Si el diseñ o del software no es un programa (y no lo es), entonces, ¿qué es?

8.3. ¿Có mo se evalú a la calidad del diseñ o del software?

8.4. Estudie el conjunto de tareas presentado para el diseñ o. ¿Dó nde se evalú a la calidad en dicho conjunto?
¿Có mo se logra? ¿Có mo se consiguen los atributos de calidad estudiados en la secció n 8.2.1?

8.5. Dé ejemplos de tres abstracciones de datos y de las abstracciones de procedimiento que se usan para
manipularlas.

8.6. Describa con sus propias palabras la arquitectura de software.

8.7. Sugiera un patró n de diseñ o que encuentre en una categoría de objetos cotidianos (por ejemplo, elec-
tró nica de consumo, automó viles, aparatos, etc.). Describa el patró n en forma breve.

8.8. Describa con sus propias palabras la separació n de problemas. ¿Hay algú n caso en el que no sea apro-
piada la estrategia de divide y vencerá s? ¿Có mo afecta esto al argumento a favor de la modularidad?

8.9. ¿Cuá ndo debe implementarse un diseñ o modular como software monolítico? ¿Có mo se logra esto? ¿El
rendimiento es la ú nica justificació n para la implementació n de software monolítico?

8.10. Analice la relació n entre el concepto de ocultamiento de informació n como atributo de la

modularidad efectiva y el de independencia de los mó dulos.

8.11. ¿Có mo se relacionan los conceptos de acoplamiento y portabilidad del software? Dé ejemplos que
apoyen su punto de vista.

8.12. Aplique un “enfoque de refinamiento stepwise” para desarrollar tres niveles distintos de
abstracciones del procedimiento para uno o má s de los programas siguientes: a) un revisor de la escritura
que, dada una cantidad numé rica de dinero, imprima é sta en las palabras que se requieren normalmente en
un cheque. b) una resolució n en forma iterativa de las raíces de una ecuació n trascendente. c) un algoritmo
de programa- ció n de tareas simples para un sistema operativo.

8.13. Considere el software requerido para implementar la capacidad de navegació n (con un GPS) en un
dispositivo mó vil de comunicació n portá til. Describa dos o tres preocupaciones de interferencia que se pre-
sentarían. Analice la manera en la que se representaría como aspecto una de estas preocupaciones.

8.14. ¿”Rediseñ ar” significa que se modifica todo el diseñ o en forma iterativa? Si no es así, ¿qué significa?

8.15. Describa en breves palabras cada uno de los cuatro elementos del modelo del diseñ o.

LECTURAS ADICIONALES Y FUENTES DE I N F O R M A C I Ó N

Donald Norman ha escrito dos libros (The Design of Everyday Things, Doubleday, 1990, y The Psychology of
Everyday Things, Harpercollins, 1988) que se han convertido en clá sicos de la bibliografía sobre el diseñ o y
una “obligació n” de lectura para quien diseñ e cualquier cosa que utilicen los humanos. Adams (Conceptual
Blockbusting, 3a. ed., Addison-Wesley, 1986) escribió un libro cuya lectura es esencial para los diseñ adores
que deseen ampliar su forma de pensar. Por ú ltimo, el texto clá sico de Polya (How to Solve It, 2a. ed., Prince-
ton University Press, 1988) proporciona un proceso general de solució n de problemas que ayuda a los dise-
ñ adores de software cuando se enfrentan a problemas complejos.
En la misma tradició n, Winograd et al. (Bringing Design to Software, Addison-Wesley, 1996) analizan los
diseñ os de software que funcionan, los que no y su por qué . Un libro fascinante editado por Wixon y Ramsey
(Field Methods Casebook for Software Design, Wiley, 1996) sugiere mé todos de investigació n de campo (muy
parecidos a los de los antropó logos) para entender có mo hacen el trabajo los usuarios finales y luego
diseñ ar el software que satisfaga sus necesidades. Beyer y Holtzblatt (Contextual Design: A Customer-
Centered Appro- ach to Systems Designs, Academic Press, 1997) ofrecen otro punto de vista del diseñ o de
software que integra al consumidor o usuario en cada aspecto del proceso de diseñ o. Bain (Emergent
Design, Addison-Wesley, 2008) acopla los patrones, el rediseñ o y el desarrollo orientado a pruebas en un
enfoque de diseñ o eficaz.
Un tratamiento exhaustivo del diseñ o en el contexto de la ingeniería de software es presentado por Fox
(Introduction to Software Engineering Design, Addison-Wesley, 2006) y Zhu (Software Design Methodology,
Butterworth-Heinemann, 2005). McConnell (Code Complete, 2a. ed., Microsoft Press, 2004) plantea un estudio
excelente de los aspectos prá cticos del diseñ o de software de alta calidad. Robertson (Simple Program
Design, 3a. ed., Boyd y Fraser Publishing, 1999) presenta un aná lisis introductorio del diseñ o de software,
ú til para quienes se inician en el estudio del tema. Budgen (Software Design, 2a. ed., Addison-Wesley, 2004)
presenta
[Link]
CAPÍTULO 8 CONCEPTOS DE D ISEÑ O 205

varios mé todos populares de diseñ o y los compara entre sí. Fowler y sus colegas (Refactoring: Improving the
Design of Existing Code, Addison-Wesley, 1999) estudian té cnicas para la optimizació n incremental de diseñ os
de software. Rosenberg y Stevens (Use Case Driven Object Modeling with UML, Apress, 2007) estudian el de-
sarrollo de diseñ os orientados a objeto con el empleo de casos de uso como fundamento.
En una antología editada por Freeman y Wasserman (Software Design Techniques, 4a. ed., IEEE, 1983),
hay una excelente revisió n histó rica del diseñ o de software. Esta edició n contiene muchas reimpresiones de
los artículos clá sicos que forman la base de las tendencias actuales del diseñ o del software. Card y Glass
(Mea- suring Software Design Quality, Prentice-Hall, 1990) presentan mediciones de la calidad procedentes
de los campos de la té cnica y la administració n.
En internet hay una variedad amplia de fuentes de informació n acerca del diseñ o de software. En el sitio
web del libro: [Link]/engcs/compsci/pressman/professional/olc/[Link], se encuentra
una lista actualizada de referencias existentes en la red mundial que son relevantes para el diseñ o de soft-
ware y para la ingeniería de diseñ o.

[Link]