UML软件工程组织 |
业务资源管理模式语言概述(4)(2) |
作者:Rosana T. Vaccare Braga 等著,zhen_lei 译 |
略图:
图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"提供生成类。 本文的模式语言反映了十年资源管理系统开发的职业经验。它的应用使分析新系统变得容易,因为它为系统分析提供了指南,包括了这一领域需要注意的主要问题。我们计划扩展这种语言,包括仓储管理和更好地处理付款,基于这种语言的框架也会开发出来。
|
版权所有:UML软件工程组织 |