Universidad Nacional Experimental
de los Llanos Ocidentales Ezequiel Zamora
UNELLEZ- Barinas

Arquitectura del
software

B...
Breve historia de la arquitectura de software: Sus inicios y fundamentos.
Aunque el término arquitectura de software, tal ...
También en este año se abren nuevas perspectivas para la arquitectura de software, aparecen las
estrategias orientadas a l...
primera magnitud y tal vez unos cuarenta o cincuenta propuestos en ponencias que no
han resistido el paso del tiempo o que...
hecho, en el título y en los contenidos de numerosos papers de la profesión [MB02] [CN96].
Conceptos como el de estilo, o ...
Herramientas y ambientes de diseño arquitectónico
Estudios de casos

Modalidades y tendencias en la arquitectura de soft...
La arquitectura se encarga de: Selección de tecnologías Requerimientos no funcionales Manejo de
riesgos, etc. y el Diseño ...
los que se agrupan en torno de los patrones se confunden a veces con ingenieros y diseñadores,
cuando no con programadores...
La dinámica incontenible de la producción de patrones en la práctica de la arquitectura desoftware,
su carácter entusiasta...
Upcoming SlideShare
Loading in...5
×

Arquitectura del software

161

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
161
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Arquitectura del software

  1. 1. Universidad Nacional Experimental de los Llanos Ocidentales Ezequiel Zamora UNELLEZ- Barinas Arquitectura del software Bachilleres: 21.168.736 Caro José 19.193.035 Díaz Nohely Barinas, Enero 2014
  2. 2. Breve historia de la arquitectura de software: Sus inicios y fundamentos. Aunque el término arquitectura de software, tal y como lo concebimos ahora, aparece en 1992 con el trabajo de Perry y Wolf, sus antecedentes se remontan al menos hasta finales de la década de los sesenta. En 1968, Dijkstra habla de una estructuración correcta de los sistemas de software, aunque no la llama arquitectura como tal. Posteriormente, en 1969, P. I. Sharp, comentando las ideas de Dijkstra, ya usa el término arquitectura de software al mencionar que quizá luego se hable de “la escuela de arquitectura de software de Dijkstra”, y al mismo tiempo lamentar que la industria de ese tiempo preste muy poca atención a ésta. Durante la década de los setentas el concepto de arquitectura deambuló por el aire sin una semántica clara y carente de una expresión pragmática. En esta misma década, el diseño estructurado dio pie a la independencia entre el diseño y la implementación. Los trabajos de Parnas sobre técnicas de modularización en decisiones de diseño y familias de programas, fueron, sin duda, aportaciones esenciales y permanentes. Rompiendo esquemas y acaparando la atención en la década de los ochentas, aparece el paradigma de la orientación a objetos. En esta década aparecen dos trabajos importantes de Mary Shaw, que retoman las abstracciones de alto nivel: “Técnicas de abstracción en lenguajes modernos de programación” y “Los sistemas de gran escala requieren de abstracciones de alto nivel”. Hacia finales de los ochenta y principios de los noventa, comienza a gestarse de manera más clara la idea de que las aplicaciones tienen una morfología, una estructura. El trabajo de Perry y Wolf de 1992 es el punto de partida para lo que hoy conocemos como arquitectura de software. Por un lado, son los primeros que proponen un modelo para la arquitectura de software; este modelo contempla a la arquitectura formada por tres componentes: elementos, forma y razón. Los elementos pueden ser de procesamiento, datos o conexión; la forma se define de acuerdo a las propiedades , y a las relaciones entre los elementos; la razón se contempla en términos de restricciones del sistema, que se derivan de los requerimientos del sistema. Perry y Wolf profetizaron que: “la década de los noventas, creemos, será la década de la arquitectura de software”, lo cual se convirtió en realidad. A lo largo de esa década, salieron a la luz varios trabajos con propuestas relevantes, entre ellas, la programación basada en componentes, el surgimiento de los patrones y estilos, el modelo de 4+1 vistas, y lenguajes de descripción de arquitecturas (ADL) entre otras. En la segunda mitad de los noventa aparecen los primeros libros de texto dedicados a la arquitectura de software. El año 2000 cierra esta década con dos trabajos clave: el modelo REST propuesto en la tesis de Roy Fielding que pone la atención en Internet y los modelos orientados a servicios; y el trabajo de la IEEE, que genera una versión definitiva de la recomendación IEEE std 1471-2000.
  3. 3. También en este año se abren nuevas perspectivas para la arquitectura de software, aparecen las estrategias orientadas a líneas de productos y se procura insertar la arquitectura de software dentro del ciclo de vida, obligando a redefinir las metodologías referentes a él en términos de arquitectura. Actualmente hay una cierta efervescencia alrededor de desarrollos centrados en arquitectura, métodos de análisis y diseño de arquitecturas (dentro del ciclo de vida), análisis de arquitecturas de software basados en escenarios, modelos de evaluación de arquitecturas de software y modelos orientados por la arquitectura entre algunos otros tópicos. Definición de los conceptos fundamentales: Estilos:Un estilo es un concepto descriptivo que define una forma de articulación u organización arquitectónica. El conjunto de los estilos cataloga las formas básicas posibles de estructuras de software, mientras que las formas complejas se articulan mediante composición de los estilos fundamentales. Sucintamente descriptos, los estilos conjugan elementos (o “componentes”, como se los llama aquí), conectores, configuraciones y restricciones. Al estipular los conectores como elemento de juicio de primera clase, el concepto de estilo, incidentalmente, se sitúa en un orden de discurso y de método que el modelado orientado a objetos en general y UML en particular no cubren satisfactoriamente. La descripción de un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor es hacerlo en un lenguaje de descripción arquitectónica o en lenguajes formales de especificación. A diferencia de los patrones de diseños, que son centenares, los estilos se ordenan en seis o siete clases fundamentales y unos veinte ejemplares, como máximo. Es digno de señalarse el empeño por subsumir todas las formas existentes de aplicaciones en un conjunto de dimensiones tan modestas. Las arquitecturas complejas o compuestas resultan del agregado o la composición de estilos más básicos. Algunos estilos típicos son las arquitecturas basadas en flujo de datos, las peer-to-peer, las de invocación implícita, las jerárquicas, las centradas en datos o las de intérprete-máquina virtual. Lenguajes de descripción de arquitecturas: Los lenguajes de descripción de arquitecturas, o ADLs, ocupan una parte importante del trabajo arquitectónico desde la fundación de la disciplina. Se trata de un conjunto de propuestas de variado nivel de rigurosidad, casi todas ellas de extracción académica, que fueron surgiendo desde comienzos de la década de 1990 hasta la actualidad, más o menos en contemporaneidad con el proyecto de unificación de los lenguajes de modelado bajo la forma de UML. Los ADL difiere sustancialmente de UML, que al menos en su versión 1.x se estima inadecuado en su capacidad para expresar conectores en particular y en su modelo semántico en general para las clases de descripción y análisis que se requieren. Los ADLs permiten modelar una arquitectura mucho antes que se lleve a cabo la programación de las aplicaciones que la componen, analizar su adecuación, determinar sus puntos críticos y eventualmente simular su comportamiento. Los ADL son bien conocidos en los estudios universitarios de AS, pero muy pocos arquitectos de industria parecen conocerlos y son menos aún quienes los utilizan como instrumento en el diseño arquitectónico de sus proyectos. Hay unos veinte ADL de
  4. 4. primera magnitud y tal vez unos cuarenta o cincuenta propuestos en ponencias que no han resistido el paso del tiempo o que no han encontrado su camino en el mercado. Se han analizado esos lenguajes descriptivos en un documento aparte, en el cual se invita asimismo a su discusión. Frameworks y Vistas:Los frameworksson una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio. Las vistas, Al final, a este miembro de la familia le corresponde dibujar, o expresar la última forma de los datos: la interfaz gráfica que interactúa con el usuario final del programa (GUI). Después de todo, a este miembro le toca evidenciar la información obtenida hasta hacerla llegar al controlador. Solo (e inicialmente), nos espera demostrar la información. Procesos y metodología: Proceso;.Hace alusión a los marcos de trabajo las cuales son representados por vistas. Por ejemplo: las vistas estáticas se corresponden con las perspectivas particulares de los diferentes participantes y las vistas dinámicas tienen que ver con etapas del proceso, el ciclo de vida o metodología caracterizadas en requerimientos, análisis, diseño, implementación e integración. Metodología.Hace referencia a un frameworkque es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información: RUP, RAD, RSD, ARIS, PERA, CIMOSA, GRAI, GERAM, CMM. En el campo de a AS la dominante es el Modelo de Madurez de la Capacidad (CMM). Abstraccion: La idea de abstracción forma parte de lo que acaso sea la pieza conceptual más importante de la AS, el concepto de estilo; un estilo se identifica a grandes rasgos o ,como se dice habitualmente, en un estilo “menos es más”. La misma idea prevalece en todos los conceptos y procedimientos que se consideran arquitectónicos. Para Len Bass, Paul Clements y Rick Kazman [BCK98], si una decisión debe posponerse hasta el momento de tratar las cosas a un bajo nivel, no se trata de una decisión de arquitectura. Clements y Northrop [CN96] sostienen que el trabajo de Garlan y Shaw sobre los estilos arquitectónicos nos enseña que aunque los programas pueden combinarse de maneras prácticamente infinitas, hay mucho que ganar si nos restringimos a un conjunto relativamente pequeño de elecciones cuando se trata de cooperación e interacción. Las ventajas incluyen mejor reutilización, mejores análisis, menor tiempo se selección y mayor interoperabilidad. “Menos es más” figura, de
  5. 5. hecho, en el título y en los contenidos de numerosos papers de la profesión [MB02] [CN96]. Conceptos como el de estilo, o marcos como MSF, revelan su naturaleza arquitectónica en su abstracción y en su generalidad. Escenarios: Esta es una noción arquitectónica importante y se encuentra en la base de muchos de los métodos de diseño y desarrollo basados en arquitectura, como ALMA, SAAM y ATAM. Hay que ser precavidos y advertir desde el comienzo que lo que habitualmente se traduce como “escenario” no es estrictamente lo que en lengua castellana se designa como tal; la traducción correcta debería ser más bien “guión” o “libreto”. La traducción literal del término no hace más que aportar confusión. Desde Kruchten en adelante, se reconoce que los escenarios se dividen en dos categorías: casos de uso (secuencias de responsabilidades) y casos de cambio (modificaciones propuestas al sistema). Los escenarios han sido básicamente técnicas que se implementan en la elicitación de los requerimientos, particularmente en relación a los operadores de sistemas. Típicamente, la técnica comienza instrumentando sesiones de brainstorming. También se han utilizado escenarios como método para comparar alternativas de diseño. Los escenarios describen una utilización anticipada o deseada del sistema, y típicamente se expresan en una frase; Kazman, Abowd, Bass y Clements proponen también llamarlos viñetas Campos de la arquitectura del software: La AS es hoy en día un conjunto inmenso y heterogéneo de áreas de investigación teórica y de formulación práctica, por lo que conviene aunque más no sea enumerar algunos de sus campos y sus focos. Una semblanza semejante (de la que aquí se proporciona sólo un rudimento) dudosamente debería ser estática. La AS comenzó siendo una abstracción descriptiva puntual que en los primeros años no investigó de manera sistemática ni las relaciones que la vinculaban con los requerimientos previos, ni los pasos metodológicos a dar luego para comenzar a componer el diseño. Pero esa sincronicidad estructuralista no pudo sostenerse. Por el contrario, daría la impresión que, a medida que pasa el tiempo, la AS tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la ingeniería de software, sólo que a un mayor nivel de abstracción y agregando una nueva dimensión reflexiva en lo que concierne a la fundamentación formal del proceso. Hay unas pocas caracterizaciones (y mucha actividad de copiado y pegado) en torno de las áreas que componen el territorio. David Garlan y Dewayne Perry, en su introducción al volumen de abril de 1995 de IEEE Transactionson Software Engineering dedicado a la AS, en el cual se delinean las áreas de investigación más promisorias, enumeran las siguientes: Lenguajes de descripción de arquitecturas Fundamentos formales de la AS (bases matemáticas, caracterizaciones formales de propiedades extra-funcionales tales como mantenibilidad, teorías de la interconexión, etcétera). Técnicas de análisis arquitectónicas Métodos de desarrollo basados en arquitectura Recuperación y reutilización de arquitectura Codificación y guía arquitectónica
  6. 6. Herramientas y ambientes de diseño arquitectónico Estudios de casos Modalidades y tendencias en la arquitectura de software: Arquitectura como etapa de ingeniería y diseño orientada a objetos: Esta perspectiva concierne a decisiones sobre organización, selección de elementos estructurales, comportamiento, composición y estilo arquitectónicos susceptibles de ser descritas a través de las cinco vistas clásicas del modelo 4+1 de Kruchten (UML y Rational). Rumbaugh, Jacobson, Book, Larman, Kruchten, entre otros.. Arquitectura estructural: Basada en un modelo estático de estilos, ADLs y vistas. La representan los académicos de la Universidad Carnegie Mellon de Pittsbugh: Shaw, Clements, Garlan, Allen, Abowd, Ockerbloom. En ella se reconocen tres modalidades en cuanto a formalización: –Descripción verbales o diagramas de caja (los más informales) –Los que se sirven de ADLs (intermedios), y –Los que utilizan lenguajes formales de especificación como CHAM y Z (los más exigentes) Estructuralismo arquitectónico radical: Formada por un grupo europeo con una actitud confrontativa con UML. Tiene al menos dos tendencias: Una excluye el modelado OO para AS y otra integra metamodelos y estereotipos correctivos de UML Arquitectura basada en patrones: No está rígidamente vinculada con el modelado UML, ni a las metodologías de CMM. El diseño consiste en identificar y articular patrones preexistentes, que se definen en forma parecida a los estilos de arquitectura. Arquitectura procesual: 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. La documentación se encuentra en SEI, pero no se mezcla con CMM. 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, el cual es, ocasionalmente borroso en la arquitectura estructural clásica. 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. Diferencias entre arquitectura y diseño: Literalmente se dice que es lo mismo, pero yendo más profundo el diseño es una parte de la arquitectura, por eso se dice que ambas tienen el mismo propósito, la arquitectura de software en la estructura del sistema y en las interconexiones se diferencia del diseño, en otras palabras el diseño son todos los componentes en detalle, mientras que la arquitectura muestra como estos componentes se interconectan entre si formando su estructura.
  7. 7. La arquitectura se encarga de: Selección de tecnologías Requerimientos no funcionales Manejo de riesgos, etc. y el Diseño se encarga de: Los requerimientos funcionales Diseño detallado de componentes, etc. Repositorios y relevancia de la arquitectura del software: Un repositorio, depósito o archivo es un sitio centralizado donde se almacena y mantiene información digital, habitualmente bases de datos o archivos informáticos Existen unos cuantos repositorios de información arquitectónica, cuyas direcciones son más o menos permanentes. El más importante hoy en día parece ser el del Software EngineeringInstitute en la Universidad Carnegie Mellon de Pittsburgh, Pennsylvan (http://www.sei.cmu.edu/ata/ata_init.html). El sitio del SEI incluye abundante literatura académica y todas las especificaciones o recomendaciones metodológicas. Las páginas de cabecera de la estrategia de arquitectura de Microsoft se hallan en http://msdn.microsoft.com/architecture/. Las páginas de Patterns&Practices están en http://www.microsoft.com/resources/practices/completelist.asp. La estrategia arquitectónica misma se encuentra delineada en un documento de Michael Platt en http://msdn.microsoft.com/architecture/overview/default.aspx?pull=/library/enus/ dnea/html/eaarchover.asp. Numerosas editoriales, universidades, consorcios y centros de investigación incluyen vínculos ligados a la AS. Muy seguramente los lectores podrán suministrar otros sitios de referencia importantes. Las relevancia : Aunque todavía no se ha constituido un repositorio uniformizado de estudios de casos en base al cual se pueda extraer una conclusión responsable, la AS ha resultado instrumental en un número respetable de escenarios reduciendo costos, evitando errores, encontrando fallas, implementando sistemas de misión crítica. Cada uno de los documentos que describen lenguajes de descripción arquitectónica, por ejemplo, subraya su utilización exitosa en proyectos de gran envergadura requeridos por organizaciones de gobierno o por grandes empresas. Aún cuando aquí y allá se señalen dificultades ocasionales, nadie duda de la necesidad de una visión arquitectónica. Las virtudes de la arquitectura del software son: Comunicación mutua Decisiones tempranas Restricciones constructivas Reutilización, o abstracción transferible de un sistema. Evolución Análisis Administración Definiciones de estilo Los estilos sólo se manifiestan en arquitectura teórica descriptiva de alto nivel deabstracción; los patrones, por todas partes. Los partidarios de los estilos se definen desde el inicio como arquitectos;
  8. 8. los que se agrupan en torno de los patrones se confunden a veces con ingenieros y diseñadores, cuando no con programadores con conciencia sistemática o lo que alguna vez se llamó analistas de software. El primer grupo ha abundado en taxonomías internas de los estilos y en reflexión teórica; el segundo se ha mantenido, en general, refractario al impulso taxonómico, llevado por una actitud resueltamente empírica. Ambos, con mayor o menor plenitud y autoconciencia, participan del campo abarcativo de la arquitectura de software. Los estilos se encuentran en el centro de la arquitectura y constituyen buena parte de su sustancia. Los patrones de arquitectura están claramente dentro de la disciplina arquitectónica, solapándose con los estilos, mientras que los patrones de diseño se encuentran más bien en la periferia, si es que no decididamente afuera. Según esa definición, estilos y arquitectura nacen en el mismo momento. Con una sola excepción (documentada en el párrafo siguiente) no he podido encontrar referencias a la palabra estilos anteriores a 1992. Todavía en julio de ese año Robert Allen y David Garlan [AG92] de la Universidad de Carnegie Mellon se refieren a “paradigmas de arquitectura” y “estructuras de sistemas”, mencionando entre ellos lo que luego sería el familiar estilo tubería-filtros, los modelos de pizarra y los de flujo de datos. Con nombres idénticos, esos paradigmas pasarían a llamarse estilos un mes más tarde en todos los textos de la misma escuela primero y en toda la arquitectura de software después. Inventario y descripción de los estilos arquitectónicos: Los estilos que habrán de describirse a continuación no aspiran a ser todos los que se han propuesto, sino apenas los más representativos y vigentes. De más está decir que, como se ha visto, la agrupación de estilos y sub-estilos es susceptible de realizarse de múltiples formas, conforme a los criterios que se apliquen en la constitución de los ejemplares. No se ha de rendir cuentas aquí por la congruencia de la clasificación (nadie ha hecho lo propio con las suyas), porque cada vez que se la ha revisado en modo outline, se cedió a la tentación de cambiar su estructura, la cual seguirá sufriendo metamorfosis después de despachado el artículo. Se podrá apreciar que, en consonancia con los usos de la especialidad, la caracterización de los estilos no constituye un reflejo pormenorizado de los detalles de sus estructuras, sino una visión deliberadamente sucinta y genérica que destaca sus valores esenciales y sus rasgos distintivos. Entre acumular pormenores que podrían recabarse en otras fuentes y mantener el caudal descriptivo de cada estilo en una magnitud que facilite su comparación rápida con los demás se ha escogido, Saussureanamente, lo segundo. En cuanto a las formas de representación esquemática, se ha optado por reproducir el estilo gráfico característico de la literatura principal del género, el cual es deliberadamente informal y minimalista, en lugar de aplicar una notación formal o máselaborada. La notación se establecerá entonces en términos de lo que Shaw y Clementsllaman “boxology” [SC96]. Huelga decir que la descripción de los estilos puede hacerse también en términos de lenguajes descriptivos de arquitectura (ADLs) y las respectivas notaciones de las herramientas que se asocian con ellos, según puede verse en un estudio separado [Rey04b]. Resta anticipar que algunas especies de software conspicuas en la práctica no aparecen en los catálogos usuales de estilo. La ausencia más notoria concierne a los sistemas de workflow, que seguramente heredan el prejuicio ancestral de los ingenieros y arquitectos más refinados en contra de los diagramas de flujo y las abstracciones procesuales. Fred Brooks, por ejemplo, considera el diagrama de flujo como una abstracción muy pobre de la estructura de un sistema [Bro75] [Bro86]. Estilos y patrones de arquitectura y diseño:
  9. 9. La dinámica incontenible de la producción de patrones en la práctica de la arquitectura desoftware, su carácter entusiasta, cuando no militante, y la profusión de sus manifestaciones han atenuado la idea de que los patrones de diseño constituyen sólo uno de los paradigmas, marcos o formas del diseño arquitectónico, cada uno de los cuales posee una historia y una fundamentación distinta, y presenta, como todas las cosas en este terreno, sus sesgos, sus beneficios y sus limitaciones. Todo el mundo acepta que existen diversas clases de patrones: de análisis, de arquitectura (divididos en progresivamente estructurales, sistemas distribuidos, sistemas interactivos, sistemas adaptables), de diseño (conductuales, creacionales, estructurales), de organización o proceso, de programación y los llamados idiomas, entre otros. Cada autor que escribe sobre el asunto agrega una clase diferente, y los estándares en vigencia no hacen ningún esfuerzo para poner un límite a la proliferación de variedades y ejemplares. Como sea, concentrémonos inicialmente en los patrones de diseño. Un patrón de diseño, obviamente, debe encajar por un lado con otros tipos de patrones imaginables y por el otro con la teoría, la práctica y los marcos que en general rigen el diseño. ¿Cuáles son las grandes estrategias de diseño, si puede saberse? Una vez más, cuando llega el momento de disponer en un mapa las estrategias, los marcos de referencia o los paradigmas de diseño disponibles se encuentra multitud de propuestas clasificatorias que a veces no coinciden siquiera en la identificación de la disciplina en que se formulan. De todas maneras, estimo que es razonable pensar que las estrategias mayores de diseño pueden subsumirse en un conjunto relativamente manejable de cuatro o cinco tipos, uno de los cuales es, precisamente, el diseño orientado por patrones. Estas estrategias no necesariamente son excluyentes y antagónicas, pero se encuentran bastante bien delimitadas en la literatura usual [Tek00].

×