Capitulo 3 Arquitecturas de Software

3.1 Introduccin
La Ingeniera de Diseo un conjunto de principios, conceptos y prcticas que conducen al
desarrollo de un sistema o producto de alta calidad. Los principios del diseo (establecen una filo-
sofa primordial que guan al diseador en el trabajo que desempea. Es necesario comprender los
conceptos del diseo antes de que se apliquen las mecnicas de la prctica del diseo, y la
prctica del diseo mismo conduce a la creacin de varias representaciones del software, el cual
sirve como gua para la actividad de construccin que sigue.
La ingeniera del diseo no es una frase comn dentro del contexto de la ingeniera del
software. Sin embargo, debera serlo. El diseo es una actividad primordial de la ingeniera. A
principios de la dcada de 1990, Mitch Kapor, el creador de Lotus 1 -2-3, present un "manifiesto
sobre el diseo de software" en Dr. Dohbs Journal. Ah afirma.-,
Qu es el diseo? Es el lugar en donde una persona se puede parar con un pie en dos mundos
el mundo de la tecnologa y el de la gente y los propsitos humanos e intenta unirlos...
El crtico de arquitectura romana Vitruvius aport la nocin de que las construcciones bien diseadas
eran aquellas que mostraban firmeza, comodidad y placer. Lo mismo debe decirse del buen
software. Firmeza: el programa no debe tener ningn error que inhiba su funcin. Comodidad: un
programa debe cumplir con los propsitos para los que fue creado. Placer: la experiencia de usar el
programa debe ser agradable. Aqu se presentan los principios de una teora de diseo para
software.
La meta de la ingeniera de diseo es producir un modelo de representacin que muestre
firmeza, comodidad y placer. Para lograrlo, un diseador debe practicar la diversificacin y
despus la convergencia. Belady [BEL81] establece que "la diversificacin es la adquisicin de un
repertorio de alternativas, la materia prima del diseo: componentes, soluciones de componentes
y conocimiento, todo contenido en catlogos, libros de texto y en la mente". Una vez que se ha
integrado este conjunto de informacin, el diseador debe elegir y tomar elementos del
repertorio que cumplan los requisitos definidos por la ingeniera de requisitos y el modelo de
anlisis . Cuando esto ocurre, se consideran y se rechazan las alternativas, y el ingeniero de diseo
converge en "una configuracin particular de componentes y, por lo tanto, en la creacin del
producto final" [BEL81].
La diversificacin y la convergencia demandan intuicin y juicio. Estas cualidades estn basadas
en la experiencia de construir entidades similares, un conjunto de principios que guan cmo
evoluciona el modelo, un conjunto de criterios que permiten juzgar la calidad, y un proceso de
iteracin que conduce a una representacin del diseo final.
La ingeniera del diseo para el software de computadora est en un cambio continuo, en la
medida en que evolucionan mejores mtodos, mejores anlisis y una comprensin ms amplia.
Aun en la actualidad, la mayora de las metodologas del diseo de software carecen de
profundidad, flexibilidad y naturaleza cuantitativa, que por lo general se asocian con disciplinas de
diseo de ingeniera ms clsicas. Sin embargo, existen mtodos para el diseo de software, se
dispone de criterios para la calidad del diseo, y es posible aplicar notacin de diseo. En este
captulo se explorarn los conceptos y principios fundamentales aplicables a todo el diseo de
software, los elementos del modelo del diseo y el impacto de los patrones sobre el proceso de
diseo.
3.2 Diseo dentro del contexto de la ingeniera del software.
El diseo del software se encuentra en el ncleo tcnico de la respectiva ingeniera y se
aplica de manera independiente al modelo de software que se utilice. Una vez que se analizan y
especifican los requisitos, el diseo del software es la ltima accin de la ingeniera
correspondiente dentro de la actividad del modelado, la cual establece una plataforma para la
construccin (generacin de cdigo y pruebas).
Cada uno de los elementos del modelo de anlisis proporciona la informacin necesaria para
crear los cuatro modelos de diseo que se requieren para una especificacin completa de diseo.
En la figura 3.1 se ilustra el flujo de informacin durante el diseo del software. Los requisitos del
software que muestran los elementos basados en escenarios, basados en clases, orientados al
flujo y de comportamiento alimentan la tarea de diseo. Mediante la notacin de diseo y de los
mtodos de diseo que se exponen en captulos posteriores, la tarea de diseo produce un diseo
de datos-clase, un diseo arquitectnico, un diseo de interfaz y un diseo de componentes. El
diseo de datos-clase transforma los modelos de anlisis y clases en las clases de diseo y las
estructuras de datos que se requieren para implementar el software.
Figura 3. 1 Transformacin del modelo de anlisis en un modelo de diseo.
Las clases y relaciones que definen las tarjetas ndice CRC y el contenido detallado de datos que
muestran los atributos de clase y otras notaciones proporcionan la base para la actividad de
diseo de datos. Una parte del diseo de clases puede ocurrir en conjunto con el diseo de la
arquitectura del software. El diseo de clase ms detallado se realiza a medida que se disea cada
componente del software.
El diseo arquitectnico define la relacin entre los elementos estructurales ms importantes del
software, los estilos arquitectnicos y patrones de diseo que pueden usarse para satisfacer los
requisitos definidos por el sistema, y las restricciones que afectan la manera en que se pueden
implementar los patrones arquitectnicos [SHA96], La representacin del diseo arquitectnico -el
marco de trabajo de un sistema basado en computadora- puede derivarse de la especificacin del
sistema, del modelo de anlisis y de la interaccin de los subsistemas definidos dentro del modelo
de anlisis.
El diseo de la interfaz describe la forma en que el software se comunica con los sistemas que
interactan con l y con los humanos que los utilizan. Una interfaz implica un flujo de informacin
(por ejemplo, datos o control) y un tipo de comportamiento especfico. Por lo tanto, los escenarios
de uso y los modelos de comportamiento proporcionan mucha de la informacin que se requiere
en el diseo de la interfaz.
El diseo al nivel de componentes transforma los elementos estructurales de la arquitectura del
software en una descripcin procedimental de los componentes de ste. La informacin obtenida
de los modelos basados en clases, los modelos de flujo y los modelos de comportamiento sirven
como base para el diseo de componentes.
Durante el diseo se toman decisiones que al final incidirn en el xito de la construccin del
software, as como en, con el mismo grado de importancia, la facilidad con que el software puede
mantenerse. Pero, por qu es tan importante el diseo?
La importancia del diseo del software puede describirse con una sola palabra: calidad. El diseo
es la etapa en la que se fomentar la calidad en la ingeniera del software. El diseo proporciona
las representaciones del software susceptibles de evaluar respecto de la calidad. El diseo es la
nica forma en que, de manera exacta, un requisito del cliente se puede convertir en un sistema o
producto de software terminado. El diseo del software sirve como fundamento para todas las
actividades subsecuentes de la ingeniera del software y del soporte de ste. Sin diseo se corre el
riesgo de construir un sistema inestable, el cual fallar cuando se realicen cambios pequeos; que
ser difcil de probar; cuya calidad no podr evaluarse sino hasta etapas tardas del proceso del
software, cuando queda poco tiempo y ya se ha gastado mucho dinero en l.

3.3 Proceso y calidad del Diseo.
El diseo del software es un proceso iterativo mediante el cual los requisitos se traducen en un
"plano" para construir el software. Al inicio, el plano representa una visin holstica del software.
Es decir, el diseo se representa en un grado alto de abstraccin, el cual puede rastrearse de
manera directa hasta conseguir el objetivo especfico del sistema y requisitos ms detallados de
comportamiento, funcionales y de datos. A medida en que ocurren las iteraciones del diseo, un
refinamiento sub-siguiente conduce a representaciones del diseo a grados mucho ms bajos de
abstraccin. Estos grados an se pueden rastrear hasta los requisitos, pero la conexin es ms
sutil.
A travs del proceso del diseo, la calidad en evolucin de ste se evala con una serie de
revisiones tcnicas formales o con revisiones de diseo. McGlaughlin [MCG91] sugiere tres
caractersticas que sirven como gua en la evaluacin de un buen diseo:
El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis, y
debe ajustarse a todos los requisitos implcitos que desea el cliente.
El diseo debe ser una gua legible y comprensible para quienes generan cdigo y quienes
realizan pruebas y, en consecuencia, dan soporte al software.
El diseo debe proporcionar una imagen completa del software dando direccin a los
dominios de datos, funcionales y de comportamiento desde una perspectiva de
implementacin. Cada una de estas caractersticas es en realidad una meta del proceso de diseo.
Pero, cmo se alcanza cada una de ellas?



Directrices de calidad. Con el fin de evaluar la calidad de una representacin de diseo se deben
establecer los criterios tcnicos para un buen diseo. En secciones posteriores de este captulo se
expondrn los conceptos de diseo que tambin sirven como criterios de calidad del software. Por
ahora se presentan las siguientes directrices:

1. Un diseo debe presentar una estructura arquitectnica que a) se haya creado mediante
patrones de diseo reconocibles, b) la integren componentes que exhiban buenas caractersticas
de diseo (stas se explican ms adelante en este captulo), y c) pueda implementarse de manera
evolutiva, para que de esta forma facilite la implementacin y las pruebas.

2. Un diseo debe ser modular, esto es, el software deber dividirse de manera lgica en
elementos o subsistemas.
3. Un diseo debe contener distintas representaciones de los datos, la arquitectura, las interfaces
y los componentes.

4. Un diseo debe conducir a estructuras de datos que sean apropiadas para las clases que habrn
de implementarse y que procedan de patrones de datos reconocibles.

5. Un diseo debe conducir a componentes que presenten caractersticas funcionales
independientes.

6. Un diseo debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los
componentes y el ambiente externo.

7. Un diseo debe obtenerse por medio de un mtodo repetible que se base en la informacin
obtenida durante el anlisis de requisitos del software.

8. Un diseo debe representarse por medio de una notacin que comunique de manera eficaz su
significado.

Estas directrices de diseo no se logran por casualidad. El proceso de diseo del software fomenta
el buen diseo aplicando principios fundamentales de diseo, una metodologa sistemtica y una
revisin cuidadosa.

Atributos de calidad. Hewlett-Packard [GRA87] desarroll un conjunto de atributos de calidad;
entre ellos estn la funcionalidad, la facilidad de uso, la confiabilidad, el desempeo y la
soportabilidad. Estos atributos de calidad representan un objetivo para todo el diseo de
software:

La funcionalidad se estima al evaluar el conjunto de caractersticas y capacidades del programa,
la generalidad de las funciones que se entregan y la seguridad del sistema en su totalidad.
La facilidad de uso se valora al considerar los factores humanos, la esttica, consistencia y
documentacin generales.
La confiabilidad se evala al medir la frecuencia y severidad de las fallas, la precisin de los
resultados de salida, la media del momento de fallas (MMF), la habilidad para recuperarse de las
fallas y la previsibilidad del programa.

El desempeo se mide con la velocidad de procesamiento, tiempo de respuesta, consumo de
recursos, rendimiento y eficacia.
La soportabilidad combina la habilidad de extender el programa (extensibilidad), la adaptabilidad
y la serviciabilidad estos tres atributos representan un concepto ms comn, facilidad de
mantenimiento adems, resistencia a pruebas, compatibilidad, configurabilidad (habilidad para
organizar y controlar elementos de la configuracin de software), la facilidad con que puede
instalarse el sistema, y la facilidad con que se pueden localizar los problemas.
No todos los atributos de la calidad del software tienen el mismo peso cuando se desarrolla el
diseo del software. Tal vez una aplicacin tenga un especial inters en la seguridad. Es posible
que otra demande desempeo con un enfoque particular en la velocidad de procesamiento. Una
tercera puede centrarse en la confiabilidad. Sin importar el peso, es importante puntualizar que
estos atributos de calidad deben considerarse al comienzo del diseo, no despus de que el diseo
est completo y haya comenzado la construccin

3.4 Conceptos de Diseo.

A travs de la historia de la ingeniera del software ha evolucionado un conjunto de conceptos
fundamentales de diseo de software. Aunque el grado de inters en cada concepto ha variado
con los aos, han pasado la prueba del tiempo. Cada uno ofrece al ingeniero de software un
fundamento sobre el cual pueden aplicarse mtodos de diseo ms elaborados.
M. A. Jackson IJAC75] dijo una vez: "El comienzo de la sabidura para [un ingeniero de software]
es reconocer la diferencia entre hacer que un programe funcione y conseguir que lo haga del
modo correcto". Los conceptos fundamentales del diseo de software ofrecen el marco de trabajo
necesario para hacer las cosas "del modo correcto".
3.4.1 Abstraccin
Cuando se considera una solucin modular a cualquier problema se pueden exponer muchos
grados de abstraccin. En un alto grado de abstraccin una solucin se establece en trminos
generales con el lenguaje del entorno del problema. En los grados de menor abstraccin se
proporciona una descripcin ms detallada de la solucin.
En la medida en que cambian los diferentes grados de abstraccin se trabaja para crear
abstracciones procedimentales y de datos. Una abstraccin procedimental se refiere a una
secuencia de instrucciones que tiene una funcin especfica y limitada. El nombre de abstraccin
procedimental implica estas funciones, pero se omiten detalles especficos. Un ejemplo de
abstraccin procedimental sera la palabra abrir para una puerta. Abrir implica una larga secuencia
de pasos procedimentales (por ejemplo, caminar a la puerta, alcanzar la manija, darle vuelta a la
manija y empujar la puerta, hacerse a un lado para abrir paso a la puerta que se abre, etc.).
Una abstraccin de datos es una coleccin nombrada de datos que describe un objeto de datos.
En el contexto de abstraccin procedimental, abrir se puede definir como una abstraccin de
datos llamada puerta. Como cualquier objeto de datos, la abstraccin de datos para puerta
abarcara una serie de atributos que la describan (por ejemplo, puerta, tipo, direccin de apertura,
mecanismo de apertura, peso, dimensiones). Se puede decir que la abstraccin procedimental
abrir empleara la informacin contenida en los atributos de la abstraccin de datos puerta.
3.4.2 Arquitectura
La arquitectura del software alude a "la estructura general del software y las formas en que la
estructura proporciona una integridad conceptual para un sistema" [SHA95a]. En su forma ms
simple, la arquitectura es la estructura u organizacin de los componentes del programa
(mdulos), la manera en que estos componentes interactan, y la estructura de datos que utilizan
los componentes. En un sentido ms amplio, sin embargo, los componentes pueden generalizarse
para representar elementos importantes del sistema y sus interacciones.
Una de las metas del diseo de software es derivar una representacin arquitectnica de un
sistema. Esta representacin sirve como el marco de trabajo a partir del cual se conducen
actividades de diseo ms detalladas. Un conjunto de patrones arquitectnicos permite que un
ingeniero de software reutilice conceptos en el nivel de diseo.
El diseo arquitectnico puede representarse al usar uno o ms de muchos modelos diferentes
[GAR95]. Los modelos estructurales representan la arquitectura como una coleccin organizada de
componentes del programa. Los modelos del marco de trabajo incrementan el grado de
abstraccin del diseo al intentar identificar marcos de trabajo repetibles del diseo
arquitectnico que se encuentran en tipos de aplicaciones similares. Los modelos dinmicos
abordan los aspectos conductuales de la arquitectura del programa, al indicar cmo puede
cambiar la configuracin de la estructura o el sistema, como funcin de los eventos externos. Los
modelos del proceso se centran en el diseo del proceso tcnico o de negocios que el sistema debe
contener. Por ltimo, los modelos funcionales pueden utilizarse para representar la jerarqua
funcional de un sistema.
3.4.3 Patrones
Brad Appleton define un patrn de diseo de la siguiente manera: "Un patrn es una semilla de
conocimiento, la cual tiene un nombre y transporta la esencia de una solucin probada a un
problema recurrente dentro de cierto contexto en medio de intereses en competencia" [APP98].
Dicho de otro modo, un patrn de diseo describe una estructura de diseo que resuelve un
problema de diseo particular dentro de un contexto especfico y en medio de "fuerzas" que
pueden tener un impacto en la manera en que se aplica y utiliza el patrn.

La finalidad de cada patrn de diseo es proporcionar una descripcin que le permita al
diseador determinar 1) si el patrn es aplicable al trabajo actual, 2) si el patrn se puede
reutilizar (por ende, ahorrar tiempo del diseo), y 3) si el patrn puede servir como gua para
desarrollar un patrn similar, pero diferente en cuanto a la funcionalidad o estructura.
3.4.4 Modularidad
Los patrones de arquitectura y diseo de software materializan la modularidad; es decir, el
software se divide en componentes con nombres independientes y que es posible abordar en
forma individual. Estos componentes llamados mdulos se integran para satisfacer los requisitos
del problema.
Se ha establecido que la "modularidad es el atributo particular del software que permite que un
programa sea manejable de manera intelectual" [MYE78], El software monoltico (es decir, un
programa grande compuesto por un mdulo sencillo) no puede entenderlo con facilidad un
ingeniero de software. El nmero de rutas de control, la amplitud de las referencias, el nmero de
variables y la complejidad general imposibilitara comprenderlo. Este punto se ilustra con el
siguiente argumento, basado en observaciones de solucin de problemas humanos.
Considrense dos problemas, p
1
, y p
2
. Si la complejidad observada para p
1
, es mayor que la dep
2

se deduce que el esfuerzo requerido para resolver p, es mayor que el esfuerzo necesario para
resolverp
2
. Como un caso general, este resultado es obvio en el sentido intuitivo; la resolucin de
un problema difcil toma ms tiempo.
Tambin se deduce que la complejidad observada de dos problemas, cuando estn
combinados, con frecuencia es mayor que la suma de las complejidades observadas cuando cada
una de ellas se toma por separado: esto conduce a una estrategia de "divide y vencers" (es ms
fcil resolver un problema complejo cuando ste se divide en piezas ms manejables). Esto tiene
implicaciones importantes con respecto a la modularidad y al software. De hecho, es un
argumento para la modularidad.
Es posible concluir que si el software se subdivide en forma indefinida, el esfuerzo requerido
para desarrollarlo se reducir en forma sensible. Por desgracia, hay otras fuerzas que entran en
juego, lo que ocasiona que esta conclusin sea (tristemente) invlida. En relacin con la figura 3.2,
el esfuerzo (costo) para desarrollar un solo mdulo de software decrece conforme se incrementa
el nmero de mdulos. Si se tiene el mismo conjunto de requisitos, ms mdulos significan un
tamao individual menor. Sin embargo, a medida que crece el nmero de mdulos, el esfuerzo
(costo) asociado con la integracin de los mdulos tambin crece. Estas caractersticas conducen
tambin a la curva total del costo o el esfuerzo que se muestra en la figura. Existe un nmero M de
mdulos que resultara en un costo de desarrollo mnimo, aunque hasta el momento no se tiene la
sofisticacin necesaria para predecir M con seguridad.
Las curvas que se muestran en la figura 3.2 proporcionan una gua til cuando se considera la
modularidad. sta debe aplicarse, pero se debe tener cuidado de permanecer en la vecindad de
M. Debe evitarse la modularidad excesiva o insuficiente, pero cmo puede conocerse la
vecindad de M? Qu tan modular debe hacerse el software? Las respuestas a estas preguntas
requieren comprender otros conceptos de diseo que se considerarn despus, en este mismo
captulo.
Un diseo y el programa resultante se modularizan de manera que el desarrollo se pueda
planear con mayor facilidad; se puedan definir y entregar incrementos del software; los cambios
puedan ajustarse con mayor facilidad; las pruebas y la eliminacin de errores se puedan conducir
con ms eficiencia, y el mantenimiento se pueda conducir sin efectos laterales de consideracin.








Figura 3. 2 Modularidad y costo del software


3.4.5 Ocultacin de informacin
El concepto de modularidad conduce a todos los diseadores de software a formularse una
pregunta fundamental: cmo puede descomponerse una solucin de software para obtener el
mejor conjunto de mdulos? El principio de ocultacin de informacin [PAR72] sugiere que los
mdulos "se caracterizan por las decisiones de diseo que (cada uno) oculta a los otros". En otras
palabras, los mdulos deben especificarse y disearse de manera que la informacin
(procedimiento y datos) que est dentro del mdulo sea inaccesible para otros mdulos que no
necesiten esa informacin.
La ocultacin implica que se puede conseguir una modularidad efectiva al definir un conjunto
de mdulos independientes que se comuniquen entre s y que intercambien slo la informacin
necesaria para lograr la funcin del software. La abstraccin ayuda a definir las entidades de
procedimiento (o informacin) que conforman el software. La ocultacin define y fortalece las
restricciones de acceso para los detalles de procedimiento dentro de un mdulo y para cualquier
estructura de datos local que utilice el mdulo [ROS75].
El uso de la ocultacin de informacin, como un criterio de diseo para sistemas modulares,
proporciona los mayores beneficios cuando se requieren modificaciones durante la realizacin de
las pruebas y, despus, en el curso de mantenimiento del software. Como la mayora de los datos
y procedimientos est oculta de las otras partes del software, existe una probabilidad menor de
introducir errores inadvertidos al realizar las modificaciones y propagarlos a otros lugares dentro
del software.
3.4.6 Independencia funcional
El concepto de independencia funcional es la suma directa de la modularidad y de los conceptos
de abstraccin y ocultacin de informacin. En referencias obligadas sobre el diseo de software,
Wirth [WIR71] y Pamas [PAR72] aluden a las tcnicas de refinamiento que mejoran la
independencia de los mdulos. Trabajos posteriores de Stevens, Myers y Constantine [STE74]
consolidaron el concepto.
La independencia funcional se consigue al desarrollar mdulos con una funcin "determinante" y
una "aversin" a la interaccin excesiva con otros mdulos. Dicho de otra manera, se desea
disear el software de tal manera que cada mdulo aborde una subfuncin especfica de los
requisitos y tenga una sola interfaz cuando se observe desde otras partes de la estructura del
programa. Es justo preguntarse por qu es importante la independencia.
El software con una modularidad efectiva, es decir, con mdulos independientes, es ms fcil
de desarrollar porque la funcin se puede fraccionar y las interfaces se simplifican (considrense
las ramificaciones cuando el desarrollo se realiza en equipo). Los mdulos independientes son ms
fciles de mantener (y probar) porque se limitan los efectos secundarios que originan las
modificaciones al diseo o al cdigo, se reduce la propagacin de errores, y es posible emplear
mdulos reutilizables. En resumen, la independencia funcional es una clave para el buen diseo, y
el diseo es la clave para lograr la calidad del software.
La independencia se evala aplicando dos criterios cualitativos: cohesin y acoplamiento. La
cohesin es una medida de la fuerza funcional relativa de un mdulo. El acoplamiento es una
medida de la interdependencia relativa entre los mdulos.
Un mdulo cohesivo realiza una sola tarea, para lo que requiere muy poca interaccin con
otros componentes en otras partes del programa. Dicho de manera sencilla, un mdulo cohesivo
debe (idealmente) hacer slo una cosa.
El acoplamiento es una medida de la interconexin entre los mdulos de una estructura de
software. El acoplamiento depende de la complejidad de la interfaz entre los mdulos, el punto
donde se realiza una entrada o referencia a un mdulo, y los datos que pasan a travs de la
interfaz. En el diseo de software se intenta conseguir el acoplamiento ms bajo posible. Una
conectividad sencilla entre los mdulos da como resultado un software ms fcil de entender y
menos propenso a experimentar el "efecto ola" [STE74], el cual se presenta cuando surgen
problemas en un lugar y despus se propagan a travs del sistema.
3.4.7 Refinamiento
El refinamiento paso a paso es una estrategia de diseo descendente que propuso inicialmente
Niklaus Wirth [WIR71]. El desarrollo de un programa se realiza al retinar de manera sucesiva los
niveles de detalle procedimentales. Una jerarqua se desarrolla al descomponer el enunciado
macroscpico de una funcin (una abstraccin procedimental) paso a paso hasta alcanzar las
oraciones del lenguaje de programacin.
En realidad, el refinamiento es un proceso de elaboracin. Se inicia con el enunciado de una
funcin (o una descripcin de datos) que se define con un alto grado de abstraccin. Esto es, el
enunciado describe los datos o la funcin de manera conceptual, pero no proporciona informacin
acerca de los trabajos internos de la funcin o de la estructura interna de los datos. El
refinamiento hace que el diseador trabaje sobre el enunciado original y que proporcione ms y
ms detalles conforme se realiza cada refinamiento sucesivo (elaboracin).
La abstraccin y el refinamiento son conceptos complementarios. La abstraccin le permite a
un diseador especificar procedimientos y datos sin considerar detalles de grado menor. El
refinamiento ayuda al diseador a revelar los detalles de grado menor mientras se realiza el
diseo. Ambos conceptos auxilian al diseador en la creacin de un modelo de diseo completo a
medida que evoluciona la actividad de diseo.

3.4.8 Refabricacin
Una actividad importante de diseo que sugieren muchos mtodos giles (captulo 4) es la
Refabricacin, tcnica de reorganizacin que simplifica el diseo (o cdigo) de un componente sin
cambiar su funcin o comportamiento. Fowler [FOW99] define la Refabricacin de la siguiente
manera: "La Refabricacin es el proceso de cambiar un sistema de software de tal forma que no se
altere el comportamiento externo de su cdigo [diseo] y aun as se mejore su estructura interna."
Cuando un software se refabrica el diseo existente se examina en busca de redundancias,
elementos de diseo intiles, algoritmos innecesarios o insuficientes, estructuras de datos
inapropiadas o construidas de manera incorrecta, o cualquier otra falla de diseo que se pueda
corregir para lograr un mejor diseo. Por ejemplo, una primera iteracin de diseo podra producir
un componente que muestra poca cohesin (realiza tres funciones que tienen muy pocas
relaciones entre s). El diseador puede decidir que el componente debe refabricarse en tres
componentes distintos, cada uno de ellos con una elevada cohesin. El resultado ser un software
ms fcil de integrar, probar y mantener.

3.4.9 Clases de Diseo
Cada una de estas clases describe algn elemento del dominio del problema, con enfoque en los
aspectos del problema visibles para el usuario o el cliente. El grado de abstraccin de una clase de
anlisis es relativamente alto.
Conforme evoluciona el modelo de diseo, el equipo de software debe definir un conjunto de
clases de diseo que 1) retine las clases de anlisis al proporcionar detalles del diseo que
permitirn la implementacin de las clases, y 2) produzca un conjunto nuevo de clases de diseo
que implementen una infraestructura de software para soportar la solucin del negocio. Se
sugieren cinco diferentes tipos de clases de diseo, cada uno representa una capa distinta de la
arquitectura de diseo [AMB01]:

Las clases de interfaz con el usuario 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, un libro de verificacin, un formato de orden, una mquina de fax) y
las clases de diseo para la interfaz pueden ser representaciones visuales de los elementos de la
metfora.

Las clases del dominio de negocios a menudo son refinamientos de las clases de anlisis
definidas antes. Las clases identifican los atributos y servicios (mtodos) necesarios para
implementar algn elemento del dominio de negocios.

Las clases de proceso implementan abstracciones del negocio en un nivel ms bajo, las cuales se
requieren para manejar por completo las clases del dominio de negocios.

Las clases persistentes representan almacenamientos de datos (por ejemplo, una base de datos)
que persistirn ms all de la ejecucin del software.
Las clases de sistema implementan las funciones de gestin y control del software que
permiten que el sistema opere y se comunique dentro de su entorno de computacin y con
el mundo exterior.
A medida que evoluciona el modelo de diseo, el equipo de software debe desarrollar un conjunto
completo de atributos y operaciones para cada clase de diseo. El grado de abstraccin se reduce
conforme cada clase de anlisis se transforma en una representacin del diseo. Esto es, las clases
de anlisis representan objetos (y servicios asociados que se aplican a stos) usando la jerga del
dominio de negocios. Las clases de diseo presentan un mayor detalle tcnico, pues son una gua
para la implementacin.
Arlow y Neustadt [ARL02] sugieren revisar cada clase de diseo para asegurar que la misma
est "bien formada". Ellos definen cuatro caractersticas de una clase de diseo bien formada:
Completa y suficiente. Una clase de diseo debe ser la encapsulacin completa de todos los
atributos y mtodos que se pueden esperar, en forma razonable (con base en una interpretacin
reconocible del nombre de la clase), que existan para clase. Por ejemplo, la clase escena definida
para el software de edicin de videos est completa slo si contiene todos los atributos y mtodos
que pueden asociarse de manera razonable con la creacin de una escena de video. La suficiencia
asegura que la clase de diseo contenga slo aquellos mtodos que sean suficientes para lograr el
objetivo, ni ms ni menos.
Primitivismo. Los mtodos asociados con una clase de diseo deben enfocarse en el
cumplimiento de un servicio para la clase. Una vez que el servicio ha sido implementado con un
mtodo, la clase no debe proporcionar otra forma de complementar la misma cosa. Por ejemplo,
la clase videoClip del software de edicin de video podran tener atributos punto-inicial y punto-
final para indicar los puntos de inicio y fin del clip (ntese que el video bruto cargado en el sistema
puede ser ms largo que el clip que se usa). Los mtodos establecerPuntoInicial() y
establecerPuntoFinal() proporcionan los nicos medios para configurar los puntos de inicio y fin del
clip.
Cohesin alta. Una clase de diseo cohesiva tiene un conjunto de responsabilidades pequeo y
enfocado, y aplica atributos y mtodos de manera sencilla para implementar dichas
responsabilidades. Por ejemplo, la clase VideoClip del software para la edicin de video podra
contener un conjunto de mtodos para editar el videoclip. Mientras cada mtodo se enfoque slo
en atributos asociados con el video clip se mantendr la cohesin.
Acoplamiento bajo. Dentro del modelo de diseo es necesario que las clases de diseo colaboren
con alguna otra. Sin embargo, la colaboracin se debe mantener en un mnimo aceptable. Si un
modelo de diseo tiene un acoplamiento alto (todas las clases de diseo colaboran con todas las
otras clases de diseo), el sistema es difcil de implementar, probar y mantener a travs del
tiempo. En general, las clases de diseo dentro de un subsistema deben tener slo un
conocimiento limitado de las clases en otros subsistemas. Esta restriccin, llamada la Ley de
Demter [LIE03], sugiere que un mtodo slo debe enviar mensajes a mtodos de clases vecinas.
Figura 3. 3 Clase de Diseo para el plano de planta y agregacin compuesta para la clase.



3.5 El Modelo de Diseo
El modelo de diseo puede verse en dos dimensiones diferentes, como se ilustra en la figura 3.4.
La dimensin del proceso indica la evolucin del modelo de diseo conforme se ejecutan las tareas
de diseo como una parte del proceso del software. La dimensin de abstraccin representa el
grado de detalle a medida que cada elemento del modelo de anlisis se transforma en un
equivalente del diseo y despus se refina de una manera iterativa. En la figura, la lnea punteada
indica la frontera entre los modelos de anlisis y diseo. En algunos casos se distingue con claridad
entre los modelos de anlisis y diseo; en otros, el modelo de anlisis se combina con el diseo y
la distincin resulta menos obvia.
Los elementos del modelo del diseo utilizan muchos de los diagramas en UML aplicados en el
modelo de anlisis. La diferencia es que estos diagramas estn refinados y elaborados como parte
del diseo; se proporciona un mayor detalle para la implementacin especfica y se resaltan la
estructura y el estilo arquitectnicos, los componentes que residen dentro de la arquitectura y las
interfaces entre los componentes y con el mundo exterior.
Sin embargo, es importante mencionar que los elementos del modelo anotados a lo largo del
eje horizontal no siempre se desarrollan de una manera secuencial. En la mayora de los casos, el
diseo arquitectnico preliminar establece la plataforma y lo siguen el diseo de interfaz y el
diseo al nivel de componentes, los cuales a menudo se realizan en paralelo. El modelo de
despliegue con frecuencia se retrasa hasta que el diseo ha sido desarrollado por completo.

Figura 3. 4 Dimensin del modelo de diseo

3.5.1 Elementos del diseo de datos
Al igual que otras actividades de la ingeniera del software, el diseo de datos (algunas veces
llamado arquitectura de datos) crea un modelo de datos o informacin que se representa con un
alto grado de abstraccin (la visin de los datos del cliente/usuario). Despus, este modelo de
datos se refina en representaciones que de manera progresiva tienen una implementacin
especfica y que pueden procesarse mediante el sistema basado en computadora. En muchas
aplicaciones de software la arquitectura de los datos tendr una profunda influencia sobre la
arquitectura del software que los debe procesar.
La estructura de los datos siempre ha sido una parte importante del diseo del software. Al nivel
de los componentes del sistema, las estructuras del diseo de datos y los algoritmos con que se
manipulan son esenciales para la creacin de aplicaciones de alta calidad. Al nivel de aplicacin, la
traduccin de un modelo de datos (obtenido como una base de la ingeniera de requisitos) a una
base de datos es esencial para alcanzar los objetivos de negocio de un sistema. Al nivel de
negocios, la coleccin de informacin almacenada en bases de datos dispersas y reorganizadas en
una "conjuncin de datos" permite la explotacin de datos o el descubrimiento de un
conocimiento que puede tener un impacto sobre el xito del mismo negocio. En cada caso, el
diseo de datos juega un papel importante.

3.5.2 Elementos del Diseo Arquitectnico
El diseo arquitectnico para el software es el equivalente al plano de planta de una casa. Este
plano muestra la configuracin general de las habitaciones, su tamao, forma y las relaciones
entre ellas, y las puertas y ventanas que permiten el movimiento hacia y desde los cuartos. El
plano de planta proporciona una visin global de la casa. Los elementos del diseo arquitectnico
dan una visin general del software.
El modelo arquitectnico [SHA96] se obtiene a partir de tres fuentes: 1) la informacin acerca
del dominio de aplicacin para el software que se va a construir; 2) los elementos del modelo de
anlisis especfico, tales como diagramas de flujo de datos o clases de anlisis, sus relaciones y
colaboraciones para el problema que se tiene a la mano, y 3) la disponibilidad de patrones y estilos
arquitectnicos.
3.5.3 Elementos de diseo de interfaz
El diseo de interfaz para software es el equivalente a un conjunto de dibujos detallados (y
especificaciones) para puertas, ventanas y utilidades externas de una casa. Estos dibujos
representan el tamao y forma de las puertas y ventanas, la manera en que operan, la manera en
que las conexiones de las utilidades (como agua, energa elctrica, gas, telfono) llegan a la casa y
se distribuyen entre las habitaciones representadas en el plano de planta. Estos dibujos indican
dnde est localizado el timbre de la puerta, si hay un intercomunicador que anuncie la presencia
de un visitante y cmo est instalado el sistema de seguridad. En esencia, los dibujos (y especifi-
caciones) detallados para las puertas, ventanas y utilidades externas indican cmo fluyen las cosas
y la informacin desde y hacia la casa y dentro de las habitaciones que son parte del plano de
planta. Los elementos del diseo de interfaz para software muestran cmo fluye la informacin
hacia o fuera del sistema y cmo ste est comunicado entre los componentes definidos como
parte de la arquitectura. Existen tres elementos importantes del diseo de interfaz: 1) la interfaz
con el usuario (IU); 2) interfaces externas a otros sistemas, artefactos, redes u otros productores o
consumidores de informacin; y 3) interfaces internas entre varios componentes de diseo.
Estos elementos de diseo de interfaz permiten al software comunicarse de manera externa y
permiten la comunicacin y colaboracin interna entre los componentes que pueblan la
arquitectura del software.
El diseo de una IU incorpora elementos estticos (por ejemplo, distribucin, color, grficas,
mecanismos de interaccin), elementos ergonmicos (por ejemplo, informacin y ubicacin de la
distribucin, metforas, navegacin de la IU), y elementos tcnicos (como patrones de la IU,
componentes reutilizables). En general, la IU es un subsistema nico dentro de la arquitectura de
aplicacin general.
El diseo de las interfaces externas requiere informacin definitiva acerca de la entidad hacia
donde se manda o recibe la informacin. En todos los casos, esta informacin debe recopilarse
durante la ingeniera de requisitos y verificarse una vez que comience el diseo de la interfaz. El
diseo de interfaces externas debe incorporar revisin de errores y (cuando sea necesario)
caractersticas apropiadas de seguridad.
El diseo de las interfaces internas est cercanamente alineado con el diseo al nivel de los
componentes. Las realizaciones del diseo de clases de anlisis representan todas las operaciones
y esquemas de mensajes requeridos para permitir la comunicacin y colaboracin entre las
operaciones de varias clases. Cada mensaje debe ser diseado para ajustarse a la transferencia de
informacin de requisitos y los requerimientos funcionales especficos de la operacin que ha sido
solicitada.











Figura 3. 5 Representacin en UML de la interfaz para el panel de control.



En algunos casos, una interfaz se modela de una manera muy parecida a una clase. El UML define
define una interfaz de la siguiente manera [OMGOl]: "Una interfaz es un determinante de las
operaciones [pblicas] visibles de manera externa de una clase, componente u otro clasificador
(incluidos los subsistemas) sin especificacin de estructura interna". Dicho de un modo ms
simple, una interfaz es un conjunto de operaciones que describe parte del comportamiento de una
clase y proporciona acceso a esas operaciones.
Por ejemplo, la funcin de seguridad de HogarSeguro emplea un panel de control que permite al
propietario de la casa controlar ciertos aspectos de la funcin de seguridad. En una versin
avanzada del sistema, las funciones del panel de control pueden implementarse va PDA
inalmbrico o telfono mvil.
La clase PaneldeControl (figura 3.5) proporciona el comportamiento asociado con un teclado y,
por lo tanto, debe implementar operaciones de leerTeclaPresionada() y decodificafTecla(). Si estas
operaciones se suministrarn a otra clase (en este caso, a PDAInalmbrico y TelfonoMvil),
resulta intil definir una interfaz como la que se muestra en la figura. La interfaz llamada Teclado
se muestra como un estereotipo de <<interfaz>> o como un crculo pequeo y etiquetado que se
conecta a la clase con una lnea. La interfaz se define sin atributos y con el conjunto de
operaciones necesarias para lograr el comportamiento de un teclado.
La lnea punteada con un tringulo abierto en su extremo (figura 3.5) indica que la clase
PaneldeControl proporciona operaciones de Teclado como parte de su comportamiento. En UML
esto se caracteriza como una realizacin. Esto es, parte del comportamiento de PaneldeControl se
implementar al realizar las operaciones de Teclado. Estas operaciones se proporcionarn a otras
clases que entren a la interfaz.

3.5.6 Elementos de diseo al nivel de componentes.
El diseo al nivel de componentes para el software equivale a un conjunto de dibujos detallados (y
especificaciones) para cada cuarto en una casa. Estos dibujos muestran el alambrado y la
instalacin sanitaria dentro de cada cuarto, la ubicacin de los receptculos elctricos e
interruptores, llaves, lavabos, tinas, desages y armarios. Tambin describen los pisos que se
usarn, los moldes que se aplicarn, y cualquier otro detalle asociado con el cuarto. El diseo al
nivel de componentes para software describe por completo el detalle interno de cada
componente del software. Para lograrlo el diseo al nivel de componentes define estructuras de
datos para todos los objetos de datos locales, as como detalle algortmico para todo el
procesamiento que ocurre dentro de un componente y una interfaz que permite el acceso a todas
las operaciones de los componentes (comportamientos).






Figura 3. 6 Diagrama de Componente en UML, para ManejoSensor.
Dentro del contexto de la ingeniera del software orientada a objetos, un componente se
representa a manera de diagrama en UML como se muestra en la figura 3.6. En esta figura se
representa un componente llamado ManejoSensor (parte de la funcin de seguridad de
HogarSeguro). El componente est conectado a una clase llamada Sensor, la cual est asignada a
ste mediante una flecha punteada. El componente ManejoSensor realiza todas las funciones
asociadas con los sensores de HogarSeguro, entre las que se encuentran su monitoreo y
configuracin.
Los detalles de diseo de un componente se pueden modelar a muchos grados distintos de
abstraccin. En la representacin del procesamiento lgico se puede utilizar un diagrama de
actividad. El flujo detallado de procedimiento para un componente puede representarse, ya sea
mediante un pseudocdigo .

3.5.7 Elementos de diseo al nivel del despliegue

Los elementos de diseo al nivel del despliegue indican cmo se ubicarn la funcionalidad y los
subsistemas dentro del entorno computacional fsico que soportar al software. Por ejemplo, los
elementos del producto HogarSeguro estn configurados para operar dentro de tres entornos de
computacin primarios: una PC domstica, el panel de control de HogarSeguro y un servidor
ubicado en CPI Corp. (lo que proporciona acceso al sistema a travs de Internet).
Durante el diseo se desarrolla un diagrama de despliegue en UML y despus se refina, como se
muestra en la figura 3.7. En sta se muestran tres ambientes computacionales (en realidad,
debera haber ms, si se incluyen sensores, cmaras y otros). Se indican los subsistemas
(funcionalidad) que se alojan dentro de cada element de cmputo












Figura 3. 7 Diagrama de Despliegue en UML, PARA HogarSeguro.

Por ejemplo, la computadora personal aloja subsistemas que implementan seguridad, vigilancia,
administracin del hogar y caractersticas de comunicacin. Adems, se ha diseado un
subsistema de acceso externo para controlar todos los intentos de acceso al sistema HogarSeguro
desde una fuente externa. Cada subsistema sera elaborado para indicar los componentes que
implementa. El diagrama mostrado en la figura 3.7 est en forma de descriptor. Esto significa que
el diagrama de despliegue muestra el entorno computacional, pero no indica de manera explcita
detalles de configuracin. Por ejemplo, no se identifica la "computadora personal". Podra ser una
"Wintel" PC o una Macintosh, una estacin de trabajo Sun o una Linux-box. Estos detalles se
proporcionan cuando el diagrama de despliegue se revisa en forma de instancia durante etapas
posteriores del diseo o cuando comienza la construccin. Se identifica cada instancia del
despliegue (una configuracin de hardware con un nombre especfico.

3.6 Diseo de Software Basado en Patrones
Los mejores diseadores en cualquier campo de trabajo tienen la misteriosa habilidad de
vislumbrar patrones que caracterizan un problema y los patrones correspondientes que pueden
combinarse para crear una solucin. A travs del proceso de diseo, un ingeniero de software
debe buscar toda oportunidad para reutilizar patrones de diseo existentes (cuando cumplen las
necesidades de un diseo) en vez de crear nuevos.
3.6.1 Descripcin de un patrn de diseo
Las disciplinas maduras de la ingeniera utilizan miles de patrones de diseo. Por ejemplo, un
ingeniero mecnico utiliza un eje de dos pasos como un patrn de diseo clave. Los atributos
(dimetros del eje, dimensiones del orificio de las llaves, etctera) y las operaciones (por ejemplo,
la rotacin del giro y la conexin del giro) son inherentes al patrn. Un ingeniero elctrico utiliza
un circuito integrado (un patrn de diseo en extremo complejo) para resolver un elemento
especfico de un problema nuevo. Los patrones de diseo pueden describirse empleando la
plantilla [MAI03] que se muestra en el recuadro "Plantilla del patrn de diseo".

Una descripcin del patrn de diseo puede considerar tambin un conjunto de fuerzas de diseo,
has fuerzas de diseo describen requisitos no funcionales (por ejemplo, facilidad de
mantenimiento, portabilidad) asociados con el software en el que se aplicar el patrn. Adems,
las fuerzas definen las limitaciones que restringen la manera en que se implementara el diseo. En
esencia, las fuerzas de diseo describen el ambiente y las condiciones que deben existir para que
el patrn del diseo sea aplicable. Las caractersticas del patrn (clases, responsabilidades y
colaboraciones) indican los atributos ajustables del diseo para permitir que el patrn se ajuste a
una variedad de problemas [GAM95]. Estos atributos representan caractersticas del diseo que
pueden buscarse (por ejemplo, a travs de una base de datos) para que sea factible encontrar un
patrn apropiado. Por ltimo, la gua asociada con el uso de un patrn de diseo indica las
ramificaciones de las decisiones del diseo.
Los nombres de los patrones de diseo deben elegirse con cuidado. Uno de los problemas
tcnicos clave en la reutilizacin de software es la falta de habilidad para encontrar patrones
reutilizables existentes, a pesar de que existen cientos o miles de patrones. La bsqueda del
patrn "correcto" tiene un apoyo inmenso si se cuenta con un nombre significativo del patrn.


3.6.2 Utilizacin de patrones en el diseo
Los patrones de diseo pueden usarse durante el diseo del software. Una vez que se ha
desarrollado el modelo de anlisis, el diseador puede examinar una representacin detallada del
problema que debe resolver y las restricciones que impone el problema. La descripcin del
problema se examina en varios grados de abstraccin para determinar si es flexible para uno o ms
de los siguientes tipos de patrones de diseo.
Patrones arquitectnicos. Estos patrones definen la estructura general del software, indican las
relaciones entre los subsistemas y los componentes del software, y definen las reglas para
especificar las relaciones entre los elementos (clases, paquetes, componentes, subsistemas) de la
arquitectura.
Patrones de diseo. Estos patrones se aplican a un elemento especfico del diseo como un
agregado de componentes para resolver algn problema de diseo, relaciones entre los
componentes o los mecanismos para efectuar la comunicacin de componente a componente.
Idiomas. A veces llamados patrones de cdigo, estos patrones especficos de lenguaje por lo
general implementan un elemento algortmico o un componente, un protocolo de interfaz
especfico o un mecanismo de comunicacin entre los componentes.
Cada uno de los tipos de patrones difiere en el grado de abstraccin con el que est
representado y con el grado en el que proporciona una gua directa para la acti vidad de
construccin (en este caso, codificacin) del proceso de software.
3.6.3 Marcos de trabajo
En algunos casos es necesario proporcionar una infraestructura esqueltica especfica de
implementacin, llamada marco de trabajo, para el trabajo de diseo. Esto es, el diseador puede
seleccionar una "mini arquitectura reutilizable que ofrezca el comportamiento y la estructura
genrica para una familia de abstracciones de software, junto con un contexto... que especifique
su colaboracin y uso dentro de un dominio dado" [APP98].
Un marco de trabajo no es un patrn arquitectnico, sino un esqueleto con una coleccin de
"puntos de conexin" (tambin llamados ganchos y ranuras) que le permiten adaptarse a un
dominio de un problema especfico. Los puntos de conexin permiten al diseador integrar clases
o funcionalidad especficas del problema dentro del esqueleto. En un contexto orientado al objeto,
un marco de trabajo es una coleccin de clases que cooperan.
En esencia, el diseador de un marco de trabajo argumentar que una mini arquitectura
reutilizable se puede aplicar a todo el software que se desarrollar dentro de un dominio limitado
de aplicacin. Para que sean ms efectivos, los marcos de trabajo se aplican sin cambios. Se
pueden agregar elementos de diseo adicionales, pero slo a travs de los puntos de conexin
que permiten que el diseador desarrolle el esqueleto del marco de trabajo.












3.7 Diseo Arquitectnico
El diseo se ha descrito como un proceso de varios pasos en el cual las representaciones de la
estructura de los datos y el programa, las caractersticas de la informacin y el detalle
procedimental se sintetizan a partir de los requisitos. Esta descripcin la ampla Freeman [FRE80]:
Diseo es una actividad relacionada con la toma de decisiones, a menudo de naturaleza estructural.
Comparte con la programacin una preocupacin relacionada con abstraer la representacin de la
informacin y las secuencias del procesamiento, pero el grado de detalles es muy diferente en los
extremos. El diseo construye representaciones coherentes y bien planeadas de los programas, que se
concentran en las interrelaciones entre las partes al nivel ms elevado y las operaciones lgicas en los
niveles inferiores.
Los mtodos de diseo del software se derivan de la consideracin de cada uno de los tres
dominios del anlisis del modelo. Los dominios de la informacin, la funcin y el comportamiento
sirven como gua para el diseo del software. En este captulo se presentarn los mtodos
requeridos para crear "representaciones coherentes y bien planeadas" de las capas de los datos y
la arquitectura del modelo de diseo. El objetivo es proporcionar un enfoque sistemtico del
diseo arquitectnico: los planos preliminares que se utilizan.

Qu es?
Es el diseo arquitectnico representa la estructura de datos y los componentes del programa
necesarios para construir un sistema computacional. Asume el estilo arquitectnico que tomara
el sistema, la estructura y las propiedades de los componentes que constituyen el sistema y las
interrelaciones entre todos los componentes arquitectnicos de un sistema.
Quin los hace?
Aunque un ingeniero de software puede disear los datos y la arquitectura, a menudo el trabajo
se asigna a especialistas cuando se construyen sistemas grandes complejos. Un diseador de base
de datos o de almacene de datos crea la arquitectura de datos del sistema. El arquitecto del
sistema selecciona un estilo arquitectnico apropiado para los requisitos derivados durante la
ingeniera del sistema y el anlisis de las requisitos del software.
Por qu es importante?
Nadie tratara de construir una casa sin un plano, verdad? Tampoco empezara a trazar planos
bosquejando la distribucin de la fontanera. Necesitara un panorama general (la propia casa)
antes de preocuparse por los detalles. Eso es lo que hace el diseo arquitectnico: proporciona
una vista gene-Era) y asegura que se obtenga lo que se desea.
Cules son los pasos?
El diseo arquitectnico empieza con el diseo de los datos y luego pasa a la derivacin de una o
ms representaciones de la estructura arquitectnica del sistema. Se analizan los estilos o
patrones arquitectnicos alternos para derivar la estructura que se amolda mejor a los requisitos
del cliente. En cuanto se selecciona una opcin se elabora la arquitectura empleando un mtodo
de diseo apropiado.
Cul es el producto obtenido?
Un modelo que abarca la arquitectura de los datos y la estructura del programa se crea durante
esta etapa del diseo. Adems, se describen las propiedades de los componentes y sus relaciones
(interacciones).
Cmo puedo estar seguro de que lo he hecho correctamente?
En cada etapa se revisan los productos resultantes del diseo de del software para verificar la
claridad, correccin, el grado en que han completado y su consistencia con los requisitos y ente
unos y otros.

3.7.1 Arquitectura de Software
En su notable libro sobre el tema, Shaw y Garlan [SHA96] analizan la arquitectura del software de
la siguiente manera:
Desde la primera vez que un programa se dividi en mdulos, los sistemas de software han tenido
arquitecturas, y los programadores han sido responsables de las interacciones entre los mdulos y las
propiedades globales del ensamblaje. Histricamente, las arquitecturas han estado implcitas (como
accidentes de implementacin o sistemas heredados del pasado). Los buenos desabolladores de
software han adoptado con frecuencia uno o varios patrones arquitectnicos como estrategia para la
organizacin del sistema, pero los emplean de manera informal y no tienen medios para hacerlos
explcitos en el sistema resultante.

Hoy, la arquitectura del software efectiva y su representacin y diseo explcitos se han vuelto
temas dominantes en la ingeniera del software.

3.7.2 Qu es la arquitectura?
Cuando se analiza la arquitectura de un edificio vienen a la mente muchos atributos diferentes. En
el aspecto ms simple se considera la forma general de la estructura fsica. Pero, en realidad, la
arquitectura es mucho ms, es la manera en que los diversos componentes de un edificio se
integran para formar un todo cohesionado. Es la manera en que el edificio se amolda a su
ambiente y se combina con otros edificios vecinos. Es el grado en el cual el edificio cumple con el
propsito establecido y en que satisface las necesidades de su propietario.
Es la percepcin esttica de la estructura el impacto visual del edificio y la manera en que las
texturas, los colores y los materiales se combinan para crear la fachada externa y el "entorno
viviente" del interior. Son pequeos detalles: el diseo de la iluminacin, el tipo de piso, la
colocacin de las cosas que cuelgan de las paredes, la lista es casi interminable. Finalmente, se
trata de un arte.


Pero qu pasa con la arquitectura del software? Bass, Clement y Kazman [BAS03] definen este
trmino elusivo de la siguiente manera:
La arquitectura del software de un programa o sistema de cmputo es la estructura o las
estructuras del sistema, que incluyen los componentes del software, las propiedades visibles
externamente de esos componentes y las relaciones entre ellos.
La arquitectura no es el software operativo. En cambio, es una representacin que permite que un
ingeniero del software: 1) analice la efectividad del diseo para cumplir con los requisitos
establecidos, 2) considere opciones arquitectnicas en una etapa en que an resulta
relativamente fcil hacer cambios al diseo, y 3) reduzca los riesgos asociados con la construccin
del software.



Esta definicin destaca el papel de los "componentes del software" en cualquier representacin
arquitectnica. En el contexto del diseo arquitectnico, un componente de software es algo tan
simple como un mdulo del programa o una clase orientada a objetos, pero tambin se extiende
para incluir bases de datos y middleware que permita configurar una red de clientes y servidores.

El diseo de la Arquitectura del software considera dos niveles de la pirmide del diseo ( figura
3.1)el diseo de datos y el diseo Arquitectnico. En el contexto del anlisis anterior, el diseo de
los datos permite representar el componente de datos de la arquitectura en sistemas
convencionales y definiciones de clase (atributos y operaciones de encapsulamiento) de los
sistemas orientados a objetos. El diseo arquitectnico se concentra en la representacin de la
estructura de los componentes del software, sus propiedades e interacciones.
3.7.3 Por qu es importante la arquitectura?
En un libro dedicado a la arquitectura del software, Bass y sus colegas [BAS03] identifican tres
razones clave por las cuales la arquitectura del software es importante:
Las representaciones de la arquitectura del software permiten la comunicacin entre todas
las partes (participantes) interesadas en el desarrollo de un sistema de cmputo.
La arquitectura destaca las decisiones iniciales relacionadas con el diseo que tendrn un
impacto profundo en todo el trabajo de la ingeniera del software que le sigue y, lo que
tambin resulta importante, en el xito final del sistema como entidad operacional.
La arquitectura "constituye un modelo relativamente pequeo e intelectualmente
comprensible de cmo est estructurado el sistema y cmo trabajan juntos sus
componentes" [BAS03].
El modelo de diseo arquitectnico y los patrones arquitectnicos que contiene son transferibles.
Es decir, los estilos y patrones se aplican al diseo de otros sistemas y representan otro conjunto
de abstracciones que permiten a los ingenieros de software describir la arquitectura de software
de manera predecible.

3.8 Diseo de Datos

La accin de diseo de datos traduce los objetivos de datos definidos como parte del modelo de
anlisis en estructuras globales al nivel de componentes de software y , cuando es necesario una
arquitectura de base de datos al nivel de aplicacin. En algunas situaciones debe disearse y
construirse una base de datos especficamente para un nuevo sistema. Sin embargo, en otras se
emplean una o ms bases de datos existentes.

3.8.1 Diseo de Datos de nivel arquitectnico

Hoy los negocios grandes y pequeos estn inundados de datos. No resulta poco comn que
incluso un negocio de tamao moderado tenga docenas de bases de datos que sirven a muchas
aplicaciones que abarcan cientos de gigabytes de datos. El reto consiste en extraer informacin
til de este entorno de datos, sobre todo cuando la informacin se deseada tiene funcionalidad
cruzada, por ejemplo informacin que solo se obtienen si los datos especficos de mercadotcnica
estn relacionados de manera cruzada con los datos de la ingeniera de producto.

Para resolver este desafa la comunidad de empresas de la tecnologa de la informacin( TI) ha
desarrollado la tcnica de minera de datos, tambin denominada descubrimiento de
conocimientos de base de datos (DCBD) que recorre base de datos existentes con el fin de
extraer informacin apropiada en el mbito de los negocios. Sin embargo la existencia de
mltiples bases de datos, sus diferentes estructuras, el grado de detalle que contiene y muchos
otros factores hacen que la minera de datos resulte difcil dentro de un entorno existente de una
base de datos. Una solucin alterna denominada almacn de datos agrega una capa adicional a
la arquitectura de datos. Un almacn de datos es un entorno de datos independientes
Que no est directamente integrado en las aplicaciones cotidianas, pero que abarca todos los
datos utilizados en un negocio. En cierto sentido, un almacn de datos en una base de datos
grande e independiente que tiene acceso a los datos almacenados en las bases de datos que
sirven al conjunto de aplicaciones requeridas en una base de datos. Conviene ms dejar el anlisis
detallado del diseo de estructura de datos, base de datos y almacenes de datos.

3.8.2 Diseo de datos a nivel de Componentes

El diseo de datos a nivel de componentes se concentra en la representacin de estructuras de
datos a los que se tiene acceso de forma directa mediante uno o ms componentes de software.
Wasserman a propuesto un conjunto de principios que se emplean para especificar y disear estas
estructuras de datos. En realidad el diseo de datos empieza durante la creacin del modelo de
anlisis. Si se recuerda el anlisis y el diseo de requisitos suele suponerse, se considera el
siguiente conjunto de principios para la especificacin de datos.



1.-Los principios de anlisis sistemtico aplicado a la funcin y el comportamiento tambin deben
aplicarse a los datos. Tambin es necesario desarrollar y revisar las representaciones del flujo de
datos y el contenido, identificar los objetos de datos, considerar organizaciones alternas de datos
y evaluar el impacto de los datos que modelan el diseo del software.

2.- Deben identificarse todas las estructuras de datos y las operaciones que se realizaran. El diseo
de una estructura de datos eficiente debe tener en cuenta las operaciones que se realizaran en la
estructura de datos. Los atributos y operaciones encapsulados en una clase satisfacen este
principio.

3.-Debe establecerse un mecanismo para la definicin del contenido de cada objeto de datos y
usarlo para definir los datos y las operaciones que se les aplican. Los diagramas de clase (captulo 8)
definen los elementos de datos (atributos) contenidos dentro de una clase y el procesamiento
(operaciones) que se aplica a esos elementos de datos.
4.-Las decisiones del diseo al nivel de datos deben posponerse hasta una de las ltimas etapas del
proceso de diseo. Un proceso de refinacin paso a paso es aplicable al diseo de datos. Es decir,
la organizacin general de los datos puede definirse durante el anlisis de los requisitos, refinarse
durante el trabajo de diseo de datos y especificarse de manera detallada durante el diseo al
nivel de componentes.
5.-La representacin de una estructura de datos slo debe conocerse para los mdulos que deben
usar directamente los datos que contiene tal estructura. El concepto de ocultacin de la
informacin y el concepto relacionado del acoplamiento (captulo 9) proporcionan conocimientos
importantes sobre la calidad de un diseo de software.
6.-Debe desarrollarse una biblioteca de estructuras de datos tiles y tambin las operaciones que
pueden aplicrseles. Esto se logra con una biblioteca de clases.
7.- Un diseo de software y un lenguaje de programacin deben dar soporte a la especificacin y la
realizacin de os tipos de datos abstractos. La implementacin de una sofisticada estructura de
datos llega a volverse excesivamente difcil si no existen medios para la especificacin directa de la
estructura en el lenguaje de programacin elegido para la implementacin.
Estos principios forman una base para un enfoque de diseo de datos, al nivel de componentes,
que se integre a las actividades de anlisis y diseo.
3.9 Estilos y patrones Arquitectnicos
Cuando un constructor estadounidense usa la frase "colonial con una sala al centro" (centre hall
colonial) para describir una casa, la mayora de quienes estn familiarizados con las casas en
Estados Unidos evocar una imagen general del aspecto de la casa y de su plano general.
El constructor ha usado un estilo arquitectnico como mecanismo descriptivo para diferenciar la
casa de otros estilos (por ejemplo, marco en A, rancho elevado, Cape Cod). Pero algo ms
importante es que el estilo arquitectnico tambin es una plantilla para la construccin. Resulta
necesario proporcionar mayores detalles de la casa. Se deben especificar sus dimensiones finales,
agregar caractersticas personalizadas, determinar los materiales de construccin, pero el estilo
("colonial con sala ai centro") es el que gua el trabajo del constructor.



El software que se construye para sistemas de cmputo tambin muestra uno o muchos estilos
arquitectnicos. Cada estilo describe una categora de sistemas que abarca 1) un conjunto de
componentes (por ejemplo, una base de datos, mdulos computacionales) que realizan una
funcin requerida por el sistema; 2) un conjunto de conectores que permiten la "comunicacin,
coordinacin y cooperacin" entre los componentes; 3) restricciones que definen cmo se
integran los componentes para formar el sistema, y 4) modelos semnticos que permiten a un
diseador, mediante el anlisis de las propiedades conocidas de las partes que lo integran
(BAS03), comprender las propiedades generales de un sistema.

Un estilo arquitectnico es una transformacin impuesta al diseo de todo un sistema. El objetivo
es establecer una estructura para todos los componentes del sistema. En caso de que una
arquitectura existente se vaya a someter a reingeniera la imposicin de un estilo arquitectnico
desembocar en cambios fundamentales en la estructura del software, incluida una reasignacin
de la funcionalidad de los componentes [BOS00].

Un patrn arquitectnico, al igual que un estilo, impone una transformacin en el diseo de una
arquitectura. Sin embargo, un patrn difiere de un estilo en varios elementos fundamentales: 1) el
alcance de un patrn es menor, ya que se concentra en un aspecto en lugar de hacerlo en toda la
arquitectura; 2) un patrn impone una regla sobre la arquitectura, pues describe la manera en que
el software manejar algn aspecto de su funcionalidad al nivel de la infraestructura (por ejemplo,
concurrencia) [BOS00]; 3) los patrones arquitectnicos tienden a abarcar aspectos especficos del
comportamiento dentro del contexto de la arquitectura (por ejemplo, cmo maneja una
aplicacin en tiempo real la sincronizacin o las interrupciones). Los patrones se usan junto con un
estilo arquitectnico para determinar la forma de la estructura general de un sistema. En la
siguiente seccin se expondrn estilos y patrones arquitectnicos de uso comn en el software.
3.9.1 Una breve taxonoma de estilos arquitectnicos
Aunque se han creado millones de sistemas de cmputo en los ltimos 50 aos, la gran mayora
puede clasificarse (consltense [SHA96], [BUS96], [BAS03]) en un nmero relativamente pequeo
de estilos arquitectnicos:
Arquitectura centrada en datos. Un almacn de datos (por ejemplo, un archivo o una base de
datos) se encuentra en el centro de esta arquitectura; otros componentes tienen acceso a l y
cuentan con la opcin de actualizar, agregar, eliminar o, por otra parte, modificar los datos de ese
almacn. En la figura 3.8 se ilustra un estilo tpico centrado en datos. El software cliente tiene
acceso a un almacn central. En algunos casos ste es pasivo. Es decir, el software cliente accede a
los datos independientemente de cualquier cambio hecho a los datos o a las acciones de otro soft-
ware cliente. Una variacin de este enfoque transforma el depsito en un "pizarrn" que enva
notificaciones al software cliente cuando cambian los datos de inters para el cliente.


Figura 3. 8 Arquitectura Centrada en datos
Una arquitectura centrada en datos promueve la capacidad de integracin [BAS03], Esto significa
que es posible cambiar componentes existentes y agregar nuevos componentes cliente a la
arquitectura sin preocuparse por otros clientes (ya que los componentes cliente operan en forma
independiente). Adems, es posible pasar datos entre clientes empleando el mecanismo del
pizarrn (es decir, el componente pizarrn sirve para coordinar la transferencia de informacin
entre clientes). Los componentes cliente ejecutan los procesos de manera independiente.
Arquitectura de flujo de datos. Esta arquitectura se aplica cuando los datos de entrada se habrn
de transformar en datos de salida mediante una serie de componentes para el clculo o la
manipulacin. Una estructura de tuberas y filtros (figura 3.9) tiene un conjunto de componentes,
denominados/Filtros, conectados por tuberas que transmiten datos de un componente al
siguiente. Cada filtro funciona sin tomar en cuenta si los componentes tienen flujo ascendente o
descendente; est diseado para esperar la entrada de datos con cierta forma y producir su salida
(al siguiente filtro) de una forma especfica. Sin embargo, no es necesario que el filtro conozca el
funcionamiento de los filtros vecinos.







Figura 3. 9 Arquitectura de Flujo de Datos.


Si el flujo de datos degenera en una sola lnea de transformaciones se denomina
procesamiento por lotes secuencial. Esta estructura acepta un procesamiento por lotes de
datos y luego aplica una serie de componentes secuenciales (filtros) para transformarlos.
Arquitectura de llamada y retorno. Este estilo arquitectnico permite que un diseador de
software (arquitecto del sistema) obtenga una estructura de programa que resulta
relativamente fcil modificar y cambiar de tamao. En esta categora hay dos subestilos
[BASCO]:
Arquitectura de programa principal/subprograma. Esta estructura de programa
clsica separa la funcin en una jerarqua de control donde un programa "principal"
invoca a varios componentes de programa, que a su vez pueden invocar a otros
componentes. En la figura 3.10 se ilustra una arquitectura de este tipo.
Arquitectura de llamada de procedimiento remoto. Los componentes de una ar-
quitectura de programa principal/subprograma se distribuyen entre varias
computadoras de una red.


Figura 3. 10 Arquitectura de Programa principal / Subprograma









Figura 3. 11 Arquitectura Estratificada.

Arquitectura orientada a objetos. Los componentes de un sistema encapsulan los datos y las
operaciones que deben aplicarse para manipular los datos. La comunicacin y coordinacin entre
componentes se consigue mediante el paso de mensajes.
Arquitectura estratificada. En la figura 3.11 se ilustra la estructura bsica de una arquitectura
estratificada. Hay varias capas definidas; cada una de ellas realiza operaciones que se acercan
progresivamente al conjunto de instrucciones de la mquina. En la capa externa los componentes
sirven a las operaciones de interfaz de usuario. En la capa interna los componentes sirven como
interfaz con el sistema operativo. Las capas intermedias proporcionan servicios de utilera y de
software de aplicaciones.
Estos estilos arquitectnicos slo son un pequeo subconjunto de los que dispone el diseador de
software.
2
Una vez que la ingeniera de requisitos define las caractersticas y restricciones del
sistema que habr de construirse, podrn elegirse el estilo arquitectnico o la combinacin de
estilos que mejor combinen con las caractersticas y restricciones. En muchos casos ser
apropiado ms de un estilo y podran disearse y evaluarse distintas opciones. Por ejemplo, en
muchas aplicaciones de base de datos se combina un estilo por capas (apropiado para casi todos
los sistemas) con una arquitectura centrada en datos.
3.9.2 Patrones arquitectnicos
Si el constructor decide construir una casa colonial con sala al centro slo podr aplicar un estilo
arquitectnico. Los detalles del estilo (por ejemplo, nmero de chimeneas, fachada de la casa,
colocacin de puertas y ventanas) variarn considerablemente, pero una vez que se ha tomado la
decisin de la arquitectura general de la casa, el estilo se impondr al diseo.
Los patrones arquitectnicos difieren un poco. Por ejemplo, cada casa (y todo estilo arquitectnico para
casas) emplea un patrn cocina, el cual define la necesidad de colocar los artculos bsicos de cocina,
un fregadero, alacenas y, posiblemente, reglas para ubicar cosas relacionadas con el flujo de trabajo
en la habitacin. Adems, el patrn podra especificar la necesidad de cubiertas y acabados,
iluminacin, interruptores de pared o una isla central, pisos, etc. Obviamente, hay ms de un di-
seo de cocina, pero todo diseo se concebir dentro del contexto de la "solucin" que sugiere el
patrn cocina.


Como ya se indic, los patrones arquitectnicos para el software definen un enfoque especfico
para el manejo de alguna caracterstica de comportamiento del sistema. Bosch [BOS00] define
varios patrones arquitectnicos. En los siguientes prrafos se presentan ejemplos representativos.
Concurrencia. Muchas aplicaciones deben manejar varias tareas de manera tal que simulen
paralelismo (es decir, esto ocurre cada vez que un solo procesador maneja varias tareas
"paralelas" o componentes). Una aplicacin tiene varias maneras de manejar la concurrencia, y
cada una se presenta mediante un patrn arquitectnico diferente. Por ejemplo, un enfoque
consiste en usar un patrn de manejo de procesos del sistema operativo que ofrece caractersticas
integradas del sistema operativo que permiten la ejecucin concurrente de los componentes. El
patrn tambin incorpora funcionalidad del sistema operativo que maneja la comunicacin entre
los procesos, la calendarizacin y otras funciones requeridas para alcanzar la concurrencia. Otro
mtodo sera definir un calendarizador de tareas al nivel de aplicacin. Un patrn calendarizador
de tareas contiene un conjunto de objetos activos, y cada uno de ellos incluye una operacin tic/)
[BOS00]. El calendarizador invoca peridicamente tic/) para cada objeto, que luego realiza las
funciones que debe realizar antes de regresar el control al calendarizador, mismo que invoca de
nuevo la operacin tic/) para el siguiente objeto concurrente.
Persistencia. Los datos persisten si sobreviven despus de la ejecucin del proceso que los cre.
Los datos persistentes se almacenan en una base de datos o un archivo; en un momento
posterior, otros procesos tienen la opcin de leerlos o modificarlos. En los entornos orientados a
objetos la idea de un objeto persistente extiende un poco ms el concepto de persistencia. Los
valores de todos los atributos del objeto, el estado general de ste y otra informacin
complementaria se almacenan para su aplicacin y recuperacin posterior. En general, se
emplean dos patrones arquitectnicos para lograr la persistencia: 1) un patrn de sistema de
administracin de base de datos que aplica las capacidades de almacenamiento y recuperacin de
un sistema de administracin de base de datos a la arquitectura de la aplicacin, o 2) un patrn de
persistencia al nivel de la aplicacin que construye caractersticas de persistencia en la
arquitectura de sta (por ejemplo, el software de procesamiento de palabras que maneja su
propia estructura de documento).
Distribucin. El problema de la distribucin dirige la manera en que se comunican entre s los
sistemas, o los componentes de stos, en un entorno distribuido. Este problema incluye dos
elementos: 1) la manera en que las entidades se conectan entre s, y 2) la naturaleza de la
comunicacin. El patrn arquitectnico ms comn es- tableado para dirigir el problema de la
distribucin es el de corredor. Un corredor acta como "intermediario" entre el componente
cliente y un componente servidor. El cliente enva un mensaje al corredor (que contiene toda la
informacin apropiada para que se realice la comunicacin), el cual completa la conexin. CORBA
es un ejemplo de una arquitectura de corredor.
Antes de elegir cualquiera de los patrones arquitectnicos indicados en los prrafos anteriores,
debe evaluarse si es apropiado para la aplicacin y el estilo arquitectnico general, adems de
evaluar su facilidad de mantenimiento, confiabilidad, seguridad y desempeo.
3.9.3 Organizacin y refinamiento

Debido a que el proceso de diseo suele dejar a un ingeniero de software con varias opciones
arquitectnicas, es importante establecer un conjunto de criterios de diseo para evaluar un
diseo arquitectnico. Las siguientes preguntas [BAS03] proporcionan una visin especfica del
estilo arquitectnico que se ha derivado.

Control. Cmo se maneja el control dentro de la arquitectura? Existe una jerarqua de control
distintiva y, si es as, cul es la funcin de los componentes dentro de esta jerarqua de control?
Cmo transfieren los campos el control dentro del sistema? Cmo se comparte el control entre
los componentes? Cul es la topologa del control (es decir, cul es la forma geomtrica que
asume el control)? Est sincronizado el control o los componentes operan asincrnicamente?

Datos. Cmo se comunican los datos entre los componentes? El flujo de datos es continuo o los
objetos de datos se pasan espordicamente al sistema? Cul es el modo de transferencia de los
datos (por ejemplo, los datos se pasan de un componente a otro o estn disponibles globalmente
para compartirse entre los componentes del sistema)? Existen componentes de datos (por
ejemplo, un pizarrn o almacn) y, de ser as, cul es su papel? Cmo interactan los
componentes funcionales con los de datos? Los componentes de datos son pasivos o activos (es
decir, interactan activamente con otros componentes del sistema)? Cmo interactan los datos
y el control dentro del sistema?

Estas preguntas proporcionan al diseador una evaluacin temprana de la calidad del diseo y
sientan las bases para un anlisis ms detallado de la arquitectura.




3.10 Diseo Arquitectnico
Cuando empieza el diseo arquitectnico debe ponerse en contexto el software que se habr de
desarrollar; es decir, el diseo debe definir las entidades externas (otros sistemas, otros
dispositivos, otras personas) con las que interacta el software y tambin la naturaleza de la
interaccin. Esta informacin suele adquirirse del modelo de anlisis y toda la dems informacin
reunida durante la ingeniera de requisitos. Una vez que se ha modelado el contexto y que se han
descrito todas las interfaces externas del software, el diseador especifica la estructura del sistema al
definir y refinar los componentes del software que implementan la arquitectura.
Este proceso prosigue de manera iterativa hasta que se obtiene una estructura arquitectnica
completa.

3.10.1 Representacin del sistema en el contexto
Un diagrama de contexto del sistema cumple con este requisito al representar el flujo de la informacin
dentro y fuera del sistema, la informacin del usuario y el procesamiento relevante de soporte. Al nivel
de diseo arquitectnico, un arquitecto del software aplica un diseo de contexto arquitectnico (DCA)
para modelar la manera en que el software interactuar con las entidades ubicadas ms all de sus
lmites. La estructura genrica de los diagramas de contexto arquitectnico se ilustra en la figura 3.12.
Si se toma como referencia la figura, los sistemas que interactan con el sistema de destino (el sistema
para el que se est desarrollando un diseo arquitectnico) se representan as:
Sistemas superordinados-. los que emplean el sistema de destino como parte de algn esquema de
procesamiento de nivel ms elevado.
Sistemas subordinados: los que utiliza el sistema de destino y que proporcionan los datos o el
procesamiento necesarios para completar la funcionalidad del sistema de destino.








Figura 3. 12 Diagrama de Contexto arquitectnico (Adaptado de BOSOO-)
Sistemas al nivel de par: los que interactan de igual a igual (es decir, la informacin la producen
o consumen los pares y el sistema de destino).
Actores: las entidades (personas, dispositivos) que interactan con el sistema de destino
produciendo o consumiendo informacin necesaria para el procesamiento de requisitos.
Cada una de estas entidades externas se comunica con el sistema de destino mediante una interfaz
(los pequeos rectngulos sombreados).
Para ilustrar la utilizacin del DCA considrese de nuevo la funcin de seguridad casera del producto
HogarSeguro. El controlador general y el sistema de Internet del producto HogarSeguro son
superdordinados a la funcin de seguridad y se muestran arriba de la funcin en la figura 3.13 La funcin
de vigilancia es un sistema par y emplea (es empleado por) la funcin de seguridad en versiones
posteriores del producto. Los paneles de propietario y control son actores que actan como
productores y consumidores de la informacin utilizada, producida (o de ambos tipos) por el software
de seguridad. Por ltimo, el software de seguridad emplea los sensores, que se muestran como
subordinados de ste.
Como parte del diseo arquitectnico tendran que especificarse los detalles de cada interfaz
mostrada en la figura 3.13. En esta etapa deben identificarse todos los datos que fluyen al interior o el
exterior del sistema de destino.
3.10.2 Definicin de arquetipos
Un arquetipo es una clase o un patrn que representa una abstraccin central importantsima en el
diseo de una arquitectura para el sistema de destino. En general, se requiere un conjunto
relativamente pequeo de arquetipos para disear incluso sistemas relativamente complejos. La
arquitectura del sistema de destino la integran arquetipos, que representan elementos estables de
la arquitectura pero que pueden dar paso a instancias de muchas maneras diferentes, con base en
el comportamiento del sistema.


Figura 3. 13 Diagrama de contexto arquitectnico para la funcin de seguridad de HogarSeguro
En muchos casos, los arquetipos se derivan al examinar las clases de anlisis definidas como parte
del modelo de anlisis. Si se contina el anlisis de la funcin de seguridad casera de HogarSeguro
se definiran los siguientes arquetipos:

Nodo. Representa una coleccin cohesiva de elementos de entrada y salida en la funcin
de seguridad casera. Por ejemplo, un nodo estara integrado por 1) varios sensores y 2)
varios indicadores de alarma (salida).
Detector. Una abstraccin que abarca todo el equipo de sensores que alimenta
informacin en el sistema de destino.
Indicador. Una abstraccin que representa todos los mecanismos (por ejemplo, sirena de
alarma, luces parpadeantes, timbre) para indicar que est ocurriendo una condicin de
alarma.
Controlador. Una abstraccin que describe el mecanismo que permite el armado o
desarmado de un nodo. Si los controladores residen en una red tienen la capacidad de
comunicarse entre s.
Cada uno de estos arquetipos se describe con la notacin UML, como se muestra en la figura 3.14.
Recurdese que los arquetipos forman la base de la arquitectura pero son abstracciones que
deben refinarse an ms a medida que avanza el diseo arquitectnico. Por ejemplo, Detector
podra refinarse en una jerarqua de clase de sensores.
3.10.3 Refinamiento de la arquitectura en componentes
A medida que se refina la arquitectura del software en componentes, la estructura del sistema
empieza a emerger. Pero cmo se eligen estos componentes?


Figura 3. 14 Relaciones UML. Para los Arquetipos para la funcin de seguridad de HogarSeguro.
Para responder, el diseador de la arquitectura empieza con las clases descritas como parte del
modelo de anlisis. Estas clases de anlisis representan entidades dentro del dominio de la
aplicacin (negocio) que deben atenderse dentro de la arquitectura del software. Por tanto, el
dominio de la aplicacin es una fuente para la derivacin y el refinamiento de los componentes.
Otra fuente es el dominio de la infraestructura. La arquitectura debe adecuarse a muchos
componentes de infraestructura que habilitan los componentes de la aplicacin, pero que no
tienen conexin de negocios con el dominio de la aplicacin.

Por ejemplo, los componentes de administracin de memoria, de comunicacin, de base de datos
y de administracin de tareas suelen integrarse en la arquitectura del software.
La interfaz descrita en el diagrama de contexto de la arquitectura) indica que uno o ms
componentes especializados procesan los datos que fluyen por la interfaz. En algunos casos (por
ejemplo, una interfaz grfica de usuario) debe disearse una arquitectura completa de
subsistemas con muchos componentes.

Continuando con la funcin de seguridad casera de HogarSeguro, se definir el conjunto de
componentes de nivel superior que atienden la siguiente funcionalidad:
Administracin de comunicacin extema: coordina la comunicacin de la funcin de
seguridad con entidades externas; por ejemplo, sistemas de Internet, notificacin
externa de alarma.
Procesamiento del panel de control: maneja toda la funcionalidad del panel de
control.
Manejo del detector, coordina el acceso a todos los detectores conectados al
sistema.
Procesamiento de alarma: verifica todas las condiciones de alarma y acta sobre
ellas.
Cada uno de estos componentes de nivel superior tendra que elaborarse iterativamente y
luego posicionarse dentro de la arquitectura general de HogarSeguro. Para cada uno se
definiran clases de diseo (con los atributos y las operaciones apropiadas). Sin embargo, es
importante observar que los detalles de diseo de todos los atributos y las operaciones slo
se especificaran hasta la realizacin del diseo en el nivel de componentes
En la figura 3.15 se ilustra la estructura arquitectnica general (representada como un
diagrama de componentes UML). El componente Manejo de comunicacin externa
Figura 3. 15 Estructura General de la Arquitectura de HogarSeguro con componentes de nivel superior








Adquiere las transacciones provenientes de los componentes que procesan la interfaz grfica de
usuario de HogarSeguro y la interfaz de Internet. El componente director de HogarSeguro maneja esta
informacin y selecciona la funcin de producto apropiada (en este caso, seguridad). El
componente procesamiento de panel de control interacta con el propietario para armar o
desarmar la funcin de seguridad. El componente manejo de detector agrupa los sensores para
detectar una condicin de alarma, y el componente procesamiento de alarma produce una salida
cuando se detecta la alarma.
3.10.4 Descripcin de la creacin de instancias del sistema
El diseo arquitectnico que se ha modelado hasta este punto a todava es de un nivel
relativamente alto. Se ha representado el contexto del sistema; se han definido los arquetipos que
indican las abstracciones importantes dentro del dominio del problema; es evidente la estructura
general del sistema; y se han identificado los principales componentes del software. Sin embargo,
an se necesita mayor refinamiento (recurdese que todo el diseo es iterativo).Esto se logra
desarrollando una instancia de la arquitectura. Es decir, la arquitectura se aplica a un problema
especfico con el propsito de demostrar que la estructura y los componentes son apropiados.
En la figura 3.16 se ilustra una instancia de la arquitectura HogarSeguro para el sistema de
seguridad. Los componentes que muestra la figura 3.15se retinan an ms para mostrar detalles
adicionales. Por ejemplo, el componente manejo de detector interacta con el componente de
infraestructura calendarizador que implementa el agrupa-miento "concurrente" de cada objeto
sensor del sistema de seguridad. Una elaboracin similar se realiza para cada uno de los
componentes representados en la figura 3.16.

Figura 3. 16 Instancia de la Funcin de seguridad con elaboracin de componentes.



3.11 Evaluacin De Diseos Arquitectnicos Alternos
En el mejor de los casos, el diseo produce varias opciones arquitectnicas que se evalan para
determinar cul es la ms apropiada respecto al problema que habr de resolverse. En las
siguientes secciones se analizaran diseos arquitectnicos alternos.


3.11.1 Un mtodo de anlisis de compensacin para la arquitectura
El Instituto de Ingeniera del Software (SEI, por sus siglas en ingls) ha desarrollado un mtodo de
anlisis de compensacin para la arquitectura (MACA) [KAZ98] que define un proceso de evaluacin
iterativo para las arquitecturas del software. Las siguientes actividades de anlisis del diseo se
realizan iterativamente:
1. Recopilar escenarios. Se desarrolla un conjunto de casos de uso para representar el sistema
desde el punto de vista del usuario.
2. Deducir requisitos, restricciones y descripcin de entornos. Esta informacin se requiere como
parte de la ingeniera de requisitos y se usa para asegurarse de que se atiendan todas las
preocupaciones de los participantes.
3. Describir los estilos/patrones arquitectnicos que se han elegido para dirigir los escenarios y
requisitos.
4. Evaluar os atributos de calidad al considerar cada atributo de manera aislada. Entre los
atributos de calidad para la evaluacin del diseo arquitectnico se incluyen confiabilidad,
desempeo, seguridad, facilidad de mantenimiento, flexibilidad, facilidad de prueba,
portabilidad, facilidad de reutilizacin e interoperabilidad.
5. Identificar la sensibilidad de los atributos de calidad respecto de varios atributos
arquitectnicos para un estilo arquitectnico especfico. Esto se logra haciendo pequeos
cambios en la arquitectura y determinando la sensibilidad al cambio de un atributo de
calidad, como el desempeo. Cualquier atributo al que afecte significativamente la
variacin en la arquitectura se considerar un punto de sensibilidad.
6. Analizar as arquitecturas alternas (desarrolladas en el paso 3) empleando el anlisis de
sensibilidad aplicado en el paso 5. El SEI describe este enfoque de la siguiente manera
[KAZ98]:

Que son sensibles varios atributos. Por ejemplo, el desempeo de una arquitectura cliente-
servidor sera muy sensible al nmero de servidores (el desempeo aumentar, dentro de cierto
rango, al aumentar el nmero de servidores ). Por tanto, el nmero de servidores es un punto de
compensacin para esta arquitectura.
Estos seis pasos representan la primera iteracin MACA. Con base en los resultados de los pasos 5
y 6 ser posible eliminar algunas opciones arquitectnicas, modificar una o ms de las
arquitecturas restantes y representarlas con ms detalle, y luego aplicar de nueva cuenta los pasos
de MACA.

3.11.2 Complejidad arquitectnica
Una tcnica til para evaluar la complejidad general de una arquitectura determinada consiste en
considerar las dependencias entre componentes dentro de la arquitectura. Estas dependencias las
orienta la informacin, el flujo de control, o ambas, dentro del sistema. Zhao [ZHA98] sugiere tres tipos
de dependencias:
Dependencias compartidas que representan relaciones de dependencia entre consumidores que
usan el mismo recurso o los productores que producen para los mismos consumidores. Por
ejemplo, supnganse dos componentes u y v que se refieren a los mismos datos globales.
Entonces existe una relacin de dependencia compartida entre u y v.
Dependencias de flujo que representan las relaciones de dependencia entre productores y
consumidores de recursos. Por ejemplo, para dos componentes L y v, si u debe completarse
antes de que el control pase a v (prerrequisito) o si u se comunica con v mediante parmetros,
entonces existe una relacin de dependencia de flujo entre u y v.
Dependencias restringidas que representan restricciones al flujo relativo de control entre un
conjunto de actividades. Por ejemplo, si dos componentes u y v no pueden ejecutarse al mismo
tiempo (exclusin mutua), entonces existe una relacin de dependencia restringida entre u y v.
Las dependencias compartidas y de flujo que seala Zhao son similares al concepto de acoplamiento.
Acoplamiento es un concepto importante de diseo que se aplica al nivel de arquitectura y de
componentes.
3.11.3 Lenguajes de descripcin arquitectnica
El arquitecto de una casa tiene un conjunto de herramientas estandarizadas y de notacin que permite
representar el diseo de una manera poco ambigua y fcil de comprender. Aunque el arquitecto del
software puede dibujar con notacin UML, se necesitan otras formas de diagramacin, y unas cuantas
herramientas relacionadas, para aplicar un enfoque ms formal a la especificacin de un diseo
arquitectnico. El lenguaje de descripcin arquitectnica (LDA) proporciona una semntica y una sintaxis
para describir una arquitectura del software. Hofmann y sus colegas [HOF01] sugieren que un LDA debe
proporcionar al diseador la capacidad de separar componentes arquitectnicos, de integrar
componentes individuales en bloques arquitectnicos mayores y de representar interfaces
(mecanismos de conexin) entre componentes. Una vez que se hayan establecido las tcnicas
descriptivas, basadas en el lenguaje para diseo arquitectnico, es ms probable que se establezcan
los mtodos de evaluacin efectivos para la arquitectura a medida que el diseo evoluciona.

3.12 Correlacin del flujo de datos de una Arquitectura de Software
Los estilos analizados en la seccin anterior representan arquitecturas radicalmente diferentes;
por tanto, no debe sorprender que no exista una completa correlacin (o mapeo) que logre la
transicin del modelo de anlisis a diversos estilos arquitectnicos. En realidad, no hay correlacin
prctica para algunos estilos arquitectnicos..
Ilustrar un enfoque de la correlacin arquitectnica requiere tener en cuenta una tcnica de
correlacin aplicada a la arquitectura de llamada y retorno (una estructura muy comn en muchos
tipos de sistemas). Esta tcnica de correlacin permite que un diseador derive arquitecturas de
llamada y retorno razonablemente complejas a partir de diagramas de flujo de datos dentro del
modelo de anlisis. La tcnica, a veces denominada diseo estructurado, se presenta en libros de
Myers [MYE78] y Your-don y Constantin [YOU79].
El diseo estructurado suele caracterizarse como un mtodo de diseo orientado a flujo de
datos, ya que proporciona una conveniente transicin de un diagrama de flujo de datos (captulo
8) a una arquitectura del software. El tipo de flujo de informacin es el controlador para el
enfoque de correlacin o mapeo.
3.12.1 Flujo de transformacin
La informacin debe entrar y salir del software en una forma lgica para "la realidad externa". Por
ejemplo, los datos escritos en un teclado, los tonos de una lnea telefnica y las imgenes de video en
una aplicacin multimedia son medios de informacin de la realidad externa. Estos datos externos
deben convertirse en una forma interna para el procesamiento. La informacin ingresa en el sistema
por rutas que transforman los datos externos en una forma interna. Estas rutas se identifican como
flujo de entrada. En el ncleo del software ocurre una transicin. Los datos entrantes se pasan por un
centro de transformacin y empiezan a moverse por rutas que ahora los llevan "fuera" del software. Al
desplazamiento de los datos por estas rutas se le denomina flujo de salida. El flujo general de datos
ocurre de manera secuencial y sigue una o unas cuantas rutas "en lnea recta".
9
Cuando un segmento de
un diagrama de flujo de datos muestra estas caractersticas est presente el flujo de transformacin.
3.12.3 Flujo de transaccin
Al flujo de informacin suele caracterizarlo un solo elemento de datos, llamado transaccin, que dispara
otro flujo de datos por una de muchas rutas. Cuando un diagrama de flujo de datos (DFD) asume la forma
mostrada en la figura 3.16 est presente el flujo de transaccin.
Al flujo de transaccin lo caracterizan los datos que se desplazan por un camino entrante que convierte la
informacin proveniente del exterior en una transaccin. sta se evala y, con base en su valor, se inicia
el flujo por una de muchas rutas de accin. Al elemento que concentra y distribuye el flujo de informacin,
del que emanan muchas rutas de accin, se le denomina centro de transaccin.
Debe observarse que, dentro del DFD de un sistema grande, tienen que estar presentes los flujos de
transformacin y transaccin. Por ejemplo, en una transaccin orientada a flujo, el flujo de informacin
por un camino de accin puede tener caractersticas del flujo de transformacin.







Figura 3. 17 Flujo de transaccin.
3.12.4 Correlacin de transformaciones
La correlacin de transformaciones es un conjunto de pasos de diseo que permite que un DFD
con caractersticas de flujo de transformacin se correlacione con un estilo arquitectnico
especfico. Ilustrar este enfoque requiere considerar de nuevo la funcin de seguridad
HogarSeguro
0
Un elemento del modelo de anlisis es un conjunto de diagramas de flujo de datos
que describen el flujo de informacin dentro de la funcin de seguridad. Con el fin de
correlacionar estos diagramas en una arquitectura se llevan a cabo los siguientes pasos de diseo:
Paso 1. Revisar el modelo fundamental del sistema. El modelo fundamental del sistema o
diagrama de contexto describe la funcin de seguridad como una sola transformacin, que
representa a los productores y consumidores externos de los datos que fluyen al interior y hacia
fuera de la funcin. En la figura 3.17se describe un modelo de nivel 0; en la 3.18 se muestra un
flujo de datos refinado para la funcin de seguridad.
Paso 2. Revisar y retinar los diagramas de flujo de datos para el software.
La informacin obtenida de los modelos de anlisis se refina para producir mayor detalle. Por
ejemplo, se examina el DFD de nivel 2 para supervisar sensores (figura 3.18) y se deriva un
diagrama de flujo de datos de nivel 3, como se muestra en la figura 3.19. En el nivel 3 cada
transformacin del DFD muestra una cohesin relativamente alta .Es decir, el proceso implcito en
una transformacin realiza una funcin nica y distintiva que puede implementarse como un
componente del software HogarSeguro. Por tanto, el DFD de la figura 3.19 contiene suficiente de-
talle para un "primer corte" en el diseo arquitectnico del subsistema supervisar sensores, y se
sigue adelante sin mayor refinamiento.


Figura 3. 18 DFD Al Nivel De Contexto Para La Funcin de HogarSeguro















Figura 3. 20 DFD de nivel 2 que refina la transformacin monitorear sensores.

Figura 3. 19 DFD de nivel 1 para la funcin de seguridad de HogarSeguro
Paso 3. Determinar si el DFD tiene caractersticas de flujo de transformacin o de transaccin.
En general, siempre es posible representar el flujo de informacin dentro de un sistema como una
transformacin. Sin embargo, cuando se encuentra una caracterstica obvia de transaccin (figura 3.17),
se recomienda una correlacin de diseo diferente. En este paso el diseador selecciona las
caractersticas de flujo global (de todo el software) con base en la naturaleza prevaleciente del DFD.

Figura 3. 21 DFD nivel 3 para monitorear sensores con lmites de flujo


Adems, se aslan las regiones locales del flujo de transformacin o transaccin. Estos subflujos se
aprovechan para reafirmar la arquitectura del programa derivado de una caracterstica global
descrita antes. Por ahora, la atencin se centrar slo en el flujo de datos del subsistema
monitorear sensores descrito en la figura 3.21. Al evaluar el DFD (figura 3.21) se aprecia que los
datos entran al software por una ruta de entrada y salen por tres rutas de salida. No participa un
centro de transaccin distintivo (aunque la transformacin establece condiciones de alarma que
podran percibirse como tales). Por tanto, se supondr una caracterstica general de
transformacin para el flujo de la informacin.
Paso 4. Aislar el centro de transformacin al especificar lmites de flujo de entrada y salida. En la
seccin anterior, el flujo de entrada se describi como un camino que convierte la informacin con
forma externa en informacin interna; el flujo de salida hace la conversin inversa. Los lmites de
los flujos de entrada y salida estn abiertos a la interpretacin. Es decir, diferentes diseadores
seleccionarn puntos ligeramente diferentes del flujo como posicin de los lmites. En realidad, las
soluciones alternas de diseo se obtienen al modificar la posicin de los lmites de flujo. Aunque
debe tenerse cuidado al seleccionar los lmites, la variacin en una burbuja a lo largo del camino
de flujo generalmente tendr poco impacto en la estructura final del programa.



Los lmites de flujo en este ejemplo se ilustran como curvas sombreadas que corren verticalmente
por el flujo de la figura 3.21. Las transformaciones (burbujas) que constituyen el centro de
transformacin caen dentro de los dos lmites sombreados que corren de arriba abajo en la figura.
Podra respaldarse el argumento de que es posible reajustar un lmite (por ejemplo, podra
proponerse un lmite de flujo de entrada que separe leer sensores y adquirir informacin de
respuesta). En este paso de diseo debe resaltarse la seleccin de lmites razonables, no la larga
iteracin sobre la posicin de los lmites.
Paso 5. Realizar una "factorizacin de primer nivel". La arquitectura del programa que se ha
derivado a partir de los resultados de la correlacin lleva a una distribucin descendente del
control. La factorizacin genera una estructura de programa en que los componentes
descendentes se encargan de la toma de decisiones y los componentes de bajo nivel realizan ms
trabajo de entrada, clculo y salida. Los componentes de nivel intermedio se encargan de parte
del control y realizan cantidades moderadas de trabajo.
Al encontrar el flujo de transformacin se correlaciona un DFD con una estructura especfica (una
arquitectura de llamada y retorno) que proporciona control para el procesamiento de la
informacin de entrada, de transformacin y de salida. En la figura 3.22 se muestra esta
factorizacin de primer nivel para el subsistema supervisar sensores. Un controlador principal
(llamado supervisar director de sensores) reside en la parte superior de la estructura del programa
y coordina las siguientes funciones subordinadas de control:











Figura 3. 22 Factorizacin de primer nivel para supervisar sensores.

Un controlador de procesamiento de informacin entrante, llamado controlador de entrada
de sensores, coordina la recepcin de todos los datos de entrada.
Un controlador de flujo de transformacin, llamado controlador de condiciones de alarma,
supervisa todas las operaciones de los datos en forma adecuada para el trabajo interno (por
ejemplo, un mdulo que invoca varios procedimientos de transformacin de datos).
Un controlador de procesamiento de informacin saliente, llamado controlador de salida de
alarma, coordina la produccin de informacin de salida.
Aunque una estructura de tres picos se desprende de la figura 3.22, flujos complejos en sistemas
grandes llegan a pedir dos o ms mdulos de control para cada una de las funciones genricas de
control descritas. El nmero de mdulos en el primer nivel debe limitarse al mnimo posible para
realizar las funciones de control y aun mantener buenas caractersticas de independencia
funcional.
Paso 6. Realice una "factorizacin de segundo nivel".
La factorizacin de segundo nivel se logra al correlacionar las transformaciones individuales
(burbujas) de una DFD con los mdulos apropiados dentro de la arquitectura. Si se empieza en el
lmite del centro de transformacin y se desplaza hacia fuera por rutas de entrada y luego por
rutas de salida, las transformaciones se correlacionarn en niveles subordinados de la estructura
del software. En la figura 3.23 se muestra el enfoque general de la factorizacin de segundo nivel.
Aunque en la figura 3.23 se ilustra una correlacin uno a uno entre transformaciones de DFD y
mdulos de software, suelen ocurrir correlaciones diferentes. Es posible combinar dos o hasta tres
burbujas y representarlas como un componente, o expandir una sola burbuja en dos o ms
componentes. Consideraciones prcticas y medidas de la calidad del diseo dictan el resultado de
la factorizacin de segundo nivel. La revisin y el refinamiento producen cambios en la estructura,
pero sirven como diseo de "primera iteracin". La factorizacin de segundo nivel para el flujo de
entrada se realiza de la misma manera. La factorizacin se realiza nuevamente al desplazarse
hacia fuera, desde el lmite del centro de transformacin en el lado del flujo de entrada. El centro
de transformacin del software del subsistema monitorear sensores se correlaciona de manera un
poco diferente. Cada conversin de datos o transformacin de datos de la parte de la
transformacin del DFD se correlaciona con un mdulo que est subordinado al controlador de
transformacin. En la figura 3.24 se muestra una arquitectura de primera iteracin completa.
Los componentes correlacionados de la manera anterior y mostrada en la figura 3.24 representan
un diseo inicial de la arquitectura del software. Aunque el nombre de los componentes indica
una funcin, debe escribirse una breve explicacin de su procesamiento (adaptado de la
especificacin creada durante el modelado del anlisis).











Figura 3. 23 Factorizacin de segundo nivel para supervisar sensores-



Figura 3. 24 Estructura de primera iteracin para supervisar sensores
Paso 7. Refinar la arquitectura de primera iteracin empleando diseo heurstico para mejorar
la calidad del software. Siempre es posible refinar una arquitectura de primera iteracin si se
aplican conceptos de independencia funcional. Los componentes se expanden o contraen para
producir una factorizacin sensible, una buena cohesin, un acoplamiento mnimo y, lo que es
ms importante, una estructura que se implemente sin dificultades, se pruebe sin confusin y se
mantenga sin problemas.
. Por ejemplo, hay ocasiones que el controlador del flujo de datos de entrada resulta totalmente
innecesario, que se requiere algn procesamiento de entrada en un componente subordinado al
controlador de transformacin, que no puede evitarse el acoplamiento elevado debido a los datos
globales, o que no logran alcanzarse las caractersticas ptimas de la estructura. Los requisitos del
software, junto con el juicio humano, deben servir para tomar la decisin final.
El objetivo de los siete pasos precedentes es desarrollar una representacin arquitectnica del
software. Es decir, una vez definida la estructura, es posible evaluar y refinar la arquitectura del
software al tener un panorama general de l. Las modificaciones hechas en este momento
requieren poca informacin adicional, pero tendrn un fuerte impacto en la calidad del software.
El lector debe hacer una breve pausa y considerar la diferencia entre el enfoque del diseo
descrito y el proceso de "escribir programas". Si el cdigo es la nica representacin del software,
el desarrollador tendr gran dificultad para evaluar o refinar a voluntad, en un nivel global u
holstico. En realidad, tendr dificultad para "ver el bosque entre los rboles".




Figura 3. 25Estructura Refinada Del Programa Para Supervisor Sensores
3.12.5 Correlacin de transacciones
En muchas aplicaciones de software, un solo elemento de datos dispara varios flujos de informacin
que afectan una funcin relacionada con el elemento de datos que dispara. El elemento de datos,
llamado transaccin, y sus correspondientes caractersticas de flujo se analizaron en la seccin 10.6.2. En
esta seccin se considerarn los pasos de diseo empleados para correlacionar el flujo de transaccin
con una arquitectura de software.
La correlacin de transacciones se ilustrar si se considera el subsistema de interaccin con el usuario
de la funcin de seguridad de HogarSeguro. En la figura 3.19 se muestra el flujo de datos de nivel 1 para
este subsistema. Al refinar el flujo se deriva un diagrama de flujo de datos de nivel 2, como se muestra
en la figura 3.26 El objeto de datos comandos de usuario fluye dentro del sistema y genera un flujo de
informacin adicional por una de tres rutas de accin. Un solo elemento de datos, tipo de comando,
hace que el flujo de datos se expanda hacia fuera del concentrador. Por tanto, la caracterstica
general del flujo de datos est orientada a la transaccin.
Debe observarse que el flujo de informacin a lo largo de dos de las tres rutas de accin acomoda
el flujo de entrada adicional (por ejemplo, parmetros y datos del sistema son entradas del
camino de accin "configurar"). Todas las rutas de accin fluyen en una sola transformacin,
desplegar mensajes y estatus.
Los pasos del diseo para la correlacin de transacciones son similares y en algunos casos
idnticos a los pasos para correlacin de transformaciones (seccin 10.6.3). Una diferencia
importante se encuentra en la correlacin del DFD con la estructura del software.

Paso 1. Revisar el modelo fundamental del sistema.
Paso 2. Revisar y refinar los diagramas de flujo de datos para el software.
Paso 3. Determinar si el DFD tiene caractersticas de flujo de transformacin o de transaccin.
Los pasos 1, 2 y 3 son idnticos a los correspondientes en la correlacin de transformaciones. El
DFD que se muestra en la figura 10.19 tiene una caracterstica de flujo de transformacin clsico.
Sin embargo, el flujo por las rutas de accin que emanan de la burbuja invocar procesamiento de
comandos parece contar con caractersticas de flujo de transformacin. Por tanto, deben
determinarse lmites de flujo para ambos tipos.
Paso 4. Identificar el centro de transaccin y las caractersticas de flujo en cada una de las rutas
de accin. La ubicacin del centro de transaccin se desprende directamente del DFD. El centro de
transaccin se encuentra en el origen de varias rutas de accin que fluyen de l de manera radial.
En el caso del flujo mostrado en la figura 10.19, la burbuja invocar procesamiento de comandos es
el centro de transaccin.
El camino entrante (es decir, el camino del flujo en que se recibe la transaccin) y todas las rutas
de accin deben estar aislados. Es necesario evaluar la caracterstica de flujo individual de cada
camino de accin. Por ejemplo, el camino "contrasea" (mostrado dentro de un rea sombreada
en la figura 10.19) tiene caractersticas de transformacin. El flujo de entrada, de transformacin y
de salida se indican con lmites.
Paso 5. Correlacionar el DFD con una estructura de programa sensible al procesamiento de la
transaccin. El flujo de transaccin se correlaciona con una arquitectura que contiene una rama
entrante y una para despacho. La estructura de la rama entrante se desarrolla de manera muy
parecida a la correlacin de transformaciones. Si se empieza en el centro de transaccin, las
burbujas ubicadas a lo largo del camino entrante se correlacionan con mdulos. La estructura de
la rama para despacho contiene un mdulo despachador que controla todos los mdulos de
actividades.



Figura 3. 26DFD de nivel 2 para el subsistema de interaccin con el usuario
Cada camino de flujo de accin del DFD se correlaciona con una estructura que corresponde a sus
caractersticas de flujo especficas. Este proceso se ilustra esquemticamente en la figura 3.27
Si se toma en cuenta el flujo de datos del subsistema de interaccin con el usuario, la factorizacin
de primer nivel para el paso 5 se muestra en la figura 3.28. Las burbujas leer comandos del usuario
y activar/desactivar sistema se correlacionan directamente con la arquitectura sin necesidad de
mdulos de control inmediato. El centro de transaccin, invocar comando de procesamiento, se
correlaciona directamente con el mdulo despachador del mismo nombre. Se crean controladores
para la configuracin del sistema y el procesamiento de la contrasea, como se ilustra en la figura
3.27
Paso 6. Factorizar y reflnar la estructura de transaccin y la de cada camino de accin. Cada
camino de accin del DFD tiene sus propias caractersticas de flujo de informacin. Ya se ha
observado que es posible encontrar los flujos de transformacin o transaccin. La "subestructura"
relacionada con el camino de accin se desarrolla empleando los pasos de diseo analizados en
esta seccin y en la anterior. Como ejemplo, considrese el flujo de informacin de procesamiento
de la contrasea que se muestra en la figura 3.26 (dentro del rea sombreada). El flujo muestra.


Figura 3. 27 Correlacin de transacciones


Figura 3. 28 Factorizacin de primer nivel para el subsistema de interaccin con el usuario
Caractersticas de transformacin clsicas. Se ingresa una contrasea (flujo entrante) y se
transmite a un centro de transformacin donde se compara contra las contraseas
almacenadas. Si no se obtiene una coincidencia, se producen una alarma y un mensaje de
precaucin (flujo saliente). El camino "configurar" se dibuja de manera similar empleando
correlacin de transformaciones. En la figura 3.29 se muestra la arquitectura del software
resultante.
Paso 7. Retinar la arquitectura de primera iteracin empleando diseo heurstico para
mejorar la calidad del software. Este paso para la correlacin de transacciones es idntico al
de transformaciones. En ambos enfoques de diseo, criterios.

Figura 3. 29 Arquitectura de primera iteracin para el subsistema de iteracin con el usuario
Como independencia del mdulo, factibilidad (eficacia de la implementacin y la prueba) y
facilidad de mantenimiento deben ponderarse cuidadosamente cuando se propongan
modificaciones estructurales.
3.12.5 Refinamiento del diseo arquitectnico
Cualquier anlisis de refinamiento del diseo debe prolongarse ron l siguiente comentario:
recuerde que un "diseo ptimo" que no funciona tiene un mrito cuestionable. El diseador de
software debe preocuparse por desarrollar una representacin del software que cumpla con todos
los requisitos funcionales y de desempeo, as como la aceptacin del mrito basado en las
medidas y la heurstica del diseo.
Debe estimularse el refinamiento de la arquitectura del software durante las primeras etapas del
diseo. Como se analiz al principio de este captulo, es posible derivar, refinar y evaluar estilos
arquitectnicos alternos para determinar cul es el "mejor" enfoque. Este mtodo para afrontar la
optimizacin es uno de los verdaderos beneficios que se obtienen de desarrollar una
representacin de la arquitectura del software Es importante indicar que a menudo la simplicidad
estructural refleja elegancia y eficiencia. El objetivo del refinamiento del diseo debe ser el uso del
menor nmero de componentes que permitan una integracin efectiva de los mdulos.