1 / 122

EA 和團隊開發技巧 - UML 、軟體開發與建構管理

EA 和團隊開發技巧 - UML 、軟體開發與建構管理. Ringle Lai. Agenda. UML 與軟體開發 軟體開發最佳實務 HSDc Team 簡介與實際實務經驗分享 軟體建構管理實務 ( 整合 EA 與 Subversion). UML 與軟體開發. 為什麼需要 UML. 在建築業中，設計圖是一座建物中最重要的基礎，建物必須要依圖施工，才能夠保證建物的品質 軟體設計與建築相同，有品質的軟體必須要能夠依照設計圖施工，也必須要能夠依照設計圖檢驗

lydia
Download Presentation

EA 和團隊開發技巧 - UML 、軟體開發與建構管理

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EA和團隊開發技巧 - UML、軟體開發與建構管理 Ringle Lai

  2. Agenda • UML與軟體開發 • 軟體開發最佳實務 • HSDc Team簡介與實際實務經驗分享 • 軟體建構管理實務(整合EA與Subversion)

  3. UML與軟體開發

  4. 為什麼需要UML • 在建築業中，設計圖是一座建物中最重要的基礎，建物必須要依圖施工，才能夠保證建物的品質 • 軟體設計與建築相同，有品質的軟體必須要能夠依照設計圖施工，也必須要能夠依照設計圖檢驗 • 正因為設計圖的重要，因此，設計師在面對任何的開發團隊成員，都應該要採用統一的設計語言，這也就是為什麼目前所有的設計團隊都重視UML的原因 • 擁有一個好的UML工具，能夠讓程式碼與設計圖合而為一，無論是從設計圖產生程式碼，或是從程式碼產生設計圖，都可以完整支援

  5. UML可以幫助我們什麼？ • 讓團隊成員可以用共同的設計語言溝通 • 可以把團隊的設計心血完整記錄下來，以供日後參考 • 面對大型專案時，不同的開發團隊可以利用不同的UML圖形把焦點放在特定的一個領域中 • 十三種UML的圖形，可以涵括整個軟體設計各個不同面向的設計

  6. 什麼是UML不能做到的？ • UML不能夠「保證」軟體一定設計的出來 • 這是屬於「軟體開發流程」的範疇 • UML充其量祇是一個設計的共通語言，並不包括「軟體開發流程」的標準化 • 一般而言，軟體開發團隊必須要有自己適用的「軟體開發流程」，並配合該流程，決定使用的UML元件有哪些 • HSDc所規劃的開發流程，主要包括RA(需求蒐集)、HSD(高階系統設計)、DSD(詳細系統設計)、PG(程式寫作)、SI(系統整合)等流程，每一個不同流程，都有其適用的UML圖形

  7. 什麼是UML不能做到的？ • 使用UML並不能夠保證設計圖和未來寫出來的程式碼是一致的 • 這主要是「專案管理面」的問題 • 一般來說，大部分的專案在越接近交付的時間時，設計圖與程式碼的落差就會越大 • 由於時間的壓力，再加上沒有一個好的工具輔助做雙向的檢核，往往在專案完成後一年，設計圖和程式碼的差異就已經完全無法彌補 • 最終，使用UML變成祇是製作文件，而並非伴隨著軟體設計的產物

  8. 什麼是UML不能做到的？ • 使用UML並不能夠保證軟體能夠及時交付 • 這同樣是屬於「軟體開發流程」的範疇 • 在軟體開發流程中，應該盡可能使用「I & I」(Iteration & Incremental)的方法來開發，以減低開發的風險 • 在HSDc所規劃的軟體流程中，RA->HSD->DSD->PG->SI，整個完整的開發流程，應至多以「一個禮拜」為單位作一個循環，如此可以盡快瞭解整個專案的風險，並且快速反應使用者的需求

  9. 什麼是UML不能做到的？ • 使用UML並不能夠保證程式在交付時的正確性 • 這主要是屬於「測試管理」的範圍 • 一般來說，一個專案的成功與否，主要端視其是否擬定一個完整的測試計畫 • 測試計畫需要由使用單位與開發團隊來共同擬定 • 測試計畫的擬定，應該要在專案的需求蒐集階段就完成，並且隨著需求的變動而隨之調整 • 測試程式的寫作則必須要在程式寫作之前完成，如此可以避免造假

  10. 關於UML與軟體設計 • UML祇是軟體設計的通用平台，而軟體設計則包括「開發流程規劃」、「架構設計」、「專案管理」、「建構管理」、「測試管理」等不同的構面 • UML在每一個不同的構面都可以提供相對應的協助，但最終來說，仍需要針對不同構面建構出團隊所需要的相關管理機制 • HSDc主要是針對這幾個不同的管理構面提供顧問服務，包括規劃開發流程、輔導架構設計、建立管理制度 … 等相關的服務 • 以下，我們將提出幾個不同產業的實例與各位分享

  11. 大型家電廠的採購系統開發案例

  12. 案例背景說明 • 該專案為一家大型的家電製造商所開發的系統 • 該廠商的上游有多家的供應商，供應不同的相關原料 • 當該廠商的生產單位在其ERP擬定生產計畫後，會將該年度的原料請購紀錄送至電子化採購系統，該電子化採購系統會自動產生「RFP」(Request For Purchase)，並利用簡訊系統以及Email給予註冊的供應商 • 供應商在收到簡訊或是Email後，必須要先到該廠商的電子化採購系統中，在採購要求所需的時間內提出報價單 • 該廠商的採購人員(Buyer)透過電子化採購系統進行比價，並且決定第一優先及第二優先順位的供應商，並產生採購單，同時透過簡訊系統以及Email通知該兩家供應商 • 供應商收到簡訊後，若是確認要進行供貨，必須在規定的期間內，到電子化採購系統確認採購單，電子化採購系統收到確認後，會以Email通知廠商的負責採購人員 • 廠商採購人員到電子化採購系統確認採購單，電子化採購系統會將該採購單回傳至該廠商的ERP系統中

  13. 軟體開發流程設計 • 本專案共包括以下角色： • RA：負責蒐集使用者的需求 • Architect：負責整體系統架構設計，並且Review SA/SD與TD的設計規格 • SA/SD：負責進行整體系統的高階設計，在本階段，並不考慮平台面的實體設計 • Technical Designer (TD)：根據SA/SD的設計結果，加入平台面的實體設計，並且負責督促PG完成程式設計 • PG：負責進行程式設計以及撰寫單元測試程式

  14. 軟體開發流程設計 – 續 • 上述的幾個角色的工作內容以及執掌，如下圖所示：

  15. 軟體開發流程設計 – 續 • 軟體開發時間進程設計 • 本系統主要是利用 I&I 的方式進行設計，因此，每個Iteration以「一週」為單位 • 每個「Iteration」預計完成三個「使用案例」，並且在每一個「Iteration」交付後，由使用者直接進行兩個禮拜的測試，每一個「使用案例」則允許兩次的修改 • 以本專案為例，共有39個使用案例，因此，預計使用26週的時間進行開發(約六個月)

  16. 架構設計 • 該系統必須要能夠與ERP系統溝通，除此之外，由於該家電廠商的工作流程系統是Notes平台，因此，也必須要能夠與Notes系統溝通 • 在設計上，HSDc建議使用「軟體主機板」的設計方式，搭配「IBM MQ」作為資料交換的平台 • 整體架構設計如下圖

  17. 架構設計 • 利用UML Package Diagram表達系統架構

  18. SA/SD產出 • 以「產生RFP」為例，在該設計中，下圖中的三個服務是EP開發團隊必須要完成的服務

  19. SA/SD產出 • 針對上述的每一個Use Case，必須要寫下其使用案例敘述

  20. SA/SD產出 • 每個Use Case會有對應的Sequence Diagram表達其實作

  21. TD產出 • 針對HSD的Sequence Diagram，DSD應該要繪製平台面的相關設計

  22. UML扮演的角色 • 上述所有不同角色的人員，都利用UML進行設計，各個角色的人員都可以透過UML來溝通 • 因此，針對各個不同角色的人，必須具備： • 繪製及讀取UML設計圖的能力 • 使用UML工具的能力 • 針對Architect，則必須： • 瞭解各個不同層次(SA/SD及TD)對於相同的Domain的UML表達之差異 • 規劃整體系統的架構規範

  23. 軟體開發最佳實務

  24. 以架構為中心(Architecture Centric) • 所謂的架構(Architecture)，就是希望擔任各類角色的軟體開發團隊，都能對系統有一致性(consistence)的全貌見解 • 軟體架構(Software Architecture)不只跟結構與行為有關，同時也跟背景環境有關，包括： • 使用方式 • 功能性(Functionality) • 效能 • 彈性 • 再使用性(Reuse) • 可理解性(Comprehensibility) • 經濟效應與 • 技術的限制與取捨

  25. 以架構為中心(Architecture Centric) • 一般來說，軟體架構的可由三個主要觀點來觀察 系統外部的觀點 功能與非功能性 利用使用案例模型 需求觀點 軟體架構 實際可執行的程式碼 與平台技術息息相關 利用自動化測試機制來檢驗 重視系統的結構設計 表達重要的Domain Concept 利用類別圖以及循序圖 結構觀點 實作觀點

  26. 以架構為中心(Architecture Centric) • 在第一個時間點，架構師(Architect)必須要能夠確實定義自己所開發系統的範圍 • 利用「使用案例圖」(Use Case Diagram)可以幫助架構師釐清系統的範圍 • 利用「套件圖」(Package Diagram)可以讓架構師瞭解模組與模組間的相依關係 • 利用「複合結構圖」(Composite Structure Diagram)可以讓架構師瞭解介面間的彼此相依關係 • 利用「類別圖」(Class Diagram)可以讓架構師確認Domain的重要概念

  27. 常見的謬誤 正確的架構觀點 以架構為中心(Architecture Centric) • 「使用案例圖」與系統架構 共同的問題： 忽略了系統範圍

  28. 以架構為中心(Architecture Centric) • 套件圖與系統架構 支援性系統 確認所要開發系統 的使用者 與支援性的系統 使用者

  29. 以架構為中心(Architecture Centric) • 複合結構圖與架構 明確定義介面關係

  30. 以架構為中心(Architecture Centric) • 類別圖與架構 用Domain Concept 定義系統內部的結構

  31. 循環漸增(Iteration & Incremental) • 循環漸增的開發方式，最大的優點在於它把風險的問題儘早凸顯，並在較不衍生太多其它相關的問題時就事先處理

  32. 循環漸增(Iteration & Incremental) • 反覆式流程的開發方式有下列優點： • 提早降低風險 • 較早能具有可視性(Visible)的進展(Progress) • 較早能得到回饋，較可以得到使用者的保證(engagement)及適應性(adaptation)，由此再精緻(refine)系統的設計，以更進一步契合使用者的需求 • 增加團隊的信心，並可以一直學習 • 產品的整體品質較佳

  33. 循環漸增(Iteration & Incremental) • 一般而言，當需求變化較大，系統範圍較不固定的系統，利用循環漸增的方式，能夠有效地面對改變的需求，快速反應 • 相反地，若是需求非常固定，且系統範圍不會有大幅度地修改，使用循環漸增和傳統的瀑布式開發模式，並沒有太大的差距 • 一般來說，循環漸增最大的潛在危機是：開發團隊成員無法忍受「不確定性」

  34. 軟體製程簡介

  35. 軟體製程簡介 • 軟體製程並非一成不變，和晶圓代工的製程一樣，面對不同的專案、不同的團隊成員，應該要調配出不同的製程，如此一來，才有可能讓整體的軟體產出具備良好的品質 • 若以兩岸分工而言，HSDc所設計的軟體製程如下

  36. 軟體製程簡介

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

  38. 企業流程塑模 • Eriksson-Penker Business Extensions的企業流程塑模

  39. 企業流程塑模 • 訂單處理的範例

  40. 企業流程塑模 • 當然，針對每一個Process的內涵，可以定義更詳細的工作流程 • 此時，可以利用UML的Activity Diagram來進行描述 • 當然，企業流程塑模的對象是領域專家，因此，一般來說，在進行企業塑模時，不宜介入過多的操作性的資訊

  41. 需求的蒐集與整理 • 一般來說，需求的蒐集通常是利用「純文字」把資料進行彙整 • 但是，我們可以透過UML的Extend的Requirement Diagram來整理這些需求

  42. 需求的蒐集與整理 • 非功能性的需求，我們也可以利用相同的圖形來進行蒐集

  43. 利用使用案例收斂需求 • 使用者的需求大都天馬行空，因此，我們必須要將訪談的重點盡量收斂在特定的「焦點」上 • 使用案例指的是對使用者而言，一個比較「有意義」的「功能點」，因此，利用使用案例來聚焦，通常會比較有效率 • 在使用案例中，一方面我們可以將過去所蒐集到的Requirement與使用案例進行對應，另一方面，也可以讓使用者進行腦力激盪，確認對他們而言有意義的需求

  44. 利用使用案例收斂需求 • 使用案例對應至Requirement

  45. 利用使用案例收斂需求 • 當然，對於使用者與系統間的對話過程，我們也會利用使用案例敘述將之表達出來

  46. 利用使用案例收斂需求 • 至於每一個使用案例，也應該提出至少一個有關該使用案例的測試案例

  47. 系統的分析與設計 • 在系統的設計階段，應該先把平台面相關的知識先放在一邊，而應該思考有關Domain上的重要議題 • 一般來說，在這個階段中設計的類別，不外乎是分析型的類別，包括： • Control Object • Boundary Object • Entity Object

  48. 分析類別中的Control Object • Control object是屬於功能性的Object，而且這個功能與Use Case有相當密切的關係 • 一般來說，Control物件主要的任務是協調各種物件，讓物件彼此合作以達成Use Case所想達成的功能面的需求 • 在設計策略上，我們通常會讓每一個Use Case都有一個Control Object，這個Object就稱之為「UCO」(Use case Control Object)

  49. 分析類別中的Control Object • 下圖就是Control Object的示意圖

  50. 分析類別中的Boundary Object • Boundary Objec是屬於與外部橋接的Object，這類型的Object將會與外部直接接軌，受到外部的限制 • 就Use Case的觀點來看，所有跟外部Actor溝通的地方，都必須要加入一個Boundary物件 • Control Object與Boundary Object其實和Use Case的關係非常密切

More Related