Haga clic para ingresar al directorio de series de artículos.
现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
Diseño de arquitectura de sistemas · Conceptos básicos (1) [Diseñador de arquitectura de sistemas]
- 1. El concepto de arquitectura de software★★★
- 2. Estilo de arquitectura de software★★★★★
-
- 2.1 Cinco estilos clásicos de arquitectura de software
- 2.2 estilo C2
- 2.3 Estilo de circuito cerrado
- 3. Método de desarrollo de software basado en arquitectura (ABSD) ★★★★
- 4. Arquitectura de software de dominio específico (DSSA) ★★★
- 5. Reutilización de la arquitectura de software★★★
1. El concepto de arquitectura de software★★★
1.1 Definición de arquitectura de software.
conceptos de arquitectura de software
Arquitectura de software = La arquitectura de software
se refiere a una o más estructuras del sistema. La estructura incluye:
(1) Estructura: los componentes del software (que pueden ser módulos de programa, clases o middleware)
(2) Atributos: componentes Propiedades visibles externamente
(3) Interacción: la relación entre componentes.
La naturaleza de la arquitectura del software.
La arquitectura de software proporciona una abstracción de alto nivel de la estructura, el comportamiento y las propiedades de un sistema de software . Un estilo arquitectónico de software es un patrón idiomático
para un dominio de aplicación específico.La arquitectura define un vocabulario y un conjunto de restricciones .
El papel de la arquitectura de software.
La arquitectura de software es el medio por el cual se comunican las partes interesadas del proyecto .
La arquitectura de software es un modelo transferible y reutilizable , y es posible predecir la calidad del software estudiando la arquitectura del software.
La arquitectura de software simplifica el razonamiento y el control de los cambios, facilita la creación de prototipos paso a paso y puede servir como base para la capacitación.
Análisis de requisitos → Arquitectura (cerrando la brecha entre los requisitos y el diseño) → Diseño de software
El diseño de arquitectura es la asignación de requisitos, que asigna la responsabilidad de cumplir los requisitos a los componentes .
El diseño de la arquitectura de software se describe exhaustivamente a través de múltiples vistas: vista 4 + 1 .
1.2 Diseño de arquitectura de software vista 4+1
Perspectivas y puntos de vista:
Examine desde diferentes perspectivas, por lo que habrá diferentes puntos de vista.
Kruchten propuso un modelo de vista "4+1" en 1995. El modelo de vista "4+1" describe la arquitectura del software desde 5 perspectivas diferentes, incluida la vista lógica, la vista de proceso, la vista física, la vista de desarrollo y la vista de escena. Cada vista solo se preocupa por un aspecto del sistema y solo la combinación de cinco vistas puede reflejar el contenido completo de la arquitectura del software del sistema.
Vista lógica : Soporta principalmente los requisitos funcionales del sistema, es decir, los servicios proporcionados por el sistema a los usuarios finales. La cuestión principal a la que se debe prestar atención en el diseño de vistas lógicas es mantener un modelo de objetos único y cohesivo en todo el sistema y describir la relación entre el modelo de objetos y los objetos.
Vista de desarrollo : También conocida como vista de módulos, se centra principalmente en la organización y gestión de módulos de software. La vista de desarrollo se describe a través de diagramas de modelo y diagramas de subsistema de relaciones de entrada y salida del sistema. Puede describir la perspectiva de desarrollo completa después de identificar todos los elementos que contiene el software, o puede enumerar los principios de la vista de desarrollo antes de identificar cada elemento.
Vista de proceso : también conocida como vista de proceso. Centrarse en las características operativas del sistema, centrándose principalmente en algunos requisitos no funcionales, como el rendimiento y la disponibilidad del sistema. La vista de proceso enfatiza la concurrencia, la distribución, la integración del sistema y la tolerancia a fallas, así como la estructura del proceso como abstracción principal en la vista lógica. La visión del proceso se puede describir como múltiples niveles de abstracción, y cada nivel se centra en diferentes aspectos.
Vista física : Considera principalmente cómo asignar software a hardware y generalmente tiene en cuenta la resolución de problemas como la topología del sistema, la instalación del sistema y la comunicación.
Escenario : Puede verse como una abstracción de esas importantes actividades del sistema, que conecta orgánicamente las cuatro vistas. En cierto sentido, el escenario es la abstracción de requisitos más importante. Al desarrollar una arquitectura, ayuda a los diseñadores a encontrar los componentes de la arquitectura y las relaciones entre ellos. Los escenarios también se pueden utilizar para analizar una vista específica o para describir cómo interactúan entre sí los diferentes componentes de la vista. Las escenas se pueden representar textual o gráficamente.
La vista lógica y la vista de desarrollo describen la estructura estática del sistema , mientras que la vista de proceso y la vista física describen la estructura dinámica del sistema . Para diferentes sistemas de software, los ángulos de enfoque también son diferentes. Por ejemplo, para los sistemas de información de gestión, se pone más énfasis en describir el sistema desde la vista lógica y la vista de desarrollo, mientras que para los sistemas de control en tiempo real, se pone más énfasis en describir el sistema desde la vista del proceso y la vista física.
1.3 Diseño de arquitectura de software y ciclo de vida.
La arquitectura del software recorre todo el ciclo de vida y las diferentes etapas tienen diferentes funciones y significados . La tabla de rendimiento del trabajo de la arquitectura de cada etapa:
| escenario | Función y significado |
|---|---|
| etapa de análisis de requisitos | Favorece la comunicación entre los participantes en cada etapa y también es fácil mantener la trazabilidad de cada etapa. La conversión del modelo de requisitos de software al modelo de arquitectura de software se centra en dos cuestiones: 1) Cómo construir un modelo de arquitectura de software basado en el modelo de requisitos 2) Cómo garantizar la trazabilidad de la conversión del modelo |
| fase de diseño | Concéntrese en las etapas más tempranas y numerosas. La investigación en esta etapa incluye principalmente: 1) Descripción del modelo de arquitectura de software 2) Métodos de diseño y análisis del modelo de arquitectura de software 3) Resumen de la experiencia en diseño de arquitectura de software y descripción del modelo de arquitectura de reutilización La investigación incluye: ① Composición de SA (arquitectura de software) Modelo: modelado de componentes y conexiones ② Lenguaje de descripción de arquitectura (ADL) ③ Vista múltiple: vista 4 + 1 Tres elementos básicos de ADL: 1) Componente: unidad informática o de almacenamiento de datos, incluidos los componentes y las interfaces de componentes correspondientes 2) Conectores: arquitectónicos bloques de construcción para modelar interacciones entre componentes y las reglas que gobiernan estas interacciones 3) Configuración de arquitectura: diagramas de conexión que describen los componentes y conectores de la arquitectura ADL se utiliza para modelar y es un pseudocódigo |
| etapa de implementacion | Realice eficazmente la transformación desde el diseño de la arquitectura de software hasta la implementación. La investigación de arquitectura en esta etapa incluye: 1) Soporte basado en el proceso de desarrollo de la arquitectura 2) Búsqueda de formas de transición de la arquitectura a la implementación 3) Investigación sobre tecnología de prueba basada en arquitectura |
| etapa de ensamblaje de componentes | El diseño del ensamblaje de componentes reutilizables puede mejorar la eficiencia de la implementación del sistema. Los contenidos de la investigación en esta etapa incluyen: 1) Cómo soportar la interconexión de componentes reutilizables, es decir, brindar soporte para la implementación de conectores especificados en el modelo de diseño arquitectónico 2) Cómo detectar y eliminar problemas de desajuste arquitectónico y problemas de adaptación durante el proceso de ensamblaje incluye principalmente: ① Adaptación del propio componente ② Desajuste de conectores (mecanismo de interconexión) ③ Desajuste entre las piezas y el conjunto |
| Fase de implementación | Organizar y presentar la arquitectura de software y hardware durante la fase de implementación, y evaluar y analizar los planes de implementación. El papel de la arquitectura de software en la etapa de implementación en la implementación de software: 1) Proporcionar una vista arquitectónica de alto nivel para describir el modelo de software y hardware en la etapa de implementación 2) Según el modelo de arquitectura de software, los atributos de calidad del plan de implementación pueden ser analizado para seleccionar un plan de implementación razonable |
| etapa posterior al desarrollo | Principalmente en torno al mantenimiento, la evolución y la reutilización. Las direcciones de investigación de la arquitectura del sistema después de la implementación y la instalación (etapa posterior al desarrollo) incluyen: 1) Arquitectura de software dinámica 2) Recuperación y reconstrucción de la arquitectura |
1.4 La importancia de la arquitectura del software
El diseño de la arquitectura de software es un factor clave para reducir costos, mejorar la calidad y entregar productos a tiempo y bajo demanda.
2. Estilo de arquitectura de software★★★★★
- Un estilo arquitectónico define un glosario de términos utilizados para describir un sistema y un conjunto de reglas para guiar su construcción.
- El estilo arquitectónico refleja las características estructurales y semánticas compartidas por muchos sistemas en el campo y orienta cómo organizar eficazmente varios componentes en un sistema completo.
- Un estilo arquitectónico de software es un patrón idiomático para un dominio de aplicación específico. La arquitectura define un vocabulario y un conjunto de restricciones.
2.1 Cinco estilos clásicos de arquitectura de software
| Cinco estilos arquitectónicos | sub estilo |
|---|---|
| estilo de flujo de datos | lote, filtro de tubería |
| estilo de llamada/retorno | Programa/Subrutina, Orientación a Objetos, Jerarquía |
| estilo centrado en datos | Sistema de base de datos, sistema de pizarra, sistema de hipertexto. |
| Estilo de máquina virtual | Intérprete, sistema de reglas. |
| estilo de componente independiente | Comunicación de procesos, sistema controlado por eventos (llamada implícita) |
2.1.1 Estilo arquitectónico del flujo de datos
| ventaja | defecto | Ejemplos típicos |
|---|---|---|
| 1、松耦合【高内聚-低耦合】 2、良好的重用性/可维护性 3、可扩展性【标准接口适配】 4、良好的隐蔽性 5、支持并行 |
1、交互性较差 2、复杂性高 3、性能较差（每个过滤器都需要解析与合成数据） |
传统编译器 网络报文处理 |
2.1.1.1 批处理风格
批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。数据必须是完整的，以整体的方式传递。
2.1.1.2 管道/过滤器风格
在管道/过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
2.1.2 调用/返回系结构风格
2.1.2.1 主程序/子程序风格
主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。
2.1.2.2 面向对象风格
这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
2.1.2.3 层次结构风格
层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见
2.1.3 以数据为中心系结构风格
2.1.3.1 仓库结构风格
数据库系统是仓库风格最常见的形式。在数据库系统中，构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
2.1.3.2 黑板结构风格
黑板系统包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中，例如，信号处理、问题规划和编译器优化等。语音识别、知识推理。
2.1.3.3 超文本系统风格
超文本系统中出现的构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。
2.1.4 虚拟机体系结构风格
2.1.4.1 解释器风格
解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。
2.1.4.2 规则系统风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。
2.1.5 独立构件体系结构风格
2.1.5.1 进程间通信风格
构件是独立的过程，连接件是消息传递，构件通常是命名过程，消息传递的方式可以是点对点，异步或者同步的方式，以及远程过程方法调用等。
2.1.5.2 事件驱动系统风格（隐式调用）
构件不直接调用一个过程，而是触发或广播一个或多个事件。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用（implicit invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。
2.2 C2风格
C2风格通过连接件连接构件或某个构件组，构件与构件之间无连接。
软件体系结构设计的一个核心问题就是能否使用重复的体系结构模式，即能否达到体系结构级的软件重用。
C2 = EBI（基于事件的集成）+ LCS（分层客户端服务器）
C2是一种基于构件和消息的架构风格，可用于创建灵活的，可伸缩的软件系统。可以将架构看作是按照一定规则由连接件如消息路由设备连接的许多构件组成的层次网络系统中的构件和连接件都有一个“顶部”和“底部”;一个构件的“顶部”或“底部”可以连接到一个连接件的“底部”或“顶部”;对于一个连接件，和其相连的构件或连接件的数量没有限制，但是构件和构件之间不能直接相连。
C2架构的基本规则：
- 构件和连接件都有一个顶部和一个底部。
- 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
- 一个连接件可以和任意数目的其他构件和连接件连接。
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
2.3 闭环风格
- 适用于嵌入式系统，用于解决简单闭环控制问题。
- 经典应用：空调温控，定速巡航。
三、基于架构的软件开发方法（ABSD）★★★★
3.1 体系机构设计的方法概述
基于架构的软件设计（ABSD，Architecture-Based Software Design）是一种架构驱动方法，架构驱动也就是说架构先行，需求获取和分析还没有完成就开始架构设计，需求获取和分析与架构设计并行，例如产品线系统和长期运行的系统，我们不可能开始就能决定所有的需求。
ABSD强调由业务、质量和功能需求的组合驱动架构设计 ，强调采用 视角和视图 来 描述软件架构 ，采用 用例（功能需求）和质量场景（质量需求） 来 描述需求 。
ABSD方法有三个基础：
- 第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
- 第二个基础是通过选择架构风格来实现质量和业务需求。
- 第三个基础是软件模板的使用。
3.2 基于架构的开发模型（ABSD）
传统的软件开发过程是问题定义，需求分析，软件设计，实现，测试。ABSD把整个软件过程分成六个部分，架构需求，设计，文档化，复审，实现，演化六个步骤。
四、特定领域的软件架构（DSSA）★★★
DSSA（Domain Specific Software Architecture）特定领域软件架构，可以看做开发产品线的一个方法或理论，目标就是支持一个特定领域中多应用的生成。
4.1 特定领域的软件架构 - 基本活动
（1）建立领域模型，一个严格定义的问题域或解决域。其中，垂直域是在相同领域中深入；水平域是在不同领域中平移。
（2）具有普遍性，使其可以用于领域中某个特定应用的开发。
（3）对整个领域的合适程序的抽象。
（4）具备该领域固定的、典型的在开发过程中的。可复用元素。
4.2 特定领域的软件架构 - 领域分析机制
4.3 特定领域的软件架构 - 建立过程
五、软件架构的复用★★★
-
Definición y clasificación de la reutilización de la arquitectura de software La reutilización de la arquitectura de software
es un proceso sistemático de desarrollo de software: desarrollar un conjunto de módulos de componentes de software básicos para cubrir similitudes entre diferentes requisitos/arquitecturas y mejorar la eficiencia y la calidad del desarrollo y el rendimiento del sistema. -
Las razones para la reutilización de la arquitectura de software son
reducir el trabajo de desarrollo, reducir el tiempo de desarrollo, reducir los costos de desarrollo, aumentar la productividad, mejorar la calidad del producto y lograr una mejor interoperabilidad. -
Objetos y formas de reutilización de la arquitectura de software Los activos reutilizables
incluyen: requisitos, diseño arquitectónico, elementos, análisis de modelado, pruebas, planificación de proyectos, procesos + métodos + herramientas, personal, sistemas de muestra y eliminación de defectos.
Las formas generales de reutilización incluyen: reutilización de funciones, reutilización de bibliotecas y reutilización de clases, interfaces y paquetes en el desarrollo orientado a objetos. -
El proceso básico de reutilización de la arquitectura de software
(1) Primero construir/obtener activos de software reutilizables (requisito previo para la reutilización);
(2) Administrar activos reutilizables;
(3) Usar activos reutilizables.
Haga clic para ingresar al directorio de series de artículos.