软体设计实例分享 教程课件

《软体设计实例分享 教程课件》由会员分享，可在线阅读，更多相关《软体设计实例分享 教程课件（122页珍藏版）》请在金锄头文库上搜索。

1、EA和團隊開發技巧 - UML、軟體開發與建構管理,Ringle Lai,Agenda,UML與軟體開發 軟體開發最佳實務 HSDc Team簡介與實際實務經驗分享 軟體建構管理實務(整合EA與Subversion),UML與軟體開發,為什麼需要UML,在建築業中，設計圖是一座建物中最重要的基礎，建物必須要依圖施工，才能夠保證建物的品質 軟體設計與建築相同，有品質的軟體必須要能夠依照設計圖施工，也必須要能夠依照設計圖檢驗 正因為設計圖的重要，因此，設計師在面對任何的開發團隊成員，都應該要採用統一的設計語言，這也就是為什麼目前所有的設計團隊都重視UML的原因 擁有一個好的UML工具，能夠讓程式碼

2、與設計圖合而為一，無論是從設計圖產生程式碼，或是從程式碼產生設計圖，都可以完整支援,UML可以幫助我們什麼？,讓團隊成員可以用共同的設計語言溝通 可以把團隊的設計心血完整記錄下來，以供日後參考 面對大型專案時，不同的開發團隊可以利用不同的UML圖形把焦點放在特定的一個領域中 十三種UML的圖形，可以涵括整個軟體設計各個不同面向的設計,什麼是UML不能做到的？,UML不能夠保證軟體一定設計的出來 這是屬於軟體開發流程的範疇 UML充其量祇是一個設計的共通語言，並不包括軟體開發流程的標準化 一般而言，軟體開發團隊必須要有自己適用的軟體開發流程，並配合該流程，決定使用的UML元件有哪些 HSDc所規

3、劃的開發流程，主要包括RA(需求蒐集)、HSD(高階系統設計)、DSD(詳細系統設計)、PG(程式寫作)、SI(系統整合)等流程，每一個不同流程，都有其適用的UML圖形,什麼是UML不能做到的？,使用UML並不能夠保證設計圖和未來寫出來的程式碼是一致的 這主要是專案管理面的問題 一般來說，大部分的專案在越接近交付的時間時，設計圖與程式碼的落差就會越大 由於時間的壓力，再加上沒有一個好的工具輔助做雙向的檢核，往往在專案完成後一年，設計圖和程式碼的差異就已經完全無法彌補 最終，使用UML變成祇是製作文件，而並非伴隨著軟體設計的產物,什麼是UML不能做到的？,使用UML並不能夠保證軟體能夠及時交付

4、這同樣是屬於軟體開發流程的範疇 在軟體開發流程中，應該盡可能使用I & I(Iteration & Incremental)的方法來開發，以減低開發的風險 在HSDc所規劃的軟體流程中，RA-HSD-DSD-PG-SI，整個完整的開發流程，應至多以一個禮拜為單位作一個循環，如此可以盡快瞭解整個專案的風險，並且快速反應使用者的需求,什麼是UML不能做到的？,使用UML並不能夠保證程式在交付時的正確性 這主要是屬於測試管理的範圍 一般來說，一個專案的成功與否，主要端視其是否擬定一個完整的測試計畫 測試計畫需要由使用單位與開發團隊來共同擬定 測試計畫的擬定，應該要在專案的需求蒐集階段就完成，並且隨著

5、需求的變動而隨之調整 測試程式的寫作則必須要在程式寫作之前完成，如此可以避免造假,關於UML與軟體設計,UML祇是軟體設計的通用平台，而軟體設計則包括開發流程規劃、架構設計、專案管理、建構管理、測試管理等不同的構面 UML在每一個不同的構面都可以提供相對應的協助，但最終來說，仍需要針對不同構面建構出團隊所需要的相關管理機制 HSDc主要是針對這幾個不同的管理構面提供顧問服務，包括規劃開發流程、輔導架構設計、建立管理制度 等相關的服務 以下，我們將提出幾個不同產業的實例與各位分享,大型家電廠的採購系統開發案例,案例背景說明,該專案為一家大型的家電製造商所開發的系統 該廠商的上游有多家的供應商，供

6、應不同的相關原料 當該廠商的生產單位在其ERP擬定生產計畫後，會將該年度的原料請購紀錄送至電子化採購系統，該電子化採購系統會自動產生RFP(Request For Purchase)，並利用簡訊系統以及Email給予註冊的供應商 供應商在收到簡訊或是Email後，必須要先到該廠商的電子化採購系統中，在採購要求所需的時間內提出報價單 該廠商的採購人員(Buyer)透過電子化採購系統進行比價，並且決定第一優先及第二優先順位的供應商，並產生採購單，同時透過簡訊系統以及Email通知該兩家供應商 供應商收到簡訊後，若是確認要進行供貨，必須在規定的期間內，到電子化採購系統確認採購單，電子化採購系統收到確

7、認後，會以Email通知廠商的負責採購人員 廠商採購人員到電子化採購系統確認採購單，電子化採購系統會將該採購單回傳至該廠商的ERP系統中,軟體開發流程設計,本專案共包括以下角色： RA：負責蒐集使用者的需求 Architect：負責整體系統架構設計，並且Review SA/SD與TD的設計規格 SA/SD：負責進行整體系統的高階設計，在本階段，並不考慮平台面的實體設計 Technical Designer (TD)：根據SA/SD的設計結果，加入平台面的實體設計，並且負責督促PG完成程式設計 PG：負責進行程式設計以及撰寫單元測試程式,軟體開發流程設計 續,上述的幾個角色的工作內容以及執掌，如

8、下圖所示：,軟體開發流程設計 續,軟體開發時間進程設計 本系統主要是利用 I&I 的方式進行設計，因此，每個Iteration以一週為單位 每個Iteration預計完成三個使用案例，並且在每一個Iteration交付後，由使用者直接進行兩個禮拜的測試，每一個使用案例則允許兩次的修改 以本專案為例，共有39個使用案例，因此，預計使用26週的時間進行開發(約六個月),架構設計,該系統必須要能夠與ERP系統溝通，除此之外，由於該家電廠商的工作流程系統是Notes平台，因此，也必須要能夠與Notes系統溝通 在設計上，HSDc建議使用軟體主機板的設計方式，搭配IBM MQ作為資料交換的平台 整體架構

9、設計如下圖,架構設計,利用UML Package Diagram表達系統架構,SA/SD產出,以產生RFP為例，在該設計中，下圖中的三個服務是EP開發團隊必須要完成的服務,SA/SD產出,針對上述的每一個Use Case，必須要寫下其使用案例敘述,SA/SD產出,每個Use Case會有對應的Sequence Diagram表達其實作,TD產出,針對HSD的Sequence Diagram，DSD應該要繪製平台面的相關設計,UML扮演的角色,上述所有不同角色的人員，都利用UML進行設計，各個角色的人員都可以透過UML來溝通 因此，針對各個不同角色的人，必須具備： 繪製及讀取UML設計圖的能力

10、使用UML工具的能力 針對Architect，則必須： 瞭解各個不同層次(SA/SD及TD)對於相同的Domain的UML表達之差異 規劃整體系統的架構規範,軟體開發最佳實務,以架構為中心(Architecture Centric),所謂的架構(Architecture)，就是希望擔任各類角色的軟體開發團隊，都能對系統有一致性(consistence)的全貌見解 軟體架構(Software Architecture)不只跟結構與行為有關，同時也跟背景環境有關，包括： 使用方式 功能性(Functionality) 效能 彈性 再使用性(Reuse) 可理解性(Comprehensibility

11、) 經濟效應與 技術的限制與取捨,以架構為中心(Architecture Centric),一般來說，軟體架構的可由三個主要觀點來觀察,軟體架構,需求觀點,結構觀點,實作觀點,系統外部的觀點 功能與非功能性 利用使用案例模型,重視系統的結構設計 表達重要的Domain Concept 利用類別圖以及循序圖,實際可執行的程式碼 與平台技術息息相關 利用自動化測試機制來檢驗,以架構為中心(Architecture Centric),在第一個時間點，架構師(Architect)必須要能夠確實定義自己所開發系統的範圍 利用使用案例圖(Use Case Diagram)可以幫助架構師釐清系統的範圍 利用

12、套件圖(Package Diagram)可以讓架構師瞭解模組與模組間的相依關係 利用複合結構圖(Composite Structure Diagram)可以讓架構師瞭解介面間的彼此相依關係 利用類別圖(Class Diagram)可以讓架構師確認Domain的重要概念,以架構為中心(Architecture Centric),使用案例圖與系統架構,共同的問題：忽略了系統範圍,以架構為中心(Architecture Centric),套件圖與系統架構,使用者,支援性系統,確認所要開發系統 的使用者 與支援性的系統,以架構為中心(Architecture Centric),複合結構圖與架構,明確定

13、義介面關係,以架構為中心(Architecture Centric),類別圖與架構,用Domain Concept 定義系統內部的結構,循環漸增(Iteration & Incremental),循環漸增的開發方式，最大的優點在於它把風險的問題儘早凸顯，並在較不衍生太多其它相關的問題時就事先處理,循環漸增(Iteration & Incremental),反覆式流程的開發方式有下列優點： 提早降低風險 較早能具有可視性(Visible)的進展(Progress) 較早能得到回饋，較可以得到使用者的保證(engagement)及適應性(adaptation)，由此再精緻(refine)系統的設計

14、，以更進一步契合使用者的需求 增加團隊的信心，並可以一直學習 產品的整體品質較佳,循環漸增(Iteration & Incremental),一般而言，當需求變化較大，系統範圍較不固定的系統，利用循環漸增的方式，能夠有效地面對改變的需求，快速反應 相反地，若是需求非常固定，且系統範圍不會有大幅度地修改，使用循環漸增和傳統的瀑布式開發模式，並沒有太大的差距 一般來說，循環漸增最大的潛在危機是：開發團隊成員無法忍受不確定性,軟體製程簡介,軟體製程簡介,軟體製程並非一成不變，和晶圓代工的製程一樣，面對不同的專案、不同的團隊成員，應該要調配出不同的製程，如此一來，才有可能讓整體的軟體產出具備良好的品質

15、 若以兩岸分工而言，HSDc所設計的軟體製程如下,軟體製程簡介,需求蒐集階段,在需求蒐集階段，RA與Architect應先針對所要開發的系統範圍進行兩方面的訪談 針對所面對的企業，應先瞭解該企業的主要企業流程，並且蒐集相關的企業規則，此部分的訪談對象應該是該企業的領域專家 至於局部性的需求，則應該對實際的操作人員進行訪談，並且記錄相關的功能性以及非功能性的需求 企業流程塑模可以利用UML的Activity Diagram或其擴充型態 - Eriksson-Penker Business Extensions來表達 局部需求蒐集，則可以利用使用案例模型來進行蒐集以及整理,企業流程塑模,Eriks

16、son-Penker Business Extensions的企業流程塑模,企業流程塑模,訂單處理的範例,企業流程塑模,當然，針對每一個Process的內涵，可以定義更詳細的工作流程 此時，可以利用UML的Activity Diagram來進行描述 當然，企業流程塑模的對象是領域專家，因此，一般來說，在進行企業塑模時，不宜介入過多的操作性的資訊,需求的蒐集與整理,一般來說，需求的蒐集通常是利用純文字把資料進行彙整 但是，我們可以透過UML的Extend的Requirement Diagram來整理這些需求,需求的蒐集與整理,非功能性的需求，我們也可以利用相同的圖形來進行蒐集,利用使用案例收斂需求,使用者的需求大都天馬行空，因此，我們必須要將訪談的重點盡量收斂在特定的焦點上 使用案例指的是對使用者而言，一個比較有意義的功能點，因此，利用使用案例來聚焦，通常會比較有效率 在使用案例中，一方面我們可以將過去所蒐集到的Requirement與使用案例進行對應，另一方面，也可以讓使用者進行腦力激盪，確認對他們而言有意義的需求,