在软件建模的过程中,分析建模是一个很重要的阶段,起作用是通过对业务的分析和抽象,提取出关键过程和实体,为设计做好基础。
分析建模主要包含两方面内容:
- 静态结构分析——主要工作是提取业务领域核心概念的类和对象。
- 用例分析——基于需求分析,对用例的实现过程进行分析。
1.要素:
- 事务:多为业务领域中的相对独立的业务,比如预订客房、借书、订餐等;
- 参与者:参与此业务过程的人,如客房预订系统的顾客;
- 地点:需要记录的事务发生的地点,如购物系统的收银机的位置(可通过编号记录);
- 物:涉及到的物品,例如图书管理系统的图书、订餐系统的饭菜等。
- 顺序型:事务与事务之间为顺序关系,某一事务完成后执行下一事务;
- 并发型:几件事务可在时间上同时执行;
- 嵌套型:某一相对复杂的事务中包含若干相对简单的事务。
通常事务和其细项(在学校和老师讨论时通常这么叫)之间多重性为一对多的关系,比如一份订单可对应多个订单物品,其他的多重性视具体情况而定。
好了,下面我们就通过一个例子来看看如何运用吧。以一个在线订餐系统为例:
首先我们来描述“订餐”这个事务,与其相关的有什么人呢?顾客自然是不可缺少的,还有谁呢?餐厅需要有人来处理顾客所下的订单,我们就把他叫做“业务员”,当然,还要有厨师来烹饪出美味可口的饭菜,不过此处我们的粒度逐步细化,厨师可以不需要直接参与处理订单的业务,所以此处不计。发生的地点呢?顾客无论是在办公室或是书桌前甚至是躺在床上拿着ipad,只要能够上网,进入订餐网站都可以进行订餐,业务员自然是在餐厅处理订单,于是我们先把“餐厅”加入我们的事务模式。相关的物品呢?订餐事务自然生成了订单,另外,顾客的一份订单可以包含一份或者多份饭菜,我们称之为“订单饭菜”。这样我们就有了与“订餐”相关的要素,对上面的图稍作修改,我们得到下图:
再考虑多重性:一个顾客可以多次订餐,而一次订餐事务是有一个顾客发起,所以“顾客”和“订餐事务”应该是一对多的关系,同理可得出业务员和订餐事务的关系。每次订餐生成一个订单,其多重性为一对一。每个订单有至少一份饭菜。于是我们修改上面的图:
这是个简单的例子,简要说明事务模式这种方法在分析建模中的应用,当然对这个例子还可以做进一步的分析,比如订单可以有多种状态,于是可以画出订单的状态图,饭菜可以有不同的分类,既可以通过“饭菜”类的属性区别也可以增加“类别”这个新类,订餐事务也可以进一步细分为:预订、审核、烹饪、送餐等事务,也就是事务的嵌套方式。
本人才疏学浅,这里只是自己的理解,与大家分享,不足之处还望多多指正。