UML软件工程组织

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

 

当处理资源时,多种事务可能参与管理。其中有7种模式关注这些资源管理事务。在上一篇文章中,我们介绍了预定资源、交易询价和维护询价,本文将继续介绍余下的四种模式。


模式7——RentTheResource(资源出租)


上下文:

你的应用软件处理资源出租,该资源可以是借给顾客一段时间的物品,也可以是由专家进行服务的一段时间。你已确定出租前是否允许预订。

问题:

应用程序如何管理资源出租?

约束:

· 出租资源过程包含了很多细节信息。保存这些信息对出租资源管理非常重要。

· 出租情况的历史信息可以帮助管理者预计哪些资源值得投资。

· 必须特别注意,需要采用好的系统功能弥补附加的存储空间和处理时间。

结论:

确定应用系统是否允许资源出租。

解决方案:

创建与"Resource"类关联的"Resource Rental"类表示所有与出租相关的细节如日期、阶段、费用等。

略图:

图14显示了RentTheResource模式,出租与一个来源方,一个目的方和一个资源相关。使用ItemizeTheResourceTransaction(11)模式实现一次出租过程中处理多个资源。如果你采用"BookTheResource"模式(4),就要将"Resource Rental"类与"Resource Booking"类以"0..1 to 0..1"关系相连接,因为预订的结果可能出租也可能不出租,出租的物品可能经过预订,也可能不经过预订。这种情况下,不需要将"Source Party"和"Destiny-party"与"Resource Rental"连接,因为这种关系与预订相关的关系相同。如果你没有采用模式(4),也就是说,你的应用软件不需要预订功能,就要创建"Source Party"和"Destiny-party"与"Resource Rental"连接分别用来表示组织分支与顾客。资源出租有共同的属性:开始日期与结束日期,顾客支付的租费。还有一些通用的方法:出租资源,归还资源(当顾客交回资源时)和计算收入(例如每月计算)。图14中还显示了通过来源获得出租情况、通过目的获得出租情况等方法。


图14--RentTheResource模式


示例:

图15表示RentTheResource模式的一个实例,在一个录像带出租系统中,其中"Videotape(录像带)"扮演"Resource(资源)","Video Rental(录像带出租)"扮演"Resource Rental(资源出租)","Branch(分店)"扮演"Source-party(来源)","Customer(顾客)"扮演"Destiny-Party"。


图15--RentTheResource模式实例


相关模式:

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

下一模式:

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


模式8——TradeTheResource(资源交易)


上下文:

应用软件处理资源交易,可能是资源销售,也可能是购买资源。你已经确定、分类、量化了应用软件需要管理的资源,也可能应用了QuoteTheTrade模式(5)。资源交易可以看作资源所有权的转移,一方拥有的资源变为另一方所有。在销售过程中,如果没有库存资源,顾客可以填订购单。在采购过程中,系统需要向供应商请求,供应商在一定时间内将货物送到。

问题:

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

约束:

记录交易信息是基本功能,因为通过交易信息可以获得重要的资源需求报告(许多这一领域的系统关心利润)。

在做性能价格比分析时必须考虑到处理交易过程所需要的存储空间和时间。

结论:

确定应用系统是否有资源交易。

解决方案:

建立与"Resource(资源)"类相连接的"Resource Trade"类表示交易中的所有细节。如果采用了"QuoteTheTrade"(5),将"Resource Trade"类与"Trade Quotation"类采用"0..1 to 0…1"关系相关联。因为询价后可能成交也可能不成交,一笔交易前可能有询价过程,也可能没有询价过程。"Source-Party"总是表示资源原来的拥有者,"Destiny-Party"总是表示资源最终的拥有者。因此,在销售资源的情况下,"Source-Party"指组织的分支机构或部门,"Destiny-Party"指购买资源的顾客。在采购资源的情况下,"Source-Party"指供应商,"Destiny-Party"指采购资源的组织中的分支机构或部门。尽管应用了模式(5),你还是要将"Resource Trade"(此处原文似有误,译注)与"Source-Party"和"Destiny-Party"连接,因为询价可以进行多次,但实际的交易只有一次。

  下一页

 



版权所有:UML软件工程组织