UNIVERSIDAD TECNOLOGICA BOLIVIANA

INGENIERIA DE SISTEMAS
ANALISIS DE SISTEMAS II
NOMBRE: RAMOS CHACHAQUE SERGIO WILMER
PRACTICA
ARQUITECTURA DEL SOFTWARE
El concepto de arquitectura de software se refiere a la estructuracin del
sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta
estructuracin representa un diseo de alto nivel del sistema que tiene dos
propsitos primarios: satisfacer los atributos de calidad (desempeo, seguridad,
modificabilidad), y servir como gua en el desarrollo. Al igual que en la
ingeniera civil, las decisiones crticas relativas al diseo general de un sistema
de software complejo deben de hacerse desde un principio. El no crear este
diseo desde etapas tempranas del desarrollo puede limitar severamente el
que el producto final satisfaga las necesidades de los clientes. Adems, el
costo de las correcciones relacionadas con problemas en la arquitectura es
muy elevado. Es as que la arquitectura de software juega un papel
fundamental dentro del desarrollo.

Qu es la arquitectura de software?
Antes de elaborar sobre el tema, es conveniente definir el concepto ya que hoy
en da el trmino de arquitectura se usa para referirse a varios aspectos
relacionados con las TI. De acuerdo al Software Engineering Institute (SEI), la
Arquitectura de Software se refiere a las estructuras de un sistema,
compuestas de elementos con propiedades visibles de forma externa y las
relaciones que existen entre ellos.
El trmino elementos dentro de la definicin del SEI es vago a propsito, pues
puede referirse a distintas entidades relacionadas con el sistema. Los
elementos pueden ser entidades que existen en tiempo de ejecucin (objetos,
hilos), entidades lgicas que existen en tiempo de desarrollo (clases,
componentes) y entidades fsicas (nodos, directorios). Por otro lado, las
relaciones entre elementos dependen de propiedades visibles (o pblicas) de
los elementos, quedando ocultos los detalles de implementacin. Finalmente,
cada conjunto de elementos relacionados de un tipo particular corresponde a
una estructura distinta, de ah que la arquitectura esta compuesta por distintas
estructuras.

Por qu es importante la arquitectura de software?

La arquitectura de software es de especial importancia ya que la manera en
que se estructura un sistema tiene un impacto directo sobre la capacidad de
este para satisfacer lo que se conoce como los atributos de calidad del sistema.

Ejemplos de atributos de calidad son el desempeo, que tiene que ver con el
tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad,
que tiene que ver con qu tan sencillo les resulta a los usuarios realizar
operaciones con el sistema, o bien la modificabilidad, que tiene que ver con
qu tan simple resulta introducir cambios en el sistema. Los atributos de
calidad son parte de los requerimientos (no funcionales) del sistema y son
caractersticas que deben expresarse de forma cuantitativa. No tiene sentido,
por ejemplo, decir que el sistema debe devolver una peticin de manera
rpida, o presentar una pgina ligera, ya que no es posible evaluar
objetivamente si el sistema cubre o no esos requerimientos.

El ciclo de desarrollo de la arquitectura

Dentro de un proyecto de desarrollo, e independientemente de la metodologa
que se utilice, se puede hablar de desarrollo de la arquitectura de software.
Este desarrollo, que precede a la construccin del sistema, esta dividido en las
siguientes etapas: requerimientos, diseo, documentacin y evaluacin. Cabe
sealar que las actividades relacionadas con el desarrollo de la arquitectura de
software generalmente forman parte de las actividades definidas dentro de las
metodologas de desarrollo.
A continuacin se describen dichas etapas.
Requerimientos. La etapa de requerimientos se enfoca en la captura,
documentacin y priorizacin de requerimientos que influencian la arquitectura.
Como se mencion anteriormente, los atributos de calidad juegan un papel
preponderante dentro de estos requerimientos, as que esta etapa hace nfasis
en ellos. Otros requerimientos, sin embargo, son tambin relevantes para la
arquitectura, estos son los requerimientos funcionales primarios y las
restricciones.
Diseo. La etapa de diseo es la etapa central en relacin con la arquitectura y
probablemente la ms compleja. Durante esta etapa se definen las estructuras
que componen la arquitectura. La creacin de estas estructuras se hace en
base a patrones de diseo, tcticas de diseo y elecciones tecnolgicas. El
diseo que se realiza debe buscar ante todo satisfacer los requerimientos que
influencian a la arquitectura, y no simplemente incorporar diversas tecnologas
por que estn de moda.
Documentacin. Una vez creado el diseo de la arquitectura, es necesario
poder comunicarlo a otros involucrados dentro del desarrollo. La comunicacin
exitosa del diseo muchas veces depende de que dicho diseo sea
documentado de forma apropiada. La documentacin de una arquitectura
involucra la representacin de varias de sus estructuras que son representadas
a travs de distintas vistas. Una vista generalmente contiene un diagrama,
adems de informacin adicional, que apoya en la comprensin de dicho
diagrama.
Evaluacin. Dado que la arquitectura de software juega un papel crtico en el
desarrollo, es conveniente evaluar el diseo una vez que este ha sido
documentado con el fin de identificar posibles problemas y riesgos. La ventaja
de evaluar el diseo es que es una actividad que se puede realizar de manera

temprana (an antes de codificar), y que el costo de correccin de los defectos

identificados a travs de la evaluacin es mucho menor al costo que tendra el
corregir estos defectos una vez que el sistema ha sido construido.

El rol de arquitecto
Las actividades descritas anteriormente requieren de habilidades particulares
que son la responsabilidad del arquitecto de software. El arquitecto es un lder
tcnico que debe conocer los principios relacionados con la arquitectura de
software, tener un amplio conocimiento respecto a la tecnologa, y tener
excelentes habilidades de comunicacin escrita y oral.
Desafortunadamente, en la actualidad pocos arquitectos de software que
laboran en la industria han recibido una formacin terica respecto al tema.
Esto se debe a que no es sino hasta pocas recientes que se han establecido
de manera ms formal los conceptos relacionados con la arquitectura de
software, y que actualmente pocas instituciones ofrecen cursos enfocados en el
tema. El desconocimiento de los principios relativos a la arquitectura de
software frecuentemente impacta de manera negativa a los proyectos de
desarrollo.

Apenas empezamos
A lo largo de las distintas entregas de esta columna que inicia se buscar dar
una panormica del tema de arquitectura de software y se discutir de manera
ms detallada aspectos como:

requerimientos que influyen en la arquitectura,

el diseo, documentacin y evaluacin de la arquitectura,

los retos relacionados con la introduccin de prcticas de arquitectura de

software en un contexto organizacional,

la arquitectura de software dentro de las metodologas de desarrollo,

el perfil del arquitecto de software.

Modelo Vista de Deployment

Introduccin
Est seccin describe una o ms configuraciones fsicas sobre las cuales se realiza el deploy
del
software y es ejecutado, as como la infraestructura necesaria para su instalacin.
Para el caso del Framework Batuta se describe el escenario general de distribucin esperado
para los componentes de software antes descritos, las caractersticas de los nodos
presentados y
la comunicacin entre los mismos.

Distribucin y Deployment
La figura 17 presenta el escenario de distribucin esperado para la instalacin del framework.

El mismo se ubica en el contexto de una organizacin, sobre una LAN privada y se prev el
acceso va Internet a un repositorio de servicios.

A continuacin se describen los nodos presentes en la figura:

Servidor BPM: representa el equipo donde correr el subsistema Ejecucin de Procesos.
Por tanto, se ejecutan aqu las funcionalidades de transformacin e instalacin de
procesos de negocio as como el motor de ejecucin de procesos. Tales servicios son
expuestos mediante respectivas interfaces web service.
PC Analista de Negocios: representa la estacin de trabajo de un usuario analista de
negocio. En este nodo correr el subsistema Definicin de Procesos. Se comunica con el
Servidor BPM para la transformacin e instalacin del proceso definido; la
comunicacin es va SOAP a travs de la interfaz web service expuesta por dicho nodo.
Cliente de Proceso de Negocio: representa el equipo donde corre una aplicacin
cliente que desea ejecutar un proceso de negocio disponible en el Servidor BPM. No hay
Documento de Arquitectura de Software Proyecto Batuta - Generador de Aplicaciones Orquestadoras
Versin 2.3 Pg. 20

componentes del framework corriendo en este nodo. Los procesos son ejecutados
invocando el web service publicado para cada uno de ellos.
Servidor Resolucin de Servicios: representa el equipo donde correr el subsistema
Resolucin de Servicios. Recibe pedidos del motor de ejecucin de servicios corriendo en
el Servidor BPM. La comunicacin es nuevamente a travs de una interfaz web service.
Repositorio de Servicios: representa un equipo donde se mantendr un registro de
servicios disponibles a los cuales podr acceder el subsistema Resolucin de Servicios
para buscar los servicios adecuados para una determinada solicitud. Podra existir ms
de una instancia de este nodo a la cual acceder.
Las interfaces de comunicacin previstas para los nodos, basadas en web services, posibilitan
plantear mltiples escenarios de distribucin y permiten el planteo de una infraestructura
multiplataforma.

Modelo de Vista Lgica

Introduccin
Se presentan en este punto los sucesivos refinamientos que definen las diferentes unidades
lgicas que componen la arquitectura del Framework Batuta.
El primer refinamiento realizado consiste en la descomposicin en subsistemas. Los
subsistemas representan cortes verticales al diseo del sistema. Cada subsistema consiste en
el
agrupamiento de diferentes funcionalidades relacionadas entre s y posee la capacidad de
funcionar como un sistema en s mismo.
Posteriormente se explora la composicin de cada uno de los subsistemas.
Finalmente se incluye la realizacin de los casos de uso descriptos en la seccin anterior
mediante los componentes arquitectnicos definidos

Descomposicin en Subsistemas

La descomposicin propuesta, basada en el modelo Peer to Peer, organiza la arquitectura en

un
conjunto de subsistemas funcionalmente cohesivos que interactan entre s para cumplir sus
funciones.

El modelo diente-servidor
El modelo arquitectnico cliente-servidor es un modelo de sistemas distribuido que
muestra cmo los datos y el procesamiento se distribuyen a lo largo de varios
procesadores. Los componentes principales de este modelo son:
1. Un conjunto de servidores independientes que ofrecen servicios a otros
subsistemas. Ejemplos de servidores son los servidores de impresin que ofrecen
estos servicios, los servidores de archivos que ofrecen los servicios de administracin
de archivos y los servidores de compilacin que ofrecen los servicios de compilacin
de lenguajes de programacin.
2. Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores.. Por
lo general, stos son subsistemas. Existen varias instancias de un programa cliente
que se ejecuta de forma concurrente.
3. Una red que permite a los clientes acceder a estos servicios. En principio, sta no
es realmente necesaria puesto que tanto los clientes como los servidores podran
ejecutarse en una sola mquina. Sin embargo, en la prctica este modelo no se
utilizara como tal.
Los clientes tienen que conocer los nombres de los servidores disponibles y los
servicios que suministran. Sin embargo, los servidores no requieren conocer la
identidad de los clientes o cuntos clientes existen. Los clientes acceden a los
servicios suministrados por un servidor a travs de llamadas a procedimientos
remotos.

En la figura 5.25 se muestra un ejemplo de un sistema construido utilizando un modelo

cliente-servidor. ste es un sistema de hipertexto multiusuario que provee una
biblioteca de pelculas y fotografas. En este sistema existen varios servidores que
administran y despliegan los diferentes tipos de medios. Las pelculas se deben
transmitir rpidamente y de forma sincronizada, pero a una resolucin relativamente
bajas. Pueden estar comprimidas en un almacn. Sin embargo, las imgenes se

deben enviar en alta resolucin. El catlogo debe estar disponible para responder a
una gran variedad de peticiones

El enfoque cliente-servidor se puede utilizar para implementar un sistema basado en

depsitos, donde el depsito se suministra como un servidor del sistema. Los subsistemas que acceden al depsito son los clientes. Sin embargo, normalmente cada
subsistema administra sus propios datos. Los servidores y clientes intercambian datos
para su procesamiento. Esto conduce a problemas de desempeo citando se
intercambian grandes cantidades de datos. Sin embargo, puesto que cada vez existen
redes ms veloces, este problema es cada vez menos importante.
La ventaja ms importante del modelo cliente-servidor es que es una arquitectura
distribuida. Los sistemas en red se pueden utilizar de forma efectiva con muchos
procesadores distribuidos. Es fcil agregar un nuevo servidor e integrarlo con el resto
del sistema o actualizar de forma transparente los servidores sin afectar otras partes
del sistema. Las arquitecturas distribuidas, incluyendo las arquitecturas cliente-servidor
y las de objetos distribuidos.
Sin embargo, es necesario hacer cambios a los clientes y servidores existentes pasa
obtener los mayores beneficios al integrar un nuevo servidor. No existe un modelo
compartido de datos y los subsistemas por lo regular organizan sus datos de diversas
formas. Esto significa que los modelos de datos especficos se establecen para cada
servidor que permita optimizar su desempeo. La falta de un modelo de referencia
compartido para los datos implica que es difcil anticiparse a los problemas al
momento de integrar los datos de un nuevo servidor. Cada servidor debe tener
responsabilidad de las actividades de administracin de datos como la de respaldo y
de recuperacin.