《系統分析師ＵＭＬ實務手冊》讀書筆記－－第一章

第一章

　1、使用者與系統分析員的專業背景不同，交流訪談難免會有誤解和遺漏。下面的對策試圖減輕系統分析員的工作壓力：

1）    使用UML圖引導訪談，降低遺漏需求的情況。系統分析員在訪談過程中，通過多款不同的圖來理清需求各種不同角度的面貌，降低遺漏。

2）    快速產生可執行檔程式片段，通過展示來凸顯誤解。

3）    封裝變化，讓需求發生變化時，可以追蹤到變化之處，迅速改版，並且不讓變化起漣漪效應，向外擴散。

 　2、系統分析員主要會用到下列的UML圖

     1）、行為類

         使用案例圖（Use Case Diagram）

         活動圖表（Activity Diagram）

         狀態圖（State Machine Diagram）

         順序圖表（Sequence Diagram）

     2）、結構圖

         類圖（Class Diagram）

　3、並非所有的事物都適合對應成軟體對象（Object），候選對象應符合下列兩項條件：

　　　１）、在企業運作過程中，業務人員會使用到的專業事物或概念；

　　　２）、在資訊化時系統也會用到，或者需要儲存。

4、針對對象的各項屬性，系統分析員還需要瞭解他在企業裡的定義、資料類型、可能的範圍值和初始值，更別忘了瞭解這項屬性是怎麼跑出來的。

５、對於對象的封裝性，系統分析員要掌握下列要點：

　　　　１）、已知操作。對象通常僅對其他對象透露自身的操作，彼此之間通過調用已知的操作來互動；

　　　　２）、封裝屬性。封裝屬性值，不透露給其他對象；

　　　　３）、封裝方法。僅對其他對象透露操作，但不透露其方法。

　　　如果需要與其他對象互動，甚至是用到對象本身的屬性或操作時，切記嚴守下列三條：

　　　　１）、不得直接提及對象的屬性；

　　　　２）、不得假設對象的執行方法；

　　　　３）、僅能夠使用對象的操作。

　　　嚴守對象的封裝性，有一個好處，當需求發生變化需要改寫代碼時，變化會被局限在對象的屬性和方法中，不會起漣漪效應，也不會發生牽一髮而動全身的連鎖反應。由於軟體內部的組成對象易於汰舊換新，所以軟體的使用壽命延長，後繼的維護成本也偏低，企業因此得到高投資報酬率。不過眼前首先要付出的代價是較高的開發成本。

　６、判斷是否採用關聯關係：

　　　１）、在企業領域的專業概念裡，兩種對象之間有一種固定不變且需要儲存的靜態關係；

　　　２）、在資訊化時，系統會用到這些靜態關係，而且必須將他們儲存到資料庫。

　　　判斷是否採用彙總關係：

　　　１）、符合上述關聯關聯準則；

　　　２）、在企業領域的專業概念裡，兩種對象之間有Whole-Part的靜態關係。

　　　判斷是否採用組合關係：

　　　１）、符合上述彙總關係；

　　　２）、Part對象只能連結一個Whole對象，且Whole對象被登出時，Part對象必須一塊被登出。

　７、系統用例：表達使用者與資訊系統的互動；－－（系統執行者，將引導整個開發程式）

　　　業務用例：表達顧客與企業組織的互動。――（業務執行者）

　８、ＭＤＡ（Model-Driven Architecture）開發程式，分為下列三個階段：

　　　１）、ＣＩＭ――聚焦於系統內容及需求，但不涉及系統內部的結構與運作細節；

　　　２）、ＰＩＭ――聚焦於系統內部細節，但不涉及現實系統的具體平台；

　　　３）、ＰＳＭ――聚焦於系統落實到特定平台的細節。

　　　具體步驟參照：

　　　１）、CIM-1：定義商務程序，產生業務用例模型；

　　　２）、CIM-2：分析商務程序，產生活動圖表；

　　　３）、CIM-3：定義系統範圍，產生系統使用案例圖；

　　　４）、PIM-1：分析系統流程，產生系統用例敘述；

　　　５）、PIM-2：分析商務規則，產生狀態圖；

　　　６）、PIM-3：定義靜態結構，產生類圖；

　　　７）、PIM-4：定義操作及方法，產生順序圖表。

－－ｅｎｄ