Arquitectura de software

Proceso de desarrollo de software
Actividades básicas
Requisitos Diseño Construcción Prueba Depuración de Implementación Mantenimiento
Paradigmas y modelos
Ingeniería de software Cascada Creación de prototipos Incremental Modelo V Modelo de la doble uve Espiral IID Ágil Lean DevOps
Metodologías y marcos
Sala blanca TSP PSP RAD DSDM MSF Scrum Kanban UP XP TDD ATDD BDD FDD DDD MDD
Disciplinas de apoyo
Gestión de la configuración Infraestructura como código Documentación Aseguramiento de la calidad del software (SQA) Gestión de proyectos Experiencia de usuario
Herramientas
Compilador de Depurador de Generador de perfiles Diseñador de GUI Modelado IDE Construir la automatización Automatización de liberación Prueba
Normas y BOKs
CMMI Estándares IEEE ISO 9001 Normas ISO/IEC SWEBOK PMBOK BABOK

Arquitectura de software se refiere a las estructuras fundamentales de un sistema de software, la disciplina de la creación de tales estructuras y la documentación de estas estructuras. Estas estructuras son necesarios para razonar sobre el sistema de software. Cada estructura compone de elementos de software, las relaciones entre ellos y las propiedades de elementos y relaciones, junto con razón de ser para la introducción y configuración de cada elemento. El arquitectura de un software de sistema es una metáfora, análoga a la arquitectura de un edificio.

Arquitectura de software es sobre tomar decisiones estructurales fundamentales que son costosos de cambiar una vez implementado. Opciones de arquitectura de software, también llamados decisiones arquitectónicas, incluyen opciones estructurales específicas de posibilidades en el diseño de software. Por ejemplo, los sistemas que controlaban la lanzadera de espacio vehículo de lanzamiento tenía el requisito de ser muy rápido y muy confiable. Por lo tanto, una adecuada Computación en tiempo real lengua tendría que ser elegido. Además, para satisfacer la necesidad de fiabilidad la elección podría realizarse para tener múltiples redundantes e independientemente producido copias del programa y ejecutar estas copias en independiente hardware y contrastar resultados.

Documentación de arquitectura de software facilita la comunicación entre partes interesadas, captura las decisiones sobre el diseño de la arquitectura y permite la reutilización de componentes de diseño entre los proyectos.

Ámbito de aplicación

Las opiniones varían en cuanto al alcance de arquitecturas de software:

• Estructura del sistema en general, macroscópico; Esto se refiere a la arquitectura como un nivel más alto abstracción de un sistema de software que consiste en una colección de computacional componentes junto con conectores describen la interacción entre estos componentes.
• Lo importante, sea lo que sea; Esto se refiere al hecho de que arquitectos de software deben se refieren a aquellas decisiones que tienen alto impacto en el sistema y sus actores.
• Lo que es fundamental para comprender un sistema en su entorno; en esta definición, el medio ambiente se caracteriza por preocupaciones de partes interesadas, las limitaciones técnicas y diferentes dimensiones del contexto del proyecto.
• Cosas que las personas perciben como difíciles de cambiar; puesto que el diseño de la arquitectura a menudo ocurre al principio del ciclo de vida de un sistema de software, el arquitecto debe centrarse en las decisiones que "tienen que" estar en lo cierto la primera vez. Siguiendo esta línea de pensamiento, cuestiones de diseño arquitectónico pueden ser no arquitectónica una vez que su irreversibilidad puede ser superada (véase "arquitectura de Software y desarrollo ágil" abajo).
• Un conjunto de decisiones de diseño arquitectónico; arquitectura de software no debe considerarse como meramente un conjunto de modelos o estructuras, pero debe incluir las decisiones que conducen a estas estructuras particulares y las razones detrás de ellos (por ejemplo, justificaciones, respuestas a preguntas de "por qué")). Esta idea ha llevado a investigación sustancial en la gestión del conocimiento en software de arquitectura.

No hay fuerte distinción entre software arquitectura versus diseño e Ingeniería de requerimientos (véase Campos relacionados a continuación). Son todos parte de una cadena de"intencionalidad" de intenciones de alto nivel a los detalles de bajo nivel. Esta dualidad también se conoce como "twin peaks" de ingeniería de software.

Características

Arquitectura de software expone lo siguiente:

Multitud de partes interesadas: sistemas de software tienen que atender a una variedad de partes interesadas como administradores de empresas, propietarios de aplicaciones, desarrolladores, usuarios finales y operadores de infraestructura. Estos actores todos tienen sus propias preocupaciones con respecto al sistema. Equilibrio de estas preocupaciones y demostrando cómo se abordan es parte del diseño de la instalación. Esto implica que la arquitectura implica lidiar con una amplia variedad de preocupaciones y de las partes interesadas y tiene un carácter multidisciplinar. Arquitecto de software requieren habilidades no técnicas como las competencias de comunicación y negociación.

Separación de preocupaciones: la forma establecida para los arquitectos reducir la complejidad es separar las preocupaciones que impulsan el diseño. Documentación de arquitectura muestra que todas las preocupaciones de las partes interesadas se han modelado y descripción de la arquitectura desde diferentes puntos de vista asociados a las diversas preocupaciones de los interesados. Estas descripciones separadas se denominan vistas arquitectónicas (véase por ejemplo la Modelo de vista arquitectura de 4 + 1).

Basada en la calidad: clásico diseño de software enfoques (p. ej. Programación estructurada de Jackson) fueron conducidos por la funcionalidad requerida y el flujo de datos a través del sistema, pero la penetración actual es que la arquitectura de un sistema de software está más estrechamente relacionada con su atributos de calidad tales como tolerancia a fallos, compatibilidad con versiones anteriores, extensibilidad de, fiabilidad, capacidad de mantenimiento, disponibilidad de, seguridad, usabilidad y otros tales,ilities. Preocupaciones de los actores a menudo se traducen en requisitos y limitaciones a estos atributos de calidad, que vario se llaman requisitos no funcionales, requisitos no funcionales, requisitos de comportamiento y requisitos del atributo de calidad.

Estilos recurrentes: como la arquitectura del edificio, la disciplina de arquitectura de software ha desarrollado formas estándar para abordar problemas recurrentes. Estas maneras de "estándar" son llamadas por varios nombres en diversos niveles de abstracción. Términos comunes para soluciones recurrentes son estilo arquitectónico, principio, táctica, arquitectura de referencia y patrón arquitectónico.

Integridad conceptual: un término introducido por Fred Brooks en El mítico hombre-mes para denotar la idea de que la arquitectura de un sistema de software representa una visión global de lo que debe hacer y cómo debe hacerlo. Esta visión debe ser separada de su aplicación. El arquitecto asume el papel de "guardián de la visión", asegurándose de que son adiciones al sistema en línea con la arquitectura, por lo tanto, preservar integridad conceptual.

Motivación

Arquitectura de software es una abstracción "intelectualmente graspable" de un sistema complejo. Esta abstracción proporciona una serie de beneficios:

• Da una base para el análisis del comportamiento de sistemas de software antes de que el sistema ha sido construido. La capacidad de verificar que un sistema de software futuro cumple las necesidades de sus grupos de interés sin tener que construirlo representa sustancial ahorro de costes y reducción del riesgo. Varias técnicas se han desarrollado en la academia y la práctica para llevar a cabo tales análisis, por ejemplo ATAM, ÁRIDO y TARA.
• Proporciona una base para la reutilización de elementos y decisiones. Una arquitectura de software completa o partes de él, como estrategias arquitectónicas individuales y las decisiones, pueden utilizarse en múltiples sistemas cuyas partes interesadas requieren similares atributos de calidad o funcionalidad, ahorro de costes de diseño y mitigar el riesgo de errores de diseño (suponiendo que los contextos de proyecto partido).
• Es compatible con principios decisiones de diseño que afectan la vida de desarrollo, implementación y mantenimiento de un sistema. Acertar con las decisiones tempranas de alto impacto es importante para evitar el horario y excesos de presupuesto. Por otra parte, un principio de desarrollo de software lean es aplazar las decisiones hasta el último momento responsable (M. y T. Poppendieck); sin embargo, no siempre está claro cuando este ha llegado el momento para un subconjunto particular de decisiones.
• Facilita la comunicación con las partes interesadas, contribuyendo a un sistema que satisface mejor sus necesidades. Comunicar sobre sistemas complejos desde el punto de vista de los actores les ayuda a comprender las consecuencias de los requisitos establecidos y las decisiones de diseño en base a ellos. Arquitectura le da la capacidad de comunicar sobre decisiones de diseño antes de implementa el sistema, cuando sean todavía relativamente fáciles de adaptar.
• Ayuda en la gestión de riesgos. Arquitectura de software ayuda a reducir los riesgos y posibilidades de fallar.
• Permite reducción de costos. Arquitectura de software es un medio para gestionar los riesgos y costos en complejos proyectos.

Historia

La comparación entre el software de diseño y arquitectura (civil) primero fue dibujada a finales de 1960, pero el término arquitectura de software se convirtió en frecuente sólo en la década de 1990. El campo de la Ciencias de la computación había encontrado problemas relacionados con la complejidad desde su formación. Anteriores problemas de complejidad fueron solucionados por los desarrolladores eligiendo el derecho de estructuras de datos, desarrollo de algoritmos dey aplicando el concepto de separación de preocupaciones. Aunque el término "arquitectura de software" es relativamente nuevo en la industria, los principios fundamentales del campo se han aplicado esporádicamente por Ingeniería de software pioneros desde mediados de la década de 1980. Primeros intentos de captar y explicar la arquitectura software de un sistema eran impreciso y desorganizado, a menudo caracterizado por un conjunto de caja y línea diagramas de.

Arquitectura de software como concepto tiene su origen en la investigación de Edsger Dijkstra en 1968 y David Parnas en la década de 1970. Estos científicos hizo hincapié en que la estructura de un sistema de software es importante y la estructura correcta es crítica. Durante la década de 1990 hubo un esfuerzo concertado para definir y codificar aspectos fundamentales de la disciplina, con la investigación de trabajo concentrándose en estilos arquitectónicos (patrones de), lenguajes de descripción de arquitectura, y documentación de arquitectura. Instituciones de investigación han desempeñado un papel destacado en la promoción de arquitectura de software como disciplina. Por ejemplo, Mary Shaw y David Garlan de Carnegie Mellon escribió un libro titulado Arquitectura de software: Perspectivas en una disciplina emergente en 1996, que promovió conceptos de arquitectura de software como componentes, conectores y estilos.

IEEE 1471-2000, Recomendó la práctica para la descripción de la arquitectura de sistemas intensivos en Software, fue el primer estándar formal en el área de arquitectura de software. Fue adoptado en 2007 por ISO como ISO/IEC 42010:2007. En noviembre de 2011, IEEE 1471 – 2000 fue reemplazado por ISO/IEC/IEEE 42010:2011, Sistemas e ingeniería de software, descripción de la arquitectura (publicado conjuntamente por IEEE e ISO). Mientras que en IEEE 1471, arquitectura de software sobre la arquitectura de "sistemas intensivos en software", definido como "cualquier sistema donde el software contribuye esencial influencias para el diseño, construcción, despliegue y evolución del sistema en su conjunto", la edición 2011 va un paso más allá mediante la inclusión de la ISO/IEC 15288 y ISO/IEC 12207 definiciones de un sistema, que abarcan el hardware y software, pero "los seres humanos, procesos, procedimientos, instalaciones, materiales y entidades naturales".

Actividades de arquitectura

Hay muchas actividades que realiza un arquitecto de software. Arquitecto de software típicamente trabaja con gerentes de proyecto, analiza requisitos arquitectónico significativos con los actores, diseña una arquitectura de software, evalúa un diseño, se comunica con los diseñadores y las partes interesadas, documenta el diseño arquitectónico y mucho más. Hay cuatro actividades básicas en el diseño de arquitectura de software. Estas actividades de arquitectura de la base se llevan a cabo iterativamente y en diferentes etapas del ciclo de vida de desarrollo inicial del software, así como sobre la evolución de un sistema.

Análisis arquitectónico es el proceso de comprensión del entorno en el que funcionará un sistema de propuestas o sistemas y determinar los requisitos para el sistema. La entrada o requisitos para la actividad de análisis pueden venir de cualquier número de partes interesadas e incluyen artículos tales como:

• lo que hará el sistema de operación (los requisitos funcionales)
• así el sistema realizará la ejecución de requisitos no funcionales tales como confiabilidad, operabilidad, eficiencia de funcionamiento, seguridad, compatibilidad definidos en ISO/IEC 25010: estándar 2011
• tiempo de desarrollo de requisitos no funcionales tales como mantenimiento y transferencia definidos en ISO 25010:2011 estándar
• requerimientos del negocio y contextos ambientales de un sistema que puede cambiar con el tiempo, como la preocupación legal, social, financiero, competitivo y la tecnología

Las salidas de la actividad de análisis son los requisitos que tienen un impacto mensurable en la arquitectura de un sistema de software, llamado requisitos arquitectónico significativos.

Síntesis arquitectónica o el diseño es el proceso de creación de una arquitectura. Dado el requisitos arquitectónico significativos determinado por el análisis, el estado actual del diseño y los resultados de las actividades de evaluación, el diseño es creado y mejorado. Ver para una discusión de varias técnicas para la mejora de un diseño actual.

Evaluación de arquitectura es el proceso de determinar qué tan bien el diseño actual o una parte de él cumple con los requisitos derivados durante el análisis. Una evaluación puede ocurrir siempre que un arquitecto está considerando una decisión de diseño, puede ocurrir después de que una parte del diseño se ha completado, puede ocurrir después de que se ha completado el diseño final o puede ocurrir después de que el sistema ha sido construido. Algunas de las técnicas de evaluación de arquitectura de software disponibles incluyen Método de análisis de compensación de arquitectura (ATAM) y TARA. Marcos para la comparación de las técnicas se discuten en y.

Evolución de la arquitectura es el proceso de mantenimiento y adaptación de una arquitectura de software existente para satisfacer necesidades y cambios ambientales. Como arquitectura de software proporciona una estructura fundamental de un sistema de software, su evolución y mantenimiento necesariamente impactaría su estructura fundamental. Como tal, se refiere a arquitectura evolución con adición de nueva funcionalidad así como mantener la funcionalidad existente y el comportamiento del sistema, por ejemplo, mediante la refactorización de arquitectura.

La arquitectura requiere actividades de apoyo crítico. Estas actividades tienen lugar durante todo el proceso de arquitectura de software de base. Incluyen conocimientos diseño gestión y comunicación, razonamiento y toma de decisiones y la documentación.

Apoyo a actividades de arquitectura

Actividades de soporte de arquitectura de software se llevan a cabo durante las actividades de arquitectura de software de base. Estas actividades de apoyo ayudar a un arquitecto de software para realizar análisis, síntesis, evaluación y evolución. Por ejemplo, un arquitecto tiene que reunir conocimientos, tomar decisiones y documentos durante la fase de análisis.

• Comunicación y gestión del conocimiento es la actividad de explorar y gestionar el conocimiento que es esencial para diseñar una arquitectura de software. Arquitecto de software no funciona en aislamiento. Reciben insumos, requisitos funcionales y no funcionales y diseño de contextos, de diversas partes interesadas; y dispone de salidas a los interesados. Conocimiento de arquitectura de software es a menudo tácita y se mantiene en las cabezas de los actores. Arquitectura de software Gestión del conocimiento (AKM) trata de encontrar, la comunicación y retención de conocimientos. Como problemas de diseño de arquitectura de software son complejos e interdependientes, una brecha de conocimiento en el razonamiento de diseño puede conducir a diseño de arquitectura de software incorrecta. Actividades de AKM y comunicación ejemplos de búsqueda de patrones de diseño, prototipado, pidiendo desarrolladores experimentados y arquitectos, evaluar los diseños de sistemas similares, compartir conocimientos con otros diseñadores y las partes interesadas.
• Diseño de razonamiento y toma de decisiones es la actividad de evaluar decisiones de diseño. Esta actividad es fundamental para las actividades de arquitectura de software principales. Implica reunir y asociar contextos de decisión, formulación de problemas de decisión de diseño, buscar opciones de solución y evaluar compensaciones antes de tomar decisiones. Este proceso se produce en diferentes niveles de granularidad de la decisión, mientras que la evaluación de requisitos arquitectónicos significativos y las decisiones de arquitectura de software y software de análisis de arquitectura, síntesis y evaluación. Ejemplos de razonamiento las actividades incluyen entender los impactos de un requisito o un diseño en atributos de calidad, cuestionar los problemas que podría causar un diseño, las opciones de solución y evaluar los intercambios entre las soluciones.
• Documentación es la actividad de diseño generado durante el proceso de arquitectura de software de grabación. Un diseño del sistema se describe mediante varias vistas que incluyen con frecuencia una visión estática que muestra la estructura del código del sistema, una vista dinámica que muestran las acciones del sistema durante la ejecución y una vista de despliegue que muestra cómo un sistema se coloca en el hardware para la ejecución. Vista de 4 + 1 de Krutchen sugiere una descripción de vistas utilizadas para documentar la arquitectura de software; Documentación de arquitecturas de Software: Vistas y más allá tiene descripciones de los tipos de anotaciones que podrían utilizarse en la descripción. Ejemplos de actividades de documentación están escribiendo una especificación, un modelo de diseño de sistema, documentando una lógica de diseño, desarrollo de un punto de vista, puntos de vista de la documentación de la grabación. Métodos de ingeniería de software tales como el OpenUP y métodos de diseño de arquitectura como el proceso de Software de arquitectura (P. Eeles, P. Cripps) sugieren tipos de artefacto (también conocido como producto del trabajo) y plantillas para estas actividades de documentación; ISO/IEC/IEEE 42010:2011 va acompañado de una plantilla de documentación como (bienhttps://www.ISO-Architecture.org/IEEE-1471/templates/).

Temas de arquitectura de software

Descripción de la arquitectura de software

Artículo principal: Descripción de la arquitectura de software

Descripción de la arquitectura de software consiste en los principios y prácticas de modelación y representación de arquitecturas, usando mecanismos tales como: lenguajes de descripción de arquitectura, puntos de vista de arquitectura y los marcos de arquitectura.

Lenguajes de descripción de arquitectura

Artículo principal: Lenguaje de descripción de arquitectura

Un lenguaje de descripción de arquitectura (ADL) es cualquier medio de expresión que se utiliza para describir un (arquitectura de softwareISO/IEC/IEEE 42010). Muchas ADLs especiales se han desarrollado desde la década de 1990, incluyendo ArchiMate, AADL (Norma SAE), Wright (desarrollado por Carnegie Mellon), Acme (desarrollado por Carnegie Mellon), xADL (desarrollado por UCI), Darwin (desarrollado por Imperial College London), DAOP-ADL (desarrollado por la Universidad de Málaga), SBC-ADL (desarrollado por Universidad Nacional de Yat-sensor del sol), y ByADL (Universidad de l ' Aquila, Italia).

AVCS no han logrado todavía en una escala amplia en la práctica; UML, a menudo de perfil y fotos de ricos Informal (DPI) también conocido como diagramas de caja y línea dominan. Uso de UML ha sido criticado por algunos líderes de pensamiento, pero éxitos también se han divulgado. Contexto, envases, componentes Simon Brown, modelo de clases (C4) es un adiditon reciente a caja de herramientas de notación del arquitecto: https://www.voxxed.com/blog/2014/10/simple-sketches-for-diagramming-Your-software-Architecture/.

Según Gregor Hohpe, arquitectos deben dejar de dibujo de diagramas, en cualquier notación y comenzar a comunicarse: https://www.enterpriseintegrationpatterns.com/ramblings/94_37things.html.

Puntos de vista de arquitectura

Artículo principal: Modelo vista

Modelo de vista arquitectura de 4 + 1.

Descripciones de la arquitectura de software comúnmente se organizan en Vistas, que son análogos a los diferentes tipos de planos hecho en edificio arquitectura. Cada vista aborda un conjunto de problemas del sistema, siguiendo las convenciones de su punto de vista, donde un punto de vista es una especificación que describe las notaciones, modelado y técnicas de análisis a utilizar en una vista que expresan la arquitectura en cuestión desde la perspectiva de un determinado conjunto de las partes interesadas y sus preocupaciones (ISO/IEC/IEEE 42010). El punto de vista especifica no sólo las preocupaciones enmarcadas (es decir, ser abordadas) pero la presentación, tipo de modelo utilizado, convenciones utilizadas y las reglas de coherencia (correspondencia) para mantener una visión consistente con otras vistas.

Punto de vista popular modelos incluyen las opiniones de 4 + 1 sobre arquitectura de software, puntos de vista y catálogo perspectices por Nick Rozanski y Eoin Woods y el modelo de punto de vista de IBM ANUNCIOS por Philippe Spaas et al.

Marcos de arquitectura

Artículo principal: Marco de arquitectura

Un marco de arquitectura captura el («convenios, principios y prácticas para la descripción de las arquitecturas establecidas dentro de un dominio específico de aplicación y/o comunidad de actores»ISO/IEC/IEEE 42010). Un marco generalmente se implementa en términos de uno o más puntos de vista o AVD.

Métodos de diseño de arquitectura

Métodos de definen modelos de proceso (actividades realizadas por papeles) y especifican artefactos para ser creado y entregado; también pueden sugerir técnicas y prácticas que ayudan a los médicos cuando realizan las actividades y producir los artefactos definición en el método. Cinco tales métodos se comparan y se consolidó en.

Arquitectura de software y desarrollo ágil

Artículo principal: Desarrollo ágil

La importancia de la arquitectura fue indicada en las primeras obras en ágil; por ejemplo, original Scrum el papel de Ken Schwaber de OOPSLA 97 tiene la noción de un pregame, en el que una arquitectura de alto nivel del sistema es (establecidohttps://www.jeffsutherland.org/oopsla/schwapub.pdf). Sin embargo, hay también preocupaciones que arquitectura de software conduce a demasiada Gran diseño frontal, especialmente entre los defensores de Desarrollo ágil de software. Se han desarrollado varios métodos para equilibrar las ventajas y desventajas del diseño inicial y la agilidad, incluyendo el método ágil DSDM que exige una fase de "Fundaciones" que se están "lo suficiente" cimientos arquitectónicos. IEEE Software dedicó un número especial a la interacción entre arquitectura y agilidad. P. Krutchen, uno de los creadores del proceso unificado (UP) y las vistas de 4 + 1 original en arquitectura de software, resume la relación sinérgica en un blog de diciembre de 2013 post llamado "Arquitectura ágil".

Patrones y estilos arquitectónicos

Artículo principal: Patrones y estilos de arquitectura de software

Un patrón arquitectónico es una solución general, reutilizable para un problema que comúnmente ocurren en arquitectura de software dentro de un contexto determinado. Patrones arquitectónicos a menudo están documentados como software patrones de diseño.

(Siguiendo la arquitectura tradicional del edificio, un 'estilo arquitectónico del software' es un método específico de la construcción, caracterizado por las características que lo hacen notable"Estilo arquitectónico). "Un estilo arquitectónico define: una familia de sistemas en términos de un patrón de organización estructural; un vocabulario de componentes y conectores, con restricciones sobre cómo pueden combinarse." "estilos arquitectónicos son reutilizables 'paquetes' de las decisiones de diseño y las restricciones que se aplican a una arquitectura para inducir cualidades deseables solicitadas".

Hay muchos patrones arquitectónicos reconocidos y estilos, entre ellos:

• Pizarra
• Cliente-servidor (2-tier, 3-tier, n-tier, Computación en la nube exhiben este estilo)
• Basado en componentes
• Centradas en los datos
• Dirigida por eventos (o Invocación implícita)
• En capas de (o Arquitectura de varias capas)
• Aplicación monolítica
• Peer-to-peer (P2P)
• Tubos y filtros
• Plug-ins
• Transferencia de estado representacional (RESTO)
• Basada en reglas
• Arquitectura Servicio-orientada y microservicios como su enfoque de implementación
• Compartido nada arquitectura
• Arquitectura en el espacio

Algunos arquitectos de software tratan patrones arquitectónicos y estilos arquitectónicos como el mismo, Otros tratan estilos como composiciones de patrones combinados con principios arquitectónicos que conjuntamente dirección particular intención de. Estas dos posiciones tienen en común que los patrones y estilos son modismos de arquitectos a utilizar; "proporcionan un lenguaje común" o "vocabulario" con el cual describir las clases de sistemas.

Erosión de arquitectura de software

Erosión de arquitectura de software (o "decaimiento") se refiere a la diferencia observada entre la arquitectura prevista y real de un sistema de software como en su implementación. Software arquitectura erosión ocurre cuando las decisiones de implementación no lograr la arquitectura como previsto o violar restricciones o principios de que la arquitectura. La diferencia entre arquitecturas previstas y reales a veces se entiende en términos de la noción de deuda técnica.

Como ejemplo, considere una estrictamente en capas de sistema, donde cada capa sólo puede utilizar los servicios proporcionados por la capa inmediatamente debajo de él. Cualquier componente de código de fuente que no observa esta restricción representa una violación de la arquitectura. Si no se corrige, tales violaciones pueden transformar la arquitectura en un bloque monolítico, con efectos adversos sobre la comprensibilidad, la mantenibilidad y la evolutividad.

Se han propuesto diversos enfoques a la erosión de la dirección. "estos enfoques, que incluyen herramientas, técnicas y procesos, principalmente se clasifican en tres categorías genéricas que intentan minimizar, prevenir y reparar la erosión de la arquitectura. Dentro de estas categorías, cada enfoque se descompone más que refleja el alto nivel estrategias adoptadas para hacer frente a la erosión. Estas son: conformidad de arquitectura orientada a procesos, gestión de evolución de arquitectura, ejecución de diseño de arquitectura, arquitectura para técnicas de aplicación acoplamiento, autoadaptación y arquitectura restauración de recuperación, el descubrimiento y la reconciliación. "

Existen dos técnicas principales para detectar violaciones de arquitectura: modelos de reflexión y lenguajes específicos de dominio. Técnicas de modelo (RM) de reflexión comparan un modelo de alto nivel proporcionado por los arquitectos del sistema con la implementación de código fuente. Ejemplos de herramientas basadas en la RM el Bauhaus Suite (desarrollado por Axivion), GUARDAR (desarrollado por Fraunhofer IESE) y Estructura-101 (desarrollado por Software avanzado). También hay lenguajes específicos de dominio con énfasis en la especificación y comprobación de las limitaciones arquitectónicas, incluyendo. QL (desarrollado por Semmle Limited) y DCL (de la Universidad Federal de Minas Gerais).

Recuperación de arquitectura de software

Artículo principal: Recuperación de arquitectura de software

Recuperación de arquitectura de software (o reconstrucción, o ingeniería inversa) incluye los métodos, técnicas y procesos para descubrir la arquitectura de un sistema de software de información disponible, incluyendo su implementación y documentación. Recuperación de la arquitectura a menudo es necesario tomar decisiones frente a la documentación obsoleta o desactualizada y erosión de la arquitectura: decisiones de implementación y mantenimiento de divergencia de la arquitectura concepción.

Campos relacionados

Diseño

Artículo principal: Diseño de software

La arquitectura es diseño pero no todo el diseño arquitectónico. En la práctica, el arquitecto es quien traza la línea entre arquitectura de software (diseño arquitectónico) y el detallado diseño (arquitectura). No hay reglas ni directrices que todos los casos, aunque ha habido intentos de formalizar la distinción. Según el Hipótesis de Intension/del lugar, la distinción entre diseño arquitectónico y el detallado se define por la Criterio de la localidad, de acuerdo que es una declaración acerca de diseño de software puede ser ampliado no local (arquitectura) si y solamente si un programa que satisface en un programa que no. Por ejemplo, la cliente – servidor estilo es arquitectónico (estratégico) porque un programa que se basa en este principio se puede ampliar en un programa que no es cliente-servidor, por ejemplo, mediante la adición de Peer-to-peer nodos.

Ingeniería de requerimientos

Artículo principal: Ingeniería de requerimientos

Ingeniería de requerimientos y arquitectura de software puede ser visto como enfoques complementarios: mientras que los objetivos de la arquitectura de software del 'espacio de solución' o el 'cómo', direcciones de ingeniería de requisitos la 'espacio del problema' o el 'qué'. Requisitos de ingeniería implica el elicitación, negociación, Especificación, validación, documentación y gestión de requisitos. Ingeniería de requisitos y arquitectura de software giran alrededor de partes interesadas preocupaciones, necesidades y deseos.

Hay un considerable solapamiento entre requisitos arquitectura ingeniería y software, como lo demuestra por ejemplo un estudio de cinco métodos de arquitectura de software industrial que concluye que "las entradas (objetivos, restricciones, etc.) son generalmente mal definido y sólo consigue descubierto o mejor entendido como la arquitectura comienza a emerger" y que si bien "mayoría de los problemas arquitectónicos se expresan como requerimientos del sistema, también pueden incluir decisiones de diseño por mandato". En Resumen, la elección del comportamiento requerido dado un problema en particular afecta a la arquitectura de la solución que aborda este problema, mientras que al mismo tiempo el diseño arquitectónico puede afectar el problema e introducir nuevos requisitos. Enfoques como el modelo Twin Peaks objetivo es explotar la sinérgica relación entre requerimientos y arquitectura.

Otros tipos de 'arquitectura'

Artículos principales: Arquitectura de computadores, Arquitectura de sistemas, y Arquitectura de la empresa

Arquitectura de computadores

Arquitectura de computadores objetivos de la estructura interna de un sistema informático, en cuanto a la colaboración de componentes de hardware tales como la CPU o procesador, el autobuses y de la memoria.

Arquitectura de sistemas

El término arquitectura de sistemas originalmente se ha aplicado a la arquitectura de sistemas que se compone de ambos hardware y software. La principal preocupación dirigida por la arquitectura de sistemas, también conocido como ES arquitectura, es entonces la integración de software y hardware en un dispositivo completo, correctamente de trabajo. En otro significado, mucho más amplio – común, el término se aplica a la arquitectura de cualquier sistema complejo que puede ser de técnico, socio-técnico o de naturaleza social.

Arquitectura de la empresa

El objetivo de arquitectura de la empresa es "visión de negocio y estrategia de la empresa efectiva". Arquitectura de la empresa Marcos, tales como TOGAF y de la Marco de Zachman, generalmente distinguir entre capas de la arquitectura de empresa diferentes. Aunque la terminología difiere de marco a marco, muchas incluyen al menos una distinción entre un negocios capa, un aplicación (o información) capay un tecnología capa. Arquitectura empresarial aborda entre otros la alineación entre estas capas, generalmente en un enfoque de arriba hacia abajo. Continuando el edificio de la metáfora de la arquitectura de la arquitectura de software, arquitectura de la empresa es análoga a la planificación del nivel de la ciudad.

Véase también

• Patrón arquitectónico (informática)
• Requisitos arquitectónico significativos
• Diseño basado en atributo
• Arquitectura de computadores
• OpenUP
• Arquitectura de la solución
• Arquitectura de sistemas
• Diseño de sistemas
• Método de análisis de arquitectura de software

Lectura adicional

• Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed poco, Paulo Merson, Robert Nord, Judith Stafford: Arquitecturas de Software documentación: Vistas y más allá, segunda edición. Addison-Wesley, 2010, ISBN 0-321-55268-7. Este libro describe lo que es arquitectura de software y muestra cómo documentar en varias vistas, utilizando UML y otras notaciones. También explica cómo complementar las vistas de la arquitectura con comportamiento, interfaz de software y documentación de la justificación. Que acompaña el libro es un wiki que contiene un ejemplo de documentación de arquitectura de software.
• Len Bass, Paul Clements, Rick Kazman: Arquitectura de software en la práctica, tercera edición. Addison Wesley, 2012, ISBN 0-321-81573-4 (Este libro, ahora en la tercera edición, elocuentemente cubre los conceptos fundamentales de la disciplina. El tema se centra en el logro de los atributos de calidad de un sistema).
• Philippe Krutchen: Planos arquitectónicos – el modelo 4 + 1 vistas de arquitectura de Software. En: IEEE Software. 12 (6) de noviembre de 1995, págs. 42-50 (también disponible en línea en el Sitio web de Rational(PDF))
• Martin Fowler (con Ralph Johnson) ¿Quién necesita un arquitecto? IEEE Software, julio/agosto 2003
• George Fairbanks: Lo suficiente como arquitectura de Software, propone un enfoque basado en riesgo al método de diseño corte y confección y modelado.
• Nick Rozanski y Eoin Woods, Arquitectura de sistemas de software (2ª edición) presenta los conceptos centrales de la arquitectura, así como un marco de arquitectura basado en el punto de vista y la perspectiva
• Peter Cripps y Peter Eeles: El proceso de diseñar la arquitectura de Software, una completa colección de arquitectura de las tareas, productos de trabajo de varios métodos de diseño de la arquitectura industrial.

Acoplamientos externos

• Qué es una arquitectura de software, P. Eeles, IBM developerWorks
• ¿Qué es arquitectura de Software?, MSDN
• Colección de definiciones de arquitectura de software en Instituto de ingeniería de software (SEI), Universidad Carnegie-Mellon (CMU)
• Qué es un nombre: arquitectura, G. Starke y Glosario de arquitectura de software por iSAQB
• Asociación Internacional de arquitectos IT (IASA Global), conocida como la Asociación Internacional para arquitectos de Software (IASA)
• SoftwareArchitecturePortal.org — sitio web de Grupo de funcionamiento de IFIP 2.10 en arquitectura de Software
• SoftwareArchitectures.com — recursos de información sobre la disciplina
• Cuando va mal la buena arquitectura
• La arquitectura espiral impulsada por desarrollo – la SDLC basado en Modelo de dinámica espiral es para reducir los riesgos de la arquitectura ineficaz

Otras Páginas

• ReDigi
• CtrlS (categoria Cloud computing los proveedores)
• Analisis de DNS
• Asociacion de quiropracticos de Nueva Jersey
• Tecnologias de informacion y comunicacion para el desarrollo (seccion de clima, tiempo y respuesta de emergencia)
• E. Aboobacker