[全程建模]應徐峰兄之《軟體工程之全程建模實現》閱讀有感

首先，感謝兄台的直言，小子今天路過看到此文，因此回應。
1）關於的問題有不少朋友提到過，至於項目，有類似行業經驗的人應該可以看得出來是屬於哪些行業的項目。
說實話，小子不敢拿一個完整的項目來做，否則，肯定會有公司找我算賬的。
書中的都是經過修改後的圖，比原圖略顯簡單，但應該足夠說明問題。
當然，完美結合是不可能的，這也不是我要添加的詞語，估計是美工或者電子社策劃人員的考慮。這點，我向所有的朋友道歉。
2）我這本書主要講的是方法，我個人認為也就是所謂的方法論，而不講工程過程，因為不同的項目有不同的管理員模式、不同的使用者物件、不同的使用者要求和行業特性，區別太多，需要具體問題具體考慮，我認為能夠寫的，只有方法，而沒有過程——這是小子一向的觀點。所以，操作步驟是必需的，希望使讀者看了書以後，可以自行按照書上的內容自行做一些摸索。
3）這一點我不太明白，所以，不好多講。如果您有問題，歡迎您到我的blog或者csdn的軟工板塊上來單獨提出。
4）這一點，也可能是小子不懂寫書吧。很多人說過我應該想李維先生學習，可是，畢竟精力有限，只能希望再次豐富內容之後，我爭取做得更好一些吧。

關於您的問題：
1）互動建模是對用例闡述在表現層的細化，它可以輔助做分析模型，因為它直接完成了使用者的操作和系統的直接反映過程。
2）小子認為領域模型、業務模型應該屬於業務建模領域，不屬於小子所言的分析模型或者說是rational的分析模型的範疇。
3）關於模式的問題說起來可能太多，不過，我竊以為Gof的模式更多的處於編碼層，但是，應用了，你也不能解決你的業務問題，他所能提供的也是一個抽象層上面的方法，必須你選擇正確的模式解決類似的問題而已，所以，這和文檔模版以及數學公式的作用應該是相同的。
也許小子理解有些偏差，望不吝賜教。
4）關於基本架構方面的設計類的問題，我個人認為這是在架構指導設計的過程中形成，並在設計結束後提取的，就算是jdbc的串連實現，也只是背景一個實作類別中的串連方法實現，這些在一定程度上是通用的，或者說是屬於可重用構件方面的部分。
這部分在將來，我個人認為可以通過程式碼程式庫來進行較好的支援，也就是將來MDA中完全不需要人工參與再次編碼的部分。

不知道上面這些內容是否回答的完整，歡迎各位批評指正。