回复关系：
作者 内容
 w_rose   软件OO工程
分析环节：
分析用户领域有价值的对象以及对象之间的关系（关键是后者）。这些对象将来可以与支持对象继承和接口的任何编程语言直接对应，因此从分析到编程和从编程回到分析的过程非常容易，程序代码就是一种文档，是“自我描述”的。
实际上将任意一个旧程序所处理的数据抽象为层次化的结构(使用c的struct)并且给出用户能理解的术语，这支程序就会立即变得好理解多了。

设计环节：
基本是传统的面向状态的方法。但是与传统的分析方法类似，传统的设计方法往往针对“一个整数”之类 与用户领域的术语不直接对应的数据进行设计，不但繁琐而且很容易让用户摸不着头脑。因为分析中已经将各种对象高度抽象，设计中的状态直接是某些对象的属性集合，设计变成了类似行为科学的描述，非常生活化。

处处强调对象化：
OO非常强调分析和设计阶段将程序对象高度抽象为最一般用户都能完全理解的术语。这在过去几十年许多著名的程序设计师的文章中都是如此。但OO将此推向极至，坚决反对在分析和设计阶段涉及任何只有计算机领域才关心的概念。

继承了结构化编程的精髓：
在60年代末的大量文章（高级语言编译系统、逻辑程序、人工智能等等）都谈论了将程序的数据组织成记录并且给出清晰的名称能够将程序的数据结构与处理过程相分离。由于数据结构代表了程序的主要信息，用更高效率的数据结构取代不太有效的数据结构可以迅速提升程序的效率。采用对数据结构进行抽象的方法，可以将过细的数据结构推迟到程序设计的后期再完成，而先针对高层次机构设计出流程来，这符合逻辑程序根据未来不确定的过程自顶向下（从目标出发）解决问题的普遍特点。

创新：
OO的特殊性在于定义了分析中的继承和设计中的对消（操作覆盖）的具体规则。这些规则使得程序可以写的很简练。后代不必重复写出祖先的各种关系和事件处理流程，而只需要说明什么改变了就行了。对于很复杂的程序，仅使用最高不过几层继承就可以轻松地将别人 1 万行代码缩小到2、3千行代码，没有重复抄写的废话，因此由于不小心抄写错误带来的运行时错误也排除了。同时这种多重继承和多层继承也更符合人类的理解事物的习惯。可惜.NET并不直接支持多重继承（只支持多重接口）。

调试和成本估计更容易：
OO风格的程序都是离散的。现在程序员很喜欢设计组件，每个组件都有详细的设计文档、运行效率的技术参数，测试用例等等，可以一个一个单独地测试。这些组件的先后排列次序对整个软件毫无影响。至于成本估算，就像商业一样，有人认为费用审计考虑得详细了很费时间，但是行家确实比一般人考虑的详细很多，也没发现他们比一般人笨。

偏重对象分析还是偏重动态设计：
软件本来就是在这个两维世界上的暂时平衡点，目的是为了推向市场。对象分析中对象之间的关系隐含了许多动作（比如删除对象应当同时删除自己的组成部分，以及对象如何检索等等）。而动态设计中每一个动作事件都是从一个已经定义好的对象身上发生的。因此不应该偏重哪种方法，而应当在“对象->动作->对象”这个次序上反复修改以使从两个角度对系统的描述都比较容易理解。好的设计往往要从“聪明”的设计上“降格”以便在两个条件上平衡：读者没有分歧和描述很简单。

完备性：
严格说，一个组件的测试代码远比实现它的代码要多。开发一个组件时可能只有一种单一的目的，但是为了发布它需要假设另外还有很多种目的使用它。比如对用户界面一个常见的“多余目的”就是有些“多事”的用户会不时拼命地胡乱敲击键盘。
 02/05/30 23:52 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 huig   分析模型与设计模型往往差别很大。基本做不到平滑过渡
 02/05/31 11:29 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   什么叫平滑过渡?干嘛要平滑过渡？如果世界必须有男人和女人之分，就等于说任何组织内必须要“平滑过渡”吗？
 02/05/31 12:06 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   “做完分析再做设计”，这可能吗？
 02/05/31 12:10 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 huig   我误会了？你一个分析环节，一个设计环节的。
"因此从分析到编程和从编程回到分析的过程非常容易，程序代码就是一种文档，是“自我描述”的"

这难道不是说分析和设计的平滑过渡？？？？


分析是针对业务领域的，而设计则是对分析模型的进一步细化。
分析和设计在大部分的软件过程中都是统一的。
 02/05/31 12:46 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 wljcan   理论上应该是这样的，如果时间充裕也是可能的。
在软件工程中有一种方法叫并发开发模型，可以边分析边设计，但如果用瀑布型或者rup，则必须先分析后设计，理论上是这样的。呵呵
 02/05/31 13:01 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   我有时候把分析和设计统称为分析。但是我绝不会把编程叫做设计。
 02/05/31 19:52 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   你是否曾经用完rup之后，把它从硬盘上删除，然后再安装开发环境编程？不会吧。即使开发完程序第一版本，你还有需要回到rup来再补充点东西！
 02/05/31 19:55 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 wljcan   我感觉你对RUP有点误解，RUP本身就提出了增量和迭代的概念，你刚才说的还是传统的瀑布模型。
RUP是一种软件工程方法，它不是一种工具，怎么叫“用完RUP”?统一模型的思想应该分布于软件工程的各个阶段，编程只是实现部分。
 02/06/01 10:11 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 huig   回复: 我有时候把分析和设计统称为分析。但是我绝不会把编程叫做设计。
你的设计难道不需要用代码来检验？哪个的水平这么高，设计中不会出现问题，敏捷方法都强调尽早写代码，因为只有在写代码，作测试的过程中才会发现很多问题，才能降低项目的风险。
 02/06/01 13:33 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 dengqizhou   在分析阶段，要直接提取出用户领域对象，这不太容易吧。
在分析阶段，直接提取出用户领域对象，这样做比较困难，我认为可以先做出一个针对业务的分析模型，再映射成对象模型。
 02/06/01 18:08 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   我的目的是告诉huig根本无法设想“过渡”的含义(因为本来是一个事物的两面，两面怎么过渡成一面)，所以举了一个根本不可能事情来反问他如何合作。
 02/06/01 20:19 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 w_rose   好啊！不过我这里只是讨论OO的要点是什么，没有讨论OO如何做。如果讨论分析的方法，在详细了解用户需求描述之后，得到对象模型之前，可以写出十几条步骤机械地执行呢！对于步骤，太简单了分歧就很大，就像岔路太多就等于没有路。
 02/06/01 20:30 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 dengqizhou  明白了。不过我觉得找出一种简单实用的OO过程模式，也是OO的要点之一吧。
 02/06/02 09:57 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：