軟工藝術 : [轉貼]軟體架構設計鮮思維

• 發表新主題

發表者	討論內容
冷日 (冷日)	發表時間：2008/3/14 9:03
Webmaster 註冊日: 2008/2/19 來自: 發表數: 15773	[轉貼]軟體架構設計鮮思維 軟體架構設計鮮思維－界定清晰的系統範圍與責任 文/ iThome(記者)2006-04-25 以土地公廟的系統分析為例，來說明如何利用案例圖界定系統範圍，以釐清系統與其內部元素的責任；同時並利用循序圖，表達系統內部元素之間是如何動態合作，來完成系統的功能需求。 作者：王克明 信仁軟體設計顧問中心軟體架構師、機械化師文書官、系統工程師、Oracle DBA、IT部門副理、講師、顧問 傳統的資訊系統開發模式，開發人員常假設為單一的系統，由自己從頭到尾所負責來實作完成的。如今E化系統的開發，更會面臨多個應用系統的整合，團隊必須對所承包的系統有明確清晰的範圍，才有可能釐清系統所該擔負的責任，以及是如何與其他系統的訊息溝通。 架構師經常會利用使用案例圖（Use Case Diagram）來界定系統開發的範圍（System Boundary），可以讓團隊的內部成員能對系統全貌有一致性的認知，也能據此找出使用該系統的參與者（Actor），以及參與者使用該系統的目的（Goal），同時也能區分出系統的「內」與「外」，如此才能知道什麼是該做、什麼不需要做。 所謂的「外」，是從使用者的角度來看待與應用系統之間的互動，此時系統是一個「黑箱（Black-box）」，又不致干涉到系統實作的內部，所專注的僅是在於與系統溝通時訊息的「進（Request）」與「出（Response）」。在需求分析階段，分析師要能捕捉到使用者對系統的期待或想法，也就是要能取得使用者的需求，而使用案例便是一種極佳的工具。 至於「內」就是系統內部的結構，是由系統內部的靜態元素所組成，這些元素係源自於問題領域（Problem Domain）的概念術語，稱為實體（Entity）。每一個實體均有所需儲存的資訊，以及應盡的責任。系統分析的目的就在於如何找出這些元素（或稱之實體），並賦予每一個元素的責任，然後系統分析/設計師動態組合這些元素，配合實體平臺的服務元件，來滿足系統外部的功能需求。也就是說，靜態面的結構元素，與功能面的行為（Behavior）描述，均是屬於系統分析師的範疇。 以一個接近現實生活面的例子，來說明如何利用使用案例圖界定系統範圍，以釐清系統與其內部元素的責任。同時並利用循序圖，表達系統內部元素之間是如何動態合作，來完成系統的功能需求。 土地公廟的許願－利用使用案例圖界定系統範圍 南山福德宮使用案例圖 使用案例就如同去廟宇向神明祈求，並在心裡許願以求得平安、健康等各種願望，兩者有許多相似之處，例如： ●眾神明所居住的廟宇，就如同寫使用案例時，需界定系統範圍（廟宇即系統）。 ●信徒向神明許願，信徒就是使用系統（廟宇）的參與者（Actor），而所許的願就是使用案例（Use Case）。 ●許願後還願是一種契約，就是一種交易（Transaction）。這就如同系統能滿足參與者使用系統的目的（Goal），那麼，每一個所滿足的使用案例就是一個交易。 ●信徒向神明許願，不需要了解神明是如何能達成信徒的願望，最終只要能完成你所許的願即可；這如同參與者使用系統的使用案例，不需要了解系統是如何（How-to）完成參與者的使用案例，只要能滿足其目的（Goal）即可。 舉個例子，來說明如何利用使用案例「塑模（Modeling）」信徒的許願，一段簡單的文字敘述如下： 「兩個信徒，到福德宮土地公廟許願。其中信男許的願是『求得大樂透明牌』；信女許的願是『求得子息』。」 初期的系統分析，界定系統是『南山福德宮（烘爐地土地公廟）』，參與者有兩個：一個是『信男』，另一個是『信女』；使用案例是 『求得大樂透明牌』與『求得子息』（參考使用案例圖）。 土地公非執掌婦女的生育，註生娘娘也是系統，但是祂並不屬於土地公廟的管轄，所以是屬於外部的系統，也就是土地公廟的「支援性參與者（Supporting Actor）」。 信男與信女都不需要知道土地公是如何達成他們的願意，最終就是只要能滿足其願望即可。所以，信女也根本不需要知道「求得子息」的實際工作是由土地公轉派交付給註生娘娘來實現的。若是想知道系統是如何實現其願望，那麼，就勢必要打開土地公廟的系統，探究其內部是由哪些人員來協調、互動與合作，以完成信徒們所交付的願望。 實現信眾們的許願－系統內部的結構分析與分派責任 求得大樂透明牌的循序圖 找出工作人員、分派工作人員的職掌，就如同系統分析中的找出元素、分派元素的責任，這是屬於系統內部的結構分析與設計範疇。我們可以利用循序圖表達參與使用案例的元素彼此之間的協調與合作（參考循序圖）。 每天有那麼多信眾來許願，土地公顯然會分派責任給祂下轄的隨從們，協調、互動與合作來實現其願望（使用案例）。若信眾們會把他們的許願寫在籤紙上，並請廟公轉交給神明，那麼，廟公就是擔任著窗口的角色（Facade）。當然，也有可能信眾們是直接在心中許願，藉由心意傳達給土地公，那麼，土地公就是擔任窗口的角色。同時，祂也是控制者（Controller），當接收到信眾們的許願訊息後，土地公將該訊息交付給文隨從，而文隨從又將訊息輸入至祂的樂透邏輯演算機，來取得明牌號碼。 實作介面溝通內部與外部系統 界定系統範圍，找出使用該系統的參與者，並記錄參與者使用該系統的目的。若為完成該參與者的目的，而經分析後確認為了要完成該目的，需要外部系統的協助，自然就需要傳遞訊息給外部的系統。請記得，系統與外部系統的溝通，是透過 「訊息（Message）」 來溝通，在實做面的層次上，也就是透過 「介面（Interface）」 的呼叫。 筆者以為，系統分析與設計是一件饒富於創意又有趣的工作，從以上的案例可以發現到，系統分析人員要能在心中 「想像」軟體應用系統的內部，是由一群有生命的 「個體（Instance）」 所共同協力互助，來完成一件件由系統所交付的任務（也就是需求）。
回覆

平面展開

前一個主題 | 下一個主題 | | | |

討論串

•  » [轉貼]軟體架構設計鮮思維 (冷日
  (冷日), 2008/3/14 9:03)
•      [轉貼]軟體架構設計鮮思維(1) 系統整合－誰是老大？ (冷日
  (冷日), 2008/3/14 9:03)
•        [轉貼]什麼是架構？ (冷日
  (冷日), 2008/3/14 9:04)
•          [轉貼]先從觀點看架構 (冷日
  (冷日), 2008/3/14 9:04)
•            [轉貼]關於系統整合— 架構的呈現 (冷日
  (冷日), 2008/3/14 9:06)