OOAD培訓心得

周末參加了公司組織的“物件導向設計與分析基礎”的培訓，感覺獲益良多。
有些比較好的東西摘出來，標記！

【使用者需求觀】
        這個名稱說起來容易，一切從使用者出發，使用者的需求決定我們的產品，從使用者的角度去考慮問題。但是實踐時，我總會考慮這個需求如何對應，那個需求如何?。這樣做不是很好，容易考慮的太多，注意力偏離了正軌，用個大家常說的詞就是“不上道”。
        需求分析階段，應該把系統當成一個黑盒，這時，我們需要做的就是規定他與外界互動，讓他擁有最基本的完成使用者需要的功能。
    
【功能的劃分】
        這個問題說多了，可以用整個一篇文章，這裡我們只考慮需求階段，在這個階段，還是那句話，不要過多的考慮實現。
        在我的第一個項目裡，因為是新手，所以我很小心的考慮了很多，比如這個功能可以和哪些功能聯絡在一起，比如這個功能可能用到的技術。從而造成了這樣一個問題，當考慮第一個問題的時候，ok，一切都是空白，然後把他的準系統列出來，把他可能用到的技術列出來，然後繼續，隨著發現的需求的增多，我考慮的問題也就隨之增多，從而不容易將它們系統的梳理出來，形成的需求式樣書就很混亂。
        需求的分類，應該盡量多考慮的是使用者提出的最原始的功能，按功能分類，而不是按實現分類。當然並不是不考慮實現，需求整理出來後，在評審過程中，才是考慮這些需求可行性的時候。
        不得不說的是最讓人頭疼的“隱藏需求”，系統的啟動和推出，是最容易忽略的地方，另一個就是預設值這樣的隱藏需求。需要向使用者確認。特別是設計到介面和多使用者的時候更加需要小心謹慎。

【粒度】
        拿“學生選課系統”來說，最基本的需求就是能夠選課，對於這個籠統的功能，可以演化出很多更細的功能，比如說選主幹課，選輔修課，選主幹課備選課等等。這些更細的功能如何被全部發掘出來，隱含的問題如課程的先行條件應該什麼時候考慮？這就需要對粒度的把握。
        一般而言，可以分為這麼幾個層次：

1. 第一個層次只注重使用者提出的大功能，把使用者提出的最籠統的功能拿出來。如選課。
2. 第二個層次找出實現完整功能的那些具體功能。如選主幹課等。
3. 第三個層次找出那些隱藏需求，如某一類課程的先行條件等。
4. 第四個層次是介面，對於一個與使用者互動的程式，最重要的可能就是人機介面的友好性和易用性，這時候會經常遇到預設值，狀態遷移等問題，需要進行細緻的考慮和確認。

        這裡讚美一下Rational Rose這個工具，實際操作時，可以先考慮畫出“基本用例”（大功能），然後在根據這個基本用力細化為“包含用例”和“擴充用例”（實現大功能的小功能）。這樣我們會很自然的進行前兩個層次的需求整理，至於後兩層次則更多的需要縝密的思路和經驗。
        說一句題外話，根據這些包含用例和擴充用例，我們很自然的會想到“模板模式”和“裝飾者模式”。

【用例分析】
        Rose提供了分析類這樣的概念，又把開發人員很自然的拉到了經典的“MVC模式”中。
        Use Case是由Actor觸發的，根據這種關係可以把一個用例模型細化為：

1. 負責與使用者互動的介面類；
2. 負責商務邏輯的控制類（控制類的設計原則有時候在於非功能性的需求，如效能等，當這些非功能性的需求很少時而且商務邏輯也不複雜時可以省略MVC中的C，就像MS的Document./View模型一樣）；
3. 負責與裝置互動的實體類。

        而Actor從概念上可以分為三類：人，系統，裝置/計時器。所以介面類又可分為三類：
        使用者介面類，使用者接受外界的輸入和向外界展現資料；
        系統介面類，用於內部模組的通訊協定；
        裝置介面類，負責處理裝置的資訊。

        再說一句題外話，每個Use Case會對應1…n個事件流。而事件流又可分為基本流和備選流，這就可以用多態去封裝變化。
        不得不提到的是檢查參數的有效性這樣的操作應該讓那種類負責？？？誰有決定資料是否有效權利？當然是負責處理資料的實體類。雖然有時候這可能有點像商務邏輯方面的東西，但是仔細考慮後就會發現，資料的有效性這樣的問題可能經常會變化，想要在變化時使他影響的範圍最小，那麼交給實體類是個不錯的注意。控制類的職責是商務程序/工作的分配。

【用例驅動的設計】
        使用者的需求才是指導設計的最重要的準則。從分析類出發，就會到設計模型的元素，這些元素最可能的是一系列的類，但要組織這些類，準則是很難把握的，畢竟項目是不可能完全相同的。可能要說原則那就是高內聚、低耦合，這並不是OO所特有的，面向過程同樣遵從該原則。
         用例是以使用者需要的功能建立的，所以根據這些基本用例，我們可以抽象出一系列的子系統和包（package/namespace…），這兩者最關鍵的區別在於子系統會隱藏掉實現細節，只留下interface，所以盡量用子系統。借用功能劃分的原則就是盡量根據需求中的大功能劃分子系統。
        設計子系統內部的類的時候，就要本著高內聚低耦合的原則，UML中類的關係很多，但是比較常用的有四種，依賴、關聯、彙總、組合。
        依賴和關聯的區分其實很微弱，同樣是使用的關係，依賴更注重暫時性，關聯則意味著比較長期，所以依賴一般是A在實現某一函數中執行個體化了一個B，而關聯一般是B的指標或引用就是A的一個資料成員。
        彙總和組合的區分也較微弱，同樣是內含項目關聯性，彙總的關係可以拆斷，組合則頗有武俠世界中的劍在人在，劍亡人亡的味道。所以彙總一般是持有引用或指標的實現，組合則直接是對象。
        都是引用和指標，彙總和關聯的區別在於邏輯上的意義，彙總是包含，關聯是使用！