Wikibrief

Arquitectura de software

Editar artículo
Desarrollo de software
Actividades centrales de la ingeniería de software
Paradigmas y modelos
Metodologías y marcos
Disciplinas de apoyo
Practicas
Instrumentos
Estándares y cuerpos de conocimiento
Glosarios
Contornos
  • v
  • t
  • mi

La arquitectura de software se refiere a las estructuras fundamentales de un sistema de software y la disciplina de crear tales estructuras y sistemas. Cada estructura comprende elementos de software, relaciones entre ellos y propiedades tanto de elementos como de relaciones. La arquitectura de un sistema de software es una metáfora, análoga a la arquitectura de un edificio. Funciona como un plano para el sistema y el proyecto en desarrollo, estableciendo las tareas necesarias para ser ejecutadas por los equipos de diseño.

La arquitectura de software se trata de tomar decisiones estructurales fundamentales que son costosas de cambiar una vez implementadas. Las opciones de arquitectura de software incluyen opciones estructurales específicas de las posibilidades en el diseño del software. Por ejemplo, los sistemas que controlaban el vehículo de lanzamiento del transbordador espacial tenían el requisito de ser muy rápidos y muy fiables. Por lo tanto, sería necesario elegir un lenguaje de computación en tiempo real apropiado. Además, para satisfacer la necesidad de confiabilidad, se podría optar por tener múltiples copias redundantes y producidas independientemente del programa, y ​​ejecutar estas copias en hardware independiente mientras se verifican los resultados.

La documentación de la arquitectura del software facilita la comunicación entre las partes interesadas, captura las decisiones iniciales sobre el diseño de alto nivel y permite la reutilización de los componentes del diseño entre proyectos.

Software_Architecture_Activities
Contenido
  • 1 Alcance
  • 2 caracteristicas
  • 3 Motivación
  • 4 Historia
  • 5 actividades de arquitectura
    • 5.1 Actividades de apoyo a la arquitectura
  • 6 Temas de arquitectura de software
    • 6.1 Descripción de la arquitectura del software
    • 6.2 Idiomas de descripción de la arquitectura
    • 6.3 Miradores de arquitectura
    • 6.4 Marcos de arquitectura
    • 6.5 Estilos y patrones arquitectónicos
    • 6.6 Arquitectura de software y desarrollo ágil
    • 6.7 Erosión de la arquitectura de software
    • 6.8 Recuperación de la arquitectura de software
  • 7 Campos relacionados
    • 7.1 Diseño
    • 7.2 Ingeniería de requisitos
    • 7.3 Otros tipos de 'arquitectura'
  • 8 Véase también
  • 9 referencias
  • 10 Lecturas adicionales
  • 11 Enlaces externos

Alcance

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

  • Estructura del sistema macroscópico: se refiere a la arquitectura como una abstracción de nivel superior de un sistema de software que consiste en una colección de componentes computacionales junto con conectores que describen la interacción entre estos componentes.
  • Lo importante, sea lo que sea: esto se refiere al hecho de que los arquitectos de software deben preocuparse por las decisiones que tienen un gran impacto en el sistema y sus partes interesadas.
  • Lo que es fundamental para comprender un sistema en su entorno.
  • Cosas que la gente percibe como difíciles de cambiar: dado que el diseño de la arquitectura tiene lugar al comienzo del ciclo de vida de un sistema de software, el arquitecto debe centrarse en las decisiones que "tienen que" ser correctas la primera vez. Siguiendo esta línea de pensamiento, los problemas de diseño arquitectónico pueden volverse no arquitectónicos una vez que se pueda superar su irreversibilidad.
  • Un conjunto de decisiones de diseño arquitectónico: la arquitectura de software no debe considerarse simplemente un conjunto de modelos o estructuras, sino que debe incluir las decisiones que conducen a estas estructuras particulares y la razón fundamental detrás de ellas. Esta idea ha llevado a una investigación sustancial sobre la gestión del conocimiento de la arquitectura de software.

No existe una distinción clara entre la arquitectura de software y el diseño y la ingeniería de requisitos (consulte los campos relacionados a continuación). Todos son parte de una "cadena de intencionalidad" desde las intenciones de alto nivel hasta los detalles de bajo nivel.

Caracteristicas

La arquitectura de software exhibe lo siguiente:

Multitud de partes interesadas: los sistemas de software deben atender a una variedad de partes interesadas, como gerentes comerciales, propietarios, usuarios y operadores. Todos estos interesados ​​tienen sus propias preocupaciones con respecto al sistema. Equilibrar estas preocupaciones y demostrar que se abordan es parte del diseño del sistema. Esto implica que la arquitectura implica tratar con una amplia variedad de inquietudes y partes interesadas, y tiene un carácter multidisciplinario.

Separación de preocupaciones : la forma establecida para que los arquitectos reduzcan la complejidad es separar las preocupaciones que impulsan el diseño. La documentación de la arquitectura muestra que todas las preocupaciones de las partes interesadas se abordan modelando y describiendo la arquitectura desde puntos de vista separados asociados con las diversas preocupaciones de las partes interesadas. Estas descripciones separadas se denominan vistas arquitectónicas (consulte, por ejemplo, el modelo de vista arquitectónica 4 + 1 ).

Impulsado por la calidad: los enfoques clásicos de diseño de software (por ejemplo, la programación estructurada de Jackson ) fueron impulsados ​​por la funcionalidad requerida y el flujo de datos a través del sistema, pero la idea actual es que la arquitectura de un sistema de software está más estrechamente relacionada con sus atributos de calidad, como La tolerancia a fallos, compatibilidad con versiones anteriores, la extensibilidad, confiabilidad, mantenibilidad, disponibilidad, seguridad, facilidad de uso, y otros - ilities. Las preocupaciones de las partes interesadas a menudo se traducen en requisitos sobre estos atributos de calidad, que se denominan de diversas formas requisitos no funcionales, requisitos extrafuncionales, requisitos de comportamiento o requisitos de atributos de calidad.

Estilos recurrentes: al igual que la arquitectura de edificios, la disciplina de arquitectura de software ha desarrollado formas estándar para abordar preocupaciones recurrentes. Estas "formas estándar" reciben varios nombres en varios niveles de abstracción. Los términos comunes para las soluciones recurrentes son estilo arquitectónico, táctica, arquitectura de referencia y patrón arquitectónico.

Integridad conceptual: término introducido por Fred Brooks en The Mythical Man-Month para denotar la idea de que la arquitectura de un sistema de software representa una visión general de lo que debe hacer y cómo debe hacerlo. Esta visión debe separarse de su implementación. El arquitecto asume el papel de "guardián de la visión", asegurándose de que las adiciones al sistema estén en línea con la arquitectura, preservando así la integridad conceptual.

Restricciones cognitivas: una observación realizada por primera vez en un artículo de 1967 por el programador informático Melvin Conway de que las organizaciones que diseñan sistemas están obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones. Al igual que con la integridad conceptual, fue Fred Brooks quien lo presentó a una audiencia más amplia cuando citó el artículo y la idea en su elegante clásico The Mythical Man-Month, llamándolo "Ley de Conway".

Motivación

La arquitectura de software es una abstracción "intelectualmente comprensible" de un sistema complejo. Esta abstracción proporciona una serie de beneficios:

  • Proporciona una base para el análisis del comportamiento de los sistemas de software antes de que se construya el sistema. La capacidad de verificar que un futuro sistema de software satisfaga las necesidades de sus partes interesadas sin tener que construirlo representa un ahorro sustancial de costos y una mitigación de riesgos. Se han desarrollado varias técnicas para realizar dichos análisis, como ATAM o mediante la creación de una representación visual del sistema de software.
  • Proporciona una base para la reutilización de elementos y decisiones. Una arquitectura de software completa o partes de ella, como estrategias y decisiones arquitectónicas individuales, se pueden reutilizar en múltiples sistemas cuyas partes interesadas requieren atributos de calidad o funcionalidad similares, lo que ahorra costos de diseño y mitiga el riesgo de errores de diseño.
  • Es compatible con las decisiones de diseño iniciales que afectan el desarrollo, la implementación y la vida útil de mantenimiento de un sistema. Tomar las decisiones tempranas de alto impacto correctamente es importante para evitar sobrecostos en el cronograma y el presupuesto.
  • Facilita la comunicación con las partes interesadas, contribuyendo a un sistema que satisfaga mejor sus necesidades. Comunicarse sobre sistemas complejos desde el punto de vista de las partes interesadas les ayuda a comprender las consecuencias de los requisitos establecidos y las decisiones de diseño basadas en ellos. La arquitectura brinda la capacidad de comunicarse sobre las decisiones de diseño antes de que se implemente el sistema, cuando aún son relativamente fáciles de adaptar.
  • Ayuda en la gestión de riesgos. La arquitectura del software ayuda a reducir los riesgos y la posibilidad de fallas.
  • Permite la reducción de costes. La arquitectura de software es un medio para administrar riesgos y costos en proyectos de TI complejos.

Historia

La comparación entre el diseño de software y la arquitectura (civil) se estableció por primera vez a finales de la década de 1960, pero el término "arquitectura de software" no tuvo un uso generalizado hasta la década de 1990. El campo de la informática ha encontrado problemas asociados con la complejidad desde su formación. Los desarrolladores resolvieron problemas anteriores de complejidad eligiendo las estructuras de datos correctas, desarrollando algoritmos y aplicando el concepto de separación de preocupaciones. Aunque el término "arquitectura de software" es relativamente nuevo en la industria, los pioneros de la ingeniería de software han aplicado esporádicamente los principios fundamentales del campo desde mediados de la década de 1980. Los primeros intentos de capturar y explicar la arquitectura de software de un sistema fueron imprecisos y desorganizados, a menudo caracterizados por un conjunto de diagramas de caja y línea.

La arquitectura de software como concepto tiene sus orígenes en la investigación de Edsger Dijkstra en 1968 y David Parnas a principios de la década de 1970. Estos científicos enfatizaron que la estructura de un sistema de software es importante y que conseguir la estructura correcta es fundamental. Durante la década de 1990 hubo un esfuerzo concertado para definir y codificar los aspectos fundamentales de la disciplina, con el trabajo de investigación se concentra en estilos arquitectónicos ( patrones ), descripción de la arquitectura idiomas, documentación de la arquitectura y los métodos formales.

Las instituciones de investigación han desempeñado un papel destacado en la promoción de la arquitectura de software como disciplina. Mary Shaw y David Garlan de Carnegie Mellon escribieron un libro titulado Arquitectura de software: perspectivas sobre una disciplina emergente en 1996, que promovía conceptos de arquitectura de software como componentes, conectores y estilos. Los esfuerzos del Instituto de Investigación de Software de la Universidad de California en Irvine en la investigación de la arquitectura de software se dirigen principalmente a los estilos arquitectónicos, los lenguajes de descripción de la arquitectura y las arquitecturas dinámicas.

IEEE 1471-2000, "Práctica recomendada 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, "Ingeniería de sistemas y software - Descripción de la arquitectura" (publicado conjuntamente por IEEE e ISO).

Mientras que en IEEE 1471, la arquitectura de software se refería a la arquitectura de "sistemas intensivos en software", definida como "cualquier sistema en el que el software contribuya con influencias esenciales al diseño, construcción, implementación y evolución del sistema en su conjunto", la edición de 2011 va un paso más allá al incluir las definiciones ISO / IEC 15288 e ISO / IEC 12207 de un sistema, que abarcan no solo hardware y software, sino también "humanos, procesos, procedimientos, instalaciones, materiales y entidades naturales". Esto refleja la relación entre la arquitectura de software, la arquitectura empresarial y la arquitectura de la solución.

Actividades de arquitectura

Son muchas las actividades que realiza un arquitecto de software. Un arquitecto de software normalmente trabaja con los gerentes de proyectos, analiza los requisitos arquitectónicamente significativos con las partes interesadas, 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 más. Hay cuatro actividades principales en el diseño de arquitectura de software. Estas actividades de arquitectura central se realizan de forma iterativa y en diferentes etapas del ciclo de vida inicial del desarrollo de software, así como durante la evolución de un sistema.

El análisis arquitectónico es el proceso de comprender el entorno en el que operará un sistema propuesto y determinar los requisitos del sistema. La entrada o los requisitos para la actividad de análisis pueden provenir de cualquier número de partes interesadas e incluir elementos tales como:

  • lo que hará el sistema cuando esté operativo (los requisitos funcionales)
  • qué tan bien el sistema cumplirá los requisitos no funcionales en tiempo de ejecución tales como confiabilidad, operabilidad, eficiencia de desempeño, seguridad, compatibilidad definidos en la norma ISO / IEC 25010 : 2011
  • tiempo de desarrollo de requisitos no funcionales tales como mantenibilidad y transferibilidad definidos en la norma ISO 25010: 2011
  • Requisitos comerciales y contextos ambientales de un sistema que pueden cambiar con el tiempo, como preocupaciones legales, sociales, financieras, competitivas y tecnológicas.

Los resultados de la actividad de análisis son aquellos requisitos que tienen un impacto medible en la arquitectura de un sistema de software, denominados requisitos arquitectónicamente significativos.

La síntesis o diseño arquitectónico es el proceso de creación de una arquitectura. Dados los requisitos arquitectónicamente significativos determinados por el análisis, el estado actual del diseño y los resultados de cualquier actividad de evaluación, el diseño se crea y mejora.

La evaluación de la arquitectura es el proceso de determinar qué tan bien el diseño actual o una parte del mismo satisface 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 se haya completado una parte del diseño, puede ocurrir después de que se haya completado el diseño final o puede ocurrir después de que se haya construido el sistema. Algunas de las técnicas de evaluación de la arquitectura de software disponibles incluyen el Método de análisis de compensación de arquitectura (ATAM) y TARA. Los marcos para comparar las técnicas se discuten en marcos como el Informe SARA y Revisiones de arquitectura: práctica y experiencia.

La evolución de la arquitectura es el proceso de mantener y adaptar una arquitectura de software existente para cumplir con los cambios en los requisitos y el entorno. Como la arquitectura de software proporciona una estructura fundamental de un sistema de software, su evolución y mantenimiento necesariamente afectaría su estructura fundamental. Como tal, la evolución de la arquitectura se preocupa por agregar nuevas funciones, así como por mantener la funcionalidad existente y el comportamiento del sistema.

La arquitectura requiere actividades de apoyo críticas. Estas actividades de apoyo tienen lugar a lo largo del proceso de arquitectura de software central. Incluyen la gestión y la comunicación del conocimiento, el razonamiento del diseño y la toma de decisiones, y la documentación.

Actividades de apoyo a la arquitectura

Las actividades de soporte de la arquitectura de software se llevan a cabo durante las actividades básicas de la arquitectura de software. Estas actividades de apoyo ayudan a un arquitecto de software a realizar análisis, síntesis, evaluación y evolución. Por ejemplo, un arquitecto tiene que recopilar conocimientos, tomar decisiones y documentar durante la fase de análisis.

  • La gestión y comunicación del conocimiento es el acto de explorar y gestionar el conocimiento que es esencial para diseñar una arquitectura de software. Un arquitecto de software no trabaja de forma aislada. Reciben insumos, requisitos funcionales y no funcionales y contextos de diseño de varios interesados; y proporciona resultados a las partes interesadas. El conocimiento de la arquitectura de software suele ser tácito y se conserva en la cabeza de las partes interesadas. La actividad de gestión del conocimiento de la arquitectura de software se trata de encontrar, comunicar y retener conocimiento. Como los problemas de diseño de la arquitectura de software son intrincados e interdependientes, una brecha de conocimiento en el razonamiento del diseño puede llevar a un diseño de arquitectura de software incorrecto. Entre los ejemplos de actividades de comunicación y gestión del conocimiento se incluyen la búsqueda de patrones de diseño, la creación de prototipos, la consulta a desarrolladores y arquitectos experimentados, la evaluación de diseños de sistemas similares, el intercambio de conocimientos con otros diseñadores y partes interesadas y la documentación de la experiencia en una página wiki.
  • El razonamiento del diseño y la toma de decisiones es la actividad de evaluar las decisiones de diseño. Esta actividad es fundamental para las tres actividades centrales de arquitectura de software. Implica recopilar y asociar contextos de decisión, formular problemas de decisión de diseño, encontrar opciones de solución y evaluar compensaciones antes de tomar decisiones. Este proceso ocurre en diferentes niveles de granularidad de decisiones mientras se evalúan requisitos arquitectónicos significativos y decisiones de arquitectura de software, y análisis, síntesis y evaluación de la arquitectura de software. Los ejemplos de actividades de razonamiento incluyen comprender los impactos de un requisito o un diseño en los atributos de calidad, cuestionar los problemas que podría causar un diseño, evaluar las posibles opciones de solución y evaluar las compensaciones entre las soluciones.
  • La documentación es el acto de registrar el diseño generado durante el proceso de arquitectura del software. El diseño del sistema se describe utilizando varias vistas que frecuentemente incluyen una vista estática que muestra la estructura del código del sistema, una vista dinámica que muestra las acciones del sistema durante la ejecución y una vista de implementación que muestra cómo se coloca un sistema en el hardware para su ejecución. La vista 4 + 1 de Kruchten sugiere una descripción de las vistas comúnmente utilizadas para documentar la arquitectura de software; Documentación de arquitecturas de software: vistas y más allá tiene descripciones de los tipos de notaciones que podrían usarse dentro de la descripción de la vista. Ejemplos de actividades de documentación son escribir una especificación, registrar un modelo de diseño de sistema, documentar una justificación del diseño, desarrollar un punto de vista, documentar vistas.

Temas de arquitectura de software

Descripción de la arquitectura del software

Artículo principal: descripción de la arquitectura del software

La descripción de la arquitectura de software involucra los principios y prácticas de modelado y representación de arquitecturas, utilizando mecanismos como lenguajes de descripción de arquitectura, puntos de vista de arquitectura y marcos de arquitectura.

Lenguajes de descripción de arquitectura

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

Un lenguaje de descripción de arquitectura (ADL) es cualquier medio de expresión utilizado para describir una arquitectura de software ( ISO / IEC / IEEE 42010 ). Se han desarrollado muchas ADL con fines especiales desde la década de 1990, incluyendo AADL (estándar 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 la Universidad Nacional Sun Yat-Sen ) y ByADL (Universidad de L'Aquila, Italia).

Miradores de arquitectura

Artículo principal: Ver modelo Modelo de vista arquitectónica 4 + 1.

Las descripciones de la arquitectura de software se organizan comúnmente en vistas, que son análogas a los diferentes tipos de planos realizados en la arquitectura de edificios. Cada vista aborda un conjunto de preocupaciones 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 expresa la arquitectura en cuestión desde la perspectiva de un conjunto dado. de las partes interesadas y sus preocupaciones ( ISO / IEC / IEEE 42010 ). El punto de vista especifica no solo las preocupaciones enmarcadas (es decir, que deben abordarse) sino la presentación, los tipos de modelos utilizados, las convenciones utilizadas y cualquier regla de coherencia (correspondencia) para mantener una visión coherente con otras vistas.

Marcos de arquitectura

Artículo principal: marco de arquitectura

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

Estilos y patrones arquitectónicos

Artículo principal: patrón arquitectónico

Un patrón arquitectónico es una solución general reutilizable para un problema que ocurre comúnmente en la arquitectura de software dentro de un contexto dado. Los patrones arquitectónicos a menudo se documentan como patrones de diseño de software.

Siguiendo la arquitectura de construcción tradicional, un 'estilo arquitectónico de software' es un método específico de 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 se pueden combinar.

Los estilos arquitectónicos son "paquetes" reutilizables de decisiones de diseño y restricciones que se aplican a una arquitectura para inducir las cualidades deseables elegidas.

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

Algunos tratan los patrones arquitectónicos y los estilos arquitectónicos como lo mismo, algunos tratan los estilos como especializaciones de patrones. Lo que tienen en común es que tanto los patrones como los estilos son modismos para que los usen los arquitectos, "proporcionan un lenguaje común" o "vocabulario" con el que describir clases de sistemas.

Arquitectura de software y desarrollo ágil

Artículo principal: Desarrollo ágil

También existe la preocupación de que la arquitectura de software lleve a demasiado Big Design Up Front, especialmente entre los defensores del desarrollo de software ágil. Se han desarrollado varios métodos para equilibrar las ventajas y desventajas del diseño inicial y la agilidad, incluido el método ágil DSDM que exige una fase de "cimientos" durante la cual se establecen los cimientos arquitectónicos "suficientes". IEEE Software dedicó un número especial a la interacción entre agilidad y arquitectura.

Erosión de la arquitectura de software

La erosión (o "decadencia") de la arquitectura de software se refiere a la brecha observada entre la arquitectura planificada y real de un sistema de software tal como se realiza en su implementación. La erosión de la arquitectura de software ocurre cuando las decisiones de implementación no logran completamente la arquitectura según lo planeado o violan las restricciones o los principios de esa arquitectura.

Como ejemplo, considere un sistema estrictamente en capas, donde cada capa solo puede usar los servicios proporcionados por la capa inmediatamente debajo de ella. Cualquier componente de código fuente que no observe 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, mantenibilidad y capacidad de evolución.

Se han propuesto varios enfoques para abordar la erosión. "Estos enfoques, que incluyen herramientas, técnicas y procesos, se clasifican principalmente en tres categorías generales que intentan minimizar, prevenir y reparar la erosión de la arquitectura. Dentro de estas categorías amplias, cada enfoque se desglosa aún más reflejando las estrategias de alto nivel adoptadas para abordar la erosión. Se trata de la conformidad de la arquitectura orientada a procesos, la gestión de la evolución de la arquitectura, la aplicación del diseño de la arquitectura, la vinculación de la arquitectura a la implementación, la autoadaptación y las técnicas de restauración de la arquitectura que consisten en recuperación, descubrimiento y reconciliación ".

Hay dos técnicas principales para detectar violaciones arquitectónicas: modelos de reflexión y lenguajes específicos de dominio. Las técnicas del modelo de reflexión (RM) comparan un modelo de alto nivel proporcionado por los arquitectos del sistema con la implementación del código fuente. También hay lenguajes específicos de dominio que se centran en especificar y comprobar las restricciones arquitectónicas.

Recuperación de la arquitectura de software

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

La recuperación de la 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 a partir de la información disponible, incluida su implementación y documentación. La recuperación de la arquitectura a menudo es necesaria para tomar decisiones informadas frente a la documentación obsoleta o desactualizada y la erosión de la arquitectura : decisiones de implementación y mantenimiento que divergen de la arquitectura prevista. Existen prácticas para recuperar la arquitectura de software como análisis de programa estático. Esto es parte de los temas cubiertos por la práctica de inteligencia de software.

Campos relacionados

Diseño

Artículo principal: Diseño de software

La arquitectura es diseño, pero no todo el diseño es arquitectónico. En la práctica, el arquitecto es quien traza la línea entre la arquitectura de software (diseño arquitectónico) y el diseño detallado (diseño no arquitectónico). No existen reglas o pautas que se ajusten a todos los casos, aunque ha habido intentos de formalizar la distinción. De acuerdo con la Hipótesis de Intensión / Localidad, la distinción entre diseño arquitectónico y de detalle está definida por el Criterio de Localidad, según el cual un enunciado sobre el diseño de software es no local (arquitectónico) si y solo si un programa que lo satisface puede expandirse a un programa que no lo hace. Por ejemplo, el estilo cliente-servidor es arquitectónico (estratégico) porque un programa que se basa en este principio se puede expandir a un programa que no sea cliente-servidor, por ejemplo, agregando nodos peer-to-peer.

Ingeniería de requisitos

Artículo principal: Ingeniería de requisitos

La ingeniería de requisitos y la arquitectura de software pueden verse como enfoques complementarios: mientras que la arquitectura de software se enfoca en el ' espacio de solución ' o el 'cómo', la ingeniería de requisitos aborda el ' espacio de problemas ' o el 'qué'. La ingeniería de requisitos implica la obtención, negociación, especificación, validación, documentación y gestión de requisitos. Tanto la ingeniería de requisitos como la arquitectura del software giran en torno a las preocupaciones, necesidades y deseos de las partes interesadas.

Existe una superposición considerable entre la ingeniería de requisitos y la arquitectura de 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.) suelen estar mal definidas y solo se descubren o mejoran entendido como la arquitectura comienza a emerger " y que si bien " la mayoría de las preocupaciones arquitectónicas se expresan como requisitos en el sistema, también pueden incluir decisiones de diseño obligatorias ". En resumen, el comportamiento requerido afecta la arquitectura de la solución, lo que a su vez puede introducir nuevos requisitos. Enfoques como el modelo Twin Peaks tienen como objetivo explotar la relación sinérgica entre los requisitos y la arquitectura.

Otros tipos de 'arquitectura'

Artículos principales: Arquitectura informática, Arquitectura de sistemas y Arquitectura empresarial
Arquitectura de Computadores
La arquitectura de la computadora tiene como objetivo la estructura interna de un sistema informático, en términos de componentes de hardware en colaboración, como la CPU (o procesador), el bus y la memoria.
Arquitectura de sistemas
El término arquitectura de sistemas se aplicó originalmente a la arquitectura de sistemas que consta de hardware y software. La principal preocupación que aborda la arquitectura de sistemas es entonces la integración de software y hardware en un dispositivo completo y que funcione correctamente. En otro sentido común, mucho más amplio, el término se aplica a la arquitectura de cualquier sistema complejo que pueda ser de naturaleza técnica, sociotécnica o social.
Arquitectura empresarial
El objetivo de la arquitectura empresarial es "traducir la visión y la estrategia empresarial en una empresa eficaz". Los marcos de arquitectura empresarial, como TOGAF y Zachman Framework, generalmente distinguen entre diferentes capas de arquitectura empresarial. Aunque difiere terminología de marco a marco, muchos de ellos incluyen al menos una distinción entre un negocio capa, una aplicación (o información ) de capa, y una tecnología de capa. La arquitectura empresarial aborda, entre otras cosas, la alineación entre estas capas, generalmente en un enfoque de arriba hacia abajo.

Ver también

Referencias

Otras lecturas

enlaces externos

Contactos: mail@wikibrief.org
El contenido está disponible bajo la licencia CC BY-SA 3.0 (a menos que se indique lo contrario).