【UML建模】二 售票系统建模案例

一 用例图

 

参与者包括售票员、监督员和公用电话亭。公用电话亭是另一个系统，它接受顾客的订票请求。在售票处的应用模型中，顾客不是参与者，因为顾客不直接与售票处打交道。用例包括通过公用电话亭或售票员购票，购预约票（只能通过售票员）以及售票监督（应监督员的要求）。购票和购预约票包括一个共同的部分—即通过信用卡来付钱。（对售票系统的完整描述还要包括其他一些用例，例如换票和验票等。）

二 顺序图

   

顾客在公用电话亭与售票处通话触发了这个用例的执行。顺序图中付款这个用例包括售票处与公用电话亭和信用卡服务处的两个通信过程。这个顺序图用于系统开发初期，未包括完整的与用户之间的接口信息。例如，座位是怎样排列的；对各类座位的详细说明都还没有确定。尽管如此，交互过程中最基本的通信已经在这个用例的顺序图中表达出来了。

三 协作图

 

 

订票涉及的各个对象间的交互关系。请求从公用电话亭发出，要求从所有的演出中查找某次演出的资料。返回给 t i c k e t s e l l e r对象的指针d b代表了与某次演出资料的局部暂时链接，这个链接在交互过程中保持，交互结束时丢弃。售票方准备了许多演出的票；顾客在各种价位做一次选择，锁定所选座位，售票员将顾客的选择返回给公用电话亭。当顾客在座位表中做出选择后，所选座位被声明，其余座位解锁。

四 状态图

    初始状态是 Av a i l a b l e状态。在票开始对外出售前，一部分票是给预约者预留的。当顾客预定个人票时，被预定的票首先处于锁定状态，此时顾客仍有是否确实要购买这张票的选择权，故这张票可能出售给顾客也可能因为顾客不要这张票而解除锁定状态。如果超过了指定的期限顾客仍未做出选择，此票将被自动解除锁定状态。预约者也可以换其他演出的票，如果这样的话，最初预约票也可以对外出售。

五 活动图

 

上演一个剧目所要进行的活动（这个例子仅供参考，不必太认真地凭着看戏的经验而把问题复杂化）。箭头说明活动间的顺序依赖关系—例如，在规划进度前，首先要选择演出的剧目加粗的横线段表示分叉和结合控制。例如，安排好整个剧目的进度后，可以进行宣传报道、购买剧本、雇用演员、准备道具、设计照明、加工戏服等，所有这些活动都可同时进行。在进行彩排之前，剧本和演员必须已经具备。

六 构建图

  

图中有三个用户接口：顾客和公用电话亭之间的接口、售票员与在线订票系统之间的接口和监督员查询售票情况的接口。售票方构件顺序接受来自售票员和公用电话亭的请求；信用卡主管构件用于处理信用卡付款；还有一个存储票信息的数据库构件。构件图表示了系统中的各种构件。在个别系统的实际物理配置中，可能有某个构件的多个备份。

图中的小圆圈代表接口，即服务的连贯集。从构件到接口的实线表明该构件提供的列在接口旁的服务。从构件到接口的虚线箭头说明这个构件要求接口提供的服务。例如，购买个人票可以通过公用电话亭订购也可直接向售票员购买，但购买团体票只能通过售票员。

 

七 部署图（描述层）

  

部署视图描述位于节点实例上的运行构件实例的安排。节点是一组运行资源，如计算机、

设备或存储器。这个视图允许评估分配结果和资源分配图中表示了系统中的各构件和每个节点包含的构件。节点用立方体图形表示 。

八 部署图（实例层）

九 包图

将整个剧院系统分解所得到的包和它们之间的依赖关系。售票处子系统在前面的例子中已经讨论过了，完整的系统还包括剧院管理和计划子系统。每个子系统还包含了多个包。

 

十 类图

 

售票系统的类图，它只是售票系统领域模型的一部分。图中表示了几个重要的类， 如C u s t o m e r、R e s e r v a t i o n、Ti c k e t和P e r f o r m a n c e。一个顾客可多次订票，但每一次订票只能由一个顾客来执行。有两种订票方式：个人票或套票，前者只是一张票，后者包括多张票。每一张票不是个人票就是套票中的一张，但是不能又是个人票又是套票中的一张。每场演出都有多张票可供预定，每张票对应一个唯一的座位号。每次演出用剧目名、日期和时间来标识。