1、1,软件需求分析与建模-用例图建模,时间：2024年4月29日,软 件 需 求 分 析 与 建 模,2,用例模型和用例图,用例模型概述；用例图；建立用例模型的主要工作；用例模型(用例图)的建造；小 结。,软 件 需 求 分 析 与 建 模,3,I 用例模型概述,什么是用例？用例模型的意义；用例分析的目的；用例的属性；对用例图关心的人员。,软 件 需 求 分 析 与 建 模,4,什么是用例？,确定需求：软件开发中的一个致命的问题为此，各有关方面需要大量的交流，以增进对需求的了解。然而，对各方所关心的事情的描述却都是粗糙的（非形式化）、口头的或是一些杂乱的草稿，没有文档怎样描述用户所关心的事情？用
2、例是对（用户）所关心的事情的描述。,软 件 需 求 分 析 与 建 模,5,场景Scenario,场景：用户与系统之间的一个交互过程，即为实现这次交互所要经历的一系列步骤例：一个基于Web的在线购物站点的购物场景：主场景：顾客浏览了货单并将感兴趣的物品添加的购物筐中。如决定购买，则说明要购买的物品，提供信用卡信息并确认购物清单。系统将检查信用卡的合法性并确认销售结果。给客户发出确认电子邮件备选场景：信用卡失效,软 件 需 求 分 析 与 建 模,6,用例Use Cases,用例：一组场景，用以共同描述用户的某个特定的目标。例：购买商品用例主场景：顾客浏览货单并选择要买的商品顾客来付款顾客填写采
3、购信息（地址、隔天或3天送货）系统显示价目信息顾客填写信用卡信息系统检查信用卡的合法性系统确认销售系统给客户发出确认电子邮件,软 件 需 求 分 析 与 建 模,7,候选场景,候选场景：信用卡失效第6步，系统检查信用卡失败。允许客户重新执行第5步候选场景：固定客户3a.系统显示当前购物信息、价格信息、信用卡的最后四位数字3b.顾客接受或修改这些隐含值。转至主场景的第6步,软 件 需 求 分 析 与 建 模,8,用例模型的意义,用例模型对软件开发方法的研究具有重要意义：任何方法的首要问题是了解需求，而分析典型用例是用户和开发者一起了解需求、剖析需求和跟踪需求的有效工具。Jacobson首先提出用
4、例分析方法，对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度，是面向对象技术进入第二代的标志。,软 件 需 求 分 析 与 建 模,9,用例分析的目的,1.描述和决定系统的功能需求，帮助客户和软件开发人员形成一致意见。2.给出系统应该做什么且与内容一致的可视化描述，使之成为在开发全过程中研讨系统需求和进行系统设计的依据。3.在软件测试阶段作为系统测试的基础。建立系统实现的各个对象类和系统操作与功能需求之间的可追踪关系。,软 件 需 求 分 析 与 建 模,10,用例的一些基本特点,用例描述了用户提出的一些可见需求；用例可大可小例：10人年的项目，20-100个用例用例对应
5、一个具体的用户目标,从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互。以字处理程序为例，“将某些正文置为黑体”和“创建一个索引”便是两个典型的用例。从这两个例子中可以了解用例的一些特点：,软 件 需 求 分 析 与 建 模,11,对用例模型关心的人员,客户：他关心如何使用系统的功能；充当模型中的哪一个角色；如何调整模型可以更好地适应他们的愿望。开发人员：他需要理解系统的功能，以作为今后工作的基础和依据；在系统集成测试期间，可以使用这些用例测试系统。其他人员：销售人员，技术支持人员，文档编写人员等也关心用例图。,软 件 需 求 分 析 与 建 模,12,用例用于描述系统的功能，
6、这个功能是外部使用者看到的系统功能，不反映功能的实现方式,用例的特点(1),软 件 需 求 分 析 与 建 模,13,用例的特点(2),用例描述用户提出的一些可见需求，对应一个具体的用户目标。,数据上传,软 件 需 求 分 析 与 建 模,14,用例的特点(3),用例反映系统与用户的一次交互过程，应该具有交互的信息的传递。,帐户，密码，金额数,确认信息，帐户余额,软 件 需 求 分 析 与 建 模,15,II 用例图,用例图举例；用例图中的图符；用例图中的模型元素。,软 件 需 求 分 析 与 建 模,16,用例图举例（UML1.1）,软 件 需 求 分 析 与 建 模,17,用例图举例（UM
7、L1.3）,包含,贸易经理,设置边界,更新帐目,记帐系统,泛化,用例,执行者,包含,风险分析,交易估价,进行交易,超越边界,评 价,营销人员,销售人员,软 件 需 求 分 析 与 建 模,18,用例图中的图符（UML1.3）,执行者,系统,用例,关联,扩展,注释体,注释连接,包含,软 件 需 求 分 析 与 建 模,19,用例图中的模型元素：系统边界、执行者和用例,系统边界：一个提供“用例”所需要的功能的“黑盒 子”。系统的外部特性由系统的功能来定义；整个系统的功能用一组用例来描述。执行者：需要使用系统的任何外部实体(例如：人、其它系统或外部设备等)。用例：用客户或用户的语言和词汇来描述的系统
8、的一个完整功能。,软 件 需 求 分 析 与 建 模,20,用例图中的模型元素(续1)：关联、使用和 扩展,关联：连接执行者和用例，表示该执行者所代表的系统外部实体与该用例所描述的系统需求有 关。这是执行者和用例之间的唯一合法连接。包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能。扩展：由用例 A连向用例 B，表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况，即一种扩展。,软 件 需 求 分 析 与 建 模,21,参与者,1.参与者的概念 参与者（actor）是外部需要与系统交互的事物。也被称为活动者或执行者。2.参与者的三种类型.人：客户，读者，库管员.设备
9、：计算机，磁盘，读卡机等.外部系统：上层系统等,软 件 需 求 分 析 与 建 模,22,参与者可以表示为下面三种形式。,参与者的表示,软 件 需 求 分 析 与 建 模,23,参与者之间可以有泛化关系。,参与者之间的关系,当几种执行者所扮演的角色可以被泛化时，可以定义一个更抽象的角色。执行者是一个类,代表一种角色,而不是具体某个人,软 件 需 求 分 析 与 建 模,24,执行者的泛化：责任重叠,执行者可以通过泛化关系来定义，在这种泛化关系中，一个执行者的抽象描述可以被一个或多个具体的执行者所共享如系统中经理可以参加雇员的所有用例,软 件 需 求 分 析 与 建 模,25,用例之间的关系(1
10、),用例之间可以具有以下几种关系：关联关系泛化关系包含关系 扩展关系,软 件 需 求 分 析 与 建 模,26,关联关系 参与者与用例之间是关联关系，表示参与者与用例之间具有使用，交互信息的关联。,参与者与用例之间的关系,软 件 需 求 分 析 与 建 模,27,泛化关系 参与者与参与者之间，用例与用例之间存在一般与特殊的关系。,用例之间的关系(3),软 件 需 求 分 析 与 建 模,28,用例的泛化关系,同一业务目的不同技术实现：一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例）UML 1.5:用例间的泛化关系表明子用例继承父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中
11、所有的关系,软 件 需 求 分 析 与 建 模,29,包含关系 两个用例之间，一个用例(基本用例)的行为包含了另外一个用例(包含用例)的行为。包含关系用依赖关系的构造型来表示。,用例之间的关系(4),软 件 需 求 分 析 与 建 模,30,扩展关系 扩展关系表示基本用例在扩展点要增加新的行为或功能，以扩展到新用例。扩展关系用依赖关系的构造型来表示。,用例之间的关系(5),第一种表示,软 件 需 求 分 析 与 建 模,31,扩展关系,类似于泛化关系，但添加了一些新规则扩展用例可以在基用例之上添加新的行为，但是基用例必须声明某些特定的“扩展点”，并且扩展用例只能在这些扩展点上扩展新的行为。,罚
12、款,还书,扩展点：书到期,extend,第二种表示,建议采用第二种表示，注意箭头指向,软 件 需 求 分 析 与 建 模,32,扩展关系有一系列的扩展点名称，其个数与扩展用例中的片断数相等。每个扩展点必须在基用例中定义。使用扩展关系如下图：,软 件 需 求 分 析 与 建 模,33,软 件 需 求 分 析 与 建 模,34,III 建立用例模型的主要工作,定义系统；找出执行者；找出用例；描述用例；用例的整理与加工；验证模型。,软 件 需 求 分 析 与 建 模,35,用例图的作用,用例图用来描述软件需求模型中的系统功能，通过一组用例可以描述软件系统能够给用户提供的功能。用例图可以作为整个系统开发过程中的开发依据，指导和驱动其他模型。,软 件 需 求 分 析 与 建 模,36,用例图的形式,软 件 需 求 分 析 与 建 模,37,III.1 定义系统,