在前面讨论的Resource Transcations（资源事务）中有许多共同的行为。其中一个行为可以包含多个项目，每个项目对应一个不同的资源（ItemizeTheResourceTransaction（11）。事务可以产生一些报酬（PayForTheResourceTransaction（12））。事务也可能由一个人或小组完成，这对系统非常重要（IdentifyTheTranscationExecutor（13））。当一个资源需要维护，我们必须关注维护所必需的人力服务（IdentifyMaintenanceTasks（14））和这个过程中所使用的部件（IdentifyMainanceParts（15））。实际上，人力服务和部件都是在维护中可见的资源，被维护的资源是一个属于顾客的物品。
上下文
应用系统管理资源而你已经采用了第2节中的一个或多个模式。在一些应用中，一次事务可能要包含对多个资源的处理，例如，一个顾客在录像带出租店可以一次租多个录像带。或者，当向供应商采购时，一次可能采购多种产品。因此，允许一次事务包含多个条目会让人感到方便。表1中列出了第2节中可能遇到这种情况的模式中和模式中的类。
问题：
如何在一个事务中管理多个资源？
约束：
· 当需要在一次事务中处理多个资源时，只在表示事务的类中加入数量属性不是一个可行的方案：它只能处理在一次事务中对同一种资源不同单元的情况。
· 在有些应用中，没有必要在一次事务中包括多个项目：例如，在汽车修理店中，一个顾客一般一次只修理一辆汽车。在这种情况下，可能的例外可以当作两个或多个事务处理，因为为这种很少出现的情况花费过多不值得。
结论：
确定一个事务中是否需要处理多个资源。
解决方案：
建立一个“Transaction Item”类聚合到“Resource Transaction”中，控制一个事务中的多个项目。
略图：
图22表示了ItemizeTheResourceTransaction模式，"Resource Transaction"类和"Resource"类（或是某些情况下"Resource Instance"类）间的连接应去掉，建立从"Transaction Item"类到"Resource"类（或是 "Resource Instance"类）间的连接，如图22所示。"Transaction Item"类表示一次事务中处理的多个项目。仅当采用"ResourceMeasurementPattern（3b）"时，它有可选属性"数量"和"价格"。在"Resource Transaction"类中增加了一个"统计事务条目"的方法。
示例：
图23表示ItemizeTheResourceTransaction模式的一个实例，其中"Product"扮演"Resource"，"Delivery"扮演"Resource Delivery"，"Purchase"扮演"Resource Transaction"，"Purchase Item"扮演"Transaction Item"。
相关模式：
ItemizeTheResourceTransaction模式是"Behavior across a Collection"模式，和"State across a collection"模式[Coa 92]的特例。如果你考虑类"Resource Transaction"和"Transaction Item"（本模式），这里有"Transaction Line Item"模式[Coa 97]的一个应用。如果你考虑类"Transaction Item"和"Resource"，这里有"Item-Line Item"模式[Coa97]的一个应用。
下一模式：
下一步考虑是否采用"PayForTheResourceTransaction"（12）和IdentifyTheTransactionExecutor（13）。
上下文
应用系统管理资源而你已经采用了第2节中的一个或多个模式。许多资源交易有多种支付方式。例如，租房子，购买冰箱或者修汽车，顾客要付一大笔钱。如果一时拿不出全款，一些应用系统提供分期付款。其结果是管理更加复杂，要引入对收入和分期付款的控制。
问题：
如何控制与资源交易相关的付款？
约束：
· 只在“Resource Transaction”类中加入一些属性来控制付款往往是不够的，对收入与分期付款进行好的管理需要更精确的信息。
· 保存顾客的历史数据对组织确定顾客的信用起更好的支持作用。
· 对每笔分期付款独立处理将增加系统的难度。这种情况必须考虑，例如，所有的顾客支付现金。
结论：
确定资源事务可以采用分期付款。
解决方案：
如果一次付款，只要在"Resource Transaction"类中添加"付款日期"和"金额"就可以了。否则，就要创建一个与"Resource Transaction"类相关的"Payment"类跟踪每一笔付款。
略图：
图24表示了PayForTheResourceTransaction模式。方法"确定支付方式"添加到"Resource Transaction"中，确定顾客希望分几期付款以及相应的利息。"Payment"类中包括属性"开始日期"、"付款日"、"分期序号"、"金额"和"状态"。最后一个属性控制分期付款的可能状态，例如，已经付清、拖期等。方法"Coming installments"列出了将要分期付款的日期。方法"Overdue Payment"列出了所有拖期的付款。方法"Register Payment"负责完成客户的付款。方法"Payment done"列出在一定时期内所有的付款。
示例：
图25描述了PayForTheResourceTransaction的一个实例。其中，"Sale"扮演"Resource Transaction"，"Accounts Receivable"扮演"Payment"。
相关模式：
PayForTheResourceTransaction是"Transaction-Subsequent transaction"模式的一个特例。
下一模式：
下一个可能的模式是IdentifyTheTransactionExecutor（13）
上下文
应用系统管理资源，而你已经采用了第2节中的一个或多个模式。许多资源交易有多种支付方式。对于实际系统，知道是谁完成的事务非常有用。例如，在一个计算机商店，销售人员卖出计算机并且按照每周或每月获得佣金。因此，为了提供佣金报表，系统需要这些信息。
问题：
如何识别事务的执行者？
约束：
· 在"Resource Transaction"类中加入"执行者"属性对于仅关心执行者姓名的小系统来说是一个好方案。但是在一些系统中，"执行者"具有管理所必须的其它属性，例如，固定的薪水，特殊佣金比例，最小销售额等。
· 只有当应用系统需要时，才值得将每个执行者信息分开存放，因为这样会需要更多的存储空间和处理时间。
结论：
确定执行者对系统是否重要。
解决方案：
创建与"Resource Transaction"类（表1中所示）相关联的"Transaction Executor"类，表示可能的事务负责人或团队。
| 下一页 |