《软件构架》word版

1、.软件构架软件构架2020-04-19 09：44软件架构软件架构software architecture是一系列相关的抽象形式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描绘的对象是直接构成系统的抽象组件。各个组件之间的连接那么明确和相对细致地描绘组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比方详细某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_计算机科学来实现。软件体系构造是构建计算机软件理论的根底。与建筑师设定建筑工程的设计原那么和目的，作为绘图员画图的根底一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际

2、系统设计方案的根底。软件构架是一个容易理解的概念，多数工程师尤其是经历不多的工程师会从直觉上来认识它，但要给出准确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些详细的特征。在"软件构架简介"中，David GArlan和Mary Shaw认为软件构架是有关如下问题的设计层次："在计算的算法和数据构造之外，设计并确定系统整体构造成为了新的问题。构造问题包括总体组织构造和全局控制构造；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。"GS93但构架不仅是构造；IEEE

3、Working Group on Architecture把其定义为"系统在其环境中的最高层概念"IEEE98。构架还包括"符合"系统完好性、经济约束条件、审美需求和款式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进展整体考虑，即同时注重对外部的考虑。在Rational Unified ProcESs中，软件系统的构架在某一给定点是指系统重要构件的组织或构造，这些重要构件通过接口与不断减小的构件与接口所组成的构件进展交互。从和目的、主题、材料和构造的联络上来说，软件架构可以和建筑物的架构相比较。一个软件架构师需要有广泛的软件理论知

4、识和相应的经历来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。是一般而言，软件系统的架构ArchitECture有两个要素：·它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由元件组成的，而这些元件如何形成、互相之间如何发生作用，那么是关于这个系统本身构造的重要信息。详细地说，就是要包括架构元件Architecture Component、联结器Connector、任务流TASk-flow。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结

5、器那么描绘这些元件之间通讯的途径、通讯的机制、通讯的预期结果，任务流那么描绘系统如何使用这些元件和联结器完成某一项需求。·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开场进展详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。历史早在1960年代，诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在Rational Software Corporation和MiCROSof

6、t内部的相关活动，软件架构这个概念开场越来越流行起来。卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做Software Architecture perspective on an emerging DIscipline的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作那么主要集中于架构风格、架构描绘语言以及动态架构。计算机软件的历史开场于五十年代，历史非常短暂，而相比之下建筑工程那么从石器时代就开场了，人类在几千年的建筑设计理论中积

7、累了大量的经历和教训。建筑设计根本上包含两点，一是建筑风格，二是建筑形式。独特的建筑风格和恰中选择的建筑形式，可以使一个独一无二。下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个宏大的石级堆垒而上，九十一级台阶象征着四季的天数夺路而出，塔顶的神殿耸入云天。所有的数字都如日历般严谨，风格雄浑。难以想象这是石器时代的建筑物。图1、位于墨西哥Chichen-Itza在玛雅语中chi意为嘴chen意为井的古玛雅建筑。摄影：作者软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必

8、须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们We shape our buildings,and afterwaRDS our buildings shape us。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见一样的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的创始

9、人之一Louis Sullivan也认为形式应当服从于功能FORMs follows function。几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的，当然就是形式理论和XP理论。架构的目的是什么正如同软件本身有其要到达的目的一样，架构设计要到达的目的是什么呢?一般而言，软件架构设计要到达如下的目的：·可靠性Reliable。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。·平安行Secure。软件系统所承担的交易的商业价值极高，系统的平安性非常重要。·可扩展性SCAlable。软件必须可以在用户的使

10、用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。·可定制化CuSTomizable。同样的一套软件，可以根据客户群的不同和市场需求的变化进展调整。·可扩展性Extensible。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进展功能和性能的扩展·可维护性MAIntainable。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费·客户体验Customer Experience。软件系统必须易于使用。·市

11、场时机Time to Market。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比方用户界面，数据库，外部系统接口，商业逻辑元件，等等。比方下面就是笔者亲身经历过的一个软件系统的逻辑架构图图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比方WEB效劳器层次中有HTML效劳元件、Session效劳元件、平安效劳元件、系统管理元件等。·物理架构、软件元件

12、是怎样放到硬件上的。比方下面这张物理架构图描绘了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理效劳器、WEB效劳器、应用效劳器、报表效劳器、整合效劳器、存储效劳器、主机等等。图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵敏性、性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统

13、的可扩展性、可靠性、强壮性、灵敏性、性能等做出奉献，是非常重要的信息。其次，进展软件设计需要做出的决定中，必然会包括逻辑构造、物理构造，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。根据作者的经历，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比方一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。构架描绘为了讨论和分析软件构架，必须首先定义构架表示方式，即描绘构架重要方面的方式。在Rational Unified Process中，软件构架文档记录有这种描绘。构架视图我们决定

14、以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众例如最终用户、设计人员、管理人员、系统工程师、维护人员等所关注的特定方面。构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式PW92，由此记录主要的构造设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。典型的构架视图集构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明"在构架方面具有重要意义"的模型元素。在Rational Unified Process中，您将从一个典型的视图集开场，

15、该视图集称为"4+1视图模型"KRU95。它包括：用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。施行视图：包括施行模型及其从模块到包和层的组织形式的概览。同时还描绘了将逻辑视图中的包和类向施行视图中的包和模块分配的情况。它是施行模型的子集。进程视图：包括所涉及任务进程和线程的描绘，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要

16、该视图。在Rational Unified Process中，它是设计模型的子集。配置视图：包括对最典型的平台配置的各种物理节点的描绘以及将任务来自进程视图向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、平安视图、数据视图等等。对于简单系统，可以省略4+1视图模型中的一些视图。构架重点虽然以上视图可以表示系统的整体设计，但构架只同以下几个详细方面相关：模型的构造，即组织形式，例如分层。根本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。几个关键场景，它们表示了

17、整个系统的主要控制流程。记录模块度、可选特征、产品线状况的效劳。构架视图在本质上是整体设计的抽象或简化，它们通过舍弃详细细节来突出重要的特征。在考虑以下方面时，这些特征非常重要：系统演进，即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量，例如性能、可用性、可移植性和平安性。向团队或分包商分配开发工作。决定是否包括市售构件。插入范围更广的系统。构架形式构架形式是解决复发构架问题的现成形式。构架框架或构架根底设施中间件是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或根底设施中进展解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。构架形式例如BU

18、S96根据构架形式最适用的系统的特征将其分类，其中一个类别处理更普遍的构造问题。下表显示了BUS96中所提供的类别和这些类别所包含的形式。类别形式构造层管道和过滤器黑板分布式系统代理交互系统模型-视图-控制器表示-抽象-控制自适应系统反射微核软件构架是一个容易理解的概念，多数工程师尤其是经历不多的工程师会从直觉上来认识它，但要给出准确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些详细的特征。在"软件构架简介"中，David Garlan和Mary Shaw认为软件构架是有关如下问题的设计层次："在计算的算法和数据构造之外，设计并

19、确定系统整体构造成为了新的问题。构造问题包括总体组织构造和全局控制构造；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。"GS93但构架不仅是构造；IEEE Working Group on Architecture把其定义为"系统在其环境中的最高层概念"IEEE98。构架还包括"符合"系统完好性、经济约束条件、审美需求和款式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进展整体考虑，即同时注重对外部的考虑。在Rational Unified Process中，软件系统

20、的构架在某一给定点是指系统重要构件的组织或构造，这些重要构件通过接口与不断减小的构件与接口所组成的构件进展交互。为说明其含义，下面将详述其中的两个；完好说明请参见BUS96。形式以以下广泛使用的形式来表示：形式名环境问题影响，描绘应考虑的不同问题方面解决方案根本原理结果环境例如形式名环境需要进展构造分解的大系统。问题必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见效劳问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否那么要在不同的构件中屡次处理一样的问题可能会不一致。影响系统的某些部分应当是可交换的构件中的变化不应波动相似的责任应归为一组构件大小-复杂构件可

21、能要进展分解解决方法将系统分成构件组，并使构件组形成层叠构造。使上层只使用下层决不使用上层提供的效劳。尽量不使用非紧邻下层提供的效劳不跳层使用效劳，除非中间层只添加通过构件。例如：1.通用层严格的分层构架规定设计元素类、构件、包、子系统只能使用下层提供的效劳，效劳可以包括事件处理、错误处理、数据库访问等等。相对于记录在底层的原始操作系统级调用，它包括更明显的机制。2.业务系统层上图显示了另一个分层例如，其中有垂直特定应用层、程度层和根底设施层。注意：此处的目的是采用非常短的业务"烟囱"并实现各种应用程序间的通用性。否那么，就可能有多个人解决同一问题，从而导致潜在的分歧。有关

22、该形式的深化讨论，请参见指南：分层。形式名黑板环境没有解决问题确实定方法算法或方法不可行的领域。例如AI系统、语音识别和监视系统。问题多个问题解决参谋知识参谋必须通过协作来解决他们无法单独解决的问题。各参谋的工作结果必须可以供所有其他参谋访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。影响知识参谋参与解决问题的顺序不是确定的，这可能取决于问题解决策略不同参谋的输入结果或部分解决方案可能有不同的表示方式各参谋并不直接知道对方的存在，但可以评估对方发布的工作解决方法多名知识参谋都可访问一个称为"黑板"的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的参谋。激活后，参谋查看黑板，以确定它是否能参与解决问题。假设参谋决定它可以参与，控制对象就可以允许参谋将其部分或最终解决方案放置于黑板上。例如：以上显示了使用UML建模的构造或静态视图。它将成为参数化协作的一部分，然后会绑定到实参上对形式进展实例化。构架风格软件构架或仅是构架视图可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。款式可以通过一组形式或通过选择特定构