我是荔园微风，作为一名在IT界整整25年的老兵，今天我们来聊聊Windows软件架构的概念。
Shaw和Garlan在他们划时代的著作中以如下方式讨论了软件的体系结构：从第一个程序被划分成模块开始，软件系统就有了体系结构。现在，有效的软件体系结构及其明确的描述和设计，已经成为Windows软件工程领域中重要的主题。
Windows软件架构的定义
Bass、Clements 和 Kazman对于这个概念给出了如下的定义：一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。体系结构并非可运行软件。确切地说，它是一种表达，使软件工程师能够(1)分析设计在满足规定需求方面的有效性。(2)在设计变更相对容易的阶段，考虑体系结构可能的选择方案。(3)降低与软件构造相关联的风险。
在Windows体系结构设计的环境中，软件构件可以简单到程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的“中间件”。
软件体系结构的设计通常考虑了两个层次——数据设计和体系结构设计。数据设计使我们表示出传统系统中体系结构的数据构件和面向对象系统中类的定义（封装了属性和操作），体系结构设计则主要关注软件构件的结构、属性和交互作用。
建立Windows体系结构层的“内聚的、良好设计的表示”所需的方法，其目标是提供一种导出体系结构设计的系统化方法，而体系结构设计是构建软件的初始蓝图。
Windows软件架构设计与生命周期
1.需求分析阶段
在本质上，需求和SA设计面临的是不同的对象：一个是问题空间；另一个是解空间。保持二者的可追踪性和转换，一直是软件工程领域追求的目标。从软件需求模型向SA模型的转换主要关注两个问题：(1)如何根据需求模型构建SA模型。(2)如何保证模型转换的可追踪性。
针对这两个问题的解决方案，随着所采用的需求模型的不同而各异。在采用Use Case图描述需求的方法中，从Use Case图向SA模型（包括类图等）的转换一般经过词性分析和一些经验规则来完成，而可追踪性则可通过表格或者UseCaseMap等来维护。
从软件复用的角度看，SA影响需求工程也有其自然性和必然性，已有系统的SA模型对新系统的需求工程能够起到很好的借鉴作用。在需求阶段研究SA,有助于将SA的概念贯穿整个软件生命周期，从而保证了软件开发过程的概念完整性，有利于各阶段参与者的交流，也易于维护各阶段的可追踪性。
2.设计阶段
设计阶段是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为三个层次。
(1)SA的基本概念,即SA模型由哪些元素组成,这些组成元素之间按照何种原则组织。传统的设计概念只包括构件（软件系统中相对独立的有机组成部分，最初称为模块)以及一些基本的模块互联机制。随着研究的深入，构件间的互联机制逐渐独立出来，成为与构件同等级别的实体，称为连接子。现阶段的SA描述方法是构件和连接子的建模。近年来，也有学者认为应当把Aspect等引入SA模型。
(2)体系结构描述语言（Architecture Description Language,ADL)，支持构件、连接子及其配置的描述语言就是如今所说的体系结构描述语言。ADL对连接子的重视成为区分ADL和其他建模语言的重要特征之一。典型的ADL包括UniCon、Rapide、Darwin、Wright、C2 SADLAcme、 xADL、 XYZ/ADL和 ABC/ADL等。
(3）SA模型的多视图表示，从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的SA模型。多视图作为一种描述SA的重要途径，也是近年来SA研究领域的重要方向之一。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的特定方面，多视图体现了关注点分离的思想。
把体系结构描述语言和多视图结合起来描述Windows系统的体系结构，能使系统更易于理解，方便系统相关人员之间进行交流，并且有利于系统的一致性检测以及系统质量属性的评估。学术界已经提出若干多视图的方案，典型的包括4+1模型（逻辑视图、进程视图、开发视图、物理视图，加上统一的场景)、Hofmesiter的4视图模型（概念视图、模块视图、执行视图、代码视图)、CMU-SEI的Views and Beyond模型（模块视图、构件和连接子视图、分配视图)等。此外，工业界也提出了若干多视图描述SA模型的标准，如IEEE标准1471-2000（软件密集型系统体系结构描述推荐实践）、开放分布式处理参考模型(RM-ODP)、统一建模语言(UML)以及IBM公司推出的Zachman框架等。需要说明的是，现阶段的ADL大多没有显式地支持多视图，并且上述多视图并不一定只描述设计阶段的模型。
3.实现阶段
最初的SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现从SA设计向实现的转换，实现阶段的体系结构研究在以下几个方面。(1)研究基于SA的开发过程支持，如项目组织结构、配置管理等。(2)寻求从SA向实现过渡的途径，如将程序设计语言元素引入SA阶段、模型映射、构件组装、复用中间件平台等。(3)研究基于SA的测试技术。
SA提供了待生成系统的蓝图，根据该蓝图实现系统需要较好的开发组织结构和过程管理技术。以体系结构为中心的软件项目管理方法，开发团队的组织结构应该和体系结构模型有一定的对应关系，从而提高软件开发的效率和质量。
对于大型软件系统而言，由于参与实现的人员较多，所以需要提供适当的配置管理手段。SA引入能够有效扩充现有配置管理的能力，通过在SA描述中引入版本、可选择项等信息，可以分析和记录不同版本构件和连接子之间的演化，从而可用来组织配置管理的相关活动。典型的例子包括支持给构件指定多种实现的UniCon、支持给构件和连接子定义版本信息和可选信息的xADL等。
为了填补高层SA模型和底层实现之间的鸿沟，通过封装底层的实现细节，模型转换、精化等手段缩小概念之间的差距。典型的方法如下。(1)在SA模型中引入实现阶段的概念，如引入程序设计语言元素等。(2)通过模型转换技术，将高层的SA模型逐步精化成能够支持实现的模型。(3)封装底层的实现细节，使之成为较大粒度构件，在SA指导下通过构件组装的方式实现系统，这往往需要底层中间件平台的支持。
4.构件组装阶段
在SA设计模型的指导下，可复用构件组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。研究内容包括：(1)如何支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持。(2)在组装过程中，如何检测并消除体系结构失配问题。
对设计阶段连接子的支持：不少ADL支持在实现阶段将连接子转换到具体的程序代码或系统实现，如 UniCon 定义了 Pipe、FileIO、ProcedureCall等多种内建的连接子类型，它们在设计阶段被实例化，并可以在实现阶段在工具的支持下转化成为具体的实现机制，如过程调用、操作系统数据访问、Unix管道和文件、远程过程调用等。支持从SA模型生成代码的体系结构描述语言，如C2SADL、Rapide等，也都提供了一定的机 制生成连接子的代码。
中间件遵循特定的构件标准，为构件互联提供支持，并提供相应的公共服务，如安全服务、命名服务等。中间件支持的连接子实现有如下优势：
(1)中间件提供了构件之间跨平台交互的能力，且遵循特定的工业标准，如CORBA、J2EE、COM等，可以有效地保证构件之间的通信完整性。
(2)产品化的中间件可以提供强大的公共服务能力，这样能够更好地保证最终系统的质量属性。设计阶段连接子的规约可以用于中间件的选择，如消息通信连接子最好选择提供消息通信机制的中间件平台。从某种意义上说，随着中间件技术的发展，也导致一类新的SA风格，即中间件导向的体系结构风格(middleware-induced architectural style)的出现。
检测并消除体系结构失配：体系结构失配问题是由DavidGarlan等人在1995年提出。失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设（assumption)与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括：
(1)由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。
(2)由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。
(3)由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。
5.部署阶段
随着网络与分布式软件的发展，软件部署逐渐从软件开发过程中独立出来，成为软件生命周期中一个独立的阶段。为了使分布式软件满足一定的质量属性要求，如性能、可靠性等，部署需要考虑多方面的信息，如待部署软件构件的互联性、硬件的拓扑结构、硬件资源占用（如CPU、内存）等。SA对软件部署作用如下。(1)提供高层的体系结构视图描述部署阶段的软硬件模型。(2)基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案。
现阶段，基于SA的软件部署研究更多地集中在组织和展示部署阶段的SA、评估分析部署方案等方面，部署方案的分析往往停留在定性的层面，并需要部署人员的参与。
6.后开发阶段
后开发阶段是指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。
1)动态软件体系结构
传统的SA研究设想体系结构总是静态的，即软件的体系结构一旦建立，就不会在运行时刻发生变动。但人们在实践中发现，现实中的软件往往具有动态性，即它们的体系结构会在运行时发生改变。SA在运行时发生的变化包括两类。一类是软件内部执行所导致的体系结构改变。比如，很多服务器端软件会在客户请求到达时创建新的构件来响应用户的需求。某个自适应的软件系统可能根据不同的配置状况采用不同的连接子来传送数据。另一类变化是软件系统外部的请求对软件进行的重配置。比如，有很多高安全性的软件系统，这些系统在升级或进行其他修改时不能停机。因为修改是在运行时刻进行的，体系结构也就动态地发生了变化。在高安全性系统之外也有很多软件需要进行动态修改，比如很多操作系统期望能够在升级时无须重新启动系统，在运行过程中就完成对体系结构的修改。
由于软件系统会在运行时刻发生动态变化，这就给体系结构的研究提出了很多新的问题。如何在设计阶段捕获体系结构的这种动态性，并进一步指导软件系统在运行时刻实施这些变化，从而达到系统的在线演化或自适应甚至自主计算，是动态体系结构所要研究的内容。现阶段，动态软件体系结构研究可分为以下两个部分。
(1)体系结构设计阶段的支持。主要包括变化的描述、根据变化如何生成修改策略、描述修改过程、在高抽象层次保证修改的可行性以及分析、推理修改所带来的影响等。(2)运行时刻基础设施的支持。主要包括系统体系结构的维护、保证体系结构修改在约束范围内、提供系统的运行时刻信息、分析修改后的体系结构符合指定的属性、正确映射体系结构构造元素的变化到实现模块、保证系统的重要子系统的连续执行并保持状态、分析和测试运行系统等。
2)体系结构恢复与重建
当前系统的开发很少是从头开始的，大量的软件开发任务是基于已有的遗产系统进行升级、增强或移植。这些系统在开发的时候没有考虑SA,在将这些系统进行构件化包装、复用的时候，会得不到体系结构的支持。因此，从这些系统中恢复或重构体系结构是有意义的，也是必要的。
SA重建是指从已实现的系统中获取体系结构的过程。一般地，SA重建的输出是一组体系结构视图。现有的体系结构重建方法可以分为4类：
(1)手工体系结构重建。(2)工具支持的手工重建。通过工具对手工重建提供辅助支持，包括获得基本体系结构单元、提供图形界面允许用户操作SA模型、支持分析SA模型等。如KLOCworkinSight工(www.klocwork.com/products/insight.asp)使用代码分析算法直接源代码获得SA构件视图，用户可以通过操作图形化的SA设定体系结构规则，并可在工具的支持下实现对体系结构的理解、自动控制和管理。(3)通过查询语言来自动建立聚集。这类方法适用于较大规模的系统，基本思路是：在逆向工程工具的支持下分析程序源代码，然后将所得到的体系结构信息存入数据库，并通过适当的查询语言得到有效的体系结构显示。(4)使用其他技术，比如数据挖掘等。
好了，说了这么多，本文的重点来了，Windows软件架构的重要性到底是什么？
Windows软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。
1.Windows架构设计能够满足系统的品质
系统的功能性是软件构架师通过组成体系架构的多种元素之间的交互作用来支持的。Windows架构设计用于实现系统的品质，如性能、安全性和可维护性等。通过架构设计文档化，可以尽早的评估项目的这些品质。
2.Windows架构设计使受益人达成一致的目标
Windows架构设计的过程使得不同的受益人达成一致的目标，体系架构的过程需要确保架构设计被清楚地传达与理解。一个被有效传达的体系架构使得涉众们可以辩论决议和权衡，反复讨论，最终达成共识。文档化体系架构是非常重要的，这是软件构架师的主要职责。
3.Windows架构设计能够支持计划编制过程
Windows架构设计将确定组件之间的依赖关系，直接支持项目计划和项目管理的活动，例如，细节化分，日程安排，工作分配，成本分析，风险管理和技能开发等；构架师还能协助估算项目成本，例如，体系架构决定使用第三方组件的成本，以及支持开发的所有工具的成本；构架师支持技术风险的管理，包括制定每一个风险的优先次序，以及确定一个恰当的风险缓解策略。
4.Windows架构设计对系统开发的指导性
Windows架构设计主要目标就是确保体系架构能够为设计人员和实现人员所承担的工作提供可靠的框架。很明显，这比简单的传送一个体系架构视图要复杂的多。为了确保最终体系架构的完整性，构架师必须明确的定义体系架构，因为它确定了体系架构的重要元素，例如系统的组件，组件之间的接口以及组件之间的通信。
构架师同时还必须定义恰当的标准和指导方针，它们将会引导设计人员和实现人员的工作。对开发过程活动采取恰当的架构回顾和评估，能够确保体系架构的完整性。这些QA（Quality Assurance,质量保障)活动的任务是确定体系架构的标准和指导方针的有效性。
5.Windows架构设计能够有效地管理复杂性
如今的系统越来越复杂，这种复杂性需要我们去管理。Windows体系架构通过构件及构件之间关系，描述了一个抽象的系统，因而提供了高层次的复杂管理的方法。同样，架构设计过程考虑组件的递归分解。这是处理一个大的问题的很好的一个方法，它可以把这个大问题分解成很多的小问题，再逐个的解决。
6.Windows架构设计为复用奠定了基础
Windows架构设计过程可以同时支持使用和建立复用资源。复用资源可以降低一个系统的成本，并且可以改进系统的质量，这些好处已经被证明。一个体系架构的建立，能够支持大粒度的资源复用。例如，体系架构的重要组件和它们之间的接口和质量，能够支持现货供应的组件，存在的系统和封装的应用程序等的选择，从而可以用来实现这些组件。
7.Windows架构设计能够降低维护费用
Windows架构设计过程可以在很多方面帮助我们降低维护费用。首先最重要的是架构设计过程要确保系统的维护人员是一个主要的涉众，并且他们的需求被作为首要的任务满足。一个被恰当文档化的体系架构不应该仅仅为了减轻系统的可维护性；构架师还应该确保结合了恰当的系统维护机制，并且在建立体系架构的时候还要考虑系统的适应性和可护充性。
8.Windows架构设计能够支持冲突分析
Windows架构设计的一个重要的好处是它可以允许我们在采取改变之前推断它所产生的影响。一个软件构架确定了主要的组件和它们之间的交互作用,两个组件之间的依赖性以及这些组件对于需求的可追溯性。有了这个信息，例如需求的改变等可以通过组件的影响来分析。同样的，改变一个组件的影响可以在依靠它的其他组件上分析出来。
作者简介：荔园微风，1981年生，高级工程师，浙大工学硕士，软件工程项目主管，做过程序员、软件设计师、系统架构师，早期的Windows程序员，Visual Studio忠实用户，C/C++使用者，是一位在计算机界学习、拼搏、奋斗了25年的老将，经历了UNIX时代、桌面WIN32时代、Web应用时代、云计算时代、手机安卓时代、大数据时代、ICT时代、AI深度学习时代、智能机器时代，我不知道未来还会有什么时代，只记得这一路走来，充满着艰辛与收获，愿同大家一起走下去，充满希望的走下去。
