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

HSDc Team

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

Ringle Lai

HSDc Team UML 與軟體設計

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

Subversion)

HSDc Team

UML 與軟體開發

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


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

HSDc Team UML 與軟體設計什麼是 UML 不能做到的？• UML 不能夠「保證」軟體一定設計的出來

– 這是屬於「軟體開發流程」的範疇– UML 充其量祇是一個設計的共通語言，並不包括「軟體開發流程」的標準化– 一般而言，軟體開發團隊必須要有自己適用的「軟體開發流程」，並配合該流程，決定使用的

UML 元件有哪些– HSDc 所規劃的開發流程，主要包括 RA( 需求蒐集 )、 HSD( 高階系統設計 )、 DSD( 詳細系統設計 )、 PG( 程式寫作 )、 SI( 系統整合 ) 等流程，每一個不同流程，都有其適用的 UML 圖形

HSDc Team UML 與軟體設計什麼是 UML 不能做到的？• 使用 UML 並不能夠保證設計圖和未來寫出來的程式碼是一致的

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

HSDc Team UML 與軟體設計什麼是 UML 不能做到的？• 使用 UML 並不能夠保證軟體能夠及時交付

– 這同樣是屬於「軟體開發流程」的範疇– 在軟體開發流程中，應該盡可能使用「 I & I」

(Iteration & Incremental) 的方法來開發，以減低開發的風險– 在 HSDc 所規劃的軟體流程中， RA->HSD-

>DSD->PG->SI ，整個完整的開發流程，應至多以「一個禮拜」為單位作一個循環，如此可以盡快瞭解整個專案的風險，並且快速反應使用者的需求

HSDc Team UML 與軟體設計什麼是 UML 不能做到的？• 使用 UML 並不能夠保證程式在交付時的正確性

– 這主要是屬於「測試管理」的範圍– 一般來說，一個專案的成功與否，主要端視其是否擬定一個完整的測試計畫– 測試計畫需要由使用單位與開發團隊來共同擬定– 測試計畫的擬定，應該要在專案的需求蒐集階段就完成，並且隨著需求的變動而隨之調整– 測試程式的寫作則必須要在程式寫作之前完成，如此可以避免造假

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

HSDc Team

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

HSDc Team UML 與軟體設計案例背景說明– 該專案為一家大型的家電製造商所開發的系統– 該廠商的上游有多家的供應商，供應不同的相關原料– 當該廠商的生產單位在其 ERP擬定生產計畫後，會將該年度的原料請購紀錄送至電子化採購系統，該電子化採購系統會自動產生「 RFP」 (Request For Purchase) ，並利用簡訊系統以及 Email給予註冊的供應商

– 供應商在收到簡訊或是 Email 後，必須要先到該廠商的電子化採購系統中，在採購要求所需的時間內提出報價單 – 該廠商的採購人員 (Buyer)透過電子化採購系統進行比價，並且決定第一優先及第二優先順位的供應商，並產生採購單，同時透過簡訊系統以及 Email 通知該兩家供應商 – 供應商收到簡訊後，若是確認要進行供貨，必須在規定的期間內，到電子化採購系統確認採購單，電子化採購系統收到確認後，會以

Email 通知廠商的負責採購人員 – 廠商採購人員到電子化採購系統確認採購單，電子化採購系統會將該採購單回傳至該廠商的 ERP 系統中

HSDc Team UML 與軟體設計軟體開發流程設計•本專案共包括以下角色：

– RA：負責蒐集使用者的需求– Architect：負責整體系統架構設計，並且

Review SA/SD與 TD 的設計規格– SA/SD：負責進行整體系統的高階設計，在本階段，並不考慮平台面的實體設計– Technical Designer (TD)：根據 SA/SD 的設計結果，加入平台面的實體設計，並且負責督促

PG 完成程式設計– PG：負責進行程式設計以及撰寫單元測試程式

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

HSDc Team UML 與軟體設計軟體開發流程設計 – 續• 軟體開發時間進程設計

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

HSDc Team UML 與軟體設計架構設計• 該系統必須要能夠與 ERP 系統溝通，除此之外，由於該家電廠商的工作流程系統是

Notes平台，因此，也必須要能夠與 Notes系統溝通• 在設計上， HSDc 建議使用「軟體主機板」的設計方式，搭配「 IBM MQ 」作為資料交換的平台• 整體架構設計如下圖

HSDc Team UML 與軟體設計架構設計• 利用 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 設計圖的能力– 使用 UML 工具的能力

•針對 Architect ，則必須：– 瞭解各個不同層次 (SA/SD及 TD) 對於相同的

Domain的 UML表達之差異– 規劃整體系統的架構規範

HSDc Team

軟體開發最佳實務

HSDc Team UML 與軟體設計以架構為中心 (Architecture Centric)

• 所謂的架構 (Architecture) ，就是希望擔任各類角色的軟體開發團隊，都能對系統有一致性(consistence) 的全貌見解

• 軟體架構 (Software Architecture) 不只跟結構與行為有關，同時也跟背景環境有關，包括：– 使用方式– 功能性 (Functionality)– 效能– 彈性– 再使用性 (Reuse)– 可理解性 (Comprehensibility)– 經濟效應與– 技術的限制與取捨


• 一般來說，軟體架構的可由三個主要觀點來觀察

軟體架構

需求觀點

結構觀點實作觀點

系統外部的觀點功能與非功能性利用使用案例模型

重視系統的結構設計表達重要的 Domain Concept利用類別圖以及循序圖實際可執行的程式碼與平台技術息息相關利用自動化測試機制來檢驗


• 在第一個時間點，架構師 (Architect) 必須要能夠確實定義自己所開發系統的範圍– 利用「使用案例圖」 (Use Case Diagram) 可以幫助架構師釐清系統的範圍– 利用「套件圖」 (Package Diagram) 可以讓架構師瞭解模組與模組間的相依關係– 利用「複合結構圖」 (Composite Structure

Diagram) 可以讓架構師瞭解介面間的彼此相依關係– 利用「類別圖」 (Class Diagram) 可以讓架構師確認 Domain 的重要概念


• 「使用案例圖」與系統架構常見的謬誤正確的架構觀點

財會系統

應收帳結帳

財會系統

排程系統

結算應收帳款

ERP 系統

銷售子系統

結算每日銷售資訊

財務管理子系統

ERP 系統

排程系統

結算每日銷售資訊

共同的問題：忽略了系統範圍


•套件圖與系統架構管理人員

Storage Service System

Embedded OS

Web Server

FTP Server

使用者

支援性系統

確認所要開發系統的使用者與支援性的系統


•複合結構圖與架構BPM_System

Workflow_Kernel

Default_Process_Definition Default_Rule_Engine

Default_Organization

Other_Process_Definition_System

WFMC_Interface_1

Active_Directory

LDAP

Other_Rule_EngineRulableWFMC_Interface_1

Need_Rule

LDAP

Process定義介面 Rule執行介面

組織定義介面明確定義介面關係


•類別圖與架構

出差旅費申請流程

+ () : String決定下一關卡審核人員+ (String) : String取得目前流程

Instance流程

- m_ : Documentation參考文件

+ Document (String) : void設定資訊+ (String) : String取得目前流程+ () : void送審<<property get>>+ get () : 規則性規則性<<property set>>+ set ( ) : void規則性規則性

<<interface>>規則性

+ () : String決定下一關卡審核人員

請假流程

+ () : String決定下一關卡審核人員+ (String) : String取得目前流程

-m_規則

1

用 Domain Concept定義系統內部的結構

HSDc Team UML 與軟體設計循環漸增 (Iteration & Incremental)

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


•反覆式流程的開發方式有下列優點：– 提早降低風險 – 較早能具有可視性 (Visible) 的進展 (Progress) – 較早能得到回饋，較可以得到使用者的保證

(engagement) 及適應性 (adaptation) ，由此再精緻 (refine) 系統的設計，以更進一步契合使用者的需求 – 增加團隊的信心，並可以一直學習– 產品的整體品質較佳


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

HSDc Team

軟體製程簡介

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

HSDc Team UML 與軟體設計軟體製程簡介

HSDc Team UML 與軟體設計需求蒐集階段• 在需求蒐集階段， RA與 Architect 應先針對所要開發的系統範圍進行兩方面的訪談

– 針對所面對的企業，應先瞭解該企業的「主要企業流程」，並且蒐集相關的「企業規則」，此部分的訪談對象應該是該企業的「領域專家」– 至於局部性的需求，則應該對實際的「操作人員」進行訪談，並且記錄相關的功能性以及非功能性的需求

• 企業流程塑模可以利用 UML的 Activity Diagram或其擴充型態 - Eriksson-Penker Business Extensions 來表達

• 局部需求蒐集，則可以利用「使用案例模型」來進行蒐集以及整理

HSDc Team UML 與軟體設計企業流程塑模• Eriksson-Penker Business Extensions的企業流程塑模

HSDc Team UML 與軟體設計企業流程塑模•訂單處理的範例ʳ

訂購業務處理

ʳ

開立發票

ʳ

收到貨款

ʳ

準備訂單內商品

ʳ

處理出貨

收到訂單結束訂購

ʳ

<<goal>>處理客戶訂單與出貨事宜

ʳ

<<部門>>出貨部門

ʳ

<<部門>>財務部門

<<entity>>訂購資訊

<<supply>><<achieve>>

<<support>><<support>>

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

HSDc Team UML 與軟體設計需求的蒐集與整理• 一般來說，需求的蒐集通常是利用「純文字」把資料進行彙整•但是，我們可以透過 UML的 Extend的

Requirement Diagram 來整理這些需求

HSDc Team UML 與軟體設計需求的蒐集與整理• 非功能性的需求，我們也可以利用相同的圖形來進行蒐集

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

HSDc Team UML 與軟體設計利用使用案例收斂需求• 使用案例對應至 Requirement

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

HSDc Team UML 與軟體設計利用使用案例收斂需求• 至於每一個使用案例，也應該提出至少一個有關該使用案例的測試案例

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

– Control Object– Boundary Object– Entity Object

HSDc Team UML 與軟體設計分析類別中的 Control Object• Control object 是屬於功能性的 Object ，而且這個功能與 Use Case 有相當密切的關係 • 一般來說， Control 物件主要的任務是協調各種物件，讓物件彼此合作以達成 Use

Case 所想達成的功能面的需求• 在設計策略上，我們通常會讓每一個 Use

Case 都有一個 Control Object ，這個Object 就稱之為「 UCO」 (Use case Control Object)

HSDc Team UML 與軟體設計分析類別中的 Control Object• 下圖就是 Control Object 的示意圖

HSDc Team UML 與軟體設計分析類別中的 Boundary Object• Boundary Objec 是屬於與外部橋接的Object ，這類型的 Object將會與外部直接接軌，受到外部的限制

•就 Use Case 的觀點來看，所有跟外部Actor 溝通的地方，都必須要加入一個Boundary 物件

• Control Object與 Boundary Object 其實和 Use Case 的關係非常密切

HSDc Team UML 與軟體設計分析類別中的 Boundary Object• Boundary Object如下所示

HSDc Team UML 與軟體設計分析類別中的 Entity Object• Entity object 是屬於系統本質面的概念性的Object ，這類型的 Object 不會隨著 Use Case 的增多而有所變動

• Entity 物件主要是將資訊及資源封裝起來，因此其定義相當明確• 就系統的設計來說， Entity 物件代表了企業中的重要概念，因此，這樣的物件的變動性會比較低• 從設計的觀點來說，這類型的物件，可以說是軟體設計中最重要的一部份

HSDc Team UML 與軟體設計分析類別中的 Entity Object• 要找 Entity Object ，大都是需要比較具備經驗的 SA 才有辦法將這些物件找出來•但是，我們其實可以利用 Peter Coad的

Transaction Pattern 幫助我們尋找 Entity Objectcd Transaction Pattern

Actor Paticipant Transaction

TransactionLineItemItem

SubsequentTransaction

SubsequentTransactionLineItem

SpecificItem

Place

1 * 1 *

1..*

1

1 *

1 *

1..*

1

1 *

1

*

*

1

*

11

*

HSDc Team UML 與軟體設計分析類別中的 Entity Object• 下圖就是維修系統的 Entity Object

HSDc Team UML 與軟體設計系統的分析與設計• 系統除了靜態的類別結構外，另外我們針對每一個 Use Case ，都應該要繪製一個「物件合作」的「循序圖」，來驗證我們的靜態結構能夠滿足使用者對於系統的需求• 在循序圖中，主要要表達每一個 Use Case敘述中的每一段「使用者與系統」的互動過程，都可以被滿足• 也因此，循序圖一般被稱之為「系統動態結構圖」

HSDc Team UML 與軟體設計系統的分析與設計• 利用循序圖表達物件合作關係sd 判斷保固期Relization-First Step

維修中心判斷保固期_Client 判斷保固期UCO 中心廠

ERP_Adapter

中心廠ERP

1. 維修中心人員提供維修品的序號給系統

2. 系統提供維修品的序號給中心廠ERP

3. 中心廠ERP提供出貨日期、製造日期及客戶等級給系統

4. 系統根據Business Rule BR1判斷該維修品是否超過保固期

維修交易顧客筆記型電腦

alt

[ =A]顧客等級

[ =B]顧客等級

Submit( )維修品序號

boolean:= ( )查詢是否超過保固期維修品序號

String:= ( )查詢維修品資訊維修品序號

String:= // ( )查詢維修品資訊維修品序號

boolean:= BusinessRule ( )根據判斷是否超過保固期出貨資訊

boolean:= ()判斷是否超過保固期

String:= ()提供顧客等級

Date:= ()提供購買日期

Date:= ()提供製造日期


Technical Designer 的平台設計• 一般來說， Technical Designer 必須要把

SA/SD 的設計產出，加入有關平台面的知識，並且將之表達出來• 通常來說，為了能夠確切表達平台相關知識，可以利用 UML的 Composite Structure

Diagram 來進行表達•除此之外， TD 也可以把對應的設計觀念，利用表列式的方式加以說明•如果對於 SA/SD 的設計圖有所變動的話， TD 應該要繪製對應的設計圖，以方便

Architect進行比對


Technical Designer 的平台設計• SA/SD與 TD 的對應設計表分析類別 .NET 技術Control Object 1.使用 Base Class Libray

2.用 .NET的 Class Libray 來實作Boundary Object – Client 1.使用 Windows Form 實作；或

2.使用 Web Form 實作 (ASP .NET 技術 )

Boundary Object – Boundary 1.使用 XML Class Library2.使用 XML Web Services Client端 Class3.用 .NET的 Class Library 來實作

Boundary Object – PO 1.使用 ADO.NET2.用 .NET的 Class Library 來實作

Entity Object 1.使用 Base Class Library2.用 .NET的 Class Library 來實作


Technical Designer 的平台設計• SA/SD與 TD 的對應設計表分析類別名稱設計類別名稱設計類別 Namespace

判斷保固期 UCO ConsiderWarrantyUco IDM.RepairSystem.Control

判斷保固期 _Client ConsiderWarrantyClient IDM.RepairSystem.Web

中心廠 ERP_Adapter WarrrantyERPAdapter IDM.RepairSystem.Boundary

產品 Product IDM.RepairSystem.Entity

筆記型電腦 Notebook IDM.RepairSystem.Entity

維修中心 RepairCenter IDM.RepairSystem.Entity

維修交易 RepairTransaction IDM.RepairSystem.Entity

維修交易細項 RepairTransactionItem IDM.RepairSystem.Entity

顧客 Customer IDM.RepairSystem.Entity


Technical Designer 的平台設計• TD 的設計圖

Customer

- address: string- level: string- name: string

+ Customer()- ~Customer()+ Dispose() : void<<create>>+ Customer(string, string, string)<<property>>+ Address() : string+ CustomerLevel() : string+ Name() : string

Notebook

- issuedDate: DateTime- purchasedDate: DateTime- serialNo: string+ m_Product: Product

+ Notebook()- ~Notebook()+ Dispose() : void<<create>>+ Notebook(string, DateTime, DateTime)<<property>>+ IssuedDate() : DateTime+ PurchasedDate() : DateTime+ SerialNo() : string

Product

- name: string- type: string

+ Product()- ~Product()+ Dispose() : void<<create>>+ Product(string, string)<<property>>+ Name() : string+ Type() : string

RepairCenter

- address: string- name: string

+ RepairCenter()- ~RepairCenter()+ Dispose() : void<<create>>+ RepairCenter(string, string)<<property>>+ Address() : string+ Name() : string

RepairTransaction

- issueDate: DateTime- m_RepairTransactionItem: ArrayList- repairDate: DateTime- repairNumber: string- requestDate: DateTime+ m_Notebook: Notebook- mRepairTranactionItems: RepairTransactionItem+ m_Customer: Customer+ m_RepairCenter: RepairCenter

+ RepairTransaction()- ~RepairTransaction()+ Dispose() : void+ CreateItems(ICollection) : void+ IsWarranty() : bool<<create>>+ RepairTransaction(string, DateTime, DateTime, DateTime)<<property>>+ IssueDate() : DateTime+ RepairDate() : DateTime+ RepairTransactionItem() : ArrayList+ RequestDate() : DateTime+ RMANumber() : string

RepairTransactionItem

- defect: string- solvedDate: DateTime- symptom: string

+ RepairTransactionItem()- ~RepairTransactionItem()+ Dispose() : void<<create>>+ RepairTransactionItem(string, string, DateTime)<<property>>+ Defect() : string+ SolvedDate() : DateTime+ Symptom() : string

1..*1

1..*

1

1..*

1

-mRepairTranactionItems1..*1

HSDc Team UML 與軟體設計.NET 中的細部設計分享 – Virtual DB

• 前面所說的設計方式，主要是傳統的物件導向式的設計，在該種設計方式中，其實有許多所謂的「物件」，都僅僅只存在著取值(getter) 及設值 (setter) 的函式

•事實上，在現在的設計環境中，所有的資料值，其實都可以利用 XML 來進行傳遞• 由於 XML 具備結構，而且又只是標準的字串，因此，利用 XML進行資料傳遞，既可以保有資料的結構性，又可以讓參數簡單化，因此，在設計上，這已經是不可檔的趨勢


•然而，在設計上，這又必須面臨另外一個令人頭痛的問題 – XML Parsing•針對一個簡單的 XML字串，我們必須要撰寫複雜的 XML Parsing 程式，才能夠取得其對應的值•在 .NET 中，為了解決這個問題，便提出了「 DataSet 」的 Solution

• 我們可以利用 .NET 的「 DataSet 」設計工具，定義 XML 的標準 Schema ，然後直接利用 .NET 所產生的「取值」及「設值」函式來進行資料的存取


• 這個 DataSet 的存取，就好像是在Memory 中設了一個虛擬的 DataBase ，讓各自的 Service 可以對自己私有的DataBase進行存取，這個概念，稱之為「 Virtual DB 」

•若我們導入 Virtual DB 的概念，則我們的設計圖，將會變成如下的樣子


System.Data.DataTableCustomer

System.Data.DataTableNotebook

System.Data.DataTableProduct

System.Data.DataTableRepairCenter

System.Data.DataTableRepairTransaction

System.Data.DataTableRepairTransactionItem

System.Data.DataSetVirtualDB


• 也因此，在運作上，我們變成直接針對虛擬DB 來進行運作，因此，在 Technical Designer 的設計圖，將會變成像這個樣子

Data存在 VDB 中

:維修中心

:ConsiderWarrantyUco:ConsiderWarrantyClient :VirtualDB :WarrantyERPAdapter

:中心廠ERP

:RepairTransaction

Submit(SerialNo) :bool

IsWarranty(SerialNo) :bool

QueryRepairItem(vdb) :VirtualDB

// 查詢維修品資訊

// Set Data to VDB

IsWarrantyByRule(vdb) :bool

IsWarranty(vdb) :bool

// Get Data From VDB


PG 的程式寫作 – 測試先行• 對於 PG 的設計來說，其首先取得的，主要是由 TD 所提供的「循序圖」以及程式碼的框架• TD 所提供的程式碼框架，應該要說明每一個程式碼的內涵•除此之外，針對每一個 Control 物件， PG應該要知道該 Control 物件中的每一個

Method 所對應的實際測試案例


PG 的程式寫作 – 測試先行•針對每一個 Control Object， PG 所獲得的程式碼框架應如下所示：


PG 的程式寫作 – 測試先行測試案例名稱未超過保固期測試 -1

敘述給予保固期內的產品序號 (客戶等級為 A) ，回傳未超過保固期輸入值產品序號： SN00001

預期產出回傳未超過保固期

HSDc Team

軟體建構管理實務 - 整合 Subversion與 EA

HSDc Team UML 與軟體設計建構管理的原理• 建構管理的目的

– 讓系統在建構的過程中，可以追蹤並且管理整個建構的過程– 系統的建構 ( 無論是軟體、硬體或是韌體 ) 其實是一連串逐步建置的過程– 在這個建置過程中，當然會遇到有關「 Change 」的管理以及團隊合作相關的 Issue– 因此，建構管理的主要目的就是在控制以及管理上述的 Change 以及團隊合作相關的主題– 針對軟體的建構，則這個主題又被擴大稱之為「軟體建構管理」 (Software Configuration

Management; SCM)

HSDc Team UML 與軟體設計建構管理的原理• SCM 的定義

– software configuration management (SCM) is a “set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.”(From Roger Pressman (in his book) Software Engineering: A Practitioner's Approach)

HSDc Team UML 與軟體設計建構管理的原理• 也就是說，軟體建構管理主要是針對「建構期間的產品」 (work products) ，管理其版本 (manage version) 以及控制其改變 (control change) ，並且針對這些改變提供相關的審核 (audit) 以及報告 (report) 的機制• 一般來說，軟體建構的過程通常如下圖所示：

ref. SCM Terminology Presentation from SCM Community Web Site

HSDc Team UML 與軟體設計建構管理的原理• 建構管理的重要假設：

– 針對不同的專案、不同的時間點，我們必須要掌握一個主要路徑的原則– 針對不同的開發版本，則需要在不同的的分支中

Release 各個不同的正式版本，並且在適當的時機點匯入到主要路徑中– 如此一來，整體的開發將會在同一個主要路徑中被控制以及管理

HSDc Team UML 與軟體設計建構管理的原理• SCM 的意涵

– 第一層意涵是屬於管理層面的• 必須要擬定一個管理的機制以及管理的結構• 主要目的就是讓開發人員能夠按照該機制將文件以及程式碼納入管理，並養成習慣隨時將這些資料更新至管理的儲庫 (Repository)之中

– 第二層意義則是其使用的工具• 必須要選擇一個特定的使用工具• 由於不同的工具會有不同的特性，最好在選定工具後就盡量不要再更換

HSDc Team UML 與軟體設計建構管理的原理• 一般來說， SCM 的整體活動，應該如下圖所示

ref. Configuration Management Principles and Practice By Anne Mette Jonassen Hass

HSDc Team UML 與軟體設計建構管理的原理• CM 的核心主要是放在 Development 階段各個

Release 的儲存 ( 上圖中 Storage 的部分 ) 以及整體有關 Change 的管理 ( 上圖中 Change control 的部分 )

• 與之搭配的，則是有關整體專案人員的相關識別資料 (Identification) 以及相關的追蹤管理(Status Reporting)

• 這些所有相關的資料，都會放置在稱之為「Metadata 」的儲存庫 (Repository) 中

• 至於整個 CM 所能夠管理的單元，一般我們稱之為「 Comfiguration Management Items」

HSDc Team UML 與軟體設計建構管理的原理• 以下，用一張 Class Diagram 來描述「 Comfiguration Management Items 」

HSDc Team UML 與軟體設計建構管理的原理• SCM 所能夠控管的範圍，主要仍是在可電子化的部分，至於 Physical Item ，則需要利用管理的相關機制來進行相關的控管• SCM 所能夠控管的，主要包括

– 開發的文件 (Development Document) ，以及– 開發程式碼 (Source Code)

• 至於實際的執行程式碼 (Binary Code) ，其實並非整體 CM 所應該控管的範圍

HSDc Team UML 與軟體設計版本控管機制的建立• 在這個部分，我們將介紹利用 Subversion來完成版本控管機制的建立• Subversion 是一個 Open Source 的專案，其主要是著眼於原先的另一個 Open Source的專案 – CVS 有太多的問題，因此，希望可以建立一個更為簡潔、能力更強的版本控管軟體• Subversion 主要服務的建構管理對象，仍是在 SCM 的範疇中，因此，使用

Subversion 可以解決 SCM 中大部分的問題

HSDc Team UML 與軟體設計版本控管機制的建立• Subversion 的架構如下圖所示：

HSDc Team UML 與軟體設計版本控管機制的建立• 安裝 Subversion

– Subversion 是屬於一個 light weight的 SCM容器，也因此， Subversion 其實並不一定需要安裝一個Subversion的 Server

– 從上圖可以知道，如果你使用 Http 通訊協定來存取Subversion的 Repository ，則你只需要將兩個檔案複製到 Apache 的相關目錄，則 Subversion 就可以運作了

– 當然，如果你要利用 Subversion 的通訊協定 -svn 來進行存取，則你必須要啟動一個 svnadmin 的服務– 如果是在 Repository的 local端進行存取的話，則什麼通訊協定都不需要了

HSDc Team UML 與軟體設計版本控管機制的建立• Subversion Server端的安裝 - 1

– 因此， Subversion 的安裝非常簡單，你只要Download 相對平台的 Subversion 的壓縮檔，然後解壓縮，如果有必要的話，就在環境變數中加入 Subversion 的對應執行目錄到 path 中即可 ( 目前最新的 Subversion版本為 1.4.5)

步驟一：打開壓縮檔步驟二：解壓縮步驟三：建立環境變數

HSDc Team UML 與軟體設計版本控管機制的建立• Subversion Server端的安裝 – 2

– 安裝 Apache Server•請直接到 Apache 的網站 Download Apache Http

Server 的安裝檔，目前 Subversion 1.4.5 已經Support Apache 2.2 ，因此，請下載最新的版本即可 ( 目前最新的版本為 2.2.6)

步驟一：按照 Default一步一步安裝 Apache步驟二： Copy檔案

步驟三：修改 Apache的 Config檔

HSDc Team UML 與軟體設計版本控管機制的建立• Subversion Client端的安裝

– 一般來說，在 Subversion的 Server端並沒有相關的圖形化管理工具，只能夠透過標準的Subversion Command Mode去執行 Server端的管理

– 為了要比較容易操作 Subversion ，通常會在Server Side安裝一個 Subversion的 Client端工具來幫忙管理

– 以Windows 的環境來說，通常是使用跟Windows Explorer 整合的 TortoiseSVN 來作為這個 Client端的工具

HSDc Team UML 與軟體設計版本控管機制的建立• 建立 Server端的 Repository

– Subversion的 Repository 是以非常自由的方式來建立，你可以在任何可以存取的 Directory建立 Repository– 一般來說，若要採取中央集權的方式來控管的話，你可以建立一個 SVN/Repository 的子目錄來集中管理所有的 Repository– 我們在該目錄下，建立一個「 HsdcDemoSVN」的子目錄，並利用 TortoiseSVN 來建立

Repository( 利用 BerkleyDB格式 )

HSDc Team UML 與軟體設計版本控管機制的建立• 建立 Server端的 Repository – 2

– 利用 TortoiseSVN 建立 Repository

– 在 Apache的 Config檔建立 DAV Location 的位置，並指向Repository

步驟一：建立目錄結構步驟二：建立 Repository 步驟三：選擇 Repository格式步驟四：完成後的 Repository

步驟一：修改 Location位置步驟二：重開 Apache 步驟三：利用 Browser查詢 Repository

HSDc Team UML 與軟體設計版本控管機制的建立• 建立 Authority機制 ( 使用 Basic Auth)

步驟一：建立 Password file 步驟二：設定 Config 步驟一：進入 Repository 時，會要求 Authorization

HSDc Team UML 與軟體設計版本控管機制的建立•按照軟體建構的基本理論：

•在 Subversion 中分別可以利用Trunk、 Branch 以及 Tag 來完成上述的幾個階段

HSDc Team UML 與軟體設計版本控管機制的建立• Trunk

– 指的是整個軟體開發的「主要路徑」，在「主要路徑」中，只放經由 PM 或是 QA認可的相關開發文件以及程式碼– 其他的軟體建構工具稱之為「 Baseline 」

• Branch– 指的是開發人員所負責的副本，對開發人員來說， Branch 是開發階段的產物，至於最終的結果，應該交由 PM 或是 QA人員來進行處理

• Tag– 指的是專案進行中的特定 MileStone ，通常是一個

Release 或是一個 Version– 一般來說， Tag 也可以稱之為 Baseline的 Snapshot

HSDc Team UML 與軟體設計Subversion Repository 的專案規劃• 我們以一個假設的專案 (ExampleProject) 為例• 在該專案中，共有四個專案成員，分別是：

– Kenming – 擔任 Architect及Developer– Cathy – 擔任 PM– Ringle – 擔任 Developer– QA – 擔任 QA

• 在專案 Repository 的設計上，分別如下：– Repository – HsdcDemoSVN– Project – HsdcDemoSVN/ExampleProject– Trunk - HsdcDemoSVN/ExampleProject/trunk– Branches -

HsdcDemoSVN/ExampleProject/branches/private/kenmingHsdcDemoSVN/ExampleProject/branches/private/cathyHsdcDemoSVN/ExampleProject/branches/private/ringleHsdcDemoSVN/ExampleProject/branches/private/qa

– Tags - HsdcDemoSVN/ExampleProject/tags

HSDc Team UML 與軟體設計Subversion Repository 的專案規劃• PM 建立 Project結構• PM (Cathy) 需要先在自己的 local端建立一個目錄結構，並且將該目錄結構 Import到 Repository 中

步驟一：建立目錄結構步驟二： Import 目錄結構步驟三：選擇 Repository 步驟四：認證


Subversion 與設計產出• 下圖是 EA 與版本控管機制間的關係圖


Subversion 與設計產出•根據前面的關係圖，我們可以得知

Architect 在第一個階段，應該要先架構出第一個版本的 UML 專案規劃，並且把相關產出匯入到 Database( 此例中為 SQL Server) 中

• 接著， Architect 要在 EA 中設定Subversion

• 最後，將所有的產出寫入到 Subversion的trunk/model 中


Subversion 與設計產出• Architect (Kenming) 的操作如下所示：

步驟一：轉移專案至 DB 步驟二：設定路徑步驟三：取得Model Repository

步驟四：設定 Version Control 步驟五： Config Package 步驟六：完成 Version Control


Subversion 與設計產出• 接著， Developer Kenming 以及 Ringle分別把該 Trunk 的版本， Branches 到各自的 branches 中進行操作

步驟一：對 Model 建立分支步驟二：設定分支的位置


Subversion 與設計產出• 在第一個 Milestone – release 1.1 中，由

Architect (Kenming) 把兩者間衝突的Model進行Merge 後，放至 Trunk ，並且記錄一個 tag為 1.1 ，並且把所有 tag為1.1 的產出寫入到 tags 目錄下的 1.1


Subversion 與設計產出• Architect Merge 步驟一：Merge


Subversion 與設計產出•版本圖


Subversion 與文件產出• 在專案進行的過程中，會有許多的相關文件• 這些文件的格式通常會是 Office 的格式•在 Subversion 中， Office 的檔案格式沒有辦法直接由 Office進行存取，因此，必須透過像 TortoiseSVN 來進行存取•回到我們的範例專案， PM Cathy新增了一個執行計畫，則該計畫目前應該要放在「 trunk->project_doc 」

• 相同地，我們 PM 就可以直接把該檔案匯入到 Repository 中


Subversion 與文件產出• PM Cathy 的工作

•當然，若要開始編寫該執行計畫，仍應該要把這一份資料 Branch到 cathy 的目錄下進行修正


Subversion 與開發產出• Subversion v.s. Eclipse

– Subversion與 Eclipse 的結合非常密切，你必須要先在 Eclipse 上安裝一個 Plug-in Subclipse (按照 Eclipse 的版本，在 Find and Install Update 中新增一個 Remote Update Site)

– 接著，你就可以直接在 Eclipse 上操作Subversion 的相關指令了

– 我們以 Eclipse 3.3 為例，我們所安裝的Subclipse 的版本則是 1.2.x


Subversion 與開發產出• Developer Ringle 的操作

– 先設定 Subclipse 的環境

– 接著，到專案環境中把 Source Code 以及專案設定送到版本控管


Subversion 與開發產出

• 當然， Developer 要真的進行開發時，仍然要使用 Branches 的方式來設定工作區，如此才可以享受到團隊開發的好處


Subversion 與開發產出• Subversion v.s. VS .NET 2005

– 在 VS .NET 2005 中要與 Subversion 溝通，也必須要透過一些外掛的程式– 以 Freeware 來說，主要是有 anhk 這個

Freeware 的專案– 但若需要整合 VS .NET 2005 的團隊功能的話，則可以考慮 PushOK 的相關整合版本– 以 anhk 而言，其主要是在 VS .NET的 Add-in中加入其自己的相關 Subversion操作指令– 而 PushOK則是整合到 VS的 Team 開發環境裡


Subversion 與開發產出• Developer Ringle 的操作 (PushOK)

– 設定環境


Subversion 與開發產出


附錄一、公司介紹HSDc (High-quality Software Design

Center)

HSDc Team UML 與軟體設計使命、目標與願景•使命 (Mission) – 提升及協助軟體開發人員在軟體設計的專業技能及必備素養 •目標 (Goal) – 把軟體做 ”軟”。(Keeping Software Soft !! )

•願景 (Vision) – 成為大中華地區的專業軟體設計中心。

HSDc Team UML 與軟體設計核心刺蝟原則

HSDc Team UML 與軟體設計軟體設計的重視方向• 重視軟體設計的思維與基本功

– 從本質看軟體設計• 設計與實做，是一體兩面。

– 軟體設計是人性化、生活化，非純工程與技術。• 重視

– 觀照整體的能力。– 軟體整體的架構 (Architecture) 與結構

(Structure)

HSDc Team UML 與軟體設計經營策略與方向• 三合一

– 顧問 (Consultant)– 教育 (Education)– 產品 (Product) 代理

HSDc Team UML 與軟體設計顧問 (Consultant)服務項目• 大型應用系統的主機板 (Motherboard)架構設計，包括異質系統、 Legacy 系統、異質資料庫與作業系統平台的整合與建置規劃。 • 協助客戶快速建立原型 (Prototype) 系統，打通技術環節、驗證系統架構。• 根據企業客戶的實際軟硬體環境，規劃與設計配套的軟體設計實務課程。• 協助與指導規劃開發團隊建置 Macro and Micro Process 與產出 (Artifacts)。• 指導客戶外包 (Outsourcing) 的規劃與品質驗收。• 協助與指導客戶在實際案子的軟體設計建置與規劃，包括在塑模工具上的使用。

HSDc Team UML 與軟體設計軟體設計的教育範疇 • 軟體設計的基礎內功

– 思維的活化 — 運用物件導向的哲理。 – UML 2.0/OOAD 的活用。

• 專案管理與開發流程 Guideline — RUP 與 Agile、 XP Process – 傳授專案管理最佳的應用實務與階段產出 (Artifacts)。 – 跨海峽兩岸分工的開發模式 — 高階設計與細部系統設計的專業分工。

• 設計塑模 (Modeling) 與程式實作的整合、測試與部署 (Deployment) – 中、大型系統整體架構設計與實作。– 軟體的正反向工程。 – 活用分析 /設計樣式 (Analysis/Design Patterns)。 – 傳授 J2EE 的中、高階實作技術。 – 傳授 .NET 的中、高階實作技術。 – 教授利用 UML Tool (如 Enterprise Architect) 實作軟體設計。

HSDc Team UML 與軟體設計產品代理 Enterprise Architect - UML Design Tool

• 涵蓋系統開發週期的軟體設計– 物件導向的系統開發絕不僅僅是畫類別圖而已！現今的系統開發重視的是整個開發的週期。包括企業流程分析、以使用案例匯整需求、建立動態流程塑模、元件塑模、部署塑模、系統管理、非功能性的需求、使用者介面設計以及測試、維護等工作。

• 富有特色的系統設計 – Enterprise Architect 是一個完整的 UML 分析與設計工具，涵蓋軟體開發各階段所需要的功能 – 從需求蒐集到分析階段、設計塑模、測試與維護。 EA 採用圖形介面 (Windows/Linux) 而且支援團隊協同開發，它不但可以協助開發團隊建構健全而易於維護的軟體，還提供高品質的文件輸出功能。

HSDc Team UML 與軟體設計產品主要特色 • 完整支援 UML 2.0 規格的塑模設計與建構。• 建立使用案例、邏輯、動態、實體塑模。• 依據開發流程客製化的擴充機制。• 產出 RTF、 HTML 的高品質文件。• 簡單易用。• 成本低。• 建立資料塑模、產生資料庫 DDL ，透過 ODBC 由資料庫反向建立資料模型。• 團隊協同開發 (Professional/Corporate) 。• 支援 XMI (XML Metadata Interface)匯入與匯出。• 支援正、反向工程，由塑模產生程式碼，或是由程式碼反向建立塑模。–支援 Java, C#, C++, VB.NET, Delphi, Visual Basic,

PHP

HSDc Team UML 與軟體設計實務經驗與專長• 軟體設計及物件導向的專業顧問團隊。•超過 8 年的專業輔導顧問及教育經驗。• 專精 .NET 及 J2EE 平台及各種開發工具的應用。• 專注整體架構設計、大型系統整合、 3-tier 元件化開發及軟體開發程序 ( 包括 RUP 及 XP 等的研究 ) 的持續改善及增進。• 團隊成員擁有多張專業認證執照，包括 OMG

UML OCUP 、 Rational OOAD & Rose 認證、 Oracle DBA、 Java SCJP、 Novel CNE/CNI、Microsoft MCSE/MCSD/MCDBA 。

HSDc Team UML 與軟體設計顧問輔導與教育實務經驗• 多年來擔任國內各領域單位教育訓練與顧問輔導，包括中科院、工研院、陸總部、台積電、台灣電通、技術學院、空中大學等多所院校、南港軟體園區、北中南多家 ISV．．．等。•極為豐富的系統開發實戰經驗，包括指導海峽兩岸協同系統開發、大型系統的整體架構設計、多個異質系統整合設計．．．等。• 最擅長以非常淺顯易懂的比喻及說明，將複雜的系統抽絲剝繭，重新釐清脈絡，得以將複雜的問題以簡單的方式提供解決方案。


•附錄二、與現有開發工具整合的支援列表


• 與 IDE 程式開發工具的整合– Visual Studio .NET 2003 and 2005– Eclipse

• 版本控管的整合– Microsoft Visual Source Safe– CVS (Open Source)– Subversion (Open Source)

• UML 元件 (Components)權限控管所支援的資料庫系統– 支援 ODBC 所連結的資料庫，包括 MS SQL, Oracle, MySQL,

PostgreSQL … 等。• 與其它 Modeling Tools 的整合

– 只要符合 XMI (XML Metadata Interface) 規格，包括 Rose, Together 等，均可互相交換 Model 檔 (透過 Import/Export)。

• MDG Technology for BPMN (Business Process Modeling Notation)– 支援 BPMN 1.1 規格。

EA 6.5 內建整合功能


EA 6.5 與 3rd Party 工具的整合• MDG Link (better synchronization between

forward/reverse engineering)– Visual Studio .NET 2005– Eclipse

• Zicom Mentor http://www.zicom.com.au/zicom/– Visual dictionary of UML– View UML Specification, paper, books and

courses by browser.

http://www.zicom.com.au/zicom/

HSDc Team

Q & A

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

Documents

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