Java SOA 基本觀、架構與實做 <1>

*** 本系列文章與程式碼範例 均為 賴信仁 (Ringle Lai) 所撰寫 ***

在之前的課程中,我們曾經說明過SOA的設計來源其實是從架構面的 使用案例 (Use Case) 模型分析而來。本次課程我們將進一步地說明,如何利用標準化的設計準則來設計一個公司的SOA架構。

以下是屬於 SOA (Service Oriented Architeture) 的定義:

A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components—services—that can be reused and combined to address changing business priorities.
Ref: Service-Oriented Architecture (SOA) Compass, by Bieberstein et al. (2006)

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Ref: http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-9

從上述的定義來看,所謂 SOA 的目的,其實只是在分散處理的環境,提供了一個「分散但可預期的」整體環境。

從這個定義來看,其實在數年前由產業界的力量所推出的「RosettaNet」,就是這一波 SOA 的濫觴;只是目前的SOA的觀念,從產業間的合作關係,逐漸地往企業內部的整體流程整合邁進。但從其基本觀念觀之,其實正是「Design to Interface」觀念的衍生。

那麼,SOA 究竟是怎樣的觀念呢,其基本的結構又會是如何?我們以下圖來呈現一般 SOA 所建議的架構(由於 SOA 畢竟並非一個標準化的架構,因此,各個不同的廠商或是學者,各自有其對 SOA 架構的看法,以下筆者所採取的,是筆者比較認同的SOA架構圖):

圖1. SOA的參考架構
(點擊圖片鏈接看原圖)圖 1 、SOA的參考架構
(Ref: SOA Practitioners’Guide Part 2: SOA Reference Architecture, 2006, p.19)

從這個架構圖,可以看出 SOA 架構的立體性。

在 SOA 架構中,對於企業 (Business)有意義的部分,在於整體企業服務層次的提供,這是上圖中最上方的三角形的部分,也因此,一般在實現 SOA 時,我們必須先從 Business 著手;至於下方的三個 Tier,則是從 IT 的架構層面出發,其主要的目的,在於提供 Business Service 一個穩定性的地基。 以上圖來看,其實 Service Tier 所代表的意義,在於將企業的 應用程式 (Application) 做適當的包裝,好讓其可以簡單地 Mapping 到 Business 的 Service。

也因此,所謂的 SOA 並非是一個固定的產品或是規則,相反地,先讓我們確認 SOA 的主要目的(Business Service <-> Information Service),再從這個主要目的去找尋適合的開發方式 (Development Process)與適用的技術,如此一來,對於 SOA 的整體規劃才不至於見樹而忘林,甚至在不知不覺間,被特定的廠商牽著鼻子走,反而忘掉了 SOA 的最根本的目的!

讀者對使用案例的幾個提問 (針對另文「三論博客來的使用案例分析」)

網友 Thomas,在我個人發表過的一篇文章:「三論「博X來」— 訂購商品與結帳是否是同一個使用案例?」,提問了對使用案例分析的幾個相當不錯的問題與觀點。 老實說,這讓我精神為之振奮起來,已經許久沒有人與我討論使用案例分析的議題了。 我曾提及,使用案例是易學難精,沒有把握基本精要與原則,很難把圖給畫好 (不容易界定出系統範圍),更何況是用純文字來寫出需求陳述。而且,使用案例如同學習圍棋一樣,每一個階段的學習與思考,又能再有著對其本質更深一層的體悟。 相對來說,應用在實務的需求分析上,也會來得更為得心應手。

這裡就 Thomas 所提問的問題,獨立出來另以本文來回覆。 同時也算是對上述該篇文章的補充論述。

您好:
對與你的無私與熱心真的令人佩服
看了你這篇文章感覺上有一個地方有點不解之處,想跟您請教一下
一般來說 使用 Use Case 時最怕受傳統結構化的影響,而將 Use Case 畫成功能分解,但看了你的 Use Case Diagram 的圖,其中訂購商品這個 Use Case 又去 include 查詢商品資訊及放入購物車,坦白講感覺有點像是功能分解的方式,要是我畫這張圖,我可能只會有查詢商品資訊及放入購物車,不會有一個訂購商品這個 Use Case,查詢商品是使用者一進來就會使用的功能,對使用者來講是一個獨立的價值,他就是喜歡逛逛而已,而放入購車又可視為一個獨立的需求,至於訂購商品應該是一個企業流程,這個企業流程包含很多有價值的事情,實在不適合當成一個 Use cASE 反而比較適合成為此 uSE Case 的系統邊界,除非你這張 use case 的層級是在討論企業層級的 use case,而不是在討論 系統層級的 use case
不知您以為我的觀點是否正確
謝謝

關於上述問題的回覆:

  1. 我們要先對使用案例的本質弄清楚。Use Case 確然就是功能分解!! (這點最重要,要先分清楚使用案例的分解方式為何)
  2. 與傳統的模組化功能分解不一樣的是,模組化的功能分解係以功能樹 (functional tree)的方式將大功能分解成小功能,每一個小功能又各自分解更小的功能,直至每一個小功能可以成為一個開發的單位為止。
  3. Use Case 的功能分解,係以目標導向 (Goal-oriented) 的方式,從使用者 (參與者)的角度,在特定的期間 (session) 內,能完成他對系統的操作期望。每一個 Use Case,均可以被視為是一個迷你的系統,是可以被各自獨立來實現 (realize)。
  4. 回至本例,我在圖中係凸顯了系統需滿足使用者兩個主要的功能 (期望),一為訂購商品;另一為結帳商品。 至於為何是分為兩個使用案例,我已在文內有敘述。
  5. 為何我是把主要的 UC 名稱定為「訂購商品」而不是「放入購物車」,原因在於我想凸顯它是 參與者 (Actor) 操作系統的一個重要目的。若用英文命名,會更為恰當。名稱即為 「Place a Order」,如此也比較不至於從字面上引起誤解。 另外,可要注意的是,「訂購商品」正是該資訊系統最重要的交易型使用案例,若把它拿掉,那麼這個資訊系統的價值可就完全不見了。 (其實,我在文內均已有描述這樣的論點,您可以再仔細研讀。)
  6. 「訂購商品」與「訂購業務流程」是兩個完全不同的層次,一個是資訊系統操作層級;另一為業務流程層級。 兩者我其實是各自分開來表達的。前者我利用使用案例圖,後者我是利用業務流程圖的。 可以參考我另外一篇文章:「從企業流程(活動)圖找出資訊系統的使用案例。
  7. 至於為何在圖形上,「訂購商品」會包含 (include) 兩個 Sub-UC (一為查詢商品,另一為放入購物車)? 我在文內其實特別還說明,我是把這兩個 Sub-UC 視為是參與者在「訂購商品」期間內,重要的子程序。
  8. 那麼,「查詢商品」是否可以被視之為另外一個獨立的 Use Case? 答案是 Yes! 但是,可不要把「查詢商品」與在「訂購商品」內所包含的「查詢商品」混在一起。 前述已提,每一個使用案例,是可以被獨立來實現的。 一個獨立的 UC 與另一個被包含的 UC 雖然可能有著相同的程序,但是,在 Use Case 的需求分析階段時,儘量不要去涉及到公用的議題,而是留待到結構分析設計的階段。
  9. 最後,所謂的企業層級的使用案例,與資訊系統層級的使用案例,其實這個就是系統邊界界定的問題了。 幾年前寫過一篇:「從鳥瞰的觀點看 Use Case Diagram」,可以參考之。

關於軟體開發「需求獲取」的幾個問題來信回覆

近日有位來自大陸對岸,就讀軟體工程的同學 Email 來信問了我關於需求獲取的問題。 很難得,並不算是問我 How-to 的問題,而我也覺得他問的問題還挺有意思的,所以也把我個人對其的回覆公佈分享出來。

2009/3/24 cnlogn

王克明老師,您好。
  我是一個初學軟件工程的學生,正學到需求獲取。因為仰慕佛教的無遮大會的問答機制,又無意間撞到濛濛的秘密基地,發現了前輩(有緣分),於是冒昧請教。
  我知道需求信息來源,獲取方法/技術。那麼什麼是需求獲取策略?
  我知道需求三個層次分別是業務需求,用戶需求和功能需求(非功能需求)。那麼什麼是客戶需求?什麼是產品需求?
  為什麼把領域分析和業務建模放在需求獲取階段?此致
敬禮

2009-03-24

Cnlogn 同學您好:

  1. 與其說需求獲取的方法/技術 是一種策略(strategy),倒不如說是一種態度。 什麼態度呢? 因為知道不可能一次就能很明確地從使用者端得到正確詳細的需求,所以,需求分析師 (Requirement Analyst, RA)不會也不應該一開始就想要得到所謂正確的需求,而會是以漸增、漸進的方式 (Iteration and Incremental),從一個所謂的功能單位(例如 Use Case),逐步地從目標框架,往精確度要求。 所以這是一種目標導向的作法,先確立目標,再來往細節調整。
  2. 我覺得是不應該去硬背那個什麼三個層次的需求。應該是說,需求會透過多種不同的角度,理解與紀錄各個不同使用者角色的需求。 包括整體性的業務流程面、包括操作員 (Operator)對系統的局部功能要求、包括整體使用者對系統關於穩定、效能、彈性等非功能性的滿意度需求… 等等。 需求的面向 (View)是很多面的,RA 要能擅長透過多種不同的觀點來看待需求面。
  3. 我不會硬性定義所謂的領域分析與業務建模是放在需求獲取階段。 關於分析、設計、乃至實做測試等工作,會是快速跑過一整個循環 (Iteration),再取得回饋 (feedback)來持續修正調整的。 軟體工程把製程 (Process)固定下來的前提是需求穩定不變,問題是,軟體又不同於其它成熟產業領域的關鍵就在於,需求一直持續地變化。

我曾經寫過一篇:「從軟體架構師(Architect)的觀點來看軟體開發流程」,您可參考看看的。

Best Regards.
Kenming.

VDB 理論與實作 by .NET (1) — 虛擬DB、Value 與 Business 物件的關係

VDB 理論與設計 — Ringle Lai;本次範例實現 — Steve Chou:編排與修正 — Kenming Wang。


虛擬DB(Virtual DB) 並非特定平台的實做技術,其主要特性如下:

針對某一個特定的任務,將該任務所需的相關資料由各種不同的資料來源取得至 記憶體(Memory)中,讓相關的處理程式可以「就近處理」這些資料;其與資料來源的實體儲存格式無關,且在取得資料後,應該保持與資料來源「離線(offline)」的方式來進行存取,而 虛擬DB 只提供資料的存取,不負責進行運算。

也因此,Java 世界中的 Value Object 其實也是「虛擬DB」的一種體現;至於在.NET Solution中,最適宜表現虛擬DB的技術就是 ADO .NET 中的「DataSet」技術。而 Business Object 與 Value Object 最大的差別在於 Business Object必須要有「企業運算邏輯(Business Logic)」。舉例而言,下圖就是一個典型的Business Object的類別圖:

典型的 Business Object 類別圖
(點擊圖片鏈接看原圖)圖、典型的 Business Object 類別圖

根據前述的 Business Object 的定義,我們可以發覺在上圖中,Business Objcet只有兩個,分別是:

  • Order Class – 因為其有一個【CalculateTotalAmount】的 Business Method;
  • OrderItems Class – 因為其有一個【CalculateSubtotal】的 Business Method。

而在該圖中,Product Class 因為只有一個 Getter 的 Method,因此可以將之視為 Value Object,至於 OrderItems 也有一個【Quantity】的屬性,因此也具備了 Value Object 的性質。

一般來說,Business Object其實通常具備了三個主要特質,分別是:

  • 資料面 – 這通常會以【屬性(attributes)】來呈現。
  • 企業邏輯 – 這通常是除了 Getter 與 Setter 之外的 Method。
  • 結構面 – 也就是類別間的靜態關係(包括 Association、Aggregation、Generalization 以及Dependency 等)。

然而,當我們有了 虛擬DB 的概念後,資料面的部分可以交由 虛擬DB 代勞,因此,Business Object就只存在了企業邏輯以及結構面。

我們可以利用UML的 Composite Structure Diagram(複合結構圖) 來表達 虛擬DB 與 Business Object 兩類元件的關係:

虛擬DB 與 Business Object 間的關係
(點擊圖片鏈接看原圖)圖、虛擬DB 與 Business Object 間的關係

DoDAF 案例規劃與演練《2》— OV5 (Operational Activity Model)

OV-5 — Operational Activity Model,可說是等同於傳統的企業的業務流程 (Business Process)描述, 在經由一連串的操作 (Operation)所組成的工作流程 (Workflow)後,以履行某一個業務標的或任務 (Mission)。

OV-5 的表達可說是幾乎與 UML 活動圖表達一般,它會描述在諸多活動之間包括 性能 (capibility), 活動 (activity, 或稱為工作, task), 輸入/輸出流 (I/O Flow)等資訊。

為了呈現某一連串活動所組成的活動圖,其目的為何,則可以利用企業層級的使用案例 (Business Use Case)來表達。

OV-5 精要 (Essential)筆記:

  • 利用企業層級的使用案例圖 (Business-level Use Case Diagram) 表達系統的規劃範圍。(本範例為 JFC 系統,亦即將聯合作戰指揮部當作系統)
  • 從使用案例可以看出:
    • 系統觸發事件的主要參與者 (primary actor),與系統的支援性參與者 (supporting actor)。
    • 系統所提供的服務 (service),每一個系統服務即為一個使用案例 (use case)。
  • 區分系統 “內” 與 “外” 時的好處在於:
    • 外部觀點即為功能性的需求分析,是站在外面看待如何 “用” 系統。
    • 內部觀點則著重在系統內部的組成結構元素,一般即以所謂物件導向的分析設計思維。
  • dodaf_ov5_business_usecase
    圖 1、OV5 – Business Use Case (點擊圖可察看原圖)

  • 作業活動圖 (Operational Activity Diagram)的重點在於表達什麼人(角色, role),在什麼時候,做什麼樣的事情(活動, activity),以及這些活動之間的流程關連。
  • 本張視圖的關鍵為呈現 “整體性的業務流程 (business process)”。
  • dodaf_ov5_operational_activity_model
    圖 2、OV5 – Operational Activity Model (點擊圖可察看原圖)

※延伸參考
 o DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)
 o 聊聊 DoDAF/MoDAF 規格與實作議題

DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)

對於大型系統利用 DoDAF 規格的架構規劃,其實均有個共同的特點,也就是有多個節點(Node)、多個資訊系統(Information System)。 包括軍事領域的聯合作戰指揮系統、以及政府單位防救災系統的架構規劃等,均是有這樣的特點:如何表達表達多個節點之間的關連性、如何表達多個資訊系統之間的互動。

兩個主要的觀點: Operation View and System View。 又依照每個觀點所涵蓋的層次(layer) 與 功能性質的不同,又分為 OV1~OV7, SV1~SV11。 有趣的是,即使是 Operation View,也會利用如 UML 的循序圖(sequence diagram),如 OV6,來表達節點之間的動態互動情形。 而 UML 循序圖一般是被用來表達軟體系統內部,參與物件之間的互動合作關係。 其實這隱含什麼意思呢? 很簡單的道理! 在 Operation View,也可以運用物件導向分析的手法,與 System View 所不同的只有:一個是把 Node 當物件;另一個是把 System 當物件;但是相同的是:兩者均用物件導向分析設計的思維來作塑模(Modeling)

依據「DoDAF Deskbook v1」的建議,Architecture View 的開發步驟可以參考如下圖的各種視圖的先後開發順序。 當然,這不會是絕對的,對我而言,在抓這類大型系統的架構時,首要就是要先能界定出系統的整體框架。當把某一個設計的目標框架,界定為一個系統時,就會分出 “外” 與 “內”,而兩者的分析手法與看待系統的角度就會不一樣了。 “外” 重視的是 “用”,所以會觀察系統所提供的服務,而服務就會衍生出,系統應該提供什麼 “介面(interface” 讓外部的參與者來用;再來 “內” 重視的就是系統的組成元素,這就是屬於結構分析的角度。結構分析觀察的兩個重點是,一個為靜態的結構關係、另一個就是,在動態為了完成某一個 “用” 的功能服務時,會有哪些元素的參與、它們彼此之間又是如何傳遞訊息的。 最終,你就會發現到,到底是如何 “界定” 某一個框架為一個系統,會是架構師最大的課題與其必備的素養了。

DoDAF_Architecture_View 建議開發步驟
圖 1、 摘錄自「DoDAF Deskbook v1 p.2-5」

從上圖中可以看出, 「DoDAF Deskbook」所建議的開發步驟,是以 AV1 開始觸發、以 AV2 涵蓋所有的視圖。 事實上,AV-1 是什麼呢? “Overview and Summary”。 其實它就是一份 SAD(System Architecture Document)。 文件內容大概就是包含了專案的目的、專案的描述與說明、架構規劃的標的、情境、任務、願景與目標 …等。 也就是說,在未來展開這個系統的規劃時,範圍與目標均是在該文件所描述的範圍之內。 AV-2 呢? “Integrated Dictionary”,它就是未來在涵蓋所有的視圖內,經常會使用的術語(terminology),要能給予一個明確的定義及其該字彙的意涵。

所以, “All-View” 只是文件的報告而已,真正的第一張視圖是 OV1— “High Level Operational Concept”。 這一張也可以說是要能涵蓋所要規劃系統全貌最大格局的視圖了。 它是給指揮官以上的層級所看的概念性視圖,所以盡量不要以技術面的角度來表達這張視圖。 參考下圖:

DoDAF_OV1_Conceptual_Diagram
圖 2、OV-1— 高階概念視圖

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal