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