jueves, 25 de septiembre de 2008
Conclusiones
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
DESVENTAJAS
Decisiones tempranas de diseño.
Vale la pena revisar el inventario de aspectos negativos elaborada por Clements y Northrop:
VENTAJAS
Comunicación mutua.
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.
Evolució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,
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
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
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
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
Definiciones
No es novedad que ninguna definición de
Una definición reconocida es la de Clements :
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
En una definición tal vez demasiado amplia, David Garlan [Gar00] establece que
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.
miércoles, 24 de septiembre de 2008
ANTECEDENTES HISTORICOS
Se trata entonces de una práctica joven, de apenas unos doce años de trabajo constante, que en estos momentos experimenta una nueva ola creativa en el desarrollo cabal de sus técnicas en la obra de Rick Kazman, Mark Klein, Len Bass y otros metodólogos en el contexto del SEI, en la misma universidad. A comienzos del siglo XXI comienzan ya a discernirse tendencias, cuyas desavenencias mutuas todavía son leves: al menos una en el sur de California (Irvine y Los Ángeles) con Nenad Medvidovic, David Rosenblum y Richard Taylor, otra en el SRI de Menlo Park con Mark Moriconi y sus colegas y otra más vinculada a las recomendaciones formales de
Cada vez que se narra la historia de la arquitectura de software (o de la ingeniería de software, según el caso), se reconoce que en un principio, hacia 1968, Edsger Dijkstra, de
En la conferencia de
“Pienso que tenemos algo, aparte de la ingeniería de software: algo de lo que hemos hablado muy poco pero que deberíamos poner sobre el tapete y concentrar la atención en ello. Es la cuestión de la arquitectura de software. La arquitectura es diferente de la ingeniería. Como ejemplo de lo que quiero decir, echemos una mirada a OS/360. Partes de OS/360 están extremadamente bien codificadas. Partes de OS, si vamos al detalle, han utilizado técnicas que hemos acordado constituyen buena práctica de programación. La razón de que OS sea un amontonamiento amorfo de programas es que no tuvo arquitecto. Su diseño fue delegado a series de grupos de ingenieros, cada uno de los cuales inventó su propia arquitectura. Y cuando esos pedazos se clavaron todos juntos no produjeron una tersa y bella pieza de software .”
Sharp continúa su alegación afirmando que con el tiempo probablemente llegue a hablarse de “la escuela de arquitectura de software de Dijkstra” y se lamenta que en la industria de su tiempo se preste tan poca o ninguna atención a la arquitectura. La frase siguiente también es extremadamente visionaria:
“Lo que sucede es que las especificaciones de software se consideran especificaciones funcionales. Sólo hablamos sobre lo que queremos que haga el programa. Es mi creencia que cualquiera que sea responsable de la implementación de una pieza de software debe especificar más que esto. Debe especificar el diseño, la forma; y dentro de ese marco de referencia, los programadores e ingenieros deben crear algo. Ningún ingeniero o programador, ninguna herramienta de programación, nos ayudará, o ayudará al negocio del software, a maquillar un diseño feo. El control, la administración, la educación y todas las cosas buenas de las que hablamos son importantes; pero la gente que implementa debe entender lo que el arquitecto tiene en mente .”
En 1975, Brooks, diseñador del sistema operativo OS/360 y Premio Turing 2000, utilizaba el concepto de arquitectura del sistema para designar “la especificación completa y detallada de la interfaz de usuario” y consideraba que el arquitecto es un agente del usuario, igual que lo es quien diseña su casa [Bro75], empleando una nomenclatura que ya nadie aplica de ese modo. En el mismo texto, identificaba y razonaba sobre las estructuras de alto nivel y reconocía la importancia de las decisiones tomadas a ese nivel de diseño. También distinguía entre arquitectura e implementación; mientras aquella decía qué hacer, la implementación se ocupa de cómo. Aunque el concepto de AS actual y el de Brooks difieren en no escasa medida, el texto de Brooks The mythical man-month sigue siendo, un cuarto de siglo más tarde, el más leído en ingeniería de software. Se ha señalado que Dijkstra y Brooks, el primero partidario de un formalismo matemático y el segundo de considerar las variables humanas, constituyen dos personalidades opuestas, que se sitúan en los orígenes de las metodologías fuertes y de las heterodoxias ágiles, respectivamente ; pero eso será otra historia.
Una novedad importante en la década de 1970 fue el advenimiento del diseño estructurado y de los primeros modelos explícitos de desarrollo de software. Estos modelos comenzaron a basarse en una estrategia más orgánica, evolutiva, cíclica, dejando atrás las metáforas del desarrollo en cascada que se inspiraban más bien en la línea de montaje de la ingeniería del hardware y la manufactura. Surgieron entonces las primeras investigaciones académicas en materia de diseño de sistemas complejos o “intensivos”. Poco a poco el diseño se fue independizando de la implementación, y se forjaron herramientas, técnicas y lenguajes de modelado específicos.
En la misma época, otro precursor importante, David Parnas, demostró que los criterios seleccionados en la descomposición de un sistema impactan en la estructura de los programas y propuso diversos principios de diseño que debían seguirse a fin de obtener una estructura adecuada. Parnas desarrolló temas tales como módulos con ocultamiento de información , estructuras de software y familias de programas, enfatizando siempre la búsqueda de calidad del software, medible en términos de economías en los procesos de desarrollo y mantenimiento. Aunque Dijkstra, con sus frases lapidarias y memorables, se ha convertido en la figura legendaria por excelencia de los mitos de origen de
En 1972, Parnas publicó un ensayo en el que discutía la forma en que la modularidad en el diseño de sistemas podía mejorar la flexibilidad y el control conceptual del sistema, acortando los tiempos de desarrollo . Introdujo entonces el concepto de ocultamiento de información (information hiding), uno de los principios de diseño fundamentales en diseño de software aún en la actualidad. La herencia de este concepto en la ingeniería y la arquitectura ulterior es inmensa, y se confunde estrechamente con la idea de abstracción. En la segunda de las descomposiciones que propone Parnas comienza a utilizarse el ocultamiento de información como criterio. “Los módulos ya no se corresponden con las etapas de procesamiento. ? Cada módulo en la segunda descomposición se caracteriza por su conocimiento de una decisión de diseño oculta para todos los otros módulos. Su interfaz o definición se escoge para que revele tan poco como sea posible sobre su forma interna de trabajo”. Cada módulo deviene entonces una caja negra para los demás módulos del sistema, los cuales podrán acceder a aquél a través de interfaces bien definidas, en gran medida invariables. Es fácil reconocer en este principio ideas ya presentadas por Dijkstra en su implementación del THE-Multiprogramming System. Pero la significación del artículo de 1972 radica en la idea de Parnas de basar la técnica de modularización en decisiones de diseño, mientras que los “niveles de abstracción” de Dijkstra involucraban más bien (igual que su famosa invectiva en contra del Go-to) técnicas de programación.
El concepto de ocultamiento se fue mezclando con encapsulamiento y abstracción, tras algunos avatares de avance y retroceso. Los arquitectos más escrupulosos distinguen entre encapsulamiento y ocultamiento, considerando a aquél como una capacidad de los lenguajes de programación y a éste como un principio más general de diseño. De hecho, Parnas no hablaba en términos de programación orientada a objeto, sino de módulos y sub-rutinas, porque el momento de los objetos no había llegado todavía.El pensamiento de Parnas sobre familias de programas, en particular, anticipa ideas que luego habrían de desarrollarse a propósito de los estilos de arquitectura:
“Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o lo serán alguna vez) a los cuales es provechoso o útil considerar como grupo. Esto evita el uso de conceptos ambiguos tales como “similitud funcional” que surgen a veces cuando se describen dominios. Por ejemplo, los ambientes de ingeniería de software y los juegos de video no se consideran usualmente en el mismo dominio, aunque podrían considerarse miembros de la misma familia de programas en una discusión sobre herramientas que ayuden a construir interfaces gráficas, que casualmente ambos utilizan.”
Una familia de programas puede enumerarse en principio mediante la especificación del árbol de decisión que se atraviesa para llegar a cada miembro de la familia. Las hojas del árbol representan sistemas ejecutables. El concepto soporta la noción de derivar un miembro de la familia a partir de uno ya existente. El procedimiento consiste en seguir hacia atrás el árbol hasta que se alcanza un nodo (punto de decisión) genealógicamente común a ambos, y luego proceder hacia abajo hasta llegar al miembro deseado. El concepto también soporta la noción de derivar varios miembros de la familia de un punto de decisión común, aclarando la semejanza y las diferencias entre ellos.
Las decisiones iniciales son las que más probablemente permanecerán constantes entre los miembros; las decisiones más tardías (cerca de las hojas) en un árbol prudentemente estructurado deberían representar decisiones susceptibles de cambiarse trivialmente, tales como los valores de tiempo de compilación o las constantes de tiempo de carga. La significación del concepto de familia de programas para
Decía Parnas que las decisiones tempranas de desarrollo serían las que probablemente permanecerían invariantes en el desarrollo ulterior de una solución. Esas “decisiones tempranas” constituyen de hecho lo que hoy se llamarían decisiones arquitectónicas. Como escriben Clements y Northrop en todo el desenvolvimiento ulterior de la disciplina permanecería en primer plano esta misma idea: la estructura es primordial (structure matters), y la elección de la estructura correcta ha de ser crítica para el éxito del desarrollo de una solución. Ni duda cabe que “la elección de la estructura correcta” sintetiza, como ninguna otra expresión, el programa y la razón de ser de
En la década de 1980, los métodos de desarrollo estructurado demostraron no escalar suficientemente y fueron dejando el lugar a un nuevo paradigma, el de la programación orientada a objetos. En teoría, parecía posible modelar el dominio del problema y el de la solución en un lenguaje de implementación. La investigación que llevó a lo que después sería el diseño orientado a objetos puede remontarse incluso a la década de 1960 con Simula, un lenguaje de programación de simulaciones, el primero que proporcionaba tipos de datos abstractos y clases, y después fue refinada con el advenimiento de Smalltalk. Paralelamente, hacia fines de la década de 1980 y comienzos de la siguiente, la expresión arquitectura de software comienza a aparecer en la literatura para hacer referencia a la configuración morfológica de una aplicación.
Mientras se considera que la ingeniería de software se fundó en 1968, cuando F.L. Bauer usó ese sintagma por primera vez en la conferencia de
El primer estudio en que aparece la expresión “arquitectura de software” en el sentido en que hoy lo conocemos es sin duda el de Perry y Wolf ; ocurrió tan tarde como en 1992, aunque el trabajo se fue gestando desde 1989. En él, los autores proponen concebir
“El propósito de este paper es construir el fundamento para la arquitectura de software. Primero desarrollaremos una intuición para la arquitectura de software recurriendo a diversas disciplinas arquitectónicas bien definidas. Sobre la base de esa intuición, presentamos un modelo para la arquitectura de software que consiste en tres componentes: elementos, forma y razón (rationale). Los elementos son elementos ya sea de procesamiento, datos o conexión. La forma se define en términos de las propiedades de, y las relaciones entre, los elementos, es decir, restricciones operadas sobre ellos. La razón proporciona una base subyacente para la arquitectura en términos de las restricciones del sistema, que lo más frecuente es que se deriven de los requerimientos del sistema. Discutimos los componentes del modelo en el contexto tanto de la arquitectura como de los estilos arquitectónicos....”
La declaración, como puede verse, no tiene una palabra de desperdicio: cada idea cuenta, cada intuición ha permanecido viva desde entonces. Los autores prosiguen reseñando el progreso de las técnicas de diseño en la década de 1970, en la que los investigadores pusieron en claro que el diseño es una actividad separada de la implementación y que requiere notaciones, técnicas y herramientas especiales. Los resultados de esta investigación comienzan ahora (decían en 1992) a penetrar el mercado en la forma de herramientas de ingeniería asistida por computadoras, CASE. Pero uno de los resultados del uso de estas herramientas ha sido que se produjo la absorción de las herramientas de diseño por los lenguajes de implementación. Esta integración ha tendido a esfumar, si es que no a confundir, la diferencia entre diseño e implementación. En la década de 1980 se perfeccionaron las técnicas descriptivas y las notaciones formales, permitiéndonos razonar mejor sobre los sistemas de software. Para la caracterización de lo que sucederá en la década siguiente ellos formulan esta otra frase que ha quedado inscripta en la historia mayor de la especialidad:
“La década de 1990, creemos, será la década de la arquitectura de software. Usamos el término “arquitectura” en contraste con “diseño”, para evocar nociones de codificación, de abstracción, de estándares, de entrenamiento formal (de los arquitectos de software) y de estilo. ? Es tiempo de re-examinar el papel de la arquitectura de software en el contexto más amplio del proceso de software y de su administración, así como señalar las nuevas técnicas que han sido adoptadas.”
Considerada como disciplina por mérito propio,
Dando cumplimiento a las profecías de Perry y Wolf, la década de 1990 fue sin duda la de la consolidación y diseminación de
Un segundo gran tema de la época fue el surgimiento de los patrones, cristalizada en dos textos fundamentales, el de
A lo largo de una cadena de intermediarios y pensadores originales, las ideas llegaron por fin a la informática diez años más tarde. Si bien la idea de arquitectura implícita en el trabajo actual con patrones está más cerca de la implementación y el código, y aunque la reutilización de patrones guarda estrecha relación con la tradición del diseño concreto orientado a objetos, algunos arquitectos emanados de la escuela de Carnegie Mellon formalizaron un acercamiento con esa estrategia. Tanto en los patrones como en la arquitectura, la idea dominante es la de re-utilización. A impulsos de otra idea mayor de la época (la crisis del software), la bibliografía sobre el impacto económico de la re-utilización alcanza hoy magnitudes de cuatro dígitos.
Como quiera que sea,
Uno de los acontecimientos arquitectónicos más importantes del año 2000 fue la hoy célebre tesis de Roy Fielding que presentó el modelo REST, el cual establece definitivamente el tema de las tecnologías de Internet y los modelos orientados a servicios y recursos en el centro de las preocupaciones de la disciplina. En el mismo año se publica la versión definitiva de la recomendación IEEE Std 1471, que procura homogeneizar y ordenar la nomenclatura de descripción arquitectónica y homologa los estilos como un modelo fundamental de representación conceptual.
En el siglo XXI,
