需求分析师培训Day02课件

需求分析师培训Day022023/7/17需求分析师培训Day02Agenda需求分析最佳实践需求建模最佳实践用例驱动的需求过程实践需求分析师培训Day02Agenda需求分析最佳实践需求建模最佳实践用例驱动的需求过程实践需求分析是需求工程中的核心需求分析师培训Day02需求分析回顾所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明分析方法：结构化分析法、面向对象分析法、面向问题域分析法需求分析与需求捕获是交替进行的需求分析的结果将通过建模、规格说明

书编写的方式文档化需求分析师培训Day02需求分析最佳实践1定义系统边界：评估原始需求，定义将要开发的系统的边界；确定哪些是系统需求，哪些是和系统相关的操作过程的需求，哪些是在系统范围之外的需求

>主要效益：消除不必要的需求

>引入成本：低>应用成本：低

>实施指南：询问某项需求是否是基于不完整的或者不可靠的信息做出的？某项需求的实现

是否需要在系统已定义的数据库之外的

信息？某项需求是否和系统的核心功能

相关？某项需求是否牵涉到系统之外的

功能或者设备的性能？需求分析师培训Day02需求分析最佳实践2使用校验表进行需求分析：根据经验开发需求问题校验表，并将其用于需求的系统化分析，每一项需求都应按照校验表进行分析。

>主要效益：更快、更完整地进行需求分析

>引入成本：低-中>应用成本：低

>实施指南：校验表不超过10项

草率设计：该需求包括不成熟设计或实现信息吗？

组合需求：该需求是单独的需求还是可以细分为多个需求？

多余需求：该需求只是系统的修饰，还是真正必需？

使用非标准硬件：必须使用非标准的硬件还是软件？

符合业务目标：符合在需求文档开始处定义的业务目标？

需求多义性：不同人是否可以从不同方式来理解？

需求可实现性：基于当前技术，该需求可实现吗？

需求可测试性：是否能够判断系统是否符合需求需求分析师培训Day02需求分析最佳实践3使用软件支持协商：鼓励使用电子邮件来交换需求信息并且进行需求协商；也可以使用BBS、即时通信、群件系统来进行沟通与协商。

>主要效益：需求问题的更快解决

>引入成本：低-中>应用成本：低-中

>实施指南：电子邮件需指派一个问题管理人员，负责跟踪问题的提出、传递、回应和达成

解决方案；BBS方案需要限制讨论的长

度；群件方案需要事行定义好需求管理

项的结构需求分析师培训Day02需求分析最佳实践4对冲突和冲突解决方案做好计划：任何需求集中都会有冲突、重叠和遗漏问题，应该安排会议讨论这些需求并解决分析过程中发现的问题。

>主要效益：需求问题的更快解决

>引入成本：低>应用成本：低

>实施指南：会议是解决需求冲突最快的方式，应聚焦于解决突出的需求问题；电子信息交

换也是可取的方式之一；会议通常包括

叙述阶段、讨论阶段和决策阶段；分析

的结果要发给所有与会者需求分析师培训Day02需求分析最佳实践5需求分级：每一项需求都应该标上优先级，以反映它们对项目相关人员的重要性和对整个系统成功与否的重要性。

>主要效益：关注最重要的需求

>引入成本：低>应用成本：低

>实施指南：在需求捕获阶段就标明优先级是最理想的；通常需要进行了初始的分析工作才

可能分配优先级；优先级的分配要由需

求分析人员和项目相关人员共同完成；

优先级不应太多，如必须的、有用的、

希望的需求分析师培训Day02需求分析最佳实践6使用多维方法进行需求分类：应对需求进行分类以便标记相关的需求，不必将单个需求只归到一个类，可以派生出多种分类方法。

>主要效益：有助于发现需求重叠和冲突

>引入成本：低-中>应用成本：中

>实施指南：可用系统、用户界面、数据库、通信、安全来进行分类；建议最多有5~6个分

类；决定分类后，应把每个需求都和一

到多个关键词关联起来；分类完成后，

可以抽取很多组具有相同分类的需求进

行比较和分析需求分析师培训Day02需求分析最佳实践7使用交互矩阵发现冲突与重叠：交互矩阵的每一行和每一列都代表一项需求，每一个元素都用来表示对应的需求是否冲突、重叠或者独立

>主要效益：揭示需求重叠和冲突

>引入成本：低>应用成本：中-高

>实施指南：创建交互矩阵最简单的方法是使用电子表格程序，在首行、首列均标上需求标

识符；然后如果需求冲突填入1、重叠填

入1000，独立则填0；这样只需要用求

和的方式来统计出各种数目；通常需求

不应超过200条需求分析师培训Day02需求分析最佳实践8评估需求风险：对每一项需求或者一系列相关的需求进行风险分析，指出在实现需求过程中可能会发生的问题、这些问题发生的机率及其影响。

>主要效益：标识有问题的需求

>引入成本：中>应用成本：中

>实施指南：应考虑的风险主要有性能风险、安全风险、过程风险、实现技术风险、数据库

风险、日程风险、外部风险、稳定风险需求分析师培训Day02Agenda需求分析最佳实践需求建模最佳实践用例驱动的需求过程实践需求建模是表述需求的关键手段需求分析师培训Day02讨论在你的实践中是否建模？如果有建模，那么主要建哪些模型？有什么体会？如果没有建模，主要的原因是什么？

需求分析师培训Day02模型是对现实的简化需求分析师培训Day02建模的目的与原则帮助我们按照实际情况或按我们需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对我们所做出的决策进行文档化仅当需要模型时，才构建它选择要创建什么模型对如何动手解决问题和如何形成解决方案有着意义深远的影响；每一种模型可以在不同的精度级别上表示；最好的模型是与现实相联系的；单个模型是不充分的。对每个重要的系统最好用一组几乎独立的模型去处理。需求分析师培训Day02系统建模最佳实践1开发互补的模型：在单个模型中包含所有的系统规格说明信息是难以实现的，因为这样的系统将会特别复杂，不可能读懂，因此应该创建多个系统模型。

>主要效益：揭示规格说明中的错误和不一致

>引入成本：低-中>应用成本：中

>实施指南：通常会开发数据处理模型(DFD)、组合模型(E-R)、分类模型(类图)、刺激-响应模型(状态图、活动图)、过程模型等；选择什么模

型取决于要说明的信息类型、模型的读

者、模型开发者的技能、CASE工具需求分析师培训Day02系统建模最佳实践2系统环境建模：为了理解需求，应该就系统环境开发一个或多个模型，应该说明和本系统的接口和其他系统，以使用可能会使用本系统的业务过程。

>主要效益：记录必须说明接口的外部系统

>引入成本：低>应用成本：低

>实施指南：环境模型就是系统的使用语境模型，应包括和本系统直接交互的其他系统、可能和本系统共存并发生交互的系统、系统所在的业务

过程。需求分析师培训Day02系统建模最佳实践3系统体系结构建模：每次都应该开发系统的体系结构模型，用来说明系统是如何分解成子系统，还应解释子系统之间的通信。

>主要效益：有助于划分系统需求

>引入成本：低-中>应用成本：低

>实施指南：常用的体系结构模型包括客户机-服务器系统、分层系统、基于共享库通信的系统、管道系统需求分析师培训Day02系统建模最佳实践4用标准化方法进行系统建模：标准化方法是一种系统分析和设计方法，包括定义、开发和确认系统模型过程中用到的表示法、指南和规则。

>主要效益：使用标准的方式书写系统模型

>引入成本：中-高>应用成本：中

>实施指南：包括过程化(结构化)方法、面向对象方法，其主要包括一组推荐的系统模型和相应的开发该模型的表示法、一组建模规则、一组关

于创建高质量系统模型的指南、一份描

述、一些报告。需求分析师培训Day02系统建模最佳实践5使用数据字典：系统建模中使用的名字都应当记录在数据字典中，它是一份由计算机维护的名字列表以及相关的信息。

>主要效益：避免名字重复使用和误解

>引入成本：中>应用成本：低

>实施指南：进行数据字典的至少应包括模型中实体的名字、名字的别名及变化、实体类型、为何引入模型、针对实体的约束、指向相关实体的

链接；数据字典必须由一台服务器维护，

开发人员本机要与服务器经常实现同步需求分析师培训Day02系统建模最佳实践6记录项目相关人员需求和系统模型之间联系：记录项目相关人员用自然语言描述的需求和说明这个系统的具体模型之间的关系。

>主要效益：便列发现受变更影响的需求和模型

>引入成本：低>应用成本：中

需求分析师培训Day02UML基础需求分析师培训Day02UML发展历程需求分析师培训Day02UML特性与发展现状UML是一种Language（语言）UML是一种Modeling（建模）LanguageUML是Unified（统一）ModelingLanguage已进入全面应用阶段的事实标准应用领域正在逐渐扩展，包括嵌入式系统建模、业务建模、流程建模等多个领域成为“产生式编程”的重要支持技术：MDA、

可执行UML等需求分析师培训Day02为什么使用UML建模UML是一种统一的、标准化的建模语言UML是一种应用面很广泛的建模语言模型的种类模型的用途业务模型对业务过程、工作流、组织的建模需求模型对捕获的需求进行整理和分析的工具，辅助开发人员与用户进行沟通设计模型包含高层设计（架构模型）和详细设计模型，用于统一开发人员、沟通设计信息数据库模型设计数据库的结构、表结构以及与应用系统的交互实现模型用来理清软件的组成、部署方案，为安装与维护人员的工作提供指导需求分析师培训Day02草图和蓝图蓝图一般是指采用CASE工具绘制的、正式的、规范的UML模型草图则通常是指手工绘制的、规范度较低的在纸张的UML模型大胆地绘制草图，尽可能基于草图进行讨论。对于局部的、重要性不高的、共享范围较小的UML模型，直接将草图扫描到电脑存档即可；对于全局的、重要性高的、高度共享的，在草图的基础上用CASE工具绘制成为正式的蓝图，并将其纳入统一的模型管理中需求分析师培训Day02谁应该建模业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与设计模型：高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。详细设计模型则以资深开发人员为主，架构师提供指导。实现模型：以资深开发人员（设计人员）为主，架构师提供总体指导。数据库模型：以数据库开发人员为主，架构师提供指导，资深开发人员（设计人员）予以配合。需求分析师培训Day02常见认识误区UML是一种方法论UML就是一堆图形UML只能够应用于面向对象开发中UML就是Rose里的符号UML的学习周期很长、很复杂需求分析师培训Day02UML的组成基本构造块：也就是建模

元素，是模型的主体UML规则：也就是支配基

本构造块如何放在一起的

规则公共机制：运用于整个

UML模型中的公共机制、

扩展机制需求分析师培训Day02事物构造块事物构造块是对模型中最具有代表性的成分的抽象结构事物：UML中的名词，它是模型的静态部分，描述概念或物理元素。行为事物：UML中的动词，它是模型中的动态部分，是一种跨越时间、空间的行为。分组事物：UML中的容器，用来组织模型，使模型更加的结构化。注释事务：UML中的解释部分，和代码中的注释语句一样，是用来描述模型的。需求分析师培训Day02面向对象视角下的世界首先建立反应现实世界中不同事物的“构造块”，然后确定“构造块”之间的“关系”，再确定各个构造块的属性和“行为”。这样，在软件系统中就可以模拟现实世界的“构造块”之间的交互与协作面向对象软件开发的核心思想就是高内聚（封装）、低耦合（消息驱动），使用简洁的接口拼合简单的部件需求分析师培训Day02结构事物类（class）和对象（object）接口（interface）主动类（activeclass）用例（usecase）协作（collaboration）构件（component）节点（node）需求分析师培训Day02类和对象类是对一组具有相同属性、相同操作、相同关系和相同语义的对象的抽象UML中类是用一个矩形表示的，它包含三个区域，最上面是类名、中间是类的属性、最下面是类的方法对象则是类的一个实例需求分析师培训Day02接口接口是描述某个类或构件的一个服务操作集需求分析师培训Day02主动类主动类实际上是一种特殊的类。引用它的原因，实际上是在开发中需要有一些类能够起到

启动控制活动的作用主动类是指其对象至少拥有一个进

程或线程，能够启动控制活动的类需求分析师培训Day02用例与协作用例是著名的大师IvarJacobson首先提出的，现已经成为了面向对象软件开发中一个需求分析的最常用工具用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。

一个用例定义一组用例实例。协作定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他元素构

成的一个群体。对于某个用例的实现就可

以表示为一个协作需求分析师培训Day02构件在实际的软件系统中，有许多要比“类”更大的实体，例如一个COM组件、一个DLL文件、一个JavaBeans、一个执行文件等等。为了更好地对在UML模型中对它们进行表示，就引入了构件（也译为组件）构件是系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组外部接口。在系统中满足相同接口的组件可以自由地替换需求分析师培训Day02节点为了能够有效地对部署的结构进行建模，UML引入了节点这一概念，它可以用来描述实际的PC机、打印机、服务器等软件运行的基础硬件节点是运行时存在的物理元素，它表示了一种可计算的资源，通常至少有存储空间和处理能力需求分析师培训Day02行为事物交互（interaction）：是在特定语境中，共同完成某个任务的一组对象之间交换的信息集合交互的表示法很简单，就是一条有向直线，并在上面标有操作名状态机（statemachine）：是一个对象或交互在生命周期内响应事件所经历的状态序列在UML模型中将状态画为一个圆

角矩形，并在矩形内写出状态名

称及其子状态需求分析师培训Day02分组事物对于一个中大型的软件系统而言，通常会包含大量的类，因此也就会存在大量的结构事物、行为事物，为了能够更加有效地对其进行整合，生成或简或繁、或宏观或微观的模型，就需要对其进行分组。在UML中，提供了“包（Package）”来完成这一目标需求分析师培训Day02注释事物结构事物是模型的主要构造块，行为事物则是补充了模型中的动态部分，分组事物而是用来更好地组织模型，似乎已经很完整了。而注释事物则是用来锦上添花的，它是用来在UML模型上添加适当的解释部分需求分析师培训Day02关系构造块—关联关系关联（Association）表示两个类之间存在某种语义上的联系。关联关系提供了通信的路径，它是所有关系中最通用、语义最弱的。在UML中，使用一条实线来表示关联关系在关联关系中有两种比较特殊的关系：聚合和组合聚合关系：聚合（Aggregation）是一种特殊形式的关联。聚合表示类间的关系是整体与部分的关系如果发现“部分”类的存在，是完全依赖于“整体”类的，那么就应该使用“组合”关系来描述需求分析师培训Day02关系构造块—其他关系泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。实现关系是用来规定接口和实现接口的类或组件之间的关系。接口是操作的集合，这些操作用于规定类或组件的服务。扩展表示将一个构造型附加到一个元类上，使得元类的定义中包括这个构造型。有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。需求分析师培训Day02UML规则命名：也就是为事物、关系和图起名字。和任何语言一样，名字都是一个标识符范围：与类的作用域相似，包括所有者作用域和目标作用域两类可见性：可见性规则标准表示法Rose属性Rose方法public任一元素，若能访问包容器，就可以访问它+

protected只有包容器中的元素或包容器的后代才能够看到它#

private只有包容器中的元素才能够看得到它-

package只有声明在同一个包中的元素才能够看到该元素~需求分析师培训Day02公共机制—规格描述在图形表示法的每个部分后面都有一个规格描述（也称为详述），它用来对构造块的语法和语义进行文字叙述。这种构思，也就使可视化视图和文字视图的分离：需求分析师培训Day02公共机制—UML修饰与通用划分在为了更好的表示这些细节，UML中还提供了一些修饰符号，例如不同可视性的符号、用斜体字表示抽象类UML通用划分：

1）类与对象的划分：类是一种抽象，对象是一个具体的实例

2）接口与实现的分离：接口是一种声明、是一个契约，也是服务的入口；实现则是负责实施接口提供的契约需求分析师培训Day02UML扩展机制构造型：在实际的建模过程中，可能会需要定义一些特定于某个领域或某个系统的构造块需求分析师培训Day02UML扩展机制标记值：则是用来为事物添加新特性的。标记值的表示方法是用形如“{标记信息}”的字符串约束：是用来增加新的语义或改变已存在规则的一种机制（自由文本和OCL两种表示法）。约束的表示法和标记值法类似，都是使用花括号括起来的串来表示，不过它是不能够放在元素中的，而是放在相关的元素附近需求分析师培训Day02图名功能备注类图描述类、类的特性以及类之间的关系UML1原有对象图描述一个时间点上系统中各个对象的一个快照UML1非正式图复合结构图描述类的运行时刻的分解UML2.0新增构件图描述构件的结构与连接UML1原有部署图描述在各个节点上的部署UML1原有包图描述编译时的层次结构UML中非正式图用例图描述用户与系统如何交互UML1原有活动图描述过程行为与并行行为UML1原有状态机图描述事件如何改变对象生命周期UML1原有顺序图描述对象之间的交互，重点在强调顺序UML1原有通信图描述对象之间的交互，重点在于连接UML1中的协作图定时图描述对象之间的交互，重点在于定时UML2.0新增交互概观图是一种顺序图与活动图的混合UML2.0新增UML定义的图需求分析师培训Day02主要领域视图图结构静态视图类图设计视图复合结构图、协作图、构件图用例视图用例图动态状态视图状态机图活动视图活动图交互视图顺序图、通信图物理部署视图部署图模型管理模型管理视图包图特性描述包图UML视图和图需求分析师培训Day02UML图形分类需求分析师培训Day024+1视图需求分析师培训Day024+1视图用例视图：它是最基本的需求分析模型，是可被最终用户看到的系统行为的用例组成。常用的模型包括用例图、交互图、状态图、活动图等。设计视图：又称为逻辑视图，以问题域的语汇组成的类和对象集合，用来描述类、接口、协作。常用的模型包括类图、交互图、状态图、活动图等。进程视图：形成系统并发与同步机制的线程和进程，也就是将可执行线程和进程作为活动类的建模，可理解为设计视图的一次执行实例。它使用的模型与设计视图类似，区别在于更侧重于主动类。需求分析师培训Day024+1视图实现视图：对组成基于系统的物理代码的文件和组件进行建模，即装配与发布物理系统的构件和文件。常用的模型包括构件图、交互图、状态图、活动图。部署视图：包含了形成系统硬件拓扑结构的节点，也就是描述组件是如何物理地部署到一组物理的、可计算节点上的。常用的模型包括部署图、交互图、状态图、活动图。需求分析师培训Day02开发过程需求分析师培训Day02练习题如果你想对一个类的用途进行简要描述，那么应该采用

？请简要说明原因。

A.标记值B.规格描述C.注释D.构造型请列举出三个以上UML中的事物构造块。说说适合用来表示“系统向用户提供的功能”的构造块是什么适用于模型管理的是哪张图？下图所示的符号表示的是什么？它是关系构造块还是事物构造块？需求分析师培训Day02类图基础需求分析师培训Day02理解面向对象思想需求分析师培训Day02理解面向对象思想每个对象都扮演了一个角色，并为其它成员提供特定的服务或执行特定的行为。在面向对象世界中，行为的启动是通过将“消息”传递给对此行为负责的对象来完成的；同时还将伴随着执行要求附上相关的信息（参数）；而收到该消息的对象则会执行相应的“方法”来实现需求用类和对象表示现实世界，用消息和方法来模拟现实世界的核心思想需求分析师培训Day02如何用UML表示一个类名称：每个类都有一个惟一的名称，通常采用CamelCase格式表示属性：是已被命名的类的

特性，它描述该类实例中

包含的信息操作：是类所提供的服务，

它可以由类的任何对象请求以影响其行为属性名和操作名也通常采用CamelCase格式表示，只不过首字母通常为小写。

需求分析师培训Day02如何阅读类图先看清有哪些类，然后看

看类之间存在的关系，并

结合多重性来理解类图的

结构特点以及

各个属性和方

法的含义需求分析师培训Day02读图过程读出类：图中共有7个类，Order、OrderItem、Customer、Consignee、DeliverOrder、Peddlery、Prodcut读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。

1）OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderItem。

2）Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。需求分析师培训Day02读图过程多重性：用来说明关联的两个类之间的数量关系源类及多重性目标类及多重性分析Customer(1)Order(0…n)订单是属于某个客户的，网站的客户可以有0个或多个订单Order(1)Consignee(1)每个订单只能够有一个收货人Order(1)OrderItem(1…n)订单是由订单项组成的，至少要有一个订单项，最多可有n个Order(1)DeliverOrder(1…n)一个订单有一个或多个送货单说明：系统根据订单项的产品所属的商户，将其分发给商户，拆成了多个送货单！DeliverOrder(1)OrderItem(1…n)一张送货单对应订单中的一到多个订单项DeliverOrder(1)Consignee(1)每张送货单都对应着一个收货人Peddlery(1)DeliverOrder(0…n)每个商户可以有相关的0个或多个送货单OrderItem(1)Product(1)每个订单项中都包含着唯一的一个产品Peddlery(1)Prodcut(0…n)产品是属于某个商户的，可注册0到多个产品需求分析师培训Day02读图过程—理解方法和图Order类，有两个方法：dispatch()和close()，从名字中可以猜出它们分别实现“分拆订单生成送货单”和“完成订单”。而在DeliveOrder()类中则有一个Close()方法，同理它应该表示“完成送货”。而在OrderItem中有一个stateChange()方法和deliverState，不难猜出它就是用来改变其“是否交给收货人”标志位的需求分析师培训Day02读图过程—理解方法和图先调用Order的dispatch()方法，它将根据其包含的OrderItem中产品信息，来按供应商户分拆成若干个DeliverOrder。商户登录系统后就可以获取其DeliverOrder，并在执行完后调用close()方法。这时，就将调用OrderItem的stateChange()方法来改为其状态。同时再调用Order的close()方法，判断该Order的所有的OrderItem是否都已经送到了，如果是就将其真正close()掉

需求分析师培训Day02使用了更多建模元素的类图需求分析师培训Day02辅助建模符号导航箭号：类的实例之间只能沿着导航箭头的方向传递，在Order中可以获取其相应的Consignee，而从Consignee中是无法了解与其相关的Order的角色名称：Customer端有一个“+Owner”字符串，这表示Customer扮演的角色是Owner，也能对关联进行命名需求分析师培训Day02辅助建模符号导出属性：是指可以根据其他值计算出来的特性，这种属性应在其名称前加上一个“/”符号。限定符：在Order和OrderItem之间的组合关系中，OrderItem这端多了个方框，写着“ProductId”。在UML中称为限定符，存在限定符的关联称为受限关联。它用来表示某种限定关系。在本例中说明：对于一张订单，每一种产品只能用一个订单项约束：用来说明规则，{xor}…职责：在类的属性栏中添加注释行表示，或增加了一个新的分栏需求分析师培训Day02对象约束语言环境与约束：每个OCL表达式都必须是针对某个元素的，因此在OCL表达式前必须说明它针对元素（这就称为环境）

1）“contextObjectinv：”，其中Object是OCL表达式针对的建模元素名称；

2）“Object”，其中Object是OCL表达式针对的建模元素名称。

当声明了环境之后，就可以用self来引用它的变量

需求分析师培训Day02对象约束语言子集约束：一致性：一个客户拥有零个或多个合同，发票是基于某个合同的，而一个客户将收到零张或多张发票

Invoice：self.contract.customer=self.customer需求分析师培训Day02对象约束语言异或关系：规定的取值范围：

Rectangle：length>0andwidth>0需求分析师培训Day02用类图表示软件系统模型领域模型是从面向对象视角看待现实世界的结果，也就是通过类图描述现实世界中各种事物的关系。分析模型和领域模型很相近，分析模型主要是针对软件系统，领域模型则更多偏重对业务领域的分析设计模型则是在分析模型的基础上添加设计元素的结果。设计模型中的类的属性集更趋完善。需求分析师培训Day02用类图表示数据库逻辑模型从某种意义上说UML中的类图是E-R图的超集，E-R图只针对存储的数据，而类图则在些基础上，增加了行为建模的能力。在使用类图来表示E-R模型时，要注意遵循以下策略将表示E-R模型的类，用UML的标准构造型“{persistent}”来表示；展开类的结构性细节，并加强关联和多重性分析；尽量消除循环关联、n-元关联需求分析师培训Day02最常见的域建模错误10.立即给关联指定多重度(multiplicity)，确保每个关联都有明确的多重度。9.对名词和动词做过度的分析，而背离初衷。8.不对用例和时序图进行研究，就将操作分配给类。7.对象和类的通用程度越高，在其他项目中重用它们的可能性就越大。6.对于每个“…一部分(part-of)”关联，就使用聚集还是组合(composition)而争论不休。需求分析师培训Day02最常见的域建模错误5.未对问题空间进行建模之前，就假定一种具体的实现策略。4.将类命名为难以理解的名称cPortMgrIntf)，而不是直观的名称(如PortfolioManager)。3.直接进入到实现结构，如友元关系和参数化类。2.在域类和关系型数据库表之间建立一对一的映射。1.过早地执行“模式化”，这将导致根据同用户问题毫无关系的模式创建解决方案。需求分析师培训Day02练习一下图是一个仓库管理系统的类模型局部，其中IncomeOrder是指入库单，OrderItem是指入库中的每一项，Product则是产品信息。请指出模型中的错误，说明原因并改正错误需求分析师培训Day02练习二在描述“税务审批服务

申请”时，它主要包含

哪几个方面的内容？它有几

种不同的类别?对于每一条流转记录，可

能与几个“税务审批服务

申请”相关？与几个处理

人相关？需求分析师培训Day02练习三3过早考虑

实现阶段

的内容需求分析师培训Day02练习四48LoginManager4.名字不直观

8.太早定义类

的操作需求分析师培训Day02练习五4564.名字不直观

5.指定实现方

式—EJB6.过早考虑聚

合或组合ShoppingCart需求分析师培训Day02练习六28102.与数据库表

一一对应8.过早分配类

的操作10关联多重性Order需求分析师培训Day02练习七1251.使用了设计模式：Proxy；2.price、quan…publisher可能

成为关联类；5.用了Java中

的Vector需求分析师培训Day02练习七需求分析师培训Day02练习八585.使用了构造

型8.过早分配类

的操作CandldateOrderCustomerReview需求分析师培训Day02练习九：根据下面描述绘制类图这是一个“碟片出租店”使用的系统，它将用于计算每一位顾客的消费金额并打印报表。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租凭时间和影片类型算出费用。影片分三类：普通片、儿童片和新片。除了计算费用，还要为常客计算机点数；点数会随着“租片种类是否为新片”而有所不同。需求分析师培训Day02练习九解答1这是一个“碟片出租店”使用的程序，它将用于计算每一位顾客的消费金额并打印报表。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租期和影片类型算出其消费金额。

影片分三类：普通片、儿童片和新片。除了计算消费金额，还要为常客计算累积点数；累积点数会随着“租片种类是否为新片”而有所不同。需求分析师培训Day02练习九解答2这是一个“碟片出租店”使用的程序，它将用于计算每一位顾客的消费金额并打印报表。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租期和影片类型算出其消费金额。

影片分三类：普通片、儿童片和新片。除了计算消费金额，还要为常客计算累积点数；累积点数会随着“租片种类是否为新片”而有所不同。碟片出租店程序消费金额报表操作者顾客影片租期影片类型普通片儿童片新片累积点数需求分析师培训Day02练习九解答3碟片出租店程序消费金额报表操作者顾客影片租期影片类型普通片儿童片新片累积点数在系统外系统本身应该是每次“交易”属性类！在系统外在系统外，但需记录，类！类！属性影片的属性类！类！类！顾客的属性报表顾客影片普通片儿童片交易新片需求分析师培训Day02练习九解答4需求分析师培训Day02练习十下图是小张绘制的一张关于网上商城用户管理的领域类图，但其中存在一些问题，请指出错误并说明理由需求分析师培训Day02讨论类图有什么用？用类图对领域进行建模时，主要的困难在于哪些方面？需求分析师培训Day02交互图基础需求分析师培训Day02交互的概念一次交互就是指在特定语境中，为了实现某一个目标，而在一组对象之间进行交换的一组消息所表示的行为在大多数的情况下，消息通常是指启动一个操作，或发送一个信号，以及创建或销毁一个对象由一条有方向的直线，加上名称、参数（可选）和顺序组成需求分析师培训Day02四种交互图顺序图：强调消息时间顺序。首先把参与交互的对象放在图的上方，沿X轴方向排列。通常把发起交互的对象放在左边，较下级对象依次放在右边。然后，把这些对象发送和接收的消息沿Y轴方向按时间顺序从上到下放置。读者提供了控制流随着时间推移的清晰的可视化轨迹。协作图：在UML2.0中称为通信图，强调的是参加交互的对象的组织。首先将参加交互的对象作为图的顶点，然后用这些对象之间的边线表示为图的边，再使用对象发送和接收的消息来修饰这些边。为读者提供了在协作对象结构组织的语境中观察控制流的一个清晰的可视化轨迹需求分析师培训Day02四种交互图定时图：采用了一种带数字刻度的时间轴来精确地描述消息的顺序，而不是像顺序图那样只是指定消息的相对顺序。而且它还允许可视化地表示每条生命线的状态变化，当需要对实时事件进行定义时，定时图就可以很好地满足交互概述图：是交互图和活动图的混合物。你可以把交互概述图想像为活动图，只不过其中的活动被换成了一些小型顺序图；也可以把其想像为利用标明控制流的活动图分解过的顺序图需求分析师培训Day02阅读顺序图需求分析师培训Day02顺序图的主要元素对象与角色：最顶上一排矩形框。在交互图中，参与交互的对象既可以是具体的事物，又可以是原型化的事物。作为具体的事物，一个对象代

表现实世界中的某个东西。例如，aOrder

作为类Order的一个实例，可以代表一个

特定的订单；而如果作为一个原型化的事

件，则aOrder可以代表类Order的任何一

个实例。生命线与控制焦点：每个对象都有自己的

生命线，对象生命线是一条垂直的虚线，

用来表示一个对象在一段时间内存在。需求分析师培训Day02顺序图的主要元素消息：用来描述对象之间所进行的通信的，该信息带有对将要发生的活动的期望。当传送一个消息时，它所引起的动用是一个通过对计算过程的抽象而得到的可执行语句。消息分为五种：调用、返回、发送、创建和销毁调用：表示调用某个对象一个操作

需求分析师培训Day02顺序图的主要元素返回：表示被调用的对象，向调用者返回一个值发送：发送是指向对象发送一个信号，和调用不同，它是一种事件，用来表示个实例间进行通信的异步激发机制

创建和销毁：就是创建和销毁一个对象。需求分析师培训Day02顺序图的主要元素顺序编号：整个消息的传递过程就形成了一个完整的序列，因此通过在每个消息的前面加上一个用冒号隔开的顺序号来表示其顺序。除了顺序编号之外，还可以采用嵌套方案：需求分析师培训Day02顺序图的主要元素循环与分支需求分析师培训Day02读图小结在dispatchForm（分发窗体）中，对于某个已支付的Order进行分发时，就会调用该订单（一个Order类的实例对象aOrder）的dispatch()方法。dispatch()方法将逐个调用该Order对应的所有OrderItem对象的getPeddleryId()方法还获取供应商ID（PeddleryId），而OrderItem对象则是通过其所对应的Product对象来的getPeddleryId()方法来获取供应商ID。需求分析师培训Day02读图小结当Order的实例对象aOrder得到返回的PeddleryId后，根据该值判断是否已经有相对应的DeliverOrder对象，如果没有就创建它（调用create(PeddleryId)），然后再将对应的Product添加到这个DeliverOrder对象中。否则就直接添加到相应的DeliverOrder对象中。需求分析师培训Day02阅读协作(通信)图需求分析师培训Day02协作图的主要元素链：连接器，是用来表示对象之间的语义连接，一般而言，链是关联的一个实例（包括《association》、《self》、《global》、《local》等）。不过在UML2中已经开始弱化它们的使用，因此除非必要，无需过多地考虑它们消息编号：消息的编号有两种，一种是无层次编号，它简单直观；另一种是嵌套的编号，它更易于表示消息的包含关系迭代标记：用*号表示，表示循环，通常还有迭代表达式，用来说明循环规则需求分析师培训Day02协作图的主要元素监护条件：通常是用来表示分支的，也就是表示“如果条件为true，才发送消息”在通信图中使用监护条件一定要有所限制，通常应只列出主要的监护条件，否则会影响其阅读。如果需要，尽可能还是通过顺序图来表示需求分析师培训Day02交互建模的准备工作首先根据自己的喜好和实际的表现需要来选择顺序图或通信图。不过由于它们在语义上是等价的，因此可以绘制出一种，再通过建模工具来自动转换成另一种图分析模型中的交互图彻重于分析类的职责分配和交互流程，而设计模型中的交互图则彻重于设计类的引入和实际方法的调用与流程控制先确定参与交互的对象、对象之间的关系(通信图)，然后确定对象间的消息交互流程(用同步调用、异步消息、返回消息表示)，并利用交互片断(顺序图)或迭代标记及监护条件来表示循环和分支结构需求分析师培训Day02交互建模—Robustness分析Robustness分析不是UML模型的一部分，它是一个强大的草图工具，是介于分析和设计之间的一种有效工具在Robustness分析中，将应用边界类、控制类和实体类从一个用例中抽取三类对象的方法：需求分析师培训Day02Robustness分析—从事件流开始需求分析师培训Day02Robustness分析：寻找边界对象图书管理员向系统发出“新增书籍信息”请求——主窗口、“新增书籍信息”按钮系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类——书籍类别列表框。图书管理员做出选择后，显示相应界面，

让图书管理员输入信

息，并自动根据书号

规则生成书号——

“新书信息录入”窗口

及辅助的“提交”按钮需求分析师培训Day02寻找控制对象与实体对象根据事件流中的步骤5，以及扩展路径的描述，就可以在原图上增加相应的控制对象，得到更进一步的Robustness分析图需求分析师培训Day02寻找控制对象与实体对象新添两个逻辑：一是基本事件流中的步骤2、3要求根据用户选择的类别，自动获得书号；二是当书名重复性检查没有通过（有重名），则应返回要求其重输

需求分析师培训Day02构建交互模型需求分析师培训Day02转成通信图需求分析师培训Day02交互模型的应用用例建模的目标是从使用者的角度来对系统进行梳理，Robustness分析则是对使用者的使用场景（一个用例的实例）进行的具体的分析，从而理解了系统需要做什么，并找出更多与解决方案相关的设计类。但更重要的是完整地捕获出这些类的行为、责任以及它们之间的交互，而这些正是系统运行的机制。而交互建模，正是要通过寻找对象之间的交互关系，从而进行“行为分配”。需求分析师培训Day02交互模型的类型与演变需求分析师培训Day02分析阶段的交互模型针对用例图中的每个用例，并结合领域模型中的类，寻找分析类，并通过Robustness分析来理清业务逻辑流程，再用交互模型将其确定下来。同时这个阶段，不断地丰富分析模型，将新找到的类添加到类图中去在分析阶段我们主要关注于区分出边界对象、实体对象和控制对象，暂时不要考虑其具体的实现类对于较复杂的用例而言，我们可以按上述的流程逐渐地进行分析、设计、实施；但对于比较简单的用例而言，也是可以直接从用例描述中导出设计阶段交互模型需求分析师培训Day02分析阶段的交互模型之后引入基础类：各种库函数、框架进行质量评审：

1）低耦合

2）高内聚

3）效率

4）完整性

5）简单性优化类设计：设计模式与重构需求分析师培训Day02设计阶段的交互模型当在分析模型的基础上，通过引入基础类、优化类设计之后，必然会获得新的类模型（设计模型），因此就可能需要基于新引入的“设计类”来更新交互模型，以获得与实际代码相吻合的模型是否建立设计阶段的交互模型，也是取决于需要的。通常只有约一半的用例可能需要精化交互模型；如果在一般的MIS应用系统中，这个比例可能会更低需求分析师培训Day02交互模型的建模要点创建交互图时，应该遵循以下策略：给出一个能表达其目的的名称；通过修改元素的布局，尽量避免交叉线的存在；可以通过注解和颜色作为可视化提示，以突出图形中的重要特性；尽量少用分支，对于分支很多的场景，可以考虑用活动图来补充切记“尽可能保持简单”需求分析师培训Day02状态图基础需求分析师培训Day02状态及状态表示法状态是指在对象生命周期中满足某些条件、执行某些活动或等待某些事件的一个条件和状况一个状态通常包括名称、进入/退出活动、内部转换、子状态和延迟事件等五个部分组成需求分析师培训Day02阅读简单状态图最为核心的元素无外乎是两个：一个是用圆角矩形表示的状态（初态和终态例外）；另一个则是在状态之间的、包含一些文字描述的有向箭头线，这些箭头线称为转换需求分析师培训Day02转换的五要素源状态：即受转换影响的状态目标状态：当转换完成后对象的状态触发事件：用来为转换定义一个事件，包括调用、改变、信号、时间四类事件监护条件：布尔表达式，决定是否激活转换动作：转换激活时的操作需求分析师培训Day02读图小结与状态off相关的转换有两个，其触发事件都是turnOn，只不过其监护条件不同。如果对象收到事件turnOn，那么将判断壶中是否有水；如果[没水]，则仍然处于off状态；如果[有水]则转为on状态，并执行“烧水”动作而与状态on相关的转换也有两个，如果“水开了”就执行turnOff，关掉开关；如果烧坏了，就进入了终态了需求分析师培训Day02复杂转换转换类型描述语法外部转换对事件做出响应，引起状态变化或自身转换，同时引发一个特定动作，如果离开或进入状态将引发进入转换、离开转换事件(参数)[监护条件]/动作内部转换对事件做出响应，并执行一个特定的活动，但并不引起状态变化或进入转换、离开转换事件(参数)[监护条件]/动作进入转换当进入某一状态时，执行相应活动entry/活动退出转换当离开某一状态时，执行相应活动exit/活动需求分析师培训Day02阅读带复杂转换的状态图需求分析师培训Day02各种转换的区别进入和退出转换：当进入一个状态时，执行某个动作；或当退出某个状态时，执行什么动作。这时就可以使用进入和退出转换来表示内部转换：用来处理一些不离开该状态的事件

需求分析师培训Day02活动与延迟事件活动：当对象处于一个状态时，它一般是空闲的，在等待一个事件的发生。但是某些时间，你可能希望描述个正在进行的活动。在处于一个状态的同时，对象做着某些工作，并一直继续到被某个事件中断。延迟事件：延迟事件是一种特殊的事件，它是指该事件不会触发状态的转换，当对象处于该状态时事件不会丢失，但会被延迟执行。例如，当E-mail程序中正在发送第一封邮件时，用户下达发送第二封邮件执令就会被延迟，但第一封邮件发送完成后，这封邮件就会被发送。这种事件就属于延迟事件。需求分析师培训Day02顺序复合状态图需求分析师培训Day02并发复合状态图需求分析师培训Day02历史“一个圆圈中加上字母H”，用来表示历史状态的。它的含义是：当从状态“结账”和“显示购物车”返回子状态“显示索引信息”时，将进入的是离开时的历史状态。也就是说，转到购

物车或结账区之后，

再回到“浏览目录”的

页面时，其中的内容

是不变的，仍然保留

原来的信息。需求分析师培训Day02状态图应用说明对对象生命周期建模：主要描述对象能够响应的事件、对这些事件的响以及过去对当前行为的影响对反应型对象建模：这个对象可能处于的稳定状态、从一个状态到另一个状态之间的转换所需的触发事件，以及每个状态改变时发生的动作状态机图既可以用来表示一个业务领域的知识，也可以用来描述设计阶段对象的状态变迁。

需求分析师培训Day02讨论状态图有什么用？什么情况下使用状态图？哪种项目应用状态图的情况会比较多？需求分析师培训Day02活动图基础需求分析师培训Day02活动图概述活动图是一种表述过程机理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。因此，它的作用和传统的“流程图”是有着很深的渊源，也十分的相似。不过它与流程图的最主要区别在于，活动图能够支持并行的行为在UML的各个版本中，活动图的改变可谓最大，每次UML标准更新时，都对活动图进行了修订。对于UML2.0而言，最大的改变莫过于去除了“活动图是状态图的一种特例”这一规定需求分析师培训Day02阅读简单活动图需求分析师培训Day02活动图主要元素初始节点和活动终点：用一个实心圆表示初始节点，用一个圆圈内加一个实心圆来表示活动终点活动节点：是活动图中最主要的元素之一，它用来表示一个活动转换：当一个活动结束时，控制流就会马上传递给下一个活动节点，在活动图中称之为“转换”，用一条带箭头的直线来表示需求分析师培训Day02活动图主要元素分支与监护条件：分支是用菱形表示的，它有一个进入转换（箭头从外指向分支符号），

一个或多个离开转换（箭头从分支符

号指向外）。而每个离开转换上都会

有一个监护条件，用来表示满足什么

条件的时候执行该转换。分岔与汇合：需求分析师培训Day02带泳道的活动图需求分析师培训Day02带对象流的活动图需求分析师培训Day02复杂活动图辅助活动图汇合描述：当汇合的所有入流均到点汇合点时，就将执行汇合点指向的活动节点。但是有些时候，你希望对其做一些约束，这时就可以借助汇合描述来完成。汇合描述实际上是一个约束，其格式就是“{约束条件}”。需求分析师培训Day02复杂活动图发送信号与接收信号需求分析师培训Day02复杂活动图引脚：表示活动节点的相应参数扩展区：需求分析师培训Day02活动图应用说明对工作流建模：用于业务建模的时候，每一条泳道表示一个职责单位，该图能够有效地体现出所有职责单位之间的工作职责，业务范围以及之间的交互关系、信息流程建模时应遵循以下策略：为工作流建立一个焦点，除非你所涉及的系统很小，否则不可能在一张图中显示出系统中所有的控制流。选择对全部工作流中的一部分有高层职责的业务对象，并为每个重要的业务对象创建一条泳道。需求分析师培训Day02活动图应用说明识别工作流初始节点的前置条件和活动终点的后置条件，这可有效地实现对工作流的边界进行建模。从该工作流的初始节点开始，说明随时间发生的动作和活动，并在活动图中把它们表示成活动节点。将复杂的活动或多次出现的活动集合归到一个活动节点，并通过辅助活动图或子活动图来表示它们。找出连接这些活动节点的转换，首先从工作流的顺序开始，然后考虑分支，接着再考虑分岔和汇合。如果工作流中涉及重要的对象，则也可以将它们加入到活动图中。若工作流中有多次启用的，则可采用展开区表示。需求分析师培训Day02活动图应用说明对操作建模：每一个对象占据一个泳道，而活动则是该对象的成员方法建模时应遵循以下策略：收集操作所涉及的抽象概念，包括操作的参数、返回类型、所属类的属性以及某些邻近的类。识别该操作的初始节点的前置条件和活动终点的后置条件。也要识别在操作执行过程中必须保持的信息。从该操作的初始节点开始，说明随着时间发生的活动，并在活动图中将它们表示为活动节点。如果需要，使用分支来说明条件语句及循环语句。仅当这个操作属于一个主动类时，才在必要时用分岔和汇合来说明并行的控制流程。需求分析师培训Day02练习有一个表示某公司销售过程

的一张活动图，请阅读并说

明该图所表示的含义假设订单的接收与关闭是由

销售人员负责，开票收款是

由财务人员负责，准备货物

是由仓管负责。请将其修改

成为带泳道的活动图，以体

现这种分工需求分析师培训Day02练习需求分析师培训Day02练习假设，我们希望在活动图中体现出：仓管人员是根据“订单”来准备货物的，因此销售人员在收到订单后，必须将订单传给仓管人员。应该采用什么机制？请直接修改活动图。在公司运转一段时间后，财务人员对该流程提出了置疑，反应说收款工作经常滞后，客户总是在收到货物后的很长时间才付款。因此必须加以改进。请提出一个合理的修改意见，并用活动图表示出来。需求分析师培训Day02练习需求分析师培训Day02练习需求分析师培训Day02讨论活动图什么时候用？一张活动图通常的范围是怎么界定的？需求分析师培训Day02构件图基础需求分析师培训Day02构件的类型实施构件：这类构件是构成一个可执行系统必要和充分的构件，例如动态链接库、可执行文件，另外还包括如COM+、CORBA及企业级JavaBeans、动态Web页面也属于实施构件的一部分。工作产品构件：这类构件主要是开发过程的产物，包括创建实施构件的源代码文件及数据文件。这些构件并不是直接地参与可执行系统，而且用来产生可执行系统的中间工作产品。执行构件：作为一个正在执行的系统的结果而被创建的，例如由DLL实例化形成的COM+对象。需求分析师培训Day02构件及构件接口表示法需求分析师培训Day02阅读基本构件图需求分析师培训Day02阅读嵌套构件图需求分析师培训Day02构件图应用说明对可执行程序的结构建模

1）首先识别你想建模的构件集合

2）考虑集合中各构件的不同类型

3）对这个集合中的每个构件，分析它们之的关系需求分析师培训Day02构件图应用说明对源代码建模

1）识别出感兴趣的相关源代码文件的集合，并把它们建模为构件；

2）对于较大的系统，利用包来进行分组；

3）通过约束来表示源代码的版本

号、作者和最后修改日期等信息；

4）用依赖关系来表示

这些文件间编译的依

赖关系。需求分析师培训Day02部署图基础需求分析师培训Day02阅读基本部署图需求分析师培训Day02部署图主要元素节点：它代表一个运行时的计算资源，例如一台计算机、一个工作站等其它设备节点的概念和构件有许多相同之处，例如二者有多名称，都可以参与依赖、泛化和关联关系，都可以被嵌套，都可以有实例，都可以参与交互。但它们之间也存在明显的区别：构件是参与系统执行的事物，而节点是执行构件的事物；构件表示逻辑元素的物理打包，而节点表示构件的物理部署。本图中建模了四个节点：B/S客户端、C/S客户端、IIS服务器和数据库服务器需求分析师培训Day02部署图主要元素连接：节点之间最常见的关系就是关联关系（用一根实线表示）。为了更好地表示两个节点之间的关系，我们可以通过“约束”来对连接进行描述。

源节点目标节点约束含义B/S客户端IIS服务器{HTTP+Network}网络连接，使用HTTP协议C/S客户端IIS服务器{HTTP+SOAP+Network}网连接，通过WebService访问服务IIS服务器数据库服务器{ADO.NET}.NET提供的数据库访问解决方案需求分析师培训Day02部署图补充元素处理器（《process》）：具有处理能力的节点，即可以执行构件。设备（《device》）：没有处理能力的节点，至少是不关心其处理能力的节点。例如打印机、IC卡读写器，如果我们的系统不考虑它们内部的芯片，就可以建模为设备。节点属性和操作：可以为一个节点提供处理器速度、内存容量、网卡数量等属性，可以为其提供启动、关机等操作

需求分析师培训Day02部署图补充元素自定义构造型图标需求分析师培训Day02部署图应用说明部署图是一种分两阶段演化的，最初的部署图是在设计时，作为确定最终硬件构架过程的一部分而创建的，然后逐步地对它进行精化，从而得到一个或多个实例形式的部署图。设计阶段：焦点聚焦于节点或节点实例，以及它们之间的连接实现阶段：焦点聚集于将物理构件分配给节点需求分析师培训Day02部署图适用领域如果你开发的应用系统是一个单机程序，那么部署图并不能够给你带来什么好处嵌入式系统建模：对于嵌入式系统，部署图可以使硬件工程师和软件开发者之间实现更好的交流

客户机/服务器和分布式系统建模需求分析师培训Day02Agenda需求分析最佳实践需求建模最佳实践用例驱动的需求过程实践现代需求工程最佳实践需求分析师培训Day02用例驱动的需求实践：概述需要特性软件需求问题域解决方案域用例补充规约需求分析师培训Day02关于用例分析技术用例分析的创建源于实践，在IvarJacobson在爱立信公司研发AXE（电话交换机）时总结而成的用例的概念确定于1986年，所以它不应该当作一种新技术（有人认为其是一个正处于临床实验阶段的新药）许多人是在学习UML时，接触到用例，并且产生了一些误解，误把用例图当作了用例分析的全部内容用例分析技术已经广泛地应用于许多软件开发组织的实践，收效甚佳，成为了软件需求最佳实践之一需求分析师培训Day02用例模型的运用方法增量开发的用例模型模型的无缝转换需求分析师培训Day02用例模型建模要点构建结构良好的用例：

1）为系统和部分系统中单个的、可标识和合理的原子行为命名；

2）将公共的行为抽取出来，放到一个被包含用例中，再将它《include》进来；

3）对于变化部分，将其抽取出来，放到一个扩展用例（用《extent》连接）中；

4）清晰地描述事件流，使得读者能够轻而易举地理解构建结构良好的用例图：摆放元素时，应该避免交叉线的出现；对于语义上接近的行为和角色，最好使它们在物理上也更加接近；根据系统实际情况控制粒度需求分析师培训Day02核心元素：参与者定义：在系统之外，透过系统边界与系统进行有意义交互的任何事物边界类：顾客需求分析师培训Day02边界是职责边界，而非物理边界需求分析师培训Day02谁是机票预订系统的执行者需求分析师培训Day02它们都可以是执行者用户维护人员时间系统其他系统需求分析师培训Day02参与者：总结参与者是为了完成一个事件而与系统交互的实体参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟其它系统：当你的系统需要与其它系统交互时，如在开发ATM柜员机系统时，银行后台系统就是一个参与者硬件设备：如果你的系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者时钟：当你的系统需要定时触发时，时钟就是一个参与者，如在开发Foxmail中的“定时自动接

收”功能时，就需要引入时钟作为参与者需求分析师培训Day02核心元素：用例IvarJacobson在RUP中为用例做出了以下定义

用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。步骤目标路径需求分析师培训Day02用例：使用场景的抽象场景1：原有客户育才学校呼入，选择电话号码组“全体家长”和“放假通知”音频文件，设置日期、时间和其它呼叫标准，然后启动一个语音外呼任务。场景2：原有客户精英软件公司呼入，选择电话号码组“全体客户”和“产品升级通知”音频文件，设置日期、时间和其它呼叫标准，然后启动一个语音外呼任务。场景3：客户通达核电计划在核电力设施发生紧急情况时，向其经理和支持人员打电话。此时，不仅要能够正确地打到家里，还要正确地判断出谁能够接收到这个消息，谁不能够接收。需求提出后，必须马上执行。启动外呼任务需求分析师培训Day02用例定义：用例描述了执行者（参与者）使用系统实现目标的方式，以及系统为其能够实现该目标而提供的帮助。用例描述了系统及其执行者结合起来向至少一个参与者传递有价值的东西的方式需求分析师培训Day02常见错误用例太细（用例应包括事件流，事件流中应有步骤）把步骤当做用例（如登录输入用户名、验证密码…）

把系统活动当用例！

特例：新增、删除、查询、修改管理

也被戏称为：CRUD（四轮马车）误认为用例的粒度与系统实现的复杂度相关其实很简单，一个用例为执行者提供一个价值需求分析师培训Day02用例要突出涉众的利益找出用例相关的涉众；分析涉众的利益所在；在用例中充分考虑涉众的利益。需求分析师培训Day02用例分析技术的组成用例图：用例描述：前置条件：用户启动该应用系统基本路径：1）系统显示登录界面；2）用户输入用户名和密码；3）系统验证信息；…………可选路径：后置条件：执行者，Actor

参与者用例，UseCase参与者：定义了用户在系统交互过程中所扮演的角色，其可以是一个人，也可以是另一个系统。需求分析师培训Day02用例图实例需求分析师培训Day02用例之间的关系：包含关系包含关系用构造型《include》表示是指基用例（baseusecase）在它内部说明的某一个位置上显式地合并了另一个用例的行为需求分析师培训Day02用例之间的关系：扩展关系包含关系用构造型《extend》表示表示基用例在由扩展用例间接说明的一个位置上，隐式地合并了另一个用例的行为需求分析师培训Day02用例之间的关系：泛化关系用例间的泛化表示子用例继承了父用例的行为和含义子用例还可以增加或覆盖父用例的行为；子用例可以出现在父用例出现的任何位置需求分析师培训Day02读图小结这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。需求分析师培训Day02用例描述：事件流用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事需求分析师培训Day02用例描述：前置条件指在用例启动时，参与者与系统应置为何状态；

1）系统能检测到；

2）系统在用例开始前能检测到；

3）应为“可观测”的前置条件需求分析师培训Day02用例描述：前置条件客户已发出订单----错误工作人员已登录系统----正确库存大于下单数----错误需求分析师培训Day02用例描述：后置条件用例结束时，系统的状态

1）系统能检测到；

2）应为“可观测”的：

只包含可检测的条件，

合并影响相同的条件后置条件需求分析师培训Day02用例描述：基本事件流基本事件流是对用例中

常规、预期路径的描述

（有时被称为Happy

day场景），这是大多

数用户在大部分时间中

所采取的路径。通常体系了系统的核心

价值。基本事件流需求分析师培训Day02用例描述：扩展事件流系统还需要进行意外处理扩展事件流需求分析师培训Day02事件流编写要点使用简单的语法：主语明确，语义易于理解明确写出“谁控制球”：通常就是指出参与者；从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是跳开来；显示过程向前推移：也就是每一步都有前进的感觉（例如：用户按下tab键就不够）；显示执行者的意图而非动作（光有动作，让人不容易直接从事件流中理会用例）。需求分析师培训Day02事件流编写要点包括“合理的活动集”（带数据的请求、系统确认、更改内部、返回结果）；“确认”而不是“检查是否”；（如：系统确认用户密码正确，而非系统检查用户密码是否正确）可选择地提及时间限制；习惯用语“用户让系统A与系统B交互”；习惯用语“循环执行步骤x到y，直到条件满足；需求分析师培训Day02用例描述模板用例编号[为用例制定一个唯一的编号，通常格式为UCxx]用例名称[应为一个动词短语，让读者一目了然地知道用例的目标]用例概述[用例的目标，一个概要性的描述]范围[用例的设计范围]主参与者[该用例的主Actor，在此列出名称，并简要的描述它]次要参与者[该用例的次要Actor，在此列出名称，并简要的描述它]项目相关人利益说明项目相关人利益[项目相关人员名称][从该用例获取的利益]…………前置条件[即启动该用例所应该满足的条件。]后置条件[即该用例完成之后，将执行什么动作。]成功保证[描述当前目标完成后，环境变化情况。]基本事件流步骤活动1[在这里写出触发事件到目标完成以及清除的步骤。]2……(其中可以包含子事件流，以子事件流编号来表示)扩展事件流1a[1a表示是对1的扩展，其中应说明条件和活动]1b……(其中可以包含子事件流，以子事件流编号来表示)子事件流[对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。]规则与约束[对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]需求分析师培训Day02用例模型的建立过程需求分析师培训Day02分析过程—需求FEAT01.新增书籍信息FEAT02.修改已有的书籍信息FEAT03.书籍信息按计算机类、非计算机类分别建档FEAT04.录入新书时能够自动按规则生成书号FEAT05.计算机类与非计算机类书籍采用不同的书号规则FEAT06.录入新书时如果重名将自动提示FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍FEAT08.列出所有书籍信息FEAT09.记录外借情况FEAT10.外借状态能够自动反应在书籍信息中FEAT11.按人、按书查询外借情况FEAT12.列出所有的外借情况FEAT13.按特定时间段统计购买金额、册数FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行需求分析师培训Day02分析过程—合并特性到用例FEAT01.新增书籍信息FEAT02.修改已有的书籍信息FEAT03.书籍信息按计算机类、非计算机类分别建档FEAT04.录入新书时能够自动按规则生成书号FEAT05.计算机类与非计算机类书籍采用不同的书号规则FEAT06.录入新书时如果重名将自动提示FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍FEAT08.列出所有书籍信息FEAT09.记录外借情况FEAT10.外借状态能够自动反应在书籍信息中FEAT11.按人、按书查询外借情况FEA