略图：
图16表示了TradeTheResource模式。交易与一个来源方，一个目的方和一个资源相关。使用ItemizeTheResourceTransaction（11）模式实现一次交易过程中处理多个资源。"Resource
Trade"状态属性描述交易进展：正在执行，部分完成，完全完成。如果采用"QuantifyTheResource"模式中的"Resource
Measurement"子模式，"Resource Trade"中包含一个表示量的属性。"Resource Trade"类中除了交易、取消交易以及获得未发货交易等方法外，还包括通过来源获得交易情况，通过目的获得交易和通过资源获得交易，如图16所示。
示例：
图17表示了TradeTheResource 模式的一个实例，在存货控制系统中，其中"Product"扮演"Resource"，"Purchase"扮演"Resource Trade"，"Supplier"扮演"Source-party"，"Store-branch"扮演"Destiny-Party"。
相关模式：
TradeTheResource是"Association-Object"模式[Boy98]，和"Time-Association"模式[Coa 92]的特例。它也是"Participant-Transaction"和"Specific Item-Transaction"[Coa97]的组合应用。
下一模式：
交易下一个步骤是发货，采用CheckResourceDelivery模式（10）。也可以看第3节的模式，在对其它通用的事务细节建模时，它们非常有用。
上下文
应用系统处理资源的维护和修理，象在模式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所示。
示例：
图19表示了MaintenanceTheResource模式的一个实例，在汽车修理店系统中，其中"Vehicle"扮演"Resource"，"Repair log"扮演"Resource Maintenance"，"Repair shop branch"扮演"Source-party"，"Customer"扮演"Destiny-Party"。
相关模式：
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节的模式，利用它们详细说明其它细节。
上下文
应用软件处理资源交易，可能是资源销售，也可能是购买资源。你已经确定、分类、量化了应用软件需要管理的资源，也可能应用了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-Party"中。
示例：
图21表示了CheckResourceDelivery 模式的一个实例，其中"Product（产品）"扮演"Resource（资源）"，"Delivery（交付）"扮演"Resource Delivery（资源交付）"，"Purchase（购买）"扮演"Resource Trade（资源交易）"。
相关模式：
CheckResourceDelivery 模式是"Association-Object"模式[Boy98]，和"Time-Association"模式[Coa 92]的特例。它也是"Participant-Transaction"和"Specific Item-Transaction"[Coa97]的组合应用。如果你考虑类"Resource Trade"（模式8）和"Resource Delivery"（本模式），这里有"Transaction-Subsequent Transaction"模式[Coa 97]的一个应用。
下一模式：
第3节的模式，利用它们详细说明其它细节。
| 上一页 |