目的
  • 根据从类似系统或在类似问题域中获得的经验定义系统的候选体系结构。
  • 定义系统的体系结构模式、关键机制和建模约定。
角色:软件设计人员 
频率:可在“先启”阶段进行,也可在此阶段之外进行。应该在第一个“精化”迭代中进行。当要探索对软件体系结构的重要更改或补充时,可以在以后的迭代中重复进行。

步骤
输入工件:   生成的工件:  
工具向导:  
更多信息: 

工作流程明细:  

体系结构分析侧重于定义候选体系结构以及限制系统中将使用的体系结构方法。它依赖于收集类似系统或问题领域中获得的经验来限制并集中体系结构,使工作不要浪费在体系结构重新发现上。在已经有很好定义的体系结构的系统中,体系结构分析可以省略;体系结构分析主要在开发新的和没有先例的系统时很有用。

制作体系结构概述 回到页首

目的  通过探索并评估高级别体系结构选项来协助系统预测。 
较早地将对目标系统的高级别结构的理解传达给资助者、开发团队和其它涉众。

体系结构概述在项目生命周期的早期创建,可能早在先启阶段就创建。它反映早期的决策以及对实施远景的有效假设,以及关于物理和逻辑体系结构的决策和系统的非功能要求。它由软件设计人员(通常与项目资助者合作)制作,采用的形式是非正式的、有丰富图片的故事板或形象图。从概念上讲,它说明提议的解决方案的基本性质,传递主要思想并包含主要构造块。体系结构概述的正式程度视具体的项目而定。例如,在较大的、正式度较高的项目中,可能有必要在“软件体系结构”文档的适当部分记录体系结构概述,这样它就可以接受正式复审。

此时,体系结构概述是临时的初审。在可执行体系结构原型已经使体系结构(包括设计、实施和部署问题)有效前,请不要根据体系结构概述图付诸实施。

请考虑根据参考体系结构、其它体系结构模式或其它体系结构资产来创建体系结构。

考虑您是否要优化并维护体系结构概述图以充当交流载体。

许多系统都被限制在现有的硬件和软件环境中进行开发和部署;对于这些系统,软件设计人员将收集关于当前环境的信息。

例如,在电子商务系统开发中,以下信息是相关的:

  • 现有网络的逻辑和物理设计
  • 现有的数据库和数据库设计
  • 现有的 Web 环境(服务器、防火墙等等)
  • 现有的服务器环境(配置、软件版本、计划的升级)
  • 现有的标准(网络、命名、协议等等)

这样的信息可以用文本的形式记录,也可以记录在部署模型中。

调查可用资产 回到页首

目的  确定可能与项目相关的资产。
分析资产与项目要求之间的适合情况和差距。
决定是否将系统的领域基于资产之上。
找到并列出可能可以在项目中重复使用的资产。
执行初步的评估,以确保潜在可获得必要的支持。

您需要了解考虑资产的环境的要求以及要求的系统范围和一般功能。在组织资产库和行业资料中搜索,找到资产或类似的项目。有几类资产需要考虑,如(但不限于)行业模型、框架、类和经验。您将需要评估可用的资产是否有助于解决当前项目的关键挑战,以及它们是否与项目的限制条件兼容。

您将希望分析资产和客户需求之间的适合程度,考虑是不是有可以协商的需求(以使资产可用)。

请确保您确实评估了是否可以修改或扩展资产以满足需求,以及会有怎样的代价(从采用资产的成本、风险和功能的角度)。

最后,您还需要大体上决定是否使用一个或多个资产并记录这一决策的理由。

定义子系统的高级别组织 回到页首

目的 创建“设计模型”的初始结构。

当重点放在执行先启阶段的体系结构合成上时,这一步骤被排除在该活动之外。

一般情况下,设计模型是分层组织的 - 常见的体系结构模式,以适合大中型系统。层数不是固定的,但各个情况下都不相同。

在体系结构分析期间,您通常关注两个高级层,即应用特定于业务层。这就是子系统的高级别组织的意义。其它的低级别层在活动:合并现有的设计元素中考虑。如果您使用的是特定的体系结构模式,子系统围绕着该模式的体系结构模板进行定义。

有关分层的更多信息,请参阅指南:分层

确定关键抽象 回到页首

目的 确定系统必须处理的关键抽象(),为分析作准备。

当重点放在执行体系结构合成时,这一步骤必须执行并达到适当程度,以指导软件设计人员为工件:体系结构概念验证的构造选择资产,以及支持代表性的使用方案。

需求和活动通常会揭示系统必须能够处理的关键概念;这些概念自我表明为关键的设计抽象。因为已经完成的工作,活动:用例分析期间就没有必要再重复确定工作了。

您可以通过确定初步实体分析类,利用现有的知识,根据系统的一般知识(如“要求”、词汇表,特别是领域模型(如果您有的话))来代表这些关键抽象。

当您定义关键抽象时,请同时定义实体类之间存在的任何关系。在一个或数个类图中展示关键抽象,并为每个抽象创建一个简短描述。根据领域和系统的创新程度,可能已经存在了记录许多对系统建模所必需的关键抽象的分析模式。使用这样的模式(应该已经在领域中成功使用)将大大减轻了确定必须表示的重要概念的智力负担。[FOW97a] 展示一些分析模式,这些分析模式可以立即用于业务系统建模,但可能也可以在其它环境中应用。另一个示例是“Object Management Group”(OMG),它也尝试通过其“领域技术委员会”及其相关的任务工作组的工作为许多领域定义接口和协议。这一工作不可避免地会引向确定领域中的重要抽象。

此时确定的分析类将可能在项目过程中发生更改和演变。本步骤的目的不是为了确定一组能在设计过程中存留下来的类,而是确定系统必须处理的关键概念。不要在这个初始阶段花太多时间详细描述实体类,因为存在这样的风险:您将确定的类和关系实际上并不是用例所需要的。请记住,您在查看用例时将找到更多的实体类和关系。

确定定型的交互 回到页首

本步骤仅在“先启”期间作为工作流程明细:执行体系结构合成的一部分执行“体系结构分析”(此活动)时被包含。

本步骤的目的是确定系统中关键抽象之间的、这样的交互:这些交互可以表现系统中的重要种类的活动的特征,或者能够成为它们的代表。这些交互作为“用例实现”被记录。

制作部署概述 回到页首

目的

为评估实施系统的生存能力提供基础。
获得对系统的地理分发和操作复杂性的了解。
为早期工作和成本估算提供基础。

制作关于软件如何部署的高级别概述。例如,确定系统是否需要进行远程访问,或者是否有暗示跨多个节点分发的要求。要考虑的一些信息来源有:

  • 用户(在位置上),在“用户概要文件”(“远景”中)和用例(“用例模型”中)中定义
  • 服务级别要求(在“附加规范”中)
  • 限制条件(在“附加规范”中,例如与旧系统对接的要求)

如果要求不一般的分发系统,那么就可以使用“部署模型”来记录节点之间的关系。这应该包括临时给节点分配组件和数据,以及表明用户如何访问那些要访问数据的组件。节点和连接的详细规范被延迟 - 除了它们对于估计或评估生存能力非常重要的场合以外。可以使用现有的资产(如果有合适的资产)。虽然这是项目中制作的第一个部署模型,而且它是快速地、在较高级别制作的,但是它还是可能会确定实际的硬件和软件产品(如果它们是已知的话,或者如果此时作出这些选择决策很重要的话)。

验证部署模型支持执行典型用例的用户(特别是远程用户 - 如果要求的话),而同时能满足非功能要求和限制条件。验证节点和连接足够支持不同节点上的组件之间以及组件和它们存储的数据之间的交互。

确定分析机制 回到页首

目的 定义设计人员用来使它们的对象“有生命”的分析机制和服务。

当重点放在执行先启阶段的体系结构合成上时,这一步骤被排除在该活动之外。

分析机制可用自上而下(演绎法)或者自下而上(进展中发现)的方法来确定。在自上而下模式中,经验让软件设计人员知道领域中存在某些问题,需要有某些种类的解决方案。在分析期间可能会表现为机制的常见体系结构问题的示例有:持久性、事务管理、故障管理、消息传递和推理引擎。所有这些问题的共同方面是每一个都是广泛的系统类的一般功能,而且每一个提供的功能都能与基本的应用程序功能交互或者支持基本的应用程序功能。分析机制支持系统的基本功能要求中要求的功能,而不管它的部署平台或实施语言是什么。分析机制也可以用许多不同的方法进行设计和实施;一般情况下,会有多个设计机制与每个分析机制相对应,而且可能会有多种方法实施每个设计机制。

自下而上的方法用在分析机制最终生成的地方 - 当软件设计人员看见(也许一开始很微弱)各种问题的一组解决方案中显露出一个共同的主题时,分析机制得以创建。有必要提供让不同线程中的元素将它们的时间同步的方法,也有必要有分配资源的共同方法。简化分析语言的分析机制从这些模式中显露出来。

确定分析机制意味着您确定存在着一个共同的、可能是暗含的(即系统要求暗示)子问题,并且您将它命名。一开始,名称可能就是现有的名称;例如软件设计人员认识到系统将要求一个持久性机制。最后,该机制将通过类集的协作来实施(请参阅 [BOO98]),其中一些类不直接提供应用程序功能,它们的存在只是为了支持机制。这些支持类经常位于分层体系结构的中低层,从而向所有应用程序级别的类提供共同的支持服务。

如果确定的子问题足够普通,那么或许会存在一个模式,机制可以从该模式实例化 - 通过绑定现有的类并根据模式的要求实施新的类。用这种方式制作的分析机制将是抽象的,并需要在设计和实施中进一步改进。

关于更多信息,请参阅概念:分析机制

复审结果 回到页首

目的 确保体系结构分析结果的完整性和一致性。

如“体系结构分析”作出的结论那样,复审已经确定的体系结构机制、子系统、程序包和类,以确保它们的完整性和一致性。因为“体系结构分析”的结果是初步的,并且相对不太正式,因此复审也应该是不正式的。场景或用例可以用于验证在数个级别作出的体系结构选择 - 从业务透视图向下直到发生的具体交互。

有关评估此活动的结果的更多信息,请参阅检查点:软件体系结构文档 - 体系结构分析考虑事项



Rational Unified Process   2003.06.15