方案二:增加冗余
方案三:增加中间调合层
一个组件图的例子，网上交费业务的组件视图
再次提醒读者，这些例子只是针对某个问题的解决方案之一，不可避免的带着笔者的个人经验色彩。这些解决方案不是真理，没有高下，甚至没有对错。目的只是为了提供思路，而非模板和教条。熟悉设计模式的读者可以从设计模式中找到很多解决这类问题的模式。读者不应该拘泥于研究笔者这些解决方案，这些方案仅是为了配合说明调整分析模型关键点而提供的示例而已，重要的是理解那几个关键点。
这一篇当中，笔者讲述了一些调整分析模型的要点，并举了几个例子。笔者不得不说的是，写这篇文章真的花费不少力气。设计是一种创造性工作，随环境而变，随要求而变，随设计师而变...要总结出一套方法来实在是困难。笔者只能就自己的经验写一些要点。诚然，这些例子不足以解决所有问题。目前估计没人能做到\统一设计方法\，真到了那一天，软件就是工业化生产了。笔者希望通过这几个要点和例子，能够激发读者的思路，举一反三，而不是照葫芦画瓢（我相信想画也画不出来）。今天这篇同时也揭示了分析模型到底要做些什么。读者也可以体会一下，调整分析模型与原来没有分析模型时调整设计类相比哪个更容易些，工作量更小些。
接下来，要讨论如何转化到设计类的问题了。但是设计类是实现类，它必然与软件框架，系统架构，实现语言息息相关。所以下一篇将讨论软件框架和系统架构在UML里的表现方形式，再下一篇才讨论分析类到设计类的转化问题。敬请期待。
*********************************************************