当处理资源时，多种事务可能参与管理。以下7种模式关注这些资源管理事务。一个资源可以被预订（BookTheResource（4）），可以被出租一段时间（RentTheResource（7）），可以在购买之前询价（QuoteTheTrade（5）），可以被买或卖（TradTheResource（8）），可以有交货核查（CheckResourceDelivery（10）），可以在维修前询价（QuoteTheMaintenance（6）），可以进行维修（MaintainTheResource
上下文
你的应用软件处理资源出租，该资源可以是借给顾客一段时间的物品，也可以是由专家进行服务的一段时间。你已经确定、分类、量化了应用软件需要管理的资源。一些依赖资源出租的业务系统允许预先预订资源，在你想要的时间使用它。例如，在录像带出租店，经常要预订一个影片，主要是当它被其它顾客借走时。如果它没有被别人借走，预订就没有必要了。
问题：
如何在实际出租前管理资源预订。
约束：
· 仅仅在相关资源上加入一个预订状态会将预订的顾客数限制在一个。实际上，可以有多个顾客对一个资源感兴趣。
· 登记预订细节对好的资源管理是必要的，经常被预订的资源是库房中应该增加的候选者。
· 保留旧的预订信息会增加对存储的要求，分离的预订信息会占用多的处理时间。
结论：
确定你的应用是否需要资源预订。
解决方案：
建立一个与"Resource（资源）"类关联的"Resource Booking（资源预订）"类来表明预订资源过程的细节，如日期，期限，价格等。建立一个与"Resource Booking"类关联"Source Party（来源）"类表明组织中负责预订的分支机构或部门。建立一个"Destiny-Party（目的）"类表示要求预订的顾客或客户。在这个模式中，"Source Party"为可选项，因为在小系统中组织本身负责预订，没有必要创建一个类来表示。还提供了一个用来处理老的预订的操作，避免空间的浪费。
略图：
图8表示"BookTheResource"模式。预订与一个来源方，一个目的方和一个资源相关。使用ItemizeTheResourceTransaction（资源项事务）（11）模式来在一次预订中处理多个资源。在资源预订中有许多相同的属性，预订日期、客户希望租用的时间，租金（也就是顾客可以预付一部分租金），预订情况。也有公用的方法：预订资源和取消预订。以及通过来源获得预订、通过目的获得预订、通过资源获得预订等方法。如图8所示。
示例：
图9表示BookTheResource 模式的一个实例，在一个录像带出租系统中，其中"Video（影片）"扮演"Resource（资源）"，"Video Booking（录像带预订）"扮演"Resource Booking（资源预订）"，"Branch（分店）"扮演"Source-party（来源）"，"Customer（顾客）"扮演"Destiny-Party"。
变体：
预订与资源量化有关"QuantifyTheResource（3）"。例如，图书馆的情况，采用Resource Instance模式，预订的是资源，但实际出租的是样本。但是，一些情况下，图8中应将"Resource"替换为"Resource Instance"。 例如，在上面的录像带出租例子中，顾客可能希望预订原版带而不是翻译版本，这种情况下，最好不预订影片，而预订录像带本身，而录像带是资源实例。在这两个方案中进行选择非常重要。
相关模式：
"BookTheResource"是"Association-Object"[Boy 98]模式和"Time-Association"[Coa92]模式的特定应用。它也是"Participant-Transaction"和"Specific Item-Transaction"[Coa97]的组合应用。
下一模式：
在决定了是否可以进行资源预订后，下一个是"RentTheResource（7）"。也可以看第3节的模式，在对其它通用的事务细节建模时，它们非常有用。
上下文
应用系统处理资源交易，资源可能是组织买卖的商品。你已经确定、分类、量化了应用软件需要管理的资源。买卖商品的过程是一个由付钱获得商品一方计划的活动。例如，组织经常在决定是否交易前询问商品的价格。
问题：
在成交前如何保存资源询价的过程？
约束：
· 保存询价信息对处理买和卖同样重要。首先，制作比价图来支持决策；其次，提供给用户询价服务，系统可以跟踪没有成交的询价过程，提交给组织管理者以分析可能的竞争对手。
· 处理这些信息需要附加的空间和处理时间。
结论：
确定应用系统需要对资源销售或采购进行询价。
解决方案：
创建一个与"Resource（资源）"相关的"TradeQuotation（交易询价）"类表示询价的细节。同样创建与"BookTheResource（4）"相同的"Source-Party"和"Destiny-Party"。
略图：
图10表示QuoteTheTrade模式，询价与一个来源方，一个目的方和一个资源相关。使用ItemizeTheResourceTransaction（11）模式实现一次询价过程中处理多个资源。TradeQuotation属性包括：询价日期、询价有效期和价格本身。有将询价与交易关联的方法。图10中还表示了通过来源获得询价、通过目的获得询价等方法，在"Resource"类中增加了一个通过资源获得询价的方法。
示例：
图11表示了QuoteTheTrade模式的一个实例，在存货控制系统中，其中"Product"扮演"Resource"，"Purchase Quotation"扮演"Trade Quotation"，"Supplier"扮演"Source-party"，"Store-branch"扮演"Destiny-Party"。
变体：
根据量化模式的不同，"Resource"类可能被"Resource Instance"类替换。例如，如果资源的不同实例的价格不同，询价也不同。
相关模式：
QuoteTheResource是"Association-Object"模式[Boy98]，和"Time-Association"模式[Coa 92]的特例。它也是"Participant-Transaction"和"Specific Item-Transaction"[Coa97]的组合应用。
下一模式：
询价后要进行的就是交易，TradeTheResource（8）。也可以看第3节的模式，在对其它通用的事务细节建模时，它们非常有用。
上下文
应用系统处理资源的维护和修理。你已经确定、分类、量化了应用软件需要管理的资源。在这种情况下，资源基本上是用户的一个物品发生故障或需要定期维护。为了重新使用，它必须经过修理。或是为了防止发生故障在一定时期内必须进行维护。例如，汽车、电视、电子应用产品和计算机是在生命周期中经常发生故障的资源。许多顾客在修理前要做一下费用估算，因为如果修理费用与其本身价值相比的比率较高，修理就不值得了。
问题：
如何记录顾客针对维护的询价过程？
约束：
· 有时询价信息不重要，除非询价后有维修工作。在这种情况下，询价属性可以与维护属性放在一起。例如，在你把电视机送去修理之前，你会询问修理价格来决定是否修理。电视修理店可能想也可能不想记录一个没有修理的询价。
· 但是如果你去汽车修理店询价，你可能会付费，回答问题的工作人员会得到报酬。因此汽车修理系统需要记录询价过程，即使没有修理发生。
· 处理这些信息需要附加的空间和处理时间。
结论：
确定应用系统在实际维护前需要询价。
解决方案：
创建一个与"Resource"相关的"MaintenanceQuotation"类表示询价的细节。同样创建与"BookTheResource（4）"相同的"Source-Party"和"Destiny-Party"。
略图：
图12表示QuoteTheMaintenance模式，询价与一个来源方，一个目的方和一个资源相关。使用ItemizeTheResourceTransaction（11）模式实现一次询价过程中处理多个资源。QuoteTheMaintenance包括许多公用属性：询价日期、询价有效期和价格本身。还有公共的方法：询价和与维护关联（如果询价有效）。图12中还表示了通过来源获得询价、通过目的获得询价等方法，在"Resource"类中增加了一个通过资源获得询价的方法。
示例：
图13表示了QuoteTheMaintenance模式的一个实例，在汽车修理店系统中，其中"Vehicle"扮演"Resource"，"Repair Quotation"扮演"Maintenance Quotation"，"Repair shop branch"扮演"Source-party"，"Customer"扮演"Destiny-Party"。
相关模式：
QuoteTheMaintenance是"Association-Object"模式[Boy98]，和"Time-Association"模式[Coa 92]的特例。它也是"Participant-Transaction"和"Specific Item-Transaction"[Coa97]的组合应用。
下一模式：
维护询价完成后就是维护资源MaintainTheResource（8），也可以看第3节的模式，在对其它通用的事务细节建模时，它们非常有用。