发信人: leeyg()
整理人: leeyg(2001-06-05 22:50:06), 站内信件
|
: 做分析的时候，不仅仅是需求分析（包括总体设计、详细设计），
: 都是一个逐步求精的过程。可能大家会认为这仅仅是瀑布模式的系统
:分析的结论，对于面向对象的分析不一定是这样。但是，想想即使是面
:向对象的分析，最后还是要将问题分解，然后逐个解决。因此这种层
:状的分析结果是必然的。
我觉得你的需求分析思路是属“功能分解法”的思路。功能分解法
的特点就是开头容易后来难，客户提供了需求，分析员要做2步工作：
首先要将需求映射为功能，再将这些功能映射为计算机术语的系统。
而这个映射是最艰难的，其实这个映射就是你所想要搞的工具。我以
前很为这个映射头痛。
面向对象的分析并不需要逐步求精，从一定意义上来说，也不需
要将问题分解。面向对象的分析这样走：罗列（遍历），选取（补充）。
尽可能地罗列所有的属性，一个不漏地遍历各个服务，去除与本系统
无关的属性与方法，补充遗漏的属性与方法。这个过程贯穿从分析到设
计的整个过程，从分析员到编码员。现今的分析方法中，能够做到这一
点的只有面向对象的分析方法。
功能分析法对需求的适应性在各种分析方法中是最差的，因为客
户的需求是经常变动的。Coad和Yourdon对各种系统成分的易变性和稳
定性作过比较其结论是：当需求发生变化时，系统中最容易变化的部
分是功能部分，其次是与外部系统或设备的接口部分，第三是描述问
题域事物的数据，最稳定的部分是对象。
当然，面向对象的分析也有自己的缺点，大家共同交流交流。
--
※ 修改:．leeyg 于 Oct 23 13:54:48 修改本文．[FROM: 202.104.35.40]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.104.35.40]
发信人: hyenachenyao (BlueHyena), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易虚拟社区 (Sat Oct 23 16:18:01 1999), 站内信件
【 在 leeyg (雷云沟) 的大作中提到: 】
: : 做分析的时候，不仅仅是需求分析（包括总体设计、详细设计），
: : 都是一个逐步求精的过程。可能大家会认为这仅仅是瀑布模式的系统
: :分析的结论，对于面向对象的分析不一定是这样。但是，想想即使是面
: :向对象的分析，最后还是要将问题分解，然后逐个解决。因此这种层
: .......
说的好!!!
我已经做了3年的MIS开发,被这种功能分析搞得头都大了:用户的需求一天一变.
面向对象分析,设计方法就是为了解决这种软件开发工程中的问题而提出来的.
最明显的特性就是:继承性,封装性.
再有,就是随着网络技术的发展,资源的重复利用问题逐渐突出,因此,面向对象技
术
应用更为普遍.
当然,任何一种方法论都有其优缺点,主要看他解决的问题域是什么.
正是由于网络技术的发展,面向对象技术和分布是技术结合而成,出现了现在非常
流行的构件技术.
--
※ 修改:．hyenachenyao 于 Oct 23 16:21:14 修改本文．[FROM: 210.72.251.71]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 210.72.251.71]
发信人: edison (edison), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易 BBS (Sat Oct 23 22:39:05 1999), 转信
看我的观点：
首先我的需求分析思路不是功能分解的思路。需求绝对不能看成
是功能。功能可以说是需求的一部分，但是绝对不是需求。我们可以
这么说：为了满足需求A，需要功能B。但是我们同时还可以这样继续
说：为了实现功能B，我们需要对象C、函数D、方法E.... 等等，这也
是需求。
再说，需求经常在变，没错！我们要做的就是尽量让需求不变。
但是，为什么我们刚开始的时候的需求到最后总是不停的变呢。
我觉得那是因为我们没有找到最根本、最本质的需求。因此，寻找
一个软件最根本、最本质的需求（往往这也不是用户提出的需求，用
户提不出这种需求）成为至关重要。谁找准了这个谁就占了上风。
往往我们在做软件的时候其实分析员们对软件的目标都有个大概
的轮廓但是却很难描述清楚。因此，只能归结出一个一个的需求，但
是往往这些需求又归结的不准，所以才出现需求在不断的变化。当然，
没有任何一个人可以做到一次分析成功。所以对这个需求的变化过程
的管理非常重要，也就是我说的需要支持版本控制。
你说面向对象的分析不用理会需求。我想这是绝对错误的。做软件
都不知道要做什么那怎么可能做的出来？即使做出来也不知道做的是什
么！你说：“面向对象的分析这样走：罗列（遍历），选取（补充）。
尽可能地罗列所有的属性，一个不漏地遍历各个服务，去除与本系统
无关的属性与方法，补充遗漏的属性与方法。”那请问你去除与本系
无关的属性与方法，补充遗漏的属性与方法的原则是什么。是需求！
对于那些符合我们需求的对象我们保留下来，对于实现我们需求有用
的属性、方法，我们留下来，没有的我们补充进来。当然，你说的这
个肯定是面向对象的分析方法，但是我并不赞成这种做法。我认为面
向对象的方法的精华并不在于不需要逐步求精，而在于面向对象的方
法将 Code 与我们的真实世界很好的联系到一起，一个 Object 就是
我们世界里的一个对象。世界中的对象如何相互作用，Object 之间的
方法或消息就如何作用。它使得我们的程序与现实世界之间的隔阂大
大减少。但是如果在面向对象分析的时候采用罗列（编历）、选取（
补充）的方法绝对不是明智之举。倒不如我们开始就从需求开始，为
了满足一个需求需要那些对象、需要对象的什么属性、什么行为。何
必等到将所有对象、所有属性、所有行为都列出来才考虑需求。其实
我想大家在分析的时候下意识已经这么做了。我在这里强调的原因是
在《面向对象的系统分析》（邵维忠、杨芙清著）中就是leeyg 兄所
说。因此，为了表达我对它的异议，在此强调了一边。
我们再往细里说，例如为了完成一个函数（显然这个函数存在的
意义是为了实现一个软件需求）。在编函数之前我们也要明确这个函
数的需求，知道这个函数要实现什么我们才能编得出代码。这就是我
说的需求的细分。从大的角度来说，用户提出的是软件需求。从细节
上来说，一个函数的功能也是一个需求。一个更小的需求，一个为了
实现一个大需求而存在的小需求。需求是一环扣一环，为了满足需求
A，引出了需求 B，为了满足需求 B 又引出了需求 C。这是一个非常
容易理解的概念。
回到我首先说的问题上。需求一定要找准，谁找准了需求谁就占
了上风。但是往往我们首先看到的需求不是最顶层的需求（我们不可
能找到最顶层的需求，因为永远所有软件的最终需求是做出来后可以
满足任何需求的软件，显然这是不可能的事，我们只能是最大限度的
逼近这个目标，但是永远达不到！），是中间层的需求。而我们对需
求分析后又会产生更多的小需求或引发一些其他的需求。因此，对需
求的归纳总结非常重要。所以我觉得有个软件的辅助（版本控制）可
以大大的提高我们对这些需求的总结，从而尽快的找到本质需求。
也许在这篇帖子里，需求一词可能都有一点不太适合，因为需求
的意思往往大家的理解是用户提出的需求。但是我又想不出什么其他
更好的词汇，可能"目的"一词也行!
leeyg 兄:
你的数据库系统面向对象一文, 我看了, 写的非常好。不过你是 delphi
开发员，我是 PB 开发员。
【 在 leeyg (雷云沟) 的大作中提到: 】
: : 做分析的时候，不仅仅是需求分析（包括总体设计、详细设计），
: : 都是一个逐步求精的过程。可能大家会认为这仅仅是瀑布模式的系统
: :分析的结论，对于面向对象的分析不一定是这样。但是，想想即使是面
: :向对象的分析，最后还是要将问题分解，然后逐个解决。因此这种层
: :状的分析结果是必然的。
:
: 我觉得你的需求分析思路是属“功能分解法”的思路。功能分解法
: 的特点就是开头容易后来难，客户提供了需求，分析员要做2步工作：
: 首先要将需求映射为功能，再将这些功能映射为计算机术语的系统。
: 而这个映射是最艰难的，其实这个映射就是你所想要搞的工具。我以
: 前很为这个映射头痛。
:
: 面向对象的分析并不需要逐步求精，从一定意义上来说，也不需
: 要将问题分解。面向对象的分析这样走：罗列（遍历），选取（补充）。
: 尽可能地罗列所有的属性，一个不漏地遍历各个服务，去除与本系统
: 无关的属性与方法，补充遗漏的属性与方法。这个过程贯穿从分析到设
: 计的整个过程，从分析员到编码员。现今的分析方法中，能够做到这一
: 点的只有面向对象的分析方法。
:
: 功能分析法对需求的适应性在各种分析方法中是最差的，因为客
: 户的需求是经常变动的。Coad和Yourdon对各种系统成分的易变性和稳
: 定性作过比较其结论是：当需求发生变化时，系统中最容易变化的部
: 分是功能部分，其次是与外部系统或设备的接口部分，第三是描述问
: 题域事物的数据，最稳定的部分是对象。
:
:
: 当然，面向对象的分析也有自己的缺点，大家共同交流交流。
:
:
:
--
谢谢没有在 "将本文章寄一份给原作者" 处打勾, 再次感谢!
※ 修改:．edison 于 Oct 23 22:41:42 修改本文．[FROM: bbs.szptt.net.cn]
※ 来源:．网易 BBS bbs.netease.com．[FROM: bbs.szptt.net.cn]
发信人: leeyg (雷云沟), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易虚拟社区 (Sun Oct 24 10:55:26 1999), 站内信件
【 在 edison (edison) 的大作中提到: 】
: 看我的观点：
: 首先我的需求分析思路不是功能分解的思路。需求绝对不能看成
: 是功能。功能可以说是需求的一部分，但是绝对不是需求。我们可以
: 这么说：为了满足需求A，需要功能B。但是我们同时还可以这样继续
: .......
是这样，无论哪一种分析方法，都一定是要理会需求的，这一点不
容怀疑。我只是认为：面向对象的分析方法无需逐步求精，在一定意义
上也无需将功能分解。
功能分析法将需求通过功能去体现，面向对象法通过系统责任去体
现。
至于需求的变化，你所说的在分析时没有抓住需求的本质导致需求
与原来不同，这一是分析员与用户沟通不够，另一方面也是因为用户并
不能准确地表达他们究竟要什么。
上面的这些，优秀的系统分析员可以解决，但是，下面的因素，却
不是系统分析员可以解决的：
1、社会的竞争因素。我是搞银行的，我有过多次的经历，分析的时候
本没有这种因素（政策不准做），但随着外资银行的引进，银行竞争的加剧
原来的系统在开发到未段时已经引入了新的需求。
2、经费问题：给的钱多了，他要求你做大，经济拮据了，他要求你做小
所以，需求很重要，但我觉得无论哪一个分析员，都不可能完全做到
将系统的需求深入理解到可以适应这种非分析员所能预测的需求的变化。
不知对否
--
※ 修改:．leeyg 于 Oct 24 15:15:20 修改本文．[FROM: 202.103.135.107]
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.104.35.40]
发信人: kenmlee (ken), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易虚拟社区 (Mon Oct 25 17:23:24 1999), 站内信件
edison和leeyg两位的精彩发言有让人茅塞顿开的感觉，
谢谢两位
在此，发表一下我的看法：
首先，对leeyg兄的观点“面向对象的分析方法无需逐步求精”表示异议，
面向对象的系统分析第一步应该是确定系统的对象，但不可能把一个现实
中的系统的所有元素都抽象为计算机中的对象的，因此必须对系统进行分析
整理出必须的对象来，然后在这些对象基础上完成系统的任务，但我想没有
人敢说他对系统的面向对象分析是完美的无缺点的，那么他的分析就一定有
可改进之处，于是他改进了一次又一次，面向对象的逐步求精我想大家都看
到了吧。可能面向对象在功能分析上是可以略去很多事，但其本身却离不开
循序渐进逐步求精这个过程。
其次，对edison的“版本控制”观点我同意leeyg的说法，我们开发人员尚且
控制不了的事情又怎么能让“版本控制”系统做到呢？另外，目前好象
版本控制系统大多用于开发小组成员间的开发过程控制，需求的版本控制该由
谁来使用呢，开发人员还是客户
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.166.212]
发信人: ebus (Franky), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易虚拟社区 (Tue Oct 26 01:14:29 1999), 站内信件
谢谢各位。
大家在这里的讨论就是“逐步求精”的过程。
我认为，面向对象分析法也是要逐步求精的。因为，首先，分析员罗列对象的时
候并不关心属性、服务什么的。
其次，为重用而进行的先一般后特殊的类设计也可算是求精过程。
当然，我不赞成以功能分解为中心进行系统分析的（一般说来），原因就是功能
会变动。
面向对象分析和设计则从问题域内的对象的本质出发，构建了相互关联的对象系
统，并用这个系统实现实际需要的功能。当实际功能发生变化时，通过继承等手
段新生类和对象来实现新功能。
但是，面向对象分析和设计法也要对付功能需求，因为软件毕竟是要实现一定功
能的。不过次序和观点不同而已。
【 在 kenmlee (ken) 的大作中提到: 】
: edison和leeyg两位的精彩发言有让人茅塞顿开的感觉，
: 谢谢两位
:
: 在此，发表一下我的看法：
: .......
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.98.130.120]
发信人: leeyg (), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易虚拟社区 (Tue Oct 26 19:19:35 1999), 站内信件
看来，不同意面向对象的分析不需要逐步求精的同志还不少。
也许是我们对逐步求精的概念理解不同。先让我将在几年的实践
中所理解的逐步求精陈述一下：
我觉得：逐步求精是先全局后局部、先整体后细节、先抽象后具体
的自顶向下的设计方法。它从最能直接反映问题的体系结构的概念出发，
逐步向计算机机器语言精细化、具体化，最终设计出可以在机器上执行
的程序。
通常我们所指的逐步求精法，是指应用于软件开发期的需求分析、
概要设计阶段所用的分析方法。逐步求精法在遵循严格瀑布模型的自顶
向下设计中应用广泛。
之所以说面向对象的分析不需要逐步求精，首先面向对象并不是自
顶向下的设计方法。严格来说，面向对象并不是一个自底向上的方法，
因为面向对象从分析到实现是连贯且统一的，它用的是喷泉模型，没有
严格的上层下层。
其次，两者的思路不同。面向对象面首先接触是的现实生活中具体
的对象。逐步求精却是先抽象再具体（这也是逐步求精方法对分析员的
素质及经验要求极高的原因之一）。
“抽象”是一种与逐步求精正相反的活动。假如系统中有一个“苹
果”对象，在分析过程中发现要增加一种“水果”对象，这个对象可以
说是由分析员从“苹果”中抽象出来的，但实际上，更应该是说分析
员要把日常生活中被遗漏的“水果”对象罗列出来。比较虚幻的实例连
接也是如此，这种连接在生活中一定是存在的，要把它以合适的方法罗
列出来，并不是抽象出来。水果的“色泽”，“形状”等属性，可以说
是由分析员“抽象”出来的，但更应该说是分析员准确地将这些属性罗
列出来。方法也是如此。无它，面向对象反映的是现实。
继承是从抽象到具体，但严格来说，继承也不是逐步求精。因为在
面向对象中，继承的目的是对抽象类的特性化。而且，在分析时，运用
的是抽象而不是继承。
逐步求精法在软件工程的发展中起到的作用绝不可抹杀！不少成熟
的系统均是由这个方法而来，IBM就是一个典型。逐步求精法对我的工作
帮助非常大，从开始接触到应用已经多年，随着项目的增多和研究的深
入，它所固有的缺点也使我从觉察到困惑，个中的困难与不解相信你我
都曾经经历。面向对象也许不是最好的解决办法，但我认为它的确比以
往的分析方法先进。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: ]
发信人: yxue (jose), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易虚拟社区 (Fri Nov 19 11:45:27 1999), 站内信件
【 在 kenmlee (ken) 的大作中提到: 】
: edison和leeyg两位的精彩发言有让人茅塞顿开的感觉，
: 谢谢两位
:
: 在此，发表一下我的看法：
: .......
我想就需求分析的问题与大家讨论一下。
首先，我认为面向对象的分析和功能分解并不是不相容的。因为无论采用哪种
分析方法，都不可避免地要对系统功能进行分析——当你和用户首先打交道的
时候，用户只会告诉你“我需要这个系统实现XXX功能”、“我需要这个系统
能够如何如何”。OOSE中的USE CASE就是功能分析的工具，OMT中没有类似的工具
。
而UML将USE CASE包括进来的目的就是从功能的角度来捕获需求。所以我认为，
功能分析是面向对象分析的基础。
其次，我对edsion兄的“让需求固定，得到最根本、最本质的需求”表示异议。
我认为用户需求处于不断变化，是不存在“最根本、最本质的需求”的，只存在
在某个时间内用户满意的需求。如果一个软件在交付时达到了当时用户满意的
需求，这个项目就是比较成功的。之所以说比较成功，是因为今后用户的需求
还会变，如果目前的软件不考虑将来用户业务的发展，那就不能说是成功的。
第三，系统分析的目的就是捕获需求。但在软件项目启动的时候，可能连用户
也说不清楚需求到底是什么，我倾向于使用Rational的Unified Process方法，
就是在软件开发的各个阶段中都要做一些需求分析，在初创阶段和求精多做一些
，
在构造阶段少做一些，在不断地与用户交流中逐步积累需求。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.190.16]
发信人: rup (rup), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易虚拟社区 (Fri Dec 17 21:22:30 1999), 站内信件
【 在 leeyg (雷云沟) 的大作中提到: 】
: : 做分析的时候，不仅仅是需求分析（包括总体设计、详细设计），
: : 都是一个逐步求精的过程。可能大家会认为这仅仅是瀑布模式的系统
: :分析的结论，对于面向对象的分析不一定是这样。但是，想想即使是面
: :向对象的分析，最后还是要将问题分解，然后逐个解决。因此这种层
: .......
各位的意见好象逐渐向Rational's OOAD的方法靠拢，Rational think the deve
lop
process is a "iteration" process,每一次循环都会发现新的需求（程序员和用
户都会）
在分析和概要设计时就应经过３，４次的循环.....
版本控制，Rational Clearcase是一个相当不错的工具，支持Team develop.
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.109.52.252]
发信人: edison (edison), 信区: SystemAnalysis
标 题: Re: 面向对象与功能分解--与edison探讨
发信站: 网易 BBS (Fri Dec 17 22:29:19 1999), 站内信件
是吗，哪里可以下载？
实在是万分感谢！
【 在 rup (rup) 的大作中提到: 】
: 【 在 leeyg (雷云沟) 的大作中提到: 】
: : .......
: 各位的意见好象逐渐向Rational's OOAD的方法靠拢，Rational think the deve
: lop
: process is a "iteration" process,每一次循环都会发现新的需求（程序员和用
: 户都会）
: 在分析和概要设计时就应经过３，４次的循环.....
:
: 版本控制，Rational Clearcase是一个相当不错的工具，支持Team develop.
:
:
:
--
谢谢没有在 "将本文章寄一份给原作者" 处打勾, 再次感谢!
※ 来源:．网易 BBS bbs.netease.com．[FROM: 202.96.191.124]
|
|