当我们进行业务流程分析时,只空对空而不落到纸面上是不可以的。过去,在面向过程的时代,我们绘制DFD图、流程图,以及编写流程说明来描绘这一部分分析;而现在,在面向对象的时代,我们则是绘制行动图、状态图,以及编写用例说明来完成这部分工作。
在这部分工作中,编写用例说明应当是最主要的工作,之后在一些关键部分辅之以行动图、状态图。现在我们来看看用例说明应当怎样编写。
毫不疑问,做用例分析首先是要绘制出用例图(前面已经说过了)。图形的最大优势是能够形象生动地描述我们的分析,但它最大的缺点是会遗失许多的细节信息,因此我们必须要对它进行进一步的文字描述。
由于不同的人对用例的理解不同,格式也不尽相同,但一些基本的元素是一样的。以上表格是我采用的用例说明格式,其中用例名称、用例描述、参与者、前置条件、事件流、后置条件是公认的、用例说明的基本元素。
用例标识:就是用例的编号,一般采用“项目编号-子系统编号-模块编号-序号”来编号。
用例名称:没啥可说的,就是用例图中该用例的名称。注意用例的命名规则:用例名称通常是一个动词短语或短句,而不是一个名词短语。它可以是一个动词(如:自动考核),一个动宾短语(如:提取存款),一个被动句(如:发票填报),或者一个主谓句(如:用户提款,这个不推荐,因为主语就是参与者,显得有些多余)。
用例类型:在我看来,不同类型的用例,其用例说明的格式是不一样的。以上给出的是“业务操作”类用例的格式,它更加着重地在描述业务操作的流程。而“查询报表”类用例则没有什么流程,它更加着重地在描述报表格式及显示内容(后面再给出)。还有用例类型还包括“子用例”、“扩展用例”。
用例描述:对该用例的功能定义、要实现的业务需求,以及谁(参与者)应该如何使用进行描述。同时,这部分还可以整体概述实现业务需求的主要流程,以及与其它用例、其它外部系统的关系。通过用例描述,阅读者可以对该用例有一个整体的认识。
参与者:用例图中该用例的参与者,通常是业务操作的触发者和施与对象(如外部系统)。
触发事件:谁干了什么,触发了这个用例。
前置条件:在触发该用例相关操作前必须达到的条件。