4-图书管理系统-领域分析阶段.ppt

图书管理系统的业务流程建模 根据访谈分析业务流程 1.借书流程 图书管理员得到学生出示的借书证 图书管理员得到学生递给他的书 进行借书信息登记 我们的进度，在这里 我们的进度，在这里 2.还书流程 得到图书信息 查阅借书信息表 登记归还 我们的进度，在这里 我们的进度，在这里 3.借阅管理流程 4.图书管理流程 我们的进度，在这里 我们绘制了借阅管理的活动图之后，发现无法更清楚的描绘用户的业务情况，这说明 我们需要对办理借阅证这个动作状态和借阅证遗失补办这个动作状态进行进一步细化。 我们的进度，在这里 本次小节 在本次课中，我们学习了以下知识： 利用用例图进行业务建模的知识 利用活动图进行业务流程建模的知识 在领域分析中，我们可以根据与用户访谈的结果，进行业务用例建模，并为每个业务用例进行业务流程建模，帮助我们获取和分析用户实际业务情况，为下一步进行需求分析做准备。 课程小结 本次课中，用到以下知识 用户访谈 类的建模：类图 我们的进度，在这里 图书管理系统实例—领域分析阶段（2） 工作任务 根据访谈内容，进行业务用例建模 根据访谈内容，进行业务流程的建模 提交内容 业务用例图 业务流程活动图 我们的进度，在这里 我们的进度，在这里 工作任务1：业务用例建模交付的工作产品：业务用例图 学习情境知识点1：业务用例建模 1 概述 2 参与者 3 用例 4 用例建模 我们的进度，在这里 1 概述 画好用例图（Use Case Diagrams）是由软件需求到最终实现的第一步，在UML中用例图用于对系统、子系统或类的行为的可视化，以便使系统的用户更容易理解这些元素的用途，也便利软件开发人员最终实现这些元素。 UML中的用例图描述了一组用例、参与者以及它们之间的关系，因此用例图包括以下3方面内容 1）用例（Use Case）； （2）参与者（Actor）； （3）参与者之间的关系，泛化关系、包含关系、扩展关系等 我们的进度，在这里 2 用例（Use Case） 2.1 用例的概念 2.2 识别用例 2.3 用例与事件流 我们的进度，在这里 2.1 用例的概念 用例是对一个系统或一个应用的一种单一的使用方式所作的描述，是关于单个活动者在与系统对话中所执行的处理行为的陈述序列。 每个用例都必须有一个惟一的名字以区别于其他用例。 图形上用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。用例的UML图标如图所示。 我们的进度，在这里 2.2 识别用例 识别用例最好的办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。 在识别用例的过程中，通过以下的几个问题可以帮助识别用例： （1）特定参与者希望系统提供什么功能； （2）当系统改变状态时，通知参与者吗； （3）存在影响系统的外部事件吗； （4）是哪个参与者通知系统这些事件。 （5）系统是否存储和检索信息，如果是，这个行为由哪个参与者触发； 我们的进度，在这里 3 参与者（Actor） 参与者（Actor）是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由他们参与用例时所担当的角色来表示。 UML中，参与者用“人形”图标来表示，名字写在图标的下方。 我们的进度，在这里 3 参与者（Actor） 参与者一般分为三种： 系统用户 其他系统 可运行的进程 3 参与者（Actor） 在获取用例前要先确定系统的参与者，可以根据以下的一些问题来寻找系统的参与者。 （1）谁或什么使用该系统； （2）交互中，它们扮演什么角色； （3）谁安装系统； （4）谁启动和关闭系统； （5）谁维护系统； （6）与该系统交互的是什么系统； （7）谁从系统获取信息； （8）谁提供信息给系统； （9）有什么事发生在固定事件。 系统的主要功能使用者 系统的维护、管理人员 系统的硬件设备 对系统产生结果感兴趣的人 或者其他系统 3 参与者（Actor） 在建模参与者过程中，记住以下要点。 （1）参与者对于系统而言总是外部的，因此它们在你的控制之外。 （2）参与者直接同系统交互，这可以帮助定义系统边界。 （3） 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物。 （4）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。例如，某研究生担任某教授的助教，同职业的角度看，他扮演了两个角色——学生和助教。 （5） 每一个参与者需要有一个具有业务一样的名字，在建模中，不推荐使用诸如NewActor这样的名字。 （6）每个参与者必须有简短的描述，从业务角度描述参与者是什么。 （7）像类一样，参与者可以具有分栏，表示参与者属性和它可接受的事件。一般情