软件架构视图—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 次迭代之后，结构变得稳定：主要的抽象都已被到。⼦系统和过程都已经完成，以及所有的接⼝都已经实现。接下来则是软件设计的范畴，这个阶段可能也会⽤到相似的⽅法和过程。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。