任务:确定设计机制
此任务描述了如何将分析机制优化为设计机制。
用途
  • 基于实施环境施加的约束来将分析机制优化成设计机制。
关系
步骤
对分析机制的客户端分类

分析机制提供由分析类使用的概念上的服务集合。它们为最终必须关心、但处于分析工作范围之外的相当复杂的行为提供方便的简单表达方式。 它们的主要目的是允许我们捕获系统的这些尚待设计的服务的需求,而不必考虑服务提供者自身的细节。

现在,必须开始优化在分析机制上收集的信息。执行步骤如下:

确定每个分析机制的客户端。 浏览给定分析机制的所有客户端,查看它们对于该机制要求的特征。例如,许多分析类会利用持久性机制,但它们对该机制的需求可能变化很大:将具有一千个持久实例的类与将具有四百万个持久实例的类的持久性需求有显著区别。类似地,其实例必须以低于一毫秒的速度响应实例数据的类与只通过特别查询和批处理报告应用程序访问其实例数据的类需要的持久性方法将是不同的。

确定每个分析机制的特征概要文件特征概要文件可能变化很大,提供不同等级的性能、覆盖区、安全性和经济成本等。每个分析机制都不同 - 将有不同的特征适用于每个机制。多数机制将需要估计要管理的实例数量及其用预期字节数表示的预期大小。通过任何系统的大量数据的移动将产生必须处理的巨大性能问题。

按照客户端使用的特征概要文件,对客户端分组。对客户端分组:这些客户端看来需要同一个分析机制,该机制具有相似的特征概要文件;基于每个这样的需要来确定设计机制。这些分组提供了对设计机制的初始划分。示例分析机制“进程间通信”可映射到设计机制“对象请求代理程序”。不同的特征概要文件将导致从同一个分析机制中产生不同的设计机制。分析中的简单持久性机制将产生设计中的多个持久性机制:内存中的持久性、基于文件、基于数据库和分发式等。设计机制是基于不同特征概要文件而对分析机制的优化。

列出实施机制清单

自下而上的进行并列出要处理的实施机制清单(请参阅概念:设计和实施机制):

  • 由中间件产品或组件框架提供的机制。
  • 由操作系统提供的机制。
  • 由组件提供的机制。
  • 由类库提供的机制。
  • 旧代码(另请参阅:任务:合并现有设计元素
  • 特殊用途包:GUI 构造器、地理信息系统、DBMS 等。

确定什么场合可使用现有实施机制以及什么场合需要建立新的实施机制。

将设计机制映射到实施机制

设计机制提供实施机制的抽象,将分析机制和实施机制之间的差距衔接起来。在设计期间抽象体系结构机制的使用可使我们考虑如何提供体系结构机制,而不会将手边的问题与特定机制的细节问题相混淆。它也可使我们可能用一个特定实施机制去替换另一个,而不会对设计有不利影响。

确定特征范围。 用对设计机制确定的特征来确定用于候选实施机制的合理、经济或可行的价值范围。

考虑所购组件的购买成本。 对于候选实施机制,除了纯粹的技术条件,还请考虑购买或许可成本、产品的成熟度、与供应商的关系、支持等。

搜索合适的组件,或自制组件。 通常,您将会发现对于某些设计机制,不存在明显合适的实施机制;这将会引发搜索合适的产品或确定内部开发的必要性。您也可能发现某些实施机制根本不可用。

实施机制的选择不仅基于对技术特征的良好匹配,而且基于非技术特征(如成本)。部分选择可能是临时的;几乎所有的选择都带有一些风险:性能、健壮性和可伸缩性几乎始终是要考虑的问题并必须通过评估、探索性地建立原型或包含在体系结构原型中来验证。

记录体系结构机制

在此任务中,软件设计人员的角色是通过建立或集成机制并验证它们有效,来确定和验证这些机制,然后将这些机制一致地施加到剩余的系统设计中。软件设计人员角色与流程工程师角色协作,以便在特定于项目的设计指南中记录机制和有关机制使用的详细信息。 请参阅任务:准备特定于项目的指南。分析机制与设计机制以及实施机制之间的关系(或映射),还有这些选择的相关理由应记录在软件体系结构文档中。 这些机制本身是设计模型元素(如设计包、设计类和设计子系统),作为各自设计任务的一部分在工作产品:设计模型中有详细描述。



属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息