主题

概述 回到页首

在总体上,系统确实是基于体系结构的,因为:

  • 体系结构看上去是稳定的。

    稳定性的需要是由构造阶段的性质所定的:项目通常在构造阶段展开,增加将并行工作的开发人员,并与生产产品的其他开发人员随意沟通。如果体系结构不稳定,那就不能实现构建中所需的独立性和并行性等级。

    稳定的体系结构是极其重要的。不要误解为“相当接近就足够好了”- 不稳定就是不稳定,最好使体系结构正确,并将构建的开始延迟,而不是使其继续下去。当开发人员尝试建立体系结构功能时,试图修复体系结构时涉及的协调问题将会轻易地抵销由于加快进度安排所带来的所有显而易见的好处。在构建期间更改体系结构会有广泛影响:它们往往昂贵、具破坏性并使士气低落。

    评估体系结构稳定性的实际困难在于“您并不了解什么是您所不知道的”;稳定性是相对于预期的变更来评估的。因此,稳定性本质上是主观的评估。然而,我们能将这种主观性建立在不仅仅是推测的基础之上。通过考虑“体系结构上重要的”场景(用例子集,表示系统必须支持的技术上最具挑战性的行为)来开发体系结构本身。评估体系结构的稳定性包括确保体系结构具有广泛的覆盖性,以保证在体系结构发展中将不会出现“意外”。

    过去在体系结构方面的经验也可提供很好的指示:若体系结构的更改比率低,且在包含新场景的情况下仍保持低更改比率,则有充分的理由相信该体系结构是稳定的。相反地,若每一个新场景都引起体系结构的更改,则该体系结构仍处于发展中且还未确保基线的设立。

  • 系统的复杂度与它所提供的功能匹配。
  • 给定以下角色的技能和经验,概念上的复杂性必须相当:
    • 用户
    • 操作员
    • 开发人员
  • 系统具有一个一致而内聚的体系结构
  • 组件的数量和类型是合理的
  • 系统具有一致的系统范围的安全设施。所有的安全组件协同工作以保护系统。
  • 系统将符合它的可用性目标。
  • 如果在必需时间段内发生故障,体系结构将允许恢复系统。
  • 系统基于的产品和技术与它期望的使用期匹配吗?
    • 可使用旧技术安全地建立短期的临时(策略上的)系统,因为它不久就将被丢弃。
    • 期望长期使用的系统(大多数系统)应该用最新技术和方法建立,以便能够进行维护和扩展,以支持未来的需求。
  • 体系结构定义清晰的接口,以便能够对并行团队开发进行划分。
  • 模型元素的设计者能充分了解体系结构,以成功地设计和开发模型元素。
  • 封装方法减少了复杂度并增进了理解。
  • 将包定义为包的内部是高内聚的,而包本身是松耦合的。
  • 已考虑在共同的应用领域内使用相似的解决方案。
  • 对问题领域有一般性了解的人员可以很容易地理解建议的解决方案。
  • 团队中的所有人员对由软件设计人员提出的体系结构持一致看法。
  • 软件体系结构文档是现行的。
  • 已遵循设计指南。
  • 所有技术风险或者已减轻,或者在意外事件计划中已解决。已记录发现的新风险并分析了它们的潜在影响。
  • 已满足关键的性能需求(确定的预算)。
  • 已确定测试用例、测试装置和测试配置。
  • 体系结构看上去不是“过分设计”的。
    • 适当的机制简单且易于使用。
    • 机制的数量中等,且与系统范围和问题领域的需求保持一致。
  • 体系结构可执行为当前迭代定义的所有用例实现,如图示所述:
    • 对象之间的交互,
    • 任务和进程之间的交互,
    • 物理节点之间的交互。

模型 回到页首

体系结构分析考虑事项 回到页首

概述
    • 子系统和包的划分和分层是逻辑上一致的。
    • 已确定和描述了所有分析机制。
子系统
    • 上级层中的子系统服务(接口)已定义。
    • 子系统和包之间的依赖性对应于包含的类之间的依赖性。
    • 子系统中的类支持为子系统确定的服务。
    • 关键实体类及其关系已确定。
    • 关键实体类之间的关系已定义。
    • 每个类的名称和描述明确反映其所扮演的角色。
    • 每个类的描述准确捕获类的职责。
    • 实体类已映射到相应的分析机制。
    • 聚集和关联的角色名准确描述相关类之间的关系。
    • 关系的多重性是正确的。
    • 关键实体类及其关系与业务模型(如有)、领域模型(如有)、需求和词汇表条目是一致的。

常规模型考虑事项 回到页首

    • 在给定了模型目标的情况下,模型处于适合的详细程度。
    • 对于精化阶段中的业务模型、需求模型或设计模型,强调实施问题并不过分。
    • 对于构造阶段中的设计模型,模型元素之间的功能具有良好的平衡,通过组装相对简单的元素来建立更复杂的设计。
    • 模型能够证明熟悉和胜任对适用于问题领域的概念进行全面的建模;对手头的问题适当地运用了建模技术。
    • 以尽可能简单的方式对概念建模。
    • 模型是容易演进的;可很容易地适应预期的更改。
    • 同时,不过度构造模型,不以简单性和可理解性为代价来处理可能性不大的更改。
    • 记录模型蕴涵的关键假设并使模型的复审人员能够知晓。如果假设适用于给定迭代,则在那些假设范围之内,模型应当能够演进,但在那些假设范围之外则不一定。记录假设是防止设计人员看不到“所有”可能需求的方法。在迭代过程中,分析所有可能的需求并定义一个处理每个未来需求的模型是不可能的。

回到页首

    • 图的目的已明确陈述并易于理解。
    • 图形布局是清晰的,并明确传达了意指的信息。
    • 图传达了恰好足够完成其目标的信息,而没有更多的信息。
    • 有效使用封装来隐藏详细信息并提高明确性。
    • 有效使用抽象来隐藏详细信息并提高明确性。
    • 模型元素的放置有效传达了关系;将类似或紧耦合的元素分组在一起。
    • 模型元素之间的关系易于理解。
    • 模型元素的标注有助于理解。

文档 回到页首

    • 每个模型元素都有不同的目的。
    • 不存在多余的模型元素;每个元素扮演系统中的一个基本角色。

错误恢复 回到页首

    • 对于每个错误或异常,策略定义了如何将系统恢复到“正常”状态。
    • 对于每种可能的来自用户的输入错误或来自外部系统的错误数据,将有一个策略定义如何将系统恢复到“正常”状态。
    • 始终应用一种策略来处理异常情况。
    • 始终应用一种策略来处理数据库中的数据损坏。
    • 始终应用一种策略来处理数据库的不可用性,包括是否仍能将数据输入系统并随后进行存储。
    • 如果在系统之间交换数据,则存在一种策略,用于系统如何同步数据视图。
    • 在系统中,利用冗余的处理器或节点来提供容错或高可用性,存在一种策略,用于确保不会有两个处理器或节点“认为”自己是主处理器或主节点,或者认为没有处理器或节点是主处理器或主节点。
    • 识别了分布式系统的故障模式并定义了处理故障的策略。

移交和安装 回到页首

    • 在不损失数据或操作能力的前提下升级现有系统的过程已定义并通过测试。
    • 转换前发行版使用的数据的过程已定义并通过测试。
    • 升级或安装产品所需的时间量和资源得到很好的理解,并已记录下来。
    • 系统功能一次可由一个用例激活。

管理 回到页首

    • 当系统运行时,可以重新组织或恢复磁盘空间。
    • 系统配置的职责和过程已确定并记录下来。
    • 对操作系统或管理功能的访问是受限的。
    • 满足许可需求。
    • 当系统运行时,可以运行诊断例程。
    • 系统监视操作性能本身(例如,容量阈值、关键性能阈值和资源枯竭)。
      • 定义了到达阈值时采取的操作。
      • 警报处理策略已定义。
      • 警报处理机制已定义,并已建立原型和通过测试。
      • 可“调整”警报处理机制,以防止错误的或多余的警报。
    • 用于网络(LAN、WAN)监视和管理的策略和过程已定义。
    • 网络故障可被隔离。
    • 可使用事件跟踪设施来帮助故障诊断。
      • 已了解设施开销。
      • 管理人员具备有效使用设施的知识。
    • 怀有恶意的用户不可能:
      • 进入系统。
      • 破坏关键数据。
      • 消耗所有资源。

性能 回到页首

  • 性能需求是合理的,并反映问题领域中的真实约束;其规范不是任意的。
  • 系统性能的估算值(使用工作负载分析模型按需建模)已存在,并且这些估算值表明性能需求不是重要的风险。
  • 已使用体系结构原型验证系统性能估算值,尤其是对于性能关键的需求。

内存利用 回到页首

    • 应用程序的内存预算已定义。
    • 已采取操作来检测和防止内存泄漏。
    • 应用一致的策略来定义如何使用、监视和调整虚拟内存系统。

成本和进度安排 回到页首

    • 至今为止开发的代码行的实际数目符合当前里程碑处的估计代码行数。
    • 评估假设已经过复审并保持有效。
    • 已使用最近的实际项目经验和生产力性能重新计算成本和进度安排估算。

可移植性 回到页首

    • 可移植性需求已满足。
    • 编程指南提供有关创建可移植代码的特定指南。
    • 设计指南提供有关设计可移植应用程序的特定指南。
    • 已建立“测试端口”来验证可移植性声明。

可靠性 回到页首

    • 质量度量值(MTBF、未解决缺陷个数等)已满足。
    • 如果发生灾难或系统故障,体系结构提供恢复。

安全性 回到页首

    • 安全性需求已满足。

组织问题 回到页首

    • 团队的结构良好吗?在团队之间很好划分职责了吗?
    • 存在限制团队有效性的政治、组织或管理问题吗?
    • 存在个性冲突吗?

用例视图 回到页首

软件体系结构文档的用例视图部分:

    • 每个用例在体系结构上是重要的,如此确定是因为它:
      • 对于客户是至关重要的
      • 激发其它视图中的关键元素
      • 是减轻一个或多个主要风险(包括任何挑战性的非功能需求)的推动因素。
    • 没有任何一个用例的体系结构问题已被另一个用例所涵盖
    • 用例的体系结构上重要的方面是明确的,但又不拘泥于细节
    • 用例是明确的,并不太可能以影响体系结构的方式更改,或者对于如何实现这样的明确性和稳定性存在适当的计划
    • 不缺少任何体系结构上重要的用例(可能需要对未对此视图选中的用例作一些分析)。

逻辑视图 回到页首

软件体系结构文档的逻辑视图部分:

    • 准确并完整地概述了设计的体系结构上重要的元素。
    • 显示设计中使用的一组完整的体系结构机制和选择依据的理由。
    • 显示设计的分层以及划分各层依据的理由。
    • 显示设计中使用的任何框架或模式,以及选择这些模式或框架依据的理由。
    • 体系结构上重要的模型元素的数量与系统的大小和范围是成比例的,并且使得系统中使用的主要概念仍可理解。

    进程视图 回到页首

    主题

    资源利用 回到页首

      • 已识别潜在的竞争状态(进程对关键资源的竞争),并且已定义避免和解决策略。
      • 已定义策略来处理“I/O 队列满”或“缓冲区满”状态。
      • 系统监视自身(容量阈值、关键性能阈值和资源枯竭)并在检测到问题时能够采取更正操作。

    性能 回到页首

      • 每个消息的响应时间需求已确定。
      • 存在用于系统的诊断方式,允许度量消息响应时间。
      • 重要操作的名义和最大性能需求已指定。
      • 有一组能够度量性能需求是否已满足的性能测试。
      • 性能测试涵盖系统的“超出正常范围的”行为(启动和关闭、备选和意外的用例事件流、系统故障模式)。
      • 已识别可能产生性能瓶颈的体系结构缺陷。特别强调以下方面:
        • 某个有限共享资源的使用,这些资源包括(但不限于)信号量、文件句柄、锁、锁存器、共享内存等。
        • 进程间通信。跨进程边界的通信总是比进程内通信更昂贵。
        • 处理器间通信。跨进程边界的通信总是比进程间通信更昂贵。
        • 物理内存和虚拟内存的使用;系统用完物理内存并开始使用虚拟内存的时刻,通常就是性能开始急剧下降的时刻。

    容错 回到页首

      • 其中有主进程和备份进程,已考虑多个进程认为自己是主进程(或没有进程认为自己是主进程)的可能性,并采取特定设计操作来解决冲突。
      • 当类似进程故障的事件使系统处于不一致状态时,存在将系统恢复到一致状态的外部进程。
      • 系统能够容忍错误和异常,这样当错误或异常发生时,系统可还原到一致状态。
      • 当系统运行时,可以执行诊断测试。
      • 如果需要,当系统运行时可对其升级(硬件、软件)。
      • 存在一致的策略来处理系统中的警报,并始终应用该策略。警报策略用于:
        • 设定警报报告机制的“灵敏度”;
        • 防止错误或多余警报;
        • 满足要使用警报报告机制的人员的培训和用户界面需求。
      • 警报报告机制的性能影响(进程周期、内存等)已评估并落在可接受的性能阈值(在性能需求中建立)内。
      • 工作负载/性能需求已检查并已满足。在性能需求不切实际的情况下,已对其进行重新协商。
      • 已确定存在的内存预算并已验证该软件满足那些需求。 已采取措施来检测和防止内存泄漏。
      • 存在使用虚拟内存系统的策略,包括如何监视和调整它的使用。

    模块性 回到页首

      • 进程相互之间足够独立,在需要时可跨处理器或节点分布。
      • 已识别必须保持协同定位(由于性能和吞吐量需求,或进程间通信机制,例如信号量或共享内存)的进程,已考虑到不能分配此工作负载的影响。
      • 可以异步建立的消息(以便在资源可用性增加时可以处理这些消息)已确定。

    部署视图 回到页首

      • 通过跨节点分布处理,吞吐量需求已满足,并且潜在性能瓶颈已解决。
      • 在此将信息分配(并有可能复制)到几个节点,确保了信息的完整性。
      • 存在的可靠传输消息的需求已满足。
      • 存在的安全传输消息的需求已满足。
      • 以网络流量和响应时间最小化的方式将处理分配到各节点,此做法要服从一致性和资源约束。
      • 存在的系统可用性需求已满足。
        • 已确定在发生服务器或网络故障下的最大系统当机时间,并且它在可接受的范围(如需求所定义)内。
        • 冗余和备用服务器已定义,方法为不能将多个服务器指定为“主”服务器。
      • 所有潜在的故障模式均已记录。
      • 网络故障可被隔离、诊断和解决。
      • CPU 利用的“上限”量已确定,并定义了度量方法
      • 当超过最大 CPU 利用量时,存在采取操作的规定策略。

     

    Rational Unified Process   2003.06.15