（1）--什么是分析模型
分析模型是采用分析類，在系統(tǒng)架構(gòu)和框架的約束下，來(lái)實(shí)現(xiàn)用例場(chǎng)景的產(chǎn)物。 分析模型是高層次的系統(tǒng)視圖，在語(yǔ)義上，分析類不代表最終的實(shí)現(xiàn)。它是計(jì)算機(jī)系統(tǒng)元素的高層抽象。
筆者認(rèn)為分析模型正是OO設(shè)計(jì)的核心，而設(shè)計(jì)類只是OO的實(shí)現(xiàn)手段。
分析模型是MVC模式的經(jīng)典應(yīng)用。對(duì)比分析類的名稱，MVC模式，讀者應(yīng)該能夠發(fā)現(xiàn)分析類在OO和商業(yè)目標(biāo)中精妙的對(duì)應(yīng)關(guān)系：人，事，物，規(guī)則--actor,boundary,engity,control。這就是為什么筆者說(shuō)分析模型是OO設(shè)計(jì)的核心。
（讓關(guān)心OO之路列的朋友們久等了，今天正式開始推出之路系列的第二部，OO系統(tǒng)設(shè)計(jì)師之路。在第一部OO系統(tǒng)分析員之路中，我們始于什么是用例，結(jié)束于需求規(guī)格說(shuō)明書。我們還記得在第一部中，最后的結(jié)果是系統(tǒng)用例。系統(tǒng)用例規(guī)定了系統(tǒng)范圍，通過(guò)用例場(chǎng)景，規(guī)定了系統(tǒng)藍(lán)圖，讓我們知道了系統(tǒng)將如何實(shí)現(xiàn)業(yè)務(wù)用例中規(guī)定的業(yè)務(wù)。這些工作，是由系統(tǒng)分析員來(lái)完成的。到這里為止，我們還不知道如何讓計(jì)算機(jī)來(lái)執(zhí)行這些業(yè)務(wù)。大家都知道，在需求過(guò)程結(jié)束后，即將進(jìn)行的是分析設(shè)計(jì)過(guò)程，這是系統(tǒng)設(shè)計(jì)師的職責(zé)。OO之路第二部正是針對(duì)系統(tǒng)設(shè)計(jì)師的，筆者將試圖在接下來(lái)的文章里，說(shuō)明如何做系統(tǒng)設(shè)計(jì)，要運(yùn)用哪些工具，產(chǎn)生哪些結(jié)果，以及如何來(lái)驗(yàn)證我們的設(shè)計(jì)是否正確。
這是設(shè)計(jì)師之路的第一篇，筆者要討論的是分析模型。我們經(jīng)常會(huì)聽到分析模型這個(gè)詞，但真正懂得，或者用過(guò)分析模型的人卻少之又少。下面筆者將寫下一段對(duì)話，這段對(duì)話是筆者在招聘設(shè)計(jì)師的過(guò)程中與許多應(yīng)聘者對(duì)話的場(chǎng)景模擬。90%以上的應(yīng)聘者都不能很好的回答這些問(wèn)題。讀者也可以試著回答，看看你對(duì)用UML進(jìn)行OO系統(tǒng)設(shè)計(jì)有多深的了解。
對(duì)話場(chǎng)景：
-在需求過(guò)程結(jié)束以后，接下來(lái)你會(huì)做什么？
-分析設(shè)計(jì)
-你的設(shè)計(jì)依據(jù)是什么？
-需求結(jié)果，用例模型
-你是如何設(shè)計(jì)的？設(shè)計(jì)的結(jié)果是什么？
-設(shè)計(jì)類圖，確定類的方法和屬性，會(huì)用時(shí)序圖來(lái)表達(dá)類之間的交互。還有會(huì)應(yīng)用設(shè)計(jì)模式來(lái)增強(qiáng)系統(tǒng)的擴(kuò)展性和復(fù)用能力。
-那你是如何確定出類來(lái)的呢？比如針對(duì)一個(gè)特定的需求，為什么你決定用三個(gè)類而不是五個(gè)類？類方法又是如何確定的呢？為什么設(shè)計(jì)七個(gè)方法而不是十個(gè)方法？
-短暫沉默后：經(jīng)驗(yàn)啊，從我多個(gè)項(xiàng)目的設(shè)計(jì)經(jīng)驗(yàn)和實(shí)際情況來(lái)看，用這幾個(gè)類和這些方法完全可以滿足業(yè)務(wù)要求，并且是經(jīng)過(guò)優(yōu)化的，是最好的方案。
-那么你如何能夠保證，或者，你用什么來(lái)證明，你的設(shè)計(jì)能夠滿足需求呢？除了經(jīng)驗(yàn)之外，你能用什么方法來(lái)證明呢？
-沉默之后:我有很豐富的設(shè)計(jì)經(jīng)驗(yàn)，我的設(shè)計(jì)是經(jīng)過(guò)深思熟慮的。設(shè)計(jì)會(huì)經(jīng)過(guò)評(píng)審，討論和充分的溝通，后面還有測(cè)試，不滿足需求時(shí)會(huì)再進(jìn)行修改和補(bǔ)充的。
-剛才你也說(shuō)了，需求結(jié)束后你將進(jìn)行分析設(shè)計(jì)的工作。你能說(shuō)說(shuō)分析和設(shè)計(jì)的差別嗎？分析做什么，設(shè)計(jì)做什么？
-更長(zhǎng)時(shí)間的沉默：分析和設(shè)計(jì)是同一個(gè)過(guò)程，分析是想的過(guò)程，設(shè)計(jì)是把想的內(nèi)容用類表達(dá)出來(lái)。
-我們知道在UML里有分析模型和設(shè)計(jì)模型，如果分析和設(shè)計(jì)是同一個(gè)過(guò)程，你能說(shuō)說(shuō)分析模型和設(shè)計(jì)模型的區(qū)別嗎？
-沉默...
是的，的確是這樣。很多人分不清分析和設(shè)計(jì)不同的目標(biāo)，沒(méi)有使用過(guò)或根本不知道分析模型。更多的人無(wú)法回答他的設(shè)計(jì)如何能夠被證明是滿足需求的，那些類在他們看來(lái)，都是憑經(jīng)驗(yàn)，如同精靈一般從腦子里蹦出來(lái)的。他們很自信自己的經(jīng)驗(yàn)和設(shè)計(jì)能力，津津樂(lè)道于一個(gè)又一個(gè)設(shè)計(jì)模式，他們認(rèn)為，如此優(yōu)秀的設(shè)計(jì)怎么會(huì)不滿足需求呢？證明？很奇怪的問(wèn)題，我設(shè)計(jì)的目的就是為了滿足需求，不滿足需求的設(shè)計(jì)我會(huì)不斷改進(jìn)啊，最終它一定是滿足的啊。
可惜這并沒(méi)有回答我的問(wèn)題，我問(wèn)的是如何證明，而不是是不是滿足。即使設(shè)計(jì)師擁有豐富的經(jīng)驗(yàn)和超強(qiáng)的設(shè)計(jì)能力，設(shè)計(jì)結(jié)果的確滿足了需求，并且很優(yōu)秀，但那只是結(jié)果而不是過(guò)程，那是個(gè)人英雄的勝利，而不是軟件過(guò)程的勝利。
事實(shí)上，這一切問(wèn)題，都只是因?yàn)樵O(shè)計(jì)師們遺忘了很重要的一個(gè)過(guò)程，分析模型。那么什么是分析模型呢？為什么分析模型能夠解決這些問(wèn)題呢？
RUP里對(duì)分析模型和分析類的定義是：分析類用于獲取系統(tǒng)中主要的“職責(zé)簇”。它們代表系統(tǒng)的原型類，是系統(tǒng)必須處理的主要抽象概念的“第一個(gè)關(guān)口”。如果期望獲得系統(tǒng)的“高級(jí)”概念 性簡(jiǎn)述，則可對(duì)分析類本身進(jìn)行維護(hù)。分析類還可產(chǎn)生系統(tǒng)設(shè)計(jì)的主要抽象：系統(tǒng)的設(shè)計(jì)類和子系統(tǒng)。
如果你對(duì)上面的定義感到迷惑不解（RUP的定義一向如此），下面是筆者在實(shí)際工作中對(duì)分析模型的理解和應(yīng)用經(jīng)驗(yàn)，或許可以幫助讀者理清頭緒。
問(wèn)題是為什么要用分析模型呢？現(xiàn)在絕大多數(shù)系統(tǒng)的產(chǎn)生過(guò)程并沒(méi)有用分析模型，不也照樣運(yùn)行？而且在RUP里，分析模型也只是一個(gè)Optional的過(guò)程，并非強(qiáng)制過(guò)程啊？
的確如此，這可能也是為什么大多數(shù)設(shè)計(jì)師并不用分析模型的原因。但是，同時(shí)，文章前面的對(duì)話場(chǎng)景中的問(wèn)題也產(chǎn)生了。有讀者要問(wèn)，你說(shuō)分析模型完全實(shí)現(xiàn)用例場(chǎng)景因此可以證明設(shè)計(jì)滿足需求，那么我用設(shè)計(jì)類來(lái)實(shí)現(xiàn)用例場(chǎng)景，不也可以同樣證明？ 那分析模型又有何用呢？
而這正是分析模型要存在的原因。剛才，筆者說(shuō)了，分析類不代表實(shí)現(xiàn)，它具化成設(shè)計(jì)類以后才是實(shí)現(xiàn)。分析類是系統(tǒng)元素的高層抽象。有經(jīng)驗(yàn)的設(shè)計(jì)師，特別是那些擅長(zhǎng)于使用設(shè)計(jì)模式的設(shè)計(jì)師們都知道，OO系統(tǒng)要保持?jǐn)U展能力，復(fù)用性要好，要把變更影響控制在小范圍內(nèi)，就要應(yīng)用高層次的抽象，用高層次的抽象接口來(lái)表達(dá)系統(tǒng)行為，而把具體實(shí)現(xiàn)delay到子類，配置文檔，甚至運(yùn)行期去。所有的設(shè)計(jì)模式，不論采取了怎樣的技巧，均是為了這些目的。分析模型對(duì)系統(tǒng)設(shè)計(jì)來(lái)說(shuō)也同樣延續(xù)了這樣的思想，用四個(gè)高度抽象的分析類來(lái)表達(dá)系統(tǒng)行為，而把實(shí)現(xiàn)delay到設(shè)計(jì)類中去。這些抽象透明于實(shí)現(xiàn)方式，也透明于實(shí)現(xiàn)語(yǔ)言，它表達(dá)的核心觀點(diǎn)是系統(tǒng)架構(gòu)，業(yè)務(wù)實(shí)現(xiàn)模式和規(guī)范，需求可回溯的驗(yàn)證。
比如，我們用一個(gè)實(shí)體分析類表達(dá)了某個(gè)業(yè)務(wù)實(shí)體，在分析模型中我們定義了所有針對(duì)該實(shí)體的交互和存取操作，對(duì)分析模型這個(gè)層次的抽象來(lái)說(shuō)已經(jīng)完整表達(dá)了計(jì)算機(jī)系統(tǒng)對(duì)業(yè)務(wù)需求的模擬實(shí)現(xiàn)。但其實(shí)這時(shí)并未真正的實(shí)現(xiàn)這個(gè)業(yè)務(wù)需求，一直到具化成設(shè)計(jì)類后，根據(jù)開發(fā)語(yǔ)言特性，框架，規(guī)范等等要求，這個(gè)實(shí)體分析類可以被具化成一個(gè)或多個(gè)SDO，POJO，EntityBean，可以用Hibernate，可以用 Webshpere BO，也可以用Weblogic XMLbean...等等。完全可以根據(jù)實(shí)際需要來(lái)確定實(shí)現(xiàn)方式和語(yǔ)言，因此實(shí)現(xiàn)得以delay，這就帶來(lái)了OO擴(kuò)展和復(fù)用的潛在能力。并且這時(shí)設(shè)計(jì)師已經(jīng)不用擔(dān)心具化出的設(shè)計(jì)類是否會(huì)脫離需求，它們已經(jīng)在分析模型層次被驗(yàn)證，而能專心考慮系統(tǒng)實(shí)現(xiàn)所要求的那些特性。在后續(xù)的文章里筆者還會(huì)更詳細(xì)的討論這些問(wèn)題，這里只是舉一個(gè)例子。
為什么要用分析類而不是設(shè)計(jì)類去驗(yàn)證需求呢？這是由于抽象層次更高，分析類比設(shè)計(jì)類驗(yàn)證需求的工作量以及可能的變化都要少很多。比如針對(duì)登錄要求，如果用分析類來(lái)表達(dá)，我們只需要向登錄control類發(fā)一條登錄請(qǐng)求就OK了。而設(shè)計(jì)類由于與實(shí)現(xiàn)方式相關(guān)，并且已經(jīng)具化到了實(shí)現(xiàn)，所以根據(jù)安全驗(yàn)證方式不同，LDAP，CA，SSL，或應(yīng)用服務(wù)器不同，登錄方式和方法都不同，并且可能是很多個(gè)步驟，例如getUser(),getRole(),getGroup(),register()...你愿意用這么多說(shuō)明才能表示已經(jīng)驗(yàn)證了一個(gè)簡(jiǎn)單的登錄要求嗎?慢著，如果更換了安全模式呢？更換了應(yīng)用服務(wù)器呢？這在現(xiàn)實(shí)情況中也很常見(jiàn)，對(duì)分析類來(lái)說(shuō)，由于抽象層次高于實(shí)現(xiàn)方式，因此繼續(xù)有效，而設(shè)計(jì)類卻必須更改。這就是為什么要用分析模型來(lái)驗(yàn)證需求的原因之一。
較真的讀者或許會(huì)說(shuō)，安全模式變了，就算不為了驗(yàn)證需求，設(shè)計(jì)類本身也不得不改，這看起來(lái)沒(méi)什么必然因果關(guān)系?。靠紤]一下，在一個(gè)項(xiàng)目組里，當(dāng)一份設(shè)計(jì)文檔被share到負(fù)責(zé)各個(gè)摸塊的開發(fā)小組時(shí)，各小組對(duì)該文檔都形成了一個(gè)共同的認(rèn)識(shí)。如果這個(gè)認(rèn)識(shí)是基于分析模型而不是設(shè)計(jì)模型的，當(dāng)安全模式改變，對(duì)負(fù)責(zé)安全模塊的開發(fā)小組來(lái)說(shuō)，他可以改變他負(fù)責(zé)的設(shè)計(jì)類而無(wú)需通知其它小組。因?yàn)閺姆治瞿Ｐ偷膶哟蝸?lái)看，一切都沒(méi)有改變。 這與大家熟悉的設(shè)計(jì)類中更換了類實(shí)現(xiàn)而保持接口不變的道理是一樣的，只要接口不變就無(wú)須通知任何人。 而如果這個(gè)共識(shí)是基于設(shè)計(jì)模型的，一點(diǎn)小的改變都需要通知到各個(gè)小組，因?yàn)楦餍〗M的認(rèn)識(shí)是基于類名，方法名的，改動(dòng)了，能不通知他人么？從OO角度來(lái)說(shuō)，這就是松藕合和緊藕合的差別。
從上面的例子可以看出分析模型比設(shè)計(jì)模型要穩(wěn)定得多，因此用它來(lái)驗(yàn)證和表達(dá)系統(tǒng)到需求的映射是很好的。這有助于在開發(fā)過(guò)程中當(dāng)實(shí)現(xiàn)類變來(lái)變?nèi)?，一個(gè)類改兩個(gè)，突然又加了一個(gè)設(shè)計(jì)模式(這種情形非常的常見(jiàn)吧?)時(shí)，保持系統(tǒng)到需求映射的穩(wěn)定，同時(shí)也就保持了一個(gè)穩(wěn)定的系統(tǒng)視圖和業(yè)務(wù)架構(gòu)。對(duì)開發(fā)小組來(lái)說(shuō)，不會(huì)因?yàn)檫@些變動(dòng)影響到他們對(duì)系統(tǒng)整體的認(rèn)識(shí)。
分析模型較高的抽象層次有助于讓人們更容易理解系統(tǒng)行為。由于與實(shí)現(xiàn)無(wú)關(guān)，因此可以用大白話來(lái)表達(dá)系統(tǒng)交互過(guò)程，比如對(duì)于登錄要求，我們可以直接用“登錄()”來(lái)表示這個(gè)系統(tǒng)請(qǐng)求，相比于設(shè)計(jì)類中的getUser()，getRole()，getGroup()之類的方法名，分析模型明顯要直白得多。而開發(fā)人員對(duì)系統(tǒng)行為良好的理解顯然會(huì)對(duì)開發(fā)有著很大的幫助。 在一個(gè)項(xiàng)目比較復(fù)雜，而且是多個(gè)Team橫向合作的情況下，分析模型顯得更加有效。因?yàn)樗暮?jiǎn)潔和穩(wěn)定，會(huì)讓各個(gè)開發(fā)組減少細(xì)節(jié)溝通的成本。
最后，如果你所做的項(xiàng)目并非一次性項(xiàng)目，而是基于一個(gè)行業(yè)，不斷的有相似或相同的單子，更打算長(zhǎng)期立足于這個(gè)行業(yè)，做精做深，形成完整的行業(yè)解決方案的話，分析模型更是必須要考慮的。在你的組織面對(duì)同行業(yè)不同客戶時(shí)，可能無(wú)法保證所有客戶都選擇同樣的語(yǔ)言，同樣的軟件平臺(tái)，有著同樣的業(yè)務(wù)要求。在設(shè)計(jì)模型的層次上，這必然導(dǎo)致很多個(gè)不同的實(shí)現(xiàn)版本。面對(duì)這么多不同的版本，如何去維護(hù)一個(gè)“統(tǒng)一的行業(yè)解決方案”呢？正如上面所述，由于分析模型抽象層次高于實(shí)現(xiàn)方式和實(shí)現(xiàn)語(yǔ)言，你可以用分析模型來(lái)維護(hù)這一個(gè)方案。還是登錄的例子，雖然客戶們可能有的用LDAP，有的用CA，將來(lái)可能還有新的模式，但對(duì)于分析模型來(lái)說(shuō)，安全模塊始終可以保持一致。這將非常有利于隨著各個(gè)項(xiàng)目的進(jìn)行，對(duì)分析模型的逐步維護(hù)，而形成一個(gè)統(tǒng)一的，穩(wěn)定的架構(gòu)和行業(yè)解決方案，而針對(duì)不同的客戶要求，又可以提供不同的實(shí)現(xiàn)包。
這是OO系統(tǒng)設(shè)計(jì)師之路的第一篇。筆者討論了什么是分析模型，以及為什么要用分析模型。下一篇將用一個(gè)示例說(shuō)明分析模型如何做，它的結(jié)果是什么樣的。敬請(qǐng)期待。
(2)--怎樣做分析模型
分析模型是系統(tǒng)的高層抽象，是高于實(shí)現(xiàn)語(yǔ)言和實(shí)現(xiàn)方式的。因此在做分析模型過(guò)程中，要跳出固有的java思維，C++思維，同時(shí)也暫時(shí)不要考慮設(shè)計(jì)模式的應(yīng)用，而專心的，用OO思維把四個(gè)分析類的職責(zé)和交互，以及它們之間的關(guān)系定義清楚。如果說(shuō)用例分析大部分情況下是程式化的（筆者正希望它是程式化的），那么你會(huì)發(fā)現(xiàn)，分析模型大部分工作也是程式化的。
拖了很長(zhǎng)時(shí)間才寫第二篇，為自己的懶惰羞愧一個(gè):P
上一篇筆者闡述了什么是分析模型，我們?yōu)槭裁匆褂梅治瞿Ｐ?，分析模型能給我們帶來(lái)什么。這一篇來(lái)討論怎么做分析模型。
開篇之前先說(shuō)點(diǎn)題外話。筆者不厭其煩地一次次提到需求的可追溯性，是因?yàn)檐浖こ瘫萓ML更重要更本質(zhì)。筆者自己在學(xué)習(xí)UML過(guò)程中，曾經(jīng)也非常迷惑而不得要領(lǐng)，這么多UML元素，每個(gè)都有其特定的含義，RUP中定義了更多更復(fù)雜的流程，模板，工具...雖然讀了很多資料，卻始終感覺(jué)UML信息太過(guò)于分散，不能很好的把UML應(yīng)用到實(shí)際的項(xiàng)目中去。直到有一天突然轉(zhuǎn)變了思維，不是從UML的定義中去思考如何做軟件，而是站在軟件工程的角度，去UML中找尋需要的工具。正是這一轉(zhuǎn)變使我對(duì)UML的認(rèn)識(shí)茅塞頓開。我想，初始學(xué)習(xí)UML的人可能也會(huì)經(jīng)歷跟我同樣的困惑，在這里我愿意把我的領(lǐng)悟與大家分享。對(duì)軟件項(xiàng)目來(lái)說(shuō)，OO也好，面向過(guò)程也好，UML也好，UC矩陣也好，這些都不是最重要的，軟件項(xiàng)目真正的靈魂是軟件工程。軟件工程的需要才是這些工具誕生的原因。因此我建議閱讀我文章的朋友們，在討論如何應(yīng)用UML之前，應(yīng)當(dāng)先系統(tǒng)學(xué)習(xí)軟件工程。只有掌握了軟件工程，你才會(huì)知道為什么要有用例，為什么要有分析模型。站在軟件工程的立場(chǎng)，那些孤獨(dú)的UML圖符才會(huì)變得有生命力，你隨時(shí)都會(huì)知道需要用什么樣的UML圖符來(lái)表達(dá)軟件的觀點(diǎn)。UML也不再面目可憎，它們是一群有著強(qiáng)大能力的精靈，幫助你在復(fù)雜的軟件工程道路上搭起一座座通向光明目標(biāo)的橋梁。
雖然是不厭其煩，還是要再次提醒，注意需求的過(guò)追溯性，這是軟件工程的需要。這一篇我們要討論的話題里，仍然逃不開這條主線的牽引，你會(huì)發(fā)現(xiàn)這一篇里產(chǎn)生的任何一個(gè)成果都與之前的工作息息相關(guān)。如何做分析模型？在UML里，RUP里沒(méi)有明確的答案，我從軟件工程中找到了答案，正如上一篇所說(shuō)，析模型是采用分析類，在系統(tǒng)架構(gòu)和框架的約束下，來(lái)實(shí)現(xiàn)用例場(chǎng)景的產(chǎn)物。用例場(chǎng)景是什么？是用戶需求的模擬，實(shí)現(xiàn)用例場(chǎng)景，就是實(shí)現(xiàn)需求。為了達(dá)到需求可追溯的目的，分析模型需要以下這些輸入（還是采用用例分析系列文章中的例子）：
- 用例場(chǎng)景
- 與用例實(shí)現(xiàn)相關(guān)的領(lǐng)域模型
- 用例規(guī)約 以及
- 補(bǔ)充規(guī)約
在正式開始做分析模型之前，筆者有必要提醒一下，分析模型是系統(tǒng)的高層抽象，是高于實(shí)現(xiàn)語(yǔ)言和實(shí)現(xiàn)方式的。因此在做分析模型過(guò)程中，要跳出固有的java思維，C++思維，同時(shí)也暫時(shí)不要考慮設(shè)計(jì)模式的應(yīng)用，而專心的，用OO思維把四個(gè)分析類的職責(zé)和交互，以及它們之間的關(guān)系定義清楚。如果說(shuō)用例分析大部分情況下是程式化的（筆者正希望它是程式化的），那么你會(huì)發(fā)現(xiàn)，分析模型大部分工作也是程式化的。let's begin!
現(xiàn)在，我們有這樣一些原料，用例場(chǎng)景提供了需求的輸入，領(lǐng)域模型提供了初始的業(yè)務(wù)原材料，還有用例規(guī)約和補(bǔ)充規(guī)約提供了詳盡的規(guī)則。正如筆者在之前的文章中提到的一句話：用例場(chǎng)景非常非常的重要，后續(xù)的工作就靠它了。這句話開始起作用，我們的第一步，就從用例場(chǎng)景開始。
做分析模型的建筑材料就是四個(gè)分析類，我們要用它們來(lái)搭建用例場(chǎng)景。actor分析類來(lái)自用例分析中的actor，實(shí)體類來(lái)自領(lǐng)域模型，邊界類來(lái)自用例場(chǎng)景中actor-計(jì)算機(jī)交互，控制類來(lái)自業(yè)務(wù)規(guī)則（包括用例規(guī)約中的前置、后置條件、業(yè)務(wù)規(guī)則以及補(bǔ)充規(guī)約中的全局規(guī)則）。所使用的工具是時(shí)序圖，目標(biāo)是實(shí)現(xiàn)用例場(chǎng)景。我們先來(lái)做一個(gè)草圖，對(duì)照著用例場(chǎng)景圖，一步步來(lái)，得到這個(gè)結(jié)果：
- 分析模型草圖（圖片比較大，由于Blog框架的問(wèn)題，如果看不全，可以在圖上右鍵->圖片另存為，保存到本機(jī)再看）
我們來(lái)分析一下上面的草圖。首先，這幅草圖大家可以看到，所有的實(shí)體類沒(méi)有做任何變動(dòng)，直接照搬了業(yè)務(wù)實(shí)體(領(lǐng)域模型)，所謂的控制類，只是機(jī)械的在每一個(gè)實(shí)體前加了一個(gè)控制器，邊界類只用了一個(gè)。至于過(guò)程，更是和用例場(chǎng)景一模一樣，只不過(guò)形式不同而已，改用了計(jì)算機(jī)術(shù)語(yǔ)。這個(gè)例子只有一個(gè)用例場(chǎng)景，如果有多個(gè)，每個(gè)場(chǎng)景畫一次，重復(fù)用到的類直接拖過(guò)去，能用的方法直接用，還沒(méi)有的就加上，總之忠實(shí)的實(shí)現(xiàn)這些用例場(chǎng)景就好了。整個(gè)過(guò)程很簡(jiǎn)單，很程式化，對(duì)嗎？不用腦子都能做。盡管如此，我們?nèi)匀坏玫搅艘粋€(gè)分析模型的靜態(tài)圖，就象下面這樣：
小提示：在做分析模型時(shí)，從時(shí)序圖開始做，需要用到一個(gè)分析類時(shí)，就轉(zhuǎn)到類圖中創(chuàng)建這個(gè)類，再?gòu)淖筮叺臉湫瘟斜砝锇杨愅系綍r(shí)序圖上。從一個(gè)對(duì)象畫一條表示交互消息的箭頭到另一個(gè)對(duì)象后，右鍵點(diǎn)擊線條，選擇"new operation"，再輸入操作名，這時(shí)Rose會(huì)在線上標(biāo)明這個(gè)操作名稱的同時(shí)在對(duì)應(yīng)的類上創(chuàng)建這個(gè)方法。這樣，在繪制時(shí)序圖的同時(shí)也生成了靜態(tài)類圖。最后再把類之間的交互用線連起來(lái)表示這個(gè)關(guān)聯(lián)關(guān)系，靜態(tài)圖就完成了。
再來(lái)一個(gè)小提示：rose對(duì)中文的支持不好，因此上面的圖中類下面無(wú)法完整的顯示用中文寫的方法名，不過(guò)雙擊open sepcification對(duì)話框能正確顯示。相信大家注意到我所有貼上來(lái)的圖文字都是仿宋體而不是通常用的宋體，這是因?yàn)樵谧址?，宋體并沒(méi)有被限定為GB2312，所以當(dāng)把rose里的圖全選并拷貝到畫圖或WORD里時(shí)會(huì)文字會(huì)變成亂碼。大家一定也遇到過(guò)這種情況吧？一個(gè)小技巧就是用仿宋字體，預(yù)先設(shè)定字體或者全選（crtl+A會(huì)吧），再菜單format->font，選仿宋，你可以看到在仿宋字體后面帶了GB2312的字樣^_^。這樣就不用先屏拷再剪切，再拷貝到word里了。用word2003的朋友幸運(yùn)了，沒(méi)有這個(gè)問(wèn)題。
不可否認(rèn)，這個(gè)類圖很粗糙，但是一個(gè)系統(tǒng)原型已經(jīng)出來(lái)了。我們得到了可以完全實(shí)現(xiàn)需求的一些類，主要的類方法也有了。如果你想偷懶的話，直接把它轉(zhuǎn)換成設(shè)計(jì)類圖，把中文方法名改為英文，再把領(lǐng)域模型文檔（不記得了回頭查以前的文章）中提到的實(shí)體屬性填入，就已經(jīng)可以交付開發(fā)了。因?yàn)樾枨笠呀?jīng)實(shí)現(xiàn)了，類有了，方法有了，類屬性有了，別忘了在用例分析過(guò)程中已經(jīng)用靜態(tài)HTML做了系統(tǒng)原型，因此界面也有了。一切開發(fā)需要的東西都全了。比如我們用Strus+hibernate架構(gòu)，一個(gè)實(shí)體類就是一個(gè)POJO，一個(gè)控制類就是一個(gè)action，至于界面，在靜態(tài)HTML里填入java代碼改成JSP唄。如果你是一個(gè)開發(fā)人員，把這個(gè)圖給你，相信你也會(huì)覺(jué)得開發(fā)這個(gè)需求是很明確很簡(jiǎn)單的事吧？呵呵，成就真不小，可是仔細(xì)想想，我們甚至都沒(méi)有動(dòng)腦子啊！真是的，我們沒(méi)有動(dòng)腦子，居然就做了一個(gè)設(shè)計(jì)，恩!？可事實(shí)就是這樣，誰(shuí)說(shuō)分析設(shè)計(jì)就一定要?jiǎng)幽X子？不動(dòng)腦子就不能做設(shè)計(jì)嗎？就不能體現(xiàn)一個(gè)設(shè)計(jì)師的價(jià)值嗎？設(shè)計(jì)的目的是什么？漂亮？好看？采用了很多新技術(shù)？體現(xiàn)了設(shè)計(jì)師的高明手段和淵博知識(shí)？NONONO！設(shè)計(jì)的目的是為了實(shí)現(xiàn)需求不是嗎？如果需求就是這樣簡(jiǎn)單，我們已經(jīng)實(shí)現(xiàn)了，還能不動(dòng)腦子，干嘛做那沒(méi)事找抽型的，老板又不因此少付一分錢工資，能少干點(diǎn)活兒不好嗎？很多設(shè)計(jì)師因?yàn)槎脦讉€(gè)設(shè)計(jì)模式，總要想方設(shè)法弄上去，把簡(jiǎn)單的問(wèn)題弄復(fù)雜，好象只有這樣才能體現(xiàn)他的價(jià)值。愛(ài)因斯坦說(shuō)宇宙的法則是簡(jiǎn)潔的才是最美的，設(shè)計(jì)也是如此。設(shè)計(jì)師的真正價(jià)值，是用最簡(jiǎn)單，最好懂，最簡(jiǎn)潔的設(shè)計(jì)完成最復(fù)雜的要求，而不是相反！一項(xiàng)技術(shù)，正因?yàn)槟軌虮淮蠖鄶?shù)人掌握才能流行，否則就只能呆在實(shí)驗(yàn)室里，不是嗎？
話扯遠(yuǎn)了，忍不住又抨擊了一下過(guò)度設(shè)計(jì)，很不幸被抨擊的對(duì)象也包括以前的自己^_^。好吧好吧，我知道盡管你會(huì)同意我的話，你還是會(huì)在心里嘀咕，如果設(shè)計(jì)就只有這一點(diǎn)東西，連腦子都不用動(dòng)，那設(shè)計(jì)師也太好干了吧？分析模型如果就只有這一點(diǎn)內(nèi)容，還要專門寫個(gè)系列文章，這個(gè)作者也是個(gè)欺世盜名的吧？
呵呵，為了撫平你的失望，我告訴你。之所以我們沒(méi)動(dòng)腦子，是因?yàn)橄到y(tǒng)分析員們經(jīng)過(guò)用例分析系列中的卓越工作，給我們打下了如此堅(jiān)實(shí)的基礎(chǔ)，才使得我們的工作簡(jiǎn)單到了不用動(dòng)腦子的地步。你還得感謝UML用一套很好的方法，讓你可以輕而易舉的從需求轉(zhuǎn)化到類設(shè)計(jì)。你已經(jīng)站在巨人的肩膀上了，所以就一邊兒偷著樂(lè)吧。
樂(lè)完了還得回到現(xiàn)實(shí)。在很多情況下，事情并沒(méi)有這么簡(jiǎn)單。這個(gè)粗糙的分析模型雖然可以工作，但的確有很多可以優(yōu)化的地方。不用擔(dān)心你會(huì)因?yàn)樽隽艘环莺?jiǎn)單而不用動(dòng)腦子的工作而失去飯碗。因?yàn)橄乱黄?，我們將?huì)討論怎么樣，從哪些方面，以及如何依據(jù)補(bǔ)充規(guī)約，系統(tǒng)架構(gòu)以及維護(hù)要求等來(lái)優(yōu)化和調(diào)整這個(gè)模型。這下設(shè)計(jì)師有用武之地了，學(xué)習(xí)到的知識(shí)和積累的經(jīng)驗(yàn)要發(fā)揮作用了，失落的自我價(jià)值也能體現(xiàn)了。為了證明設(shè)計(jì)師不是混吃喝的并且保住飯碗，敬請(qǐng)期待下篇，分析模型的優(yōu)化和調(diào)整。
(3)--分析模型的調(diào)整和優(yōu)化
草圖代表了需求的實(shí)現(xiàn)，是一個(gè)細(xì)節(jié)的表露。接下來(lái)的優(yōu)化的調(diào)整，就以此為基礎(chǔ)。主要的輸入：草圖，系統(tǒng)架構(gòu)，業(yè)務(wù)規(guī)則，補(bǔ)充用例規(guī)約，系統(tǒng)原型。主要的輸出：調(diào)整后的分析模型，子系統(tǒng)，組件視圖和部署視圖（針對(duì)分布式應(yīng)用而言）。
這一篇拖了很長(zhǎng)時(shí)間，除了懶之外，另一個(gè)主要原因是一直找不到思路。想歸納一下自己的設(shè)計(jì)經(jīng)驗(yàn)，找到一個(gè)相對(duì)容易學(xué)習(xí)的辦法，結(jié)果總是不得要領(lǐng)。終于不得不承認(rèn)設(shè)計(jì)工作是一項(xiàng)創(chuàng)造性的工作，是沒(méi)有辦法用什么固定的流程，普適的方法來(lái)完成的。除了知識(shí)和經(jīng)驗(yàn)之外，個(gè)人的悟性恐怕也是影響設(shè)計(jì)好壞的原因之一。這篇文章寫得很費(fèi)勁，發(fā)現(xiàn)歸納出與具體需求無(wú)關(guān)的通用的一些方法真的很困難。相信對(duì)讀者來(lái)說(shuō)這篇恐怕是到目前為止最難懂的一篇了，因?yàn)樘嗟臇|西是只可意會(huì)不可言傳的。如果讓讀者覺(jué)得困難了，只能說(shuō)聲抱歉，我已經(jīng)盡力了。市面上所有有關(guān)設(shè)計(jì)的書目，無(wú)非是講UML，講OO原則，講設(shè)計(jì)模式..這些要不就是理論，要不就是方法論，要不就是針對(duì)某一問(wèn)題領(lǐng)域的解決方案。而當(dāng)我試圖總結(jié)普適的實(shí)踐方法時(shí)，卻發(fā)現(xiàn)非常的困難。我盡力而為，但仍免不了帶著個(gè)人色彩以及具體化。最后，只能希望通過(guò)講解一些關(guān)鍵點(diǎn)以及例子來(lái)給讀者提供一些思路，提供一些借鑒意義。至于一個(gè)通用的設(shè)計(jì)方法，我徹底放棄了，相信那是一個(gè)不可完成的任務(wù)?；蛘哒f(shuō)以我目前的能力，還不足以總結(jié)出這樣的方法。
書歸正傳，這一篇講如何調(diào)整和優(yōu)化上一篇的分析模型草圖。請(qǐng)注意我的用詞是調(diào)整和優(yōu)化，也就是說(shuō)，大部分工作都是基于已經(jīng)完成的工作的。細(xì)心的讀者可能會(huì)發(fā)現(xiàn)，我一直試圖說(shuō)明的是，需求，分析，設(shè)計(jì)這些工作并非那么神秘，而是有一個(gè)程式化的過(guò)程。而我正希望整個(gè)過(guò)程越程式化越好，也希望讀者都能找到適合自己組織和項(xiàng)目類型的程式。軟件工程，既謂工程，必能遵循而重復(fù)。只有這樣才能降低成本，壓縮進(jìn)度，減少溝通，提高質(zhì)量?？芍貜?fù)的才有意義。然而從現(xiàn)在開始，這個(gè)程式將不復(fù)存在，個(gè)人的作用開始登上舞臺(tái)了。
上一篇給出的草圖，基本上是不動(dòng)腦子的。照搬了業(yè)務(wù)實(shí)體，每個(gè)實(shí)體前加了一個(gè)控制類，只用了一個(gè)界面，整個(gè)過(guò)程只是把用例場(chǎng)景又重新模擬了一遍。有的讀者要問(wèn)，既然沒(méi)有任何的改變，又沒(méi)有分析的過(guò)程，那么做這個(gè)工作不是白費(fèi)力么？實(shí)際上不是的，雖然是一個(gè)很簡(jiǎn)單的草圖，但是我們已經(jīng)完成了80%的工作，同時(shí)也為后面的工作打下了非常好的基礎(chǔ)。這個(gè)草圖用最簡(jiǎn)單最快速的方式把用例場(chǎng)景轉(zhuǎn)化成邏輯場(chǎng)景，代表了從需求到設(shè)計(jì)的演變過(guò)程。再接下來(lái)的設(shè)計(jì)工作，只要不丟掉這個(gè)草圖中的信息，不論怎么設(shè)計(jì)都保證能夠滿足需求，將會(huì)省掉接下來(lái)大量的驗(yàn)證工作而放心的在設(shè)計(jì)上下功夫。從效果上來(lái)說(shuō)，草圖雖然不一定出現(xiàn)在最終的設(shè)計(jì)成果里，但它的意義是顯而易見(jiàn)的。
有讀者對(duì)草圖中的控制類用法提出不同意見(jiàn)。為什么要一個(gè)實(shí)體類一個(gè)控制類呢？全部用一個(gè)控制類不好嗎？可以的。實(shí)際上在繪制草圖的時(shí)候可以參考本組織所采用的框架來(lái)決定控制類的用法?？刂祁惖氖褂檬亲顬殪`活的一個(gè)用法，但由于是草圖的關(guān)系，草圖的目的是用最快速最簡(jiǎn)單的方法來(lái)把需求轉(zhuǎn)化到設(shè)計(jì)，再加上我個(gè)人覺(jué)得設(shè)計(jì)時(shí)由底向上比自頂向下要好（不容易遺露關(guān)鍵信息），也符合抽象是從特性向共性演變的特點(diǎn)，所以我個(gè)人習(xí)慣是先把控制類劃到最小，再透過(guò)框架來(lái)抽象，而不是一開始就考慮框架問(wèn)題。
筆者剛才說(shuō)了，草圖代表了需求的實(shí)現(xiàn)，是一個(gè)細(xì)節(jié)的表露。接下來(lái)的優(yōu)化的調(diào)整，就以此為基礎(chǔ)。主要的輸入：草圖，系統(tǒng)架構(gòu)，業(yè)務(wù)規(guī)則，補(bǔ)充用例規(guī)約，系統(tǒng)原型。主要的輸出：調(diào)整后的分析模型，子系統(tǒng)，組件視圖和部署視圖（針對(duì)分布式應(yīng)用而言）。
先說(shuō)說(shuō)分析模型的輸出
調(diào)整分析模型目的。設(shè)計(jì)是沒(méi)有標(biāo)準(zhǔn)答案的，這里筆者只能試圖通過(guò)例子說(shuō)明思路，不可能覆蓋所有問(wèn)題，需要讀者自行體會(huì)了?；蛘咛岢鰡?wèn)題，個(gè)別解答。調(diào)整分析模型的目的，是為了使之具有更合理的結(jié)構(gòu)，更有擴(kuò)展能力和適應(yīng)能力，能更清楚的表達(dá)邏輯。什么樣的結(jié)構(gòu)是好的？OO會(huì)說(shuō)，封裝度高，耦合度低，接口(邊界)清楚...然而這些都是原則問(wèn)題，筆者無(wú)法回答什么是好的結(jié)構(gòu)，因?yàn)樵诠P者看來(lái)所有結(jié)構(gòu)都有其優(yōu)劣，就象經(jīng)典的23個(gè)設(shè)計(jì)模式里同時(shí)有該模式的優(yōu)點(diǎn)與缺陷一樣。有趣的是，筆者發(fā)現(xiàn)能量守恒定律真的是普適真理，同樣適合軟件，封裝度越高，耦合度越低的代價(jià)通常是由結(jié)構(gòu)的復(fù)雜度來(lái)替換程序的復(fù)雜度的。比如開發(fā)框架，例如Spring，其強(qiáng)大的擴(kuò)展能力和極低的耦合度是由復(fù)雜的AOP和IOC模式為代價(jià)的，其結(jié)果是完整的程序邏輯被分截成很多不連續(xù)的片段，對(duì)很熟悉AOP和IOC的程序員可能不是什么問(wèn)題，對(duì)經(jīng)驗(yàn)不多的，真是難以理解了。實(shí)際上，要做的事情不會(huì)因?yàn)椴捎昧四硞€(gè)結(jié)構(gòu)而消失，只不過(guò)從程序中轉(zhuǎn)化到配置文檔或部署文檔而已。因此關(guān)于什么是好的結(jié)構(gòu)這個(gè)問(wèn)題，請(qǐng)?jiān)徆P者無(wú)法給出答案了，只有最適合的，沒(méi)有最好的。只想提醒一點(diǎn)，受能量守恒定律的制約，謹(jǐn)防過(guò)度設(shè)計(jì)，還是那句話，要做的事情不會(huì)因?yàn)椴捎昧四硞€(gè)結(jié)構(gòu)而消失，它只是被轉(zhuǎn)化了。因此請(qǐng)根據(jù)業(yè)務(wù)規(guī)則，補(bǔ)充規(guī)約中的要求，參考項(xiàng)目周期，成本，開發(fā)人員水平等等因素，評(píng)估結(jié)構(gòu)調(diào)整的得失，得出最平衡的方案。
劃分子系統(tǒng)。在本BLOG中曾經(jīng)與網(wǎng)友rwyx討論過(guò)子系統(tǒng)劃分的問(wèn)題，詳細(xì)內(nèi)容可以去看以武會(huì)友欄目《系統(tǒng)分析，業(yè)務(wù)建模，UML，RUP相關(guān)》中關(guān)于UC矩陣的討論，由于內(nèi)容比較多，這里只例舉筆者的觀點(diǎn)和方法：我不認(rèn)為子系統(tǒng)應(yīng)該是功能性的，這是UC關(guān)注的點(diǎn)，我認(rèn)為是內(nèi)在邏輯性的，所以只有在內(nèi)部邏輯得以明確，也就是分析模型出來(lái)之后，才可能決定子系統(tǒng)。劃分子系統(tǒng)依據(jù)于分析模型的結(jié)果。我的做法是先把分析模型做出來(lái)，然后嘗試將分析模型中的對(duì)象放入不同的包（這里的確有經(jīng)驗(yàn)的成份，并不是一個(gè)個(gè)瞎試的，最初的依據(jù)還是來(lái)自業(yè)務(wù)用例，把一個(gè)業(yè)務(wù)用例當(dāng)成一個(gè)包，在此基礎(chǔ)上再改進(jìn)）。這時(shí)會(huì)發(fā)現(xiàn)一些有趣的內(nèi)容，比如，某個(gè)control類有好幾個(gè)包都需要，比如，某個(gè)包中的某個(gè)Entity類被多達(dá)七八個(gè)其它包所引用，比如，某個(gè)bandage類要與分散在七八個(gè)包里的control類打交道...為了解決這些問(wèn)題，嘗試將分析類移到別的包，合并一些包，分揀出公有元素形成新包，也就是所謂的LIB等等。最理想的情況，那些分析類的所有依賴都在局限一個(gè)包里，或只與LIB有關(guān)，或僅通過(guò)一個(gè)bandage與其它包交互....到這時(shí)就形成了子系統(tǒng)的雛形了，剩下的工作，就是參考UI的要求，決定將哪些包合成一個(gè)更高層次的包，這個(gè)包包含了UI要求，由于基礎(chǔ)來(lái)源于業(yè)務(wù)用例，基本上也會(huì)符合業(yè)務(wù)習(xí)慣要求，這個(gè)包就是子系統(tǒng)，取個(gè)合適的名字就OK了。
總結(jié)一下，大部分子系統(tǒng)劃分是自頂向下的方法，我用的是自底向上的方法。如果構(gòu)成底部組件級(jí)別的包已經(jīng)耦合度很低了，再用它們來(lái)組合子系統(tǒng)就自由得多，盡量參考UI要求就是了，這是為什么在草圖中我把控制類分得很細(xì)的原因。不過(guò)得提醒讀者，通過(guò)分析模型劃分子系統(tǒng)的方法是筆者自己獨(dú)創(chuàng)的，尚未有其它文獻(xiàn)資料的支持，僅供參考，慎用^_^
組件視圖。將聯(lián)系緊密，共同向外提供某種服務(wù)的分析類組合起來(lái)，形成一個(gè)組件。這個(gè)組件將有可能是被復(fù)用的。但組件視圖不一定是需要提取的，筆者一般使用組件視圖情形是在分布式，或與外部系統(tǒng)有交互的情況下才做。筆者對(duì)組件視圖的使用是基于SOA思想的，一個(gè)組件就是一個(gè)WebService模塊，這個(gè)模塊有被復(fù)用的要求，有被獨(dú)立部署的要求，如果沒(méi)有這樣的業(yè)務(wù)需求，就系統(tǒng)內(nèi)部而言，筆者認(rèn)為并無(wú)組件視圖的必要，包圖就足夠了。并且Rose里的組件視圖實(shí)在是...難用。那組件是如何形成的呢？筆者做組件是通過(guò)觀察邊界類而來(lái)，并且這個(gè)邊界的兩邊都是系統(tǒng)(不同于界面有一邊是人)。觀察這個(gè)邊界兩邊系統(tǒng)的交互情況，如果交互很頻繁，并且涉及雙方的多個(gè)對(duì)象，這時(shí)就要考慮組件了。用一個(gè)邏輯的組件名字，將內(nèi)部被影響到的對(duì)象組合起來(lái)，透過(guò)這個(gè)組件來(lái)與對(duì)方系統(tǒng)交互。同時(shí)維護(hù)交互目的的單純性（比如不要把取錢和開戶放在一個(gè)組件里，這是兩個(gè)不同的目的），一類目的一個(gè)組件。如果是分布式系統(tǒng)，還得考慮組件涉及到的對(duì)象可以被獨(dú)立部署問(wèn)題。提醒讀者注意，筆者對(duì)組件視圖的使用方式和理解也與一般UML教科書不同，目前也未有其它文獻(xiàn)支持，僅供參考
部署視圖部署視圖劃分出系統(tǒng)的網(wǎng)絡(luò)拓?fù)涔?jié)點(diǎn)情況。不過(guò)老實(shí)說(shuō)我覺(jué)得Rose中這個(gè)視圖不是太有效的。寧愿選擇Visio來(lái)繪制節(jié)點(diǎn)圖。部署視圖筆者不多說(shuō)，因?yàn)檎嬲枰霾渴鹨晥D的一般是分布式應(yīng)用，一般也都需要企業(yè)級(jí)應(yīng)用服務(wù)器支持，如Weblogic,Webshpere等，購(gòu)買了這些產(chǎn)品的項(xiàng)目，自然會(huì)同時(shí)有擁有這些大公司的技術(shù)支持，直接請(qǐng)他們提供解決方案好了。
接下說(shuō)說(shuō)調(diào)整分析模型的關(guān)鍵點(diǎn)
以上是分析模型在調(diào)整過(guò)程中可能需要產(chǎn)出的一些內(nèi)容。在這之前的過(guò)程都是程式化的，而今天的內(nèi)容，則需要個(gè)人的經(jīng)驗(yàn)和能力了。下面筆者盡量說(shuō)明一些調(diào)整的關(guān)鍵點(diǎn)。
關(guān)鍵點(diǎn)之一：業(yè)務(wù)規(guī)則，尤其是來(lái)自補(bǔ)充用例規(guī)約中的全局規(guī)則
業(yè)務(wù)規(guī)則需要被評(píng)估，它們是普遍存在的？還是局部存在的？所謂普遍，是指這個(gè)規(guī)則在大多數(shù)情況下都會(huì)起作用。所謂局部，是指這個(gè)規(guī)則只在某種情形下才起作用。對(duì)于普遍的規(guī)則，需要在分析模型甚至架構(gòu)上處理，而局部規(guī)則可以由后續(xù)的設(shè)計(jì)模型處理。普遍規(guī)則的例子：actor所有操作都應(yīng)該被記錄；actor存取資源時(shí)應(yīng)當(dāng)被授權(quán)；局部規(guī)則的例子：actor在下一次借書前沒(méi)有逾期未歸還的書，否則不能借閱。前兩個(gè)普遍規(guī)則例子將反應(yīng)到本篇的分析模型圖里。后一個(gè)局部規(guī)則例子要到設(shè)計(jì)模型時(shí)再給出示例圖。
也應(yīng)當(dāng)關(guān)注那些復(fù)雜的，可能將來(lái)會(huì)經(jīng)常變化的那些規(guī)則。如果這種變化的可能是普遍存在的，應(yīng)當(dāng)在分析模型中給予關(guān)注，否則，可由設(shè)計(jì)模型來(lái)處理。例如，不論是借書的條件，可供查詢圖書的條件，借閱證有效條件....都是很有可能變化的，那么，可能需要在草圖的邊界類和控制類之間加入一個(gè)Factory，來(lái)保證一定的規(guī)則替換能力。但如果只有借書條件可能變化，這個(gè)Factory只需要加在借書控制器上，由設(shè)計(jì)模型處理就行了。
關(guān)鍵點(diǎn)之二：結(jié)構(gòu)化和耦合度調(diào)整
不好的結(jié)構(gòu)是網(wǎng)狀結(jié)構(gòu)，對(duì)象之間互相依賴。這樣的結(jié)構(gòu)藕合度高，擴(kuò)展能力和適應(yīng)性就差，改動(dòng)程序時(shí)經(jīng)常牽一發(fā)而動(dòng)全身。例如草圖中的圖書、借閱證、借書藍(lán)和借閱定單。好的結(jié)構(gòu)是樹狀結(jié)構(gòu)，對(duì)象之間的依賴是單向的，不交叉的。調(diào)整后的分析類圖表示了這一轉(zhuǎn)變。當(dāng)然有時(shí)候并不是能夠完全做到這一點(diǎn)，盡量做到，并防止過(guò)度設(shè)計(jì)。
關(guān)鍵點(diǎn)之三：交互集中點(diǎn)調(diào)整
若某一個(gè)對(duì)象的交互非常多，它與很多個(gè)對(duì)象都在交互，這個(gè)對(duì)象就是問(wèn)題多發(fā)地帶了！也就是所謂的critical chain，瓶頸...它應(yīng)當(dāng)被調(diào)整。由于筆者所用的這個(gè)例子較為簡(jiǎn)單，為了延續(xù)一直以來(lái)的示例，唯一可以被看作是Critical chain的就是界面了，雖然用界面來(lái)講這個(gè)例子不太合適，但思路是可以借鑒的。調(diào)整交互集中問(wèn)題的方法有，重新規(guī)劃職責(zé)或增加冗余，或增加中間調(diào)合層等等....這個(gè)結(jié)果可參看后面的分析模型圖。
接下來(lái)，是根據(jù)上面的講述產(chǎn)筆者提供的一些例子。這些例子只可意會(huì)不可言傳的，很難說(shuō)明，能否理解就看讀者個(gè)人在OO設(shè)計(jì)上的經(jīng)驗(yàn)了。
分析模型原圖:
一個(gè)組件圖的例子，網(wǎng)上交費(fèi)業(yè)務(wù)的組件視圖
再次提醒讀者，這些例子只是針對(duì)某個(gè)問(wèn)題的解決方案之一，不可避免的帶著筆者的個(gè)人經(jīng)驗(yàn)色彩。這些解決方案不是真理，沒(méi)有高下，甚至沒(méi)有對(duì)錯(cuò)。目的只是為了提供思路，而非模板和教條。熟悉設(shè)計(jì)模式的讀者可以從設(shè)計(jì)模式中找到很多解決這類問(wèn)題的模式。讀者不應(yīng)該拘泥于研究筆者這些解決方案，這些方案僅是為了配合說(shuō)明調(diào)整分析模型關(guān)鍵點(diǎn)而提供的示例而已，重要的是理解那幾個(gè)關(guān)鍵點(diǎn)。
這一篇當(dāng)中，筆者講述了一些調(diào)整分析模型的要點(diǎn)，并舉了幾個(gè)例子。筆者不得不說(shuō)的是，寫這篇文章真的花費(fèi)不少力氣。設(shè)計(jì)是一種創(chuàng)造性工作，隨環(huán)境而變，隨要求而變，隨設(shè)計(jì)師而變...要總結(jié)出一套方法來(lái)實(shí)在是困難。筆者只能就自己的經(jīng)驗(yàn)寫一些要點(diǎn)。誠(chéng)然，這些例子不足以解決所有問(wèn)題。目前估計(jì)沒(méi)人能做到"統(tǒng)一設(shè)計(jì)方法"，真到了那一天，軟件就是工業(yè)化生產(chǎn)了。筆者希望通過(guò)這幾個(gè)要點(diǎn)和例子，能夠激發(fā)讀者的思路，舉一反三，而不是照葫蘆畫瓢（我相信想畫也畫不出來(lái)）。今天這篇同時(shí)也揭示了分析模型到底要做些什么。讀者也可以體會(huì)一下，調(diào)整分析模型與原來(lái)沒(méi)有分析模型時(shí)調(diào)整設(shè)計(jì)類相比哪個(gè)更容易些，工作量更小些。
接下來(lái)，要討論如何轉(zhuǎn)化到設(shè)計(jì)類的問(wèn)題了。但是設(shè)計(jì)類是實(shí)現(xiàn)類，它必然與軟件框架，系統(tǒng)架構(gòu)，實(shí)現(xiàn)語(yǔ)言息息相關(guān)。所以下一篇將討論軟件框架和系統(tǒng)架構(gòu)在UML里的表現(xiàn)方形式，再下一篇才討論分析類到設(shè)計(jì)類的轉(zhuǎn)化問(wèn)題。敬請(qǐng)期待。
|
