Professional Documents
Culture Documents
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.
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
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:
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).
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.
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.
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”.
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.
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.
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.
Resumen
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
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.
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
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
Libros
Software Architecture, Perspectives on an emerging discipline, Mary Shaw,
David Garlan, Prentice Hall, 1996.
volver al menú
Internets
www.cetus-links.org/top_architecture_design.html
www2.umassd.edu/SECenter/SAResources.html
volver al menú
Novedadess