第3章 用例和用例图.pptVIP

3.1 用例 □ 用例(use case) Ivar Jacobson于20世纪60-70年代在爱立信公司开发AKE、AXE系列系统时发明的。 ○ 定义1：对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列。 ○ 定义2：用例是系统、子系统或类和外部的参与者(actor)交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。 3.1 用例 □ 在UML中，用例是用一个椭圆表示，用例名往往用动宾结构或主谓结构命名(如果是英文命名，则往往是动宾结构)。 【例3.1】 3.1 用例 【例3.2】在一个银行业务系统中，可能会有以下一些用例： ·浏览账户余额 ·列出交易内容 ·划拨资金 ·支付账款 ·登录 ·退出系统 ·编辑配置文件 ·买进证券 ·卖出证券 3.1 用例 □ 使用用例进行需求分析的特点： ① 从使用者的角度描述系统中的信息 站在系统外部看系统 ② 描述了用户提出的一些可见需求 对应一个具体的用户目标 ③ 对系统行为的动态描述 属于UML的动态建模部分 3.1 用例 UML建模： ① 静态建模 ② 动态建模 ◇ 静态建模：类图、对象图、构件图和部署图 ◇ 动态建模：用例图、顺序图、协作图、状态图和活动图。 3.1 用例 □ 理论上可以把一个软件系统的所有用例都画出来，但实际开发过程中，进行用例分析时只需把那些重要的、交互过程复杂的用例找出来。 □ 用例描述的是系统的功能性需求 3.1 用例 □ 用例的需求大纲 ·系统的目的和范围 ·系统中的术语表 ·用例 ·系统采用的技术 ·开发过程中的参加人员、业务规则、系统运行所依赖的条件、安全要求、文档要求等各种其它需求 ·法律、政治、组织机构等方面的问题 3.1 用例 □ 用例这种技术很容易使用，但也很容易误用。正确使用用例分析来做好领域建模（domain modeling），以确保定义正确的需求（right requirements），然后开发出正确的系统（right system），是保证OO软件开发成功的基础。对于初学者来说，掌握用例的概念并不难，但要在具体的项目中灵活地使用用例来捕获用户的需求，并不是一件容易的事情，往往需要用户的经验、沟通能力、丰富的领域知识等。 3.1 用例 □ 本质上，用例分析是一种功能分解（functional decomposition）的技术，并未使用到面向对象思想。因而有人认为用例分析只是面向对象分析与设计（Object-Oriented Analysis/Object-Oriented Design，OOA/OOD）的先导性工作，并非OOA/OOD过程的一部分，但也有人视其为OOA/OOD的一环。 3.1 用例 □ 用例是与实现无关（implementation independent）的关于系统功能的描述。在UML中，可以用协作（collaboration）来说明对用例的实现。 3.1 用例 □ 在UML中，协作用虚线椭圆表示。在图3.3中，对用例Login共有两个实现，一个是简单的实现，另一个是带有安全验证功能的实现，这里没有显示协作的内容结构和行为方面的内容。协作的内部由两部分组成：一是结构部分，如类、接口及其他一些建模元素等；另一部分是说明类、接口以及其他建模元素如何协同工作的行为部分，如协作图（collaboration diagram）、顺序图（sequence diagram）、类图（class diagram）等。 3.2 参与者 □ 参与者（actor）是指系统以外的，需要使用系统或与系统交互的东西，包括人、设备、外部系统等。 3.2 参与者 【例3.3】在一个银行业务系统中，可能会有以下参与者： ·客户：从系统获取信息并执行金融交易。 ·管理人员：开办系统的用户。获取并更新信息。 ·厂商：接受作为转帐支付结果的资金。 ·mail系统。 3.2 参与者 □ 参与者的3种表示形式 3.2 参与者 □ 参与者之间可以存在泛化关系 3.3 脚本 □ 脚本（scenario）也被翻译为情景、场景、情节、剧本等。在UML中，脚本指贯穿用例的一条单一路径，用来显示用例中的某种特殊情况。 □ 脚本是用例的实