概念:分析机制
分析机制代表一种模式,该模式构成对常见问题的常见解决方案。 分析机制可以显示结构模式和/或行为模式。
关系
主要描述

分析机制简介

分析机制代表一种模式,该模式构成对常见问题的常见解决方案。 分析机制可以显示结构模式和/或行为模式。它们在分析期间使用,通过向设计人员提供对复杂行为的简单表示,来降低分析复杂性和提高一致性。 机制允许分析工作集中于将功能需求转换成软件概念,同时不会陷入相对复杂的行为的规范中,上述行为是支持功能所需要的,但不是它的中心。 分析机制通常源于对一个或多个体系结构分析模式的实例化。 

分析机制主要用来代表体系结构中间和靠下的层中的复杂技术的“占位符”。 通过将机制用作体系结构中的“占位符”,可以降低机制行为的细节分散体系结构搭建工作注意力的可能性。 例如,让对象生存期跨用例、流程生存期或系统关闭和启动的需要定义了对象持久性的需要。 持久性是一个特别复杂的机制,在分析期间我们不希望被我们如何达到持久性的细节分散注意力。 这促使了“持久性”分析机制的形成,该机制允许我们谈论持久对象和捕获我们对持久性机制的需求,而无需担忧持久性机制究竟会做什么以及如何工作。

分析机制通常与问题领域无关(但并不一定总是无关),而属于“计算机科学”的概念;所以,它们通常占据体系结构的中层及更低层。它们为关于领域的类或子系统提供特定的行为,或与类和/或子系统之间合作的实施相对应。 它们可以作为框架实施,略举几例:处理持久性的机制、进程间通信机制、错误或故障处理机制、通知机制和消息传递机制等等。  

但是,由于在各个不同领域建立了更多的分析模式,它们在分析机制中的部分或完全实例化将导致这些机制出现在体系结构靠上的层中。

分析机制的示例

  • 持久性

    对于它们的实例可能持久的所有类,我们需要确定:
    • 粒度:保持持久的对象大小的范围
    • 容量:保持持久的对象的数量
    • 持续时间:对象通常需要保持多久?
    • 检索机制:给定的对象如何唯一标识和检索?
    • 更新频率:对象是否或多或少是恒定的;它们永远需要更新吗?
    • 可靠性:对象是否应当在进程、处理器或者整个系统崩溃后继续存在?

  • 进程间通信

    对于所有需要与其他进程或线程中正在执行的组件或服务进行通信的模型元素,我们需要确定:
    • 等待时间:进程之间的通信速度必须是多快?
    • 同步性:异步通信
    • 消息大小:一个范围可能比单个数字更合适。
    • 协议、流量控制、缓存等等。

其他典型机制包括:

  • 消息路由
  • 进程控制和同步
  • 事务管理
  • 信息交换
  • 安全性
  • 冗余性
  • 错误报告
  • 格式转换

描述分析机制

描述分析机制的流程为:

  1. 将所有分析机制收集到列表中

    相同的分析机制在不同的用例实现或不同的设计人员之间可能以几个不同的名称出现。例如,存储持久性数据库存储库可能都指持久性机制。或者进程间通信消息传递远程调用可能都指进程间通信机制。

  2. 绘制从客户机类到分析机制的映射图
  3. 在内容中描述了该图。

    标识的类和子系统需要映射到已标识的分析机制:箭头表示类利用了该机制。 客户机类经常需要若干种机制的服务。

  4. 标识分析机制的特征

    为区分一系列的可能设计,请标识用来限定每个分析机制的关键特征。 这些特征也就是部件功能以及部件大小和性能。

  5. 通过协作建模

    在标识和命名了分析机制之后,它们最终应通过“类集”(请参阅 [BOO98])的协作进行建模,其中一些类不直接提供应用程序功能,它们的存在只是为了支持机制。 这些“支持类”经常位于分层体系结构的中低层,从而向所有应用级别的类提供公共的支持服务。

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

分析机制记录在工作产品:软件体系结构文档中。随着软件体系结构的日渐成熟,工作产品:软件体系结构文档将包含分析机制与设计机制以及实施机制之间的关系(或映射),还有与这些选择相关联的理由。