软件工程用例模型分析课件

用例模型用例模型简介用例建模技术用例模型用例模型用例建模1用例模型

(usecasemodul)在UML中，一个用例模型由若干个用例图(usecasediagram)描述。用例图是用于显示一组用例、参与者以及它们之间关系的图。用例模型

(usecasemodul)在UML中，一个用2系统是提供用例的黑盒子。其边界用矩形框表示，用例图中也可不画系统边界。用例图的组成用例（UseCase）参与者（Actor）关系（Relationship）系统（System）一个用例是可以被行为者感受到的、系统的一个完整的功能。

参与者是指在系统之外，透过系统边界与系统交互的任何事物，代表外部实体。可能是人、另外一个系统、时间的流逝等。

用例之间的关系有：扩展关系、使用关系和泛化关系。系统是提供用例的黑盒子。其边界用矩形框表示，用例图中也可不画3用例图的应用用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和外部可见行为。借助用例图，用户可以参与前期的系统分析与设计。用例图的应用用例图是从用户的角度来描述对软件产品的需求，分析4用例图对开发的意义实现测试需求分析和设计UseCases把所有这些过程绑到一起用例图对开发的意义实现测试需求分析和设计UseCases5用例模型用例模型简介用例建模技术用例模型用例模型用例建模6用例建模技术识别参与者识别用例识别用例间的关系用例阐述练习用例建模技术识别参与者识别用例识别用例间的关系用例阐述练习7识别参与者时需要思考的问题谁使用系统的主要功能谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责日常维护、管理并保证系统正常运行系统需要应付（处理）那些硬设备系统需要和那些外部系统交互谁（或什么）对系统运行产生的结果（值）感兴趣时间、气温等内部外部条件识别参与者时需要思考的问题谁使用系统的主要功能8例1：识别参与者寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；在这个叙述里，谁是寻呼台系统的Actor？例1：识别参与者寻呼台系统：用户如果预定了天气预报，系统每天9寻呼台系统用例图寻呼台系统用例图10参与者的泛化参与者之间也可以象类一样存在泛化或者依赖关系。参与者的泛化参与者之间也可以象类一样存在泛化或者依赖关系。11识别用例时需要思考的问题每个参与者的任务是什么由参与者将要创建、存储、改变、删除或读取系统中的信息吗什么用例会创建、存储、改变、删除、或读取这个信息参与者需要通知系统外部的变化吗需要通知参与者系统中正在发生的事情吗什么用例将支持和维护系统所有的功能需求都能被用例执行吗识别用例时需要思考的问题每个参与者的任务是什么12识别用例的注意事项注意事项：可观测→用例止于系统边界结果值→用例是有意义的目标系统执行→结果值由系统生成由参与者观测→业务语言、用户观点命名规则粒度大小识别用例的注意事项注意事项：13要点：用例止于系统边界描述交互，而不是内在的系统活动要点：用例止于系统边界描述交互，而不是内在的系统活动14要点：有意义的目标要点：有意义的目标15系统需要处理的，由系统生成要点：结果值由系统生成系统需要处理的，由系统生成要点：结果值由系统生成16用户词汇，而不是技术词汇如：发票，商品，洗衣机而不是：记录，字段，COM，C++等要点：业务语言而非技术语言要点：业务语言而非技术语言17用户观点系统观点要点：用户观点而非系统观点用户观点系统观点要点：用户观点而非系统观点18要点：用例的命名执行者视角：（状语）动词+（定语+）宾语要点：用例的命名执行者视角：19要点：用例的粒度(1)最常犯错误：粒度过细，陷入功能分解。过细的粒度，一般都会导致技术语言的描述，而不再是业务语言。要点：用例的粒度(1)最常犯错误：粒度过细，陷入功能分解。过20把步骤当用例把系统活动当用例要点：用例的粒度(1)把步骤当用例要点：用例的粒度(1)21要点：用例的粒度(2)“四轮马车”C(Create)

R(Read)

U(Update)

D(Delete)所有业务最终对会成为CRUD？CRUD能为Actor提供价值？CRUD掩盖业务，锐变成关系数据库的建模：“系统就是数据的增删改查”关心数据的存储和维护，反而忽略了用户的目的要点：用例的粒度(2)“四轮马车”22要点：用例的粒度(2)如果确实是CRUD？如果CRUD不涉及复杂的交互，一个用例“管理××”即可不管是C、R、U、D，都是为了完成“管理”目标甚至很多种的基本数据管理都可以用一个用例表示要点：用例的粒度(2)如果确实是CRUD？23Email服务器，A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件。例2：识别用例Email服务器，A在北京发邮件给上海的B，系统提醒B你有“24时间邮件服务器用例图时间邮件服务器用例图25识别用例间的关系<<include>><<extend>>ExtendIncludeGeneralization用例之间的关系有三种：扩展关系、使用关系和泛化关系。识别用例间的关系<<include>><<extend>>E26使用（Include）即在一个用例中重用另一个用例中的步骤。下订单检索客户信息<<include>>使用（Include）即在一个用例中重用另一个用例中的步骤。27包含关系的误用！包含关系的误用！28扩展关系（extend）扩展用例是在原用例的基础上增加新的步骤序列形成的。原用例被称为基用例（baseusecase）。扩展只能发生在基用例的序列中的某个具体制定点上，这个点叫做扩展点（extensionpoints）。扩展关系（extend）扩展用例是在原用例的基础上增加新的步29扩展关系VS包含关系在扩展关系中，基用例不必知道扩展用例的任何细节，事实上基用例没有扩展也是完整的，只有特定的条件发生了，扩展用例的行为才被执行。而包含关系则不同，没有被包含的用例，包含用例则不完整。扩展关系VS包含关系在扩展关系中，基用例不必知道扩展用30泛化关系（generalization）和类一样，泛化是指一个用例继承了另一个用例，在用例继承中，子用例可以从父用例继承行为和含义，还可以增加自己的行为。子用例可以出现在父用例出现的任何位置泛化关系（generalization）和类一样，泛化是指一31例3：用例之间的关系例3：用例之间的关系32例4：识别用例关系某电话公司决定开发一个管理所有客户信息的交互式网络系统。系统功能如下：浏览客户信息：任何使用Internet的网络用户都可以浏览电话公司所有的客户信息（包括姓名、住址、电话号码等）。登录：电话公司授予每个客户一个帐号。拥有授权帐号的客户可以登录系统。修改个人信息：客户登录系统后，可以对个人信息进行修改。删除客户信息：只有公司的管理人员才可以删除不再接受公司服务的客户的信息。【问题】在需求分析阶段，采用用例图描述系统功能需求，如下图所示，请指出图中的A、B、C和D分别是哪个用例？

例4：识别用例关系某电话公司决定开发一个管理所有客户信息的交33电话公司客户管理系统用例图电话公司客户管理系统用例图34电话公司客户管理系统用例图电话公司客户管理系统用例图35用例的描述三种常用形式摘要简介的一段式概要，通常用于主成功场景非正式非正式的段落格式。用几个段落覆盖非正式场景详述详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保障。用例描述是文本形式的。用例的描述三种常用形式36对用例摘要式描述登录：设定使用权限。用户提供用户名和密码，系统根据注册信息进行验证，通过后根据用户权限显示主界面。藏书管理：对个人拥有图书信息的管理。添加：登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统自动给出录入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为3星，最高等级为5级，最低等级为1级），数量（默认为1本，极个别情况会出现多本重复书籍）、归类（方便管理，可自己设定归类名称）。系统根据图书名称进行重复图书检查之后，将图书信息进行存储，并提示存储成功。系统重新显示初始录入界面，用户可以进行下一本图书的录入过程。查询：根据指定条件进行图书信息的查询，条件包括书名、作者、购买时间范围、喜爱程度、公开程度（是否进行晾晒）。修改：图书资料的内容有可能会出现偏差，通过信息修改功能改正偏差还书：将拣来的图书进行归还。从晒书场上捡来的图书到期后，拣书者应主动向藏书拥有者归还图书。系统在收到捡书者的归还请求后，自动向藏书拥有者发送提示信息。藏书拥有者在确定拿到图书后，通过系统进行确认彻底改变图书的状态（变为被晾晒图书，或收回私人藏书室）图书推荐：老师们可以推荐自己喜爱的图书，得到的推荐列表可以作为购买图书的依据。对用例摘要式描述登录：设定使用权限。用户提供用户名和密码，系37非正式形式的样例项目用例用例UC2：藏书管理对个人拥有图书信息的管理。用例UC2.1：添加藏书基本流程：藏书者登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统自动给出录入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为3星，最高等级为5级，最低等级为1级），数量（默认为1本，极个别情况会出现多本重复书籍）、归类（方便管理，可自己设定归类名称）。系统进行输入信息的有效性检查系统根据图书名称进行重复图书检查存储图书信息，并提示存储成功。系统重新显示初始录入界面，用户可以进行下一本图书的录入过程。分支流程：1.a、如果藏书者录入信息有误1、系统提示藏书者此信息2、返回添加藏书界面，界面保持原来填写数据3.a、如果图书名称发生重复，系统将提示此信息，并给出相应图书列表，用户可以查阅图书的详细信息，同时要求用户对此情况进行处理。1、如果确认图书录入重复，则系统放弃对当前图书信息的存储2、如果只是同名不同书，则用户确认此情况后，系统对当前录入的图书信息进行保存。非正式形式的样例项目用例用例UC2：藏书管理38详述形式的用例模板内容详述形式的用例模板内容39详述形式的样例项目用例

详述形式的样例项目用例40分支流程：

1.a、如果藏书者录入信息有误

1、系统提示藏书者此信息

2、返回添加藏书界面，界面保持原来填写数据

3.a、如果图书名称发生重复，系统将提示此信息，并给出相应图书列表，用户可以查阅图书的详细信息，同时要求用户对此情况进行处理。

1、如果确认图书录入重复，则系统放弃对当前图书信息的存储

2、如果只是同名不同书，则用户确认此情况后，系统对当前录入的图书信息进行保存。特殊需求：

希望能够上传图书封皮的小图像

希望系统能够对新录入的图书自动根据编码规则编号技术和数据变元表:

资料管理员在录入图书信息时，希望使用读卡器读取图书的ISDN号发生频率：阵发式杂项：

系统是否能够提供嵌入式的图像扫描功能，并自动转换成图书封面格式分支流程：

1.a、如果藏书者录入信息有误

1、系统提41整理后的用例图整理后的用例图42用例的可视化描述用例的可视化描述43练习1：网络在线售票订位系统的功能如下：参与者：客户、系统操作人员、系统维护人员各参与者的行为有：1、客户：执行在线订位、查询目前订位状况、在线执行付费处理（信用卡付费）、在线个人定位查询。2、系统操作人员：执行在线订位、查询目前订位状况、在线执行付费处理、在线定位状态查询3、系统维护人员：执行在线订位事件、在线定位状态查询、在线订位系统维护、系统环境设置【问题：】请依照上述分析并绘制出用例图练习1：网络在线售票订位系统的功能如下：44网络在线售票定位系统用例图网络在线售票定位系统用例图45用例模型用例模型简介用例建模技术用例模型用例模型用例建模46用例模型

(usecasemodul)在UML中，一个用例模型由若干个用例图(usecasediagram)描述。用例图是用于显示一组用例、参与者以及它们之间关系的图。用例模型

(usecasemodul)在UML中，一个用47系统是提供用例的黑盒子。其边界用矩形框表示，用例图中也可不画系统边界。用例图的组成用例（UseCase）参与者（Actor）关系（Relationship）系统（System）一个用例是可以被行为者感受到的、系统的一个完整的功能。

参与者是指在系统之外，透过系统边界与系统交互的任何事物，代表外部实体。可能是人、另外一个系统、时间的流逝等。

用例之间的关系有：扩展关系、使用关系和泛化关系。系统是提供用例的黑盒子。其边界用矩形框表示，用例图中也可不画48用例图的应用用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和外部可见行为。借助用例图，用户可以参与前期的系统分析与设计。用例图的应用用例图是从用户的角度来描述对软件产品的需求，分析49用例图对开发的意义实现测试需求分析和设计UseCases把所有这些过程绑到一起用例图对开发的意义实现测试需求分析和设计UseCases50用例模型用例模型简介用例建模技术用例模型用例模型用例建模51用例建模技术识别参与者识别用例识别用例间的关系用例阐述练习用例建模技术识别参与者识别用例识别用例间的关系用例阐述练习52识别参与者时需要思考的问题谁使用系统的主要功能谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责日常维护、管理并保证系统正常运行系统需要应付（处理）那些硬设备系统需要和那些外部系统交互谁（或什么）对系统运行产生的结果（值）感兴趣时间、气温等内部外部条件识别参与者时需要思考的问题谁使用系统的主要功能53例1：识别参与者寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；在这个叙述里，谁是寻呼台系统的Actor？例1：识别参与者寻呼台系统：用户如果预定了天气预报，系统每天54寻呼台系统用例图寻呼台系统用例图55参与者的泛化参与者之间也可以象类一样存在泛化或者依赖关系。参与者的泛化参与者之间也可以象类一样存在泛化或者依赖关系。56识别用例时需要思考的问题每个参与者的任务是什么由参与者将要创建、存储、改变、删除或读取系统中的信息吗什么用例会创建、存储、改变、删除、或读取这个信息参与者需要通知系统外部的变化吗需要通知参与者系统中正在发生的事情吗什么用例将支持和维护系统所有的功能需求都能被用例执行吗识别用例时需要思考的问题每个参与者的任务是什么57识别用例的注意事项注意事项：可观测→用例止于系统边界结果值→用例是有意义的目标系统执行→结果值由系统生成由参与者观测→业务语言、用户观点命名规则粒度大小识别用例的注意事项注意事项：58要点：用例止于系统边界描述交互，而不是内在的系统活动要点：用例止于系统边界描述交互，而不是内在的系统活动59要点：有意义的目标要点：有意义的目标60系统需要处理的，由系统生成要点：结果值由系统生成系统需要处理的，由系统生成要点：结果值由系统生成61用户词汇，而不是技术词汇如：发票，商品，洗衣机而不是：记录，字段，COM，C++等要点：业务语言而非技术语言要点：业务语言而非技术语言62用户观点系统观点要点：用户观点而非系统观点用户观点系统观点要点：用户观点而非系统观点63要点：用例的命名执行者视角：（状语）动词+（定语+）宾语要点：用例的命名执行者视角：64要点：用例的粒度(1)最常犯错误：粒度过细，陷入功能分解。过细的粒度，一般都会导致技术语言的描述，而不再是业务语言。要点：用例的粒度(1)最常犯错误：粒度过细，陷入功能分解。过65把步骤当用例把系统活动当用例要点：用例的粒度(1)把步骤当用例要点：用例的粒度(1)66要点：用例的粒度(2)“四轮马车”C(Create)

R(Read)

U(Update)

D(Delete)所有业务最终对会成为CRUD？CRUD能为Actor提供价值？CRUD掩盖业务，锐变成关系数据库的建模：“系统就是数据的增删改查”关心数据的存储和维护，反而忽略了用户的目的要点：用例的粒度(2)“四轮马车”67要点：用例的粒度(2)如果确实是CRUD？如果CRUD不涉及复杂的交互，一个用例“管理××”即可不管是C、R、U、D，都是为了完成“管理”目标甚至很多种的基本数据管理都可以用一个用例表示要点：用例的粒度(2)如果确实是CRUD？68Email服务器，A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件。例2：识别用例Email服务器，A在北京发邮件给上海的B，系统提醒B你有“69时间邮件服务器用例图时间邮件服务器用例图70识别用例间的关系<<include>><<extend>>ExtendIncludeGeneralization用例之间的关系有三种：扩展关系、使用关系和泛化关系。识别用例间的关系<<include>><<extend>>E71使用（Include）即在一个用例中重用另一个用例中的步骤。下订单检索客户信息<<include>>使用（Include）即在一个用例中重用另一个用例中的步骤。72包含关系的误用！包含关系的误用！73扩展关系（extend）扩展用例是在原用例的基础上增加新的步骤序列形成的。原用例被称为基用例（baseusecase）。扩展只能发生在基用例的序列中的某个具体制定点上，这个点叫做扩展点（extensionpoints）。扩展关系（extend）扩展用例是在原用例的基础上增加新的步74扩展关系VS包含关系在扩展关系中，基用例不必知道扩展用例的任何细节，事实上基用例没有扩展也是完整的，只有特定的条件发生了，扩展用例的行为才被执行。而包含关系则不同，没有被包含的用例，包含用例则不完整。扩展关系VS包含关系在扩展关系中，基用例不必知道扩展用75泛化关系（generalization）和类一样，泛化是指一个用例继承了另一个用例，在用例继承中，子用例可以从父用例继承行为和含义，还可以增加自己的行为。子用例可以出现在父用例出现的任何位置泛化关系（generalization）和类一样，泛化是指一76例3：用例之间的关系例3：用例之间的关系77例4：识别用例关系某电话公司决定开发一个管理所有客户信息的交互式网络系统。系统功能如下：浏览客户信息：任何使用Internet的网络用户都可以浏览电话公司所有的客户信息（包括姓名、住址、电话号码等）。登录：电话公司授予每个客户一个帐号。拥有授权帐号的客户可以登录系统。修改个人信息：客户登录系统后，可以对个人信息进行修改。删除客户信息：只有公司的管理人员才可以删除不再接受公司服务的客户的信息。【问题】在需求分析阶段，采用用例图描述系统功能需求，如下图所示，请指出图中的A、B、C和D分别是哪个用例？

例4：识别用例关系某电话公司决定开发一个管理所有客户信息的交78电话公司客户管理系统用例图电话公司客户管理系统用例图79电话公司客户管理系统用例图电话公司客户管理系统用例图80用例的描述三种常用形式摘要简介的一段式概要，通常用于主成功场景非正式非正式的段落格式。用几个段落覆盖非正式场景详述详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保障。用例描述是文本形式的。用例的描述三种常用形式81对用例摘要式描述登录：设定使用权限。用户提供用户名和密码，系统根据注册信息进行验证，通过后根据用户权限显示主界面。藏书管理：对个人拥有图书信息的管理。添加：登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统自动给出录入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为3星，最高等级为5级，最低等级为1级），数量（默认为1本，极个别情况会出现多本重复书籍）、归类（方便管理，可自己设定归类名称）。系统根据图书名称进行重复图书检查之后，将图书信息进行存储，并提示存储成功。系统重新显示初始录入界面，用户可以进行下一本图书的录入过程。查询：根据指定条件进行图书信息的查询，条件包括书名、作者、购买时间范围、喜爱程度、公开程度（是否进行晾晒）。修改：图书资料的内容有可能会出现偏差，通过信息修改功能改正偏差还书：将拣来的图书进行归还。从晒书场上捡来的图书到期后，拣书者应主动向藏书拥有者归还图书。系统在收到捡书者的归还请求后，自动向藏书拥有者发送提示信息。藏书拥有者在确定拿到图书后，通过系统进行确认彻底改变图书的状态（变为被晾晒图书，或收回私人藏书室）图书推荐：老师们可以推荐自己喜爱的图书，得到的推荐列表可以作为购买图书的依据。对用例摘要式描述登录：设定使用权限。用户提供用户名和密码，系82非正式形式的样例项目用例用例UC2：藏书管理对个人拥有图书信息的管理。用例UC2.1：添加藏书基本流程：藏书者登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统自动给出录入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为3星，最高等级为5级，最低等级为1级），数量（默认为1本，极个别情况会出现多本重复书籍）、归类（方便管理，可自己设定归类名称）。系统进