概念:分析机制
主题
分析机制的简介 
分析机制代表一种模式,该模式构成对常见问题的常见解决方案。
分析机制可以显示结构模式和/或行为模式。它们在分析期间使用,通过向设计人员提供对复杂行为的简单表示,来降低分析复杂性和提高一致性。机制允许分析工作集中于将功能需求转换成软件概念,同时不会陷入相对复杂的行为的规范中,上述行为是支持功能所需要的,但不是它的中心。
分析机制常常源自一个或多个体系结构或分析模式的实例化。
分析机制主要用来代表体系结构中间和靠下的层中的复杂技术的“占位符”。
通过将机制用作体系结构中的“占位符”,可以降低机制行为的细节分散体系结构搭建工作注意力的可能性。
例如,让对象生存期跨用例、流程生存期或系统关闭和启动的需要定义了对象持久性的需要。
持久性是一个特别复杂的机制,在分析期间我们不希望被我们如何达到持久性的细节分散注意力。
这促使了“持久性”分析机制的形成,该机制允许我们谈论持久对象和捕获我们对持久性机制的需求,而无需担忧持久性机制究竟会做什么以及如何工作。
分析机制通常(但不一定)与问题领域无关,不过属于“计算机科学”概念。因此,它们通常占据体系结构的中间和靠下的层。
它们为关于领域的类或子系统提供特定的行为,或与类和/或子系统之间合作的实施相对应。
它们可以作为框架实施,略举几例:处理持久性的机制、进程间通信机制、错误或故障处理机制、通知机制和消息传递机制等等。
但是,由于在各个不同领域建立了更多的分析模式,它们在分析机制中的部分或完全实例化将导致这些机制出现在体系结构靠上的层中。
- 持久性
对于它们的实例可能持久的所有类,我们需要标识:
- 粒度:要保持持久的对象的大小范围
- 容量:要保持持久的对象的个数
- 持续时间:对象通常需要保持多久?
- 检索机制:给定的对象如何唯一标识和检索?
- 更新频率:对象是否或多或少是恒定的;它们永远需要更新吗?
- 可靠性:在流程、处理器或者整个系统崩溃的情况下,对象能否幸存?
- 进程间通信
对于所有需要与其它进程或线程中正在执行的组件或服务进行通信的模型元素,我们需要标识:
- 等待时间:流程相互通信所需的速度。
- 同步性:异步通信
- 消息大小:一个范围可能比单个数字更合适。
- 协议、流量控制、缓存等等。
其它典型机制包括:
- 消息路由
- 进程控制和同步
- 事务管理
- 信息交换
- 安全性
- 冗余性
- 错误报告
- 格式转换
描述分析机制的流程为:
- 将所有分析机制收集到列表中
相同的分析机制在不同的用例实现或不同的设计人员之间可能以几个不同的名称出现。例如,存储、持久性、数据库和存储库可能都指持久性机制。或者进程间通信、消息传递或远程调用可能都指进程间通信机制。
- 绘制一幅从客户机类到分析机制的图

标识的类和子系统需要映射到已标识的分析机制:箭头表示类利用了该机制。
一个客户机类需要几个机制的服务并不少见。
- 标识分析机制的特征
为区分一系列的可能设计,请标识用来限定每个分析机制的关键特征。
这些特征也就是部件功能以及部件大小和性能。
- 使用协作的模型
在标识和命名了分析机制之后,它们最终应通过“类集”(请参阅 [BOO98])的协作进行建模,其中一些类不直接提供应用程序功能,它们的存在只是为了支持机制。
这些“支持类”经常位于分层体系结构的中低层,从而向所有应用级别的类提供公共的支持服务。
如果标识的机制足够普遍,那么或许会存在模式,机制可以从中实例化 - 通过绑定现有类并根据模式的要求实施新的类。
用这种方式制作的分析机制将是抽象的,并需要在设计和实施期间进一步改进。
分析机制记录在工件:软件体系结构文档中。随着软件体系结构的日渐成熟,工件:软件体系结构文档将包含分析机制到设计机制再到实施机制的关系(或映射),以及这些选项相关的理由。
模式和转换 
背景 
作为“用于重复出现问题的、在给定环境中已证实有用的解决方案模板”(摘自词汇表定义),模式的观念非常笼统:根据所解决问题的特性和规模,这样定义的模式的应用(实例化)可能需要大量模板变更。模式的应用以及由此而来的机制实例化从这样看来,是通过模型转换进行的。例如,在上面定义的机制之一中,对于安全性,作为安全机制基础的任何模式可能很普及并需要对元素类型作出不同于模型元素类型的变更。安全模式的定义可在 UML 概要文件中找到,这是捕获构造型、标注值和约束(它们定义和限制特定技术、规程、领域或建模问题的其它区域)的标准化方法。这本质上与平台相同(请参阅概念:模型驱动开发和 Mode Driven Architecture®);因此,一次或多次转换实现“大规模模式”的观念在此适用。
按照此观点,模式(大规模)和转换之间的关系可如下说明:

但是,按照许多人的普遍经验,模式受到更多的约束。按照此观点,它是一种转换(它被应用于源模型并且它的应用产生变更后的模型),但此变更是精细的、在局部(可能在其中一个步骤中)应用的,并且源和目标模型保持几乎同样的抽象广度。您甚至可将它们视作同一个模型。例如,可以以参数化协作的形式将模式应用到设计模型,并且倘若模型不是特定于技术的,仍可称结果是一个设计模型。这反映在 RUP 中,也就是我们所说的分析模式、设计模式和实施模式(术语)。按照此观点,模式和转换(现在显示为抽象类)之间的关系被如下可视化:

下面进一步探索模式的这种更特定的用法。
作为软件设计人员,我们希望继续在高度抽象的条件下工作,并且在已确定和描绘了所需的分析机制及其支持模式(大型和小型)后,使用自动化的转换实现它们。最后,当执行分析和设计时,我们希望在最终跳至代码之前,尽量使模型转换自动化,而同时 UML 模型仍处于高度抽象状态,不只是代码的直接反映。
转换方法 
在概念:模型驱动开发和 Model Driven Architecture® 中,概括了一些转换方法(请参阅如何执行转换?)。给出一个具体示例:Rational Software Architect 支持基于类型映射组合(例如,确定源模型的类、这些类的属性、操作和关系如何影响目标元素)和源模型标记(都由概要文件启用)的方法。
此方法承认源模型通常不包含足够的信息来通过类型映射完整地指导转换。软件设计人员可向源模型添加标记(如概要文件中定义的构造型),以完整地指定转换。这些表示目标平台概念的标记不属于源模型,但覆盖在源模型上。驱动转换的规则是从目标平台定义中派生的,例如,从关联概要文件和从源中使用的到目标中使用的类型的类型映射中。
建立了转换规则并标记了源后,就可以继续进行转换了。Rational Software Architect 更进一步,允许为转换提供参数,例如,指定不能从概要文件或关联标记中派生出的信息。按此系统化方法作出模型变更的其它好处在于可产生和保存转换记录。这样就保存了从源模型到目标模型的强有力的可跟踪性信息。
再给出一些具体示例:Rational Software Architect 使转换和模式中的一般转换概念具体化。提供的定义是 Rational Software Architect 所用的定义。
转换 
转换是“为批处理优化的转换,主要跨元模型、模型和各抽象程度”。应用转换的结果通常是生成明显不同的模型,例如,从 UML 模型生成文本代码模型。这是一步很重要的转变,其中还包括符号表示法的转变。
模式 
模式是“为交互式、分段的精化优化的转换,优化主要在单个元模型中、相同抽象程度下并通常在同一模型中”。按此定义,UML 模型上的模式的应用结果仍是 UML 模型,可能是稍微精细些、但被视为相同抽象程度的一个模型。
转换、模式和转变之间的关系如下优化前一张图:

这种更严格的方法的另一个结果是概要文件和从中派生出的转换变成自身的重要实体。软件设计人员将希望通过重复使用来利用在准备转换时所做的工作。期望创建转换库,以便一次性的转换成为例外。这样的库应可通过转换属性搜索或浏览,以便(例如)软件设计人员可容易地将它们与所需分析机制的已确定特征相匹配。
关于使用 Rational Software Architect 进行转换的性能的更多信息,可在各种 Rational Software Architect 教程和样本中找到,包括:
教程:应用 XYZ 模式
教程:扩展模式
样本:模式应用的模型
样本:模式
样本:要扩展的模式
教程:设计:将模型转换为代码
教程:设计:将模型转换为模型
样本:应用转换
样本:构建第一次转换
样本:构建模型到模型的转换
样本:创建生成文本的转换
样本:向其他 Rational Software Architect 用户部署转换
|