第四部分现代软件工程的需求过程ppt课件

1、第四部分 现代软件工程的需求过程,现代软件工程,传统的需求分析方法-1 面向对象的需求分析方法-2 基于UML的需求分析方法-3 需求工程与需求管理实现-4,第四部分 现代软件工程的需求过程,第三章 基于UML的需求分析方法 UML概述-3.1 需求获取与用例建模-3.2 类与对象建模-3.3 动态建模-3.4 物理体系结构建模-3.5,第四部分 现代软件工程的需求过程,3.1 UML概述,UML统一OO方法大战的努力,1960年 - 70年代 COBOL, FORTRAN, C 结构化分析和设计技术 1980年 - 1990年前 Smalltalk, Ada, C+, Visual Basi

2、c 早期面向对象生成（代码）方法 1990年中晚期 Java Unified Process,UML概要,UML是一种语言： 可视化 详细描述的 构造性的 文档化的 UML的价值 是一个开发的标准 支持完整的软件开发生命周期模型 支持不同的应用领域 是基于经验的和用户群体需要的 被许多工具支持,什么是UML?,Unified Modeling Language（统一建模语言）是国际对象管理组织OMG制定的一个通用的、可视化建模语言标准 用于描述（specify）、可视化（visualize）、构造（construct）和记载（document）软件密集型系统的各种工件 UML提供了一系列建模元

3、素、概念、关系以及规则，应用于软件开发活动 详细内容，请学习统一软件开发过程（The Unified Software Development Process）（美）Ivar Jacobson、Grady Booch、James Rumbaugh著，周伯生、冯学民、樊东平译（机械工业出版社）,UML概念,UML Unified Modeling Language. 组合了当前最好的面向对象软件建模方法 UML三位主要贡献者 1. OMT方法（对象、动态、功能模型，James Rumbaugh） 2. The Booch method （5个步骤，Grady Booch） 3. OOSE （Us

4、er Case图，Ivar Jacobson）,James Rumbaugh,Grady Booch,Ivar Jacobson,UML概念,1994年，Booch和Rumbaugh在Rational开始了UML的工作，但是的目标是创建一个“统一方法” 他们把Booch93和OMT2统一起来，与95年发布了UM0.8（Unified Method） 1995年OOSE的创始人Jacobson加入到这个联盟中，开始把工作重点放到创建一种标准建模语言，UML Unified Modeling Language。 他们以Booch方法、OMT方法、OOSE方法为基础，吸收了其他流派的长处，于96年6

5、月、10月、97年1月、11月分别推出了UML0.9、0.91、1.0和1.1,创建UML,Booch 方法,OMT,UML概念,Method 方法告诉使用者做什么、怎么做、什么时候做、为什么做（特定活动的目的），方法包括模型 Modeling 模型用来描述使用某种方法的结果，例如，通过不同角度的简化视图，描述对象系统的设计与实现结果，模型用建模语言来表达 Language 建模语言由记号（模型使用的符号）和一组规则（语法、语义等）组成,UML概念,UML是一种语言 遵循特定的规则 允许创建各种模型 并不告诉设计者需要创建哪些模型 并不提供开发过程 UML是可视化语言 UML是图形化语言 图形

6、便于交流（一幅图抵上千文字） UML是用于构造系统或理解系统的语言 UML既支持正向工程，又支持反向工程 UML是文档化语言 将所建造的系统记录下来 便于新程序员跟进 开发产品新版本时很有用处,UML的概念,模型元素 关系 扩展的机制 图表,UML构成：模型元素关系扩展的机制图表,模型元素,关系,图表,模型元素,结构元素 类，接口，协作 用例，主动类，构件 节点 行为元素 交互, 状态机 组元素 包, 子系统 其它元素 注解,类、对象与接口,一个系统往往可以从不同的角度进行观察，一个角度构成了一个视图 UML有九种图表，构成5种视图： 1、用例图（use case diagram） 2、类图（

7、class diagram） 3、对象图（object diagram） 4、状态图（state diagram） 5、时序图（sequence diagram） 6、协作图（collaboration diagram) 7、活动图（activity diagram） 8、构件图（component diagram） 9、部署图（deployment diagram）,UML的图表与视图,静态逻辑视图,动态逻辑视图,3-并发视图,1-用例视图,5-部署视图,2-逻辑视图,4-构件视图,模型,视图,和图表,活动图,模型是对一个系统从详细观察的角度的描述,模型,图表,图表是模型的视图 表现给投资者

8、看得详细的描述; 提供了系统的局部详细描述； 和别的视图保持语义一致； 在UML中,有九种标准图表 静态视图: 用例图, 类图,对象图,组件图 , 分布图 动态视图: 时序图,协作图,状态图,活动图,用例图,捕获用户能够看到的系统 通过对”场景”的描述，定义系统的功能和性能，并获得用户和开发团队的共同认可 提供清楚和无二义的用户与系统的交互描述,用例图,在开发过程的早期创建 目的： 详细说明系统的表达含义； 捕获系统的需求； 验证系统的体系结构； 驱动实现和生成测试用例。 由分析人员和领域专家开发,Use Case图,Use Case图形描述了一个系统应该执行的什么或应该有什么外部系统 它描述

9、了存在的actors（外部系统）、use case（该系统应该执行什么）以及它们的关系 在Use Case视图中可以包含以下的图形 Use Case图：包括：包、actors、use case和关系 相互作用图（序列图或协同图）：包括：对象和消息 符号表示：,Use Case图例,类图,捕获系统的词汇表 在开发过程中被创建和精确化 目的 系统中的名字和模型概念 详细描述协作关系 详细描述逻辑数据库表 由分析人员、设计人员和代码实现人员开发,类图Class Diagram类图描绘系统的静态视图它描述了系统逻辑设计中存在的包、类以及它们之间的关系类图可以代表该系统中部分或全部的类结构,1购买 0.

10、* 属于,对象图,捕获实例和连接,对象图,捕获实例和连接 在分析和设计阶段创建 目的 举例说明数据/对象结构 详细描述瞬态图 由分析人员、设计人员和代码实现人员开发,对象图Object Diagram,对象间关系,关联关系 (Association) 聚集关系(Aggregation) 泛化关系(Generalization) 依赖关系(Dependency) 细化关系 (Refinement),构件图,捕获实现的物理结构,构件图,捕获实现的物理结构 作为体系结构规范的一部分实现 目的 组织源代码 构造一个可执行的发布版本 指定物理数据库 由集成人员和程序人员创建,分布图,捕获系统硬件的拓扑结

11、构,分布图,捕获系统硬件的拓扑结构 作为系统结构规范的一部分被创建 目的 描述组件的分布 标识系统性能瓶颈 由集成人员、网络工程师和系统工程师开发,交互图,交互图描述了系统在逻辑设计中存在的对象及其间的关系 它可以代表系统中对象的结构 UML中包含两种交互图，它们对同一交互操作提供了不同的浏览视角 时序图 按时间顺序排列对象交互操作 协作图 围绕对象及其间的链接关系组织对象的交互操作,时序图,捕获系统的动态行为(面向时间的),时序图,捕获系统的动态行为(面向时间的) 目的 模型流程的控制 举例说明典型的脚本,打印机就绪 打印文件,时序图（Sequence Diagram）,打印机忙 保存文件,

12、打印文件,打印文件,计算机,打印服务器,打印队列,计算机,协作图,捕获系统的动态行为 (面向消息的),协作图,捕获系统的动态行为 (面向消息的) 目的 模型流程控制 举例说明对象结构和控制的协调,协作图（Collaboration Diagram）,状态图,捕获系统动态行为(面向事件的),状态图,捕获系统动态行为(面向事件的) 目的 对象生命周期模型 为起反作用的对象(用户接口、设备等）建模,状态图State Diagram状态图描述了：给定类的状态转换空间导致状态转换的事件导致状态改变的动作为类的重要动态行为建立状态转换图,活动图,捕获动态行为（面向活动的）,活动图,捕获动态行为（面向活动的

13、 目的 给商业工作流建模 给操作建模,活动图Activity Diagram,体系结构和UML,组织： 包, 子系统,动态 交互 状态机,设计视图,实现视图,过程视图,组件,类, 接口, 协作,活动类,分布视图,用例,UML静态图,用例图（Use Case Diagram） 类图(Class Diagram) 对象图(Object Diagram) 构件图(Component Diagram) 部署图(Deployment Diagram),UML动态图,状态图（State Diagram） 时序图（Sequence Diagram） 协作图（Collaboration Diagram） 活动

14、图（Activity Diagram）,UML建模方法与视图,用例建模 用例图 类和对象（结构）建模： 类图 对象图 行为（动态）建模 用例图 交互图（顺序图、协作图） 活动图 状态图 物理体系结构建模 构件图 实施图,UML过程,UML过程主要包括： 用例驱动（use-case-driven） 以体系结构为中心（architecture-centric） 反复（iterative） 渐增式开发（incremental）,UML过程,1、用例驱动： 用用例方法获取系统的功能需求，并以此驱动需求分析之后的所以阶段的开发 在需求阶段，用例所包括的系统功能，需要用户的确认 在设计和实现阶段，用例被实

15、现 在测试阶段，用例用于验证系统功能,需求,用例,用例影响开发的所有阶段 用例视图影响其他视图,UML过程,2、以体系结构为中心 项目开发的早期，除了需求以外，另一个最主要的工作就是确定系统的体系结构 体系结构定义了系统的各部分、各部分的关系和交互、通信机制、如何增加和修改体系结构的规则 体系结构决定了系统的功能和非功能部分 非功能部分包括：性能、易理解性、易修改性、复用度 在UML中，通过定义可以层次化的“包”，来实现把一个大系统划分成不同的小系统 确定体系结构的基本方法是：分析、选择、原型化、评估和精细,UML过程,3、反复迭代 用UML方法建模，可以反复多次，不需要一次完成 通过反复，增

16、加新信息、细化新的细节 每次反复，应进行评估，评估的内容还应包括：代价、风险 4、渐增式 多次迭代，每次迭代增加新的用例和功能 每次迭代，都是分析、设计、实现和测试的过程 迭代的最大好处是分解了风险，不至于把失败的风险留到开发的最后才发现,3.2 需求获取与用例分析,需求开发过程的阶段任务,需求开发过程的重要里程碑,基于UML的需求获取,1、需求获取与业务建模,对于一个复杂的业务系统，我们可能涉及：公司组织、业务单位、部门和人员岗位、职责和功能、内部和外边网络、客户、业务信息流、行政和财务流等等 为这个组织建立计算机系统，我们要回答： 为什么要建立这个系统 这个系统的定位在何处 我们如何确定哪

17、些功能是最适宜放在系统的特定节点上 我们何时采用计算机处理而何时采用人工处理 为适应计算机处理，我们需要改变现有工作流程吗 回答这些问题的技术，就是业务建模,业务建模的目的： 建模过程是开发者和用户之间为导出需求规约而进行的交互过程 因此： 理解现有业务组织的静态结构和动态运作方式 确保客户、最终用户以及开发人员对业务组织有共同的理解 系统的边界在那里？功能是什么？ 理解如何部署新的系统以提高生产力，以及现有的哪一个系统会受到新系统的影响 系统的功能由用例来表示： 用例用来： 确定和描述系统的功能要求 给出清晰和一致的系统做什么的描述 为验证系统所需的系统测试提供基准 提供从功能需求到系统实际

18、类和操作的跟踪能力,传统方法：业务流程图存取款业务处理过程,在UML中的建模结构就是业务用例模型和业务对象模型 领域模型将系统语境中的重要概念描述为领域对象，并建立这些领域对象之间的关系 业务模型是领域模型的超集，包括： a.业务用例模型：说明系统所支持的业务过程 b.业务对象模型：领域模型和业务用例实现 业务用例模型是业务系统预期功能的描述模型，是系统开发任务和作为产品提交时的最根本的系统工作描述 业务对象模型描述了实体和相互交互完成业务用例所需要的功能，是业务用例的实现 下面，我们用示例介绍,利用UML概念进行业务建模,业务过程与业务用例,一个业务过程是根据组织目标而采用组织资源来获得预定

19、义结果的一组逻辑相关的活动 用一个业务用例代表一个业务过程 业务用例包括： 角色（与业务活动交互的人或系统） 用例（角色与业务元素交互完成工作的事件序列） 建立业务用例的过程： 确定行为者 确定用例,确定行为者,行为者： 与系统交互的人或其他系统 交互：发送、接收、交换信息 行为者执行用例 行为者是一个角色，而不是具体个人 寻找行为者 谁使用系统的功能 谁需要系统提供信息 谁维护、管理、控制系统 系统完成功能还需要得到其他系统的支持 还有哪些人对系统的结果感兴趣,业务用例 银行,确定用例,一个用例是被行为者感受到的一个完整的功能UML的定义：用例是给一个特定行为者的一个可观察的结果值的系统所完

20、成的一系列动作这个动作除计算机内部完成的计算外，还包括与行为者的信息交互用例通过关联与行为者进行交互用例总是被行为者所启动，并回答一个可识别的结果类似于对象是类的实例，用例的实例是场景（scenario）。例如：“用户在ATM机上执行取款操作”用例的场景是：“张三在ATM机上取出300元人民币”寻找用例行为者需求系统提供哪些功能？行为者是否需要创建、读、写、修改、删除系统中的信息？行为者是否需要被系统提醒、启动系统的某个功能？系统能否帮助行为者做一些事情，来提高行为者的效率、便利,寻找用例,考虑人和饮料贩卖机的交互，包括购买饮料，首先，放置货物（饮料）等，下面考虑购买饮料。,l 用例描述了系统

21、的行为，包括行为者和系统之间的交互以及系统与系统之间的交互。 用例是系统提供的功能块。演示了人们如何使用系统。它来自于客户需求的分析。这个过程称为Use Case分析, 是整个系统开发中非常关键的过程。,我们设计一个饮料贩卖机，从用户的角度来考察它的功能： 问:“自动饮料贩卖机将为您做什么?” 答:“我通过自动饮料贩卖机购买一听饮料.” 饮料贩卖机的主要功能是使得用户可以购买饮料， 我们为这种机器标记一个叫 “买饮料”的use case.,UML中的 Use Case 表示,Buy Soda,Use Case,Actor,Communication,Customer,use case记录用户使

22、用系统是从头到尾的一系列事件。用户普遍称为“活动者”，它可以是人或另一个系统。 每一个 use case 包括 “活动者”和一个表示 use case 的椭圆。,Use Case,活动者,活动者可以是人或另一个系统，它与当前的系统交互，向系统提供输入或从系统中获得输出。,Actor Name,Telephone System (电话系统）,使用电话卡,对方付款,Phone User (电话用户）,活动者的标志,谁对某一需求感兴趣？ 组织中哪一部分使用系统? 谁从系统的使用中受益? 谁向系统提供信息？ 谁将维护系统？ 系统使用外部资源吗? 系统和已经存在的系统交互吗?,活动者的类型,实际的人，即

23、用户，是最常用的角色，几乎每个系统都有。命名这些角色的时候，要按作用来命名，而不是按照位置命名。 另外一个系统。例如航空订票系统可能需要与外部应用程序接口，验证信用卡以便购买。 可能隐蔽的角色：时间。例如商业促销项目推出免费奖，每天下午三点，系统自动选择向随机客户提供免费奖品。,在饮料自动贩卖机中，除了买饮料的顾客， 还有以下的活动者。,Buy Soda,Restock Soda,Collect Money,Customer,Supplier,Collector,每一 种活 动者 具有 自己 的 use case,饮料贩卖机中的活动者,供应商向自动贩卖机添加饮料。 收银员从自动贩卖机收钱。,理

24、解用例,用例独立于实现。用例关注的是作用而不是如何实现这个作用。 用例是系统的高级视图。用例的集合应让客户易于了解高层的整个系统。 最后，用例关注系统外的用户。每个用例应表示用户与系统间的完整事务，为用户提供一定价值。用例应按业务术语命名，而不是按技术术语命名，应让客户一目了然。 例如：用例不要命名为“客户与银行ATM的交互界面”，如果客户要买票, 用例可以称为“客户购票”。,用例分析有助于: 捕捉需求 计划开发过程的循环往复。 验证系统。 需求分析从用例分析开始，它驱动整个开发过程。 在用例中描述了所有的功能需求。,标记用例,活动者希望这个系统执行什么任务。 活动者在系统中访问哪些信息 (创

25、建, 存储, 修修改, 删除等)? 外部的哪个变化将要被告知系统？ 系统的那个事件将要被告知活动者？ 系统将要怎样维护?,标记用例,用例的完整性 每个功能需求是否至少在一个用例中?如果需求不在用例中,则不会实现。 是否考虑了每个操作者如何使用系统。 每个操作员向系统提供了什么信息。 每个操作员从系统接收了什么信息。 是否考虑了维护问题，要有人启动和关闭系统。是否标示了系统要交互的所有外部系统。 每个外部系统从系统接收什么信息和系统发送什么信息?,用例视图,一个 use case 视图包括 一个use case 集合，定义整个系统的功能 。,Buy Soda,Restock Soda,Colle

26、ct Money,Customer,Supplier,Collector,Soda Machine,Use Case 视图,系统 边界,用例的范围,2、从业务模型到系统模型,例：建立用例的系统模型,ATM取款机作为一个业务系统 来取款的客户是一个角色 用例是业务模型中业务的活动 系统模型描述了业务中系统的工作（内部活动） 角色是外部，用例是内部。取款的客户是角色，取款是用例。 用例模型开始定义角色之间的关系（关联关系、包括关系、扩展关系、一般化关系等）。 用例模型描述事件流，包括主事件流、其他事件流、前提条件、事后条件等等。 这样，我们就建立了一张描述“活动”的Use Case图，通过这张图，

27、我们就能够比较具体地描述“活动”，即让用户看到： 谁与系统交互，有助于发现缺少的参与者 知道系统的范围，有助于发现缺少的功能,业务用例描述：柜台取款,业务用例活动图：柜台取款注意：这里只有角色（客户）和用例（系统）对于系统内部的实现，我们还没有更多的涉及,从业务模型到系统模型 - ATM,系统用例 ATM,系统用例 - ATM取款,用例序列图 - ATM取款系统开始区分ATM系统和银行主机系统,用例的层次,概要目标用例： 需要多个用户目标会话来完成（日、周、月、年） 用户目标用例： 满足特定、迫切、有价值的用例目标（分钟、小时） 子功能用例： 为了完成用户的真实目标而提供的功能,用户目标层,“

28、Can the actor go away happy after having done this?” 通常1个人，1次性完成，2-20分钟,概要目标层,使用ATM用例：银行自动柜员机 含有多个用户目标，可包含：存取款、查询、修改密码、打印凭单、提供跨地域、跨银行服务 作用 说明用户目标执行的背景 说明相关目标的范围 提供了下层用例的目录,用户目标层次,用例分析流程,定义系统范围和边界 列出角色及其作用 提取概要用例并调整得当 着重对系统的用户目标层用例进行细化 填写干系人责权利、前置后置条件 编写基本流 列出所有扩展条件，编写扩展处理步骤 用活动图、状态图、交互图等描述重点用例 9. 分解

29、、合并用例，调整用例关系模型（用例图）,需求获取关键是获得用户的确认,建立业务模型的工作主要包括： 分析领域中的业务角色 分析角色间的业务功能等关系 分析业务组织架构 分析业务规则 分析业务实体 分析业务事件 分析以业务角色为主角的业务用例等； 以业务用例为实例，与用户进行沟通： 需求是否被清楚地陈述？ 存在错误的理解吗？ 需求的来源（人员、规章制度、文件）是否正确？ 需求的最终陈述是否得到用户最终责任人确认？,问题 用户不知道他们需求什么或不知道如何表达 直到开发人员把用户所描述的东西给他们，用户才认为知道自己要什么 分析人员认为自己比用户更了解用户的需求,解决方案 将用户当作领域专家来认识

30、和感激， 尝试一下其他沟通和启发技术 尽早提供相互选择的启发技术：情节 串联板、原型、角色换位等 把分析人员放在用户的位置，试着换位一小时或一天,解决用户和开发人员综合症,介绍游戏规则,被动式介绍,主动式介绍,交互式介绍,需求诱导的方法（情节串联板）,原型开发,复杂程度与成本,需求获取过程需求管理的关注点,步骤： 1、发现和分析问题 2、理解用户的需求 3、定义系统（用例模型） 4、管理范围（项目管理） 方法： 采用业务建模和系统建模的方法进行问题分析 对与系统架构和系统行为有关的用例进行描述和定义 目标： 在问题定义上与用户达成共识 理解问题背后的根本原因 确定用户和项目干系人 定义问题解空

31、间的边界 确定问题解决方案的约束和假设 最终阶段完成标志：用户对系统目标的认可签字,需求获取过程产品基线管理的关注点,技术创新和突破,产品特点,客户：涉众和用例,分析人员和专家的意见,与公司其他产品的配套和一致性,与对手的竞争性产品差异和优势,开发团队的状况与产品的可持续性,系统平台与兼容性,公司目标与市场需求,一个真正伟大的产品,需求获取过程产品路线管理的关注点,图例：,正在发行,发布代码行,需求提取的最佳实践,明确构想和范围 确立需求开发过程 用户群分类 选定产品代表 建立用户核心队伍 建立用例模型 举办用例演示会,分析业务流程 明确质量属性 检查问题报告 重用需求 ,用例常见错误,无系统

32、目标或边界 无角色定位 用户界面细节过多 目标层次太低 目的与内容不一致 含有设计内容 过多的数据细节,“ 用例分析是当今消除需求不明确、不一致、不完整 的重要手段和关键技术 ” 用例在需求获取阶段的好处： 与传统的需求分析方法相比，用例书写简单、易于理解 用例迫使开发人员从系统设计时，就从用户的角度考虑问题 用例使用户参与需求过程，帮助他们理解所建设的系统，并提供了一种交流和记录的工具 用例给出了需求的情景，从而使人们理解需求的原因以及系统是如何实现它的目标 大多数情况下，用例是开发人员写的，因此，他是理解这个需求，也知道最终要对实现这个需求负责的,用例在系统开发的其他阶段的好处： 用例在分

33、析阶段，也是一个关键的工具，它帮助我们理解系统需求做什么以及系统可能如何去做 用例在设计和实现过程中，也是一个关键的工具，它降低了因需求表达不确切和不一致，导致系统开发错误的风险 用例可以直接延伸到测试过程，这有利于确保系统真正做了它应该做的事情 用例也是用户文档的输入，可以从用例开始，很方便地组织用户文档的编写,用例在组织软件开发中的核心作用,用例驱动模型,到目前为止，我们完成了需求获取阶段的任务通过采用用例的方法，建立了业务模型，使用户理解并确认系统要做什么和不做什么,3、从业务用例到测试用例,V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过

34、程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。,测试与开发阶段的对应V模式,验收测试,在行业应用软件环境中，验收测试是项目过程非常重要的一环，也是项目经理非常关注的一项工作。 验收测试与确认测试非常相似，所不同的是，确认测试是项目组或组织内部的测试，验收测试是用户主导、现场参与、现场环境下的测试。 验收测试通常由项目组先提出测试大纲，定义测试目的、范围、方法、测试用例、预期结果、验收标准等。经用户同意批准，可能包括用户的修改、增加后，确定测试时间，开始进入验收测试。 用户在完成按测试用例的测试后，在测试记录上逐条确认、签字，最后，在测试报告上签字，完成验收测试

35、。 一般地、验收测试报告是项目初验、终验的依据和主要验收形式。,系统验收与用例的关系,验收测试的用例，在需求获取完成后产生 测试用例的依据是需求获取的业务用例。 （1）从业务用例到实现用例 （2）从业务用例到测试用例,根据用例的事件流分析，针对用例情景，产生验收测试用例。,从用例到测试用例,3.3 需求分析与类和对象建模,从现在开始，我们完成了“需求获取”阶段的任务，进入“需求分析”阶段 需求获取阶段完成的标志，是获得用户签字确认的需求描述 需求分析阶段任务完成的标志，是在经过需求分析、需求处理后，通过“需求评审” 从现在开始，我们要用面向“实现”的眼光，来看待需求 什么是面向实现？ 需求分析

36、阶段的“面向实现”，是面向可交付成果 什么是面向成果？我们先看一下需求评审的要求,需求开发过程的阶段任务,需求开发过程的重要里程碑,基于UML的需求分析,传统的需求分析阶段,需求分析阶段的任务和步骤 复查系统规模和目标 研究现有系统功能 导出新系统模型 重新定义问题 导出和分析各种可选解决方案 推荐行动方针 草拟开发计划 书写文档提交审查 阶段成果交付物： 需求定义文档（需求规格说明）,循环,需求分析需求获取与需求分析的区别,需求获取是面向用户、在较高的抽象级别上对系统特性的定义 可以更多地关注系统的特性以及如何体现用户的需求，以便更好地理解系统的形状和形式 可以对系统的完整性、一致性以及对环

37、境的适应性进行评估 在继续大量投入之前，可以利用这些信息决定可行性和管理系统的范围 可以脱离对具体需求进行取舍和决策所带来的风险 需求获取的目标是用户的认可，因此，阶段的验收标志是用户签字确认的需求描述,需求分析需求获取与需求分析的区别,需求分析是面向系统实现、严格对系统需求的定义 定义系统的输入、输出、功能、属性以及系统环境的属性，决定系统的完整集合 面向系统技术实现，讨论系统应该做什么，因此，应避免受项目进度、计划、预算、设计、测试等的影响 需求和设计是迭代进行的，但需求将引导设计，也受设计方法的制约 需求分析的验收标志是组织的需求评审,需求分析细化系统定义,在需求获取阶段，我们已经通过建

38、立业务模型、系统模型，与用户共同确定了系统的特性： 业务用例模型，可以映射出软件产品核心的需求，包括与业务功能对应的组织的特性，与业务流程对应的内外部关系特性等； 系统用例模型，是在已经建立的业务模型的基础上，建立系统的模型。 用例业务模型和系统模型的最典型表示形式 软件产品本身可能还存在与业务无直接关系的另类需求（一般与硬件、软件环境相关），比如支持多种操作系统、对软件运行的远端监控要求、异常处理（如通讯连接中断等非业务异常）等等。 另一方面，设计约束和限制，也是系统需求必须要考虑的内容 通常这三部分需求构成软件需求的总集。,需求分析细化系统定义,在需求分析阶段，我们不可避免地要涉及到进行设

39、计决策 设计决策： 硬件环境（运行在PC服务器上？还是小型机？） 平台的选择（只支持Windows平台，是否也支持UNIX平台？） 工具的限制（采用VB实现？） 方法的约束（用XYZ类库实现数据库访问？）,需求分析是在需求获取、需求分析和设计决策之间反复迭代循环的过程,需求分析细化系统定义,软件需求是具体的： 面向系统设计、编码 面向测试 因此，在需求获取的基础上，进一步细化系统需求、明确和细化系统定义，这就是需求分析阶段的任务 在传统软件过程方法中，这二个阶段不是非常清晰和明确,需求分析细化用例,在需求获取过程中，我们建立了业务模型和系统模型，引入了角色和用例的概念 角色与用例的区别： 系统

40、的角色是业务之外与业务交互的人或事 例如：ATM取款机作为一个业务系统，来取款的客户就是一个角色 用例是业务模型中，业务的活动 在系统模型中，描述了业务中系统的工作（内部活动）。角色是外部，用例是内部。取款的客户是角色，取款是用例。 用例模型开始定义角色之间的关系（关联关系：包括关系、扩展关系、一般化关系等）。用例模型描述事件流，包括主事件流、其他事件流、前提条件、事后条件等等。,需求分析细化用例,细化用例的主要步骤： 审查主角 细化描述 定义和细化事件流程 确定前置条件和后置条件 确定特殊需求 扩展用例,需求分析细化用例关系,为需求处理做准备 在定义系统的用例规约之前，确定一份基本的术语词汇

41、表，以统一项目开发中的用词。 确定系统的用例，通常从寻找系统的主角开始。如果做了业务建模，则可以先从业务对象模型中的业务工人（Business Worker）着手。 系统主要的主角确定后，可以根据为系统主角提供有价值的结果（Result of Value）这一准则（用例是为主角的活动最终提供一个有价值的结果的活动过程）来确定系统的用例。 理清系统用例之间存在的密切关系，具有的内在结构，如泛化关系、包含关系、扩展关系等。 有二种Interaction图，按时间顺序排列的是Sequence图，按对象关系排列的是Collaboration图。二种图从不同的角度，反映了案例中特定情形的流程。,需求分析

42、的成果需求评审内容,CMM2对评审内容规定为： （1）确定不完整和遗漏的给定需求； （2）评审给定需求以确定他们是否：可行、适用于软件实现、说明清楚、适当、彼此一致、可测试。 （3）有负责分析和分配系统需求的小组对确认可能有问题的给定需求进行评审并进行必要的修改。 （4）相关小组协商由给定需求所得出的约定。 在这里，我们最主要先关注（1）（2）二条 第一条：需求分析阶段的需求规格说明必须与需求获取阶段经用户签字确认的用户需求描述一致 第二条：需求规格说明还应具有一些特定的属性,良好的需求规格说明属性,具有良好的需求规格说明属性的需求文档，具有如下的属性： （1）不含糊性：如果每一个需求只有唯一

43、的一种解释，那它是不含糊的； （2）完整性：如果需求包括了功能、性能、时间响应要求、限制、接口等属性，不存在没有界定的、以为是隐含或默认而实际存在认知差异的需求，是完整的； （3）可检验性：存在有限的、经济与技术都是可行的检验方法和程序，对需求的实现与否，进行检验，使得用户和组织通过该检验，确认需求被按照需求规格说明实现； （4）一致性：需求作为一种要求是一致的，不存在系统内相互冲突的需求要求； （5）可跟踪性：需求可追踪； （6）可使用性：可为产品的各阶段，特别是维护阶段，提供充分有用的信息。,所以，我们现在可以理解： 需求分析，就是为了实现系统需求，并使最后交付成果与需求所要求的目标，不产

44、生：含糊性、不完整性、不可检验性、不一致性、不可追踪性和不可用性，而进一步对需求进行描述和定义。 需求分析继承需求获取阶段的成果 需求分析面向下阶段系统概要设计 需求分析采用自己的特定方法，达到相应的阶段要求 需求获取阶段的目标是让用户签字 采用的方法是尽量地让用户和开发团队都能理解并认同系统目标和范围界定的方法业务/系统模型、用例和USE CASE图 需求分析阶段的目标是用计算机的（而不再是用户）眼光和语言，分解需求、定义需求。但是，这个眼光不是程序设计员的眼光，是系统分析师的眼光 经过下一步需求处理后，达到需求规范要求 分析的方法是一套“建模”技术,需求分析的成果：,用例驱动的分析,为了进

45、一步描述系统，我们现在需要建立类和对象模型 类和对象模型，描述了系统的静态结构 有了系统的静态结构，我们才可以在静态结构的基础上，建立系统的行为（动态）模型 在面向对象方法中，我们已经介绍了如何建立类和对象的模型 UML的特点是一套统一描述方法和符号,用例驱动的分析实现,Booch method 的5个步骤 （1）使用“寻找什么”标准来标识类和对象分析类 （2）定义一般/特殊结构、定义整体/部分结构分析包 （3）标识主题（子系统构件的表示）建立子系统 （4）定义属性和实例联系 （5）定义操作和消息联系,静态建模,动态建模,UML的三个来源和三个组成部分： OMT、5步骤、图形符号,从业务/系统

46、模型到分析模型,分析类（逻辑结构） 用例实现：将用例的实现（执行）表示为分析类（对象）之间的交互 分析包（物理结构） 以包（分块）的方式组织分析模型的组件 强内聚、弱耦合 完整性、正确性、一致性和易读性,类是信息和行为的包装 对象是类的特定实例 类图由系统中的类和它们之间的关系组成 例如：在C/S结构的系统中，我们把系统的信息放在数据库一方，行为放在应用程序一方。 面向对象的特点之一就是将信息和影响信息的行为连接在一起，包装成类。 类图和对象图：,（1）类/对象图静态分析,类,对象,对象图使用与类图相同的形式 只是在对象名下加一个下划线 对象名后可接以冒号和类名,分析的开始查找类,分析从寻找类

47、开始，然后定义类的属性和操作 类来自问题域，核心关键是分析者对问题域的理解 应邀请问题领域的专家和用户参与 寻找类可以从以下方面考虑： 系统是否有需要储存、转换、分析和处理的信息，这些信息与系统特定时刻所发生的事件和处理有关，需要经常寄存 系统是否有包含或需要与之交互的外部系统 系统是否有需要利用已经开发的构件 系统是否联接有外部设备 在业务模型中确定的角色，如：客户、操作员等，可以看成是一个类,分析的开始查找类,面向过程的程序设计的系统抽象方法： 由语句组成（抽象成）函数 有一组函数等，构成有特定功能的子程序 系统由总控、功能子程序构成 实现是如上的由下自上 分析是根据如上的自上而下 面向对

48、象也一样 如果没有类库，一切从头来，则是很困难的，有再多原则也没有用 有了类库，分析的过程就是按已经有的类“套（动词）” 所谓“套”就是功能配对 一种寻找类的思想方法： 类-责任-协作者（Class-Responsibility-Collaborator,CRC）模型是一种简单的寻找和组织类的方法（确定类、明确责任、清晰协作关系）,MFC类的层次结构,CObject 所有MFC类之父,CCmdTarget发送系统和窗口事件给相应对象,CWinThreadMFC线程控制,CWnd 基本GUI对象类,CDocument 文档和视图类,CWinApp 主线程和主程序,CFrameWnd标题菜单边框类

49、,CView 文档的显示打印,CDialog 对话框类,CMDIChildWnd,CMinFrameWnd,CMDIFrameWnd,MFC的类结构，是基于模型/视图/控制器（MVC）模式的,类：按特征进行类分析,考虑的原则： 确切性：类是具体的事务还是抽象的信息 包含性：类是原子的，还是聚合的 顺序性：类是并发的，还是顺序的 永久性：类是临时的，还是永久存在的 完整性：类是否是不受外界的影响的 考虑的要素： 通讯/消息/路由、分布性事务、进程控制和同步、安全性 信息交换、格式转换、可用性、冗余性 应用集成 差错检测/处理 日志/报告 ,责任：类的属性和操作,属性： 属性是类的最基本的稳定特征

50、 类的属性表明类所必须完成的任务和职责 属性是从问题域分析中抽取出来的 属性是对问题的理解的深化 操作： 从系统处理功能中提取 操作反映了类的具体行为 把责任划分到类的5个原则： 尽可能地均匀分布 每个责任应尽可能地进行概括陈述 信息和与之相关的行为应保留在相同的类中 与一个事务有关的信息应局限在一个类中 仔细地设计类之间的协作关系,协作：类的另一个角色,协作： 独立完成：类使用自己的操作，完成自己的任务。 类自己不能独立完成任务，需要向其他类发送消息，请其他类协助完成某任务，由此产生协作。 例如：客户端向服务器端发出请求，完成信息查询任务。 协作是类之间的关系，当一组类协作完成一个任务时，它

51、们构成一个子系统 类之间的属性关系有三种： 部分（is-part-of） 知道（has-knowledge-of） 依赖（depends upon）,协作,类和对象在语境中通过互操作完成一个行为（如用例或对象的某个操作） 静态部分（结构）描述在协作实例中类和对象可能承担的角色。 动态部分（行为）包括一个或多个交互，表示在执行计算过程中不同时间（时序）或条件（状态）里协作中的消息流。 协作角色：一组实例在执行一个特定任务时所扮演的角色,用例实现,类分析：职责分配，如确定是控制类、实体类和边界类 用交互图（协作图、序列图）描述角色实例与分析类对象之间的交互 每个用例都需要一个或多个协作来实现,对于

52、很多的应用系统，可以考虑把类分成三种 边界类（Boundary） 系统的外部界面，如：传感器、显示、输入、外部的其他系统 控制类（Control） 系统的控制逻辑，如：业务流程、算法、处理要求等 实体类（Entity） 系统的永久存储信息，如：数据库信息 例子：考察课程登记的Use Case 边界类（窗体和报表） 登记表格、计划表、计费界面、课程表 实体类（数据库存储） 安排的课程、可提供的课程、学生计划、学生信息 控制类（处理过程） 注册管理、登记管理 考虑一下： 符合类划分的原则 明确类的责任 清晰协作关系,UML对类进行了分类，既所谓：B-C-E模型 UML有三种基本的构造型：边界、实体

53、和控制。 边界类（Boundary Calsses） 边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口以及与其他系统的接口。 要寻找和定义边界类，可以检查Use Case框图。每个角色/使用案例交互至少要有一个边界类。 边界类使角色能与系统交互。 例如，假设要迅速寻找模型中所有窗体，可以创建Form类型，将所有窗口指定为这个类型。要寻找模型中的所有窗体时，只要寻找Form类型的类即可。,UML类的三种基本构造型,控制类（Control Classes） 控制类负责协调其他类的工作。每个使用案例通常都有一个控制类，控制使用案例中事件顺序。在Interaction框图中

54、，控制类具有协调边界与实体有关消息的责任。还有处理共用功能的管理者，如资源竞争、分布式处理和错误处理等。 实体类（Entity Classes） 实体类保存要放进永久存储体的信息，在B-C-E模型中，通过实体类将数据库封装起来。例如：在JAVA中，实体类可以想象成负责处理JDBC的组件，而在EJB中，Entity Bean就是一个相当好的实体类的范例。 增加类的类型 除了上述版型外，还可以向模型中增加自己的构造型。,类的三种基本构造型,ATM取款：用例的类提取,分析和设计： 找到用例模型的类，寻找的方法是按照边界/控制/实体（BCE）模型 然后“套”已经在类库中定义好的类。在实现中，真正需要自

55、行创建的“类”并不多，甚至不需要自己创建 类库就是按BCE模型设计的,边界类,控制类,实体类,边界类,采用B-C-E模式进行类设计的好处,优点： 1、与系统的三层结构直接对应 2、可以把过去散布在Client端、数据库端等各处的程序逻辑，按BCE模式，自然地划分好，界面非常清楚 3、将商务逻辑封装在控制中，可以隐蔽其复杂性 4、将实体独立出来，以后可以直接将实体类转换为数据库的表单，包括处理（面向对象的优点：存储的数据与处理数据的功能封装，同时隐蔽了数据库系统的复杂性） 缺点： 增加了系统的复杂性（代价：在系统概要设计中分析）,（2）定义结构和层次 类和对象被标识以后，根据分析的需要，还要进一

56、步进行分解 分析类模型，产生更多的细节 细节使类进一步被分解 细分产生了类的结构和层次,J2ME的用户界面Display类,Display类管理MID的屏幕输出,Displayable一个具体的显示部件,Screen 标准的用户界面,TextBox 文本框,Alert 报警,List 列表框,Form 窗体,Canvas 显示的运行感知,StringItem,Item,ImageItem,textField,DateField,Guage,ChoiceGroup,可以看成是一个应用系统的显示子系统 需求分析要分析到哪层？ 根据系统规模而定 规模越大抽象层次越高,程序员要知道这里：如何使用Dis

57、play类,定义结构层次：对象-关系模型 在已经定义的类之间，进一步标明每个责任者和协作者之间的“连接”关系，即描述类&对象（类和它所属的对象）之间的关系 类&对象间的关系有三种形式，或称为三种结构： 归纳关系 组合关系 关联关系 这些关系，我们在面向对象方法中，已经介绍过 在分析了类&对象之间的关系之后，我们为类&对象模型，建立了联系（关联）,UML的关系,B,A,B,A,C,B,1,0.*,一个类其名为B,实线代表类A和类B的关联,关联对象的数目范围 1 = 唯一一个；0.* = 零或多个,聚集：类B为类A的一部分. 泛化：类C是类B的子类.,关联和连接 对象结构分析或静态模型的精髓，在于

58、找出类之间的准确关系。关联是两个类或多个类之间的一个关系。连接是这一关系的具体体现，就象对象类和对象实例一样。 常规关联 两个类的关联由一实线连接代表，线的两端可以各有一整数，代表一端可取的个数。可以用一整数范围(m.n),如0.*,1.*,0.1等，来代表可取的对象数。,公司,员工,1 雇佣 0.* 工作,老板 0. ,管理 ,工人 0. ,公司与员工的关联关系： 公司可以雇佣多个员工，但一个员工只可以为一个公司工作,自身的关联关系：递归关联 一个老板可以管理多个员工 一个员工可以被多个老板管理,多重关联 N元关联是在N个类之间建立的一种关系，对应的N元连接是N个对象实例间的连接。在UML中，N元关联由一个大的菱形代表，菱形与关联中每一个类用实线连接。 下图是带有多重性标记的三元关联的例子。 二元连接是二元关联的实例化， 也就是连接两个对象实例的具 体连接。 二元关联不属于两端的任一类， 而是两个类共有的关系。多元 关联是所有参与关联的类的共 同关系。 普遍来说，关联的任一端， 可连接任意个数的对象实例。 在uml中，可指定这一个数或 其范围。对象个数范围，乃关 联本身的性质，称为“多重性”。,有序和分类关联 关联有一端的多重大于一，其对应的对象集合可以