UML软件工程组织

业务资源管理模式语言概述(3)(2)
作者:Rosana T. Vaccare Braga 等著,zhen_lei 译

 

略图:

图16表示了TradeTheResource模式。交易与一个来源方,一个目的方和一个资源相关。使用ItemizeTheResourceTransaction(11)模式实现一次交易过程中处理多个资源。"Resource Trade"状态属性描述交易进展:正在执行,部分完成,完全完成。如果采用"QuantifyTheResource"模式中的"Resource Measurement"子模式,"Resource Trade"中包含一个表示量的属性。"Resource Trade"类中除了交易、取消交易以及获得未发货交易等方法外,还包括通过来源获得交易情况,通过目的获得交易和通过资源获得交易,如图16所示。



图16--TradeTheResource 模式


示例:

图17表示了TradeTheResource 模式的一个实例,在存货控制系统中,其中"Product"扮演"Resource","Purchase"扮演"Resource Trade","Supplier"扮演"Source-party","Store-branch"扮演"Destiny-Party"。



图17--TradeTheResource 模式实例


相关模式:

TradeTheResource是"Association-Object"模式[Boy98],和"Time-Association"模式[Coa 92]的特例。它也是"Participant-Transaction"和"Specific Item-Transaction"[Coa97]的组合应用。

下一模式:

交易下一个步骤是发货,采用CheckResourceDelivery模式(10)。也可以看第3节的模式,在对其它通用的事务细节建模时,它们非常有用。

模式9——MaintainTheResource(维护资源)


上下文

应用系统处理资源的维护和修理,象在模式6中描述的那样。你已经确定、分类、量化了应用软件需要管理的资源,也可能应用了QuoteTheMaintainence模式(6)。

问题:

如何在应用程序中控制资源维护?

约束:

· 保留维护信息对顾客和组织都很重要。如果维护不能令人满意的话,顾客有权投诉。为了财务上的目的,组织经常需要这些数据。如果这些信息不需要保留,一个简化处理方法是在资源类中加入一个属性保存上一次维修日期。

· 保存维修信息需要大量的存储资源,并且每个资源都有很多维修记录,需要花大量的时间来处理。

结论:

确定应用系统是否包括资源维护和修理。

解决方案:

创建与"Resource"类相关的"Resource Maintenance"类来控制维护过程。如果采用了"QuoteThe Maintenance"(6),将"Resource Maintenance"类与"Maintenance Quotation"类采用"0..1 to 0..1"关系相关联。因为询价后可能维护也可能不维护,维护前可能有询价过程,也可能没有询价过程。如果没有采用模式6,那么创建"Source Party"和"Destiny-party"与"Resource Rental"连接分别用来表示组织分支与顾客,道理与在模式4中描述的一样。

略图:

图18表示了MaintainTheResource模式,维护与一个来源方,一个目的方和一个资源相关。使用ItemizeTheResourceTransaction(11)模式实现一次交易过程中处理多个资源。在"Resource Maintenance"类中,必要的属性有"接收日期"和"离开日期"以及描述资源问题的"故障表现"。其它方法有:开始维修,注册待修资源,结束维修,完成维修,获得等待维修资源,获得未完成维修资源。通过来源获得维修、通过目的获得维修以及通过资源获得维修等方法添加到相关类中,如图18所示。



图18 --MaintainTheResource 模式


示例:

图19表示了MaintenanceTheResource模式的一个实例,在汽车修理店系统中,其中"Vehicle"扮演"Resource","Repair log"扮演"Resource Maintenance","Repair shop branch"扮演"Source-party","Customer"扮演"Destiny-Party"。



图19 --MaintainTheResource 模式实例


相关模式:

MaintainTheResource是"Association-Object"模式[Boy98],和"Time-Association"模式[Coa 92]的特例。它也是"Participant-Transaction"和"Specific Item-Transaction"[Coa97]的组合应用。如果你考虑类"Maintenance Quotation"(pattern 6)和"Resource Maintenance"(本模式),这里有一个"Transaction--Subsequent Transaction"pattern[Coa 97]的应用。

下一模式:

第3节的模式,利用它们详细说明其它细节。

模式10——CheckResourceDelivery(资源交付检查)


上下文

应用软件处理资源交易,可能是资源销售,也可能是购买资源。你已经确定、分类、量化了应用软件需要管理的资源,也可能应用了QuoteTheTrade模式(5),并且已经应用了TradeTheResource模式(8)。在有些系统中,需要提供一种检验交易发货的机制。例如,当你进行了一次采购,还没有获得货物,你会收到详细的采购清单。必须建立一种机制在增加库存前,检查与采购相关的交货。

问题:

如何管理应用系统的资源交付?

约束:

· 在有些应用系统中,只有当交货完成后才进行交易登记。因此,在其间不知道交易的事情。这就导致许多报告中缺乏细节信息。这种方法,虽然经济,但不反映实际情况。

· 如果检查仅仅是为了确认交易,在交易中添加一个表明交货日期的属性就可以了。但是,如果与交货相关的信息很多,并且对系统的效率有影响,那么就需要系统记录下来。

· 知道以前的交货情况对选择供应商非常重要。

· 当交货独立注册时存储空间和处理时间都要增加。

结论:

确认应用系统是否包括交货检查。

解决方案:

创建一个与"Resource"类相关的"Resource Delivery"类来控制资源交付的确认过程。因为交货是与交易相关的,"Resource"类与"Resource Delivery"类是"1 to 1"关系。如果你采用了子模式"Resource Measurement"或者采用了"ItemizeTheResourceTransaction"模式,这种关系会发生变化。

略图:

图20表示了CheckResourceDelivery模式。一次交货必然与一次交易相关,一次交易后必然有一次交货。使用ItemizeTheResourceTransaction(11)模式实现一次交易过程中处理多个资源。除了"Resource Delivery"中进行交货和取消交货方法外,根据资源获得交货方法被添加到"Resource"类中,将交易与交货相关的方法在"Resource Trade"类中,根据来源获得交货与根据目的获得交货应该放置在"Source-Party"和"Destiny-