Unidad lll Diseo de Arquitecturas de Software

3.1 Desarrollo de Software Basado en Arquitecturas

La arquitectura de software de un programa o sistema de computacin es la estructura o

estructuras del sistema, la que comprende los elementos de software, las propiedades
externamente visibles de estos elementos, y las relaciones entre estos.

Los sistemas pueden, y deben, estar conformados por ms de una estructura y que una Sola
estructura no puede ser considerada de ninguna manera la arquitectura.

Usos de la Documentacin de Arquitecturas

Medio de Educacin: Cuando se incorpora gente al sistema (nuevos miembros del equipo,
analistas externos, o nuevos arquitectos).
Vehculo primario para comunicacin entre stakeholders:
Base para el anlisis del sistema: Debe contener la informacin necesaria para el anlisis
particular a realizar (seguridad, performance, modificabilidad,
Vista: Una representacin de un conjunto de elementos y las relaciones entre estos

3.1.1 Historia

Desarrollo de Software Basado en Arquitecturas

Aunque el trmino arquitectura de software, tal y como lo concebimos ahora, aparece en 1992
con el trabajo de Perry y Wolf, sus antecedentes se remontan al menos hasta finales de la dcada
de los sesenta. En 1968, Dijkstra habla de una estructuracin correcta de los sistemas de software,
aunque no la llama arquitectura como tal, Posteriormente, en 1969, P. I. Sharp, comentando las
ideas de Dijkstra, ya usa el trmino arquitectura de software al mencionar que quiz luego se hable
de la escuela de arquitectura de software de Dijkstra, y al mismo tiempo lamentar que la industria
de ese tiempo preste muy poca atencin a sta.
Durante la dcada de los setentas el concepto de arquitectura deambul por el aire sin una
semntica clara y carente de una expresin pragmtica. En esta misma dcada, el diseo
estructurado dio pie a la independencia entre el diseo y la implementacin. Los trabajos de Parnas
sobre tcnicas de modularizacin en decisiones de diseo y familias de programas, fueron, sin duda,
aportaciones esenciales y permanentes.

Hacia finales de los ochenta y principios de los noventa, comienza a gestarse de manera ms clara
la idea de que las aplicaciones tienen una morfologa, una estructura. El trabajo de Perry y Wolf de
1992 es el punto de partida para lo que hoy conocemos como arquitectura de software. Por un lado,
son los primeros que proponen un modelo para la arquitectura de software; este modelo contempla
a la arquitectura formada por tres componentes: elementos, forma y razn. Los elementos pueden
ser de procesamiento, datos o conexin; la forma se define de acuerdo a las propiedades de, y a las
relaciones entre los elementos; la razn se contempla en trminos de restricciones del sistema, que
se derivan de los requerimientos del sistema.

Perry y Wolf profetizaron que: la dcada de los noventas, creemos, ser la dcada de la
arquitectura de software, lo cual se convirti en realidad. A lo largo de esa dcada, salieron a la luz
varios trabajos con propuestas relevantes, entre ellas, la programacin basada en componentes[6],
el surgimiento de los patrones y estilos, el modelo de 4+1 vistas, y lenguajes de descripcin de
arquitecturas (ADLs)entre otras. En la segunda mitad de los noventa aparecen los primeros libros
de texto dedicados a la arquitectura de software. El ao 2000 cierra esta dcada con dos trabajos
clave: el modelo REST propuesto en la tesis de Roy Fielding que pone la atencin en Internet y los
modelos orientados a servicios; y el trabajo de la IEEE, que genera una versin definitiva de la
recomendacin IEEE std 1471-2000.

Actualmente hay una cierta efervescencia alrededor de desarrollos centrados en arquitectura,

mtodos de anlisis y diseo de arquitecturas (dentro del ciclo de vida), anlisis de arquitecturas de
software basados en escenarios, modelos de evaluacin de arquitecturas de software y modelos
orientados por la arquitectura entre algunos otros tpicos.

3.2 Atributos Funcionales

Para los componentes, y teniendo en cuenta como posible objetivo la definicin de un modelo de
calidad especfico, es fundamental primero realizar una taxonoma, tratando de clasificar las
caractersticas de calidad de acuerdo a su naturaleza y a distintos parmetros que intervienen en su
medida. Se pueden realizar distintos tipos de clasificaciones.

1. En primer lugar, necesitamos discriminar entre aquellas caractersticas que tienen sentido para
los componentes aislados (caractersticas locales) o bien deben ser valoradas a nivel de la
arquitectura software de la aplicacin (que llamaremos caractersticas globales). Por ejemplo, la
tolerancia a fallos es una tpica caracterstica que va a depender de la arquitectura de la aplicacin,
mientras que la

madurez es ms propia de los componentes.

2. El instante en el cual una caracterstica puede ser observada o medida, permite establecer otra
clasificacin de las caractersticas de un producto. As, tenemos dos posibles categoras
dependiendo de si la caracterstica es observable en tiempo de ejecucin ( el rendimiento) o durante
el ciclo de vida del producto ( la mantenibilidad).

3. Como se menciona en los estndares de ISO, es importante identificar los usuarios a los que se
dirige el modelo. En el mbito del DSBC, los usuarios son fundamentalmente los arquitectos
software, que necesitan evaluar los componentes
COTS que van a formar parte de su aplicacin. As, las interfaces de los componentes objeto de
nuestro estudio son ms las interfaces programticas (es decir, las APIs que definen las formas de
acceder desde otros programas a los servicios que ofrecen los componentes), que las interfaces de
usuario.

4. Para componentes COTS, es fundamental distinguir entre mtricas internas y externas.

Las internas miden los atributos internos del producto final o de los productos intermedios (p.e. la
especificacin o el cdigo fuente) durante el diseo y la codificacin. Las externas son las que
realizan las mediciones en funcin del comportamiento del sistema durante las pruebas y la
operacin del componente. Por tanto, debido al carcter de caja negra de los componentes COTS,
son las mtricas externas las que interesan. Esto no quita que algunas de las caractersticas internas
den una medida indirecta de las externas, e incluso que puedan tener efectos sobre la arquitectura
final. As, por ejemplo, el tamao de un componente puede ser importante a la hora de tener en
cuenta los requisitos de espacio de la aplicacin.

3.3 Atributos de Calidad

Por ltimo, es importante sealar que, adems de las caractersticas de calidad en un componente,
hay otro conjunto de caractersticas no relacionadas directamente con la calidad como pueden ser
el precio, la asistencia tcnica, las condiciones de licencia, etc., que tambin son necesarias a la hora
de valorar el componente ms adecuado.

Todas estas caractersticas tcnicas y no tcnicas deben estar documentadas en un formato

aceptado por los participantes en el desarrollo de software. Una forma adecuada de implementar
la documentacin de componentes es utilizar el modelo de propiedades de

ODP [RM-ODP 1997] donde cada atributo se describe mediante un par (nombre, valor), con un tipo
asociado a cada nombre. Estas propiedades se pueden describir mediante plantillas XML, lo cual
facilita la conexin con cualquier tipo de herramientas. Adems, esta forma de documentar los
componentes abre la posibilidad de implementar procesos de seleccin automtica o
semiautomtica, facilitando el proceso de valoracin de los componentes software.

3.4 Proceso de elaboracin de Arquitecturas de Software

En los diferentes marcos, las vistas estticas se corresponden con las perspectivas particulares de
los diferentes participantes (stakeholders), mientras que las vistas dinmicas tienen que ver con
etapas del proceso, ciclo de vida o metodologa, caracterizadas como requerimiento, anlisis, diseo
(o construccin, o modelado), implementacin, integracin (prueba de conformidad, testing,
evaluacin). La terminologa, lo mismo que la articulacin temporal del proceso o el ciclo, depende
de cada marco.

El proceso es el conocimiento incorporado, y puesto que el conocimiento esta inicialmente disperso,

el desarrollo de software implcito, latente e incompleto en gran medida es un proceso social de
aprendizaje. El proceso es un dialogo en el que se rene el conocimiento y se incluye en el software
para convertirse en software. El proceso proporciona una iteracin entre los usuarios y los
diseadores, entre los usuarios y las herramientas de desarrollo, y entre los diseadores y las
herramientas de desarrollo (tecnologa). Es un proceso interactivo donde la herramienta de
desarrollo se usa como medio de comunicacin, con cada iteracin del dialogo se obtiene mayor
conocimiento.

Desde un punto de vista tcnico se puede decir que el proceso de software es un marco de trabajo
de las tareas que se requieren para construir software de alta calidad.

Aun ms importante es que la Ingeniera del Software la realizan personas creativas, con
conocimiento, que deberan trabajar dentro de un proceso del software definido y avanzado que es
apropiado para los productos que construyen y para las demandas de su mercado.
3.4.1 Forward Engineering

El proceso tradicional de pasar de las abstracciones de alto nivel y, los diseos de la implementacin
independiente lgicos para laimplementacin fsica de un sistema de contraste se refiere a tomar
un modelo de alto nivel y usarlo para construir una aplicacin ms compleja de nivel inferior (en
oposicin a la ingeniera inversa donde se toma una implementacin compleja y tratar de convertirlo
en una abstraccin de alto nivel).

3.4.2 Reverse Engineering

El proceso de anlisis de un sistema existente para identificar sus componentes y sus interrelaciones
y crear representaciones de la sistema en otra forma o en un alto nivel de Abstraccin inversa
ingeniera se suele realizar en orden a redisear el sistema para el mejor servicio de mantenimiento
o de producir una copia de un sistema que no tienen acceso a la diseo de la que se fue
originalmente producido.

3.4.2 Estilos

Un estilo arquitectnico en software es anlogo al concepto en construccin de

Consiste de algunas caractersticas claves y reglas para combinar estas caractersticas.

Estn determinados por: Un conjunto de tipos de componentes (proceso, repositorio, etc.) que
realiza alguna funcin en tiempo de ejecucin.
Una distribucin topolgica de las componentes que indica su interrelacin en tiempo de ejecucin.
Un conjunto de restricciones semnticas.Un conjunto de conectores que permiten la comunicacin,
coordinacin o cooperacin entre los

3.4.3 Patrones

Los patrones de diseo son la base para la bsqueda de soluciones a problemas comunes en el
desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces.

Un patrn de diseo resulta ser una solucin a un problema de diseo. Para que una solucin sea
considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber
comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que
debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseo en distintas
circunstancias.

Los patrones de diseo son el esqueleto de las soluciones a problemas comunes en el desarrollo de
software.

En otras palabras, brindan una solucin ya probada y documentada a problemas de desarrollo de

software que estn sujetos a contextos similares. Debemos tener presente los siguientes elementos
de un patrn: su nombre, el problema (cuando aplicar un patrn), la solucin (descripcin abstracta
del problema) y las consecuencias (costos y beneficios).

existen varios patrones de diseo popularmente conocidos, los cuales se clasifican como se muestra
a continuacin:

Patrones Creacionales
Fbrica Abstracta ( Abstract Factory )

El problema a solucionar por este patrn es el de crear diferentes familias de objetos, como por
ejemplo la creacin de interfaces grficas de distintos tipos (ventana, men, botn, etc.).

Mtodo de Fabricacin ( Factory Method )

Parte del principio de que las subclases determinan la clase a implementar.

Prototipado ( Prototype )

Se basa en la clonacin de ejemplares copindolos de un prototipo.

Singleton

Restringe la instanciacin de una clase o valor de un tipo a un solo objeto.

MVC ( Model View Controler )

Este patrn plantea la separacin del problema en tres capas: la capa model, que representa la
realidad; la capa controler , que conoce los mtodos y atributos del modelo, recibe y realiza lo que
el usuario quiere hacer; y la capa vista, que muestra un aspecto del modelo y es utilizada por la capa
anterior para interaccionar con el usuario.

Patrones Estructurales

Adaptador (Adapter): Convierte una interfaz en otra.

Puente (Bridge): Desacopla una abstraccin de su implementacin permitiendo modificarlas

independientemente.

Objeto Compuesto (Composite): Utilizado para construir objetos complejos a partir de otros ms
simples, utilizando para ello la composicin recursiva y una estructura de rbol.

Envoltorio (Decorator): Permite aadir dinmicamente funcionalidad a una clase existente, evitando
heredar sucesivas clases para incorporar la nueva funcionalidad.
Fachada (Facade): Permite simplificar la interfaz para un subsistema.

Peso Ligero (Flyweight): Elimina la redundancia o la reduce cuando tenemos gran cantidad de
objetos con informacin idntica.

Patrones de Comportamiento

Cadena de responsabilidad (Chain of responsibility): La base es permitir que ms de un objeto tenga

la posibilidad de atender una peticin.

Orden (Command): Encapsula una peticin como un objeto dando la posibilidad de deshacer la
peticin.

Intrprete (Interpreter): Intrprete de lenguaje para una gramtica simple y sencilla.

Iterador (Iterator): Define una interfaz que declara los mtodos necesarios para acceder
secuencialmente a una coleccin de objetos sin exponer su estructura interna.

Mediador (Mediator): Coordina las relaciones entre sus asociados. Permite la interaccin de varios
objetos, sin generar acoples fuertes en esas relaciones.

Recuerdo (Memento): Almacena el estado de un objeto y lo restaura posteriormente.

Observador (Observer): Notificaciones de cambios de estado de un objeto.

Estado (Server): Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado
del mismo.

Estrategia (Strategy): Utilizado para manejar la seleccin de un algoritmo.

Mtodo plantilla (Template Method): Algoritmo con varios pasos suministrados por una clase
derivada.

Visitante (Visitor): Operaciones aplicadas a elementos de una estructura de objetos heterognea