架构蓝图--软件架构_4+1_视图模型(Philippe_Kruchten)

1架构蓝图--软件架构4+1视图模型---PhilippeKruchten引言我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。通过仔细地观察这些图例中的方框和箭头，不难发现作者努力地在单一视图中表达超过其表达限度的蓝图。方框是代表运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头是表示编译时的依赖关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。是否架构只需要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开发的单个方面：数据工程、运行效率、开发策略和团队组织等。有时架构并不能解决所有客户（或者说风险承担人，USC的命名）所关注的问题。许多作者都提及了这个问题：Garlan&Shaw1、CMU的Abowd&Allen、SEI的Clements。作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的集合。架构模型软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。Perry和Wolfe使用一个精确的公式来表达，该公式由Boehm做了进一步修改：软件架构＝{元素，形式，关系/约束}软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图1）：逻辑视图（LogicalView），设计的对象模型（使用面向对象的设计方法时）。过程视图（ProcessView），捕捉设计的并发和同步特征。物理视图（PhysicalView），描述了软件到硬件的映射，反映了分布式特性。开发视图（DevelopmentView），描述了在开发环境中软件的静态组织结构。架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例（usecases）或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来，将在下文中讨论。图1－4＋1视图模型2我们在每个视图上均独立地应用Perry&Wolf的公式，即定义一个所使用的元素集合（组件、容器、连接符），捕获工作形式和模式，并且捕获关系及约束，将架构与某些需求连接起来。每种视图使用自身所特有的表示法－蓝图（blueprint）来描述，并且架构师可以对每种视图选用特定的架构风格（architecturalstyle），从而允许系统中多种风格并存。我们将轮流的观察这五种视图，展现各个视图的目标：即视图的所关注的问题，相应的架构蓝图的标记方式，描述和管理蓝图的工具。并以非常简单的形式从PABX的设计中，从我们在Alcatel商业系统（AlcatelBusinessSystem）上所做的工作中，以及从航空运输控制系统（AirTrafficControlsystem）中引出一些例子―旨在描述一下视图的特定及其标记的方式，而不是定义这些系统的架构。4+1视图模型具有相当的普遍性，因此可以使用其他的标注方法和工具，也可以采用其他的设计方法，特别是对于逻辑和过程的分解。但文中指出的这些方法都已经成功的在实践中运用过。逻辑结构面向对象的分解逻辑架构主要支持功能性需求――即在为用户提供服务方面系统所应该提供的功能。系统分解为一系列的关键抽象，（大多数）来自于问题域，表现为对象或对象类的形式。它们采用抽象、封装和继承的原理。分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。我们使用Rational/Booch方法来表示逻辑架构，借助于类图和类模板的手段4。类图用来显示一个类的集合和它们的逻辑关系：关联、使用、组合、继承等等。相似的类可以划分成类集合。类模板关注于单个类，它们强调主要的类操作，并且识别关键的对象特征。如果需要定义对象的内部行为，则使用状态转换图或状态图来完成。公共机制或服务可以在类功能（classutilities）中定义。对于数据驱动程度高的应用程序，可以使用其他形式的逻辑视图，例如E-R图，来代替面向对象的方法（OOapproach）。逻辑视图的表示法逻辑视图的标记方法来自Booch标记法4。当仅考虑具有架构意义的条目时，这种表示法相当简单。特别是在这种设计级别上，大量的修饰作用不大。我们使用RationalRose?来支持逻辑架构的设计。图2－逻辑蓝图的表示法3逻辑视图的风格逻辑视图的风格采用面向对象的风格，其主要的设计准则是试图在整个系统中保持单一的、一致的对象模型，避免就每个场合或过程产生草率的类和机制的技术说明。逻辑结构蓝图的样例图3显示了TélicPABX架构中主要的类。图3－a.TélicPABX的逻辑蓝图b.空中交通系统的蓝图PABX建立终端间的通信连接。终端可以是电话设备、中继线（例如，连接到中央办公室）、连接线（PABX专线到PABX线)、电话专线、数据线、ISDN等等。不同的线路由不同的接口卡提供支持。线路controller对象的职责是在接口卡上对所有的信号进行解码和注入，在特定于接口卡的信号与一致性的小型事件集合之间进行相互转换：开始、停止、数字化等。controller对象同时承载所有的实时约束。该类派生出许多子类以满足不同的接口类型。terminal对象的责任是维持终端的状态，代表线路协调各项服务。例如，它使用numberingplan服务来解释拨号。conversation代表了会话中的一系列终端。conversation使用了TranslationService(目录、逻辑物理映射、路由),以及建立终端之间语音路径的ConnectionService。对于一个包含了大量的具有架构重要意义的类的、更大的系统来说，图3b描述了空中交通管理系统的顶层类图，包含8个类的种类（例如，类的分组）。进程架构过程分解进程架构考虑一些非功能性的需求，如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起－即在哪个控制线程上，对象的操作被实际执行。进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序（叫作processes）的逻辑网络，4它们分布在整个一组硬件资源上，这些资源通过LAN或者WAN连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。例如，独立的逻辑网络可能用于支持离线系统与在线系统的分离，或者支持软件的模拟版本和测试版本的共存。进程是构成可执行单元任务的分组。进程代表了可以进行策略控制过程架构的层次（即：开始、恢复、重新配置及关闭）。另外，进程可以就处理负载的分布式增强或可用性的提高而不断地被重复。软件被划分为一系列单独的任务。任务是独立的控制线程，可以在处理节点上单独地被调度。接着，我们可以区别主要任务、次要任务。主要任务是可以唯一处理的架构元素；次要任务是由于实施原因而引入的局部附加任务（周期性活动、缓冲、暂停等等）。它们可以作为AdaTask或轻量线程来实施。主要任务的通讯途径是良好定义的交互任务通信机制：基于消息的同步或异步通信服务、远程过程调用、事件广播等。次要任务则以会见或共享内存来通信。在同一过程或处理节点上，主要任务不应对它们的分配做出任何假定。消息流、过程负载可以基于过程蓝图来进行评估，同样可以使用哑负载来实现中空的进程架构，并测量在目标系统上的性能。正如Filareyetal.在他的Eurocontrol实验中描述的那样。进程视图的表示法我们所使用的进程视图的表示方法是从Booch最初为Ada任务推荐的表示方法扩展而来。同样，用来所使用的表示法关注在架构上具有重要意义的元素。(图4)图4－过程蓝图表示法我们曾使用来自TRW的UniversalNetworkArchitechureServices（UNAS0）产品来构建并实施过程和任务集合（包扩它们的冗余），使它们融入过程的网络中。UNAS包含SoftwareArchitectLifecycleEnvironment(SALE)工具，它支持上述表示方法。SALE允许以图形的形式来描述进程架构，包括对可能的交互任务通信路径的规格说明，正是从这些路径中自动生成对应的Ada或C++源代码。使用该方法来指定和实施进程架构的优点是易于进行修改而不会对应用软件造成太多的影响。进程视图的风格5许多风格可以适用于进程视图。例如采用Garlan和Shaw的分类法1,我们可以得到管道和过滤器（Pipesandfilters）,或客户端/服务器，以及各种多个客户端/单个服务器和多个客户端/多个服务器的变体。对于更加复杂的系统,可以采用类似于K.Birman所描述的ISIS系统中进程组方法以及其它的标注方法和工具。进程蓝图的例子图5－TélicPABX的过程蓝图（部分）所有的终端由单个的Termalprocess处理，其中Termalprocess由输入队列中的消息进行驱动。Controller对象在组成控制过程三个任务之中的一项任务上执行：Lowcycleratetask扫描所有的非活动终端(200ms)，将Highcycleratetask(10ms)扫描清单中的终端激活，其中Highcycleratetask检测任何重要的状态变化，将它们传递给Maincontrollertask，由它来对状态的变更进行解释,并通过向对应的终端发送消息来通信。这里Controller过程中的通信通过共享内存来实现。开发架构子系统分解开发架构关注软件开发环境下实际模块的组织。软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。系统的开发架构用模块和子系统图来表达，显示了输出和输入关系。完整的开发架构只有当所有软件元素被识别后才能加以描述。但是，可以列出控制开发架构的规则：分块、分组和可见性。大部分情况下，开发架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制。开发架构视图是各种活动的基础，如：需求分配、团队工作的分配（或团队机构）、成本评估和计划、项目进度的监控、软件重用性、移植性和安全性。它是建立产品线的基础。6开发蓝图的表示方法同样，使用Booch方法的变形，仅考虑具有架构意义的项。图5－开发蓝图表示方法来自Rational的Apex开发环境支持开发架构的定义和实现、和前文描述的分层策略，以及设计规则的实施。RationalRose可以在模块和子系统层次上绘制开发蓝图，并支持开发源代码(Ada、C++）进程的正向和反向工程。开发视图的风格我们推荐使用分层（layered）的风格，定义4到6个子系统层。每层均具有良好定义的职责。设计规则是某层子系统依赖同一层或低一层的子系统，从而最大程度地减少了具有复杂模块依赖关系的网络的开发量，得到层次式的简单策略。7图6－Hughes空中交通系统（HATS）的5个层开发架构的例子图6代表了加拿大的HughesAircraft开发的空中交通控制系统（AirTrafficControlsystem）产品线的5个分层开发组织结构。这是和图3b描述的逻辑架构相对应的开发架构。第一层和第二层组成了独立于域的覆盖整个产品线的分布式基础设施，并保护其免受不同硬件平台、操作系统或市售产品（如数据库管理系统）的影响。第三层为该基础设施增加了ATC框架，形成一个特定领域的软件架构（domain-specificsoftwarearchitecture）。使用该框架,可以在第四层上构建一个功能选择板。层次5则非常依赖于客户和产品,包含了大多数用户接口和外部系统接口。72个子系统分布于5个层次上，每层包含了10至50个模块，并可以在其他蓝图上表示。物理架构软件至硬件的映射物理架构主要关注系统非功能性的需求，