需求分析师培训2

《需求分析师培训2》由会员分享，可在线阅读，更多相关《需求分析师培训2（200页珍藏版）》请在装配图网上搜索。

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

2、说明书编写的方式文档化需求分析最佳实践需求分析最佳实践 1l定义系统边界：评估原始需求，定义将要开发的系统的边界；确定哪些是系统需求，哪些是和系统相关的操作过程的需求，哪些是在系统范围之外的需求 主要效益：消除不必要的需求 引入成本：低 应用成本：低 实施指南：询问某项需求是否是基于不完整的或者不可靠的信息做出的？某项需求的实现是否需要在系统已定义的数据库之外的信息？某项需求是否和系统的核心功能相关？某项需求是否牵涉到系统之外的功能或者设备的性能？需求分析最佳实践需求分析最佳实践 2l使用校验表进行需求分析：根据经验开发需求问题校验表，并将其用于需求的系统化分析，每一项需求都应按照校验表进行分

3、析。主要效益：更快、更完整地进行需求分析 引入成本：低-中 应用成本：低 实施指南：校验表不超过10项草率设计：该需求包括不成熟设计或实现信息吗？组合需求：该需求是单独的需求还是可以细分为多个需求？多余需求：该需求只是系统的修饰，还是真正必需？使用非标准硬件：必须使用非标准的硬件还是软件？符合业务目标：符合在需求文档开始处定义的业务目标？需求多义性：不同人是否可以从不同方式来理解？需求可实现性：基于当前技术，该需求可实现吗？需求可测试性：是否能够判断系统是否符合需求需求分析最佳实践需求分析最佳实践 3l使用软件支持协商：鼓励使用电子邮件来交换需求信息并且进行需求协商；也可以使用BBS、即时通信

4、、群件系统来进行沟通与协商。主要效益：需求问题的更快解决 引入成本：低-中 应用成本：低-中 实施指南：电子邮件需指派一个问题管理人员，负责跟踪问题的提出、传递、回应和达成解决方案；BBS方案需要限制讨论的长度；群件方案需要事行定义好需求管理项的结构需求分析最佳实践需求分析最佳实践 4l对冲突和冲突解决方案做好计划：任何需求集中都会有冲突、重叠和遗漏问题，应该安排会议讨论这些需求并解决分析过程中发现的问题。主要效益：需求问题的更快解决 引入成本：低 应用成本：低 实施指南：会议是解决需求冲突最快的方式，应聚焦于解决突出的需求问题；电子信息交换也是可取的方式之一；会议通常包括叙述阶段、讨论阶段和

5、决策阶段；分析的结果要发给所有与会者需求分析最佳实践需求分析最佳实践 5l需求分级：每一项需求都应该标上优先级，以反映它们对项目相关人员的重要性和对整个系统成功与否的重要性。主要效益：关注最重要的需求 引入成本：低 应用成本：低 实施指南：在需求捕获阶段就标明优先级是最理想的；通常需要进行了初始的分析工作才可能分配优先级；优先级的分配要由需求分析人员和项目相关人员共同完成；优先级不应太多，如必须的、有用的、希望的需求分析最佳实践需求分析最佳实践 6l使用多维方法进行需求分类：应对需求进行分类以便标记相关的需求，不必将单个需求只归到一个类，可以派生出多种分类方法。主要效益：有助于发现需求重叠和冲

6、突 引入成本：低-中 应用成本：中 实施指南：可用系统、用户界面、数据库、通信、安全来进行分类；建议最多有56个分类；决定分类后，应把每个需求都和一到多个关键词关联起来；分类完成后，可以抽取很多组具有相同分类的需求进行比较和分析需求分析最佳实践需求分析最佳实践 7l使用交互矩阵发现冲突与重叠：交互矩阵的每一行和每一列都代表一项需求，每一个元素都用来表示对应的需求是否冲突、重叠或者独立 主要效益：揭示需求重叠和冲突 引入成本：低 应用成本：中-高 实施指南：创建交互矩阵最简单的方法是使用电子表格程序，在首行、首列均标上需求标识符；然后如果需求冲突填入1、重叠填入1000，独立则填0；这样只需要用

7、求和的方式来统计出各种数目；通常需求不应超过200条需求分析最佳实践需求分析最佳实践 8l评估需求风险：对每一项需求或者一系列相关的需求进行风险分析，指出在实现需求过程中可能会发生的问题、这些问题发生的机率及其影响。主要效益：标识有问题的需求 引入成本：中 应用成本：中 实施指南：应考虑的风险主要有性能风险、安全风险、过程风险、实现技术风险、数据库风险、日程风险、外部风险、稳定风险Agenda需求分析最佳实践需求分析最佳实践需求建模最佳实践需求建模最佳实践用例驱动的需求过程实践用例驱动的需求过程实践需求建模是表述需求的关键手段模型是对现实的简化模型是对现实的简化建模的目的与原则建模的目的与原则

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

9、一致 引入成本：低-中 应用成本：中 实施指南：通常会开发数据处理模型(DFD)、组合模型(E-R)、分类模型(类图)、刺激-响应模型(状态图、活动图)、过程模型等；选择什么模型取决于要说明的信息类型、模型的读者、模型开发者的技能、CASE工具系统建模最佳实践系统建模最佳实践 2l系统环境建模：为了理解需求，应该就系统环境开发一个或多个模型，应该说明和本系统的接口和其他系统，以使用可能会使用本系统的业务过程。主要效益：记录必须说明接口的外部系统 引入成本：低 应用成本：低 实施指南：环境模型就是系统的使用语境模型，应包括和本系统直接交互的其他系统、可能和本系统共存并发生交互的系统、系统所在的业

10、务过程。系统建模最佳实践系统建模最佳实践 3l系统体系结构建模：每次都应该开发系统的体系结构模型，用来说明系统是如何分解成子系统，还应解释子系统之间的通信。主要效益：有助于划分系统需求 引入成本：低-中 应用成本：低 实施指南：常用的体系结构模型包括客户机-服务器系统、分层系统、基于共享库通信的系统、管道系统系统建模最佳实践系统建模最佳实践 4l用标准化方法进行系统建模：标准化方法是一种系统分析和设计方法，包括定义、开发和确认系统模型过程中用到的表示法、指南和规则。主要效益：使用标准的方式书写系统模型 引入成本：中-高 应用成本：中 实施指南：包括过程化(结构化)方法、面向对象方法，其主要包括

11、一组推荐的系统模型和相应的开发该模型的表示法、一组建模规则、一组关于创建高质量系统模型的指南、一份描述、一些报告。系统建模最佳实践系统建模最佳实践 5l使用数据字典：系统建模中使用的名字都应当记录在数据字典中，它是一份由计算机维护的名字列表以及相关的信息。主要效益：避免名字重复使用和误解 引入成本：中 应用成本：低 实施指南：进行数据字典的至少应包括模型中实体的名字、名字的别名及变化、实体类型、为何引入模型、针对实体的约束、指向相关实体的链接；数据字典必须由一台服务器维护，开发人员本机要与服务器经常实现同步系统建模最佳实践系统建模最佳实践 6l记录项目相关人员需求和系统模型之间联系：记录项目相

12、关人员用自然语言描述的需求和说明这个系统的具体模型之间的关系。主要效益：便列发现受变更影响的需求和模型 引入成本：低 应用成本：中UML基础基础UML发展历程发展历程UML特性与发展现状特性与发展现状lUML是一种Language（语言）lUML是一种Modeling（建模）LanguagelUML是Unified（统一）Modeling Languagel已进入全面应用阶段的事实标准l应用领域正在逐渐扩展，包括嵌入式系统建模、业务建模、流程建模等多个领域l成为“产生式编程”的重要支持技术：MDA、可执行UML等为什么使用为什么使用UML建模建模lUML是一种统一的、标准化的建模语言 lUML

13、是一种应用面很广泛的建模语言模型的种类模型的用途业务模型对业务过程、工作流、组织的建模需求模型对捕获的需求进行整理和分析的工具，辅助开发人员与用户进行沟通设计模型包含高层设计（架构模型）和详细设计模型，用于统一开发人员、沟通设计信息数据库模型设计数据库的结构、表结构以及与应用系统的交互实现模型用来理清软件的组成、部署方案，为安装与维护人员的工作提供指导草图和蓝图草图和蓝图l蓝图一般是指采用CASE工具绘制的、正式的、规范的UML模型 l草图则通常是指手工绘制的、规范度较低的在纸张的UML模型 l大胆地绘制草图，尽可能基于草图进行讨论。对于局部的、重要性不高的、共享范围较小的UML模型，直接将草

14、图扫描到电脑存档即可；对于全局的、重要性高的、高度共享的，在草图的基础上用CASE工具绘制成为正式的蓝图，并将其纳入统一的模型管理中 谁应该建模谁应该建模l业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与l需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与l设计模型：高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。详细设计模型则以资深开发人员为主，架构师提供指导。l实现模型：以资深开发人员（设计人员）为主，架构师提供总体指导。l数据库模型：以数据库开发人员为主，架构师提供指导，资深开发人员

15、（设计人员）予以配合。常见认识误区常见认识误区lUML是一种方法论lUML就是一堆图形lUML只能够应用于面向对象开发中lUML就是Rose里的符号lUML的学习周期很长、很复杂UML的组成的组成l基本构造块：也就是建模元素，是模型的主体lUML规则：也就是支配基本构造块如何放在一起的规则l公共机制：运用于整个UML模型中的公共机制、扩展机制事物构造块事物构造块l事物构造块是对模型中最具有代表性的成分的抽象 l结构事物：UML中的名词，它是模型的静态部分，描述概念或物理元素。l行为事物：UML中的动词，它是模型中的动态部分，是一种跨越时间、空间的行为。l分组事物：UML中的容器，用来组织模型，

16、使模型更加的结构化。l注释事务：UML中的解释部分，和代码中的注释语句一样，是用来描述模型的。面向对象视角下的世界面向对象视角下的世界l首先建立反应现实世界中不同事物的“构造块”，然后确定“构造块”之间的“关系”，再确定各个构造块的属性和“行为”。这样，在软件系统中就可以模拟现实世界的“构造块”之间的交互与协作 l面向对象软件开发的核心思想就是高内聚（封装）、低耦合（消息驱动），使用简洁的接口拼合简单的部件结构事物结构事物l类（class）和对象（object）l接口（interface）l主动类（active class）l用例（use case）l协作（collaboration）l构件（

17、component）l节点（node）类和对象类和对象l类是对一组具有相同属性、相同操作、相同关系和相同语义的对象的抽象 lUML中类是用一个矩形表示的，它包含三个区域，最上面是类名、中间是类的属性、最下面是类的方法 l对象则是类的一个实例 接口接口l接口是描述某个类或构件的一个服务操作集主动类主动类l主动类实际上是一种特殊的类。引用它的原因，实际上是在开发中需要有一些类能够起到启动控制活动的作用 l主动类是指其对象至少拥有一个进程或线程，能够启动控制活动的类 用例与协作用例与协作l用例是著名的大师Ivar Jacobson首先提出的，现已经成为了面向对象软件开发中一个需求分析的最常用工具 l

18、用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。l协作定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他元素构成的一个群体。l对于某个用例的实现就可以表示为一个协作构件构件l在实际的软件系统中，有许多要比“类”更大的实体，例如一个COM组件、一个DLL文件、一个JavaBeans、一个执行文件等等。为了更好地对在UML模型中对它们进行表示，就引入了构件（也译为组件）l构件是系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组外部接口。在系统中满足相同接口的组件可以自由地替换 节点节点l为了能够有效地对部署的结构进行建模，

19、UML引入了节点这一概念，它可以用来描述实际的PC机、打印机、服务器等软件运行的基础硬件 l节点是运行时存在的物理元素，它表示了一种可计算的资源，通常至少有存储空间和处理能力 行为事物行为事物l交互（interaction）：是在特定语境中，共同完成某个任务的一组对象之间交换的信息集合 l交互的表示法很简单，就是一条有向直线，并在上面标有操作名 l状态机（state machine）：是一个对象或交互在生命周期内响应事件所经历的状态序列 l在UML模型中将状态画为一个圆角矩形，并在矩形内写出状态名称及其子状态分组事物分组事物l对于一个中大型的软件系统而言，通常会包含大量的类，因此也就会存在大量

20、的结构事物、行为事物，为了能够更加有效地对其进行整合，生成或简或繁、或宏观或微观的模型，就需要对其进行分组。在UML中，提供了“包（Package）”来完成这一目标注释事物注释事物l结构事物是模型的主要构造块，行为事物则是补充了模型中的动态部分，分组事物而是用来更好地组织模型，似乎已经很完整了。而注释事物则是用来锦上添花的，它是用来在UML模型上添加适当的解释部分关系构造块关系构造块关联关系关联关系l关联（Association）表示两个类之间存在某种语义上的联系。关联关系提供了通信的路径，它是所有关系中最通用、语义最弱的。l在UML中，使用一条实线来表示关联关系 l在关联关系中有两种比较特殊

21、的关系：聚合和组合 l聚合关系：聚合（Aggregation）是一种特殊形式的关联。聚合表示类间的关系是整体与部分的关系 l如果发现“部分”类的存在，是完全依赖于“整体”类的，那么就应该使用“组合”关系来描述关系构造块关系构造块其他关系其他关系l泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。l实现关系是用来规定接口和实现接口的类或组件之间的关系。接口是操作的集合，这些操作用于规定类或组件的服务。l扩展表示将一个构造型附加到一个元类上，使得元类的定义中包括这个构造型。l有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于

22、元素X。UML规则规则l命名：也就是为事物、关系和图起名字。和任何语言一样，名字都是一个标识符 l范围：与类的作用域相似，包括所有者作用域和目标作用域两类 l可见性：可见性规则标准表示法Rose属性Rose方法public任一元素，若能访问包容器，就可以访问它+protected只有包容器中的元素或包容器的后代才能够看到它#private只有包容器中的元素才能够看得到它-package只有声明在同一个包中的元素才能够看到该元素公共机制公共机制规格描述规格描述l在图形表示法的每个部分后面都有一个规格描述（也称为详述），它用来对构造块的语法和语义进行文字叙述。这种构思，也就使可视化视图和文字视图的

23、分离：公共机制公共机制UML修饰与通用划分修饰与通用划分l在为了更好的表示这些细节，UML中还提供了一些修饰符号，例如不同可视性的符号、用斜体字表示抽象类 lUML通用划分：1）类与对象的划分：类是一种抽象，对象是一个具体的实例 2）接口与实现的分离：接口是一种声明、是一个契约，也是服务的入口；实现则是负责实施接口提供的契约 UML扩展机制扩展机制l构造型：在实际的建模过程中，可能会需要定义一些特定于某个领域或某个系统的构造块 UML扩展机制扩展机制l标记值：则是用来为事物添加新特性的。标记值的表示方法是用形如“标记信息”的字符串 l约束：是用来增加新的语义或改变已存在规则的一种机制（自由文本

24、和OCL两种表示法）。约束的表示法和标记值法类似，都是使用花括号括起来的串来表示，不过它是不能够放在元素中的，而是放在相关的元素附近图名功能备注类图描述类、类的特性以及类之间的关系UML 1原有对象图描述一个时间点上系统中各个对象的一个快照UML 1非正式图复合结构图描述类的运行时刻的分解UML 2.0新增构件图描述构件的结构与连接UML 1原有部署图描述在各个节点上的部署UML 1原有包图描述编译时的层次结构UML中非正式图用例图描述用户与系统如何交互UML 1原有活动图描述过程行为与并行行为UML 1原有状态机图描述事件如何改变对象生命周期UML 1原有顺序图描述对象之间的交互，重点在强调

25、顺序UML 1原有通信图描述对象之间的交互，重点在于连接UML 1中的协作图定时图描述对象之间的交互，重点在于定时UML 2.0 新增交互概观图是一种顺序图与活动图的混合UML 2.0新增UML定义的图定义的图主要领域视图图结构静态视图类图设计视图复合结构图、协作图、构件图用例视图用例图动态状态视图状态机图活动视图活动图交互视图顺序图、通信图物理部署视图部署图模型管理模型管理视图包图特性描述包图UML视图和图视图和图UML图形分类图形分类4+1视图视图4+1视图视图l用例视图：它是最基本的需求分析模型，是可被最终用户看到的系统行为的用例组成。常用的模型包括用例图、交互图、状态图、活动图等。l设

26、计视图：又称为逻辑视图，以问题域的语汇组成的类和对象集合，用来描述类、接口、协作。常用的模型包括类图、交互图、状态图、活动图等。l进程视图：形成系统并发与同步机制的线程和进程，也就是将可执行线程和进程作为活动类的建模，可理解为设计视图的一次执行实例。它使用的模型与设计视图类似，区别在于更侧重于主动类。4+1视图视图l实现视图：对组成基于系统的物理代码的文件和组件进行建模，即装配与发布物理系统的构件和文件。常用的模型包括构件图、交互图、状态图、活动图。l部署视图：包含了形成系统硬件拓扑结构的节点，也就是描述组件是如何物理地部署到一组物理的、可计算节点上的。常用的模型包括部署图、交互图、状态图、活

27、动图。开发过程开发过程类图基础类图基础理解面向对象思想理解面向对象思想理解面向对象思想理解面向对象思想l每个对象都扮演了一个角色，并为其它成员提供特定的服务或执行特定的行为。l在面向对象世界中，行为的启动是通过将“消息”传递给对此行为负责的对象来完成的；同时还将伴随着执行要求附上相关的信息（参数）；而收到该消息的对象则会执行相应的“方法”来实现需求 l用类和对象表示现实世界，用消息和方法来模拟现实世界的核心思想如何用如何用UML表示一个类表示一个类l名称：每个类都有一个惟一的名称，通常采用CamelCase格式表示l属性：是已被命名的类的特性，它描述该类实例中包含的信息 l操作：是类所提供的服

28、务，它可以由类的任何对象请求以影响其行为l属性名和操作名也通常采用CamelCase格式表示，只不过首字母通常为小写。如何阅读类图如何阅读类图l先看清有哪些类，然后看看类之间存在的关系，并结合多重性来理解类图的结构特点以及各个属性和方法的含义读图过程读图过程l读出类：图中共有7个类，Order、OrderItem、Customer、Consignee、DeliverOrder、Peddlery、Prodcutl读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。1）OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderI

29、tem。2）Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。读图过程读图过程l多重性：用来说明关联的两个类之间的数量关系源类及多重性目标类及多重性分析Customer(1)Order(0n)订单是属于某个客户的，网站的客户可以有0个或多个订单Order(1)Consignee(1)每个订单只能够有一个收货人Order(1)OrderItem(1n)订单是由订单项组成的，至少要有一个订单项，最多可有n个Order(1)DeliverOrder(1n)一个订单有一个或多个送货单说明：系统根据订单项的产品所属的

30、商户，将其分发给商户，拆成了多个送货单！DeliverOrder(1)OrderItem(1n)一张送货单对应订单中的一到多个订单项DeliverOrder(1)Consignee(1)每张送货单都对应着一个收货人Peddlery(1)DeliverOrder(0n)每个商户可以有相关的0个或多个送货单OrderItem(1)Product(1)每个订单项中都包含着唯一的一个产品Peddlery(1)Prodcut(0n)产品是属于某个商户的，可注册0到多个产品读图过程读图过程理解方法和图理解方法和图lOrder类，有两个方法：dispatch()和close()，从名字中可以猜出它们分别实现

31、“分拆订单生成送货单”和“完成订单”。而在DeliveOrder()类中则有一个Close()方法，同理它应该表示“完成送货”。而在OrderItem中有一个stateChange()方法和deliverState，不难猜出它就是用来改变其“是否交给收货人”标志位的读图过程读图过程理解方法和图理解方法和图l先调用Order的dispatch()方法，它将根据其包含的OrderItem中产品信息，来按供应商户分拆成若干个DeliverOrder。商户登录系统后就可以获取其DeliverOrder，并在执行完后调用close()方法。这时，就将调用OrderItem的stateChange()方法

32、来改为其状态。同时再调用Order的close()方法，判断该Order的所有的OrderItem是否都已经送到了，如果是就将其真正close()掉 使用了更多建模元素的类图使用了更多建模元素的类图辅助建模符号辅助建模符号l导航箭号：类的实例之间只能沿着导航箭头的方向传递，在Order中可以获取其相应的Consignee，而从Consignee中是无法了解与其相关的Order的 l角色名称：Customer端有一个“+Owner”字符串，这表示Customer扮演的角色是Owner，也能对关联进行命名辅助建模符号辅助建模符号l导出属性：是指可以根据其他值计算出来的特性，这种属性应在其名称前加上

33、一个“/”符号。l限定符：在Order和OrderItem之间的组合关系中，OrderItem这端多了个方框，写着“ProductId”。在UML中称为限定符，存在限定符的关联称为受限关联。它用来表示某种限定关系。在本例中说明：对于一张订单，每一种产品只能用一个订单项 l约束：用来说明规则，xorl职责：在类的属性栏中添加注释行表示，或增加了一个新的分栏对象约束语言对象约束语言环境与约束：每个OCL表达式都必须是针对某个元素的，因此在OCL表达式前必须说明它针对元素（这就称为环境）1）“context Object inv：”，其中Object是OCL表达式针对的建模元素名称；2）“Objec

34、t”，其中Object是OCL表达式针对的建模元素名称。当声明了环境之后，就可以用self来引用它的变量 对象约束语言对象约束语言l子集约束：l一致性：一个客户拥有零个或多个合同，发票是基于某个合同的，而一个客户将收到零张或多张发票 Invoice：self.contract.customer=self.customer对象约束语言对象约束语言l异或关系：l规定的取值范围：Rectangle：length0 and width0 用类图表示软件系统模型用类图表示软件系统模型l领域模型是从面向对象视角看待现实世界的结果，也就是通过类图描述现实世界中各种事物的关系。l分析模型和领域模型很相近，分析

35、模型主要是针对软件系统，领域模型则更多偏重对业务领域的分析 l设计模型则是在分析模型的基础上添加设计元素的结果。设计模型中的类的属性集更趋完善。用类图表示数据库逻辑模型用类图表示数据库逻辑模型l从某种意义上说UML中的类图是E-R图的超集，E-R图只针对存储的数据，而类图则在些基础上，增加了行为建模的能力。在使用类图来表示E-R模型时，要注意遵循以下策略 l将表示E-R模型的类，用UML的标准构造型“persistent”来表示；l展开类的结构性细节，并加强关联和多重性分析；l尽量消除循环关联、n-元关联 交互图基础交互图基础交互的概念交互的概念l一次交互就是指在特定语境中，为了实现某一个目标

36、，而在一组对象之间进行交换的一组消息所表示的行为 l在大多数的情况下，消息通常是指启动一个操作，或发送一个信号，以及创建或销毁一个对象 l由一条有方向的直线，加上名称、参数（可选）和顺序组成 四种交互图四种交互图l顺序图：强调消息时间顺序。首先把参与交互的对象放在图的上方，沿X轴方向排列。通常把发起交互的对象放在左边，较下级对象依次放在右边。然后，把这些对象发送和接收的消息沿Y轴方向按时间顺序从上到下放置。读者提供了控制流随着时间推移的清晰的可视化轨迹。l协作图：在UML 2.0中称为通信图，强调的是参加交互的对象的组织。首先将参加交互的对象作为图的顶点，然后用这些对象之间的边线表示为图的边，

37、再使用对象发送和接收的消息来修饰这些边。为读者提供了在协作对象结构组织的语境中观察控制流的一个清晰的可视化轨迹 四种交互图四种交互图l定时图：采用了一种带数字刻度的时间轴来精确地描述消息的顺序，而不是像顺序图那样只是指定消息的相对顺序。而且它还允许可视化地表示每条生命线的状态变化，当需要对实时事件进行定义时，定时图就可以很好地满足 l交互概述图：是交互图和活动图的混合物。你可以把交互概述图想像为活动图，只不过其中的活动被换成了一些小型顺序图；也可以把其想像为利用标明控制流的活动图分解过的顺序图 阅读顺序图阅读顺序图顺序图的主要元素顺序图的主要元素l对象与角色：最顶上一排矩形框。在交互图中，参与

38、交互的对象既可以是具体的事物，又可以是原型化的事物。作为具体的事物，一个对象代表现实世界中的某个东西。例如，aOrder作为类Order的一个实例，可以代表一个特定的订单；而如果作为一个原型化的事件，则aOrder可以代表类Order的任何一个实例。l生命线与控制焦点：每个对象都有自己的生命线，对象生命线是一条垂直的虚线，用来表示一个对象在一段时间内存在。顺序图的主要元素顺序图的主要元素l消息：用来描述对象之间所进行的通信的，该信息带有对将要发生的活动的期望。当传送一个消息时，它所引起的动用是一个通过对计算过程的抽象而得到的可执行语句。l消息分为五种：调用、返回、发送、创建和销毁l调用：表示调

39、用某个对象一个操作 顺序图的主要元素顺序图的主要元素l返回：表示被调用的对象，向调用者返回一个值l发送：发送是指向对象发送一个信号，和调用不同，它是一种事件，用来表示个实例间进行通信的异步激发机制 l创建和销毁：就是创建和销毁一个对象。顺序图的主要元素顺序图的主要元素l顺序编号：整个消息的传递过程就形成了一个完整的序列，因此通过在每个消息的前面加上一个用冒号隔开的顺序号来表示其顺序。除了顺序编号之外，还可以采用嵌套方案：顺序图的主要元素顺序图的主要元素l循环与分支读图小结读图小结l在dispatchForm（分发窗体）中，对于某个已支付的Order进行分发时，就会调用该订单（一个Order类的

40、实例对象aOrder）的dispatch()方法。ldispatch()方法将逐个调用该Order对应的所有OrderItem对象的getPeddleryId()方法还获取供应商ID（PeddleryId），而OrderItem对象则是通过其所对应的Product对象来的getPeddleryId()方法来获取供应商ID。读图小结读图小结l当Order的实例对象aOrder得到返回的PeddleryId后，根据该值判断是否已经有相对应的DeliverOrder对象，如果没有就创建它（调用create(PeddleryId)），然后再将对应的Product添加到这个DeliverOrder对象中

41、。否则就直接添加到相应的DeliverOrder对象中。阅读协作阅读协作(通信通信)图图协作图的主要元素协作图的主要元素l链：连接器，是用来表示对象之间的语义连接，一般而言，链是关联的一个实例（包括association、self、global、local等）。不过在UML 2中已经开始弱化它们的使用，因此除非必要，无需过多地考虑它们 l消息编号：消息的编号有两种，一种是无层次编号，它简单直观；另一种是嵌套的编号，它更易于表示消息的包含关系l迭代标记：用*号表示，表示循环，通常还有迭代表达式，用来说明循环规则协作图的主要元素协作图的主要元素l监护条件：通常是用来表示分支的，也就是表示“如果条件

42、为true，才发送消息”l在通信图中使用监护条件一定要有所限制，通常应只列出主要的监护条件，否则会影响其阅读。如果需要，尽可能还是通过顺序图来表示 交互建模的准备工作交互建模的准备工作l首先根据自己的喜好和实际的表现需要来选择顺序图或通信图。不过由于它们在语义上是等价的，因此可以绘制出一种，再通过建模工具来自动转换成另一种图 l分析模型中的交互图彻重于分析类的职责分配和交互流程，而设计模型中的交互图则彻重于设计类的引入和实际方法的调用与流程控制 l先确定参与交互的对象、对象之间的关系(通信图)，然后确定对象间的消息交互流程(用同步调用、异步消息、返回消息表示)，并利用交互片断(顺序图)或迭代标

43、记及监护条件来表示循环和分支结构交互建模交互建模Robustness分析分析lRobustness分析不是UML模型的一部分，它是一个强大的草图工具，是介于分析和设计之间的一种有效工具l在Robustness分析中，将应用边界类、控制类和实体类l从一个用例中抽取三类对象的方法：Robustness分析分析从事件流开始从事件流开始Robustness分析：寻找边界对象分析：寻找边界对象l图书管理员向系统发出“新增书籍信息”请求主窗口、“新增书籍信息”按钮l系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类书籍类别列表框。l图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根

44、据书号规则生成书号“新书信息录入”窗口及辅助的“提交”按钮寻找控制对象与实体对象寻找控制对象与实体对象l根据事件流中的步骤5，以及扩展路径的描述，就可以在原图上增加相应的控制对象，得到更进一步的Robustness分析图寻找控制对象与实体对象寻找控制对象与实体对象l新添两个逻辑：一是基本事件流中的步骤2、3要求根据用户选择的类别，自动获得书号；二是当书名重复性检查没有通过（有重名），则应返回要求其重输 构建交互模型构建交互模型转成通信图转成通信图交互模型的应用交互模型的应用l用例建模的目标是从使用者的角度来对系统进行梳理，Robustness分析则是对使用者的使用场景（一个用例的实例）进行的具

45、体的分析，从而理解了系统需要做什么，并找出更多与解决方案相关的设计类。但更重要的是完整地捕获出这些类的行为、责任以及它们之间的交互，而这些正是系统运行的机制。而交互建模，正是要通过寻找对象之间的交互关系，从而进行“行为分配”。交互模型的类型与演变交互模型的类型与演变分析阶段的交互模型分析阶段的交互模型l针对用例图中的每个用例，并结合领域模型中的类，寻找分析类，并通过Robustness分析来理清业务逻辑流程，再用交互模型将其确定下来。同时这个阶段，不断地丰富分析模型，将新找到的类添加到类图中去l在分析阶段我们主要关注于区分出边界对象、实体对象和控制对象，暂时不要考虑其具体的实现类 l对于较复杂

46、的用例而言，我们可以按上述的流程逐渐地进行分析、设计、实施；但对于比较简单的用例而言，也是可以直接从用例描述中导出设计阶段交互模型分析阶段的交互模型之后分析阶段的交互模型之后l引入基础类：各种库函数、框架l进行质量评审：1）低耦合2）高内聚3）效率4）完整性5）简单性l优化类设计：设计模式与重构设计阶段的交互模型设计阶段的交互模型l当在分析模型的基础上，通过引入基础类、优化类设计之后，必然会获得新的类模型（设计模型），因此就可能需要基于新引入的“设计类”来更新交互模型，以获得与实际代码相吻合的模型 l是否建立设计阶段的交互模型，也是取决于需要的。通常只有约一半的用例可能需要精化交互模型；如果在

47、一般的MIS应用系统中，这个比例可能会更低 交互模型的建模要点交互模型的建模要点l创建交互图时，应该遵循以下策略：给出一个能表达其目的的名称；通过修改元素的布局，尽量避免交叉线的存在；可以通过注解和颜色作为可视化提示，以突出图形中的重要特性；尽量少用分支，对于分支很多的场景，可以考虑用活动图来补充 l切记“尽可能保持简单”状态图基础状态图基础状态及状态表示法状态及状态表示法l状态是指在对象生命周期中满足某些条件、执行某些活动或等待某些事件的一个条件和状况 l一个状态通常包括名称、进入/退出活动、内部转换、子状态和延迟事件等五个部分组成 阅读简单状态图阅读简单状态图l最为核心的元素无外乎是两个：

48、一个是用圆角矩形表示的状态（初态和终态例外）；另一个则是在状态之间的、包含一些文字描述的有向箭头线，这些箭头线称为转换 转换的五要素转换的五要素l源状态：即受转换影响的状态 l目标状态：当转换完成后对象的状态 l触发事件：用来为转换定义一个事件，包括调用、改变、信号、时间四类事件l监护条件：布尔表达式，决定是否激活转换l动作：转换激活时的操作读图小结读图小结l与状态off相关的转换有两个，其触发事件都是turnOn，只不过其监护条件不同。如果对象收到事件turnOn，那么将判断壶中是否有水；如果没水，则仍然处于off状态；如果有水则转为on状态，并执行“烧水”动作 l而与状态on相关的转换也有

49、两个，如果“水开了”就执行turnOff，关掉开关；如果烧坏了，就进入了终态了 复杂转换复杂转换转换类型描述语法外部转换对事件做出响应，引起状态变化或自身转换，同时引发一个特定动作，如果离开或进入状态将引发进入转换、离开转换事件(参数)监护条件/动作内部转换对事件做出响应，并执行一个特定的活动，但并不引起状态变化或进入转换、离开转换事件(参数)监护条件/动作进入转换当进入某一状态时，执行相应活动entry/活动退出转换当离开某一状态时，执行相应活动exit/活动阅读带复杂转换的状态图阅读带复杂转换的状态图各种转换的区别各种转换的区别l进入和退出转换：当进入一个状态时，执行某个动作；或当退出某个

50、状态时，执行什么动作。这时就可以使用进入和退出转换来表示l内部转换：用来处理一些不离开该状态的事件 活动与延迟事件活动与延迟事件l活动：当对象处于一个状态时，它一般是空闲的，在等待一个事件的发生。但是某些时间，你可能希望描述个正在进行的活动。在处于一个状态的同时，对象做着某些工作，并一直继续到被某个事件中断。l延迟事件：延迟事件是一种特殊的事件，它是指该事件不会触发状态的转换，当对象处于该状态时事件不会丢失，但会被延迟执行。例如，当E-mail程序中正在发送第一封邮件时，用户下达发送第二封邮件执令就会被延迟，但第一封邮件发送完成后，这封邮件就会被发送。这种事件就属于延迟事件。顺序复合状态图顺序

51、复合状态图并发复合状态图并发复合状态图历史历史l“一个圆圈中加上字母H”，用来表示历史状态的。它的含义是：当从状态“结账”和“显示购物车”返回子状态“显示索引信息”时，将进入的是离开时的历史状态。也就是说，转到购物车或结账区之后，再回到“浏览目录”的页面时，其中的内容是不变的，仍然保留原来的信息。状态图应用说明状态图应用说明l对对象生命周期建模：主要描述对象能够响应的事件、对这些事件的响以及过去对当前行为的影响 l对反应型对象建模：这个对象可能处于的稳定状态、从一个状态到另一个状态之间的转换所需的触发事件，以及每个状态改变时发生的动作 l状态机图既可以用来表示一个业务领域的知识，也可以用来描述

52、设计阶段对象的状态变迁。活动图基础活动图基础活动图概述活动图概述l活动图是一种表述过程机理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。因此，它的作用和传统的“流程图”是有着很深的渊源，也十分的相似。不过它与流程图的最主要区别在于，活动图能够支持并行的行为 l在UML的各个版本中，活动图的改变可谓最大，每次UML标准更新时，都对活动图进行了修订。对于UML 2.0而言，最大的改变莫过于去除了“活动图是状态图的一种特例”这一规定阅读简单活动图阅读简单活动图活动图主要元素活动图主要元素l初始节点和活动终点：用一个实心圆表示初始节点，用一个圆圈内

53、加一个实心圆来表示活动终点l活动节点：是活动图中最主要的元素之一，它用来表示一个活动 l转换：当一个活动结束时，控制流就会马上传递给下一个活动节点，在活动图中称之为“转换”，用一条带箭头的直线来表示 活动图主要元素活动图主要元素l分支与监护条件：分支是用菱形表示的，它有一个进入转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上都会有一个监护条件，用来表示满足什么条件的时候执行该转换。l分岔与汇合：带泳道的活动图带泳道的活动图带对象流的活动图带对象流的活动图复杂活动图复杂活动图l辅助活动图l汇合描述：当汇合的所有入流均到点汇合点时，就将执行汇合点指向的活动

54、节点。但是有些时候，你希望对其做一些约束，这时就可以借助汇合描述来完成。汇合描述实际上是一个约束，其格式就是“约束条件”。复杂活动图复杂活动图l发送信号与接收信号复杂活动图复杂活动图l引脚：表示活动节点的相应参数 l扩展区：活动图应用说明活动图应用说明l对工作流建模：用于业务建模的时候，每一条泳道表示一个职责单位，该图能够有效地体现出所有职责单位之间的工作职责，业务范围以及之间的交互关系、信息流程 l建模时应遵循以下策略：l为工作流建立一个焦点，除非你所涉及的系统很小，否则不可能在一张图中显示出系统中所有的控制流。l选择对全部工作流中的一部分有高层职责的业务对象，并为每个重要的业务对象创建一条

55、泳道。活动图应用说明活动图应用说明l识别工作流初始节点的前置条件和活动终点的后置条件，这可有效地实现对工作流的边界进行建模。l从该工作流的初始节点开始，说明随时间发生的动作和活动，并在活动图中把它们表示成活动节点。l将复杂的活动或多次出现的活动集合归到一个活动节点，并通过辅助活动图或子活动图来表示它们。l找出连接这些活动节点的转换，首先从工作流的顺序开始，然后考虑分支，接着再考虑分岔和汇合。l如果工作流中涉及重要的对象，则也可以将它们加入到活动图中。l若工作流中有多次启用的，则可采用展开区表示。活动图应用说明活动图应用说明l对操作建模：每一个对象占据一个泳道，而活动则是该对象的成员方法 l建模

56、时应遵循以下策略：l收集操作所涉及的抽象概念，包括操作的参数、返回类型、所属类的属性以及某些邻近的类。l识别该操作的初始节点的前置条件和活动终点的后置条件。也要识别在操作执行过程中必须保持的信息。l从该操作的初始节点开始，说明随着时间发生的活动，并在活动图中将它们表示为活动节点。l如果需要，使用分支来说明条件语句及循环语句。l仅当这个操作属于一个主动类时，才在必要时用分岔和汇合来说明并行的控制流程。构件图基础构件图基础构件的类型构件的类型l实施构件：这类构件是构成一个可执行系统必要和充分的构件，例如动态链接库、可执行文件，另外还包括如COM+、CORBA及企业级Java Beans、动态Web

57、页面也属于实施构件的一部分。l工作产品构件：这类构件主要是开发过程的产物，包括创建实施构件的源代码文件及数据文件。这些构件并不是直接地参与可执行系统，而且用来产生可执行系统的中间工作产品。l执行构件：作为一个正在执行的系统的结果而被创建的，例如由DLL实例化形成的COM+对象。构件及构件接口表示法构件及构件接口表示法阅读基本构件图阅读基本构件图阅读嵌套构件图阅读嵌套构件图构件图应用说明构件图应用说明l对可执行程序的结构建模1）首先识别你想建模的构件集合2）考虑集合中各构件的不同类型3）对这个集合中的每个构件，分析它们之的关系构件图应用说明构件图应用说明l对源代码建模1）识别出感兴趣的相关源代码

58、文件的集合，并把它们建模为构件；2）对于较大的系统，利用包来进行分组；3）通过约束来表示源代码的版本号、作者和最后修改日期等信息；4）用依赖关系来表示这些文件间编译的依赖关系。部署图基础部署图基础阅读基本部署图阅读基本部署图部署图主要元素部署图主要元素l节点：它代表一个运行时的计算资源，例如一台计算机、一个工作站等其它设备 l节点的概念和构件有许多相同之处，例如二者有多名称，都可以参与依赖、泛化和关联关系，都可以被嵌套，都可以有实例，都可以参与交互。但它们之间也存在明显的区别：构件是参与系统执行的事物，而节点是执行构件的事物；构件表示逻辑元素的物理打包，而节点表示构件的物理部署。l本图中建模了

59、四个节点：B/S客户端、C/S客户端、IIS服务器和数据库服务器 部署图主要元素部署图主要元素l连接：节点之间最常见的关系就是关联关系（用一根实线表示）。为了更好地表示两个节点之间的关系，我们可以通过“约束”来对连接进行描述。源节点目标节点约束含义B/S客户端IIS服务器HTTP+Network网络连接，使用HTTP协议C/S客户端IIS服务器HTTP+SOAP+Network网连接，通过Web Service访问服务IIS服务器数据库服务器ADO.NET.NET提供的数据库访问解决方案部署图补充元素部署图补充元素l处理器（process）：具有处理能力的节点，即可以执行构件。l设备（devi

60、ce）：没有处理能力的节点，至少是不关心其处理能力的节点。例如打印机、IC卡读写器，如果我们的系统不考虑它们内部的芯片，就可以建模为设备。l节点属性和操作：可以为一个节点提供处理器速度、内存容量、网卡数量等属性，可以为其提供启动、关机等操作 部署图补充元素部署图补充元素l自定义构造型图标部署图应用说明部署图应用说明l部署图是一种分两阶段演化的，最初的部署图是在设计时，作为确定最终硬件构架过程的一部分而创建的，然后逐步地对它进行精化，从而得到一个或多个实例形式的部署图。l设计阶段：焦点聚焦于节点或节点实例，以及它们之间的连接 l实现阶段：焦点聚集于将物理构件分配给节点 部署图适用领域部署图适用领

61、域l如果你开发的应用系统是一个单机程序，那么部署图并不能够给你带来什么好处 l嵌入式系统建模：对于嵌入式系统，部署图可以使硬件工程师和软件开发者之间实现更好的交流 l客户机/服务器和分布式系统建模Agenda需求分析最佳实践需求分析最佳实践需求建模最佳实践需求建模最佳实践用例驱动的需求过程实践用例驱动的需求过程实践现代需求工程最佳实践用例驱动的需求实践：概述用例驱动的需求实践：概述需 要特 性软件需求问题域问题域解决方案域解决方案域用例补充规约关于用例分析技术关于用例分析技术l用例分析的创建源于实践，在Ivar Jacobson在爱立信公司研发AXE（电话交换机）时总结而成的l用例的概念确定于

62、1986年，所以它不应该当作一种新技术（有人认为其是一个正处于临床实验阶段的新药）l许多人是在学习UML时，接触到用例，并且产生了一些误解，误把用例图当作了用例分析的全部内容l用例分析技术已经广泛地应用于许多软件开发组织的实践，收效甚佳，成为了软件需求最佳实践之一用例模型的运用方法用例模型的运用方法l增量开发的用例模型l模型的无缝转换用例模型建模要点用例模型建模要点l构建结构良好的用例：1）为系统和部分系统中单个的、可标识和合理的原子行为命名；2）将公共的行为抽取出来，放到一个被包含用例中，再将它include进来；3）对于变化部分，将其抽取出来，放到一个扩展用例（用extent连接）中；4）

63、清晰地描述事件流，使得读者能够轻而易举地理解 l构建结构良好的用例图：摆放元素时，应该避免交叉线的出现；对于语义上接近的行为和角色，最好使它们在物理上也更加接近；l根据系统实际情况控制粒度 核心元素：参与者核心元素：参与者l定义：在系统之外，透过系统边界与系统进行有意义交互的任何事物边界边界类：顾客边界是职责边界，而非物理边界边界是职责边界，而非物理边界谁是机票预订系统的执行者谁是机票预订系统的执行者它们都可以是执行者它们都可以是执行者用户维护人员时间系统系统其他系统参与者：总结参与者：总结l参与者是为了完成一个事件而与系统交互的实体l参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是

64、时钟 l其它系统：当你的系统需要与其它系统交互时，如在开发ATM柜员机系统时，银行后台系统就是一个参与者 l硬件设备：如果你的系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者 l时钟：当你的系统需要定时触发时，时钟就是一个参与者，如在开发Foxmail中的“定时自动接收”功能时，就需要引入时钟作为参与者 核心元素：用例核心元素：用例lIvar Jacobson在RUP中为用例做出了以下定义 用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。步骤目标路径用例：使用场景的抽象用例：使用场景的抽象l场景1：原有客户育才

65、学校呼入，选择电话号码组“全体家长”和“放假通知”音频文件，设置日期、时间和其它呼叫标准，然后启动一个语音外呼任务。l场景2：原有客户精英软件公司呼入，选择电话号码组“全体客户”和“产品升级通知”音频文件，设置日期、时间和其它呼叫标准，然后启动一个语音外呼任务。l场景3：客户通达核电计划在核电力设施发生紧急情况时，向其经理和支持人员打电话。此时，不仅要能够正确地打到家里，还要正确地判断出谁能够接收到这个消息，谁不能够接收。需求提出后，必须马上执行。l启动外呼任务启动外呼任务用例用例l定义：用例描述了执行者（参与者）使用系统实现目标的方式，以及系统为其能够实现该目标而提供的帮助。用例描述了系统及

66、其执行者结合起来向至少一个参与者传递有价值的东西的方式设 定选 择 条件会 员选择 商品会 员检 索 商 品常见错误常见错误l用例太细（用例应包括事件流，事件流中应有步骤）l把步骤当做用例（如登录输入用户名、验证密码）把系统活动当用例！l特例：新增、删除、查询、修改 管理也被戏称为：CRUD（四轮马车）（四轮马车）l误认为用例的粒度与系统实现的复杂度相关l其实很简单，一个用例为执行者提供一个价值会 员登录 系统验 证 用户 名/密 码用例要突出涉众的利益用例要突出涉众的利益l找出用例相关的涉众；l分析涉众的利益所在；l在用例中充分考虑涉众的利益。用例分析技术的组成用例分析技术的组成用例图：用例图：客户登 录系统用例描述：用例描述：前置条件：前置条件：用户启动该应用系统基本路径：基本路径：1）系统显示登录界面；2）用户输入用户名和密码；3）系统验证信息；可选路径：可选路径：后置条件：后置条件：客户登 录系统执行者，Actor参与者 用例，Use Case参与者：参与者：定义了用户在系统交互过程中所扮演的角色，其可以是一个人，也可以是另一个系统。用例图实例用例图实例用例之间的关系：包含关系