候鸟南飞，是因为天气变化；日落晨昏，是因为地球围绕太阳在自转；沙尘暴加剧，是因为植被破坏，沙漠化更严重的结果。每一种表象的背后，有着它自然的作用规律，当我们开始用用例进行需求分析的时候，经常是得到了许多从外部角度对系统目标的描述，这些描述非常重要，但是分析模式，实际上是超越了这些外部描述而得到的系统内部规律。

 回复: 抛小块砖：分析模式是什么
　

---

能不能说清楚点？

例如有人需要开发一套软件来模仿桌球游戏，问题可能用用例来表述表面的特征：“游戏者击中白球，它以一定的速度前进，并以特定的角度碰到红球，于是红球在某个特定的方向上前进一段距离”。可以拍下几百个这样的事件，测量不同的球速，角度和距离，但靠这些样例要写出好的仿真程序远远不够，因为除了这些表面现象，还必须了解背后的本质，那就是和质量有关的运动定律，速度，动量，等等。了解这些规律将更容易看到软件可以怎样建立。

这个例子可能很特别，因为这些定律已经成为公理；而在我们建造应用系统的时候，需要大量的了解和研究，才能接触到问题的本质。作为计算机软件开发人员，哪怕在哪一个领域工作了很多年，我们依然受到计算机思考方式的限制，因此，要建立合理的系统模型，要得到相对稳定的模式，都需要请问题域专家参与建模，我们需要教给他们一些用来表述的注记，引导他们把问题表述出来，然后，在可能的情况下，进行技术上的总结和提醒。系统的模型其实一直都存在，我们要做的，就是要和问题域专家们一起，把它们从纷繁复杂的问题表象中找出来。

在以往的系统建设经历中，曾经见过系统建模人员，将问题域人员的需求全部描述出来，然后把他们平常手工进行的业务过程，一一用软件实现，我们知道，这样其实不是很好的解决方案，每一次工具的变革都会对人们的活动产生影响，那么，我们有了计算机，硬件和软件以后，业务过程是否会受到影响，应该有所变革呢？如果需要的话，需要跟问题域专家进行协商，由他们来权衡，然后，这些变革和影响，首先就会体现在系统模型上。

这样，就已经有了一些软件过程重组的意义了，面向对象系统建模正好可以将系统分析和过程重组结合到一起，用来促进业务过程的变革。

分析模式更接近系统的概念模型，如果系统概念模型经过抽象，可以应用在多个相似的环境中，那么，它就变成了模式。在代码实现层面，我们很容易看到和理解重用的概念，从最开始的函数库，到类库，到设计模式，到应用框架，我们的对代码的重用程度越来越高，在业务领域的分析层面，重用的可能性依然存在，分析模式，就是这种重用的一部分，如果我们都可以利用以往的经验，得到业务领域的通用解决方案，它们将直接影响到应用系统的设计，因而这种重用的价值将更加显著。

 回复: 分析模式是什么 (续)
　

---

你说了很多，只有后面才说清了点什么是分析模式，其实本来要完全说清楚也是很困难，但是至少要把握核心意思。我想你还要整理一下你的思想。分析模式和自然规律是不同的。一个主观的一个是可观的。什么是模式？什么是分析模式？
我想你应该用最简单的话说出来。

 回复: 分析模式是什么 (续)
　

---

windy，我看了一些你翻译的《分析模式》，感觉有点怪怪的，我也看了GOF的实际模式，我觉得比分析模式好懂，呵呵，是不是我的分析问题的思维方式需要。。。

代码实现是具体的，分析模式本身更加抽象和不容易理解，不容易“抓到”，而且它跟具体的业务领域相关（当然也可以扩展到其他的领域）

说分析模式的时候跟业务领域是分不开的，所以我很希望我们可以就以往接触过的一些应用来回顾一下，可否存在更好的模型组织方式，也许可以看到一些分析模式的雏形。。。。

我正在总结一篇 帐务模式在代理结算系统中的应用 的文章 ：）

如果有什么别的看法，请告诉我，谢谢！

非常谢谢，那是不是要是我也写《分析模式》，那你会觉得有些怪，因为我做的应用和你做的应用是不同的，是吗？？

 不会啊
　

---

相同或相似的应用中，分析模式一定有可以重用的地方，如果是完全不同的应用，确实会存在不同的模式/模型，但我们依然可以去寻找其中的思考方法，借鉴其他领域的经验。

应该不能说“怪” ：） 只是对别的领域有不熟悉的感觉吧？

 Windy可能会做这本书的技术审校工作
　

---

现在的出版社，做事都比较认真了，读者有福了。

 请问Windy一个问题
　

---

请问，对于一个分析模式，重用的是什么东西？

也就是建模的结果

 两个问题必然是有不同的，怎么办？
　

---

对于两个不同的问题，你总不能用同一个模型去套吧？如何处理呢？

 你看这样行不 ：）
　

---

相同的问题 重用
相似的问题：部分重用
不同的问题/不清楚的问题：不重用或考虑有无重用的可能性

 这不是废话嘛
　

---

>相同的问题 重用
>相似的问题：部分重用
>不同的问题/不清楚的问题：不重用或考虑有无重用的可能性

绝对相同的问题，肯定是不存在的；绝对不同的问题（以及不清楚的问题），没有讨论重用的必要。既然讨论重用这个话题，当然就是指在“相似的问题”这个范畴内。

Windy不要回避问题，不要拿废话来搪塞我。

直接重用并不是不存在的，部分重用也是大实话啊！作为比较抽象的模型，你会借鉴它的组织方式，然后看看是否适合目前的问题，还是需要进行一些改动和补充，例如，把人和组织同样看待（Party模式的第一个模型），在建立一个银行客户登记系统时就可以直接重用，对吗？

更详细的内容可以看下面的一篇文章：
An Extension and Implementation of Fowler's Observation Analysis Pattern（http://www.joeyoder.com/Research/metadata/Observation/observationmodel.pdf）
说明：Observation是一个有名的分析模式，主要适应于医院管理系统，针对病人需要进行很多项目的测量和记录，因此，需要观测的目标，观测的项目，观测的协议，观测的结果构成了该模式的主要部分。这篇论文总结了这些模式在医院系统的实际应用情况，并用Validators（进行观测类型的有效性验证）和CompositeObservation（组合观测）补充了原来的模型。

另外，开玩笑并不等于“回避问题，不要拿废话来搪塞”，特此声明。

 当然是大实话
　

---

“复用其中一部分，修改另一部分”。毫无疑问这是大实话，因为它是废话。就好象我说“外面可能在下雨也可能没下雨”，这句话一定是正确的，但它没有给出关于天气的任何信息，因此它是一句废话。

同样，你的这句“大实话”也是信息量为0的重言式。把重言式与其他任何命题做合取，都不会改变后者的信息。所以，我们的问题依然在原地踏步：你是根据什么来判断它“是否适合目前的问题”呢？又是根据什么来决定做哪些“改动和补充”呢？如果我需要自己费劲去找这两个问题的答案，跟我费劲去找这个领域问题的解决方案，有什么不一样？

并且，“应用某个模式”和“问题得以解决”这两者之间真的有因果联系吗？或者只是恰好先后发生？如何知道它们之间的因果联系？这个问题，windy如果有兴趣可以一起回答。

分析模式包括多个领域的多个模式，就每个模式，都有关于它设计背后的理由，适合的场景，如何使用的一些推荐，重用的时候，可以直接参考这些推荐，例如，对于企业的组织结构，对于树型结构和扁平型/矩阵结构，推荐使用的模式就不同，当然，如果你说不知道是什么是树型什么是矩阵，那我无话可说。

前面我已经举了两个在问题域如何应用模式的例子，对这两个例子，你也认为是“重言式”吗？也是在原地踏步，什么也没说吗？

出现问题，寻求解决方案，问题重复出现，解决方案大致相同＝＝＝＝形成模式

模式是为了更好地解决问题，特别是那些重复出现的问题，如果一个模式经过实践证明解决了相似的问题，那么不妨一试，但试不试是你的自由。

＝＝＝“应用某个模式”和“问题得以解决”这两者之间真的有因果联系吗？或者只是恰好先后发生？

按照你的思路，我应该说“我猜测，它们之间有联系，但联系是："更好地解决问题"”

恰好先后发生：很有可能啊，我刚好用了某个模式，纯属巧合的是，我关注的那个问题解决了，这可跟模式一点关系都没有。

我刚看到一篇文章，作者提到软件模式这个概念，包括分析模式、设计模式、过程模式等。作者还说模式研究的一个趋势是将这种思维方式用到其它领域中，西方称为模式运动。我觉得从宏观的角度来看，作者说得很透彻。

原版的电子书哪里可以下载呢？（如果有的话）