首先，感谢兄台的直言，小子今天路过看到此文，因此回应。
1）关于截图的问题有不少朋友提到过，至于项目，有类似行业经验的人应该可以看得出来是属于哪些行业的项目。
说实话，小子不敢拿一个完整的项目来做，否则，肯定会有公司找我算账的。
书中的截图都是经过修改后的图，比原图略显简单，但应该足够说明问题。
当然，完美结合是不可能的，这也不是我要添加的词语，估计是美工或者电子社策划人员的考虑。这点，我向所有的朋友道歉。
2）我这本书主要讲的是方法，我个人认为也就是所谓的方法论，而不讲工程过程，因为不同的项目有不同的管理模式、不同的用户对象、不同的用户要求和行业特性，区别太多，需要具体问题具体考虑，我认为能够写的，只有方法，而没有过程——这是小子一向的观点。所以，操作步骤是必需的，希望使读者看了书以后，可以自行按照书上的内容自行做一些摸索。
3）这一点我不太明白，所以，不好多讲。如果您有问题，欢迎您到我的blog或者csdn的软工板块上来单独提出。
4）这一点，也可能是小子不懂写书吧。很多人说过我应该想李维先生学习，可是，毕竟精力有限，只能希望再次丰富内容之后，我争取做得更好一些吧。
关于您的问题：
1）交互建模是对用例阐述在表现层的细化，它可以辅助做分析模型，因为它直接完成了用户的操作和系统的直接反映过程。
2）小子认为域模型、业务模型应该属于业务建模领域，不属于小子所言的分析模型或者说是rational的分析模型的范畴。
3）关于模式的问题说起来可能太多，不过，我窃以为Gof的模式更多的处于编码层，但是，应用了，你也不能解决你的业务问题，他所能提供的也是一个抽象层上面的方法，必须你选择正确的模式解决类似的问题而已，所以，这和文档模版以及数学公式的作用应该是相同的。
也许小子理解有些偏差，望不吝赐教。
4）关于基本框架方面的设计类的问题，我个人认为这是在架构指导设计的过程中形成，并在设计结束后提取的，就算是jdbc的连接实现，也只是后台的一个实现类中的连接方法实现，这些在一定程度上是通用的，或者说是属于可重用构件方面的部分。
这部分在将来，我个人认为可以通过代码库来进行较好的支持，也就是将来MDA中完全不需要人工参与再次编码的部分。
不知道上面这些内容是否回答的完整，欢迎各位批评指正。
