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

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