图书管理系统-业务用例图

图书管理系统-业务用例图2020年3月计科系段恩泽email:[e-mail]教材学习线路图Chap1-4Chap5Chap6Chap7Chap8Chap9Chap10Chap11Chap12-13Chap14-16我们的重点是面向对象的软件工程主要内容(contents)•业务用例图图书管理系统需求描述(descriptions)•图书馆系统有借书者、普通管理员、系统管理员和一般浏览者四种角色。•一般浏览者是非图书会员，只能通过网络浏览图书馆的基本信息，如通过查询获取图书馆提供的各种服务信息。•借书者是图书馆的会员，拥有自己的账号，可以借阅图书。借书者能够从图书馆系统中借、还、续借和预约图书，还可以查询自己的借书信息和系统情况等。借书者可通过网络进行续借和预约图书。图书管理系统需求描述(descriptions)•普通管理员协助借书者完成借书、还书和续借服务。•系统管理员负责图书管理（如图书编目和图书登记）、借书者管理和普通管理员管理等任务。•本图书馆系统能够处理藏书200万册左右和4万左右的会员。•图书管理系统处理图书流通每次事务时间应小于8秒。业务建模(BusinessModeling)•任务1：–图书管理系统业务建模•要求：–根据访谈的结果，建立业务模型•工作产品：–业务用例图软件需求分析的任务(Task)•由于需求分析方法不同，描述形式不同。理解需求表达需求当前系统目标系统物理模型物理模型逻辑模型做什么逻辑模型模型化抽象化导出实例化具体化原系统新系统三个模型(ThreeModels)•功能模型：即用例模型，反映系统应该“做什么”•对象模型：构建分析类，使用类图、对象图描述对象、对象属性、对象之间的关系，是系统静态模型。•动态模型：利用活动图、时序图、协作图等描述系统动态行为。相关知识点(Knowledges)•用例图•参与者•用例•用例间的关系•用例建模用例（UseCase）•用例是待构造系统的使用场景，提供了系统将被如何使用的描述。•用例描述了由一系列执行的活动所产生的一些输出结果。每个用例描述了外部用户如何来触发系统必须响应的事件。用例图（UseCaseDiagram）•用例图（UseCaseDiagram）从用户的角度描述系统功能，指出各功能的执行者，用例图可使系统的用户更容易理解这些元素的用途，也便利软件开发人员最终实现这些元素。用例图（UseCaseDiagram）•UML中的用例图描述了一组用例、参与者以及它们之间的关系。因此用例图包括以下3方面内容–参与者（Actor）–用例（UseCase）–用例间的关系参与者（Actor）•参与者（Actor）是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由他们参与用例时所担当的角色来表示。•参与者一般可分为三类：–具体的系统用户–其他系统–可运行的进程参与者（Actor）如何识别参与者(IdentifyingActor)•在获取用例前要先确定系统的参与者，可以根据以下的一些问题来寻找系统的参与者。–谁或什么使用该系统；–谁安装系统；–谁启动和关闭系统；–谁维护系统；–与该系统交互的是什么系统；–谁从系统获取信息；–谁提供信息给系统；–有什么事发生在固定事件。•在用例图中，常使用泛化关系描述多个参与者之间的公共行为–例如学院的老师，分为专业教师和素质教师参与者之间的关系(Relations)练习(Exercise)•识别图书管理系统中的参与者及其他们之间的关系用例（UseCase）•用例的概念•识别用例用例的概念(Concept)•用例就是外部可见的系统功能。•用例包含了所必需的全部行为，即执行用例的主线次序、标准行为的不同变形及一般行为下的所有异常情况及其预期的反应。用例不是系统的功能需求或规格说明，其目的是要展示所描述过程中的需求情况。•用例的动态执行过程可以通过状态图、时序图、协作图来描述。用例的概念(Concept)•在UML中，用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。识别用例(Identifyingusecase)•从分析系统的参与者开始，考虑每个参与者是怎样使用系统。•在识别用例的过程中，通过以下的几个问题可以帮助识别用例：–特定参与者希望系统提供什么功能；–系统是否存储和检索信息，如果是，这个行为由哪个参与者触发；–当系统改变状态时，通知参与者吗；–存在影响系统的外部事件吗；–是哪个参与者通知系统这些事件。用例间的关系(relations)•泛化关系（Generalization）:一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化：•包含关系（Include）:一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。•扩展关系（Extend）:一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。用例的泛化关系（Generalization）•在WebShop电子商城后台系统中购物用户支付货款包括以下几种方式：网银支付、邮局汇款支付和支付宝支付。因此，网银支付、邮局汇款支付和支付宝支付与支付货款之间形成了泛化关系。用例的包含关系（Include）•图书管理系统中还书时，需要检查是否超期，而超期的检查主要是比较读者可用的借阅期限与实际借阅期限。•图书管理系统中借书时，需要设定归还日期，而归还日期为借阅日期加上读者可用的借阅期限。•可见借书和还书时都需要读取读者的借阅期限。为此，我们提取一个读取借阅期限的用例，这个用例可以被借书和还书复用。•借书、还书与读取借阅期限用例间的关系就是包含关系。用例的包含关系（Include）基本用例包含用例用例的扩展关系（Extend）•例购物时VIP客户可以打折扣用例图建模技术•对语境建模•对需求建模对语境建模•系统的语境指系统存在的外部环境。在UML语言中，利用用例图对系统的语境进行建模，强调的是系统的外部参与者。具体建模方法如下：–识别系统的外部参与者。–在需要加深理解的地方，为每个参与者提供一个构造型。–将参与者放入到用例图中，并说明参与者与用例之间的通信路径。–将类似参与者组织成泛化的结构层次。对需求建模•软件需求就是根据用户对产品功能的期望，提出产品外部功能的描述。需求分析所要做的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。一般要考虑系统做什么（what），而尽可能的不去考虑怎么做（how）。UML用例图可以表达和管理系统大多数的功能需求。对需求建模•对系统功能建模可以参考如下方法：–识别系统外部的参与者，从而建立系统的语境；–考虑每一个参与者期望的行为或需要系统提供的行为；–把公共行为命名为用例；–确定供其他用例使用的用例和扩展其他用例的用例；–在用例图中对这些用例、参与者和它们间的关系建模；–用描述非功能需求的注释修饰用例图。•内容：根据访谈内容，进行业务用例建模•交付：业务用例图现在的任务图书管理系统需求描述(descriptions)•图书馆系统有借书者、普通管理员、系统管理员和一般浏览者四种角色。•一般浏览者是非图书会员，只能通过网络浏览图书馆的基本信息，如通过查询获取图书馆提供的各种服务信息。•借书者是图书馆的会员，拥有自己的账号，可以借阅图书。借书者能够从图书馆系统中借、还、续借和预约图书，还可以查询自己的借书信息和系统情况等。借书者可通过网络进行续借和预约图书。图书管理系统需求描述(descriptions)•普通管理员协助借书者完成借书、还书和续借服务。•系统管理员负责图书管理（如图书编目和图书登记）、借书者管理和普通管理员管理等任务。•本图书馆系统能够处理藏书200万册左右和4万左右的会员。•图书管理系统处理图书流通每次事务时间应小于8秒。课上/后任务•在图书管理系统或自己组所选项目访谈记录的基础上，识别参与者、用例及其之间的关系，画出业务用例图•预习教材第6-7章，了解各用例的处理过程，要处理的数据及属性•预习7.2节，理解用例场景描述文档中的关键要素及含义