软件架构（）

软件() 是一组相关的抽象模式，用于指导大型软件系统的各个方面的设计。 软件架构是系统的草图。 软件架构所描述的对象是直接构成系统的抽象组件。各个组件之间的连接以清晰和相对详细的方式描述了组件之间的通信。在实现阶段，这些抽象组件被提炼成实际的组件，例如特定的类或对象。在面向对象领域，组件之间的连接通常用( )来实现。

软件架构是构建计算机实践的基础软件。就像架构师将建筑项目的设计原则和目标作为绘图员绘图的基础一样，软件架构师或系统架构师将软件架构作为实际的系统设计，以满足不同的需求。客户需求方案的基础。 软件在用途、主题、材料和结构方面，可以将建筑与建筑物的建筑进行比较。 软件架构师需要具备丰富的软件理论知识和相应的经验来实施和管理软件产品的高层设计。 软件架构师定义和设计软件模块化、模块之间的交互、用户界面风格、外部界面方法、创新的设计特性以及对象操作、逻辑和高级事物的流程。

架构是系统的基本结构，体现在指导设计开发的原则中，包括其组件、它们之间的关系以及它们与环境的关系。

软件架构是构建计算机实践的基础软件。就像架构师将建筑项目的设计原则和目标作为绘图员绘图的基础一样，软件架构师或系统架构师将软件架构作为实际的系统设计，以满足不同的需求。项目的客户需求基础。

软件架构是一个容易理解的概念，大部分工程师（尤其是经验较少的）都会直观地认出它，但很难给出一个准确的定义。特别是，很难清楚地区分设计和架构：架构是设计的一个方面，侧重于某些特定特征。

软件架构是指根据一定的设计原则，从不同的角度对系统的各个部分进行匹配和排列，形成系统的多种结构，形成一个架构，其中包括系统的各个组成部分，组件的外部可见属性以及组件之间的相互关系。组件的外部可见属性是其他组件对该组件所做的假设。

在“软件 to ”中，David 和 Mary Shaw 认为 软件 是一种设计层次结构，涉及：“除了计算的算法和数据结构之外，设计和确定整体结构结构性问题包括整体组织结构和全局控制结构；通信、同步和数据访问协议；设计元素的功能分配；物理分布；设计元素的组成；选择。"

但建筑不仅仅是结构； Group on 将其定义为“系统在其环境中的最高级别概念”。建筑还包括对系统完整性、经济约束、审美需求和风格的“遵从”。它不仅关注内部考虑，还关注系统在其用户环境和开发环境中作为一个整体，即同时关注外部考虑。

在，软件系统的架构（在给定点）是指系统的重要组件的组织或结构，这些组件通过接口与由不断减少的组件和接口组成的组件进行交互。

软件建筑可以比作建筑的用途、主题、材料和结构。 软件架构师需要具备丰富的软件理论知识和相应的经验来实施和管理软件产品的高层设计。 软件架构师定义和设计软件模块化、模块之间的交互、用户界面风格、外部界面方法、创新的设计特性以及对象操作、逻辑和高级事物的流程。

一般来说画构架图mac软件，软件系统的架构（）有两个元素：

1.是一个软件系统从整体到部分的最高层次划分。

2.一个系统通常是由组件组成的，而这些组件是如何形成的以及它们之间如何相互作用是关于系统本身结构的重要信息。

详细来说，它包括架构元素 ( )、连接器 () 和任务流 (TASk-flow)。所谓架构元素是构成系统的核心“砖块”，而连接器则描述了这些元素之间的通信路径、通信机制以及通信的预期结果。任务流描述了系统如何使用这些元素和连接器来完成某个需求。

在以后构建系统时做出的最高级别、难以更改的商业和技术决策。

在构建系统之前需要做出许多重要的决策，而一旦系统进入详细设计甚至构建阶段，这些决策就很难或不可能改变。显然，这样的决定一定是关乎系统设计成败的最重要的决定，必须认真研究和检验。

根据我们关注的角度，架构可以分为三种：

1.逻辑架构

软件系统中元素之间的关系，如用户界面、数据库、外部系统接口、业务逻辑元素等。

从上图可以看出，这个系统分为三个逻辑层级，即表示层、业务层和数据持久层。每个级别包含多个逻辑元素。比如WEB服务器层有HTML服务元素、服务元素、安全服务元素、系统管理元素。

2.物理架构

软件组件如何放置在硬件上。

例如，在下面的物理架构图中，图中的所有组件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、集成服务器、存储服务器、主机等。

3.系统架构

系统的非功能性特征，例如可扩展性、可靠性、健壮性、灵活性、性能等。

系统架构的设计要求架构师对软件以及硬件的功能和性能有扎实的了解，这无疑是架构设计工作中难度最大的工作。

此外，从各个角度，都可以看到架构的两个要素：组件划分和设计决策。

首先，软件 系统中的元素首先是逻辑元素。这些逻辑元件如何放置在硬件上，以及这些元件对整个系统的可扩展性、可靠性、稳健性、灵活性、性能等有何贡献，是非常重要的信息。

其次，软件 设计需要做出的决定必须包括逻辑结构、物理结构以及它们如何影响系统的所有非功能特性。其中许多决定一旦做出，就很难改变。

根据作者的经验，一个基于数据库的系统架构，其数据表与架构设计文档的页数一样多。例如，一个中型数据库应用系统通常包含100张左右的数据表，这样的系统设计通常需要100页左右的架构设计文档。

我们决定在多个框架视图中表示 软件 框架。每个架构视图都针对开发过程中的利益相关者（例如，最终用户、设计师、经理、系统工程师、维护人员等）感兴趣的特定方面。

架构视图显示软件架构如何分解为组件，以及组件如何通过连接器连接以生成有用的表单 [PW92]，从而记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他约束。这些决策反过来又对较低级别的需求和未来设计决策施加了进一步的限制。

架构由许多不同的架构视图表示，这些视图本质上是“具有架构意义的”模型元素的图形摘要。在 中，您将从称为“4+1 视图模型”[KRU95] 的典型视图集开始。它包括：

1.用例视图：包括用例和场景，其中包括架构上重要的行为、类或技术风险。它是用例模型的一个子集。

2.逻辑视图：包括最重要的设计类，从这些设计类到包和子系统的组织，以及从这些包和子系统到层的组织。它还包括一些用例实现。它是设计模型的一个子集。

3.实施视图：包括实施模型及其从模块到包和层的组织的概述。它还描述了将逻辑视图中的包和类分配给实现视图中的包和模块。它是实现模型的一个子集。

4.进程视图：包括对所涉及的任务（进程和线程）、它们的交互和配置以及设计对象和类对任务的分配的描述。仅当系统具有高度并行性时才需要此视图。在 中，它是设计模型的一个子集。

5.部署视图：包括各种物理节点的描述，用于最典型的平台配置和任务分配（从进程视图）到物理节点。此视图仅在分布式系统中需要。它是部署模型的一个子集。 软件 文档中记录了架构视图。您可以构建其他视图来表达需要特别注意的不同方面：用户界面视图、安全视图、数据视图等。对于简单的系统，4+1视图模型中的一些视图可以省略。

早在 1960 年代，E.W. 等人就已经涉足 软件 的概念。自 1990 年代以来，软件架构的概念越来越受欢迎，部分原因是内部和内部的相关活动。

卡内基梅隆大学和加州大学欧文分校在这方面做了很多研究。卡内基梅隆大学的 Mary Shaw 和 David 在 1996 年写了一本名为 on an 的书，介绍了 软件 架构中的许多概念，例如 软件 组件、连接器、样式等。软件 加州大学欧文分校研究所专注于建筑风格、建筑描述语言和动态建筑。

计算机的历史软件始于1950年代画构架图mac软件，历史很短。相反，建筑工程始于石器时代。人类几千年来积累了大量的建筑设计实践。经验和教训。建筑设计基本上包括两点，一是建筑风格，二是建筑模式。独特的架构款式和正确选择的建筑模式可以使建筑物独特。

软件与人的关系是建筑师必须面对的核心问题，也是软件进入历史舞台后出现的问题。同样，自建筑诞生以来，建筑与人的关系一直是建筑师不得不面对的核心问题。英国首相温斯顿·丘吉尔说，我们塑造我们的建筑，我们的建筑塑造我们（We shape our ，and our shape us）。英国下议院的议事厅比较狭窄，所以下议院的所有议员不能面朝同一个方向就座，而必须分两侧就座。丘吉尔认为，国会议员在就位时，自然会选择与自己政见相同的人同时就位，这就是英国政党制度的由来。党的本义是“方”和“面”。政党起源的关键在于建筑对人的影响。

在软件设计界曾经有很多人认为功能是最重要的，形式必须服从功能。同样，在建筑领域，现代主义建筑学派的创始人之一路易斯也认为形式应该服从于功能（FORMs）。

几乎所有的软件设计理念都能在浩瀚的建筑史中找到更遥远的历史回响。最著名的当然是模式理论和 XP 理论。

正如软件有自己要实现的目标，那么架构设计的目标是什么？总的来说，软件架构设计应该达到以下目标：

1.可靠性（）。 软件系统对用户的业务运营和管理极为重要，所以软件系统必须非常可靠。

2.安全性（）。 软件系统承担的交易的商业价值极高，系统的安全性非常重要。

3.可扩展性（）。 软件必须能够随着用户使用和用户数量的快速增加而保持合理的性能。只有这样，我们才能适应用户市场扩张的可能性。

4.可定制（）。同一套软件可以根据不同的客户群体和市场需求的变化进行调整。

5.可扩展性（）。随着新技术的出现，软件系统应该允许引入新技术来扩展现有系统的功能和性能。

6.可维护性（）。 软件系统的维护包括两个方面，一是消除现有的错误，二是将新的软件需求反映到现有系统中。易于维护的系统可以有效降低技术支持成本。

7.客户体验 ( )。 软件系统必须易于使用。

8.上市时间。 软件用户面临横向竞争，软件提供商也面临横向竞争。以最快的速度争夺市场机会非常重要。

虽然以上视图可以代表系统的整体设计，但架构仅与以下特定方面相关：

模型的结构，即组织模式，如层次结构。基本元素，即关键用例、主要类、通用机制等，与模型中的元素相对。几个关键场景，代表了整个系统的主要控制流程。一种记录模块化、可选功能和产品线状态的服务。

架构视图本质上是对整体设计的抽象或简化，通过省略特定细节来突出重要功能。在考虑以下方面时，这些特征很重要。

系统进化意味着进入下一个开发周期。在产品线环境中重用架构或架构的一部分。评估补充质量，例如性能、可用​​性、便携性和安全性。将开发工作分配给团队或分包商。决定是否包括市售组件。插入更广泛的系统。

架构模式是解决复杂架构问题的现成形式。框架或框架基础设施（中间件）是可以在其上构建框架的一组组件。许多主要的架构难题应该在框架或基础架构中解决，并且通常是特定领域的：指挥和控制、MIS、控制系统等等。

架构模式示例

[BUS96] 根据架构模式最适用的系统的特征对其进行分类，其中一类处理更一般的结构问题。下表显示了[BUS96]中提供的类别以及这些类别中包含的模式。

类别模式结构层管道和过滤器黑板分布式系统代理交互系统模型-视图-控制器表示-抽象-控制自适应系统反射微内核

在“软件 to ”中，David 和 Mary Shaw 认为，软件 是一种设计层次结构，涉及：“超越计算的算法和数据结构，设计和确定整体结构结构问题包括整体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；选择。 [GS93]

但建筑不仅仅是结构； IEEE Group on 将其定义为“系统在其环境中的最高级别概念”[]。建筑还包括对系统完整性、经济约束、审美需求和风格的“遵从”。它不仅关注内部考虑，还关注系统在其用户环境和开发环境中作为一个整体，即同时关注外部考虑。

在，软件系统的架构（在给定点）是指系统的重要组件的组织或结构，这些组件通过接口与由不断减少的组件和接口组成的组件进行交互。

为了阐明它们的含义，下面详细介绍其中的两个；有关完整说明，请参见 [BUS96]。模式以以下广泛使用的形式表示：

模式名称环境问题影响，描述应该考虑的不同问题方面的解决方案基本原理结果环境示例模式名称层

环境需要庞大的结构分解系统。

一个问题必须处理不同抽象级别的问题系统。例如：硬件控制问题、常见服务问题和特定于不同领域的问题。最好不要编写垂直组件来处理所有抽象级别。否则，相同的问题将在不同的组件中处理多次（可能不一致）。

影响

系统的某些部分应该是可更换的。组件的变化不应波动。类似的职责应该归为一类。形成分层结构。使上层只使用下层提供的服务（永远不要使用上层）。尽量不要使用直接下层不提供的服务（不要跳层使用服务，除非中间层只添加透传组件）。

例子：

1.通用层

严格的分层架构规定设计元素（类、组件、包、子系统）只能使用较低层提供的服务。服务可以包括事件处理、错误处理、数据库访问等。它包含比在后台记录的原始操作系统级别调用更明显的机制。

2.业务系统层

上图显示了另一个分层示例，包括垂直应用程序特定层、水平层和基础设施层。注意：这里的目标是拥有一个非常短的业务“烟囱”，并在各种应用程序中实现通用性。否则，可能会有多人在处理同一个问题，从而导致潜在的分歧。

有关此模式的深入讨论，请参阅指南：分层。

模式名称黑板

环境没有确定的方法（算法）来解决问题或方法不可行的区域。例如人工智能系统、语音识别和监控系统。

问题多个问题解决顾问（知识顾问）必须协作解决他们无法单独解决的问题。每个顾问的工作成果必须可供所有其他顾问访问，让他们能够评估自己是否可以参与解决方案寻找并发布他们的工作成果。

影响

知识顾问参与问题解决的顺序不是确定性的，可能取决于解决问题的策略

不同顾问的输入（结果或部分解决方案）可能会有不同的表示

每个顾问并不直接知道对方的存在，但可以评估对方发布的工作

解决方案 多个知识顾问可以访问一个名为“”的共享数据库。黑板提供了一个界面来监控和更新其内容。控制模块/对象激活遵循特定策略的顾问。激活后，顾问查看黑板，看是否可以参与解决问题。如果顾问决定它可以参与，控制对象可以允许顾问将其（或最终）解决方案的一部分放在黑板上。

例子：

上面显示了使用 UML 建模的结构或静态视图。它将是参数化协作的一部分，然后将绑定到参数以实例化架构。

建筑风格软件框架（或只是框架视图）可以具有称为建筑风格的属性，它减少了可选形式并赋予框架一定程度的一致性。样式可以通过一组模式或通过选择特定组件或连接器作为基础组件来定义。对于给定的系统，某些样式可能会作为架构描述的一部分记录在架构样式指南（设计指南文档的一部分）中。样式在架构的可理解性和完整性方面发挥着重要作用。

逻辑视图：类图、状态机和对象图。进程视图：类图和对象图（包括任务-进程和线程）。实现视图：组件图。部署视图：配置图。

架构描述语言（ADL）用于描述软件的架构。架构描述语言有几种（卡内基梅隆大学开发）、Acme（卡内基梅隆大学开发）、C2（UCI开发）、（伦敦帝国理工学院开发）。 ADL 的基本构建块包括组件、连接器和配置。

框架

架构视图的图形表示称为架构计划。对于上述各种视图，设计图由以下统一建模语言图 [UML99] 组成：

1.逻辑视图：类图、状态机和对象图。

2.进程视图：类图和对象图（包括任务 - 进程和线程）。

3.实现视图：组件绘图。

4.部署视图：配置图。

5.用例视图：用例图描述用例、主角和常见的设计类；序列图描述设计对象及其协作关系。

架构设计过程

在 中，架构主要是分析-设计工作流程的结果。随着项目再次经历这个工作流程，架构将在一次又一次的迭代中进化、改进和细化。由于每次迭代都包括集成和测试，因此在交付产品时架构相当健壮。架构是细化阶段每次迭代的重点，架构的基线通常在此阶段结束时确定。

建筑师

软件设计师中有一些技术高超、经验丰富的设计师，需要承担软件系统的架构设计，即如何设计系统的组件，组件如何设计被划分为交互如何发生，以及在系统内做出逻辑、物理和系统关键决策。

这样的人被称为建筑师（）。在许多公司中，架构师并不是一个专门且正式的职位。通常在开发团队中，最有经验的程序员负责一些架构工作。在一个部门内，最有经验的项目经理负责一些架构工作。

但是，越来越多的公司意识到架构工作的重要性，并在不同的组织层级设立了专门的架构师职位，负责不同层级的逻辑架构、物理架构、系统架构的设计、配置、维护等。

软件架构是软件系统运行时元素的抽象，软件系统可能有很多抽象层，或者由多个业务流程组成，每一层抽象或者每个业务流程进程有自己的 软件 架构。

软件架构是平衡的艺术。

参考：