面向对象的设计与技术第二章.pptVIP

3.1需求工作流 主要发生在项目生命期的开始、贯穿整个初始和细化阶段 3.2软件需求－元模型 需求、用例和参与者 例子：Supplementary Requirements Specification 3.3需求工程 需求工程用于描述涉及抽取、文档化和维护软件系统需求。 发现需要系统为用户提供什么的集合。 需求工作流的目的是在开始进行OO分析和设计之前，必须揭示系统应该做什么并达成一致，使用系统用户语言来表达，并为系统应该做什么创建非常高级的规格说明。 3.4需求的重要性 有效的需求工程是软件开发项目中关键的成功因素。 研究表明需求工程的失败是软件产品失败的主要原因。 软件工程失败的另一个最重要的原因是缺少用户参与。 同样，如果用户是需求的主要来源，那么这也是需求工程失败的主要原因之一。 3.5需求工作流细节 引入了新工作人员－需求工程师 找出功能性需求 找出非功能性需求 优先排序需求 跟踪用例和需求 3.6定义需求 可以定义需求为 “应该做什么的规格说明”。 需求是系统的基础。原则上需求应该仅仅是陈述系统应该做什么，而不是它应如何做。 这是重要的区别。在理论上如何分离what和how是引人注目的，实际上，一组需求将是what和how的混合物。 基本上有两种类型的需求： 功能性需求——系统应该提供什么功能。 非功能性需求—系统的特定特性或者约束。 3.6.1系统需求规格说明 SRS(System Requirement Specification)说明系统将做什么 SRS是软件构造过程的真正开始。它常常是OO分析和设计的初始输入。 可以用自然语言书写，也可用需求工程工具如 Requisite Pro(Rational Corporation)或者DOORS 对于任何一份SRS的基本提问是： “它对我有什么用？” “它是否帮助我理解系统应该做什么？” 3.6.2形式良好的需求 UML通过用例机制来处理需求，但一般认为用例还不够，我们仍然需要SRS和需求管理工具。 推荐陈述需求用非常简单的格式 3.6.3功能性和非功能性需求 功能性需求是系统应该做什么的陈述—它是系统功能的陈述。 非功能性需求是对系统的约束。 例子：ATM取款机 功能性需求－ATM取款过程。 非功能性需求－采用C++/Oracle。 3.6.4需求抽取 从真实世界中抽取出精确的场面或映射，以捕获软件系统的需求。 根据转换语法的描述，这个映射由剔除、变形和泛化这三种过程所创建。 剔除—信息被过滤。 变形—信息被相关创造和幻想机制所修改。 泛化—创建关于真理和谬误的规则、信念和原理。 Noam Chomsky,《Syntactic Structures》,1975 挑战全称量词 小结 本讲讨论了UP需求工作流,需求工作流的大部分工作发生在UP项目生命期的初始和细化阶段。 许多项目的失败归因于需求工程问题。 需求元模型表示有两种方法捕获需求—功能性需求和非功能性需求、用例和参与者。 扩展标准UP需求工作流，增加需求工程师，找出功能性/非功能性需求，给需求排出优先顺序，在需求和用例之间跟踪。 系统需求规格说明(SRS)包含系统的功能性需求和非功能性需求。可以是：文档和数据库。 映射自然语言包括：剔除，变形，泛化。应该挑战全称量词 4.1用例建模 用例建模是需求工程的一种形式，是抽取和文档化需求的补充方法 相对于“传统”SRS方法 典型用例建模方法： 找出系统边界。 找出参与者。 找出用例(包括说明用例，创建场景) 4.2用例模型 用例建模活动输出用例模型，包括四个部分： 参与者—人们所扮演的角色或者使用系统的事物。 用例—参与者与系统交互的物件。 关系—参与者和用例之间有意义的联系。 系统边界—包围用例的方框，说明正在建模系统的边界。 4.3 UP活动－参与者和用例 找出参与者和用例 找出系统边界 列出项目词汇表者和用例 4.3.1 确定系统边界 构造系统所需做的第一件事情是确定系统的边界，也就是定义什么是系统的组成部分(系统的边界内)以及什么是系统的外部(系统边界外)。 系统边界绘制为方框，标有系统的名称，参与者绘制在边界外部，用例绘制在边界内部。 4.3.2参与者 一些外部实体与系统直接交互时所扮演的角色。包括用户角色或者由外部系统所扮演的角色。 参与者仅是带有自身特殊图标的类的构造型，通常使用stick man代表由人扮演的角色，box代表由其他系统所扮演的角色。 找出参与者 谁或什么使用该系统？ 交互中，它们扮演什么角色？ 谁安装系统？ 谁启动和关闭系统？ 谁维护系统？ 与该系统交互的是其他什么系统？ 谁从该系统获取信息，谁提供信息给系统？ 有什么事情发生在固定时间？ 4.3.3 用例 “系统、子系统或类能够与外部参与者交互所执行的动作序列，包括各