IDS5501

Principios de

Diseo del Software

V.1.1
@josebovet

Clase anterior

Modelado de los requerimientos

Introduccin

Diagrama de flujo de datos

Caso de uso

Diagrama de actividades

Objetivos de las clase

Principios del Diseo del Software

Introduccin.

Diseo en el contexto de la ingeniera de software.

El PROCESO,CONCEPTOS, y el MODELO del diseo.

Introduccin

Qu es?

Qu es?

Es el detalle sobre arquitectura del software, estructuras de datos,

interfaces y componentes que se necesitan para implementar el sistema.

6

Qu es?

El diseo es lo que casi todo ingeniero quiere hacer. Es el lugar

en el que las reglas de la creatividad los requerimientos de
los participantes, las necesidades del negocio y las

consideraciones tcnicas se unen para formular un

producto o sistema.

Quin lo hace?

Quin lo hace?

Ingenieros de Software.
Quienes llevan a cabo
las tareas del diseo.

Por qu es

importante?
10

Por qu es importante?

El diseo permite modelar el sistema o

producto que se va a construir.

Permite medir la calidad y su mejora antes

de generar cdigo.

Permite establecer la calidad del software.

11

Cules son los pasos?

Cules son los pasos?

1.Representar la Arquitectura del sistema.

2.Modelar interfaces(usuarios, sistemas,
dispositivos, componentes).

3.Disear componentes del software.

13

Cul es el producto final?

14

Cul es el producto final?

Un modelo de diseo que agrupa las

representaciones arquitectnicas, interfaces

en el nivel de componente y despliegue.

15

Ejemplos

16

Cmo me aseguro de que

lo hice bien?

17

Cmo me aseguro de que lo hice bien?

El modelo de diseo es evaluado por el

equipo de software

Comprobaciones

Errores

Inconsistencias u omisiones,

Si existen mejores alternativas.

y si es posible implementar el modelo dentro de las restricciones, plazo

y costo

18

Diseo en el contexto de la
ingeniera de software.

El milagro ms comn de la ingeniera de software es la transicin del anlisis al diseo y de

ste al cdigo. Richard Due

"Hay dos formas de construir un diseo del software. Una es

hacerlo tan simple que sea obvio que no hay deficiencias y la

otra es hacerlo tan complicado que no haya deficiencias
obvias. El primer mtodo es mucho ms difcil."

C. A. R. Hoare

Contexto

El diseo del software comienza una vez que se

han analizado y modelado los requerimientos.

Es la ltima accin de la ingeniera de software

dentro de la actividad de modelado.

Prepara la etapa de construccin (generacin y

prueba de cdigo)

Permite obtener 4 modelos de diseo.

21

Modelos en el diseo.

22

Modelos en el diseo.

Diseo en el nivel de componentes

Diseo de la interfaz

Diseo de la Arquitectura
Diseo de datos o clases

23

Diseo en el nivel de componentes

El diseo en el nivel de componente transforma los

elementos estructurales de la arquitectura del software en
una descripcin de sus componentes.

La informacin obtenida a partir de los modelos basados en

clase, flujo y comportamiento sirve como la base para
disear los componentes.

Generacin diagrama de componentes.

24

Diagrama de componentes

25

Diseo de la interfaz

El diseo de la interfaz describe la forma en la que el

software se comunica con los sistemas que interactan con
l y con los humanos

Una interfaz implica un flujo de informacin (por ejemplo,

datos o control) y un tipo especfico de comportamiento.

Modelos de escenarios, de casos de uso, y de

comportamiento dan mucha de la informacin requerida
para disear la interfaz.

26

Diseo de la interfaz

27

Diseo de la Arquitectura

El diseo de la arquitectura define la relacin entre los

elementos principales de la estructura del software, los
estilos y patrones de diseo de la arquitectura que
pueden usarse para alcanzar.

La representacin del diseo de la arquitectura en el

marco de un sistema basado en computadora se obtiene
del modelo de los requerimientos

28

Arquitectura basada en EC2

29

Diseo de la Datos o Clases

El diseo de datos o clases transforma los modelos de

clases en realizaciones de clases de diseo y en las

estructuras de datos que se requieren para implementar el

software.

Parte del diseo de clase puede llevarse a cabo junto con el

diseo de la arquitectura del software.

Un diseo ms detallado de las clases tiene lugar cuando

se disea cada componente del software.
30

Diagrama de clases o datos.

31

El Proceso de Diseo

...escribir un fragmento inteligente de cdigo que funcione es una cosa; disear algo que d
apoyo a largo plazo a una empresa es otra muy diferente. C. Ferguson

Proceso de Diseo

El diseo de software es un proceso iterativo por

medio del cual se traducen los requerimientos en un
plano para construir el software.

Se representa en un nivel alto de abstraccin, en el

que se rastrea directamente el objetivo especfico
del sistema y los requerimientos ms detallados de
datos, funcionamiento y comportamiento.

Iteraciones del diseo, permiten mejoras que

conducen a niveles menores de abstraccin.
33

Proceso de Diseo

Lineamientos y atributos de la calidad del software.

La evolucin del diseo del software.

34

Lineamientos y atributos de la calidad

del software.

35

Lineamientos y atributos de la calidad del software.

A travs del proceso de diseo se evala la calidad

del software de acuerdo con la serie de revisiones.

Debe implementar todos los requerimientos explcitos contenidos en el modelo

de requerimientos.

Debe ser una gua legible y comprensible para quienes generan el cdigo 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

implementacin.

36

Caractersticas de un buen diseo.

1. Debe tener una arquitectura que :

Se haya creado con el empleo de estilos o patrones

arquitectnicos reconocibles.

Est compuesta de componentes con buenas caractersticas de

diseo (stas se analizan ms adelante, en este captulo),.

Se implementen en forma evolutiva, de modo que faciliten la

implementacin y las pruebas.

37

Caractersticas de un buen diseo.

2. Debe ser modular, es decir, el software debe estar dividido de manera
lgica en elementos o subsistemas.

3. Debe contener distintas representaciones de datos, arquitectura,

interfaces y componentes.

4. Debe conducir a estructuras de datos apropiadas para las clases que se

van a implementar y que surjan de patrones reconocibles de datos.

5. Debe llevar a componentes que tengan caractersticas funcionales

independientes.

38

Caractersticas de un buen diseo.

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 mtodo repetible motivado por la

informacin ob- tenida durante el anlisis de los requerimientos del
software.

8. Debe representarse con una notacin que comunique con eficacia su

significado.

39

Atributos de calidad.

Hewlett-Packard desarroll un conjunto de atributos de la

calidad del software a los que se dio el acrnimo FURPS:

Funcionalidad

Usabilidad

Confiabilidad,

Rendimiento

Mantenibilidad.

Los atributos de calidad FURPS representan el objetivo de

todo diseo de software.
40

FUNCIONALIDAD
La funcionalidad se califica de acuerdo con:

El conjunto de caractersticas y capacidades

del programa.

La generalidad de las funciones que se

entregan.

La seguridad general del sistema.

41

USABILIDAD
Se evala:

Tomando en cuenta factores humanos

La esttica general.
La consistencia.

La documentacin.

42

CONFIABILIDAD
Se evala:

Medicin 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 recuperacin ante sta y lo

predecible del programa.
43

RENDIMIENTO
Se evala:

Con base en la velocidad de procesamiento.

El tiempo de respuesta.
El uso de recursos.
El conjunto.

La eficiencia.

44

MANTENIBILIDAD

Combina la capacidad del programa para ser ampliable

(extensibilidad), adaptable y servicial (trmino comn:
mantenibilidad).

Que pueda probarse, ser compatible y configurable

(capacidad de organizar y controlar los elementos de la
configuracin del software)

Facilidad para instalarse en el sistema.

Para que se detecten los problemas.

45

La evolucin del diseo del

software.

46

La evolucin del diseo del software.

Acu el trmino "Ingeniera de software.

En este campo se desarrollaron los conceptos de
software asncrono, la programacin por
prioridad, pruebas de end-to-end; que

actualmente se convirtieron en la base para el

diseo de software y pruebas.

47

La evolucin del diseo del software.

La evolucin del diseo del software es un proceso continuo

que ya ha cubierto casi seis dcadas.

Primeros enfoques:

Diseo y desarrollo de programas modulares.

Programacin estructurada

Nuevos enfoques:

Diseo orientado a objeto.

Orientados al aspecto.

En la industria del software se aplican varios mtodos de diseo, aparte de los ya

mencionados; cada mtodo de diseo de software introduce heurstica y notacin nicas, as

como un punto de vista sobre lo que caracteriza a la calidad en el diseo.
48

La evolucin del diseo del software.

No obstante, todos estos mtodos tienen algunas caractersticas en

comn:
1. Un mecanismo para traducir el modelo de requerimientos en una
representacin del diseo.
2. Una notacin para representar las componentes funcionales y
sus interfaces.
3. Una heurstica para mejorar y hacer particiones.
4. Lineamientos para evaluar la calidad.
49

Conceptos de diseo

50

Conceptos de Diseo.

Abstraccin

Arquitectura
Patrones

Divisin de problemas
Modularidad

Ocultamiento de informacin
Independencia funcional
Refinamiento
Aspectos

Rediseo

Conceptos de diseo orientados a objeto.

Clases de diseo

51

Abstraccin
La abstraccin es uno de los modos fundamentales
con los que los humanos luchamos con la
complejidad.
Grady Booch

52

Abstraccin

Consiste en aislar un elemento de su contexto o del resto de los

elementos que lo acompaan.
En programacin, el trmino se refiere al nfasis en el "qu hace?"
ms que en el "cmo lo hace?.

Cuando se considera una solucin modular para cualquier

problema, es posible plantear varios niveles de abstraccin

En el ms elevado: Enuncia una solucin en trminos gruesos

con el uso del lenguaje del ambiente del problema.

En niveles ms bajos: Se da la descripcin ms detallada de la

solucin.
53

Arquitectura
Una arquitectura del software es el producto del trabajo de
desarrollo que tiene la rentabilidad ms alta para una inversin
en cuanto a calidad, secuencia de actividades y costo.

54

Arquitectura

La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un sistema.

Tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones

coherentes que proporcionan el marco.

Selecciona y disea con base en objetivos (requerimientos) y restricciones.

Define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin,
sus interfaces y la comunicacin entre ellos.

Tiene que ver con el diseo y la implementacin de estructuras de software de alto nivel.

Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos de forma

adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeo de un
sistema, as como requerimientos no funcionales, como la confiabilidad.
55

Patrones
Cada patrn describe un problema que ocurre una y otra vez
en nuestro ambiente, por lo que describe el ncleo de la
solucin de ese problema, en forma tal que puede usarse sta
un milln de veces sin repetir lo mismo ni una sola vez.
Christopher Alexander

56

Patrones

Es una mezcla con nombre propio de puntos de vista que contienen la esencia de una solucin
demostrada para un problema recurrente dentro de cierto contexto de necesidades en competencia
Brad Appleton

Dicho de otra manera, un patrn de diseo describe una estructura de diseo que resuelve un
problema particular del diseo dentro de un contexto especfico.

El objetivo de cada patrn de diseo es proporcionar una descripcin que permita a un

diseador determinar :
1) Si el patrn es aplicable al trabajo en cuestin,
2) Si puede volverse a usar (con lo que se ahorra tiempo de diseo)
3) Si sirve como gua para desarrollar un patrn distinto en funciones o estructura.

57

Patrones

58

Divisin de problemas
El argumento para separar los problemas puede llevarse
demasiado lejos. Si se divide un problema en un nmero muy
grande de problemas muy pequeos, ser fcil resolver cada
uno de stos, pero unificarlos en la solucin (integracin) ser
muy difcil.

59

Divisin del Problema

Si para dos problemas, p1 y p2, la complejidad que se percibe para

p1 es mayor que la percibida para p2.

Entonces

se concluye que el esfuerzo requerido para resolver p1 es

mayor que el necesario para resolver p2.

Se concluye que cuando se combinan dos problemas, con frecuencia la complejidad

percibida es mayor que la suma de la complejidad tomada por separado. Esto lleva
a la estrategia de divide y vencers, pues es ms fcil resolver un problema
complejo si se divide en elementos manejables.
60

Divisin del Problema

Concepto de diseo que sugiere que cualquier problema complejo

puede manejarse con ms facilidad si se subdivide en elementos
susceptibles de resolverse u optimizarse de manera
independiente.

Un problema es una caracterstica o comportamiento que se

especifica en el modelo de los requerimientos para el software.

Al separar un problema en sus piezas ms pequeas y por ello ms

manejables, se requiere menos esfuerzo y tiempo para resolverlo.

61

Modularidad

Cul es el nmero correcto de mdulos para un sistema dado?

62

Mdulos

63

Modularidad

Es la manifestacin ms comn de la divisin de problemas.

El software se divide en componentes con nombres distintos y

abordables por separado, en ocasiones llamados mdulos, que se

integran para satisfacer los requerimientos del problema.

Se dice que la modularidad es el nico atributo del software que

permite que un programa sea manejable en lo intelectual

64

Modularidad

El esfuerzo (costo) de desarrollar un mdulo individual de software

disminuye conforme aumenta el nmero total de mdulos. Dado el
mismo conjunto de requerimientos, tener ms mdulos significa
tamaos individuales ms pequeos.

Sin embargo, a medida que se incrementa el nmero de mdulos, el

esfuerzo (costo) asociado con su integracin tambin aumenta.
65

Ocultamiento de
informacin

El objetivo de ocultar la informacin es esconder los detalles

de las estructuras de datos y el procesamiento tras una interfaz
de mdulo.

66

Ocultamiento de Informacin

El ocultamiento implica que la modularidad efectiva se logra definiendo un

conjunto de mdulos independientes que intercambien slo aquella informacin
necesaria para lograr la funcin del software.

Sugiere que los mdulos se caractericen por decisiones de diseo que se

oculten (cada una) de las dems.

En otras palabras, deben especificarse y disearse mdulos, de forma que la

informacin (algoritmos y datos) contenida en un mdulo sea inaccesible para
los que no necesiten de ella.

Proporciona beneficios cuando se requiere hacer modificaciones durante las

pruebas, y ms adelante, al dar mantenimiento al software.
67

Independencia
funcional

La cohesin es un indicador cualitativo del grado en el que

un mdulo se centra en hacer una sola cosa.

68

Independencia Funcional

Es resultado directo de la separacin de problemas y de los conceptos de

abstraccin y ocultamiento de informacin.

La independencia se evala con el uso de dos criterios cualitativos:

La cohesin: Indicador de la fortaleza relativa funcional de un mdulo

El acoplamiento: Es de la independencia relativa entre mdulos.

Es la interconexin entre mdulos en una estructura de software, y depende de la

complejidad de la interfaz entre mdulos, del grado en el que se entra o se hace
referencia a un mdulo y de qu datos pasan a travs de la interfaz.

En el diseo de software, debe buscarse el mnimo acoplamiento posible

Conectividad simple entre mdulos da como resultado un software que es ms

fcil de entender y de detectar errores.

69

Refinamiento
Existe la tendencia a pasar de inmediato a los detalles e ignorar
los pasos del refinamiento. Esto genera errores y hace que el
diseo sea mucho ms difcil de revisar.

70

Refinamiento stepwise

71

Refinamiento

El refinamiento stepwise es una estrategia de diseo propuesta originalmente por

Niklaus Wirth.

Un programa se elabora por medio del refinamiento sucesivo de los detalles del
procedimiento.

Se desarrolla una jerarqua con la descomposicin de un enunciado macroscpico

de la funcin (abstraccin del procedimiento) en forma escalonada hasta llegar a
los comandos del lenguaje de programacin.

72

Aspectos
Es difcil leer un libro sobre los principios de la magia sin echar
una mirada de vez en cuando a la portada para asegurarse de
que no es un texto sobre diseo de software.

73

Aspecto

Un mdulo que permita implementar la preocupacin en todas aquellas

con las que interfiera.

A* es una representacin del diseo para el requerimiento A, y B* es otra para el

requerimiento B. Por tanto, A* y B* son representaciones de las preocupaciones, y

B* interfiere con A*.

Una preocupacin de interferencia es alguna caracterstica del sistema

que se aplica a travs de muchos requerimientos distintos

74

Rediseo

75

Rediseo

Es el proceso de cambiar un sistema de software en forma tal que

no se altera el comportamiento externo del cdigo [diseo], pero
s se mejora su estructura interna.

Busca de redundancias, elementos de diseo no utilizados,

algoritmos ineficientes o innecesarios, estructuras de datos mal

construidas o inapropiadas y cualquier otra falla del diseo que
pueda corregirse para obtener un diseo mejor.

76

Conceptos de diseo
orientados a objeto.

77

Diseo orientado a Objeto

En el paradigma de la orientacin a objeto (OO) utilizado bastante

en la ingeniera de software moderna.
Capitulo 2

78

Clases de diseo
Qu tipos de clases crea el diseador?

79

Clases de diseo

Conforme el diseo evoluciona, se definir un conjunto de clases

de diseo que refinan las clases de anlisis, dando detalles del

diseo que permitirn que las clases se implementen y generen

una infraestructura para el software que apoye la solucin de
negocios.

5 tipos diferentes de clases de diseo:

Clases de usuario de la interfaz.

Clases del dominio de negocios.

Clases de proceso.

Clases persistentes.
Clases de sistemas.

80

Clases de usuario de la interfaz.

Definen todas las abstracciones necesarias

para la interaccin humano-computadora (IHC).

En muchos casos, la IHC ocurre dentro del
contexto de una metfora.

por ejemplo: cuaderno de notas, formato de

orden, mquina de fax, etc.)

Las clases del diseo para la interfaz son

representaciones visuales de los elementos de

la metfora.

81

Clases del dominio de negocios.

Refinamientos de las clases de anlisis

definidas antes.

Las clases identifican los atributos y servicios

(mtodos) que se requieren para implementar

algunos elementos del dominio de negocios.

82

Clases Modelo Negocio

83

Clases de proceso.

Implantan abstracciones de negocios de bajo

nivel que se requieren para administrar por
completo las clases de dominio de negocios.

84

Clases persistentes.

Representan almacenamientos de datos (por

ejemplo, una base de datos) que persistirn
ms all de la ejecucin del software.

85

Clases de sistemas

Implantan las funciones de administracin y

control del software que permiten que el

sistema opere y se comunique dentro de su

ambiente de computacin y con el mundo
exterior.

86

Un buen diseo de
clases

Qu es una clase de diseo bien formada?

87

Diseo de clases

A medida que se forma la arquitectura, el nivel de abstraccin se

reduce cuando cada clase de anlisis se transforma en una
representacin del diseo.

Se definen cuatro caractersticas de las clases de diseo bien

formadas.

88

Diseo de clases

Completa y suficiente
Primitivismo

Mucha cohesin.

Poco acoplamiento

89

Completa y Suficiente

Una clase de diseo debe ser el encapsulado total de

todos los atributos y mtodos que sea razonable esperar
(con base en una interpretacin comprensible del nombre
de la clase) y que existan para la clase.

Por ejemplo, la clase Escena definida para el software de

la edicin de video ser completa slo si contiene TODOS
los atributos y mtodos que se asocian de manera
razonable con la creacin de una escena de video.
90

Primitivismo

Los mtodos asociados con una clase de diseo deben

centrarse en el cumplimiento de un servicio para la clase.

Por ejemplo, la clase VideoClip para el software de la

edicin de video tal vez tenga los atributos punto-inicial y
punto-final que indiquen los puntos de inicio y fin del
corto.

Los mtodos EstablecerPuntoInicial () y

EstablecerPuntoFinal ( ) proporcionan los nicos medios
para establecer los puntos de comienzo y terminacin del
corto.
91

Mucha Cohesin

Una clase de diseo cohesiva tiene un conjunto pequeo

y centrado de responsabilidades; para implementarlas
emplea atributos y mtodos de objetivo nico.

Por ejemplo, la clase VideoClip quiz contenga un

conjunto de mtodos para editar el corto de video. La
cohesin se mantiene en tanto cada mtodo se centre
slo en los atributos asociados con el corto.

92

Poco Acoplamiento

Dentro del modelo de diseo, es necesario que las clases

de diseo colaboren una con otra. Sin embargo, la
colaboracin debe mantenerse en un mnimo aceptable.

Si un modelo de diseo est muy acoplado (todas las

clases de diseo colaboran con todas las dems), el
sistema es difcil de implementar, probar y mantener con
el paso del tiempo.

Las clases de diseo dentro de un subsistema deben

tener slo un conocimiento limitado de otras clases.
93

Conceptos Clave
ABSTRACCIN, ARQUITECTURA, ASPECTOS
ATRIBUTOS DE LA CALIDAD.
BUEN DISEO, COHESIN, DISEO DE DATOS
DISEO DEL SOFTWARE, ORIENTADO A OBJETO
DIVISIN DE PROBLEMAS, INDEPENDENCIA
FUNCIONAL,
LINEAMIENTOS DE LA CALIDAD
MODULARIDAD , OCULTAMIENTO DE INFORMACIN
PATRONES, PROCESO DE DISEO, REDISEO ,
REFINAMIENTO.

94

El modelo del diseo

Las preguntas acerca de si el diseo es necesario o digno de pagarse
estn ms all de la discusin: el diseo es inevitable. La alternativa al
buen diseo es el mal diseo, no la falta de diseo.

95

El modelo de Diseo

Un modelo de diseo esta compuesto de

elementos de las representaciones

arquitectnicas, interfaces en el nivel de

componente y despliegue.

Elementos del diseo de datos.

Elementos del diseo arquitectnico.

Elementos de diseo de la interfaz .

Elementos del diseo en el nivel de los componentes.

Elementos del diseo del despliegue
96

Elementos diseo de datos

97

Elementos diseo de datos

Crea un modelo de datos o informacin que se representa en un nivel de

abstraccin elevado (el punto de vista del usuario de los datos).

En muchas aplicaciones de software, la arquitectura de los datos tendr

una influencia profunda en la arquitectura del software que debe

procesarlo.

En el nivel de la aplicacin, la traduccin de un modelo de datos

(obtenido como parte de la ingeniera de los requerimientos) a una base

de datos es crucial para lograr los objetivos de negocios de un sistema.

98

Elementos del diseo arquitectnico

El modelo arquitectnico proviene de tres fuentes:

1) informacin sobre el dominio de la aplicacin del software que se va a

elaborar

2) los elementos especficos del modelo de requerimientos, tales como

diagramas de flujo de datos o clases de anlisis, sus relaciones y

colaboraciones para el problema en cuestin.

3) la disponibilidad de estilos arquitectnicos (captulo 9) y sus patrones

(captulo 12).

99

Elementos del diseo arquitectnico

100

Elementos del diseo arquitectnico

El diseo de la interfaz para el software es anlogo al conjunto

de trazos (y especificaciones) detalladas para las puertas,
ventanas e instalaciones de una casa.
Tales dibujos ilustran el tamao y forma de puertas y ventanas,
la manera en la que operan, la forma en la que llegan las
instalaciones de servicios (agua, electricidad, gas, telfono,
etc.) a la vivienda y se distribuyen entre las habitaciones
indicadas en el plano. Indican dnde est el timbre de la puerta,
si se usar un intercomunicador para anunciar la presencia de
un visitante.
101

Elementos de diseo de la interfaz

Hay tres elementos importantes del diseo de la interfaz:
1) La interfaz de usuario (IU).
2) Las interfaces externas que tienen que ver con otros sistemas,
dispositivos, redes y otros productores o consumidores de
informacin.
3) Interfaces internas que involucran a los distintos componentes
del diseo.
Estos elementos del diseo de la interfaz permiten que el software
se comunique externamente y permita la comunicacin y
colaboracin internas entre los componentes que constituyen la
arquitectura del software.

102

Elementos del diseo en el nivel de los componentes

Es el equivalente de los planos (y especificaciones) detallados de cada habitacin
de la casa. Estos dibujos ilustran el cableado y la plomera de cada cuarto, la
ubicacin de cajas elctricas e interruptores, grifos, coladeras, regaderas, tinas,
drenajes, gabinetes y closets.
Tambin describen el tipo de piso que se va a usar, las molduras que se van a
aplicar y todos los detalles asociados con una habitacin.
El diseo de componentes para el software describe por completo los detalles
internos de cada componente. Para lograrlo, este diseo define estructuras de
datos para todos los objetos de datos locales y detalles algortmicos para todo el
procesamiento que tiene lugar dentro de un componente, as como la interfaz
que permite el acceso a todas las operaciones de los componentes
103

Elementos del diseo en el nivel de los componentes

104

Elementos del diseo del despliegue

Los elementos del diseo del despliegue indican la forma

en la que se acomodarn la funcionalidad del software y los
subsistemas dentro del ambiente fsico de la computacin
que lo apoyar.
Por ejemplo, los elementos del producto CasaSegura se
configuran para que operen dentro de tres ambientes de
computacin principales: una PC en la casa, el panel de
control de CasaSegura y un servidor alojado en CPI Corp.
(que provee el acceso al sistema a travs de internet).
105

Elementos del diseo del despliegue

106

Preguntas
*

Cuando se escribe un programa, se disea software? En qu difieren el

diseo de software y la codificacin?

Si el diseo del software no es un programa (y no lo es), entonces, qu es?

Describa con sus propias palabras la arquitectura de software.

Cmo se relacionan los conceptos de acoplamiento y portabilidad del

software? D ejemplos que apoyen su punto de vista.

Redisear significa que se modifica todo el diseo en forma iterativa? Si no

es as, qu significa?

* Describa en breves palabras cada uno de los cuatro elementos del modelo del
diseo.

107

Prxima clase

Principios de diseo de la
arquitectura del software.

108