Arquitectura software

De Wikipedia, la enciclopedia libre

Saltar a navegación, búsqueda

En los inicios de la informática, la programación se consideraba un arte, debido a la

dificultad que entrañaba para la mayoría de los mortales, pero con el tiempo se han ido
desarrollando metodologías para conseguir nuestros propósitos. Y a todas estas técnicas
se les ha dado en llamar Arquitectura Software.

Una Arquitectura Software, también denominada Arquitectura lógica, consiste en un

conjunto de patrones y abstracciones coherentes que proporcionan el marco de
referencia necesario para guiar la construcción del software para un sistema de
información.

La arquitectura software establece los fundamentos para que analistas, diseñadores,

programadores, etc. trabajen en una línea común que permita alcanzar los objetivos y
necesidades del sistema de información.

Una arquitectura software se selecciona y diseña con base en unos objetivos y

restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero
no solamente los de tipo funcional, también otros objetivos como la mantenibilidad,
auditabilidad, flexibilidad e interacción con otros sistemas de información. Las
restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para
implementar sistemas de información. Unas arquitecturas son más recomendables de
implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para
determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura software
de tres capas para implementar sistemas en tiempo real.

La arquitectura software define, de manera abstracta, los componentes que llevan a cabo
alguna tarea de computación, sus interfaces y la comunicación ente ellos. Toda
arquitectura software debe ser implementable en una arquitectura física, que consiste
simplemente en determinar qué computadora tendrá asignada cada tarea de
computación.

La arquitectura de software, tiene que ver con el diseño y la implementación de

estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de
elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y
requerimientos de desempeño de un sistema, así como requerimientos no funcionales,
como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.

Kruchten, Philippe
Tabla de contenidos
[ocultar]
 1 Breve reseña histórica
 2 Modelos o vistas
  3 Arquitecturas más comunes
o 3.1 Bibliografía

 4 Véase también

Breve reseña histórica [editar]

En los años 1960 ya se acariciaba el concepto de arquitectura software en los círculos de
investigación (por ejemplo, por Edsger Dijkstra). No obstante, toma popularidad en los
años 1990 tras reconocerse la denominada crisis del software y como tema de interés de
la incipiente disciplina de la ingeniería del software.

Modelos o vistas [editar]

Toda arquitectura software debe describir diversos aspectos del software. Generalmente,
cada uno de estos aspectos se describe de una manera más comprensible si se utilizan
distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una
descripción parcial de una misma arquitectura y es deseable que exista cierto
solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre
sí, evidente dado que describen la misma cosa.

Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para
describir una arquitectura. No obstante, existen al menos tres vistas absolutamente
fundamentales en cualquier arquitectura:

 La visión estática: describe qué componentes tiene la arquitectura.

 La visión funcional: describe qué hace cada componente.
 La visión dinámica: describe cómo se comportan los componentes a lo largo del
tiempo y como interactúan entre sí.

Las vistas o modelos de una arquitectura pueden expresarse mediante uno o varios
lenguajes. El más 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 adpotar 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
información (o expresarlas de manera incomprensible).

Arquitecturas más comunes [editar]

Generalmente, no es necesario inventar una nueva arquitectura software para cada
sistema de información. Lo habitual es adoptar una arquitectura conocida en función de
sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más
universales són:
  Monolítica. Donde el software se estructura en grupos funcionales muy
acoplados.
 Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes
independientes pero sin reparto claro de funciones.
 Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor
donde la carga se divide en tres partes con un reparto claro de funciones: una
capa para la presentación, otra para el cálculo y otra para el almacenamiento.
Una capa solamente tiene relación con la siguiente.

Otras arquitecturas menos conocidas son:

 En pipeline.
 Entre pares.
 En pizarra.
 Orientada a servicios.
 Máquinas virtuales
Qué es la Arquitectura del Software y que relación tiene con la usabilidad. Tener
en cuenta la usabilidad en el momento del diseño de la arquitectura de un sistema
interactivo nos puede ahorrar muchos quebraderos de cabeza.

El Iceberg de la usabilidad

Se podría decir que, en el diseño de un sistema, hay tres aspectos a tener en cuenta:

 la presentación de la información
 la funcionalidad de la aplicación
 la Arquitectura del Software

Hasta hace poco, se asumía que la usabilidad era una propiedad exclusiva de la
presentación de la información. Se creía que, encapsulando la capa de presentación y
separándola del resto, se podía desarrollar la aplicación y, de forma iterativa, pasar los
tests de usabilidad. Tras cada test, tan sólo sería necesario resolver los problemas
modificando la presentación y, gracias a esta separación, la funcionalidad no quedaría
afectada.

En realidad, este modelo de desarrollo ha fallado a menudo. ¿Cuántas veces hemos

tenido que correr a realizar cambios profundos en la funcionalidad de una aplicación
después de haber detectado problemas de usabilidad? Dick Berry, en su analogía del
Iceberg de la usabilidad, explica que los aspectos relacionados con la presentación, es
decir, lo que normalmente entendemos como look & feel, sólo afectan en un 40% a la
usabilidad. El 60% restante está influenciado por lo que él llama “modelo del usuario”,
que está constituido por los objetivos que el usuario quiere alcanzar con sus tareas.

Berry relaciona el modelo del usuario con el modelo de objetos propio de la interfaz de
usuario, en el sentido estricto de la OOP (programación orientada a objetos), que
incluye, entre otras cosas, los objetos y las metáforas de la interfaz. Este modelo de
objetos, siempre según Berry, es el que permite al usuario relacionar sus objetivos con la
funcionalidad del sistema.

Por lo tanto, y esto ya es de cosecha propia, para conseguir una buena usabilidad, no
basta con tener en cuenta la capa de presentación, sino que es preciso que la usabilidad
se contemple también en el momento de la definición de la funcionalidad de la
aplicación.
Usabilidad y Arquitectura del Software

Sin embargo, a menudo hay que ir más lejos y no basta con tener en cuenta la
presentación y la funcionalidad. Sobre todo en sistemas complejos, como pueden ser los
entornos distribuidos, los transaccionales, los multicanal y aquéllos en los que puede
haber miles de usuarios conectados simultáneamente, hay que tener en cuenta la
usabilidad desde el inicio del diseño del sistema, es decir, desde lo que se denomina
momento de Arquitectura del Software.

Es bien sabido por los ingenieros del software que cuanto más tarde se detectan los
problemas, más cuesta arreglarlos. ¿Cuántas veces nos ha pasado que, al diseñar una
interfaz, desearíamos crear interacciones y diálogos que el entorno tecnológico no nos
permite? Y siempre acabamos exclamando: ¡Pero si esto mismo lo hice en tal otro sitio!
La respuesta de los técnicos no se hace esperar y, utilizando un vocabulario lleno de
siglas y conceptos técnicos, nos dicen que en su plataforma esto no es posible.

Me refiero a cosas como que el usuario pueda visualizar el progreso de sus peticiones,
que pueda deshacer acciones (undo), que pueda disponer de un entono multilingüe, que
pueda cancelar una operación que lleva mucho tiempo en espera, que pueda reutilizar
información que ha introducido anteriormente, y muchas otras cosas.

Si analizamos estos escenarios de interacción, veremos que la causa de que no se

puedan implementar es que no se tuvo en cuenta al usuario al inicio del diseño del
sistema, es decir, en la Arquitectura del Software.

¿Qué es la Arquitectura del Software?Existen muchas definiciones de Arquitectura

del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un
sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el
diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la
responsabilidad de:
 Definir los módulos principales
 Definir las responsabilidades que tendrá cada uno de estos módulos
 Definir la interacción que existirá entre dichos módulos:
 Control y flujo de datos

o Secuenciación de la información
o Protocolos de interacción y comunicación
o Ubicación en el hardware

La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el
detalle de cada uno de los módulos definidos a pasos posteriores del diseño.

La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza
así: “La Arquitectura del Software es la organización fundamental de un sistema
formada por sus componentes, las relaciones entre ellos y el contexto en el que se
implantarán, y los principios que orientan su diseño y evolución”.

Los productos resultantes de la Arquitectura del Software

El objetivo principal de la Arquitectura del Software es aportar elementos que ayuden a

la toma de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje común
que permitan la comunicación entre los equipos que participen en un proyecto. Para
conseguirlo, la Arquitectura del Software construye abstracciones, materializándolas en
forma de diagramas (blueprints) comentados.

No hay estándares en cuanto a la forma y lenguaje a utilizar en estos blueprints. De

todas formas, existe consenso en cuanto a la necesidad de organizar dichas
abstracciones en vistas, tal y como se hace al diseñar un edificio. La cantidad y tipos de
vistas difiere en función de cada tendencia arquitectónica.

Quizá uno de los modelos más conocidos es el “4+1” de Philippe Kruchten, vinculado
al Rational Unified Process (RUP), que define cuatro vistas diferentes:
 Vista lógica: describe el modelo de objetos.
 Vista de proceso: muestra la concurrencia y sincronía de los procesos.
 Vista física: muestra la ubicación del software en el hardware.
 Vista de desarrollo: describe la organización del entorno de desarrollo.
 Existe una quinta vista que consiste en una selección de casos de uso o de
escenarios que los arquitectos pueden elaborar a partir de las cuatro vistas
anteriores.

Ejemplos de Arquitectura del Software: J2EE y MVC

Para ilustrar un poco lo que se ha explicado hasta ahora, a continuación se muestran dos
diagramas de arquitectura en un entorno J2EE. Ambos diagramas están disponibles en
Designing Enterprise Applications with the J2EE Platform, Second Edition.

El primer diagrama consiste en una vista lógica que muestra los componentes y
servicios típicos de un entorno J2EE.

El segundo diagrama es una vista de proceso que muestra las relaciones entre las capas
model, view y controller de la arquitectura MVC bajo J2EE.
La investigación sobre Arquitectura del Software y Usabilidad

El interés por la relación entre Arquitectura del Software y usabilidad no es nuevo, pero
recientemente han aparecido algunos trabajos que abren el camino a la práctica del
resultado de las investigaciones. Este año, tanto en Viena, en la Conference on Human
Factors in Computing Systems (CHI2004), como en Edimburgo, en la International
Conference on Software Engineering (ICSE04), un equipo liderado por Len Bass ha
impartido un tutorial sobre el tema, cuyo título es bastante ilustrativo: Avoiding “We
can’t change THAT!”: Software Architecture & Usability (Cómo evitar “¡Esto no se
puede cambiar!”: Arquitectura del Software y Usabilidad). En el equipo docente, junto a
Bass estaban Bonni E. John y dos investigadoras españolas, Natalia Juristo y Maribel
Sánchez-Segura.

Escenarios de usabilidad sensibles a la Arquitectura del Software

El trabajo de Bass y de este equipo se basa en inventariar una serie de escenarios de

usabilidad sensibles a la Arquitectura del Software. Esto significa determinar una serie
de momentos de interacción o tareas del usuario que, para que el sistema los pueda
soportar, tienen que estar definidos en la Arquitectura del Software.

Hasta el momento, este inventario está compuesto de 26 escenarios que se pueden

consultar en el documento CMU/SEI-2001-TR-005 de Bass y otros.

La lista completa es demasiado extensa para el objetivo del presente artículo pero, a
modo de ejemplo, se enumeran a continuación los cinco primeros escenarios:
1. Agregación de datos: Poder aplicar simultáneamente una acción a un conjunto
de datos u objetos.
2. Agregación de comandos: Agrupar acciones que se puedan ejecutar de una sola
vez.
3. Comandos de cancelación
4. Uso de aplicaciones de forma concurrente
5. Validación automática de la entrada de datos
Patrones arquitecturales

Bass continúa con una propuesta de patrón arquitectural para cada escenario (sobre el
tema de patrones, consultad el artículo de Luis Villa, Patrones para el diseño de interfaz,
publicado en Grancomo).

El objetivo es doble:
 Facilitar a los expertos en usabilidad una checklist con escenarios que muestre
aspectos de usabilidad importantes a tener en cuenta en tiempo de
requerimientos.
 Facilitar a los arquitectos patrones que los guíen en el momento de dar soporte a
los escenarios.

Otro documento interesante es: Patrones de Usabilidad: Mejora de la Usabilidad del

Software desde el momento Arquitectónico (PDF), de Natalia Juristo y Maribel
Sánchez-Segura. Una de las aportaciones más interesantes de este documento es que
describe el procedimiento de obtención de los patrones de usabilidad que han de servir
para construir los patrones arquitectónicos.

Resumen

Siempre que se tenga la oportunidad, sería necesario que la usabilidad se tuviera

presente desde el inicio del diseño de un sistema, es decir, desde el momento de la
Arquitectura del Software. Pero, para que esta participación sea realmente efectiva,
arquitectos y expertos en usabilidad deberían tener un lenguaje común. Es en este
sentido en el que los escenarios de usabilidad y los patrones arquitectónicos pueden ser
de gran ayuda.

s
En este curso se busca introducir a los alumnos en el concepto de diseño de
software. Para lograrlo se presentan además de técnicas de diseño, los aspectos
claves que determinan la validez de las mismas como solución a un problema de
implementación. Se analiza el contexto en el que se deben aplicar las técnicas y se
fijan criterios de selección. Se estudia la evolución del software en el tiempo, lo que
hace que algunas de las técnicas que en determinado momento fueron válidas, hoy
ya no lo sean y en cambio otras continue vigentes.
Se introduce el concepto de arquitectura de software, como marco a todas las
actividades del diseño de software de un sistema en desarrollo.

volver al menú

Docentess

Profesor
Ing. Guillermo G. Pantaleo
Enviar email

Asistentes

Ing Diego Montaldo

Sr Gaston Real
Sr Carlos Curotto

Sr Nicolás Paez

volver al menú

Contenidoss
 Técnicas de diseño, su evolución en el tiempo. Contexto del diseño. Criterios
de buen diseño.

 Arquitectura de software. Significado, evolución del concepto, distintos tipos.

Las distintas vistas de la arquitectura de software. Relación con el Proceso
de Desarrollo. Diseño de Arquitectura, Diseño Detallado y Diseño de Código.

 Evolución de la ingeniería informática y Patrones. Referencia histórica y

motivación. Descripción. Clasificación. Sistema de Patrones. Aprendizaje y
selección. Patrones y metodologías de desarrollo. Criterios de diseño y
Patrones. Requerimientos no funcionales y Patrones.

 Proceso de Desarrollo de Software y Patrones. Patrones de arquitectura.

 Frameworks. Arquitectura. Relación con patrones y clases. Diseño, uso,

selección, documentación, evolución.

 C++ y Java. Una revisión crítica y comparativa.

  Diseño de Arquitectura, Patrones de Arquitectura : layer, model view
controller.

 Diseño Detallado, Patrones de Diseño: factory method, abstract factory,

prototype, adapter, decorator, composite, facade, proxy, chain of
responsibility, command, state, iterator, mediator, strategy y visitor.

 Diseño de Código, Patrones de tipo “Idioms”: singleton, template method.

Todos los temas que se traten serán ejemplificados en C++ y/o Java ,
según sea la característica saliente del Patrón en cuestión.

volver al menú

Normass

Ubicación en el plan de estudios

Los requisitos que deben cumplir los cursantes para inscribirse son : haber cursado
alguna materia de metodología de desarrollo de software, alguna materia
introductoria de algoritmos, alguna materia de lenguajes orientados a objetos y
alguna materia introductoria de bases de datos.

Forma de cursada
Se cursará en un cuatrimestre con dos clases semanales. Las clases son teórico
prácticas. Las clases se desarrollan los días Lunes y Jueves a las 19 horas.

Forma de aprobación
La evaluación para la aprobación de la materia consistirá en dos examenes
parciales y uno final.

volver al menú

Bibliografias

Artículos
 "Foundations for the Study of Software Architecture", Dewayne E. Perry,
Alexander L. Wolf; ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17
no 4 Oct 1992 Page 40. Acceso al documento

 "An Introduction to Software Architecture", David Garlan and Mary Shaw,

Advances in Software Engineering and Knowledge Engineering, Volume I,
edited by V.Ambriola and G.Tortora, World Scientific Publishing Company,
New Jersey, 1993. Acceso al documento
  "Architectural Blueprints—The “4+1” View Model of Software Architecture",
Philippe Kruchten, IEEE Software 12 (6), November 1995, pp. 42-50.
Acceso al documento

 "The Coming-of-Age of Software Architecture Research", Mary Shaw,

Institute for Software Research, International, Carnegie Mellon University,
Pittsburgh PA 15213. Acceso al documento

 "Application Facades ", Martin Fowler, private paper. Acceso al document

Libros
 Software Architecture, Perspectives on an emerging discipline, Mary Shaw,
David Garlan, Prentice Hall, 1996.

 Code Complete, Steve McConnell, Microsoft Press, 1994.

 Design Patterns, E. Gamma et al., Addison Wesley, 1995.

volver al menú

Internets
 www.cetus-links.org/top_architecture_design.html
 www2.umassd.edu/SECenter/SAResources.html

volver al menú

Novedadess

Ejercicios y material para alumnos:

Patrones de Análisis Acceso al documento

Ejemplo de uso de los Patrones de Análisis Planteo Solución
Esquema del Sistema de Patrones SistemaPatrones.zip
Patrones de Arquitectura Layer.zip MVC.zip
Patrones de Arquitectura (diagramas) UML1.zip UML2.zip
Patrones de Diseño (diagramas) UML3.zip
Patrones de Diseño (código de creacionales) creacionales.zip
Patrones de Diseño (código de organización del trabajo)
organizacionTrabajo.zip
Patrones de Diseño (código de control de acceso) ctrolAcceso.zip
Patrones de Diseño (diagramas) UML4.zip
Patrones de Diseño (código de variación de servicio) variacionServicio.zip
Patrones de Diseño (código de extension de servicio) extensionServicio.zip
Patrones de Diseño (diagramas) UML5.zip
Patrones de Diseño (código de adaptación) adapter.zip
Patrones de Diseño (código de estructural) composite.zip