软件建模的事务模式

在软件建模的过程中，分析建模是一个很重要的阶段，起作用是通过对业务的分析和抽象，提取出关键过程和实体，为设计做好基础。

分析建模主要包含两方面内容：

1. 静态结构分析——主要工作是提取业务领域核心概念的类和对象。
2. 用例分析——基于需求分析，对用例的实现过程进行分析。

事务模式（Transaction Pattern）是一种实用的静态结构分析方法，由Peter Coad提出。

1.要素：

• 事务：多为业务领域中的相对独立的业务，比如预订客房、借书、订餐等；
• 参与者：参与此业务过程的人，如客房预订系统的顾客；
• 地点：需要记录的事务发生的地点，如购物系统的收银机的位置（可通过编号记录）；
• 物：涉及到的物品，例如图书管理系统的图书、订餐系统的饭菜等。

2.事务的关系

• 顺序型：事务与事务之间为顺序关系，某一事务完成后执行下一事务；
• 并发型：几件事务可在时间上同时执行；
• 嵌套型：某一相对复杂的事务中包含若干相对简单的事务。

下面我们来看看事务模式的描述，如下图：

通常事务和其细项（在学校和老师讨论时通常这么叫）之间多重性为一对多的关系，比如一份订单可对应多个订单物品，其他的多重性视具体情况而定。

好了，下面我们就通过一个例子来看看如何运用吧。以一个在线订餐系统为例：

首先我们来描述“订餐”这个事务，与其相关的有什么人呢？顾客自然是不可缺少的，还有谁呢？餐厅需要有人来处理顾客所下的订单，我们就把他叫做“业务员”，当然，还要有厨师来烹饪出美味可口的饭菜，不过此处我们的粒度逐步细化，厨师可以不需要直接参与处理订单的业务，所以此处不计。发生的地点呢？顾客无论是在办公室或是书桌前甚至是躺在床上拿着ipad，只要能够上网，进入订餐网站都可以进行订餐，业务员自然是在餐厅处理订单，于是我们先把“餐厅”加入我们的事务模式。相关的物品呢？订餐事务自然生成了订单，另外，顾客的一份订单可以包含一份或者多份饭菜，我们称之为“订单饭菜”。这样我们就有了与“订餐”相关的要素，对上面的图稍作修改，我们得到下图：

接下来我们进一步分析：对于在线订餐的使用者——顾客，餐厅算是一个看不到的实体，订餐成功后会送餐上门，顾客可以完全不用进入餐厅就可完成订餐，于是我们将其ka掉。订单饭菜一定是餐厅菜单中有的，餐厅不提供的自然不会进入订单，所以我们就有了“饭菜”这个类。

再考虑多重性：一个顾客可以多次订餐，而一次订餐事务是有一个顾客发起，所以“顾客”和“订餐事务”应该是一对多的关系，同理可得出业务员和订餐事务的关系。每次订餐生成一个订单，其多重性为一对一。每个订单有至少一份饭菜。于是我们修改上面的图：

这是个简单的例子，简要说明事务模式这种方法在分析建模中的应用，当然对这个例子还可以做进一步的分析，比如订单可以有多种状态，于是可以画出订单的状态图，饭菜可以有不同的分类，既可以通过“饭菜”类的属性区别也可以增加“类别”这个新类，订餐事务也可以进一步细分为：预订、审核、烹饪、送餐等事务，也就是事务的嵌套方式。

本人才疏学浅，这里只是自己的理解，与大家分享，不足之处还望多多指正。