图26表示了IdentifyTheTransactionExecutor模式，提供与特定事务相关佣金的方法被添加到"Resource Transaction"类中。"Transaction Executor"类有属性代码、姓名、专业、佣金比例、最小销售额和薪水，还有通过执行者获得事务方法，和列出已付佣金方法。
示例：
图27表示IdentifyTheTransactionExecutor模式的一个实例，其中，"Sale"扮演"Resource Transaction"，"Salesman"扮演"Transaction Executor"。
相关模式：
IdentifyTheTransactionExecutor是"Participant-Transaction"模式的一个特例。
变体：
大型应用软件中，执行者可能是一个小组，因此可能有必要包括多个类，与Transaction Executor连接，控制小组成员间的佣金分配。
下一模式：
如果你的业务与维护，那么确定是否需要IdentifyMaintenanceTasks（14）和IdentifyMaintenanceParts（15）。否则，检查表1，看看是否有模式没有包括在内。
上下文
应用软件处理资源维护，已经应用了MaintainTheResource(9)和其它可选模式6，11，12，13（或者是这些模式的组合）。当一个资源出现故障需要维护时，经常需要人力服务。例如，一辆有刹车故障的汽车可能需要更换刹车版，调节刹车线或者需要添加润滑油。有些情况下，每一种服务由不同的人提供。因此，确定资源维护过程中的任务就非常重要了。
问题：
如何确定维护业务或维护询价过程中的任务？
约束：
· 如果只需要关于维护动作的少量信息，只要在维护中加一个属性就可以了。但是，这样所有的维护情况就被限定在一定数量的任务内。如果数量少，可能不会覆盖所有情况，如果数量大，就会浪费空间。
· 许多系统希望将每个维护动作独立处理，这样可以使不同的维护情况便于控制和比较。这种信息可以提高对新情况的报价和工作安排。
结论：
确定资源维修是否包括多个任务，可能由不同的人执行。
解决方案：
为"Resource Maintenance"建立一个聚合类"Maintenance Task"，带有属性"需要解决的问题"，"人力描述"，"花费时间"和"成本"。
略图：
图28表示IdentifyMaintenanceTasks模式，一个维护可以有多个任务。"维护执行者"类是可选的，相当于图26中的"Transaction Executor"类。是否使用该类取决于IdentifyTheTransactionExecutor模式。如果采用，将它与"Maintenance Task"类（如果每个任务由不同的人完成）相连，如图28所示，或是与"Resource Maintenance"类（如果整个维护工作由一个执行者完成）相连。
示例：
图29表示IdentifyMaintenanceTasks模式的一个实例，其中"Veicle repair"扮演"Resource Maintenance"，"Labor task"扮演"Maintenance task"，"Repairman"扮演"Maintenance Executor"。
相关模式：
如果你考虑类"Resource Maintenance"和"Maintenance Task"，那么是"Transaction-Transaction Line Item"模式的一个特例[Coa 97]。
下一模式：
确定是否需要IdentifyMaintenanceParts（15）模式。否则，检查表1，看看是否有模式没有包括在内。
上下文
应用软件处理资源维护，已经应用了MaintainTheResource(9)和其它可选模式6，11，12，13（或者是这些模式的组合）。在资源维修过程中，资源的某些部件可能需要更换，因为出了故障或是就要出故障。例如，如果汽车的刹车除了问题，刹车版可能需要更换，润滑油需要补充。在这种情况下，区分资源维护中使用的部件非常重要。
约束：
· 在有存量控制子系统的应用中，需要区分在维护中使用的部件，因为这些信息可以应用在存量控制中，用来减少库存，因此该信息连接了两个子系统。将部件单独处理可以使保修控制变得容易，虽然系统需要的存储空间和处理时间要增加。
· 另一方面，如果部件没有被任何子系统记录，那么维护中使用的部件可能要作为维护的一个属性来记录。采用这种方法要么限制部件在每次维修中的数量，要么建立一个固定的清单使用列表。
结论：
确定知道资源维护过程中的部件是否必要。
解决方案：
创建与"Resource Maintenance"类相关的"Part used in maintenance"类集合。创建"Part"类包含所有组织中可用部件。
略图：
图30表示IdentifyMaintenanceParts模式，每个资源维护可能用到多个部件，维护中使用的每个部件对应库存中的一种部件。"Resource Maintenance"类中增加了计算部件总量的方法。
示例：
图31表示IdentifyMaintenanceParts模式的一个实例，其中"Vehicle repair"扮演"Resource Maintenance"，"Part used"扮演"Part used in maintenance"，"Part"扮演"Part"。
相关模式：
如果你考虑类"Resource Maintenance"和"Part used in maintenance"，那么是"Transaction-Transaction Line Item"模式的一个特例[Coa 97]。如果你考虑类"Part"和"Part used in maintenance"，那么是"Item Line Item"模式的一个特例[Coa 97]。
下一模式：
现在，检查表1，看看是否有模式没有包括在内。
采用模式语言对一个小的汽车修理店应用系统建模。使用了模式（1）、（2）、（3b）、（3c）、（8）、（9）、（11）、（12）、（13）、（14）和（15）。图32描述了最终对象模型。表2汇总了模式语言在这个应用中的关系。按从上到下的顺序阅读"Repair subsystem"和"Purchase subsystem"，这个顺序与模式语言的描述一致。最终的对象模型可以为其它系统，如"Accounts Payable"/"Accounts Receivable"以及"Purchased part"/"Requested Parted"提供生成类。
本文的模式语言反映了十年资源管理系统开发的职业经验。它的应用使分析新系统变得容易，因为它为系统分析提供了指南，包括了这一领域需要注意的主要问题。我们计划扩展这种语言，包括仓储管理和更好地处理付款，基于这种语言的框架也会开发出来。
| 上一页 |