UML软件工程组织 |
业务资源管理模式语言概述(4)(1) |
作者:Rosana T. Vaccare Braga 等著,zhen_lei 译 |
在前面讨论的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"类,表示可能的事务负责人或团队。
|
版权所有:UML软件工程组织 |