Fundamentos de la arquitectura de software

Fundamentos de la Fundamentos de la Arquitectura de softwareArquitectura de software

Integrantes:Integrantes:Roger Villegas C.I. 18.839.157Roger Villegas C.I. 18.839.157

Nathalinis Barrios C.I. 19.517.983Nathalinis Barrios C.I. 19.517.983

REPÚBLICA BOLIVARIANA DE VENEZUELAUNIVERSIDAD NACIONAL EXPERIMENTAL

DE LOS LLANOS OCCIDENTALES“EZEQUIEL ZAMORA” – UNELLEZ

BARINAS EDO BARINAS

Breve Historia de la Arquitectura del Breve Historia de la Arquitectura del softwaresoftware

1960 1960 la historia de la arquitectura del software remonta a la época de los años 60 desde ese entonces se empezó a utilizar el término cuando Edsger Dijkstra de la Universidad Tecnológica de Eindhoven en Holanda en 1968 propuso que se establezca una estructura correcta de los sistemas de software antes de que se inicie la programación como tal, escribiendo código de cualquier manera.

En 19691969 un año después de la sesión en que se fundara la ingeniería de software, P. I. Sharp formuló que la ingeniería era diferente a la “arquitectura”.

En 19691969 Fred Brooks Jr y Ken Iverson llamaban arquitectura a la estructura conceptual de un sistema en la perspectiva del programador


En 19721972, 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, introduciendo el concepto de Ocultamiento de información, 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 19751975, 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”.

En la década de 19801980, 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.


La década de 1990, fue la década de la “arquitectura de software”, dando cumplimiento a las profecías de Perry y Wolf, fue sin duda la década de consolidación y diseminación de la AS en una escala sin precedentes. Las contribuciones más importantes surgieron en torno del instituto de ingeniería de la información de la Universidad Carnegie Mellon (CMU SEI). En la misma década, demasiado pródiga en acontecimientos, surge también la programación basada en componentes, que en su momento de mayor impacto impulsó a algunos arquitectos mayores, como Paul Clements (Clements Enero de 1996.), a afirmar que la AS promovía un modelo que debía ser más de integración de componentes pre-programados que de programación.


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, siendo este, un aspecto fundamental de la AS (Wolfy Perry).

•El modelado OO y UML no lo cubren satisfactoriamente. •Su descripción, se puede formular en lenguaje natural o en

diagramas •Se recomienda hacerlo en un lenguaje de descripción

arquitectónica (ADLs) o en lenguajes formales de especificación. Ejemplos: 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.

Conceptos fundamentales• Lenguajes de descripción arquitectónica (ADLs) 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.

•Aparecieron a principios de los 90´s •Lo integran un conjunto de propuestas, ampliamente

conocidas en el ámbito académico •Se fundamentan en la incapacidad de expresar conectores

en UML •Alrededor de 20 ADLs han sido reconocidos •Son poco utilizados en la industria del software Ejemplos: AADL, Acme, Rapide, LILEANA, etc.

Frameworks y Vistas• Un framework permite ordenar las diferentes perspectivas de

una arquitectura en términos de vistas. Una vista es un subconjunto resultante de practicar una selección o abstracción sobre una realidad, desde un punto de vista determinado.

Frameworks y Vistas

Frameworks y Vistas La IEEE Std 1471-2000 procura establecer una base común para la

descripción de arquitecturas de software, e implementa para ello tres términos básicos:

•Arquitectura. Es la organización fundamental de un sistema, encarnada en sus componentes, las relaciones entre ellos y con su entorno, y los principios que gobiernan su diseño y evolución.

•Vista. Es la representación concreta de un sistema en particular desde una perspectiva unitaria.

•Punto de vista. Define un patrón o plantilla (template) para representar un conjunto de incumbencias (concerns) relativas a una arquitectura. Ejemplos: punto de vista estructural, punto de vista conductual, punto de vista de interconexión física.

El punto de vista estructural ha sido motivado por el trabajo de los ADLs

Vistas de UML

Vistas de UMLDinámicas

Vistas de UML

Procesos y metodologías •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 framework que 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).

Procesos y metodologías

Métodos Específicos de Procesos de Ingeniería que Sistematizan el Rol de

la Arquitectura en la Totalidad del Proceso (Desarrollados en el SEI):

• Architecture Based Design (ABD),• Software Architecture Analysis Method (SAAM)• Quality Attribute Workshops (QAW)• Quality Attribute-Oriented Software Architecture Design Method (QASAR)• Attribute-Driven Design (ADD)• Architecture Tradeoff Analysis Method (ATAM)• Active Review for Intermediate Design (ARID)• Cost-Benefits Analysis Method (CBAM)• Family-Architecture Analysis Method (FAAM)• Architecture Level Modifiability Analysis (ALMA)• Software Architecture Comparison Analysis Method (SACAM)• Aplicabilidad e impacto de los métodos en el proceso de desarrollo de software

Métodos Específicos de Procesos de Ingeniería que Sistematizan el Rol de

la Arquitectura en la Totalidad del Proceso (Desarrollados en el SEI):

AbstracciónUna abstracción denota las características esenciales de un objeto que lo distingue de otras clases de objeto y provee de este modo delimitaciones conceptuales bien definidas, relativas a la perspectiva del observador.Grady Booch, 1991La abstracción consiste en extraer las propiedades esenciales, o identificar los aspectos importantes, o examinar selectivamente ciertos aspectos de un problema, posponiendo o ignorando los detalles menos sustanciales, distractivos o irrelevantes.IEEE, Rumbaugh, Shaw, et.En un estilo, “menos es más”: Si una decisión se pospone hasta el momento de tratar las cosas a bajo nivel, entonces, ésta no es una decisión arquitectónicaBass, Clemennts, Kazman, 1998

Escenarios

Son técnicas que se implementan en la elicitación de los requerimientos, particularmente en relación a los operadores de sistemas. Los escenarios, también son utilizados como métodos para comparar alternativas de diseño ya que permiten realizar una descripción anticipada del sistema y típicamente se expresan en una frase.Kazban, Abow, Bass y Clements, 1996Métodos de diseño y desarrollo basados en arquitectura por escenarios: ALMA, SAAM y ATAM

Escenario de autenticación basada en notificaciones

Campos de la arquitectura de software

La AS es un conjunto inmenso y heterogéneo de áreas de investigación teórica y de formulación práctica. Garlan y Perry (IEEE Transactions on Software Engineering, 1995) delinean las áreas de investigación más promisoras de la AS:•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•Herramientas y ambientes de diseño arquitectónico

Campos de la arquitectura de software

Necesidades actuales:

•Modelos precisos que razonen sobre las propiedades actuales de una arquitectura verificando su consistencia y completitud.•Automatización de los procesos de análisis, diseño y síntesis.

Arquitecturas mas comunes

•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 (o capas) con un reparto claro de funciones:–una capa para la presentación (interfaz de usuario),–otra para el cálculo (donde se encuentra modelado el negocio) y–otra para el almacenamiento (persistencia).

Arquitecturas mas comunes desde otra perspectiva:

•Descomposición Modular

•Arquitecturas de Dominio Específico

•Diseño Software Arquitectura Multiprocesador

•Diseño Software Arquitectura Cliente Servidor

•Diseño Software Distribuido

•Diseño Software Tiempo Real

Modalidades y tendencias

•Corrientes de la AS propuestas por Carlos Billy Reynoso (2004):1.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..


2.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)


4.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.5.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.


6.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.

Otras menos populares son:

Genética), Arquitectura centrada en la acción (inteligencia artificial heideggeriana), Arquitectura epistemológicamente reflexiva, etc.Y del lado opuesto: la anti-arquitectura

Diferencias entre arquitectura y diseño

La arquitectura es el primer paso en la producción de un diseño de software (Shaw y Garlan,1996), en donde los pasos que la distinguen son:1.Arquitectura. Asocia los requerimientos con los componentes del sistema que habrán de implementarla. Estilos complejos a partir de estilos simples, es decir, sistemas a partir de subsistemas.2.Diseño de código. Comprende algoritmos y estructuras de datos; los componentes son primitivas de los lenguajes de programación (números, caracteres, punteros, etc.).3.Diseño ejecutable. Remite el diseño a un nivel de detalle más bajo (asignación de memoria, formato de datos, etc.).La arquitectura concierne a un nivel de abstracción mas elevado; se ocupa de componentes y no de procedimientos; de las interacciones de esos componentes y no de las interfaces; de las restricciones a ejercer sobre los componentes y de las interacciones y no de los algoritmos, los procedimientos y los tipos. (Dewayne Perry, 1997)


Taylor Medvidovic (2000). Señala que la literatura mantiene un estado ambiguo al existir diferentes interpretaciones.1)Arquitectura y diseño son lo mismo2)La AS se encuentra en un nivel de abstracción por encima del diseño3)La AS es otro paso en el proceso de software4)La AS es algo nuevo y en alguna medida diferente al diseño


Estephen Albin (2003). La arquitectura es una metáfora de diseño de software la cual abarca las metodologías de diseño, así como metodologías de análisis.“El arquitecto contemporáneo ejecuta una combinación de roles(analistas, diseñadores e ingenieros de software), pero ahora caen en una orquestación del Shief Architect”•La arquitectura integra las actividades de análisis y diseño en un framework de diseño más amplio y coherente.•La integración de las metodologías y modelos es lo que distingue a la AS de la simple yuxtaposición de técnicas de análisis y diseño

Fundamentos de la arquitectura del software

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 Repositorios de la Arquitectura de SoftwareExisten 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 Engineering Institute en la Universidad Carnegie Mellon de Pittsburgh, Pennsylvania (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.

Fundamentos de la arquitectura del software

Entre los organismos que definen estándares, son esenciales los servicios de información de RM-ODP en http://www.dstc.edu.au/Research/Projects/ODP/ref_model.html, TOGAF en http://www.software.org/pub/architecture/togaf.asp DoDAF (hogar del C4ISR) en http://www.software.org/pub/architecture/dodaf.asp El estándar IEEE 1471-2000 se puede encontrar en http://www.techstreet.com/cgibin/detail?product_id=879737 El marco de referencia empresarial de Zachman se puede acceder desde http://www.software.org/pub/architecture/zachman.asp. 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

Relevancia de la Arquitectura de Software

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. Escribe Barry Boehm, especialista máximo en gestión de riesgo y bien conocido creador del COCOMO y del método de desarrollo en espiral: Si un proyecto no ha logrado una arquitectura del sistema, incluyendo su justificación, el proyecto no debe empezar el desarrollo en gran escala. Si se especifica la arquitectura como un elemento a entregar, se la puede usar a lo largo de los procesos de desarrollo y mantenimiento [Boe95].


Antes que transcribir listas de ideas que a veces coinciden y otras señalan características heterogéneas, sintetizaremos las virtudes de la AS articulando las opiniones convergentes de los expertos [CN96] [Gar00]: 1. Comunicación mutua. La AS 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.


2. Decisiones tempranas de diseño. La AS 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.


3. Restricciones constructivas. Una descripción arquitectónica proporciona blueprintsparciales 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. 4. Reutilización, o abstracción transferible de un sistema. La AS 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 atravé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.


5. Evolución. La AS 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. 6. 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.


7. 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

Definiciones de estilosEstilo también se utiliza en la informática: las hojas de estilo en cascada (Cascading Style Sheets, CSS según sus siglas en inglés) componen un lenguaje que se emplea para estipular cómo se presentará un documento que ha sido desarrollado en XML, HTML o XHTML.

Es la forma en que el autor plasma lo que escribe usando rasgos propios y particulares.El estilo es la expresión de la personalidad del autor. Es el rostro del alma. Es el hombre. Es su Vida.Cada autor es un estilo nuevo. Exactamente inimitable., ineditable, absoluto diríase.Dos autores pueden parecerse al escribir pero jamás sus estilos serán copia exacta uno de otro. Ni que traten sobre el mismo tema. Ni que usen palabras iguales. Ni que pongan en sus obras el mismo fervor.Dos elementos fundamentales lo integran, el espíritu y la técnica literaria. Predominando el espíritu, que es como decir, el dolor, la alegría, la angustia, la esperanza, el odio, el amor, el cinismo, la fraternal sinceridad.

Los estilos arquitectónicos:Es la clasificación arquitectónica en los términos de forma, técnicas,materiales, período, región, etc.Surgen del estudio de la evolución y la historia de la arquitectura.El estilo arquitectónico es una manera de clasificar la arquitectura que da énfasis a las característicasdel diseño, dando lugar a una terminología Es un estilo bastante sencillo. No lleva molduras ( detalles en relieve ) ni detalles recargados, es de líneasrectas y simples.La decoración transmite una sensación de informalidad y juventud. Es simple y funcional, se caracterizapor crear espacios amplios y luminosos. Se puede optar por colores claros en paredes y muebles. Es unestilo muy práctico, los muebles son de líneas puras y detalles discretos.Un mobiliario apropiado sería:Sillas. De madera laqueada, sola o con base de acero. Podríamos usar, asimismo, sillas en plástico decolores, con tapicería también colorida y diseños modernos.Mesas. Las mesas pueden ser de plástico, enchape melamínico o madera de acabado laqueado;preferentemente redondas, pues son menos rígidas.Mobiliario de apoyo. Como en los estilos anteriores, sólo para colocar vajilla y mantelería. Pueden sersencillas, en madera o enchape melamínico, con puertas y divisiones para guardar utensilios.

ClasificacionesEstilos de flujo de datos Tubería-filtros Tubería-filtros uniforme Estilos de replicación Repositorio replicado Cache Estilos jerárquicos Cliente-servidor Sistemas en capas y Cliente-servidor en capas Cliente-Servidor sin estado Cliente-servidor con cacheen cliente Cliente-servidor con cacheen cliente y servidor sin estado Sesión remota Acceso a datos remoto

Estilos de código móvil Máquina virtual Evaluación remota Código a demanda Código a demanda en capas Agente móvil Estilos peer-to-peer Integración basada en eventos

Descripción

Los estilos sólo se manifiestan en arquitectura teórica descriptiva de alto nivel de abstracción; los patrones, por todas partes. Los partidarios de los estilos se definen desde el inicio como arquitectos; 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 softwareEl 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 patrones arquitectónicos

Por su parte, se han materializado con referencia a lenguajes y paradigmas también específicos de desarrollo, mientras que ningún estilo presupone o establece preceptivas al respecto. Si hay algún código en las inmediaciones de un estilo, será código del lenguaje de descripción arquitectónica o del lenguaje de modelado; de ninguna manera será código de lenguaje de programación Los patrones de arquitectura están claramente dentro de la disciplina arquitectónica, solapándose con los estilos

Patrones ArquitectónicoSegún Buschmann los patrones de arquitectura se pueden ver como la descripción de un problema en particular y recurrente de diseño, que aparece en contextos de diseño arquitectónicos específicos, y representa un esquema genérico demostrado con éxito para su solución. El esquema de solución se especifica mediante la descripción de los componentes que la constituyen, sus responsabilidades y desarrollos, así como también la forma en que estos colaboran entre sí. (Buschmann, et al., 1996).Los patrones arquitectónicos se definen sobre aspectos fundamentales de la estructura del sistema software, donde se especifican un conjunto de subsistemas con sus responsabilidades y una serie de recomendaciones para organizar los distintos componentes.

Patrón de DiseñoUn patrón de diseño provee un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. Describe la estructura comúnmente recurrente de los componentes en comunicación, que resuelve un problema general de diseño en un contexto particular (Buschmann, et al., 1996).Son menores en la escala de abstracción que los patrones arquitectónicos, además tienden a ser independientes de los lenguajes y paradigmas de programación. Su aplicación tiene efectos sobre subsistemas, debido a que especifica a un mayor nivel de detalle, sin llegar a la implementación, el comportamiento de los componentes del subsistema.

Patrón de Diseño

Patrón de Diseño

Documents

Fundamentos de la arquitectura de software