4+1系统架构模型

本文转自CSDN

前言

本文参考IBM官方的软件架构模式，并参考UML视图建模，将软件架构视图—4+1模式进行了小结。关于每种视图的参考实例，会在随后继续补充进去。

架构模型

一、软件架构

软件架构概念：将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。用来处理软件高层次结构的设计和实施。

软件架构 ＝{元素，形式，关系/约束}

软件架构涉及到抽象、分解和组合、风格和美学。用由多个视图或视角组成的模型来描述软件架构，该方法称为多重视图方法。

使用多重视图的目的：

基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。

1、使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，

2、并且能够独立地处理功能性和非功能性需求。

 

多重视图方法从根本上说是需求种类的复杂性所致。

 

二、需求背景

1、需求的三个层次

软件需求包括3个不同的层次――业务需求、用户需求和功能需求。

业务需求 （Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。

用户需求 （user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求 （functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。 注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。

系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

业务规则 包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁 能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作 文档，其实，SRS还可以是包含需求信息的数据库 或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他 相关的项目功能都要用到 SRS。

除此之外，对于需求层次，我们还有其它的分法：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。在此不做一一介绍。

除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。

质量属性 （quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。

约束 （constraint）限制了开发人员设计和构建系统时的选择范围。约束，在产品的架构设计中，是需要被首先考虑的问题。

如果说产品的功能代表了产品的能力，那么产品的质量属性代表了产品的品质，产品的约束代表了产品必须去满足的或者适应的条件！用人说“用户体验”是 产品的灵魂，对于个人级的软件这么说或许很恰当，当对于企业级甚至是行业级的产品，其灵魂有两个：一个是产品带个用户的价值，另一个是产品的品质，简单的 说，就是价值和品质。但其成为一个产品的前提应该是满足约束，否则就不应该设计、开发、进入市场而成为一个垃圾。

三、4+1架构视图

架构视图是对从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。

架构要涵盖的内容和决策太多，采用"分而治之"的办法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供方便。

为了最终处理大型的、富有挑战性的架构，该模型包含五个主要的视图：

• 逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
• 过程视图（Process View），捕捉设计的并发和同步特征。
• 物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
• 开发视图（Development View），描述了在开发环境中软件的静态组织结构。
• 场景视图

3.1 逻辑视图（LogicalView）

 逻辑试图用来描述系统的功能需求，即在为用户提供服务方面系统所应该提供的功能。在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问

题领域（ProblemDefinition)。在面向对象技术中，表现为对象或对象类的形式，采用抽象、封装和继承的原理。用对象模型来代表逻辑视图，可以用类图（Class Diagram）来描述逻辑视图。借助于类图和类模板的手段 ，类图用来显示一个类的集合和它们的逻辑关系：关联、使用、组合、继承等。相似的类可以划分成类集合。类模板关注于单个类，它们强调主要的类操作，并且识别关键的对象特征。

逻辑视图的表示法：
　　构件(Components)：类、类服务、参数化类、类层次 
　　连接件(Connectors)：关联、包含聚集、使用、继承、实例化 
　　 

逻辑视图的风格采用面向对象的风格，其主要的设计准则是试图在整个系统中保持单一的、一致的对象模型，避免就每个场合或过程产生草率的类和机制的技术说明。

 

3.2   过程视图

过程视图（ProcessView），又称“进程视图”，又称“处理视图”。

过程架构考虑一些非功能性的需求，如性能和可用性。它解决并发性、分布性、系统完整性、容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起，即定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。过程视图侧重系统的运行特性。服务于系统集成人员，方便后续性能测试

Ø 构件：进程、简化进程、循环进程

Ø 连接件：消息、远程过程调用（RPC）、双向消息、事件广播 。

过程视图：关注进程、线程、对象等运行时概念，以及相关的并发、同步和通信等问题。

进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序（叫作"processes"）的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过 LAN 或者 WAN 连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。

接着，我们可以区别主要任务、次要任务。主要任务是可以唯一处理的架构元素；次要任务是由于实施原因而引入的局部附加任务（周期性活动、缓冲、暂停等等）。主要任务的通讯途径是良好定义的交互任务通信机制：基于消息的同步或异步通信服务、远程过程调用、事件广播等。次要任务则以会见或共享内存来通信。在同一过程或处理节点上，主要任务不应对它们的分配做出任何假定。

3.3  物理视图

物理视图（PhysicalView）主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。物理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性能（吞吐量）和可伸缩性。

软件在计算机网络或处理节点上运行，被识别的各种元素（网络、过程、任务和对象），需要被映射至不同的节点；我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。

物理视图的表示法

Ø  构件：处理器、计算机、其它设备

Ø  连接件：通信协议等

 

 

3.4开发视图

开发视图（DevelopmentView），描述了在开发环境中软件的静态组织结构，即关注软件开发环境下实际模块的组织，服务于软件编程人员。将软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。

系统的开发架构用模块和子系统图来表达，显示了"输出"和"输入"关系。完整的开发架构只有当所有软件元素被识别后才能加以描述。但是，可以列出控制开发架构的规则：分块、分组和可见性。

开发视图的风格通常是层次结构，每个层为上一层提供良好定义的接口，层次越低，通用性越好。

开发视图的表示方法：

Ø  构件：模块、子系统、层

Ø  连接件：参照相关性、模块/过程调用

大部分情况下，开发架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所 带来的限制。开发架构视图是各种活动的基础，如：需求分配、团队工作的分配（或团队机构）、成本评估和计划、项目进度的监控、软件重用性、移植性和安全 性。它是建立产品线的基础。

 

3.5场景视图

场景视图，又称“用例视图”，它综合所有的视图。用于刻画构件之间的相互关系，将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系，也可以描述不同视图间的构件关系。

四种视图的元素通过一组重要场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。在某种意义上场景是最重要的需求抽象，它们的设计使用对象场景图和对象交互图来表示。

场景视图是其他视图的冗余（因此"＋1"），但它起到了两个作用：

• 作为一项驱动因素来发现架构设计过程中的架构元素。
• 作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明，又作为架构原型测试的出发点。

作为一项驱动因素，源于迭代开发中有场景驱动（scenario-driven）方法。场景驱动方法认为系统大多数关键的功能以场景（或 use cases）的形式被捕获。关键意味着：最重要的功能，系统存在的理由，或使用频率最高的功能，或体现了必须减轻的一些重要的技术风险。

关于驱动开发方法：

开始阶段:

• 基于风险和重要性为某次迭代选择一些场景。场景可能被归纳为对若干用户需求的抽象。
• 形成"稻草人式的架构"。然后对场景进行"描述"，以识别主要的抽象（类、机制、过程、子系统）。
• 所发现的架构元素被分布到 4 个蓝图中：逻辑蓝图、进程蓝图、开发蓝图和物理蓝图。
• 然后实施、测试、度量该架构，这项分析可能检测到一些缺点或潜在的增强要求。
• 捕获经验教训。

循环阶段:下一个迭代过程开始进行：

• 重新评估风险，
• 扩展考虑的场景选择板。
• 选择能减轻风险或提高结构覆盖的额外的少量场景，

然后:

• 试着在原先的架构中描述这些场景。
• 发现额外的架构元素，或有时还需要找出适应这些场景所需的重要架构变更。
• 更新4个主要视图：逻辑视图、进程视图、开发视图和物理视图。
• 根据变更修订现有的场景。
• 升级实现工具（架构原型）来支持新的、扩展了的场景集合。
• 测试。如果可能的话，在实际的目标环境和负载下进行测试。
• 然后评审这五个视图来检测简洁性、可重用性和通用性的潜在问题。
• 更新设计准则和基本原理。
• 捕获经验教训。

然后:

• 试着在原先的架构中描述这些场景。
• 发现额外的架构元素，或有时还需要找出适应这些场景所需的重要架构变更。
• 更新4个主要视图：逻辑视图、进程视图、开发视图和物理视图。
• 根据变更修订现有的场景。
• 升级实现工具（架构原型）来支持新的、扩展了的场景集合。
• 测试。如果可能的话，在实际的目标环境和负载下进行测试。
• 然后评审这五个视图来检测简洁性、可重用性和通用性的潜在问题。
• 更新设计准则和基本原理。
• 捕获经验教训。

终止循环

为了实际的系统，初始的架构原型需要进行演进 。较好的情况是在经过2 次或 3 次迭代之后，结构变得稳定：主要的抽象都已被找到。子系统和过程都已经完成，以及所有的接口都已经实现。接下来则是软件设计的范畴，这个阶段可能也会用到相似的方法和过程。

 

场景视图的表示法：

场景表示法与组件逻辑视图非常相似，但它使用过程视图的连接符来表示对象之间的交互，对象实例使用实线来表达。

备注：以上所有视图的实例，在后续的文章中有附上。

四、UML中的图和各视图的对应关系

n 场景视图：用例图

n 逻辑视图：类图和对象图

n 开发视图：类图和组件图

n 进程视图：顺序图、协作图、状态图、活动图、组件图

n 部署视图：部署图

五、架构的文档化

架构设计中产生的文档可以归结为两种：

• 软件架构文档，其结构遵循"4+1"视图（请对照下图3，一个典型的提纲）
• 软件设计准则，捕获了最重要的设计决策。这些决策必须被遵守，以保持系统架构的完整性。 
  图 3 －软件架构文档提纲
   

 

结束语

无论是否经过一次本地定制的和技术上的调整，"4＋1"视图都能在许多大型项目中成功运用。事实上，它允许不同的"风险承担人"找出他们就软件架构 所关心的问题。系统工程师首先接触物理视图，然后转向进程视图；最终用户、顾客、数据分析专家从逻辑视图入手；项目经理、软件配置人员则从开发视图来看 待"4＋1"视图。 在 Rational 和其他地方，提出并讨论了其他系列视图，例如 Meszaros(BNR)、Hofmeister。Nord 和 Soni(Siemenms)、Emery 和 Hilliard（Mitre），但我们发现其他视图通常可以归入我们所描述的 4 个视图中的一个。例如Cost&Schedule 视图可以归入开发视图，将一个数据视图归入一个逻辑视图，以及将一个执行视图归入进程视图和物理视图的组合。