EL diseo del software se encuentra en el ncleo tcnico de la ingeniera del software y se aplica

independientemente del modelo de diseo de software que se utilice.

La arquitectura de Software han estado implcitas bien como accidentes en la implementacin,
bien como sistemas legados del pasado-. Los buenos desarrolladores de software han adoptado, a
menudo, uno o varios patrones arquitectnicos como estrategias de organizacin del sistema,
pero utilizaban estos patrones de modo informal y no tenan ningn inters en hacerlos explcitos
en el sistema resultante.
La descomposicin modular es un mtodo de diseo proporciona un mecanismo sistemtico para
descomponer el problema en subproblemas, reducir la complejidad de todo el problema,
consiguiendo de esta manera una solucin modular efectiva.
La arquitectura de dominio especifico Existen dos modelos de dominio especfico el modelo
genrico que son abstracciones de varios sistemas reales y el modelo de referencia que son
modelos abstractos y describen a una clase mayor de sistemas.
En el transcurso del contenido le explicaremos mas detalladamente cada uno de estos temas.

Unidad IV: Diseo y arquitectura de software
El diseo del software se encuentra en el ncleo tcnico de la ingeniera del software y se aplica
independientemente del modelo de diseo de software que se utilice. Una vez que se analizan y
especifican los requisitos del software, el diseo del software es la primera de las tres actividades
tcnicas -diseo, generacin de cdigo y pruebas- que se requieren para construir y verificar el
software. Cada actividad transforma la informacin de manera que d lugar por ltimo a un
software de computadora validado.
Shaw y Garlan [SHA96], en su libro de referencia sobre la materia, tratan la arquitectura del
software de la siguiente forma:
Incluso desde que el primer programa fue dividido en mdulos, los sistemas de software han
tenido arquitecturas, y los programadores han sido responsables de sus interacciones a travs de
mdulos y de las propiedades globales de ensamblaje. Histricamente, las arquitecturas han
estado implcitas bien como accidentes en la implementacin, bien como sistemas legados del
pasado-. Los buenos desarrolladores de software han adoptado, a menudo, uno o varios patrones
arquitectnicos como estrategias de organizacin del sistema, pero utilizaban estos patrones de
modo informal y no tenan ningn inters en hacerlos explcitos en el sistema resultante.
Hoy, la arquitectura de software operativa y su representacin y diseo explcitos se han
convertido en temas dominantes de la ingeniera de software.

Qu es arquitectura?
Cuando hablamos de la arquitectura de un edificio, nos vienen a la cabeza diferentes atributos.
A nivel ms bsico, pensamos en la forma global de la estructura fsica. Pero, en realidad, la
arquitectura es mucho ms. Es la forma en la que los diferentes componentes del edificio se
integran para formar un todo unido. Es la forma en la que el edificio encaja en su entorno y con los
otros edificios de su vecindad. Es el grado en el que el edificio consigue su propsito fijado y
satisface las necesidades de sus propietarios. Es el sentido esttico de la estructura -impacto visual
del edificio- y el modo en el que las texturas, los colores y los materiales son combinados para
crear la fachada externa y el entorno vivo interno. Son los pequeos detalles e l diseo de las
instalaciones elctricas, del tipo de suelo, de la colocacin de tapices y una lista casi interminable-.
Y, finalmente, es arte.

Pero, qu pasa con la arquitectura de software? Bass y sus colegas [BAS98] definen este esquivo
trmino de la siguiente forma:

La arquitectura de software de un sistema de programa o computacin es la estructura de las
estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos
componentes visibles externamente, y las relaciones entre ellos.

La arquitectura no es el software operacional. Ms bien, es la representacin que capacita al
ingeniero del software para: (1) analizar la efectividad del diseo para la consecucin de los
requisitos fijados, (2) considerar las alternativas arquitectnicas en una etapa en la cual hacer
cambios en el diseo es relativamente fcil, y (3) reducir los riesgos asociados a la construccin del
software.
Por qu es importante la arquitectura?
En su libro dedicado a la arquitectura de software, Bass y sus colegas [BAS98] identifican tres
razones clave por las que la arquitectura de software es importante:
Las representaciones de la arquitectura de software facilitan la comunicacin entre todas las
partes (partcipes) interesadas en el desarrollo de un sistema basado en computadora.
La arquitectura destaca decisiones tempranas de diseo que tendrn un profundo impacto en
todo el trabajo de ingeniera del software que sigue, y es tan importante en el xito final del
sistema como una entidad operacional.
La arquitectura constituye un modelo relativamente pequeo e intelectualmente comprensible
de cmo est estructurado el sistema y de cmo trabajan juntos sus componentes [BAS98].
El modelo de diseo arquitectnico y los patrones arquitectnicos contenidos dentro son
transferibles. Esto es, los estilos y patrones de arquitectura pueden ser aplicados en el diseo de
otros sistemas y representados a travs de un conjunto de abstracciones que facilitan a los
ingenieros del software la descripcin de la arquitectura de un modo predecible.

6.1 Descomposicin modular
Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un mecanismo
sistemtico para descomponer el problema en subproblemas, reducir la complejidad de todo el
problema, consiguiendo de esta manera una solucin modular efectiva.
Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite ensamblar los
componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin
modular que no inventa nada ya inventado.
Capacidad de comprensin modular. Si un mdulo se puede comprender como una unidad
autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar.
Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan cambios en los
mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de
los efectos secundarios de los cambios.
Proteccin modular. Si dentro de un mdulo se produce una condicin aberrante y sus efectos se
limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los
errores.
Finalmente, es importante destacar que un sistema se puede disear modularmente, incluso
aunque su implementacin deba ser monoltica. Existen situaciones (por ejemplo, software en
tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan
sobrecargas de memoria y de velocidad por mnimos que sean (por ejemplo, subrutinas,
procedimientos). En tales situaciones el software podr y deber disearse con modularidad como
filosofa predominante.
El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener
un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los
beneficios de un sistema modular.
DESCOMPOSICION MODULAR
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus
ventajas: claridad, reduccin de costos y reutilizacin

Los pasos a seguir son:
1. Identificar los mdulos
2. Describir cada mdulo
3. Describir las relaciones entre mdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda
considerar suficiente validad.
1. Independencia funcional
2. Acoplamiento
3. Cohesin
4. Comprensibilidad
5. Adaptabilidad

Descomposicin Modular: Independiente Funcional
Al final de los documentos ADD(Aprobacin del documento de diseo arquitectnico) y
DDD(Aprobacin del documento de diseo detallado) debe haber una matriz
REQUISITOS/COMPONNETES. En principio, cada funcin ser realizada en un mdulo distinto. Si
las funciones son independientes los mdulos tendrn independencia funcional.
Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es
recomendable reducir las relaciones entre mdulos al mnimo.
Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin.
Descomposicin Modular: Acoplamiento
El grado de acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de conexin y la
complejidad de la interface:
FUERTE
POR CONTENIDO, cuando desde un mdulo se pueden cambiar datos locales de otro
COMN, se emplea una zona comn de datos a la que tienen acceso varios mdulos
MODERADO
DE CONTROL, la zona comn es un dispositivo externo al que estn ligados los mdulos, esto
implica que un cambio en el formato de datos afecta a todos estos mdulos
POR ETIQUETA, en intercambio de datos se realiza mediante una referencia a la estructura
completa de datos (vector, pila, rbol, grafo, )
DBIL
DE DATOS, viene dado por los datos que intercambian los mdulos. Es el mejor posible
SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe
Descomposicin Modular: Cohesin
Es necesario lograr que el contenido de cada mdulo tenga la mxima coherencia. Para que el n
de mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos
afines y relacionados en un mismo mdulo.
ALTA
COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo abstracto de datos o
como una clase de objetos
COHESIN FUNCIONAL, el mdulo realiza una funcin concreta y especfica
MEDIA
COHESIN SECUENCIAL, los elementos del mdulo trabajan de forma secuencial
COHESIN DE COMUNICACIN, elementos que operan con le mismo conjunto de datos de
entrada o de salida
COHESIN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar
o parar dispositivos
BAJA
COHESIN LGICA, se agrupan elementos que realizan funciones similares. Ejs.: mdulos de E/S o
de tratamiento de errores
COHESIN COINCIDENTAL, es la peor y se produce cuando los elementos de un mdulo no
guardan relacin alguna
La descripcin del comportamiento de un mdulo permite establecer el grado de cohesin:

Si es una frase compuesta y contiene ms de un verbo la cohesin ser MEDIA
Si contiene expresiones secuenciales (primero, entonces, cuando), ser temporal o secuencial
Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin lgica
Si aparece inicializar, preparar, configurar, probablemente sea temporal.
Descomposicin Modular: Comprensibilidad
Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario que cada
uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional,
pero adems es deseable:
IDENTIFICACIN, el nombre debe ser adecuado y descriptivo
DOCUMENTACIN, debe aclarar todos los detalles de diseo e implementacin que no queden de
manifiesto en el propio cdigo
SIMPLICIDAD, las soluciones sencillas son siempre las mejores
Descomposicin Modular: Adaptabilidad
La adaptacin de un sistema resulta ms difcil cuando no hay independencia funcional, es decir,
con alto acoplamiento y baja cohesin, y cuando el diseo es poco comprensible. Otros factores
para facilitar la adaptabilidad:
PREVISIN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en
el futuro, y poner estos elementos en mdulos independientes, de manera que su modificacin
afecte al menor nmero de mdulos posible
ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificacin, diseo, e
implementacin para obtener un conocimiento suficiente del sistema antes de proceder a su
adaptacin
CONSISTENCIA, despus de cualquier adaptacin se debe mantener la consistencia del sistema,
incluidos los documentos afectados