Arquitectura de Software

ARQUITECTURA DE SOFTWARE
Diego Colque Ramos
Junio 2014

Resumen
En este paper examinaremos la importancia de la arquitectura de software en los sistemas
o software. En la descripcin implicaremos los principios y prcticas de modelado. Algunos
lenguajes de programacin usan la misma lgica, se mencionar algunos de estos. Los
patrones y frameworks brindan ayuda y soporte en la elaboracin de la arquitectura de
software y se definir alguno de ellos como ejemplo a tomar en cuenta.

1. Introduccin
1.1. Perspectiva histrica
Durante las tres primeras dcadas de la informtica (a partir de 1960), el principal
desafo era el diseo de la arquitectura de software de la computadoras de forma que
se redujera el costo de procesamiento y almacenamiento. A lo largo de la dcada de
los ochenta, los avances en microelectrnica han dado como resultado una mayor
potencia de clculo a la vez que una reduccin del coste. El problema de ahora es
diferente, es mejorar la calidad (y reducir el coste) de las soluciones basadas en
computadoras.

Los primero aos La segunda era La tercera era La cuarta era

- Orientacin por - Multiusuario - Sistemas - Potentes
lotes. - Tiempo real distribuidos sistemas de
- Distribucin - Bases de datos - Incorporacin sobremesa
limitada. - Software de - Tecnologas
- Software a como inteligencia orientadas a
medida producto - Hardware de los objetos
bajo coste - Sistemas
- Impacto en el expertos
consumo - Redes
neuronales
artificiales
- Computacin
paralela

1950 1960 1970 1980 1990 2000

Arquitectura de Software

La tabla describe la evolucin del software dentro del contexto de las reas de
aplicacin de los sistemas basados en computadoras. Durante los primeros aos del
desarrollo el hardware sufri varios cambios, mientras que el software se
contemplaba simplemente como un aadido. La programacin de computadoras era
un arte de andar por casa para el que existan pocos mtodos sistemticos. El
desarrollo del software se realizaba virtualmente sin ninguna planificacin hasta que
los planes comenzaban a descalabrarse y los costes a crecer. Durante este periodo se
utilizaba en la mayora de los sistemas una orientacin por lotes. Algunas excepciones
notables de los sistemas interactivos tales como el sistema de reserva de billetes de
American Airlines y los sistemas de tiempo real para la defensa. Sin embargo la mayor
parte del hardware se dedicaba a la ejecucin de un nico programa que, a su vez, se
dedicaba a una aplicacin especfica.

2. Marco terico

2.1. Definicin
La arquitectura se refiere a dos caractersticas importantes del software de
computadoras: (1) La estructura jerrquica de los componentes procedimentales
(mdulos) , y (2) la estructura de los datos. La arquitectura del software se obtiene
mediante un proceso de particin, que relaciona los elementos de una solucin de
software con partes de un problema del mundo real definido implcitamente durante
el anlisis de los requisitos. La evolucin del software y de la estructura de datos
comienza con una definicin del problema. La solucin aparece cuando cada parte del
problema est resuelta mediante uno o ms elementos de software. Este proceso,
simblicamente representado en la figura representa una transicin entre el anlisis
de requisitos del software u el diseo.
Arquitectura de Software

Observando la siguiente figura se ve que un problema puede ser resuelto mediante

diferentes estructuras. Se puede usar una metodologa de diseo de software para
obtener estructuras, pero debido a que cada una se basa en un concepto fundamental
diferente de buen diseo, cada mtodo de diseo dar como resultado una
estructura diferente, para el mismo conjunto de requisitos del software. No hay una
respuesta fcil a la pregunta, Cul es mejor?. An no se ha llegado ha esta etapa de
la ciencia. Sin embargo, hay caractersticas de una estructura que se puede examinar
para determinar la calidad global.

2.2. Arquitectura lenguajes de descripcin

Una descripcin de la arquitectura lenguaje es cualquier medio de expresin que se

utiliza para describir una arquitectura de software. Muchas actividades cotidianas para
fines especiales se han desarrollado desde la dcada de 1990, incluyendo AADL,
Wright, Acme, xADL, Darwin, DAOP-ADL y ByADL.

Las vistas o modelos de una arquitectura de software pueden expresarse mediante

uno o varios lenguajes. El ms obvio es el lenguaje natural, pero existen otros
lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc.
Estos lenguajes son apropiados nicamente para un modelo o vista. Afortunadamente
existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje
unificado de modelado) como lenguaje nico para todos los modelos o vistas. Sin
embargo, un lenguaje generalista corre el peligro de no ser capaz de describir
determinadas restricciones de un sistema de informacin (o expresarlas de manera
incomprensible).
Arquitectura de Software

2.3. Requerimientos de una arquitectura de software

Toda arquitectura de software deber cumplir con una serie de requerimientos que
hacen al buen diseo de una aplicacin empresarial:
o Ser robusta.
o Ser soportable y escalable.
o Sacar ventaja de los principios del diseo orientado a objetos.
o Eliminar la complejidad innecesaria (por ejemplo, evitar el uso de servidores de
aplicaciones cuando no es necesario).
o Ser mantenible y extensible.
o Ser fcil su testeo.
Y dependiendo de los requerimientos del negocio, deber:
o Soportar mltiples clientes.
o Ser portable.

2.4. Lenguajes de Patrones

Los Lenguajes de Patrones se pueden definir del siguiente modo: "La especificacin de
una serie de elementos (patrones) y sus relaciones (patrones) de modo que nos
permiten describir buenas soluciones a los diferentes problemas que aparecen en un
contexto especfico".

El objetivo de los patrones de diseo es el de capturar buenas prcticas que nos

permitan mejorar la calidad del diseo de un sistema, determinando elementos que
soporten roles tiles en dicho contexto, encapsulando complejidad, y hacindolo ms
flexible.

Por otro lado, con frecuencia se dice que la funcin define a la forma, es decir, que la
estructura o la arquitectura de cualquier sistema est muy relacionada con lo que
dicho sistema tiene que hacer.

Esta es la razn por la que los sistemas con objetivos similares comparten tambin una
arquitectura comn, unos procesos bien definidos, y un conjunto de elementos
similares (patrones de diseo). Similar funcionalidad y servicio, similar estructura.

De alguna forma, los patrones nos permiten identificar y completar los casos de uso
bsicos expuestos por el cliente, comprender la arquitectura del sistema a construir
as como su problemtica, y buscar componentes ya desarrollados que cumplan con
los requisitos del tipo de sistema a construir (es decir nos permiten obtener de una
forma sencilla la arquitectura base que buscamos durante la fase de diseo
arquitectnico).
Hay muchos patrones y estilos arquitectnicos reconocidos, entre ellos:
Pizarra Centrada en los datos
Cliente-servidor Orientada a eventos
Componente basado Capas
Arquitectura de Software

Aplicacin monoltica Artculo basado

Intercambio de archivos Orientada a servicios
Tubos y filtros Arquitectura nada compartido
Plug-ins Arquitectura basada Espacio
Transferencia de estado
representacional

2.4.1. El patrn Blackboard

El patrn Blackboard generaliza el patrn observador para permitir mltiples
fuentes de datos y mltiples visualizadores. Tambin realiza un completo
desacoplamiento de los productores y consumidores de informacin.

Blackboard es un almacn de mensajes que puede ser ledo y editado por

todos los procesos. Siempre que ocurra algo que puede ser de inters para
otra parte, el proceso responsable o informado sobre el evento aade al
Blackboard una notificacin del evento. Otros procesos pueden leer el cuadro
negro. En un caso tpico, ignoran la mayora de su contenido, que no les es de
inters, sin embargo, tal vez reaccionen a otros eventos. Un proceso que
coloca una notificacin en el Blackboard no sabe si cero, uno, o varios otros
procesos estn prestando atencin a sus modificaciones.

2.5. Frameworks
Una de las definiciones de frameworks es que lo ven como una estructura compuesta
por partes integradas. En el mundo de la POO (Programacin Orientada a Objetos) los
frameworks de aplicaciones son libreras de clases.

Bsicamente los frameworks incluyen los siguientes puntos de vista:

Procesamiento: Requerimientos funcionales y casos de uso.

Informacin: Modelo de objetos, diagramas de entidad relacin y diagramas de
flujos de datos.
Estructura: Diagramas de componentes que representan a los clientes, servidores,
aplicaciones, bases de datos y sus interconexiones.

Una arquitectura determina si estos puntos de vista son necesarios en el desarrollo de

un sistema de software.
Como conclusin podemos decir que a un framework se lo puede ver como una
arquitectura de software que modela las relaciones generales de las entidades del
dominio, proveyendo una infraestructura y "entorno de trabajo" que extiende el
dominio.
Arquitectura de Software

El uso de un entorno de trabajo que enmascare todas estas cuestiones facilita el

desarrollo del sistema, poniendo nfasis en lo que realmente es el corazn de toda
aplicacin: el dominio.

2.6. Erosin de la Arquitectura

La erosin de la arquitectura es la introduccin de decisiones de diseo en la
arquitectura descriptiva que violan la arquitectura prescriptiva.
El sistema resulta difcil de comprender y adaptar, y generalmente lleva a fallas del
sistema
Si la desviacin es grande, la comprensin se ve amenazada y surge la erosin
Tambin hay erosin cuando se toman decisiones de diseo en forma aislada, sin
considerar las anteriores
Como un ejemplo, considerar un sistema estrictamente capas, donde cada capa slo
se puede utilizar los servicios proporcionados por la capa inmediatamente por debajo
de ella. Cualquier componente de cdigo fuente que no cumpla con esta obligacin
constituye una violacin arquitectura. Si no se corrige, tales violacines pueden
transformar la arquitectura en un bloque monoltico, con efectos adversos sobre la
comprensibilidad, mantenibilidad y capacidad de evolucin.
Existen dos tcnicas principales para detectar violacines arquitectnicos: modelos
reflexin y lenguajes especficos de dominio. Tcnicas modelo Reflexion comparar un
modelo de alto nivel previsto por los arquitectos del sistema con la implementacin
del cdigo fuente. Ejemplos de herramientas comerciales basadas en RM son SAVE y
estructura-101. Tambin hay lenguajes especficos de dominio, con especial atencin
sobre la especificacin y verificacin restricciones arquitectnicas, incluyendo. QL y
DCL.

2.7. Arquitectura, puntos de vista

Arquitectura descripciones de software se organizan comnmente en puntos de vista,

que son anlogas a los diferentes tipos de planos realizados en la arquitectura del
edificio. Cada vista se dirige a un conjunto de problemas del sistema, segn las
convenciones de su punto de vista, donde un punto de vista es una especificacin que
describe las notaciones de modelado, y tcnicas de anlisis a utilizar en una vista que
expresan la arquitectura en cuestin desde la perspectiva de un conjunto dado de
partes interesadas y sus preocupaciones. El punto de vista no slo establece las
preocupaciones enmarcadas, pero la presentacin, tipo modelo utilizado,
convenciones utilizadas y las reglas de consistencia para mantener una visin
consistente con otros puntos de vista.
Arquitectura de Software

3. Conclusiones
o La potencia de las grandes computadoras de hoy, las enormes capacidades de
procesamiento y almacenamiento del hardware moderno representan un gran
potencial. El software es el mecanismo que nos facilita utilizar y explorar ese
potencial.
o No es necesario inventar una nueva arquitectura de software para un sistema
determinado, estos ya estn definidos (o la mayora de arquitecturas).
o Estas arquitecturas brindan apoyo en la toma grandes o pequeas decisiones.
o Proporciona una perspectiva general del sistema que se va a construir o que ya se
tiene.
Arquitectura de Software

4. Bibliografa
o Ingeniera del Software, un enfoque prctico Roger S. Pressman Tercera
Edicin
o Tesis: Arquitectura de Software y Entornos de Trabajo (Frameworks) de
Contenedores Ligeros Damian Ciocca

o https://www.ucursos.cl/ingenieria/2010/1/CC61H/1/material_docente/previsualiz
ar?id_material=273287
o http://centrodeartigos.com/articulos-noticias-consejos/article_135667.html