Documente Academic
Documente Profesional
Documente Cultură
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.
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 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:
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.
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.
Descomposicin en Subsistemas
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.
deben enviar en alta resolucin. El catlogo debe estar disponible para responder a
una gran variedad de peticiones