业务资源管理模式语言17
示例：
图27 表示IdentifyTheTransactionExecutor 模式的一个实例，其中，“Sale”扮演“Resource Transaction”，“Salesman”扮演“Transaction Executor”
图27——IdentifyTheTransactionExecutor 模式实例
相关模式：
IdentifyTheTransactionExecutor 是“Participant-Transaction”模式的一个特例。
变体：
大型应用软件中，执行者可能是一个小组，因此可能有必要包括多个类，与Transaction Executor 连接，控制小组成员间的佣金分配。
下一模式：
如果你的业务与维护，那么确定是否需要IdentifyMaintenanceTasks（14）和IdentifyMaintenanceParts（15）。
否则，检查表1，看看是否有模式没有包括在内。
模式14 ——IdentifyMaintenanceTasks（确定维护任务）
上下文
应用软件处理资源维护，已经应用了MaintainTheResource(9)和其它可选模式6，11，12，13（或者是这些模式的组合）。当一个资源出现故障需要维护时，经常需要人力服务。例如，一辆有刹车故障的汽车可能需要更换刹车版，调节刹车线或者需要添加润滑油。有些情况下，每一种服务由不同的人提供。因此，确定资源维护过程中的任务就非常重要了。
问题：
如何确定维护业务或维护询价过程中的任务？
约束：
如果只需要关于维护动作的少量信息，只要在维护中加一个属性就可以了。但是，这样所有的维护情况就被限定在一定数量的任务内。如果数量少，可能不会覆盖所有情况，如果数量大，就会浪费空间。
许多系统希望将每个维护动作独立处理，这样可以使不同的维护情况便于控制和比较。这种信息可以提高对新情况的报价和工作安排。
结论：
确定资源维修是否包括多个任务，可能由不同的人执行。
解决方案：
为“Resource Maintenance”建立一个聚合类“Maintenance Task”，带有属性“需要解决的问题”，“人力描述”，“花费时间”和“成本”。
略图：
图28 表示IdentifyMaintenanceTasks 模式，一个维护可以有多个任务。“维护执行者”类是可选的，相当于图26 中的“Transaction Executor”类。是否使用该类取决于IdentifyTheTransactionExecutor 模式。如果采用，将它与“Maintenance Task”类（如果每个任务由不同的人完成）相连，如图28 所示，或是与“Resource Maintenance”类（如果整个维护工作由一个执行者完成）相连。
图28——IdentifyMaintenanceTasks 模式