对象建模技术
連載：對象建模起步之五 健壯性分析
今天向大家介紹ICONIX建模方法中的重要內容：健壯性分析。通過上兩次連載中介紹的工作，我們已經有了一個成型的層次類模型，這是基于對需求的分析獲得的一個整體概念。到目前為止，我們所做的工作目的是了解這個系統，即所謂分析階段，那么如何從分析階段過渡到設計階段呢？健壯性分析登場了，這是一門十分簡單但非常有效的技術，通過簡單的30分鐘學習大多數設計師都能很快地掌握。
健壯性分析不是UML固有的一部分，它包含在“Rational的UML特殊對象過程擴展”中，也不是正規的OO設計方法，因此大多數的UML書籍中根本沒有提到它（現在你有福了，本篇文章將詳細介紹這項技術，為此我還專門去找了一些參考資料來，以免說錯了鬧笑話）。
健壯性分析是將參與用例中的對象集（層次類模型也是脫胎于用例的）進行歸類，然后分析對象間關系的方法。和MVC有點類似，健壯性分析將對象（這里不稱為類，因為屬于動態分析，參與者都是類的實例）分成三類：
有四個規則對應三類對象間的交互：
好了，讓我們啟動Rose，做個圖給大家加強認識
健壯性圖分析規則
通過繪制健壯性分析，可以很容易的獲得幾個關鍵性的內容
- 正常性
- 完整性
- 再發現對象
- 初步設計
下面是我對猜數游戲建立的健壯性分析圖：
通過對健壯性分析圖的分析，可以做出一次游戲交互的順序圖：
最后，健壯性分析是一個工具，用完了以后無需保留它，它在以后的設計中并沒有多大用處。
連載：對象建模起步之六 完善設計
原本連載準備寫到10篇左右，可是講完了健壯性分析以后就沒有多少理論可講了，剩下都是一些技巧性的工作，前面已經說過這個連載不講述UML，如果讀者需要獲得UML方面的知識可以參考其它資料。我在這一篇把剩下來的部分做個大略介紹，這個連載就此告一段落了。這里沒有介紹用例建模方面的內容，大半原因是這方面自成體系，以后有空我會陸續向大家介紹。
模型的初步設計在完成健壯性分析以后已經完成，設計者手中已經有了一個初步的類體系，如果讀者有UML基礎，很容易利用UML所提供的各種工具來完善設計。
如果發現所擁有的類圖不完整，應該繼續使用健壯性分析來研究它，持續發現類，直到整個體系完整。
在類圖已經完整地情況下，應該為類分配方法和屬性了，這是設計的關鍵一步。由于我們使用了快速原型法，在很多地方可以使用逆向工程來減輕工作量（邊界類）。控制器和實體的屬性（Attribute）與行為（Method），則可以通過順序圖來分析，如果讀者熟悉CRC卡片，那也是獲得行為的好方法。
順序圖可以直接轉換成協作圖，我個人通常不怎么使用協作圖，但是如果它對你有用，也是不錯的。在Rose里面只需要按一下F5鍵就可以從順序圖得到協作圖。
在為每個類分配完方法和屬性后，就是考慮如何實現的問題了，建模的工作已經完成。
其實建模沒什么難的，只要記住時時檢查需求，不要讓設計失控就行，你一定會成功的。
對象建模起步連載完。（有點虎頭蛇尾，沒辦法了，后面的部分跟建模方法基本沒什么相關，全是如何畫圖方面的技巧，我即使寫一大堆也不夠市面上那些書寫的好）
多謝大家的支持，向所有支持我的朋友表示感謝。
連載：對象建模起步之四 域建模之二 分析層次類
在上一次連載中，我們已經初步對問題域進行了分析，獲得一個類名的列表，接下來的工作則是繪制這個分析層次類。很顯然的，拿到類的列表，當然應該做Class Dragram，這里也不需要使用特定的工具，任何矢量繪圖工具都可以完成這個工作。請大家注意，這個階段制作的類圖，并不是最終要實現的類圖，而是一個分析類圖，它的功能是幫助設計師理清系統的關系，將需求文稿中錯綜復雜的關系整理成一個脈絡清晰的完整系統。
請原諒我上一章使用了一個不太恰當的例子，這個游戲過于簡單，只有一個參與者，只有一種活動，要是畫用例的話就只有孤零零的一個圈圈加一個小人。我在這里列出的問題純粹是為了闡述分析思路而提出問題，大家日后做項目的時候千萬不要像我這么故意把事情搞復雜。
閑話少說，先啟動ROSE制作Class Dragram，一開始應該是這個樣子的
現在我們要用我們的專業知識來歸納類了。很明顯，錯誤信息和成功信息需要一個基類，玩家答案和正確答案也是一樣。于是，類圖變成了這個樣子：
請大家再次原諒我故意把系統搞得這么復雜，其實對于這個簡單案例來說根本沒有必要做這種工作，我只是要說明在發現類以后應該要對類進行歸納處理工作。實際項目中的類一定是非常多的，分析它們之間的關系十分重要，這是讓設計師能夠把握全局的重要方法。
接下來則是分析類之間的關聯，同樣從需求文檔和問題域中尋找線索。
“游戲引擎應該準備一個正確答案”，沒錯，游戲引擎肯定要用到正確答案的。
做到現在問題來了，很明顯這個游戲的核心其實就是一個比較操作，那么這個操作應該放到哪里去處理呢？（噢，其實這不應該是在這時候考慮的事，但是由于項目比較簡單，我也就不亦步亦趨的照著順序來了）。不知道讀者知不知道MVC？也許有人搞過，但是是否知道MVC的分析方法？如果知道看后面的內容十分容易，如果不知道就要仔細看后兩章的內容了。其實在OO設計中一早就有和MVC類似的東西，那就是健壯性分析，和MVC類似，層次類也有三個歸類：邊界、實體、控制器。現在我把類做一個簡單分類：
這里只有實體和邊界類，還沒有控制器，所以我需要引入一些Helper類來補充這個層次類圖，不過今天到此為止，手累了。
另外，從本章開始起，我這個連載的題目要改一改，由于現在和以后將要加入其他技術，同時也會裁剪掉一些ICONIX的內容，不能再叫ICONIX了，以免真正搞ICONIX的人來找我麻煩，直接叫對象建模好了。
模型、UML、快速原型和ICONIX
廢話不多說，要想搞RUP也好ICONIX也好，需要對模型、UML有個大致的了解。什么是模型呢？說穿了就是對具體事物的抽象。比如你去買樓，不管售樓小姐給你說的如何天花亂墜，在沒有看過現樓之前你心里還是沒譜，只有你親自到了房子里面看過，你才知道到底是個什么樣子。可是你沒有那么多時間，還有可能開發商根本還沒有蓋好這個房子，這時候售樓小姐就會帶你到沙盤面前，指著一個房屋模型說：這就是你要買的房子。
好了，雖然現在你沒有去看過現樓，不過看到這個模型，應該對要買的樓也有了一個大概的認識，拋開奸商騙人的因素以外，以后你看到的現樓根眼前這個模型在結構上是一樣的。當然房屋模型并不能表現出所有的特征，比如自來水管的走向和電燈開關在哪，雖然這些因素對居住品質的影響也很大，但是這并不是你買樓時首要的考慮。同時開發商一般會準備多種模型可供你參觀，比如小區的整體模型和房型模型，透過小區模型你可以看到你要買的房子在小區的哪個部分，周圍綠化情況，交通之類的大致情況，而透過房型模型可以看出房間布局、客廳大小等等相對具體的情況。當你看完所有的模型后，基本上心里也有了底，大部分的人也就依據這個情況決定是否購買這套房子。
類比房屋模型，軟件模型（一般我們稱系統模型）所起到的功能基本也差不多，在UML出現以前就有很多種建模方法出現了（ICONIX就是其中之一），UML最大的貢獻是統一了建模符號。和房屋模型不同，軟件是個虛擬東西（這里是指軟件的本質），沒辦法用硬紙殼做個模型給你看，只能采用折中的辦法使用圖形和符號來盡量展示軟件的特型。以前眾多的方法都是自行設計的圖形和符號，UML來了個一鍋端，統統改用UML符號來表示，這就好比用阿拉伯數字來表示數字一樣，123你看得懂，老外也看得懂，統一的標準保證了通用性。
所以，UML是一種標準的建模語言（為什么說是語言呢？這根把數學符號稱作數學語言一樣的道理）。
現在來講快速原型。上面講了UML，只是一個大概，不過在這里只需要和數學符號類比一下就行了。數學家之間用數學符號交流是沒有問題的，大家都看得懂。UML在軟件專家之間交流也是沒有問題的，大家也都看得懂。可是這個系統的參與者并不是所有的人都是專家，還有很多人看不懂UML模型。你已經做了大量的設計，花了大量的時間制作UserCase、Class Diagram、Action Stream等等，站在用戶面前一邊演示一邊長篇大論不厭其煩的介紹系統的特點，我想結果大多數情況只有兩種：一種是用戶完全震撼，口里念念有詞——牛！一種是完全迷惑，一邊搖頭一邊對你說“你說的那些功能到底是什么樣子的啊？”。
嗯，問題來了，到底是什么樣子，這才是用戶關心的問題。你畫的一大堆紅線綠線、三角方框圓圈，用戶根本不感興趣，他也不知道那到底是什么（當然他看了心里也許會說果然夠專業，果然夠復雜，說不定對你立刻產生崇拜心理）。如何回答這個問題呢？快速原型就出場了。
我設計軟件，首先拿一張白紙，從中間筆直畫一條豎線，把它分為兩個部分，左邊是計算機自動處理的部分，右邊是用戶，中間那條線就是分界線，專業一點叫自動化邊界。我們使用電腦，都是希望它能幫我們自動處理一些工作，否則這電腦就沒用了。一個軟件的功能，說白了也就是自動處理工作的能力。于是我羅列了一大堆系統要實現的功能列在左邊（噢，這里我強調，能夠這么做的前提是做足了需求分析），用戶需要做的工作放在右邊。很好，現在我已經明確了這個系統大致的情況，用戶需要完成右邊的工作，就需要透過中間的自動化邊界調用左邊的功能（或功能的組合），除此之外別無選擇。那么也就是說只要能夠向用戶展現出自動化邊界，也就等于展現出整個系統（因為左邊對用戶來說是完全封閉的）
現在我就來開發一個（或者幾個，總之要包含所有的內容）小程序，它包含了上述所有用戶控制項，用戶運行這個程序就跟進后運行真正的系統一樣（只是它什么也不會干，只是擺擺樣子而已）。現在拿給用戶演示：不錯吧？很好，就是這樣的。那我們就按這個做了？OK，就這樣，不過有些地方需要改一下。沒問題，你看看那些地方要改的列出來給我吧......
明白什么是快速原型了吧？
至于ICONIX，那就是UML+快速原型了。當然ICONIX包含的內容遠不止這么簡單，不過基本論調就差不多了。注意哦，重點不在快速原型，在UML，在UserCase，別搞錯了方向。
連載：ICONIX 統一建模起步之二 在開始進入設計之前
抱歉，上個星期太忙，練車又淋了雨，感了點小冒，耽誤了些時間，因此這篇來的比較遲。
我寫這個連載的初衷，不過是想向大家介紹介紹ICONIX建模技術而已，但鄙人有個毛病，念頭一起就會像射線進入威爾遜云室那樣，四散開了去，以至于主線是什么不太容易辨認。好在都是cndev的老朋友，也不是正經八百的寫作出書，大家包涵著點就好，呵呵，哈哈。。。
像今天我要說的，其實根ICONIX沒什么關系，我是想用這一段寫寫自己設計、建模的泛體會（泛者，一般也，廣泛也，抽象也，反正不大容易說清楚）。
ICONIX也好，RUP也好，都是一套規則，諸位如果看過有關RUP的書，大多都講到軟件生命周期、開發周期什么什么周期的，然后講述步驟，先怎么怎么樣，然后怎么怎么樣，似乎一切井井有條，未免竊竊心喜：也沒什么難的，只要照著做，俺也能成功。等到動手來干點什么，猛然間發現千頭萬緒，無法下手，根本無法照著書里介紹的一步一步往下做。
這是為何？答案恐怕翻遍整個書店也找不到，原因其實很簡單：它們都只告訴了你做法，卻沒有告訴你想法。
做和想，是兩個不同的行為，通常來說什么樣的想法決定什么樣的做法，但是什么樣的做法卻不一定要有什么樣的想法。愚夫愚婦，見人念佛，學而時習之，表面上看上去像模像樣，實際效果大大不同，得道的通常都是高僧，大部分職業和尚除了能混碗飯吃以外沒什么大用。
現在我們拋開ICONIX、RUP中和建模無關的東西，單論建模設計，可以明確地說：這兩者在做法上沒有任何不同，不同的只是想法，即所謂哲學思想不同。用個武俠小說的說法，ICONIX是自外而內，乃是降龍十八掌，RUP則自內而外，乃是一陽指。ICONIX一開始就是以用戶界面為導向來驅動整個工程，這和RUP有很大不同（抱歉，這里我說不出RUP的設計思想，因為我對RUP沒多大研究，只是泛泛看了看而已，只能肯定RUP不是UI驅動的）。鑒于這個特色，ICONIX特別適合RAD開發者，你用Delphi、VB什么的搞個UI驅動多容易，要讓C++搞UI驅動那不是強人所難嘛。
回到建模和UML來說，ICONIX和RUP兩者其實根本是一樣的，ICONIX用到的Use Case、Class Diagram之類的東西不會和RUP有什么不同，設計方法也沒有差異。所以這方面的內容我基本不會講，上街隨便買本書大堆大堆都是。我以后的部分，大多數都是ICONIX特有的想法和做法。
讓我再稍微跑一下題，談談UML的問題。很多書籍資料都介紹了如何使用UML，什么步驟什么規則之類的，我要提醒一下：設計沒有規則，建模沒有步驟。噢，千萬不要誤會我的意思，我不是要天馬行空的胡亂設計，而是說不要受制于那些條條框框。比如說畫畫，來畫一株梅花，沒人規定要先畫什么再畫什么，先畫枝干可以，先畫花瓣也可以，只要最后畫出來別人看得出來是一株梅花就行。UML也一樣，先設計Class Diagram也可以，先設計Activity Diagram也可以。
不管是畫畫還是UML，都有一個前提，就是胸有成竹（這里用這個成語的本意）。畫梅花的心里早就有了梅花的形象，而一個方案到需要進行UML設計的時候大致是個什么樣子，設計者心中也早就有數。所以別指望著UML能無中生有，如果在準備做UML之前還沒有成型的思路，那還是先放一放的好。
好了，今天的胡扯到此告一段落了，接下來我會逐步講述ICONIX建模的過程，請注意，這些過程除去自然形成的次序外，所有的過程都是并行的。請大家牢記設計的完整性，軟件設計和編程是完全不同的，它既不是自頂向下，也不是自底向上，而是一個逐步求精的過程，一開始它就應該是全面的，就好像IE顯示GIF圖片一樣，從模糊到清晰，但從一開始你就能看到全貌，切記切記，不可偏頗。
最后，這些都是我個人見解，如有雷同實屬巧合，歡迎持不同見解者加入討論。
最最后，下章預告：域建模和發現類。
連載：ICONIX 統一建模起步之三 域建模之一 發現類連載：ICONIX 統一建模起步之三 域建模之一 發現類
歡迎大家回到我的連載，從這一期開始，我們正式進入ICONIX的世界。閑話少說，進入正題。
什么是域建模呢？我們設計一個系統，總是希望它能解決一些問題，這些問題總是映射到現實問題和概念。很明顯我們的系統依賴于這些問題，對這些問題進行歸納、分析的過程就是域建模（這個域，指的就是問題域）。
好了，講理論大家要昏昏欲睡，我這個小小的連載也沒辦法把所有的概念說的一清二楚，要是有興趣的話可以打電話跟我暢談（前提是不許打手機），現在我來用一個實際的例子講述域建模。
用個比較簡單的例子吧，本來昨天我是想用HelloWorld來的，可是它實在太簡單了，不能說明問題，考慮再三，我使用一個猜數游戲來說明問題。這個游戲相信學過編程語言的都應該很熟悉了：輸入一個數，如果猜中了顯示“你好棒啊”然后結束，如果不對，系統告訴你是太大還是太小，然后重新讓你輸入，直到猜中為止。
現在請拿一張白紙，我們開始歸納問題。
+--------------------------------------------+
| 系統應該準備一個正確答案 |
| |
| 玩家可以輸入一個答案 |
| |
| 系統應該比較玩家輸入的答案和正確答案 |
| |
| 系統應該顯示玩家每次輸入的結果 |
+--------------------------------------------+
遺憾我這個例子還是太過于簡單，不過簡單也有簡單的好處，從這個簡單的例子可以看出歸納問題的基本要點。
第一是不要涉及內部的流程，別出現“如果輸入不正確，就怎么怎么樣”的句子，這些并不是正確的問題，正確的問題必須明確的，清晰的，如果可能的話全部按照“什么可以干什么”的格式來寫。
第二是不要一開始就進入細節（抱歉，我這個例子例外，它實在是太簡單了），包涵太多細節的問題將會是一個長長的清單，這種清單根本沒什么用。盡量從最高一層分析，但也不要簡單到“用戶可以玩游戲”這種籠統的問題。總之一個原則是全面、清晰、明確。要做好問題域分析完全取決于設計師的水平與能力，這就不是可以簡單的看看書能達到的了。
好了，現在我們有了一個系統問題域的清單，可以進行下一步工作：發現類。
把問題清單中的名詞都提出來，得到一個名詞列表，這就是類的來源（不過不忙，這只是初步過程）
+----------------+
| 系統 |
| 玩家 |
| 正確答案 |
| 答案 |
| 游戲結果 |
+----------------+
不是所有的名詞都能作為類的，接下來需要進行篩選。
玩家是參與者，應該放到用例圖上去
系統太籠統，不能成為一個對象的名稱
答案和正確答案容易混淆，但稱為輸入答案又容易被誤解成一個動作，干脆叫做玩家答案
結果不明確，察看前面的需求，應該分解成錯誤信息和完成信息
篩選完畢后，得到下面一個名詞列表：
+----------------+
| 正確答案 |
| 玩家答案 |
| 錯誤信息 |
| 完成信息 |
+----------------+
這個列表缺少了系統，顯得太單薄，回過頭再仔細察看需求，應該引入一個游戲引擎，由它來充當調度者。
+----------------+
| 游戲引擎 |
| 正確答案 |
| 玩家答案 |
| 錯誤信息 |
| 完成信息 |
+----------------+
同時修改前面的問題域，現在系統已經明確是一個游戲引擎。這種替換當然是一種理想情況，通常都會發生分解和關聯，那時候需要擴充問題域，有時候還需要建立新的問題域。
+--------------------------------------------+
| 游戲引擎應該準備一個正確答案 |
| |
| 玩家可以輸入一個答案 |
| |
| 游戲引擎應該比較玩家答案和正確答案 |
| |
| 游戲引擎應該顯示玩家每次輸入的結果 |
+--------------------------------------------+
現在可以用Rose來制作Class Diagram了，同時可以用RAD工具來搞一個小小的GUI來看看效果，發現類工作到此告一段落。不過問題域分析還沒完，類與類之間的關系還沒有歸納，當然，那是下一段要講的事情了。
連載：ICONIX統一對象建模起步之一 面向對象方法簡介連載：ICONIX統一對象建模起步之一 面向對象方法簡介
抽空寫的，資料也許不全，有什么錯誤請不吝指教。
很不幸的，IT是一個隨時隨地都能冒出一大堆新概念和新詞匯的領域，在我寫第一個程序的時候恐怕我做夢也沒想到現在會發展成這個樣子。在大學我學的是結構化程序設計，我想在93年我和我的同學壓根就沒聽說過面向對象這個詞，很多同學都是出了校門才開始自學面向對象程序設計的。我起步稍微早一點，二年級讀了一本Turbo Pascal 5.5面向對象程序設計的書（還記得是學苑出版社出的）開始了面向對象程序設計的探索。然而那時候我還沒有聽說過什么設計方法，一切都是隨意的，沒有人指導我應該如何設計。
也就是在1993年，面向對象的方法領域在經過三年的發展后，已經進入成熟期，由當初的混亂逐步形成三個主要派別。他們分別是以數據為中心的方法、以腳本為中心的方法和結構化方法。
以數據為中心的方法基于技術，這些方法諸如實體關系圖、數據流圖以及狀態轉換圖，這些方法試圖通過使用數據為界限來分解系統。（學過數據結構吧，有點像，設計程序先設計數據，然后通過分析數據關系，最后來實現程序，這種方法一般是DBA用得最多的）
結構化方法則基于代碼，首先以OO編程開始，然后展開。結構化方法首先定義需要哪些程序，每個程序應該實現哪些功能，然后按照某種方式把程序組織成一張圖，稱為結構圖。（結構化方法實際上就是按功能分解系統，比如設計一個工資系統，可以按功能劃分成錄入系統、打印系統、查詢系統等等，這大約是傳統程序員用得最多的一種方法）
以腳本為中心就有點不容易說清楚了，簡單的說就是使用腳本來進行設計，像比較出名的OBA方法和Alger/Goldstein方法都屬于此類。以腳本為中心的方法使用界限來劃分系統。（沒辦法，我沒搞過OBA，實在無法用類比的方法說清楚，有經驗的朋友幫忙補充一下）
1993年最佳建模方法當屬Rumbaugh的對象建模技術(Object Modeling Technique,OMT)、Jacobson的面向對象軟件工程(Object-Oriented Software Engineering,OOSE)和Booch的方法（通常就叫Booch方法）。這三個大牛人在93年一起把這三種方法合成成一個統一的方法。以后三友一起去了Rational公司，開發出UML和RUP統一過程，成為面向對象設計領域的領先標志。
噢，說了一大堆，卻說到UML和RUP去了，還是回到ICONIX來吧。其實ICONIX也是三友發明的，在他們三個沒去Rational之前一直是由ICONIX來闡述Booch/Rumbaugh/Jacobson混合方法的（那時還沒有UML和RUP）。要是我說的話，ICONIX和RUP并沒有本質上的區別（其實都是Booch寫的），要說區別主要是態度上。RUP在操作上離地十萬八千里，太學術化，完整且忠實于理論，我在運用RUP的時候常常摸不著方向，找不到下手的地方（Seal說是沒有剪裁，用RUP一定要剪裁，可是我資質魯鈍，裁來裁去最后不知道要干啥）。ICONIX則從實用角度出發，并不完全忠實于理論，有的地方違反所有三種方法的規則以及語義，并對UML進行了擴展以符合需要。如果你是一個嚴格的UML信仰者那還是不要來搞ICONIX，但是如果你想快速的應用建模技術到你的工程中去，ICONIX是最佳的選擇之一。
本章到此結束，隨后章節我會介紹ICONIX建模的具體方法。
總結
- 上一篇： mysql宕机恢复_mysql突然宕机后
- 下一篇： vc驿站视频教程笔记2 ansi 和 u