通過真實項目來分析-面向對象分析過程
面向對象分析設計過程中的核心的項目中類分析，一般來說獲得分析類有三種途徑：1、腦力風暴；2、詞性分析法；3、CRC分析法（候選類、職責、協作分析法）。 下面我就從這三個方面來談一談如何進行系統的面向對象分析。
1、腦力風暴： 所謂腦力風暴是指我們看到需求或模型后，感覺到系統中應該存在哪些分析類。事實上，這個方法就是利用了我們的感覺與經驗；
2、詞性分析法： 所謂詞性分析法，是指我們根據需求描述或模型中的詞匯進行分析，在分析過程中，按詞性進行類、屬性、方法的劃分。 比如《面向對象分析過程案例實戰》這篇博文中提到的申請報銷這個需求，它的描述可以是這樣： 內部員工向部門經理提出報銷申請，部門經理進行審批，如批準則報銷單再經公司經理進行審核，否則申請作廢；公司經理可以審核通過，也可以作廢此申請，一旦審核通過，內部員工就可以通過財務主任進行報銷。 那么，在這個需求中，我們可以獲得以下的名詞：內部員工、報銷申請單、部門經理、公司經理、財務主任；動詞有：申請、審批、審核、作廢、報銷。 對于這么詞匯，我們可以把名詞作為類或屬性，把動詞作為方法。當然，這些內容會進一步得到確認，看這些內容對我們的目標系統是否有用，是否是分析類或類方法；
3、CRC分析法（候選類、職責、協作分析法）： CRC分析法也是一個簡單易行的分析方法。我們通過對那些可能的類進行職責與協作的分析，進一步確認系統中的分析類及其屬性、方法。CRC分析法要求我們對每一個候選類做一個卡片，在卡片上對這個類進行描述，在描述的下面寫上這個類的職責，在背面寫出與這個類有協作關系的其它類及協作關系。當然，在進行CRC分析時，會有一些具體的措施使我們獲得的分析類更完整，讓分析類的分布更合理。
這三種方法還不足以讓我們獲得比較合適的分析類。在分析過程中，我們還會對照面向對象的原則進行抽象。 另外自底而上的分析方法，不過這不是僅有的方法，可能還要根據實際項目，采用自頂向下，或兩者結合，或從中間向頂向底的分析方法。
下面就通過一個很典型的項目來分析：
項目的原型如下：某公司鑒于業務和員工的快速發展，為了提升整體工作效率，公司準備開發一套員工報賬系統，取代原來的人工處理方式，更加方便的服務于員工日常的賬務操作。財務部門能夠通過賬務系統定期向各部門負責人反映賬務統計情況，并設置和維護相關額度準則。系統應該具有基于先進技術的操作界面。
這段描述里包含的業務目標大致有二：
1.為員工提供賬務的自動化辦理，提高辦事效率，方便員工。
2. 方便財務部門管理好賬務信息。
這些業務目標一般在項目的招標書里都有相關的描述，也可以由開發方整理得出。之所以這里要把業務目標列出來，是因為我所采取的方法里，業務目標是進行需求分析的第一步，接下來的推導過程和業務模型的建立都是根據業務目標開始的。
整理出了業務目標后，接下來先不要一頭扎進具體的業務流程和業務細節之中去，應該先把涉眾找出來，整理出一份涉眾分析報告，涉眾就是和這個項目相關的人。也不要就去考慮技術實現細節，要用什么先進的技術，界面如何美觀，性能如何優越等等，雖然這些確實重要，但是相比起來，忠實的實現涉眾的期望，滿足涉眾的需求才是較為重要，也是一個項目成敗的關鍵。在實際的項目中，我們可以通過需求調研找出相關的涉眾，這里我就直接列出本案例的涉眾分析報告：
員工：公司的正式錄用雇員； 期望：通過網上辦理賬務業務申請，計算機控制流程。
部門經理：部門負責人，負責審核員工提交的申請；期望：方便審核操作，通過計算機代替原來的手工審核方式。
公司主任：公司負責人，負責2次審核員工提交的申請；期望：方便審核操作，通過計算機代替原來的手工審核方式，界面友好易用。
財務主任：公司財務部門負責人，負責發放報賬款項； 期望：通過計算機轉賬的方式替代原來的人為付款方式。
我們開始分析下本案例中的業務用例獲取工作。說到用例，就必須結合邊界和業務主角，否則用例的粒度就會出現問題，因為用例是以參與者（業務主角）為核心的，是由業務主角發起的以達到業務主角完整目標為標準的。要獲取用例就必須先得出邊界，邊界有了，那么邊界外的業務主角就有了，那么業務主角對這個邊界內的目標就是用例了。
我們先來看看一個小例子，沒有引入邊界的概念對獲取用例有什么影響，比如我去食堂就餐，要先領取餐具，然后點菜，打菜的阿姨幫忙盛菜，接著我刷卡付款，去盛飯和湯，之后是找座位，較后才開始就餐。那么領取餐具，點菜，刷卡付款之類的算是一個用例嗎 ？說算也算，說不算也不算。因為這要根據邊界來確定的，我們都知道用例是以主角發起的以完成主角的完整目標為標準的。這里的主角就是我本人，要確定我的目標就必須先確定邊界，比如以整個食堂為邊界，那么我去食堂的目的就是就餐，就餐才是我的完整目標，而其他諸如領取餐具，點菜，刷卡付款之類的都不是我去食堂的目的，這些只是我完成就餐的步驟而已，但如果把邊界粒度降低到食堂的內部，那么這個時候領取餐具，刷卡付款之類的也是一個用例了，雖然都是用例，但是和就餐這個用例的粒度是不同的，因為他們邊界所在的抽象層次不同。所以要描述用例就必須先劃分出邊界來，主角站在邊界外對這個邊界提出目標，一個目標就是一個用例，否則在描述系統的時候就會出現如我去食堂的目的是刷卡付款這樣的笑話來，當然了，除非我去食堂的目的真的只是為了付款.
這個項目中，要去找業務主角和邊界：員工，財務主任，員工信息邊界，財務信息邊界。那我們就可以找用例了。我以員工賬務服務邊界為例，根據涉眾分析報告和客戶訪談（這個在實際項目中需要好好歷練的，我覺得要有技巧引導客戶，還要有較強的總結概括能力吧）得出的。假定我從與客戶訪談的結果中得出員工對這個系統的期望和目標有通過計算機申請報銷業務，申請借款業務，這兩個期望都是與員工賬務服務這個特定的業務目標有關的，所以可以作為業務用例被納入到員工賬務服務邊界之中。如果假設員工也可以參與管理賬務信息，那么得出的員工對系統的期望就不止這兩個，但是分析的時候要注意與員工賬務服務這一業務目標相關的期望只有申請報銷業務和申請借款業務兩個，其他的期望是與管理賬務信息這個業務目標有關，應當被劃分到管理賬務信息邊界中去。 接下來是建立業務模型階段，建立業務模型的目的是為了通過UML這種對象語言將現實世界描述出來，是我們為了理解客戶的業務并和客戶達成業務上的理解而建立的模型（我們的系統將要面對的問題領域就是這個樣子），它不需要考慮計算機環境，相對于系統模型來說，他沒有加入計算機元素，是對現實業務的一種直觀的理解。我們平時開發時接觸的《軟件需求規格說明書》來源于系統模型，他描述的是軟件系統要實現的功能范圍，和計算機環境密切相關，軟件需求只是整個需求過程的一部分，可以從業務需求中推導出來的。
務模型主要包括業務用例，業務用例實現場景，業務規則，業務用例規約等等，限于個人掌握程度及個人精力所限，本案例中我主要講述業務用例和業務用例場景圖，業務用例場景主要是描述業務用例的執行過程，一般通過活動圖中的泳道來繪制，這里以“申請報銷”用例來說明：
員工報銷申請用例： 員工：申請報銷，部門經理 第一審核，公司主任 再次審核，財務主任是發放報銷費用。
到此為止，用例已經全部找出來了，接著就是要進入用例實現階段了，因為用例只是描述了系統應該做什么，是對系統提出的設想，用例實現的目的就是實現需求，把設想變為現實，由于我們采用的是面向對象的方法，所以用例實現的過程就是用對象之間的交互來實現需求的過程。不少人到這一步，包括我自己，可能直接進入類設計，數據庫表結構設計了，但是經常說不清楚類是如何推導出來的，為什么是設計2個類，為什么不是3個類 ？ 美其名曰：經驗，哈哈，無非就是拍腦袋拍出來的咯，尤其是在業務復雜的大型項目中，這種拍腦袋出來的設計估計要經過反復修改才能滿足需求。現在我發現，原來從系統需求到設計之間可以通過分析模型作為過渡，通過分析模型推導出設計模型，推導出設計類。分型模型就是采用分析類（邊界類，控制類，實體類）來實現用例場景的一種對象模型，這個抽象層次上需求已經通過對象之間的交互實現出來了，而又不必去關注具體的技術細節，如采用什么語言，什么框架之類的，可能安心的為需求到設計之間的跨越做一個橋梁。繪制分析類圖一般需求根據用例場景來推導，先一步步的分析場景中的活動：
創建新申請報賬單：這是一條由外面發出的命令，需要用邊界對象接受它；
展現錄入新報賬單界面：這是一個控制邏輯，需要有控制對象處理；
輸入報賬單信息：這是一個人工活動，由邊界接受，報賬單是一個實體對象；
提交申請：這是一條外界發出的指令，由邊界對象接受；
驗證信息：這是業務規則，通過控制對象來處理；
保存申請單：這是一段處理邏輯，由控制對象處理，同時，報賬單作為實體對象封裝了要處理的數據；
發送郵件通知：這是一段處理邏輯，需要由控制對象處理；
顯示結果：這個是處理結果，用控制對象處理，并反映到邊界對象。根據上面的分析，接下來我繪制出員工報銷申請用例實現的分析類時序圖。
在繪制該時序圖的過程中我們得到了關鍵對象以及這些對象的方法，接下來把這些對象及其方法繪制在一個圖里，定義出他們的關系，就得出了分析類靜態圖如下：
這些分析類就是我們進行系統設計的基礎了，分析類結合采用的具體框架（比如SSH），架構等，就可以推導出設計類，產生設計模型了。
推導設計類的過程由于要結合具體框架，可能要實現某某接口，繼承某個抽象類等原因，這里就不說了，等過段時間我再新寫一篇文章來說吧。由于我工作中的項目采用 SSH框架，所以我曾經疑惑覺得怎么沒有看到 Action 類啊，Service類呢， pojo呢，DAO呢，沒看到啊！后來才恍然醒悟，哦，原來所處的抽象層次不同，分析模型的抽象層次比設計模型高，不涉及到具體的框架，架構，語言等實現方式，所以在這個抽象層次上，可以不去考慮實現細節，屏蔽掉無關的信息，而專注于通過分析類的3種對象之間的交互來實現需求，為需求到設計之間搭建橋梁，設計模型就是在分析模型的基礎上結合具體框架，架構，語言等實現方式實例化分析模型的過程。完整而全面的分析模型就可以作為系統概要設計文檔了。
