[案例研討] 烏龜訂購系統開發與實作 by UML and Java-02

兩階段開發的目標設定

重點說明

本案例的演練區分為兩個釋出 (release)階段。在現實的專案開發,每一個釋出版本都應該是可以滿足使用者的功能需求。兩個釋出版本的重心為:

第一個階段:快速實現功能需求,但保留了可以具延展性的 3-tier MVC框架。
第二個階段:找出穩定的共用元素,讓系統更有彈性。

第一個階段 (release #1)在內部的開發週期分為兩個循環 (iteration)。第一個循環 (iteration #1)快速實現幾個具代表性的使用案例,並打通技術關節。而相關於邏輯處理或欄位細節等,則留待第二個開發循環 ; 所以第二個開發循環 (iteration #2)著重在於對精細度的要求,包括欄位細節、企業規則的邏輯 (business rule logic),以及對於例外事件的處理 (exception handling)。

第二個版本的釋出 (release #2),則除了在於擴展系統功能外,還希望能就維護性、彈性度等議題來作調整。此階段重點在於對系統組成結構的重整 (物件與資料結構),或亦可在程式碼上對其重構 (re-factoring)。結構重整或重構皆為共用性設計議題的整合考量,所耗費的開發成本往往比較高 (但也相對容易提升系統的價值),且須具備相當基礎的軟體設計素養才有能力將軟體做軟 (keeping software soft)。

兩個不同階段時期的釋出版本要能順暢的橋接,至少要能有兩個必要的條件:

  1. 3-tier MVC (Model-View-Controller) 實體IT框架。
  2. 以使用案例為單位的功能性測試程式碼 (function test code)。

** 關於 Release 與 Iteration 的意義與差異,可參考:
http://www.kenming.idv.tw/soft_development_iteration_vs_release-2

Release #1 (包含 Iteration #1, #2 兩個開發循環)

目標:從使用案例 (功能需求)快速導出到程式碼實做。

簡述:以使用案例為單位,找出最具價值的使用案例,優先開發。

作法:
以服務為開發的導向,為每一個使用案例設計功能性的控制物件 (位於中間層),並將實現該功能案例的邏輯 (Logic)落實於該物件內,實際連結資料庫來存取資料作運算;同時並撰寫功能測試程式碼,確保程式碼的正確性。再來則是透過 UI 表單的實作,來驗證功能。

效果:
本階段並不重視資料與企業邏輯的共用性,而是以個別的使用案例為開發單位,快速實做出可執行與可被測試的應用程式碼,滿足使用者對系統功能的要求。

但系統內部則保留可以延展的框架,確實將企業邏輯 (business logic)集中於中間層 (middleware)來,隔離 UI 層與資料庫的緊密耦合 (tight-coupling),實現 MVC (Model-View-Controller)架構。

資料與企業邏輯功用性的考量,非影響系統的功能,而是與系統的彈性度有關,這是當專案具有再利用性價值,或是產品需要高度客製化的考量時,再施以第二個階段的系統結構重整。

Release #2 (包含結構重整階段)

目標:萃取出穩定的結構共用元素 (企業物件,business object),讓系統更有彈性。

簡述:從多個使用案例中,找出共用的企業邏輯,施以結構的重整。(重構,Refactoring)

作法:

  1. 觀察多個使用案例,是否有具共用性的邏輯。 例如 「Place a Order」, 「Track Order Info」這兩個使用案例,可能均有「計算訂購總額()」的企業邏輯 (business logic)。

    原來在第一個開發階段沒有考量共用設計的情況下,是可能個別被實現在各自的使用案例控制物件 (control object)內。在結構萃取的整合階段,則會發掘出共用的部分,並分派該計算邏輯至合適的企業物件內,如「計算訂購總額」可能會被分派至「Order」的企業物件內,成為該物件的操作 (operation)。

  2. 觀察是否有「有點像又不太像」的企業規則(business rule)。 例如 「保險」的「計算保費()」 操作,會因為有各種的保險類別,如 「意外險」、 「壽險」、 「產險」 …等,而有不同的計算邏輯,但都仍會有「計算保費」的計算邏輯,只是各自的演算邏輯不同。

    這類「有點像又不太像」的功能,開發人員經常是以 switch, if then…else 這類的條件判斷來實做,但不容易應付需求變動且難以維護。此時則可以施以「多型 (polymorphism)」的設計觀念,將不同種類卻又共用相同操作名稱的計算邏輯,確實分派至各種不同的特殊化類別內 (意外險、壽險、產險…),卻又能讓外界以「一視同仁」的角度 (只有看到「保險」的一般化類別),來操作存取使用,卻又不需要直接與各類的特殊化類別直接耦合,而不致於被這些特殊化類別的變動所影響。

效果:
從控制物件「萃取(Extract)」共用性邏輯至其它如企業物件上。此一過程為物件導向中最常使用的技巧,稱為「委派(delegation)」,作用在於讓物件的責任分派 (responsibility)更明確,可以更確實的將變動侷限在可控制的範圍內,讓系統更能應付變動,更具彈性度。

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *