Ea uml
This presentation is the property of its rightful owner.
Sponsored Links
1 / 122

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


  • 85 Views
  • Uploaded on
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ea uml

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

Ringle Lai


Agenda

Agenda

  • UML與軟體開發

  • 軟體開發最佳實務

  • HSDc Team簡介與實際實務經驗分享

  • 軟體建構管理實務(整合EA與Subversion)


Ea uml

UML與軟體開發


Ea uml

為什麼需要UML

  • 在建築業中,設計圖是一座建物中最重要的基礎,建物必須要依圖施工,才能夠保證建物的品質

  • 軟體設計與建築相同,有品質的軟體必須要能夠依照設計圖施工,也必須要能夠依照設計圖檢驗

  • 正因為設計圖的重要,因此,設計師在面對任何的開發團隊成員,都應該要採用統一的設計語言,這也就是為什麼目前所有的設計團隊都重視UML的原因

  • 擁有一個好的UML工具,能夠讓程式碼與設計圖合而為一,無論是從設計圖產生程式碼,或是從程式碼產生設計圖,都可以完整支援


Ea uml

UML可以幫助我們什麼?

  • 讓團隊成員可以用共同的設計語言溝通

  • 可以把團隊的設計心血完整記錄下來,以供日後參考

  • 面對大型專案時,不同的開發團隊可以利用不同的UML圖形把焦點放在特定的一個領域中

  • 十三種UML的圖形,可以涵括整個軟體設計各個不同面向的設計


Ea uml

什麼是UML不能做到的?

  • UML不能夠「保證」軟體一定設計的出來

    • 這是屬於「軟體開發流程」的範疇

    • UML充其量祇是一個設計的共通語言,並不包括「軟體開發流程」的標準化

    • 一般而言,軟體開發團隊必須要有自己適用的「軟體開發流程」,並配合該流程,決定使用的UML元件有哪些

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


Ea uml

什麼是UML不能做到的?

  • 使用UML並不能夠保證設計圖和未來寫出來的程式碼是一致的

    • 這主要是「專案管理面」的問題

    • 一般來說,大部分的專案在越接近交付的時間時,設計圖與程式碼的落差就會越大

    • 由於時間的壓力,再加上沒有一個好的工具輔助做雙向的檢核,往往在專案完成後一年,設計圖和程式碼的差異就已經完全無法彌補

    • 最終,使用UML變成祇是製作文件,而並非伴隨著軟體設計的產物


Ea uml

什麼是UML不能做到的?

  • 使用UML並不能夠保證軟體能夠及時交付

    • 這同樣是屬於「軟體開發流程」的範疇

    • 在軟體開發流程中,應該盡可能使用「I & I」(Iteration & Incremental)的方法來開發,以減低開發的風險

    • 在HSDc所規劃的軟體流程中,RA->HSD->DSD->PG->SI,整個完整的開發流程,應至多以「一個禮拜」為單位作一個循環,如此可以盡快瞭解整個專案的風險,並且快速反應使用者的需求


Ea uml

什麼是UML不能做到的?

  • 使用UML並不能夠保證程式在交付時的正確性

    • 這主要是屬於「測試管理」的範圍

    • 一般來說,一個專案的成功與否,主要端視其是否擬定一個完整的測試計畫

    • 測試計畫需要由使用單位與開發團隊來共同擬定

    • 測試計畫的擬定,應該要在專案的需求蒐集階段就完成,並且隨著需求的變動而隨之調整

    • 測試程式的寫作則必須要在程式寫作之前完成,如此可以避免造假


Ea uml

關於UML與軟體設計

  • UML祇是軟體設計的通用平台,而軟體設計則包括「開發流程規劃」、「架構設計」、「專案管理」、「建構管理」、「測試管理」等不同的構面

  • UML在每一個不同的構面都可以提供相對應的協助,但最終來說,仍需要針對不同構面建構出團隊所需要的相關管理機制

  • HSDc主要是針對這幾個不同的管理構面提供顧問服務,包括規劃開發流程、輔導架構設計、建立管理制度 … 等相關的服務

  • 以下,我們將提出幾個不同產業的實例與各位分享


Ea uml

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


Ea uml

案例背景說明

  • 該專案為一家大型的家電製造商所開發的系統

  • 該廠商的上游有多家的供應商,供應不同的相關原料

  • 當該廠商的生產單位在其ERP擬定生產計畫後,會將該年度的原料請購紀錄送至電子化採購系統,該電子化採購系統會自動產生「RFP」(Request For Purchase),並利用簡訊系統以及Email給予註冊的供應商

  • 供應商在收到簡訊或是Email後,必須要先到該廠商的電子化採購系統中,在採購要求所需的時間內提出報價單

  • 該廠商的採購人員(Buyer)透過電子化採購系統進行比價,並且決定第一優先及第二優先順位的供應商,並產生採購單,同時透過簡訊系統以及Email通知該兩家供應商

  • 供應商收到簡訊後,若是確認要進行供貨,必須在規定的期間內,到電子化採購系統確認採購單,電子化採購系統收到確認後,會以Email通知廠商的負責採購人員

  • 廠商採購人員到電子化採購系統確認採購單,電子化採購系統會將該採購單回傳至該廠商的ERP系統中


Ea uml

軟體開發流程設計

  • 本專案共包括以下角色:

    • RA:負責蒐集使用者的需求

    • Architect:負責整體系統架構設計,並且Review SA/SD與TD的設計規格

    • SA/SD:負責進行整體系統的高階設計,在本階段,並不考慮平台面的實體設計

    • Technical Designer (TD):根據SA/SD的設計結果,加入平台面的實體設計,並且負責督促PG完成程式設計

    • PG:負責進行程式設計以及撰寫單元測試程式


Ea uml

軟體開發流程設計 – 續

  • 上述的幾個角色的工作內容以及執掌,如下圖所示:


Ea uml

軟體開發流程設計 – 續

  • 軟體開發時間進程設計

    • 本系統主要是利用 I&I 的方式進行設計,因此,每個Iteration以「一週」為單位

    • 每個「Iteration」預計完成三個「使用案例」,並且在每一個「Iteration」交付後,由使用者直接進行兩個禮拜的測試,每一個「使用案例」則允許兩次的修改

    • 以本專案為例,共有39個使用案例,因此,預計使用26週的時間進行開發(約六個月)


Ea uml

架構設計

  • 該系統必須要能夠與ERP系統溝通,除此之外,由於該家電廠商的工作流程系統是Notes平台,因此,也必須要能夠與Notes系統溝通

  • 在設計上,HSDc建議使用「軟體主機板」的設計方式,搭配「IBM MQ」作為資料交換的平台

  • 整體架構設計如下圖


Ea uml

架構設計

  • 利用UML Package Diagram表達系統架構


Sa sd

SA/SD產出

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


Sa sd1

SA/SD產出

  • 針對上述的每一個Use Case,必須要寫下其使用案例敘述


Sa sd2

SA/SD產出

  • 每個Use Case會有對應的Sequence Diagram表達其實作


Ea uml

TD產出

  • 針對HSD的Sequence Diagram,DSD應該要繪製平台面的相關設計


Ea uml

UML扮演的角色

  • 上述所有不同角色的人員,都利用UML進行設計,各個角色的人員都可以透過UML來溝通

  • 因此,針對各個不同角色的人,必須具備:

    • 繪製及讀取UML設計圖的能力

    • 使用UML工具的能力

  • 針對Architect,則必須:

    • 瞭解各個不同層次(SA/SD及TD)對於相同的Domain的UML表達之差異

    • 規劃整體系統的架構規範


Ea uml

軟體開發最佳實務


Architecture centric

以架構為中心(Architecture Centric)

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

  • 軟體架構(Software Architecture)不只跟結構與行為有關,同時也跟背景環境有關,包括:

    • 使用方式

    • 功能性(Functionality)

    • 效能

    • 彈性

    • 再使用性(Reuse)

    • 可理解性(Comprehensibility)

    • 經濟效應與

    • 技術的限制與取捨


Architecture centric1

以架構為中心(Architecture Centric)

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

系統外部的觀點

功能與非功能性

利用使用案例模型

需求觀點

軟體架構

實際可執行的程式碼

與平台技術息息相關

利用自動化測試機制來檢驗

重視系統的結構設計

表達重要的Domain Concept

利用類別圖以及循序圖

結構觀點

實作觀點


Architecture centric2

以架構為中心(Architecture Centric)

  • 在第一個時間點,架構師(Architect)必須要能夠確實定義自己所開發系統的範圍

    • 利用「使用案例圖」(Use Case Diagram)可以幫助架構師釐清系統的範圍

    • 利用「套件圖」(Package Diagram)可以讓架構師瞭解模組與模組間的相依關係

    • 利用「複合結構圖」(Composite Structure Diagram)可以讓架構師瞭解介面間的彼此相依關係

    • 利用「類別圖」(Class Diagram)可以讓架構師確認Domain的重要概念


Architecture centric3

常見的謬誤

正確的架構觀點

以架構為中心(Architecture Centric)

  • 「使用案例圖」與系統架構

共同的問題:

忽略了系統範圍


Architecture centric4

以架構為中心(Architecture Centric)

  • 套件圖與系統架構

支援性系統

確認所要開發系統

的使用者

與支援性的系統

使用者


Architecture centric5

以架構為中心(Architecture Centric)

  • 複合結構圖與架構

明確定義介面關係


Architecture centric6

以架構為中心(Architecture Centric)

  • 類別圖與架構

用Domain Concept

定義系統內部的結構


Iteration incremental

循環漸增(Iteration & Incremental)

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


Iteration incremental1

循環漸增(Iteration & Incremental)

  • 反覆式流程的開發方式有下列優點:

    • 提早降低風險

    • 較早能具有可視性(Visible)的進展(Progress)

    • 較早能得到回饋,較可以得到使用者的保證(engagement)及適應性(adaptation),由此再精緻(refine)系統的設計,以更進一步契合使用者的需求

    • 增加團隊的信心,並可以一直學習

    • 產品的整體品質較佳


Iteration incremental2

循環漸增(Iteration & Incremental)

  • 一般而言,當需求變化較大,系統範圍較不固定的系統,利用循環漸增的方式,能夠有效地面對改變的需求,快速反應

  • 相反地,若是需求非常固定,且系統範圍不會有大幅度地修改,使用循環漸增和傳統的瀑布式開發模式,並沒有太大的差距

  • 一般來說,循環漸增最大的潛在危機是:開發團隊成員無法忍受「不確定性」


Ea uml

軟體製程簡介


Ea uml

軟體製程簡介

  • 軟體製程並非一成不變,和晶圓代工的製程一樣,面對不同的專案、不同的團隊成員,應該要調配出不同的製程,如此一來,才有可能讓整體的軟體產出具備良好的品質

  • 若以兩岸分工而言,HSDc所設計的軟體製程如下


Ea uml

軟體製程簡介


Ea uml

需求蒐集階段

  • 在需求蒐集階段,RA與Architect應先針對所要開發的系統範圍進行兩方面的訪談

    • 針對所面對的企業,應先瞭解該企業的「主要企業流程」,並且蒐集相關的「企業規則」,此部分的訪談對象應該是該企業的「領域專家」

    • 至於局部性的需求,則應該對實際的「操作人員」進行訪談,並且記錄相關的功能性以及非功能性的需求

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

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


Ea uml

企業流程塑模

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


Ea uml

企業流程塑模

  • 訂單處理的範例


Ea uml

企業流程塑模

  • 當然,針對每一個Process的內涵,可以定義更詳細的工作流程

  • 此時,可以利用UML的Activity Diagram來進行描述

  • 當然,企業流程塑模的對象是領域專家,因此,一般來說,在進行企業塑模時,不宜介入過多的操作性的資訊


Ea uml

需求的蒐集與整理

  • 一般來說,需求的蒐集通常是利用「純文字」把資料進行彙整

  • 但是,我們可以透過UML的Extend的Requirement Diagram來整理這些需求


Ea uml

需求的蒐集與整理

  • 非功能性的需求,我們也可以利用相同的圖形來進行蒐集


Ea uml

利用使用案例收斂需求

  • 使用者的需求大都天馬行空,因此,我們必須要將訪談的重點盡量收斂在特定的「焦點」上

  • 使用案例指的是對使用者而言,一個比較「有意義」的「功能點」,因此,利用使用案例來聚焦,通常會比較有效率

  • 在使用案例中,一方面我們可以將過去所蒐集到的Requirement與使用案例進行對應,另一方面,也可以讓使用者進行腦力激盪,確認對他們而言有意義的需求


Ea uml

利用使用案例收斂需求

  • 使用案例對應至Requirement


Ea uml

利用使用案例收斂需求

  • 當然,對於使用者與系統間的對話過程,我們也會利用使用案例敘述將之表達出來


Ea uml

利用使用案例收斂需求

  • 至於每一個使用案例,也應該提出至少一個有關該使用案例的測試案例


Ea uml

系統的分析與設計

  • 在系統的設計階段,應該先把平台面相關的知識先放在一邊,而應該思考有關Domain上的重要議題

  • 一般來說,在這個階段中設計的類別,不外乎是分析型的類別,包括:

    • Control Object

    • Boundary Object

    • Entity Object


Control object

分析類別中的Control Object

  • Control object是屬於功能性的Object,而且這個功能與Use Case有相當密切的關係

  • 一般來說,Control物件主要的任務是協調各種物件,讓物件彼此合作以達成Use Case所想達成的功能面的需求

  • 在設計策略上,我們通常會讓每一個Use Case都有一個Control Object,這個Object就稱之為「UCO」(Use case Control Object)


Control object1

分析類別中的Control Object

  • 下圖就是Control Object的示意圖


Boundary object

分析類別中的Boundary Object

  • Boundary Objec是屬於與外部橋接的Object,這類型的Object將會與外部直接接軌,受到外部的限制

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

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


Boundary object1

分析類別中的Boundary Object

  • Boundary Object如下所示


Entity object

分析類別中的Entity Object

  • Entity object是屬於系統本質面的概念性的Object,這類型的Object不會隨著Use Case的增多而有所變動

  • Entity物件主要是將資訊及資源封裝起來,因此其定義相當明確

  • 就系統的設計來說,Entity物件代表了企業中的重要概念,因此,這樣的物件的變動性會比較低

  • 從設計的觀點來說,這類型的物件,可以說是軟體設計中最重要的一部份


Entity object1

分析類別中的Entity Object

  • 要找Entity Object,大都是需要比較具備經驗的SA才有辦法將這些物件找出來

  • 但是,我們其實可以利用Peter Coad的Transaction Pattern幫助我們尋找Entity Object


Entity object2

分析類別中的Entity Object

  • 下圖就是維修系統的Entity Object


Ea uml

系統的分析與設計

  • 系統除了靜態的類別結構外,另外我們針對每一個Use Case,都應該要繪製一個「物件合作」的「循序圖」,來驗證我們的靜態結構能夠滿足使用者對於系統的需求

  • 在循序圖中,主要要表達每一個Use Case敘述中的每一段「使用者與系統」的互動過程,都可以被滿足

  • 也因此,循序圖一般被稱之為「系統動態結構圖」


Ea uml

系統的分析與設計

  • 利用循序圖表達物件合作關係


Technical designer

Technical Designer的平台設計

  • 一般來說,Technical Designer必須要把SA/SD的設計產出,加入有關平台面的知識,並且將之表達出來

  • 通常來說,為了能夠確切表達平台相關知識,可以利用UML的Composite Structure Diagram來進行表達

  • 除此之外,TD也可以把對應的設計觀念,利用表列式的方式加以說明

  • 如果對於SA/SD的設計圖有所變動的話,TD應該要繪製對應的設計圖,以方便Architect進行比對


Technical designer1

Technical Designer的平台設計

  • SA/SD與TD的對應設計表


Technical designer2

Technical Designer的平台設計

  • SA/SD與TD的對應設計表


Technical designer3

Technical Designer的平台設計

  • TD的設計圖


Net virtual db

.NET中的細部設計分享 – Virtual DB

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

  • 事實上,在現在的設計環境中,所有的資料值,其實都可以利用XML來進行傳遞

  • 由於XML具備結構,而且又只是標準的字串,因此,利用XML進行資料傳遞,既可以保有資料的結構性,又可以讓參數簡單化,因此,在設計上,這已經是不可檔的趨勢


Net virtual db1

.NET中的細部設計分享 – Virtual DB

  • 然而,在設計上,這又必須面臨另外一個令人頭痛的問題 – XML Parsing

  • 針對一個簡單的XML字串,我們必須要撰寫複雜的XML Parsing程式,才能夠取得其對應的值

  • 在.NET中,為了解決這個問題,便提出了「DataSet」的Solution

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


Net virtual db2

.NET中的細部設計分享 – Virtual DB

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

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


Net virtual db3

.NET中的細部設計分享 – Virtual DB


Net virtual db4

.NET中的細部設計分享 – Virtual DB

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

Data存在VDB中


Ea uml

PG的程式寫作 – 測試先行

  • 對於PG的設計來說,其首先取得的,主要是由TD所提供的「循序圖」以及程式碼的框架

  • TD所提供的程式碼框架,應該要說明每一個程式碼的內涵

  • 除此之外,針對每一個Control物件,PG應該要知道該Control物件中的每一個Method所對應的實際測試案例


Ea uml

PG的程式寫作 – 測試先行

  • 針對每一個Control Object,PG所獲得的程式碼框架應如下所示:


Ea uml

PG的程式寫作 – 測試先行


Subversion ea

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


Ea uml

建構管理的原理

  • 建構管理的目的

    • 讓系統在建構的過程中,可以追蹤並且管理整個建構的過程

    • 系統的建構(無論是軟體、硬體或是韌體)其實是一連串逐步建置的過程

    • 在這個建置過程中,當然會遇到有關「Change」的管理以及團隊合作相關的Issue

    • 因此,建構管理的主要目的就是在控制以及管理上述的Change以及團隊合作相關的主題

    • 針對軟體的建構,則這個主題又被擴大稱之為「軟體建構管理」(Software Configuration Management; SCM)


Ea 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)


Ea uml

建構管理的原理

  • 也就是說,軟體建構管理主要是針對「建構期間的產品」(work products),管理其版本(manage version)以及控制其改變(control change),並且針對這些改變提供相關的審核(audit)以及報告(report)的機制

  • 一般來說,軟體建構的過程通常如下圖所示:

ref. SCM Terminology Presentation

from SCM Community Web Site


Ea uml

建構管理的原理

  • 建構管理的重要假設:

    • 針對不同的專案、不同的時間點,我們必須要掌握一個主要路徑的原則

    • 針對不同的開發版本,則需要在不同的的分支中Release各個不同的正式版本,並且在適當的時機點匯入到主要路徑中

    • 如此一來,整體的開發將會在同一個主要路徑中被控制以及管理


Ea uml

建構管理的原理

  • SCM的意涵

    • 第一層意涵是屬於管理層面的

      • 必須要擬定一個管理的機制以及管理的結構

      • 主要目的就是讓開發人員能夠按照該機制將文件以及程式碼納入管理,並養成習慣隨時將這些資料更新至管理的儲庫(Repository)之中

    • 第二層意義則是其使用的工具

      • 必須要選擇一個特定的使用工具

      • 由於不同的工具會有不同的特性,最好在選定工具後就盡量不要再更換


Ea uml

建構管理的原理

  • 一般來說,SCM的整體活動,應該如下圖所示

ref. Configuration Management Principles and Practice

By Anne Mette Jonassen Hass


Ea uml

建構管理的原理

  • CM的核心主要是放在Development階段各個Release的儲存(上圖中Storage的部分)以及整體有關Change的管理(上圖中Change control的部分)

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

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

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


Ea uml

建構管理的原理

  • 以下,用一張Class Diagram來描述「Comfiguration Management Items」


Ea uml

建構管理的原理

  • SCM所能夠控管的範圍,主要仍是在可電子化的部分,至於Physical Item,則需要利用管理的相關機制來進行相關的控管

  • SCM所能夠控管的,主要包括

    • 開發的文件(Development Document),以及

    • 開發程式碼(Source Code)

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


Ea uml

版本控管機制的建立

  • 在這個部分,我們將介紹利用Subversion來完成版本控管機制的建立

  • Subversion是一個Open Source的專案,其主要是著眼於原先的另一個Open Source的專案 – CVS有太多的問題,因此,希望可以建立一個更為簡潔、能力更強的版本控管軟體

  • Subversion主要服務的建構管理對象,仍是在SCM的範疇中,因此,使用Subversion可以解決SCM中大部分的問題


Ea uml

版本控管機制的建立

  • Subversion的架構如下圖所示:


Ea uml

版本控管機制的建立

  • 安裝Subversion

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

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

    • 當然,如果你要利用Subversion的通訊協定-svn來進行存取,則你必須要啟動一個svnadmin的服務

    • 如果是在Repository的local端進行存取的話,則什麼通訊協定都不需要了


Ea uml

步驟二:解壓縮

步驟三:建立環境變數

步驟一:打開壓縮檔

版本控管機制的建立

  • Subversion Server端的安裝 - 1

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


Ea uml

版本控管機制的建立

  • Subversion Server端的安裝 – 2

    • 安裝Apache Server

      • 請直接到Apache的網站Download Apache Http Server的安裝檔,目前Subversion 1.4.5已經Support Apache 2.2,因此,請下載最新的版本即可(目前最新的版本為2.2.6)

步驟三:修改Apache的Config檔

步驟一:按照Default

一步一步安裝Apache

步驟二:Copy檔案


Ea uml

版本控管機制的建立

  • Subversion Client端的安裝

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

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

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


Ea uml

版本控管機制的建立

  • 建立Server端的Repository

    • Subversion的Repository是以非常自由的方式來建立,你可以在任何可以存取的Directory建立Repository

    • 一般來說,若要採取中央集權的方式來控管的話,你可以建立一個SVN/Repository的子目錄來集中管理所有的Repository

    • 我們在該目錄下,建立一個「HsdcDemoSVN」的子目錄,並利用TortoiseSVN來建立Repository(利用BerkleyDB格式)


Ea uml

版本控管機制的建立

  • 建立Server端的Repository – 2

    • 利用TortoiseSVN建立Repository

    • 在Apache的Config檔建立DAV Location的位置,並指向Repository

步驟一:建立目錄結構

步驟二:建立Repository

步驟三:選擇Repository格式

步驟四:完成後的Repository

步驟一:修改Location位置

步驟二:重開Apache

步驟三:利用Browser查詢Repository


Ea uml

版本控管機制的建立

  • 建立Authority機制(使用Basic Auth)

步驟一:建立Password file

步驟二:設定Config

步驟一:進入Repository時,會要

求Authorization


Ea uml

版本控管機制的建立

  • 按照軟體建構的基本理論:

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


Ea uml

版本控管機制的建立

  • Trunk

    • 指的是整個軟體開發的「主要路徑」,在「主要路徑」中,只放經由PM或是QA認可的相關開發文件以及程式碼

    • 其他的軟體建構工具稱之為「Baseline」

  • Branch

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

  • Tag

    • 指的是專案進行中的特定MileStone,通常是一個Release或是一個Version

    • 一般來說,Tag也可以稱之為Baseline的Snapshot


Subversion repository

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/kenming

      HsdcDemoSVN/ExampleProject/branches/private/cathy

      HsdcDemoSVN/ExampleProject/branches/private/ringle

      HsdcDemoSVN/ExampleProject/branches/private/qa

    • Tags - HsdcDemoSVN/ExampleProject/tags


Subversion repository1

Subversion Repository的專案規劃

  • PM建立Project結構

  • PM (Cathy) 需要先在自己的local端建立一個目錄結構,並且將該目錄結構Import到Repository中

步驟四:認證

步驟三:選擇Repository

步驟一:建立目錄結構

步驟二:Import目錄結構


Subversion

Subversion與設計產出

  • 下圖是EA與版本控管機制間的關係圖


Subversion1

Subversion與設計產出

  • 根據前面的關係圖,我們可以得知 Architect在第一個階段,應該要先架構出第一個版本的UML專案規劃,並且把相關產出匯入到Database(此例中為SQL Server)中

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

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


Subversion2

Subversion與設計產出

  • Architect (Kenming) 的操作如下所示:

步驟二:設定路徑

步驟一:轉移專案至DB

步驟三:取得Model Repository

步驟五:Config Package

步驟六:完成Version Control

步驟四:設定Version Control


Subversion3

Subversion與設計產出

  • 接著,Developer Kenming以及Ringle分別把該Trunk的版本,Branches到各自的branches中進行操作

步驟二:設定分支的位置

步驟一:對Model建立分支


Subversion4

Subversion與設計產出

  • 在第一個Milestone – release 1.1 中,由Architect (Kenming) 把兩者間衝突的Model進行Merge後,放至Trunk,並且記錄一個tag為1.1,並且把所有tag為1.1的產出寫入到tags目錄下的1.1


Subversion5

Subversion與設計產出

  • Architect Merge 步驟一:Merge


Subversion6

Subversion與設計產出

  • 版本圖


Subversion7

Subversion與文件產出

  • 在專案進行的過程中,會有許多的相關文件

  • 這些文件的格式通常會是Office的格式

  • 在Subversion中,Office的檔案格式沒有辦法直接由Office進行存取,因此,必須透過像TortoiseSVN來進行存取

  • 回到我們的範例專案,PM Cathy新增了一個執行計畫,則該計畫目前應該要放在「trunk->project_doc」

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


Subversion8

Subversion與文件產出

  • PM Cathy的工作

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


Subversion9

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


Subversion10

Subversion與開發產出

  • Developer Ringle的操作

    • 先設定Subclipse的環境

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


Subversion11

Subversion與開發產出

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


Subversion12

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開發環境裡


Subversion13

Subversion與開發產出

  • Developer Ringle的操作(PushOK)

    • 設定環境


Subversion14

Subversion與開發產出


Ea uml

附錄一、 公司介紹

HSDc (High-quality Software Design Center)


Ea uml

使命、目標與願景

  • 使命(Mission) – 提升及協助軟體開發人員在軟體設計的專業技能及必備素養

  • 目標(Goal) – 把軟體做 ”軟”。(Keeping Software Soft !! )

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


Ea uml

核心刺蝟原則


Ea uml

軟體設計的重視方向

  • 重視軟體設計的思維與基本功

    • 從本質看軟體設計

      • 設計與實做,是一體兩面。

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

  • 重視

    • 觀照整體的能力。

    • 軟體整體的架構(Architecture)與結構(Structure)


Ea uml

經營策略與方向

  • 三合一

    • 顧問(Consultant)

    • 教育(Education)

    • 產品(Product)代理


Consultant

顧問(Consultant)服務項目

  • 大型應用系統的主機板(Motherboard)架構設計,包括異質系統、Legacy系統、異質資料庫與作業系統平台的整合與建置規劃。

  • 協助客戶快速建立原型(Prototype)系統,打通技術環節、驗證系統架構。

  • 根據企業客戶的實際軟硬體環境,規劃與設計配套的軟體設計實務課程。

  • 協助與指導規劃 開發團隊建置 Macro and Micro Process 與產出(Artifacts)。

  • 指導客戶外包(Outsourcing)的規劃與品質驗收。

  • 協助與指導客戶在實際案子的軟體設計建置與規劃,包括在塑模工具上的使用。


Ea uml

軟體設計的教育範疇

  • 軟體設計的基礎內功

    • 思維的活化 — 運用物件導向的哲理。

    • UML 2.0/OOAD 的活用。

  • 專案管理與開發流程 Guideline — RUP 與 Agile、XP Process

    • 傳授專案管理最佳的應用實務與階段產出(Artifacts)。

    • 跨海峽兩岸分工的開發模式 — 高階設計與細部系統設計的專業分工。

  • 設計塑模(Modeling)與程式實作的整合、測試與部署(Deployment)

    • 中、大型系統整體架構設計與實作。

    • 軟體的正反向工程。

    • 活用分析/設計樣式 (Analysis/Design Patterns)。

    • 傳授 J2EE的中、高階實作技術。

    • 傳授 .NET 的中、高階實作技術。

    • 教授利用 UML Tool (如 Enterprise Architect) 實作軟體設計。


Ea uml

產品代理

Enterprise Architect - UML Design Tool

  • 涵蓋系統開發週期的軟體設計

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

  • 富有特色的系統設計

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


Ea uml

產品主要特色

  • 完整支援 UML 2.0 規格的塑模設計與建構 。

  • 建立使用案例、邏輯、動態、實體塑模 。

  • 依據開發流程客製化的擴充機制。

  • 產出 RTF、HTML 的高品質文件。

  • 簡單易用 。

  • 成本低 。

  • 建立資料塑模、產生資料庫 DDL,透過 ODBC 由資料庫反向建立資料模型。

  • 團隊協同開發 (Professional/Corporate) 。

  • 支援 XMI (XML Metadata Interface)匯入與匯出 。

  • 支援正、反向工程,由塑模產生程式碼,或是由程式碼反向建立塑模。–支援 Java, C#, C++, VB.NET, Delphi, Visual Basic, PHP


Ea 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 。


Ea uml

顧問輔導與教育實務經驗

  • 多年來擔任國內各領域單位教育訓練與顧問輔導,包括中科院、工研院、陸總部、台積電、台灣電通、技術學院、空中大學等多所院校、南港軟體園區、北中南多家 ISV...等。

  • 極為豐富的系統開發實戰經驗,包括指導海峽兩岸協同系統開發、大型系統的整體架構設計、多個異質系統整合設計...等。

  • 最擅長以非常淺顯易懂的比喻及說明,將複雜的系統抽絲剝繭,重新釐清脈絡,得以將複雜的問題以簡單的方式提供解決方案。


Ea uml

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


Ea 6 5

EA 6.5 內建整合功能

  • 與 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 3rd party

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.


Ea uml

Q & A


  • Login