从上面的例子可以看出分析模型比设计模型要稳定得多，因此用它来验证和表达系统到需求的映射是很好的。这有助于在开发过程中当实现类变来变去，一个类改两个，突然又加了一个设计模式(这种情形非常的常见吧?)时，保持系统到需求映射的稳定，同时也就保持了一个稳定的系统视图和业务架构。对开发小组来说，不会因为这些变动影响到他们对系统整体的认识。
分析模型较高的抽象层次有助于让人们更容易理解系统行为。由于与实现无关，因此可以用大白话来表达系统交互过程，比如对于登录要求，我们可以直接用“登录()”来表示这个系统请求，相比于设计类中的getUser()，getRole()，getGroup()之类的方法名，分析模型明显要直白得多。而开发人员对系统行为良好的理解显然会对开发有着很大的帮助。 在一个项目比较复杂，而且是多个Team横向合作的情况下，分析模型显得更加有效。因为它的简洁和稳定，会让各个开发组减少细节沟通的成本。
最后，如果你所做的项目并非一次性项目，而是基于一个行业，不断的有相似或相同的单子，更打算长期立足于这个行业，做精做深，形成完整的行业解决方案的话，分析模型更是必须要考虑的。在你的组织面对同行业不同客户时，可能无法保证所有客户都选择同样的语言，同样的软件平台，有着同样的业务要求。在设计模型的层次上，这必然导致很多个不同的实现版本。面对这么多不同的版本，如何去维护一个“统一的行业解决方案”呢？正如上面所述，由于分析模型抽象层次高于实现方式和实现语言，你可以用分析模型来维护这一个方案。还是登录的例子，虽然客户们可能有的用LDAP，有的用CA，将来可能还有新的模式，但对于分析模型来说，安全模块始终可以保持一致。这将非常有利于随着各个项目的进行，对分析模型的逐步维护，而形成一个统一的，稳定的架构和行业解决方案，而针对不同的客户要求，又可以提供不同的实现包。
这是OO系统设计师之路的第一篇。笔者讨论了什么是分析模型，以及为什么要用分析模型。下一篇将用一个示例说明分析模型如何做，它的结果是什么样的。敬请期待。
分析模型是系统的高层抽象，是高于实现语言和实现方式的。因此在做分析模型过程中，要跳出固有的java思维，C++思维，同时也暂时不要考虑设计模式的应用，而专心的，用OO思维把四个分析类的职责和交
互，以及它们之间的关系定义清楚。如果说用例分析大部分情况下是程式化的（笔者正希望它是程式化的），那么你会发现，分析模型大部分工作也是程式化的。
拖了很长时间才写第二篇，为自己的懒惰羞愧一个:P
上一篇笔者阐述了什么是分析模型，我们为什么要使用分析模型，分析模型能给我们带来什么。这一篇来讨论怎么做分析模型。
开篇之前先说点题外话。笔者不厌其烦地一次次提到需求的可追溯性，是因为软件工程比UML更重要更本质。笔者自己在学习UML过程中，曾经也非常迷惑而不得要领，这么多UML元素，每个都有其特定的含义，RUP中定义了更多更复杂的流程，模板，工具...虽然读了很多资料，却始终感觉UML信息太过于分散，不能很好的把UML应用到实际的项目中去。直到有一天突然转变了思维，不是从UML的定义中去思考如何做软件，而是站在软件工程的角度，去UML中找寻需要的工具。正是这一转变使我对UML的认识茅塞顿开。我想，初始学习UML的人可能也会经历跟我同样的困惑，在这里我愿意把我的领悟与大家分享。对软件项目来说，OO也好，面向过程也好，UML也好，UC矩阵也好，这些都不是最重要的，软件项目真正的灵魂是软件工程。软件工程的需要才是这些工具诞生的原因。因此我建议阅读我文章的朋友们，在讨论如何应用UML之前，应当先系统学习软件工程。只有掌握了软件工程，你才会知道为什么要有用例，为什么要有分析模型。站在软件工程的立场，那些孤独的UML图符才会变得有生命力，你随时都会知道需要用什么样的UML图符来表达软件的观点。UML也不再面目可憎，它们是一群有着强大能力的精灵，帮助你在复杂的软件工程道路上搭起一座座通向光明目标的桥梁。
虽然是不厌其烦，还是要再次提醒，注意需求的过追溯性，这是软件工程的需要。这一篇我们要讨论的话题里，仍然逃不开这条主线的牵引，你会发现这一篇里产生的任何一个成果都与之前的工作息息相关。如何做分析模型？在UML里，RUP里没有明确的答案，我从软件工程中找到了答案，正如上一篇所说，析模型是采用分析类，在系统架构和框架的约束下，来实现用例场景的产物。用例场景是什么？是用户需求的模拟，实现用例场景，就是实现需求。为了达到需求可追溯的目的，分析模型需要以下这些输入（还是采用用例分析系列文章中的例子）：
? 用例场景
? 与用例实现相关的领域模型
? 用例规约 以及 ? 补充规约
在正式开始做分析模型之前，笔者有必要提醒一下，分析模型是系统的高层抽象，是高于实现语言和实现方式的。因此在做分析模型过程中，要跳出固有的java思维，C++思维，同时也暂时不要考虑设计模式的应用，而专心的，用OO思维把四个分析类的职责和交互，以及它们之间的关系定义清楚。如果说用例分析大部分情况下是程式化的（笔者正希望它是程式化的），那么你会发现，分析模型大部分工作也是程式化的。let's begin!
现在，我们有这样一些原料，用例场景提供了需求的输入，领域模型提供了初始的业务原材料，还有用例规约和补充规约提供了详尽的规则。正如笔者在之前的文章中提到的一句话：用例场景非常非常的重要，后续的工作就靠它了。这句话开始起作用，我们的第一步，就从用例场景开始。
做分析模型的建筑材料就是四个分析类，我们要用它们来搭建用例场景。actor分析类来自用例分析中的actor，实体类来自领域模型，边界类来自用例场景中actor-计算机交互，控制类来自业务规则（包括用例规约中的前置、后置条件、业务规则以及补充规约中的全局规则）。所使用的工具是时序图，目标是实现用例场景。我们先来做一个草图，对照着用例场景图，一步步来，得到这个结果：
? 分析模型草图（图片比较大，由于Blog框架的问题，如果看不全，可以在图上右键->图片另存为，
保存到本机再看）