[软件工程5领域分析——2.用例图和活动图.pptxVIP

我们的进度，在这里图书管理系统——第2次课我们的进度，在这里工作任务根据访谈内容，进行业务用例建模根据访谈内容，进行业务流程的建模提交内容业务用例图业务流程活动图我们的进度，在这里工作任务1：业务用例建模交付的工作产品：业务用例图我们的进度，在这里学习情境知识点1：业务用例建模对应教材章节：第4章 4.3-4.9什么是用例图（Use Case Diagram）用例图的应用用例图的组成参与者、用例的识别用例建模技术什么是用例图(use case diagram)在UML中，一个用例模型由若干个用例图(use case diagram)描述。用例图是显示一组用例、参与者以及它们之间关系的图。用例图的应用用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为，因此，对整个软件开发过程而言，用例图是至关重要的。用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。让用户参与前期的系统分析与设计。分析和设计需求实现测试Use Cases 把所有这些过程绑到一起Use Case 对开发的意义大学信息系统的一个用例图用例图的组成用例（Use Case）参与者（Actor）关系(Relationship)什么是参与者参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。参与者可能是人、另外一个系统、时间的流逝等。UML中，参与者用“人形”图标来表示，名字写在图标的下方。什么是用例用例（use case）一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能） 。参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。 每个用例都必须有一个惟一的名字以区别于其他用例。用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。用例的UML图标如图所示。定义系统确定执行者和用例描述执行者和用例关系确认模型 如何建立用例模型 建立系统用例模型的过程就是对系统进行功能需求分析的过程。●确定系统范围；●分析系统功能。 ●执行者通常是使用系统功能的外部用户或系统。 ●用例是一个子系统或系统的一个独立、完整功能。确认用例模型与用户需求的一致性，通常由用户与开发者共同完成。各模型元素之间有：关联、使用、扩展及泛化等关系。用例建模技术识别参与者识别用例识别用例间的关系用例阐述识别参与者的方法谁使用系统的主要功能谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责日常维护、管理并保证系统正常运行系统需要应付（处理）那些硬设备系统需要和那些外部系统交互谁（或什么）对系统运行产生的结果（值）感兴趣时间、气温等内部外部条件识别参与者 客户给销售员发来传真订货， 销售员下班前将当日订货单汇总输入系统。 谁是系统的Actor？答案： 销售员识别参与者 商品销售系统。顾客通过网络下单之后，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的。 有几个Actor？答案： 顾客(商品销售系统)， 商品销售系统(会计系统)Example例：图书管理系统的参与者：借阅者（Borrower）图书管理员（Librarian）参与者的泛化参与者之间也可以象类一样存在泛化或者依赖关系。如系统中经理可以参加雇员的所有用例识别用例的方法①参与者希望系统提供什么功能；②系统是否存储和检索信息；如果是，这个行为由哪个参与者触发；③当系统改变状态时，是否通知参与者；④是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。 识别用例 Email客户端（如：outlook express），A在北京发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件。识别用例 一个论坛类的应用，用户可以提问，别人来回答，如果有自己问题被解答的话，就给发问者发一份邮件通知。注意：发邮件这个用例可以是单独的用例，也可以是由回答用例扩展出来的用例用例间、用例与参与者的关系1. 泛化关系（Generalization）：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化：2. 包含关系（Include）一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。3. 扩展关系（Extend）：一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。4.关联关系：关联关系表示参与者与用例之间的通信。四种关系的UML图释包含关系扩展关系泛化关系关联关系用例之间的关系泛化：同一业务目的的不同技术实现包含：提取公共交互，提高复用扩展：“冻结”基用例以保持稳定 *通过关系提高用例复用泛化(generalization) 当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用