Conclusiones

La Importancia de la Arquitectura de Software radica principalmente en la búsqueda temprana de problemas para que se tome decisiones tempranas de arquitectura ayudando con el diceño y la solucion de algunos problemas que encuentra, ademas de el alto nivel de abstracción que nos brinda al hacerlo junto al diceño, vinculada con requerimientos no funcionales fuerte impulso en la academia y la industria ya que da un marco de entendimiento y mejor desarrollo del software ademas de brindarnos herramientas arquitectónicas aún en proceso de definición y desarrollo que nos permiten desarrollar mejor nuestras aplicaciones de softwre, resta elaborar: tácticas arquitectónicas, métodos basados en arquitectura, vínculo entre conceptos de arquitectura, DSLs, factorías, building blocks, …

otras bibliografías

[Spo71] C. R. Spooner. “A Software Architecture for the 70's: Part I - The General Approach.” Software - Practice and
Experience, 1 (Enero-Marzo), pp. 5-37, 1971.

[StöS/f] Harald Störrle. “Turning UML subsystems into architectural units”. Reporte, Ludwig-Maximilians-Universität
München, http://www.pst.informatik.uni-muenchen.de/personen/stoerrle/Veroeffentlichungen/PosPaperICSEFormat.pdf,
sin fecha.

[Tem01] Theodor Tempelmeier. “Comments on Design Patterns for Embedded and Real-Time Systems”. En: A. Schürr
(ed.): OMER-2 (“Object-Oriented Modeling of Embedded Realtime systems”) Workshop Proceedings. Mayo 9-12, 2001,
Herrsching, Alemania. Bericht Nr. 2001-03, Universität der Bundeswehr München, Fakultät für Informatik, Mayo de 2001.

[Tem99] Theodor Tempelmeier. “UML is great for Embedded Systems – Isn’t it?” En: P. Hofmann, A. Schürr (eds.):
OMER (“Object-Oriented Modeling of Embedded Realtime systems”) Workshop Proceedings. Mayo 28-29, 1999,
Herrsching (Ammersee), Alemania. Bericht Nr. 1999-01, Universität der Bundeswehr München, Fakultät für Informatik,
Mayo de 1999.

[TMA+S/f] Richard Taylor, Nenad Medvidovic, Kennet Anderson, James Whitehead Jr, Jason Robbins, Kari Nies, Peyman
Oreizy y Deborah Dubrow. “A component- and message-based architectural style for GUI software”. Reporte para el
proyecto F30602-94-C-0218, Advanced Research Projects Agency, sin fecha.

[Tra02] Aron Trauring. “Software methodologies: The battle of the Gurus”. Info-Tech White Papers, 2002.

[Wir71] Niklaus Wirth. “Program development by stepwise refinement”, Communications of the ACM, 14(4), pp. 221-227,
Abril de 1971.

[WL97] Sharon White y Cuauhtémoc Lemus-Olalde. “The software architecture process”.

http://nas.cl.uh.edu/whites/webpapers.dir/ETCE97pap.pdf, 1997.

Referencias bibliográficas

http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.mspx

http://www.webtaller.com/maletin/articulos/como-desarrollar-una-arquitectura-software-lenguajes-patrones-2.php

http://arquitectura-de-software.blogspot.com/2006/05/orm-object-relational-mapping-i-parte.html#_Toc110849345

http://www.sappiens.com/sappiens/comunidades/progarti.nsf/Arquitectura%20interna%20(software)%20/C758B5E6E01B088641256A8C005D718B!opendocument

http://jorgedeflon.wordpress.com/2007/07/25/%C2%BFquieres-ser-un-arquitecto-de-software/

http://msmvps.com/blogs/otelis/archive/2008/01/08/hablemos-de-arquitectura-de-software.aspx

DESVENTAJAS

Decisiones tempranas de diseño. La Arquitectura de Software representa la encarnación de las decisiones de diseño más tempranas sobre un sistema, y esos vínculos tempranos tienen un peso fuera de toda proporción en su gravedad individual con respecto al desarrollo restante del sistema, su servicio en el despliegue y su vida de mantenimiento. La arquitectura representa lo que el método SAAM una puerta de peaje: el desarrollo no puede proseguir hasta que los participantes involucrados aprueben su diseño.

Mas que desventajas la Arquitectura de Software presenta problemas que son la evaluación dominante de la trayectoria de la Arquitectura de Software es abiertamente positiva, en los primeros años del siglo comienzan a percibirse desacuerdos y frustraciones en el proyecto de la disciplina. Por empezar, está muy claro que la definición original del proyecto, formulada en círculos académicos, guarda poca relación con la imagen que se tiene de la Arquitectura de Software en las prácticas de la industria. Aún dentro de los confines de aquel círculo, a menudo las presentaciones distan de ser contribuciones desinteresadas y representan más bien posturas teóricas particulares que se quieren imponer por vía de la argumentación. Muchas de esas posturas son más programáticas que instrumentales. Un número desmesurado de artículos y ponencias destaca asimismo la frustración que muchos sienten por no haber podido consensuar una definición de la AS universalmente aceptada.

Vale la pena revisar el inventario de aspectos negativos elaborada por Clements y Northrop:

Los abogados de la distintas posturas traen sus sesgos consigo. En efecto, mientras las definiciones propuestas para la Arquitectura de Software coinciden en su núcleo, difieren seriamente en los bordes. Algunos autores requieren que la arquitectura incluya racionalización, otros piden más bien pasos para el proceso de construcción. Algunos exigen que se identifique la funcionalidad de los componentes, otros alegan que una simple topología es suficiente. En la lectura de los textos de Arquitectura de Software se torna esencial entonces conocer la motivación de sus responsables.

El estudio de la AS está siguiendo a la práctica, no liderándola. El estudio de la Arquitectura de Software ha evolucionado de la observación de los principios de diseño y las acciones que toman los diseñadores cuando trabajan en sistemas de la vida real. La Arquitectura de Software es un intento de abstraer los rasgos comunes inherentes al diseño de sistemas, y como tal debe dar cuenta de un amplio rango de actividades, conceptos, métodos, estrategias y resultados. Lo que en realidad sucede es que la Arquitectura de Software se redefine constantemente en función de lo que hacen los programadores.

El estudio es sumamente nuevo. Aunque sus raíces se prolongan en el tiempo, el campo de la Arquitectura de Software es realmente muy nuevo, según puede juzgarse de la reciente avalancha de libros, conferencias, talleres y literatura consagrado a ella.

Las fundamentaciones han sido imprecisas. El campo se ha destacado por la proliferación de términos inciertos, verdaderas amenazas para los no precavidos. Por ejemplo, la arquitectura definida como “la estructura global de un sistema” agrega confusión en lugar de reducirla, porque implica que un sistema posee una sola estructura.

El término se ha usado en exceso. El significado de la palabra “arquitectura” en su relación con la ingeniería de software se ha ido diluyendo simplemente porque parece estar de moda. Es posible encontrar referencias a las siguientes “clases” de arquitectura: específica de dominio, megaprogramación, destinatario, sistemas, redes, infraestructura, aplicaciones, operaciones, técnica, framework, conceptual, de referencia, empresarial, de factoría, C4I, de manufactura, de edificio, de máquina-herramienta, etcétera. A menudo la palabra “arquitectura” se usa de maneras inapropiadas.

VENTAJAS

Comunicación mutua. La Arquitectura de Software representa un alto nivel de abstracción común que la mayoría de los participantes, si no todos, pueden usar como base para crear entendimiento mutuo, formar consenso y comunicarse entre sí. En sus mejores expresiones, la descripción arquitectónica expone las restricciones de alto nivel sobre el diseño del sistema, así como la justificación de decisiones arquitectónicas fundamentales.

Restricciones constructivas. Una descripción arquitectónica proporciona blueprints parciales para el desarrollo, indicando los componentes y las dependencias entre ellos. Por ejemplo, una vista en capas de un arquitectura documenta típicamente los límites de abstracción entre las partes, identificando las principales interfaces y estableciendo las formas en que unas partes pueden interactuar con otras.

Reutilización, o abstracción transferible de un sistema. La Arquitectura de Software encarna un modelo relativamente pequeño, intelectualmente tratable, de la forma en que un sistema se estructura y sus componentes se entienden entre sí; este modelo es transferible a través de sistemas; en particular, se puede aplicar a otros sistemas que exhiben requerimientos parecidos y puede promover reutilización en gran escala. El diseño arquitectónico soporta reutilización de grandes componentes o incluso de frameworks en el que se pueden integrar componentes.

Evolución. La Arquitectura de Software puede exponer las dimensiones a lo largo de las cuales puede esperarse que evolucione un sistema. Haciendo explícitas estas “paredes” perdurables, quienes mantienen un sistema pueden comprender mejor las ramificaciones de los cambios y estimar con mayor precisión los costos de las modificaciones. Esas delimitaciones ayudan también a establecer mecanismos de conexión que permiten manejar requerimientos cambiantes de interoperabilidad, prototipado y reutilización.

Análisis. Las descripciones arquitectónicas aportan nuevas oportunidades para el análisis, incluyendo verificaciones de consistencia del sistema, conformidad con las restricciones impuestas por un estilo, conformidad con atributos de calidad, análisis de dependencias y análisis específicos de dominio y negocios.

Administración. La experiencia demuestra que los proyectos exitosos consideran una arquitectura viable como un logro clave del proceso de desarrollo industrial. La evaluación crítica de una arquitectura conduce típicamente a una comprensión más clara de los requerimientos, las estrategias de implementación y los riegos potenciales.

CLASIFICACION

Arquitectura como etapa de ingeniería y diseño orientada a objetos.emostrativa sería la de Grady Booch; para él, la Arquitectura de Software es “la estructura lógica y física de un sistema, forjada por todas las decisiones estratégicas y tácticas que se aplican durante el desarrollo”. Otras definiciones revelan que la Arquitectura de Software, en esta perspectiva, concierne a decisiones sobre organización, selección de elementos estructurales, comportamiento, composición y estilo arquitectónico susceptibles de ser descriptas a través de las cinco vistas clásicas del modelo 4+1 de Kruchten.

Arquitectura estructural, basada en un modelo estático de estilos, ADLs y vistas. Constituye la corriente fundacional y clásica de la disciplina. Los representantes de esta corriente son todos académicos, mayormente de la Universidad Carnegie Mellon en Pittsburgh: Mary Shaw, Paul Clements, David Garlan, Robert Allen, Gregory Abowd, John Ockerbloom. Se trata también de la visión de la AS dominante en la academia, y aunque es la que ha hecho el esfuerzo más importante por el reconocimiento de la Arquitectura de Softaware como disciplina, sus categorías y herramientas son todavía mal conocidas en la práctica industrial. En el interior del movimiento se pueden observar distintas divisiones. Hay una variante informal de “boxología” y una vertiente más formalista, representada por el grupo de Mark Moriconi en el SRI de Menlo Park. En principio se pueden reconocer tres modalidades en cuanto a la formalización; los más informales utilizan descripciones verbales o diagramas de cajas, los de talante intermedio se sirven de ADLs y los más exigentes usan lenguajes formales de especificación como CHAM y Z. En toda la corriente, el diseño arquitectónico no sólo es el de más alto nivel de abstracción, sino que además no tiene por qué coincidir con la configuración explícita de las aplicaciones; rara vez se encontrarán referencias a lenguajes de programación o piezas de código, y en general nadie habla de clases o de objetos. Mientras algunos participantes excluyen el modelo de datos de las incumbencias de la AS (Shaw, Garlan, etc), otros insisten en su relevancia (Medvidovic, Taylor). Todo estructuralismo es estático; hasta fines del siglo XX, no está muy claro el tema de la posición del modelado arquitectónico en el ciclo de vida.

Estructuralismo arquitectónico radical. Se trata de un desprendimiento de la corriente anterior, mayoritariamente europeo, que asume una actitud más confrontativa con el mundo UML. En el seno de este movimiento hay al menos dos tendencias, una que excluye de plano la relevancia del modelado orientado a objetos para la Arquitectura de Softaware y otra que procura definir nuevos metamodelos y estereotipos de UML como correctivos de la situación. Dado que pueden existir dudas sobre la materialidad de esta corriente como tal, proporcionamos referencias bibliográficas masivas que corroboran su existencia. Pasaremos revista a los argumentos más fuertes en contra de UML emanados de este movimiento en el capítulo correspondiente del documento sobre lenguajes de descripción arquitectónica.

Arquitectura basada en patrones. Si bien reconoce la importancia de un modelo emanado históricamente del diseño orientado a objetos, esta corriente surgida hacia 1996 no se encuentra tan rígidamente vinculada a UML en el modelado, ni a CMM en la metodología. El texto sobre patrones que esta variante reconoce como referencia es la serie POSA de Buschmann y otros y secundariamente el texto de la Banda de los Cuatro. La diferencia entre ambos textos sagrados de la comunidad de patrones no es menor; en el primero, la expresión “Software Architecture” figura en el mismo título; el segundo se llama Design Patterns: Elements of reusable Object-Oriented software y su tratamiento de la arquitectura es mínimo. En esta manifestación de la AS prevalece cierta tolerancia hacia modelos de proceso tácticos, no tan macroscópicos, y eventualmente se expresa cierta simpatía por las ideas de Martin Fowler y las premisas de la programación extrema. El diseño consiste en identificar y articular patrones preexistentes, que se definen en forma parecida a los estilos de arquitectura .

Arquitectura procesual. Desde comienzos del siglo XXI, con centro en el SEI y con participación de algunos (no todos) los arquitectos de Carnegie Mellon de la primera generación y muchos nombres nuevos de la segunda: Rick Kazman, Len Bass, Paul Clements, Felix Bachmann, Fabio Peruzzi, Jeromy Carrière, Mario Barbacci, Charles Weinstock. Intenta establecer modelos de ciclo de vida y técnicas de elicitación de requerimientos, brainstorming, diseño, análisis, selección de alternativas, validación, comparación, estimación de calidad y justificación económica específicas para la arquitectura de software. Toda la documentación puede encontrarse ordenada en el SEI, pero no se mezcla jamás con la de CMM, a la que redefine de punta a punta. Otras variantes dentro de la corriente procesual caracterizan de otras maneras de etapas del proceso: extracción de arquitectura, generalización, reutilización .

Arquitectura basada en escenarios. Es la corriente más nueva. Se trata de un movimiento predominantemente europeo, con centro en Holanda. Recupera el nexo de la AS con los requerimientos y la funcionalidad del sistema, ocasionalmente borroso en la arquitectura estructural clásica. Los teóricos y practicantes de esta modalidad de arquitectura se inscriben dentro del canon delineado por la arquitectura procesual, respecto de la cual el movimiento constituye una especialización. En esta corriente suele utilizarse diagramas de casos de uso UML como herramienta informal u ocasional, dado que los casos de uso son uno de los escenarios posibles. Los casos de uso no están orientados a objeto. Los autores vinculados con esta modalidad han sido, aparte de los codificadores de ATAM, CBAM, QASAR y demás métodos del SEI, los arquitectos holandeses de la Universidad Técnica de Eindhoven, de la Universidad Brije, de la Universidad de Groningen y de Philips Research: Mugurel Ionita, Dieter Hammer, Henk Obbink, Hans de Bruin, Hans van Vliet, Eelke Folmer, Jilles van Gurp, Jan Bosch. La profusión de holandeses es significativa; la Universidad de Eindhoven es, incidentalmente, el lugar en el que surgió lo que P. I. Sharp propopía llamar la escuela arquitectónica de Dijkstra.

Definiciones

No es novedad que ninguna definición de la Arquitectura de Software es respaldada unánimemente por la totalidad de los arquitectos. El número de definiciones circulantes alcanza un orden de tres dígitos, amenazando llegar a cuatro. De hecho, existen grandes compilaciones de definiciones alternativas o contrapuestas, como la colección que se encuentra en el SEI (http://www.sei.cmu.edu/architecture/definitions.html), a la que cada quien puede agregar la suya. En general, las definiciones entremezclan despreocupadamente el trabajo dinámico de estipulación de la arquitectura dentro del proceso de ingeniería o el diseño (su lugar en el ciclo de vida), la configuración o topología estática de sistemas de software contemplada desde un elevado nivel de abstracción y la caracterización de la disciplina que se ocupa de uno de esos dos asuntos, o de ambos.
Una definición reconocida es la de Clements : La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones.
En una definición semejante, hay que aclararlo, la idea de “componente” no es la de la correspondiente tecnología de desarrollo (COM, CORBA Component Model, EJB), sino la de elemento propio de un estilo. Un componente es una cosa, una entidad, a la que los arquitectos prefieren llamar “componente” antes que “objeto”, por razones que se verán en otros documentos de esta serie pero que ya es obvio imaginar cuáles han de ser.
A despecho de la abundancia de definiciones del campo de la AS, existe en general acuerdo de que ella se refiere a la estructura a grandes rasgos del sistema, estructura consistente en componentes y relaciones entre ellos . Estas cuestiones estructurales se vinculan con el diseño, pues la Arquitectura de Software es después de todo una forma de diseño de software que se manifiesta tempranamente en el proceso de creación de un sistema; pero este diseño ocurre a un nivel más abstracto que el de los algoritmos y las estructuras de datos. En el que muchos consideran un ensayo seminal de la disciplina, Mary Shaw y David Garlan sugieren que dichas cuestiones estructurales incluyen organización a grandes rasgos y estructura global de control; protocolos para la comunicación, la sincronización y el acceso a datos; la asignación de funcionalidad a elementos del diseño; la distribución física; la composición de los elementos de diseño; escalabilidad y rendimiento; y selección entre alternativas de diseño .
En una definición tal vez demasiado amplia, David Garlan [Gar00] establece que la AS constituye un puente entre el requerimiento y el código, ocupando el lugar que en los gráficos antiguos se reservaba para el diseño. La definición “oficial” de AS se ha acordado que sea la que brinda el documento de IEEE Std 1471-2000, adoptada también por Microsoft, que reza así:

La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución.

Aunque las literaturas de ambos campos rara vez convergen, entendemos que es productivo contrastar esa definición con la de ingeniería de software, conforme al estándar IEEE 610.12.1990:

La aplicación de una estrategia sistemática, disciplinada y cuantificable al desarrollo, aplicación y mantenimiento del software; esto es, la aplicación de la ingeniería al software.

Obsérvese entonces que la noción clave de la arquitectura es la organización (un concepto cualitativo o estructural), mientras que la ingeniería tiene fundamentalmente que ver con una sistematicidad susceptible de cuantificarse.