识别系统角色并建立系统功能模型
4280字,阅读需时15分钟

前面建立了系统的事件模型,现在我们来定义系统需求用到的另一个重要概念——事物。

1、识别系统的事物

事物不是指具体的人和事,事物是在系统中所扮演的角色。例如图书管理系统有管理员和借书者两个角色,小张既可以是管理员角色,也可以是借书者角色。一般说来系统需要存储事物的信息。例如,在图书管理系统,系统需要存储管理员角色和借书者角色的信息。

在电子图书在线阅读系统中,对于使用系统的用户来说,图书就可以看作是事物,并且是系统的一部分。另外,系统还需要存储用户的信息,因此用户也可以看作是事物,这些事物类似于与系统交互的外部实体或参与者,但又不同于外部实体,而是外部实体或参与者在系统中所扮演的角色。

系统需要存储的事物信息构成了事物的属性。例如在图书阅读系统中,图书事物书名、价格、页数、作者、ISBN、出版社等信息;用户有昵称、真实姓名、头像等信息。在定义系统需求阶段,我们需要明确每个事物的属性,一般选择其中一个属性用来唯一标识该事物。例如,ISBN可以作为图书的唯一标识。

在结构化开发方法中,这些事物构成了系统存储信息的相关数据。在面向对象方法中,这些事物就是在系统中相互交互的对象。无论使用哪一种开发方法,识别和理解这些事物都是关键的理解系统需求的初始步骤。

那么,如何识别新系统中的事物呢?前面已经定义了系统的事件表,我们可以从已定义的事件表中归纳出系统中的事物。

选择用户事件列表阅读图书事件,对事件做进一步分析,形成表格2-5。

01.PNG

事件的来源是该事件的外部实体或参与者,但不一定是系统中的事物,判断事件的来源是不是系统中的事物,关键是要看系统是否需要存储外部实体或参与者的信息。系统中阅读图书事件的来源是用户,用户是系统的外部实体。该事件的具体执行动作是判断用户是否具有阅读权限,然后再从服务器端获取图书内容,前置条件是用户已登录系统。从事件的执行动作和前置条件可以看出,系统需要存储用户的注册信息和图书阅读权限信息。因此用户是系统中的事物,不过系统中的这个用户事物不是指具体的人,而是表示人在系统中所扮演的角色。

另外从事件的执行动作和响应可以看出,用户的注册信息和图书内容都存储在服务端的数据库中,它是系统不可缺少的角色,系统所有的数据信息都要通过数据库存储起来。因此,数据库也是系统的事物。

事件的动作“判断用户是否具有权限阅读图书”会涉及订单,订单数据需要存储到系统中,因此订单也是系统中的事物。

系统运营者也需要登录系统,完成不同的功能,可以把系统运营者作为系统用户看待。

阅读图书事件的目的地是“移动端图书阅读页面”和“浏览器图书阅读页面”,客户端分为移动客户端和PC客户端,用户通过客户端与系统交互,客户端是系统的外部参与者,是用户同系统交互的载体,系统不需要存储客户端信息,因此客户端不属于系统事物。

从上面的分析可知,系统的事物为:用户、系统用户、图书、订单、数据库。

2、分析系统角色

用户、系统用户、图书、订单、数据库就是我们要分析的系统角色。系统角色并不是指具体的外部实体和参与者,而是系统中相互交互的对象。一个角色可能会对应多个外部实体或参与者,一个外部实体或参与者也可能会对应多个角色。

例如用户角色在系统中有属性和行为,属性有昵称、年龄、性别等,行为有登录、注册、选书、阅读图书等。在系统实际运行过程中,当用户张三登录系统时,此时用户角色就会对应张三这个人,当李四通过系统注册账号时,此时用户角色就会对应李四这个人。因此一个角色可能会对应多个外部实体与参与者。

一个外部实体或参与者也可能会对应多个角色。例如张三通过系统选书或阅读图书时,他对应的系统角色为用户,当张三通过系统管理图书时,他对应的系统角色为系统用户。因此,一个外部实体或参与者也可能会对应多个角色。

系统角色除了对应外部实体或参与者外,也会对应系统内部的功能对象。例如数据库对象用于存取其它角色的信息,因此数据库对象也是系统角色。

不同的角色在系统中有不同的工作。就如同一个软件项目开发团队,团队成员在项目团队中担任不同的角色,每个角色有不同的分工。项目经理角色负责项目的整体规划和进度管理;系统分析员角色负责项目的需求分析工作;系统设计师角色负责项目的技术架构和系统设计工作;编码人员角色负责项目的编码工作;测试人员角色负责项目的单元测试和系统测试工作。

在电子图书在线阅读系统中,有用户、系统用户、图书、订单和数据库五个系统角色。用户角色完成选书、购书、阅读图书等工作。系统用户完成图书上传、上架和下架等工作。用户和系统用户操作图书的功能要依赖于图书角色完成。订单将图书和用户关联起来,形成一对一的关系。数据库角色负责图书角色信息和用户角色信息在数据库的存取和查询工作。如图2-5所示。

02.png

图 25 系统角色关系图

前面分析了系统角色间的关系,下面我们再来看看角色的属性和行为。角色的属性就是系统要存储的信息,角色的行为就是角色在系统中担负的工作。

用户角色的属性有登录名(用户账号)、登录密码、年龄、性别、头像、电子邮箱。用户角色的行为有登录和注册、查询图书、订阅图书、购买图书、阅读图书、查看订单、意见反馈。

系统用户角色属性同用户属性完全相同。系统用户角色的行为有上传图书、图书上架和下架、订阅或订单汇总、处理用户反馈。

图书角色属性有图书名称、ISBN、作者、摘要、页数、价格、封面图片、关键词。图书角色行为有新增图书、图书信息编辑、图书状态修改、图书内容存取、图书查询。

订单角色属性有订单编号、图书唯一标识、用户唯一标识、订单创建日期、订单状态。订单角色行为有订单创建、订单删除、更新订单状态、订单查询。

数据库角色属性有数据库服务器地址、端口号、用户名、用户登录密码。数据库角色的行为有存取用户角色信息、存取图书角色信息、存取订单信息。

3、使用用例图描述系统功能

我们将使用UML建模语言的用例图对系统的角色及角色行为建立系统功能模型。

在建模之前,先简单介绍一下什么是UML建模语言。UML是面向对象开发的建模语言,由OMG(OMG是一个世界性的计算机标准协会),该协会致力于发展和传播面向对象系统,OMG在1997年公布了UML建模语言标准。UML定义了9种模型图,为软件开发过程的需求分析、系统设计、系统部署阶段提供建模支持,这9种模型图分别是用例图、类图、对象图、状态图、活动图、序列图、协作图、构件图和部署图。这些模型图从不同的侧面对系统进行建模。

在需求分析阶段,UML使用用例图、类图、协作图、顺序图和状态图从面向对象的角度出发来定义应用需求。在大多数情况下,为了得到一个完整的业务需求定义,这5种模型都要使用。但在系统功能相对简单的情况下,可以只使用用例图、类图、顺序图来定义需求。

用例描述了角色在系统中承担的职责,用例从系统角色的角度对系统功能进行建模。也可以说用例是事件表的延伸,事件表最先捕捉到系统需要响应的事件,然后通过事件表分析出系统角色,确定角色的属性和行为,最后再通过用例图对系统功能建模。

下图显示了一个用户注册的用例。一个简单的小人图形表示系统角色。这个小人图形有一个可以表示其角色的名字。用例用一个在里面标有名称的椭圆所代表,角色与用例之间的线条表示了角色参与哪些用例。如图2-6所示。

03.PNG

用例表明了角色与系统如何交互来完成业务活动,用例包含完成这个业务活动的所有步骤,这些活动步骤需要在用例中完整描述出来。一个用例可能会对应不同的活动场景,例如用户注册可能会对应在手机端注册和电脑端注册两种活动场景。所以,场景是对用例内部活动的识别和描述。

绘制用例图时,我们需要明确角色和用例,用例和用例之间的关系。角色和用例是关联关系,也就是角色参与到这个用例中,关联关系是一条直线(有些UML绘图工具也使用带单向箭头的直线),用于连接角色和用例。如图2-7所示。

04.PNG

用例和用例之间主要是包含关系、扩展关系和依赖关系。

包含关系

包含关系是指一个用例在执行过程中,会调用另外一个用例来完成相关任务,也就是在一个用例的内部包含了另外一个用例。例如,用户注册和用户登录用例都需要调用数据库角色的存储用户信息用例,在这种情况下,就可以把数据库角色的存储用户信息用例包含到用户注册和用户登录用例中。如图2-8所示。

05.PNG

扩展关系

扩展关系是一个用例对另一个用例功能的扩展。例如,用户注册有手机端注册和电脑端注册两个注册场景,则可以把用户注册作为基本用例,手机端注册和电脑端注册作为扩展用例。如图2-9所示。

06.PNG

依赖关系

依赖关系是一个用例在活动执行过程中,要依赖另一个用例的执行。例如,A用例依赖B用例,A用例或使用B用例执行后的返回结果,或使用B用例执行部分功能。依赖关系类似于包含关系,都是在用例执行过程中,调用其它用例来完成部分任务。

了解了用例的关系和绘制方法后,我们就可以根据前面给出的角色表来绘制电子图书在线阅读系统的用例图。

用户角色图例图(见图2-10)

用户角色用例有登录和注册、查询图书、订阅图书、购买图书、阅读图书、查看订单和意见反馈用例。这些用例包含或依赖于图书角色、订单角色和数据库角色的用例。

07.PNG

订单角色图例图(见图2-11)

订单角色用例有创建订单、更新订单状态、删除订单、订阅汇总、订单汇总、订单查询。这些用例了都使用了数据库角色的存取订单信息用例。

08.PNG

系统用户角色用例图、图书角色用例图、数据库角色用例图请读者自行给出。

用例规约

角色用例图确定后,还需要对每个用例配置用例规约,用例规约内容构成没有强制要求,以能够为面向对象设计提供充分的参考依据为原则。用例规约一般由用例编号、用例名称、用例参与角色、相关用例、前置条件、后置条件、输入数据、输出数据、活动步骤、业务规则等内容组成。

用例编号采用字母U开头加序号的编号规则,例如U001,U002等;用例名称就是用例的名字;用例参与角色是指在用例执行过程中参与的角色,也包括该用例依赖和包含其它用例的角色。

前置条件是指用例在执行前必须要满足的条件;后置条件是用例执行完成后需要执行的下一步操作要满足的条件,对于有多个事件流的用例,则应该有多个后置条件。

输入数据是指用例需要接收的数据;输出数据是用例需要输出的数据;活动步骤是指用例执行过程中的所有活动步骤;业务规则是指对用例的技术要求和约束,例如,在用户注册中要求用户输入的密码不能少于6位,并且是字母和数字的组合。

下面给出用户注册和登录用例规约,仅供读者参考。作为练习,请读者自行给出其他用例规约。

表格2-7给出了用户角色“注册用户”用例规约。

09.PNG

表格2-8给出了用户角色“用户登录”用例规约。

10.PNG

我要评论
全部评论