發表者

討論內容

冷日
(冷日)

發表時間：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

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[轉貼]軟體架構設計鮮思維(1) 系統整合－誰是老大？

軟體架構設計鮮思維(1) 系統整合－誰是老大？

文/ iThome (記者)2006-04-13

一般軟體公司普遍存在最大的系統整合問題點即在於：把資料庫當作應用系統來看待！這問題很大。因為軟體設計人員因此就不會有「介面」的觀念，導致每一個應用系統均無法獨立成為個別的模組或元件。

作者：王克明／信仁軟體設計顧問中心軟體架構師，機械化師文書官、系統工程師、Oracle DBA、IT部門副理、講師、顧問。

什麼是架構？
架構一詞非常難解釋，若真要一言以蔽之，那麼，可以說，「架構」是一種整體觀，需要保持從各角度看待架構時，仍有一致性與調和的觀點。

對「架構」要能有充分的理解與認識，至少要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語，包括了：整體—局部（Whole-Part）、觀點（View），包括巨（Macro）觀與微（Micro）觀、焦點（Focus）、層次（Layer）與廣度（Boundary）等。

先從觀點看架構
筆者首先以「觀點（Viewpoint）」一詞來解釋架構。要能具軟體架構的整體與協調性，最起碼要能有三個觀點：

．　需求面的觀點
．　結構面的觀點
．　實作面的觀點

關於系統整合— 架構的呈現
應用系統的整合，講究的是以「介面」作為溝通的唯一管道，這難不難？技術上其實並不難，但在設計上，確是需要專注於介面的設計，而且還需要存在著一種那麼一點抽象與創新的思維。

筆者就以某一公司的「人力資源系統」（Human Resource，HR）為例，當該公司要導入請假的電子簽核流程，而電子簽核可能是外購的工作流程（Workflow）系統，因而會牽涉到系統整合時，是要如何看待彼此之間的架構整合設計呢？

回覆

冷日
(冷日)

發表時間：2008/3/14 9:04

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[轉貼]什麼是架構？

什麼是架構？

架構一詞非常難解釋，若真要一言以蔽之，那麼，可以說，「架構」是一種整體觀，需要保持從各角度看待架構時，仍有一致性與調和的觀點。

對「架構」要能有充分的理解與認識，至少要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語，包括了：整體—局部（Whole-Part）、觀點（View），包括巨（Macro）觀與微（Micro）觀、焦點（Focus）、層次（Layer）與廣度（Boundary）等。

擔任軟體架構師（Software Architect）必備的素養，即在於：觀照整體的能力。

筆者在輔導許多軟體公司的專案開發與教育訓練時，發現到與開發團隊對「架構」一詞的認知與定義大不相同。個人發現到，大部分的IT技術開發人員，所表達出來的架構，是比較偏向於實體層次如.NET、J2EE的IT技術層次。不是不對，而是IT實體層次僅是架構的觀點之一，並不足以代表整體的架構觀。

筆者想試著利用以上述幾個術語來解釋「架構」。畢竟，架構的設計，牽涉到相關於設計中系統的議題與範圍太廣了，包括：團隊開發的共識、開發流程（Development Process）的制訂，分工與外包（Outsourcing）控管、系統的彈性、延展（Scalibility）與維護性等。

有經驗的架構師（Architect），會以各種不同的角度（以上所涵蓋的幾個術語），建構各類型的軟體模型，來看待並解釋「架構」。如同「以指標月」一般，對架構有深一層體會的架構師，會以導師（Mentor）的角色，利用各種工具來具化產出，以引導系統開發團隊的成員們認識「架構」。

UML或程式碼等只是個標示工具，而所謂「架構」，是一種共識、一種默契、一種無以言欲的整體調和感。

回覆

冷日
(冷日)

發表時間：2008/3/14 9:04

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[轉貼]先從觀點看架構

先從觀點看架構

筆者首先以「觀點（Viewpoint）」一詞來解釋架構。要能具軟體架構的整體與協調性，最起碼要能有三個觀點：

1.需求面的觀點
2.結構面的觀點
3.實作面的觀點

● 需求面的觀點：
需求（Requirement），代表著的是系統外部的觀點，也就是從參與者（Actor）的角度來看待系統所提供的功能（Function）。

筆者會建立使用案例模型（Use Case Model），來代表需求面的觀點，每一個使用案例，即代表系統所該履行的功能。

使用案例模型的建立，筆者會視系統規模的廣度，來決定是否建立企業使用案例（Business Use Case Model）模型與系統使用案例模型（System Use Case Model）兩個層次。

不以使用案例模型來代表需求面的觀點，未嘗不可。例如，利用如XP（eXtreme Programming，敏捷性開發的代表性流程）的使用者陳述（User Story）來紀錄系統的功能點（Functional Point），當然可以更形簡化需求面的陳述。只是，筆者個人是偏好於利用視覺化來建立各種觀點的模型，感覺會更有助於對整體系統的瞭解。尤其是，筆者經常以「套件圖（Package）」，表達在使用案例圖內子系統與子系統之間範圍的界定與溝通。

● 結構（Structure）面的觀點：
系統的結構設計，可以說才是決定系統的彈性、延展、效能、穩定等主要成敗因素。國內軟體專案的開發，絕大部分並不重視系統的結構設計。主因在於專案開發時程偏短線的不合理、軟體人員對結構設計未能俱足抽象與實務並重的技能，以及內部的結構是客戶所看不到，並且短期無法能感受到的。專案開發因重視短線立即性的效果，所以反而以功能需求面、使用者介面（UI）為主要的開發重點。

這如同購買房子一樣，一開始因為樣品屋美輪美奐的室內佈置（UI），以及附贈許多的家具、生活用品（功能），卻忽視掉房屋的結構設計。短期感受不到問題，住久後才逐漸顯現出如漏水、海砂屋甚至因鋼架的偷工減料而導致強烈地震一來即崩垮的慘劇。
軟體的結構模型，至少有兩個主要的產出：類別（Class）設計圖與循序（Sequence）圖。

類別圖表達的是系統的內部靜態結構；循序圖表達的是系統內部元素（稱之為物件比較理想）之間，為完成某一交付的任務（系統功能），物件之間互動合作的動態行為。

傳統的軟體結構分析與設計，會以為主要的工作是建立資料庫的E-R（Entity-Relationship）模型。這該算是靜態結構設計的一種退化解，雖然 E-R圖是以問題領域（Problem Domain）的術語作為分解的依據，這與類別圖設計的分解思維是一致的。不過最主要的問題，仍在於E-R圖的分解元素沒有自主性的行為（Behavior）能力，把行為抽離出來而分散至Form Script、Web Page、Stored-procedure …，甚至亂分一番，隨便實做某個物件，把演算邏輯「塞」進去就號稱為物件導向設計。

行為的分散，造成系統彈性與維護的困難性，是注重以E-R資料模型為結構設計主體的問題點。類別圖（Class Diagram）回歸至本質面，把資料與行為有效歸納至所該承擔的物件上。類別圖的設計最困難與謹慎之處，即在於如何有效分派責任（Responsibility Assign）至物件上。

結構的設計若以層次（Layer）之分，又分為高階抽象的領域模型，與細部、平台面相依的軟體規格模型。層次的問題，筆者會以另外一個主題：從層次來解釋架構時再來討論。

越是高階、抽象的結構模型，會比較偏向於「本質面」。當越能抽至最接近本質面的那一層，結構越為穩定。越接近本質面的那一層，其呈象反而越是簡單（Simple），但是，要能呈現出簡單，本身卻不簡單，是最為難之分析、設計的。理由是，結構設計師需要非常高度的抽象理解能力。抽象能力的培養，講究悟性，左、右腦需能平衡協調，絕非純左腦邏輯的分析，也無法利用所謂的方法論（Methodology），以所謂的「規則」來套用。這是「純（Pure）」軟體設計的修練，起碼要花上 5～10年以上（最保守的估計），培養軟體設計者的反思與創意思考能力，來鍛鍊對軟體設計的基本功夫。

● 實作面的觀點：
程式碼（Source Code）是實作最主要的產出，也可以說是最直接、有效的產出。因為，無論你的設計圖作得多棒，卻很難以工具來驗證、測試其正確性。但是，程式碼經過語法檢查、編譯後能不能執行，馬上就可以知道，並且可以透過各種的測試機制，來測試包括功能、效能、容錯（Fault Tolerance）…等各類的測試項目。

從實作面的觀點，筆者一直大力主張要能針對系統功能作測試自動化，而不要僅流於紙張上的測試案例。功能絕對會善變，功能一變，測試程式碼就必須得跟著改變，否則無法通過自動化的測試。
這非常重要，因為會直接影響到「驗收」這一環節。這裡筆者太認同XP其中之一的實務：測試先行（Test First）。由客戶撰寫測試的情節（Scenario）與提供測試相關的數據；開發團隊負責撰寫測試程式碼。

使用者接受度測試（UAT，User Acceptance Test），是可以透過撰寫功能測試程式碼來達到自動化的測試，不過，卻無法測試程式碼的結構內涵。結構的測試，更是一個重要的議題。有太多的軟體開發單位是先寫程式碼，再反轉回（Reverse）設計圖，把設計圖當文件（Document）交差了事。這很危險、脆弱的結構，是導致系統複雜難以維護，以及無法應變的主因。

我會利用如Together，EA（Enterprise Architect）等UML工具，幫程式碼照「X」光，檢驗其脈絡。反轉程式碼，呈現視覺化的模型後，最重要的是檢查元素的相依性（Dependence），從巨觀包括子系統、模組，以至於微觀的套件（Package）、元件（Component）等，是否有違背原先所承諾客戶的結構設計。

回覆

冷日
(冷日)

發表時間：2008/3/14 9:06

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15773

[轉貼]關於系統整合— 架構的呈現

關於系統整合— 架構的呈現

一般軟體公司普遍存在最大的系統整合問題點即在於：把資料庫當作應用系統來看待！這問題很大。為什麼？因為軟體設計人員就不會有「介面」（Interface）的觀念，這導致每一個應用系統均無法獨立成為個別的模組（Module）（或者，稱之為元件（Component）更為適合）。

也就是說，若要讓每個應用系統能成為獨立的個體，就需要有明確的溝通介面。資料庫僅是應用系統的私有倉儲（private storage），其它應用系統是不能也不應該直接至某一個應用系統的資料庫「撈」資料來處理，這如同硬體的主機板設計，為了取巧而以跳線的方式來讓某些元件之間快速得以連結。想想看，這樣的主機板你會肯買嗎？然而，大部在軟體系統所謂的整合技術，卻都是用這種「跳線」的投機方式來應付。以資料庫的整合方式為手段，而所謂的模組（Module），卻僅是在業務邏輯領域的分辨而已。例如，「進銷存」系統，你到世貿軟體應用展所看到各種號稱軟體產品廠商所推出的產品，一定是「一個」進銷存系統，不可能也無法明確分離成「進」、「銷」、「存」三個實體的模組，甚至可以將甲廠商的「進貨」模組，連結到乙廠商的「存貨」模組。這是一種「草本植物」的整合，雜草叢生，而根卻早已彼此糾纏不清，剪不斷、理還亂了。

那麼，回歸到應用系統的整合，講究的是以「介面」作為溝通的唯一管道，這難不難？技術上其實並不難，但在設計上，確是需要專注於介面的設計，而且還需要存在著一種那麼一點抽象與創新的思維。

筆者就以某一公司的「人力資源系統」（Human Resource，HR）為例，當該公司要導入請假的電子簽核流程，而電子簽核可能是外購的工作流程（Workflow）系統，因而會牽涉到系統整合時，是要如何看待彼此之間的架構整合設計呢？

HR與Workflow系統—誰是老大？

將原本是人工作業的請假業務流程，改為可以讓員工填寫電子表單，填寫完畢後系統即自動傳送至直屬主管供其簽核，整個請假流程完全是電腦化、自動化，這也是一種BPR（Business Process Re-Engineering）的範疇。

利用使用案例圖（Use Case Diagram）界定HR系統範圍（System Boundary），同時也找出使用該系統的參與者（Actor），以及參與者使用該系統的目的（使用案例，Use Case），觀察第一版的使用案例圖A。

圖A：HR系統隱含實作電子簽核的功能。

筆者在擔任架構師時，當遇到系統分析人員畫出如圖A的使用案例圖時，首先一個直覺的問題就是：實作請假電子簽核流程是由那個系統負責？

從圖A其實看不出來，請假電子簽核流程到底是否是由HR還是工作流程系統來負責？而事實上，電子簽核由HR 系統來負責實作明顯不合理，因為若如此，那麼，該公司如公文簽核系統，難道也是公文系統負責，也要實作一個電子簽核系統嗎？但從圖A的設計意涵，卻表達隱含了HR系統需擔負流程簽核的責任。這似乎不妥當，所以第二版本的使用案例如圖B。

圖B：將Workflow系統抽離出來，成為HR的外部參與者。

圖B則顯明地表達流程簽核係外部工作流程系統的責任，同時這也代表著兩個很重要的設計意涵：

1. 把工作流程當作外部系統，明顯表達HR系統不需實做流程簽核功能，而工作流程系統可以是其它外購產品（如 Ultimus）、OpenSource（如jBPM）的系統。

2. 當定義出與外部工作流程系統溝通的介面，例如依循 WFMC的規格，即可造成「Plug-and-Play」效果，亦即工作流程系統是隨時可以被抽換的。

這也是為何筆者從圖A導出圖B的使用案例圖時，還特意把工作流程戲稱為「小弟」。筆者一直以為，在現實人工的請假流程中，誰來負責傳遞請假單？稍具規模的公司，會由兼職的小弟或小妹擔任傳遞的工作，而若小弟不乖、傳遞效率不彰，影響到請假當事人權益，該怎麼辦？二話不說，就是換掉！

但回到現實許多公司導入外購的電子簽核系統後，卻反而由工作流程系統成為主角，其它的系統是被整合體。導入某廠商的工作流程產品後，若覺效能或穩定度不佳，想換掉？門都沒有！在導入工作流程系統，在整合自家既有的系統時，已大都由廠商以「跳線」的手法，利用資料庫的整合，將自家的系統與外購的工作流程系統，整合成「連體嬰」了。想切掉？可得要找醫術高明的外科醫師才有點機會。

當然，筆者也遇到許多的IT技術人員，質疑圖B的實作方式，甚至會疑惑若該Workflow系統沒有提供標準、明確的介面，那又該如何溝通？

諸如實作面的技術問題，筆者永遠傾向拿出第一個利器：Prototyping（雛形設計），以檢驗在實作面可能會遇到的技術面問題。先不論這該用何技術來解決系統整合的問題，反正在第一個時間點，就該具體呈現細部的系統整合，以及產出可以被執行的程式碼，解決技術人員們的疑惑。

至於第二個問題，若撇開政治面非得採用某家產品以外來說，我們可以反思，Workflow是一個非常成熟的領域。OMG轄下的WFMC組織，早已在多年前，明確規範工作流程系統的標準規格，甚至還更細分至Workflow是由多個模組所組成，模組之間並規劃明確的介面，作為彼此之間以及外部系統的溝通，這些是可以至WFMC下載規格文件來參考之。而國內已有多家 Workflow廠商宣稱已加入WFMC認證組織，所以客戶在採購Workflow系統時，當然優先以採購經由認證、品質保證的為主。

仍然找不到可以連結至工作流程系統的介面？好吧，了不起，我們幫它寫個「調變器（Adapter）」吧。這個 Adapter同時也是一種「包裹（Wrapper）」的角色—封裝外部善變的系統，未來得以把它換掉。

基本結論
所以，Workflow 並不是老大，當它是屬於「小弟」的角色時，「不乖」就應該把它換掉，但前提是不能影響到本來已在執行的業務流程。所以，換成是HR系統是老大囉？這也不然，從「架構」的整體觀點來考量，HR系統也應該會被當成是可被抽換的模組，HR 與Workflow系統都是可以被抽換的，但是彼此誰也不應該也影響到誰。所以，到底是那一個系統，才是整合的老大呢？

放棄「自我本位」的觀點，試著以「同理心」從客戶的角度來看待系統的整合，則整合的解決方案卻是意外的簡單！我們只要加上「主機板（Mother-board）」的設計觀念就可以了。關於「主機板」的整合設計，留待爾後的單元再以實際的個案來分析與討論。
這裡先帶一句話，來說明整體架構設計所應該瞭解其中一個重要的設計素養：「從客戶的角度來看時，所有的子系統（或模組）均是一視同仁的，客戶不希望因為其中一個子系統的抽換，而牽連到其它的子系統，減少其耦合度（Coupling），以避免複雜無法維護而不可收拾的結果。」

回覆

主題一覽的下方

討論串

前一個主題 | 下一個主題 | 頁首 |

| |

發表新主題

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