主题

设计和实施机制简介 回到页首

设计机制是对应的分析机制的改进(另请参阅概念:分析机制)。设计机制为概念分析机制添加具体的详细信息,但止步于需要特定技术 - 例如特定供应商的实施(比如面向对象的数据库管理系统)。如同分析机制,设计机制可实例化一个或多个模式,在本例中是体系结构设计模式

类似地,实施机制是对应设计机制的改进,使用例如特定编程语言和其它的实施技术(例如特定供应商的中间件产品)。实施机制可实例化一个或多个代码模式或实施模式。

示例:设计机制的属性 回到页首

请考虑分析机制的持久性

  • 可能需要在几秒种内存储许多(2000)个小对象(每个 200 字节),但不需要长久存储。
  • 可能需要将几个非常大的对象在磁盘上永久存储几个月,从不更新,但适合使用完善的检索方法。

这些对象将需要不同的持久性支持;可确定设计机制对于持久性支持所具有的以下属性:

  • 内存存储器;属性:总共最多 1 Mb(大小 x 卷);可非常快速地读、写和更新。
  • 闪存卡;属性:最多 8 Mb;更新和写速度慢;读速度中等。
  • 二进制文件;属性:100 Kb 到 200 Mb;更新慢;读和写速度慢。
  • 数据库管理系统(DBMS);属性:100 Kb 及更高(本质上无上限);更新、读和写速度甚至更慢。

请注意,这些速度“慢”只是与内存存储器相比而言的。显然,在某些环境中,高速缓存的使用可明显改进访问次数。

图在内容中有详细描述。

 

改进设计和实施机制之间的映射 回到页首

最初,设计机制和实施机制之间的映射可能不是最佳的,但它将使项目运行、确定尚不可见的风险并触发进一步的调查和评估。当项目继续进行并获得更多知识时,需要改进映射。

以迭代方式继续改进设计和实施机制之间的映射,消除冗余路径,同时“自上而下”和“自下而上”地工作。

自上而下地工作。当“自上而下”地工作时,新的和改进的用例实现将通过所需的分析机制对所需的设计机制提出新需求。这样的新需求可能揭示设计机制的更多属性,从而强制分开这两个机制。期间还必须在系统的复杂度和性能之间达到平衡点:

  • 不同的设计机制太多会使系统过于复杂。
  • 某些实施机制会拓宽它们的属性值的合理范围限制;对于这些实施机制,设计机制太少就会产生性能问题。

自下而上地工作。当“自下而上”地工作时,通过调查可用的实施机制,您可能会发现某些产品,它们可一次满足多个设计机制,但要求在一定程度上改造或重新划分您的设计机制。您想使用最少的实施机制,但太少也会导致性能问题。

一旦决定使用 DBMS 存储类 A 的对象,您可能会想使用它存储系统中的所有对象。这样做会非常低效或非常麻烦。不是所有需要持久存在的对象都要存储在 DBMS 中。一些对象可能持久存在,但可能只有当时运行的那个应用程序频繁访问它,而其它应用程序只是偶而访问它。这时,可能最好的办法是采用混合策略 - 将对象从 DBMS 读进内存然后定期同步。

示例

可以将航班存储在内存中用于快速访问,同时存储在 DBMS 中用于长期保存;但这需要使两者同步的机制。

将多个设计机制与一个客户端类关联作为不同属性之间的平衡点,这并不少见。

因为实施机制经常在成品组件(操作系统和中间件产品)中捆绑出现,所以需要进行某些基于成本、阻抗失配或样式统一的优化。此外,机制经常是相互依赖的,使得将服务清楚分成设计机制很困难。

示例

  • 通知机制可以将进程间的通信机制作为基础。

  • 错误报告机制可以将持久性机制作为基础。

改进贯穿整个精化阶段,而且始终是在寻求以下两个方面的平衡:

  • 根据期望的属性,与客户对设计机制的需求的准确“相符”。
  • 要获得和集成太多不同实施机制所带来的成本和复杂性。

总体目标始终是具有简单明确的一组机制,为大型系统提供概念上的完整、简单和精确。

示例:将设计机制映射到实施机制 回到页首

持久性设计机制可如下映射到实施机制:

图在内容中有详细描述。

分析机制和设计机制之间的可能映射。虚线箭头表示“专门化”,意味着设计机制的属性是从分析机制继承的,但它们将被专门化和改进。

一旦完成了机制的优化,就会存在以下映射:

图在内容中有详细描述。

从机制之间的映射描述的客户端类的设计决定;Flight 类需要两种形式的持久性:由现成的库例程实现的内存存储和用成品 ObjectStorage 产品实现的数据库存储。

该映射必须从两个方向都可以实现,以便在更改实施机制时,易于确定客户端类。

描述设计机制 回到页首

设计机制和有关它们的使用的详细信息记录在../../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website工件:特定于项目的指南中。分析机制与设计机制及实施机制之间的关系(或映射)以及这些选择的相关根本原因记录在工件:软件体系结构文档中。

对于分析机制,可使用协作对设计机制建模,这可能会实例化一个或多个体系结构设计模式

示例:持久性机制

此示例使用从 JDBC™(Java 数据库连接)引出的、基于 RDBMS 的持久性的模式实例。尽管我们在这里只是展示设计,但 JDBC 为某些类提供实际代码,因此从这里展示的内容到实施机制之间只有一步之遥。

图静态视图:JDBC 显示了协作中的类(严格地说是分类器角色)。

图在内容中有详细描述。

静态视图:JDBC

填入黄色的类是提供的类,其它类(myDBClass 等)是由设计人员组合用于创建机制的。

在 JDBC 中,客户端将使用 DBClass 来读写持久数据。DBClass 负责使用 DriverManager 类访问 JDBC 数据库。一旦打开数据库连接,DBClass 就可创建 SQL 语句,这些 SQL 语句将被发送到底层的 RDBMS,并使用 Statement 类执行。Statement 类涉及什么“告诉”数据库。SQL 查询结果在 ResultSet 对象中返回。 

DBClass 类负责使另一个类实例持久。它了解 OO - RDBMS 映射并可实施与 RDBMS 对接的行为。DBClass 串行化该对象,将其写入 RDBMS 并从 RDBMS 读取对象数据然后构建对象。每个持久类都将有相应的 DBClass。 

PersistentClassList 用于返回一组持久对象,作为数据库查询(如 DBClass.read())的结果。

我们现在展示一系列动态视图,来显示该机制实际如何运行。

图在内容中有详细描述。

JDBC:初始化

在可以访问任何持久类之前,必须进行初始化。

要初始化到数据库的连接,DBClass 必须通过使用 URL、用户和密码调用 DriverManager getConnection() 操作来装入适当的驱动程序。

操作 getConnection() 尝试建立到给定数据库 RUL 的连接。DriverManager 尝试从所注册的 JDBC 驱动程序组中选择适当的驱动程序。

参数:

URL:格式为 jdbc:subprotocol:subname 的数据库 URL。此 URL 用于查找实际数据库服务器,而在此实例中不是与 Web 相关的。

用户:被代表执行连接的数据库用户

密码:用户密码

返回

到 URL 的连接。

图在内容中有详细描述。

JDBC:创建

为了创建新类,持久性客户端请求 DBClass 创建新类。DBClass 使用缺省值创建 PersistentClass 的新实例。然后,DBClass 使用 Connection 类 createStatement() 操作创建新的 Statement。该 Statement 被执行,并且数据被插入到数据库中。

图在内容中有详细描述。

JDBC:读

为了读持久类,持久性客户端请求 DBClass 执行读操作。DBClass 使用 Connection 类 createStatement() 操作创建新的 Statement。该 Statement 被执行,并且数据在 ResultSet 对象中返回。然后,DBClass 创建 PersistentClass 的新实例并用检索出的数据填充它。数据在某个集合对象(PersistentClassList 类的一个实例)中返回。

注意:传递给 executeQuery() 的字符串不必与传入 read() 的字符串完全相同。DBClass 将构建 SQL 查询,来使用传入 read() 的条件从数据库中检索持久数据。这是因为我们不希望 DBClass 的客户需要了解数据库内部才能创建有效查询。该知识包含在 DBClass 中。

图在内容中有详细描述。

JDBC:更新

为了更新类,持久性客户端请求 DBClass 执行更新操作。DBClass 从给定 PersistentClass 对象检索数据,然后使用 Connection 类 createStatement() 操作创建新的 Statement。一旦构建了 Statement,就执行更新,使用来自该类的新数据更新数据库。

请记住:“串行化”PersistentClass 并将其写入数据库是 DBClass 的工作。这就是为什么在创建 SQL 语句之前,必须从给定 PersistentClass 中检索的原因。

注意:在上述机制中,PersistentClass 必须为所有持久数据提供访问例程,以便 DBClass 可以访问它们。这提供了对某些本应属私有的持久属性的外部访问。这是将持久性知识放在包含数据的类之外所必须付出的代价。

图在内容中有详细描述。

JDBC:删除

为了删除类,持久性客户端请求 DBClass 删除 PersistentClass。DBClass 使用 Connection 类 createStatement() 操作创建新的 Statement。该 Statement 被执行,并且数据被从数据库中除去。

在此设计的实施中,将作出关于 DBClass 到持久类的映射的某些决策,例如每个持久类有一个 DBClass,并将它们分配到适当的包中。这些包将对于提供的 java.sql(请参阅 JDBC API 文档)包有依赖关系,该包包含支持类 DriverManage、Connection、Statement 和 ResultSet。



Rational Unified Process   2003.06.15