兩段式 RUP 的開發綱要

e-化的 Business 系統的特色即在於強調分散式(Distributed)的架構。而分散的系統又必須整合以建構完整的企業服務(Business Process),並期能達成快速組裝流程來因應顧客的需求(Requirements)。

在現今新潮流的分散式系統的特色又凸顯了:

● 每個 Site 是為整體系統的子系統(Sub System)的一份子。

● 子系統之間有依存性(Dependency)的關係,此種關係是為一種動態的服務需求來建立的。而提供動態的服務則以 Web Service 來串連。

● 子系統很有可能是各種異質性的系統建構的,所以不能僅使用某種廠商所提供的分散式技術,而必須採取更具標準化的分散式交換資訊的標準。所以這更凸顯了以 XML、SOAP(Simple Object Access Protocol)等元素所組成的 Web Service 的價值:XML 提供了結構化來訂定資料交換的標準 ; SOAP 提供了架構於 HTTP 之上的一種簡易交換資料的通訊協定,利用 URL 即可在不知所提供服務的系統的實體位置狀況下,此稱之為位置的透明化(Transparent),能以簡單的 領域名稱(Domain Name) 命名來與對方溝通。

● 不能假設所有的子系統都是由自己來建立的,有可能有些子系統是需要外包(Out Sourcing) ; 或有些子系統是已既存的(Legacy System)。所以對於子系統之間的整合,我們是強調於介面(Interface)上的整合,而不是與內部的實體系統來聯繫。可以想成每個子系統都是一個可以獨立運作的有機體,有機體之間是利用觸角來相互溝通。此觸角(Interface)是對外溝通的唯一管道,對於有機體內部的結構,外部的系統不需也不必知道其細節。

分散式系統具備了上述的特色,這使得我們對於分散式系統的分析及設計上的開發流程(Development Process),勢必做一些修正,其主因在於傳統的分析設計假定於:

● 將欲開發的問題領域(Problem Domain)看待為一個完整的系統。

● 因為看待成為完整的系統,所以都假設從分析、設計乃至實做不太考量到分散式的問題,也因如此,就可能僅會是一張完整的類別圖(Class Diagram)。

● 傳統的分析都是建基於從已知的需求來取得領域上的知識,並據此來建構類別圖。但是提供 Web Service 的分散式系統,常常必須在不知道 User 需求的前提下,也要能提供服務。如何在未知需求的情況下來分析系統,就變成了是分析師非常大的挑戰了。

先整合各分散的子系統,將其觸角連結起來,以快速提供動態完成的服務給顧客是分散式系統最大的特色。相對於不同以往先假設一個完整的系統,再去切分再整合的手藝有著完全不同的開發流程的思維。

所以在不違背 RUP(Rational Unified Process)的基本精髓下,我們需考量修正 RUP 的開發流程步驟來因為現實分散式系統的架構。

在此,提供了所謂兩段式 RUP 的開發流程:

第一階段先將焦點集中於各分散的子系統的整合,以建立一致性的架構(Architecture)。這也正符合了 RUP 的最重要的基本準則:Architecture Centric(First)!

然後第二階段則依據在最抽象的整體架構思維上,從外部的 Actor(如顧客)所觸發(Trigger)的 Use Case的需求分析上,可以據此來得出許多個小的 Use Case 分佈在各子系統上,串結合作以達成顧客的 Goal。開發團隊,就針對此,來針對各個 Sub System各自帶開,各自表述,依 RUP 的四大階段及紀律(Discipline)來做分析及設計,以實現(Realize)該 Sub System 所負責的 Use Case。

此兩段式的 RUP 開發流程是以反覆式(Iterative)的方式來漸進循環的。也就是說,先建立整體的雛形架構(Architecture)後,每個負責實做子系統的團隊必須定時的回報(Feed Back)以驗證該整體架構的一致性及完整性。如此反覆循環,才有可能建立一致性、整體性、和諧的分散式系統。

文章導覽

   

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。