架构蓝图软件架构-4+1-视图模型.pdfVIP

架构蓝图 --软件架构 4+1 视图模型 本 文基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。 使用多重视图允许独立地处理各 风险承担人 ：最终用户、开发人员、系统 工程师、项目 经理等所关注的问题，并且能够独立地处理功能性和非功能性 需求。本文分别对五种视图进行了描述，并同时给出了捕获每种视图的表示 方法。这些视图使用以架构 为中心的、场景驱动以及迭代开发过程来进行设 计。 引言 我们已经看到在许多文章和书籍中，作者欲使用单张视图来捕捉所有的系统架构要点。通过仔细地观察 这些图例中的方框和箭头，不难发现作者努力地在单一视图中 表达超过其表达限度的蓝图。方框是代表 运行的程序吗？或者是代表源代码的程序块吗？或是物理计算机吗？或仅仅是逻辑功能的分组吗？箭头 是表示编译时的依赖 关系吗？或者是控制流吗？或是数据流吗？通常它代表了许多事物。是否架构只需 要单个的架构样式？有时软件架构的缺陷源于过早地划分软件或过分的强调软件开 发的单个方面：数据 工程、运行效率、开发策略和团队组织等。有时架构并不能解决所有 客户 （或者说 风险承担人 ， USC 的命名）所关注的问题。许多作者都提及了这个问题： Garlan Shaw1、CMU 的 Abowd Allen 、 SEI 的 Clements。作为补充，我们建议使用多个并发的视图来组织软件架构的描述，每个视图仅用来描 述一个特定的所关注的方面的集合。 架构模型 软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而 满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。 Perry 和 Wolfe 使用一个精确的公式来表达，该公式由 Boehm 做了进一步修改： 软件架构 ＝ { 元素，形式，关系 / 约束} 软件架构涉及到抽象、分解和组合、风格和美学。我们用由多个视图或视角组成的模型来描述它。为了 最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图（请对照图 1）： ? 逻辑视图（ Logical View ），设计的对象模型（使用面向对象的设计方法时）。 ? 过程视图（ Process View），捕捉设计的并发和同步特征。 ? 物理视图（ Physical View），描述了软件到硬件的映射，反映了分布式特性。 ? 开发视图（ Development View），描述了在开发环境中软件的静态组织结构。 架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例 （use cases）或场景 (scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来， 将在下文中讨论。 图 1 － 4 ＋1视图模型 我 们在每个视图上均独立地应用 Perry Wolf 的公式，即定义一个所使用的元素集合（组件、容器、连 接符），捕获工作形式和模式，并且捕获关系及约束，将架构与某些需求连接起来。每种视图使用自身 所特 有的表示法－蓝图（ blueprint ）来描述，并且架构师可以对每种视图选用特定的架构风格 （architectural style），从而允许系统中多种风格并存。 我们将轮流的观察这五种视图，展现各个视图的目标：即视图的所关注的问题，相应的架构蓝图的标记 方式，描述和管理蓝图的工具。并以非常简单的形式从 PABX 的设计中，从我们在 Alcatel 商业系统 （Alcatel Business System）上所做的工作中，以及从航空运输控制系统（ Air Traffic Control system ）中 引出一些例子 ―旨在描述一下视图的特定及其标记的方式，而不是定义这些系统的架构。 4+1视图模型具有相当的 普遍性 ，因此可以使用其他的标注方法和工具，也可以采用其他的设计方 法，特别是对