（计算机软件与理论专业论文）面向对象的软件需求工程及其在mis系统的应用.pdf

ab s t r a c t 尸 r e q u ir e m e n t s e n g i n e e r i n g ( r e ) is a b r a n c h o f s o f t w a r e e n g i n e e r i n g , w h o s e a c t i v i t i e s i n v o l v e r e q u i r e m e n t s e l i c it a t i o n , r e q u i r e m e n t s a n a l y s i s , r e q u i r e m e n t s s p e c i f i c a t i o n , r e q u i r e m e n t s v a l i d a t i o n a n d r e q u i r e m e n t s m a n a g e m e n t . u n i l ( u n i f i e d m o d e l i n g l a n g u a g e ) i s a n o b j e c t - o r i e n t e d m o d e l in g l a n g u a g e . t h e t h o u g h t s a n d m e t h o d s i n t h e u ml h a v e t h e d i r e c t l y g u i d e d s i g n i f i c a n c e a n d p r a c t i c a l l y a p p l i e d v a l u e f o r t h e a c t iv i t i e s o f r e q u i r e m e n t s e n g i n e e r i n g , a s w e l l as f o r t h o s e o f s o f t w a r e e n g i n e e r i n g . t h i s p a p e r f i r s t l y e x p o u n d s t h e f u n d a m e n t a l c o n c e p t s a n d m e t h o d s o f s o ft w a r e r e q u i r e m e n t s e n g i n e e r i n g a n d o f t h e u ml . s e c o n d l y , b as e d o n t h e u ml , t h e p a p e r d e s c r i b e s t h e r e s p r a c t i c in g p r o c e s s a n d p a rt o u t c o m e s o f a m a n a g e m e n t i n f o r m a t i o n s y s t e m ( mi s ) , a n d e m p h as i z e s p a r t i c u la r l y o n r e q u i r e m e n t s e l ic i t a t i o n r e q u ir e m e n t s a n a l y s i s a n d r e q u i r e m e n t s s p e c i fi c a t i o n . k e y w o r d s : r e q u i r e m e n t s e l i c i t a t i o n s p e c i f i c a t i o n , u s e c a s e , c l a s s r e q u ir e m e n t s a n a ly s i s , r e q u i r e m e n t s ， o b j e c t j 面向对象的软件需求工程及其在m i s系统的应用 第t 页 第一章前言 本章简要介绍需求工程的由来、地位及其现状。 1 . 1 需求工程的出现 对于计算机软件而言， 软件开发方与软件客户方是贯穿软件整个生命周期 的两个最基本的要素。 无论软件的规划、 开发、 测试， 还是软件的使用、 维护、 废弃， 都需要二者不同程度参与。正是由于二者自 始至终的相互制约、 相互合 作， 才推动着整个计算机软件产业不断地向前发展。其中， 需求分析是二者合 作的基石和关键所在。 在计算机软件发展的初期， 软件规模不大， 软件开发所关注的是代码编写， 需求分析很少受到重视 后来软件开发引入了生命周期的概念， 需求分析成为 其第一阶段。随着软件系统规模的扩大， 需求分析与定义在整个软件开发与维 护过程中越来越重要， 直接关系到软件的成功与否。 川门 逐渐认识到需求分析 活动不再仅限于软件开发的最初阶段， 它贯穿于系统开发的整个生命周期。 8 0 年代中期，形成了软件工程的子领域一一需求工程 ( r e q u i r e m e n t s e n g i n e e r i n g , r e ) . 如果说软件工程概念的形成是解决软件危机的必然结果，那么其子工程， 一需求工程的出现才真正体现出软件产品不同于其它产品的一个特性用 户参与整个产品过程的重要性。 进入9 0 年代以来，需求工程自 然成为计算机软件研究的热点之一。 1 . 2 需求工程的地位 虽然需求工程的重要性不容质疑，然而并非所有软件开发者，都能清楚地 意识到需求工程中的缺陷会给软件项目带来怎样的风险。 一项通过对 8 3 8 0个软件项目的调查发现，导致软件项目 失败的最主要的 两个原因是缺乏用户参与和不完整的需求以 及不完整的规格说明 ( s t a n d i s h 1 9 9 5 ) 。 而 这些正是在需 求工 程领域中 应该做好的工作。 另一项对t r m 公司所做过的软件项目的分析结果表明:所有被检测出 来的 错误中，5 4 % 是在编码和单元测试阶段以后才被发现的:更糟糕的是此类错误 中的绝大部分 ( 占4 5 % )是在需求和设计阶段发生的，而编码阶段的错误只占 9 % ( l e f f i n g w e l l 1 9 9 7 ) . 对g t e , t r w 和 工 b m 三家公司的研究表明， 在需 求阶段检查 和修复一个错 误所需的费用只有编码阶段的 1 / 5 到 1 / 1 0 ， 而在维护阶段做同样的工作所付出 的代价却是编码阶段的2 0倍。这就意味着在需求阶段和维护阶段修复一 个错 误的比 值可高 达1 : 2 0 0 ( w i e g e r s 1 9 9 6 ) 0 面向 对象 的软 件需 求工 程及其 在m i s 系 统的应用 第2 页 由 此可以 看出:需 求工程在整个软件生命周期是非常重要的， 也是非常基 础的。 作好需 求的 分 析 和管 理， 既 可以 减少软 件开 发中的 错误， 还 可以 减少 修 复错误的费用， 从而大大降 低软件开发成本， 缩短软件开发时间。 1 . 3 需求工程的现状 然而我们面 对现实是: 无论在需 求工程理论研究方面， 还是在需求工程实 践过程方面，我国软件行业同国 外的相比，都存在不小的差距。 国外在需求工程理论研究学术活动、专门的刊物和工作小组等方面，都初 具规 模。从1 9 9 3 年起每两年举办一次需求工程国际研讨会仃 s r e ) ，自1 9 9 4 年 起 每两 年举办 一 次 需 求t 程国 际 会议 ( i c r e ) ， 在 1 9 9 6 年s p r i n g e r - v e r l a g 发行了新的刊物( r e q u i r e m e n t s e n g i n e e r i n g ) 。一些关于需求工程的工 作小 组也相继成立， 如欧 洲的r e n o i r ( r e q u i r e m e n t s e n g i n e e r i n g n e t w o r k o f i n t e r n a t i o n a l c o o p e r a t i n g r e s e a r c h g r o u p s ) ，并开始开展t作。 在需求工 程实践过程方面，国 外的软件开 发公司 针对不同 种类、不同规模 的软件开发， 在软件项目 初始阶段， 就对开发者和使用者有相应的、 或长或短 培训，以引起双方对软件工程以 及需求工程理解和重视， 强调双方合作对软件 项目的决定性影响。 在国内， 不仅在需求工程的理论研究方面乏善可存， 而且在具体的实践应 用中困难重重。国内 数以 千计的软件公司，总体水平处于初级阶段，公司规模 小， 人员流动性大， 抗风险能力差。固然有为数不多的大型软件开发公司，实 施了 软件工程化开发和管理， 但是由于对软件开发过程中出现的诸多问题缺乏 理论上的理解和认识， 在惯性的作用下，往往沿用传统的思维方法， 从而使问 题得不到及时的、充分的解决。 我国的软件产业要决 速发展、要形成规模， 应该学习先进的软件工程理论 并付诸于实践。 其中，需求工程正是极易被人们忽视、却又极其关键的一课。 面向 对象 的 软件需求工 程及其在m i s 系 统的 应用 第3 页 第二章需求工程概述 需求工程是指应用己 证实 有效的技术、 方法进行需求分析， 确定客户需求， 帮助分析人员理解问题并定义目 标系统的所有外部特征的一门学科: 它通过合 适的工具和记号系统地描述待开发系统及其行为特征和相关约束， 形成需求文 档;并对用户不断变化的需求演进给予支持。 需求工程可分为系统需求工程 ( 如果是针对由软硬件共同组成的整个系 统)和软件需求工程 ( 如果仅是专门针对纯软件部分) 。 软件需求工程是一门分析并记 录软件需求的学科， 它把系统需求分解成一 些主要的子系统和任务， 把这些子系统或任务分配给软件， 并通过一系列重复 的分析、 设计、比较研究，把这些系统需求转换成软件的需求描述和一些性能 参数。 本文以下如无特别说明，需求工程主要是指软件需求工程。 2 . 1 需求 2 . 1 . 1 需求的 定义 “ 需求” 这个概念并无一个明确的定义，它包含着多个层次:不同层次的 需求从不同角度在不同程度上反映着细节问题。 工 e e e 软件工程标准词汇表 ( 1 9 9 7 )中 “ 需求”定义为: ( 1 )用户解决问 题或达到目 标所需的条 件或能力; ( 2 )系统或系统部件要满足合同、 标准、 规范或其它正式文挡所需 具有 的条件或能力: ( 3 )一种反映上面 ( 1 ) 或 ( 2 ) 所述的条件或能力的文挡说明。 这个定义包括从用户角度 ( 系统的外部行为) ，以及从开发者角度 小一 些 内部特性) 来阐述 “ 需求， 。 此外还有几种定义，对 “ 需求”这个概念进行了解释: 需求是: 从系统外部能发现系统所具有的满足于用户的特点、 功能及属性 等 ( 需求分析专家 a l a n d a v i s 1 9 9 3 ) ; 需求是: 用户所需要的并能触发一个程序或系统开 发工作的说明 ( j o n e s 1 9 9 4 ) : 需求是: 指明必须实现什么的规格说明， 它描述了 系统的行为、 特性或属 性， 是 在 开 发 过 程中 对系 统的 约束( s o m m e r v i l l e a n d s a w y e r 1 9 9 7 ) . 实际上， 真正的 “ 需求” 存在于人们的脑海中， 任何文挡形式的需求仅仅 是一个模型、一种叙述而已。也 正是因为如此，软件开发者往往容易忽视这个 问题，想当然将自己 对 “ 需求” 的理解强加于用户之上;而用户山于不熟悉信 面向对象的软件需求工 程及其在m i s 系 统的反用 第4 页 息技术，可能 提出非常含糊的“ 需求” ; 双方的 差异不可 避免 地产生， 这对 软 件的 开发 有相当 大的负面影响， 甚至最终导致软件开 发的 失败。 因 此需要我们特别注意的 是: 在软件项目的 起始阶段， 开发者与用户在描 述 “ 需求”的名词的理解上务必达成共识， 从而为项目的顺利进行奠定一个良 好的基础。 2 . 1 . 2 需求的层次 软件需求包括三个不同的层次: 业务需求、用户需求、 功能需求 ( 包括非 功能需求) 。 业务需求 ( b u s i n e s s r e q u i r e m e n t ) :反映了 组织机构或客 户对系统、 产 品高层次的目 标要求，它们在项目 视图与范围文挡中予以说明。 用户需求 ( u s e r r e q u i r e m e n t ) :其文挡描述了 用户使用产品 必须要完成 的任务，这在用例 ( u s e c a s e )文挡或脚本 ( s c e n a r i o )说明中予以说明。 功能需求 ( f u n c t i o n a l r e q u i r e m e n t ) :定义了开发人员必须实现的软件 功能， 使得用户能完成他们的 任务， 从而满足了业务需求。 软件需求各组成部分之间的关系如图2 - 1 - 1 所示。 系统需求 图2 一 卜i 软件需求各组成部分之间的关系 业务需求:由管理人员或市场分析人员确定。 所有的用户需求必须与业务 需求一致。 用户需求使需求分析者能从中总结出功能需求，以满足用户对产品 的要求从而完成其任务: 而开发人员则根据功能需求来设计软件以实现必须的 功能 面向 对象的 软件需求工程及其在m i s 系 统的应用第5 页 功能需 求: 充分 描述了 软 件系统 所应具有的 外 部行为， 应在软 件需 求规格 说明( s o f t w a r e r e q u i r e m e n t s p e c i f i c a t i o n , s r s ) 中 加以 说明。 软 件 需 求规格说明 在开发、 测试、 质量保证、 项目 管理以 及相关项目 功能中都起了 重 要的作用。 对一个复杂产品来说， 软件功能需求说明也许只是系统需求的一 个 子集，因为另外一些可能属于软件部件。 非功能需求: 作为 功能需求的补充， 描述了 系统展现给用户的 行为 和执行 的操作等，也应包括在软件需求规格说明中。它包括产品必须遵从的标准、 规 范和合约; 外部界面的具体细节; 性能要求;设计或实现的约束条件及质量属 性。 所谓约束示指开发人员在软件产品设计和构造上的限 制。 质量属性是通过 多种角度对产品的 特点进行描述，从而反映产品功能。 多角度描述产品对用户 和开发人员都极为重要。 需求并未包括设计细节、实现细节、 项目 计划信息或测试信息。需求与这 些没有关系，它关注的是充分说明你究竟想要开发什么。 当 然， 软件项目 也有其它方面的需求， 如开发环境需求或发布产品 及移植 到支撑环境的需求等等。 尽管这些需求对软件成功也至关重要， 但它们并非本 文所要讨论的。 2 . 1 . 3 需求说明的特点 1 .完整性 每一项需求都必须将所要实现的功能描述清楚， 以 使开发人员获得设计和 实现这些功能所需的全部必要信息。 2 正确性 每一项都必须准确地描述其开发的 功能。 需求的 来源是做出 正确判断的依 据， 如用户或高层的系统需求规格说明。 若软件需求与对应的系统需求相抵触， 就是不正确的;只有用户代表刁 能确定用户需求的正确性。 这是一个原则， 也 是一定要有用户积极参与 的原因 3 .可行性 每一项需求都必须是在己 知系统和环境的权能 和限制范围内 可以实施的。 为避免不可行的需求， 最好在获取需求过程中，始终有一位软件工程小组的组 员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术的可行 性。 4 .必要性 每一项需求都应客户真正所需要的和最终系统所需遵从的标准记 录下来。 “ 必要性” 也可以理解为每项需求都是用来编写文挡的 “ 根源” 。要使每项需 求都能回溯至某项客户的输入，如使用实例或别的来源。 面向对象的软件需求工 程及y_ $ 系 统的应用第6 页 5 .划分优先级 给每项需求、 特t; 用实例分配一个给定的优先级，以指明它在特定产 品中所占的分量。 “_ 所有的需求都看作同样重要， 那么项目管理者在开发 或节省预算或调厂。 丧失了 控制的自由度。 6 .无二义 对所有!说明都只有一个明确的统一的 解释。由于自 然语言 极易导致 二义性，厂量把每项需求用简洁明了的用户性语言表达出来。避免二义性 的有效，_ 括对需求文 挡的正规审查、 编写测试用例、 开发原型以及设计特 定的方本。 一j 验证性 士 一下每项需求是否能通过设计测试用例或其它的验证方法，如用演 一.立 测等来确定产品是否确实按需求实现了。 如果需求不可验证，则确定其 h 是否正确就成为主观臆断，而非客观分析了。一份前后矛盾、不可行或有 义性的需求也是不可验证的。 2 . 2 需求工程 2 . 2 . 1 软件工程开发模式 软件工程开发模式大致可分为以下几种模式，如图2 - 2 - 1 所示。 瀑布式模型: 是一种顺序的、 线性的软件开发模式: 也是一种最自 然、 最 古老的模式。 原型开发 模型: 是一种进化式、 增量式的软 件开发模式， 强调用户方参与 软 件开发过程的 重 要 性; 可分为 抛弃 式原型 和增量 式原型 两 种。目 前 使用较为 广泛。 螺旋式模型: 综合了瀑布式模型和原型开发模型的优点， 同时增加了一 个 新的元素风险估计;它是大型系统软件开发的最现实的方法。 此外还有滚动式模型、 逆向丁程模型等开发模式。 面向对象的软件需求工 程及其在m i s 系 统的应用 第7 页 瀑布式模型原型开发模型 c+ t 1 求初始分 且让划 墓子 初始需求 的风险分析 反饮的凡险分析 基于用户 说明的计划 用户 完成系统方向 初始软弓 乍 原型 工程系统 第二次原型 用 户 评 价 口 二程 螺旋模型 1j 2 一 2 一 1软件开发模式 2 . 2 . 2求工程方法 需求工程方法可大致分为4 类: 面向过程的分析方法、 面向数据的分析方 法、面向控制的分析方法、面向对象的分析方法。 从发展演变的角度来看，比较有影响的分析方法有以下几种: 2 . 2 . 2 . 1 p a r n a s 方法 最早的软件开发方法是由d . p a r n a 、 在1 9 7 2 年提出的。 由于当时软件在可 约 巾 ” 性和可靠h1 方面存在着严重问题，因此 a r n a s提出的方法是针对这两个 面向对象的软件需求工程及其在m i s 系 统的 应用 第8 页 问题的。 首先， p a r n a s 提出了 信息隐蔽原则:在概要设计时列出 将来可能发生变化 的因素，并在模块划分时将这些因素放到个别模块的内 部。 这样， 在将来由于 这些因素变化而需修改软件时， 只需修改这些个别的模块， 其它模块不受影响。 信息隐蔽技术不仅提高了 软件的可维护性， 而且也避免了 错误的蔓延， 改善了 软件的可靠性。现在信息隐蔽原则已 成为软件工程学中的一条重要原则。 p a r n a s 提出的第二条原则是在软件设计时应对可能发生的 种种意外故障采 取措施。 软件是很脆弱的， 很可能因为一个微小的错误而引发严重的事故， 所 以必须加强防范。如在分配使用设备前， 应该取设备状态字， 检查设备是否正 常。此外，模块之间也要加强检查，防止错误蔓延。 p a r n a s 对软件开发提出了深刻的见解。 然而， 他没有给出明确的工作流程。 所以这一方法不能独立使用，只能作为其它方法的补充。 2 . 2 . 2 . 2 s a s d 方法 1 9 7 8 年，e . y o u r d o n 和l . l . c o n s t a n t i n e 提出了结构化方法，即s a s d 方法， 也可称为面向 功能的软件开发方法或面向数据流的软 件开发方法。 1 9 7 9 年t o m d e m a r c 。 对此方法作了 进一步的 完善。 y o u r d o n 方法是8 0 年代使用最广泛的软件开发方法。 它首先用结构化分析 ( s a ) 对软件进行需求分析，然后用结构化设计 ( s d ) 方法进行总体设计， 最 后是结构化编程 ( s p ) 。这一方法不仅开发步骤明确， s a , s d , s p相辅相成， 一气呵成，而且给出了两类典型的软件结构 ( 变换型和事务型) ，便于参照， 使软件开发的成功率大大提高，从而深受软件开发人员的青睐。 2 . 2 . 2 . 3 面向数据结构的软件开发方法 j a c k s o n 方法 1 9 7 5 年， 6 1 . a . j a c k s o n 提出了 一类至 今仍广泛使用的 软 件开发 方 法 这 一方法从目 标系统的输入、 输出数据结构入手，导出程序框架结构，再 补充其 它细节，就可得到完整的程序结构图。 这一方法对输入、 输出 数据结构明确的 中小型系统特别有效， 如商业应用中的文件表格处理。该方法也可与其它方法 结合， 用于模块的详细设计。 j a c k s o n 方法有时也称为面向 数据结构的软件设 计方法。 w a r n i e r 方法 1 9 7 9 年，j . d . w a r n i e r 提出的软件开发方法与j a c k s o n 方法类似。 差别有三点:一是它们使用的图形工具不同，分别使用 w a r n i e r图和 j a c k s o n图;另一个差别是使用的伪码不同:最主要的差别是在构造程序框架 面向对象的软件需求工程及其在m i s 系 统的应用 第9 7, w a r n i e r 方法仅考虑 输入数据结构，而j a c k s o n 方法不 仅考虑输入数据结 而且还考虑输出数据结构。 时构 2 . 2 . 2 . 4 问题分析法 p a m 问 题分析 法。 p a m ( p r o b l e m a n a l y s i s m e t h o d ) 是8 0 年代末由日 立公司 提出的一种软件开发方法。 p a s 】 方法希望能兼顾y o u r d o n 方法、 j a c k s o n 方法和自 底向上的软件开发方 法的优点， 而避免它们的缺陷。 它的基本思想是: 考虑到输入、 输出数据结构， 指导 系统的分解， 在系统分析指导下逐步综合。 这一 方法的具体步骤是:从输 入、 输出数据结构导出基本处理框;分析这些处理框之间的先后关系; 按先后 关系逐步综合处理框， 直到画出整个系统的p a d 图。 从上述步 骤中 可以 看出， 这一方法本质上是综合的自 底向上的方法， 但在逐步综合之前已 进行了有目 的 的分解，这个目 的就是充分考虑系统的输入、输出 数据结构。 p a m方法的另一个优点是使用 p a d图。这是一种二维树形结构图，是到目 前为止 最好的 详细设计表示方法之一， 远远优于n s 图 和p d l 语言。 这一方法在日 本较为流行，软件开发的成功率也很高。由于在输入、输出 数据结构与整个系统之间同样存在着鸿沟，这一方法仍只适用于中小型问题。 2 . 2 . 2 . 5 血问对象的软件开发方法 面向对象技术是软件技术的一次革命， 在软件开发史上具有里程碑的意义。 其中，影响较大并在实践中得到认可的面向对象的软件开发方法， 先后有 o m t 方法、u m l 方法等。 0 1 i p ( o b j e c t m o d e l i n g t e c h n i q u e )方法 随着o o p( 面向 对象编程) 向o o d( 面向对象设计) 和o o a( 面向对象分析) 的 发 展 最终 形成面向 对 象的软件开 发方法o m 丁 ( o b j e c t m o d e l i n g t e c h n i q u e ) . 这是 利， 自 底向上和自 顶向下相结合的方法，而且它以 对象建模为基础，从而 不仅考虑了 输入、 输出 数据结构，实际上也包含了 所有对象的数据结构。 所以 o m t 彻底实现了p a m 没有完全实现的目 标。不仅如此， 0 0 技术在需求分析、 可 维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破， 彻底地解决了在这些方面存在的严重问题。 u m l ( u n i f i e d m o d e l i n g l a n g u a g e ) 方法 在第三章专门介绍。 面向对象的软件开发方法的主要特点如下: 1 . 自 底向上 自 勺 归纳 面向对象的软件开发方法的第一步是从问题的陈述入手，构造模型。从真 面向 对象的 软件需求工 程及其 在m i s 系 统的 应用第1 0 页 实系统导出 类的 体系， 即 对象 模型 包括类的 属性， 与 子类、 父类的继 承关系， 以 及 类之间的 关联。 类是 具有相 似属 性和 行为的 一 组具 体实 例 ( 客观对 象) 的 抽象， 父类是若干子类的归纳。因此这是一种自 底向上的归纳过程。 在自 底向 上的归纳过程中， 为使子类能更合理地继承父类的属性和行为， 可能需要自 顶 向 下的修改， 从而使整个类体系更加合理。山于这种类体系的构造是从具体到 抽象，再从抽象到具体， 符合人类的思维规律，因此能更决、更方便地完成任 务。 这与自 顶向下的y o u r d o n 方法构成鲜明的对照。 在y o u r d o n 方法中构造系 统模型是最困难的一步，因为自 顶向 下的“ 顶” 是一个空中楼阁，缺乏坚实的 基础， 而且功能分解有相当大的任意性， 因此需要开发人员有丰富的软件开发 经验。 而在面向 对象的软 件开发方法中， 这一工作可由 一 般开发人员 较快地完 成 2 . 自 顶向下的分解 与y o u r d o n 方法按功能分解不同， 在模型中通常按服务( o m t ) 或用例( l m l ) 来分解。 服务是具有共同目 标的相关功能的集合，如工 / 0 处理、图形处理等; 用例是执行者与系统的 一次典型的交互。 这一步的分解通常很明 确， 而这些子 系 统的进一步分解因有较具体的系统模型为依据， 也相对容易。 所以 面向 对象 的软件开发方法也具有自 顶向下方法的 优点，即能有效地控制模块的复杂性， 同时避免了y o u r d o n 方法中功能分解的困 难和不确定性。 3 .面向对象的软件开发方法的基础是对象模型 每个对象类由 数据结构 ( 属性) 和操作 ( 行为) 组成，有关的所有数据结 构 ( 包括输入、输出数据结构) 都成了软件开发的依据。因此j a c k s o n 方法和 p a n 中输入、 输出数据结构与整个系统之间的鸿沟， 在面向对象的软件开发方法 中不再存在。面向 对象的软件开发方法不仅具有j a c k s o n 方法和p a n 的优点， 而且可以 应用于大型系统。 更重要的是， 在j a c k s o n 方法和p a wn 方法中，当它 们的出 发点 输入、 输出 数据结构 ( 即系统的 边界) 发生变化时， 整个软 件 必须推倒重来。 但在面向对象的软件开发方法中系统边界的改变只是增加或减 少一些对象而己， 整个系统改动极小。 生需求分析彻底 需求分析不彻底是软件失败的主要原因之一。即使在日 前，这一危险依然 存在。 传统的软件开发方法不允许在开发过程中 用户的需求发生变化， 从而导 致种种问题。正是由于这一原因， 人们提出了原型化方法，推出探索原型、 实 验原型和进化原型， 积极鼓励用户改进需求。 在每次改 进需求后又形成新的进 化原型供用户试用， 直到用户基本满意， 大大提高了软件的成功率。 但是它要 求软件开发人员能迅速生成这些原型，这就要求有自 动生成代码的工具的支 持。 面向对象的 软件需求工程及其在m i s 系 统的应用 第11贾 面向 对象的 软 件开发 方 法彻底解决了 这一问 题。因 为 需求分析 过程已 与 系 统 模型的 形成 过 程一 致， 开 发人员与用户的讨论是从 用 户熟悉的 具 体实 例 ( 实 体) 开始的。 开发人员必须搞清现实系统才能导出系统 模型， 这就使用户与开 发人员之间有了 共同的语言 ，避免了传统需求分析中可能产生的种种问题。 5 . 可维护性大大改善 在面向 对象的软件开发方法之前的开发方法都是基于功能分解的。尽管软 件工程学在可维护方面作出了 极大的努力，使软件的可维护性有较大的改进。 但从本质上讲， 基于功能分解的软件是不易维护的。因为功能一旦有变化都会 使开发的软件系统产生较大的变化， 甚至推倒重来。 更严重的是， 在这种软件 系统中，修改是困难的。由于种种原因，即使是微小的修改也可能引入新的错 误。 所以 传统开发方法很可能会引起软件成本增长失控、 软件质量得不到保证 等一系列严重问题。 正是面向对象的软件开发方法才使软件的可维护性有了 质 的改善。 面向对象的软件开发方法的纂础是目 标系统的对象模型，而不是功能的分 解。 功能是对象的使用， 它依赖于应用的细节，并在开发过程中不断变化。由 于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳 定，从而使建立在对象结构上的软件系统也更为稳定。 更重要的是，面向 对象的软件开发方法彻底解决了软件的可维护性。在00 语台 中， 子类不仅可以继承父类的属性和行为， 而且也可以重载父类的某个行 为 ( 虚函数) 。利用这一特点，我们可以方便地进行功能修改:引入某类的一 个子类， 对要修改的一些行为 ( 即虚函数或虚方法) 进行重载， 也就是对它们 重新定义。由于不再在原来的程序模块中引入修改， 所以彻底解决了 软件的可 修改性， 从而也彻底解决了软件的可维护性。 00技术还提高了 软件的可靠性和 健壮性。 2 . 2 . 2 . 6 可视化开发方法 可视化开发是9 0 年代软件界最大的两个热点之一。 随着图形用户界面的兴 起， 用户界面在软件系统中 所占 的比 例也 越来越大， 有的甚至高达6 0 了 o v a 产生这一问题的原因是图 形界面元素的生成很不方便。 为此w i n d o w s 提供了应 用 程序设计 接口a p i ( a p p l i c a t i o n p r o g r a m m i n g i n t e r f a c e ) ， 它包含了6 0 0 多个函数， 极大地方便了图形用户界面的开发。但是在这批函数中，大量的函 数参数和使用数量更多的有关常量， 使基于w i n d o w s a p i 的开发变得相当困难。 为 此b o r l a n d c + + 推出了o b j e c t w i n d o w s 编程。 它将a p i 的 各 部分 用对象 类 进行封装， 提供了大量预定义的类， 并为这些定义了 许多成员函数。 利用子类 对父类的继承性，以及实例对类的 1 数的引用，应用程序的7 干 发可以省却少 ( 量 .，. 面向对象的软件需求工 程及其在m i s 系 统的 应用第1 2 页 类的定义，省却大量成员函数的定义或只需作少量修改以定义子类。o b j e c t w i n d o w s 还提供了 许多 标准的缺省处理， 大大 减少了 应用程序开发的工作量。 但要掌握它们， 对非专业人员来说仍是一个沉重的负担。 为此人们利用w i n d o w s a p i 或b o r l a n d c + + 的o b j e c t w i n d o w s 开 发了 一 批可视开 发i具。 可视化开发就是在可视开发工具提供的图形用户界面上，通过操作界面元 素， 诸如菜单、 按钮、 对话框、 编辑框、 单选框、复选框、列表框和滚动条等， 由可视开发工具自 动生成应用软件。 这类应用软件的工作方式是事件驱动。对每一事件，由系统产生相应的消 a， 再传递给相应的消息响应函数。 这些消息响应函数是由可视开发工具在生 成软件时自 动装入的。 2 . 2 . 3 需求工程阶段 需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最 终在验证的基础上冻结需求。 8 0年代， h e r b k r a s n e r定义了需求工程的五阶 段生命周期:需求定义和分析:需求决策; 形成需求规格; 需求实 现与验证; 需求演进管理。近来， m a t t h i a s j a r k e 和k l a u s p o h l 提出了三阶段周期的说 法:获取、表示和验证。 综合了几种观点， 把整个需求工程研究领域划分为需求开发和需求管理两 大部分更为合适，如图2 - 2 - 2 所示。 其中，需求开发部分是整个需求工程的中 心。需求开发可 进一步分为: 需 求获取( e l i c i t a t i o n ) 、 需求分析( a n a l y s i s ) 、 编写规格说明( s p e c i f i c a t i o n ) 和验证 ( v e r i f i c a t i o n )四个阶段。各阶段的主要任务是: ( 1 ) 需求获取:通过与用户的交流，对现有系统的观察及对任务进行分析， 从而开发、捕获和修订用户的需求: 需求开发 需 求 分 析 编 写 。 格 说 明 验 证 图2 - 2 - 2需求工程的层次分解 ( 2 ) 需求分析:为最终用户所看到的系统建立一个概念模型， 作为对需求 的抽象描述，并尽可能多的捕获现实世界的语义: 面向对象的软件需求工 程及其在m i s 系 统的 应用第1 3 页 ( 3 ) 编写规格说明:生成需求模型构件的精确的形式化的描述， 作为用户 和开发者之间的一个协约: 规格是一个预期的或己 存在的计算机系统的表示。 它可以作为开发者和用 户之间协议的基础， 来产生预期的系统。 规格定义系统所有必须具备的特性， 同时留下很多特性不做限制。 通常， 我们要求规格比组成特定系统的实际的软 件和硬件更简洁、更全面、更易于修改。 需求1程的主要结果是软件需求规格 ( s o f t w a r e r e q u i r e m e n t s p e c i f i c a t i o n , s r s ) , s r s是 对外部 行为 和系统 环境 ( 软件、 硬件、 通信 端 口 和人) 接口的简洁完整的描述性文档。 项目 管理者用它来对项目 进行计划和 管理， 在许多情况下， 它也被作为是用户的使用手册或帮助用户理解系统的文 档。 它广泛地适用于对各类应用领域中的客户问题进行理解与描述， 实现用户、 分析员和设计人员之间的通信， 为软件设计提供基础， 并支持系统的需求验证 和演进。 ( 4 ) 需求验证:以 需求规格说明为输入， 通过符号执行、模拟或快速原型 等途径，分析需求规格的正确性和可行性; 需求管理是一种与需求开发过程并行的需求工程活动: 它支持系统的需求 演进， 如需求变化和可跟踪性等问题。 需求管理的主要活动可分为:需求变更控制、 需求版本控制、 需求跟踪以 及需求状态跟踪。 需求开发和需求管理之间的关系如图2 - 2 - 3 所示: 客户需求 _ 一 一 一 基 线 项目环境 变更 图2 一 2 一 3需求开发和需求管理之间的界线 2 . 3需求工程中人的因素 最初的软件开发过程中， 软件开发者是整个活动的中心; 然而， 7 卜 发 一 个 面向对象的软件需求工程及其在m i s系统的应用第1 4 页 具 有一定 规模和复 杂性的 软件系统和编写一 个 简单的 程 序大 不一 样。 大型的、 复 杂的 软 件系统的 开发是一项工程， 必 须经 过分 析、 设计、 实 现、 测试、 维护 等一系列的 软件生命周期阶段。 编程仍然是重要的， 但更具有决定意义的是系 统建模。要建立一个良 好的系统模型不仅仅取决于软件开发者自 身的努力程 度. 而且取决于用户方的直接参与程度; 双方良 好的交流、 理解、 合作是软 件 系统开发成功的首要的前提条件。 因此， 有必要的软件开发双方的人的因素、 所扮演的角色进行界定， 以明 确双方的义务和责任。 这与不同层次的需求的获取、 分析、 验证都有直接的关 系。 2 . 3 . 1软件开发方 软件开发方可以分为: 项目负责人:负责整个软硬件系统的初始规划和管理; 系统分析和设计人员:负责整个软硬件系统的整体分析和设计; 软件项目 负责人:负责软件系统的规划，控制和管理整个软件开发过程; 软件需求开发和管理人员:负责需求的获取、分析建模、编写规格说明， 实施需求的管理; 软件编程人员:软件代码的具体编写人员: 软件测试人员:测试软件是否满足用户需求、功能需求以 及非功能需求; 软件质量保证人员:监督软件的稳定性、安全性以及易用性等等; 维护人员:在产品交付后对软硬件系统进行维护。 在一般情况下， 软件项目负责人、 软件编程人员、 软件测试人员应该由不 同的人员分别担任。 2 . 3 . 2软件客户方 软件客户方可以分为: 软件投资者: 投资软件开发的风险承担者， 是业务需求的来源者之一:当 然，软件投资者也有可能就是软件开发者自己: 客户方高层管理人员: 购买软件但不一定直接使用软件的高层人员， 是业 务需求的来源者之一; 软件的直接使用者( 用户) : 通常意义下的 客户， 是业务需求、 用户需求、 功能需求以及非功能需求的来源;是需求的最终的决策者。 面向对象的软件需求工程及其在m i s 系统的应用第1 5 页 第三章 统一建模语言u ml 统一建 模语言u m l ( u n i f ie d m o d e l in g l a n g u a g e ) 是一 种通 用的 可 视化的 建 模语一言，用于对软件进行描述、可视化处理，构造和建立软件系统的文挡。 u ml适用于各种软件开发、软件生命周期的各个阶段、各种应用领域以 及各种开发工具， 是一种总结了以 往建模技术的经验并吸收了当 今优秀成果的 标准的建模方法。 u ml并没有定义一种标准的开发过程，但它适用于迭代式的开发过程。 3 . 1 u ml的历史、 基本内容及特点 3 . 1 . 1 u ml 的历史 2 0 0 1计划的重要修订 2 0 0 0 1 9 9 9 1 9 9 8 1 9 9 7 . 9 最后提交给o ia g 1 9 9 7 . 1 最初提交给o m g 计划的较小修订 1 9 9 6统一 切礼 0 . 9 合作伙伴意见 1 9 9 5 u ni f i e d xet h od 0 . 8 b o o c h 9 3o m t - 2 其它方法b o o c h 9o m t -1 o o s e 图 3 - 卜1 m e 的 形成、 发 展 面向 对象的 分 析与设 计 ( o o a um g,i r4 r ikr-4 f-xw t tl. f em艘婴 0 f采冷d釜叨3 , 契币尊百i f 吻 a u v 4 k f g 6 荟 t 1 1李草 - wk n t n y y- dlh k 叨 -f y 4 ) -9 _vm 业: k 中困习到沂晕 军 幸 叨图荣4阵鲁图采瑜 箕 砂 。 材李最 林叨罗瑜期不4f , *wr v 冷叨翼卫草wwlx wk 洪ww 擎4 i 国唯 y j n i 圈朵 琳黔母 蜜丫互不叨间育翔罕侨时而彰采帷叨璐生洪群 wr l( 4n k -= % i l w m- 书叨璐岁卫黔壬留田粤 i k 6 w间了粤片每全笙 毕斟釜车冯甲7 。 攀幼形j和一者纷当攀职匕国奏翔即图 晰留粤币形4 k 弯4壬甲 i w派 寺一uw4wplx 小一 “ 釜叨到沂晋业型 阶沂落翔寺孚明釜咨晋图落4壬 h 草回业ou p 0 冲卿r回助今pc 国釜乌目 b 士1 l 6 沂叨b fl ; 9 晋图畜-f x 0 w 卒草晋碍澎m粤不今琳叨璐邃毋 蜜半军喂性一鲁 叨 平黔图 荣 ( e t i n吐科瞥叨 荣) 吩靳碍甲 切 荣黔尽毋 ft -7 号奎 m4 鞠丫n 崔准叨fe.i了荣害笙 釜叨+? k v尘 0 4 # -w 傅 4 h wd t c .11 im荣 0 .7 9 1 0.畜挑 、 日釜界尽 圈军醒鲁釜二妻 导升堆叨架软母甲影好 职收? ) 蜜平形习粤a留w 图阶留晋; * -冀 : xy x ( -y m 健 6 汗) 图荣v陋生甲r 鱼母y 蔓草w i w f l 旱 歇彭爵一璐 0 g 4 溉叨志彭匹 -i i a n丁丫影翠 而彰叨游留 习鲁切7f笙男幸x3合赫l- ( 图翁寥 “ 积卿止淤都彭影璐当军影影幸xd 劣 合摄班 图翁班幽彰甘工军扛卒早尊妊军 彩些擎叨合纷- t i n丫军 : 影害笙l wr n 。 丫军省斗叨志彰匹健母 革卫叹 1 闪 门杨即 。 吻落叨军票男影军又笙熟瞥叨督塑丫图1 剖郭 鞋-都方t 丫塾晕架导尊妊彰 的瞬科万军叨宙寥 鞋- 亩卿止淤箭丁丫影吐影塾晕攀 匹.e 男叨 i n in t) rp彭y 0 丫犁而 # 匹她黔叨 i w n壬香平黔 丫戳1 人几 。 书咪令望彩害罄v m 叱丫影叮勺 11 黔尽丫澎叨,m n .旱 _影彭澎杜一军朴 量 叼叨 l m z i # 0 瞥照嚼卑叨￥目草甘 回军省尊叨半葬尊任朴准叨彩军落体回旦止笙补 l ml r n 旱 _影彭截一诉叨半 耳李拯回 卫壬香军纷i * i mf l 嶙姿j w o 日l i gi i 由l 6 6 i。 款卿不工