分析樣式與商業物件
(Analysis Patterns and Business Objects)

原文出處:http://jeffsutherland.org/oopsla96/fowler.html

作者:Martin Fowler



譯者:Justim (justim@seed.net.tw)

校稿:朱子、Areca Chen

我是個從事分析及設計商業系統的顧問,我並沒有花多少時間就了解到這份工作會讓我一直遇到相似的情況。在逐漸累積相關的知識後,我可以粹取前一個專案的模式(model),稍加修改後應用在新的專案上。這些之前所累積下來的模式成為上述技巧的關鍵部分,於是我將這些有用的models寫下來並以書面的形式發表,也因此使我和研究樣式的社群有所接觸,在樣式Pattern)的領域中,上述工作較傾向被歸類於“樣式分析”的領域,於是也有了Analysis Patterns這本書的誕生[Fowler 96]

以一個系統發展人員而言,我同樣對商業物件(Business Objects)這個領域有興趣,用一組標準的商業物件來解決重複發生在商業上的問題是件很吸引人的事。這篇發表的論文帶您審視關於分析樣式及商業物件之間的關係,其中還包含了一些我在補捉(capture)分析物件過程中所得到的見解。

什麼是分析樣式?What is an Analysis Pattern?

除了這外,還有許多人正在從事著跟分析樣式有關的工作,但是這些成果只有少數被發表,所以我認為定義分析樣式最好的方式,就是以一個小例子來說明。

圖一是我書中一個叫measurement pattern(量測樣式)的樣式,它是用來在一個健保系統中用來記錄(capturing)病人身體的狀況。直覺上,我們會用一些屬性來代表病人身體的狀況譯注:這是指體檢的結果,好比說「血壓」多少,「身高」多高…等。當這些屬性不多時,上述方式的確可以運行的很好,但在一間醫院中,可能要度量上百乃至上千個的這些屬性,為每種屬性均定義一種操作方式將會導致產生一個薄弱且複雜的介面(interface)。解決這種困境比較好的方式是將所有可以量測的事物(好比說身高、體重、血型…等)視為一個phenomenon型別物件的實例(instance)。如此一來,每一個person可以有許多measurement,而每一個measurement都可以指定一個phenomenon型別的值,且所有的measurements將只會有一個屬性,而person只需要使用一個屬性就可代表所有的measurement,這麼做的話所有對屬性的操作將化約為只要針對上千個measurement的實例及phenomenon型別的查詢即可。這個方法更進一步的好處是我們可以為measurement添加新的屬性,好比說記錄如“誰應該處理它”,“何時處理”或者是“要去那兒處理”之類的資訊。

Measurement pattern diagram

1 Measurement PatternUML示意圖

例如:設John Smith有六呎高,則以measurement pattern來表示的話,就是一個personJohn Smith,其phenomenon type是身高,quantity6呎。

雖然它是個很簡單的樣式,但我們可以跟據它來建構更複雜的樣式,這些樣式都是探索記錄定性和定量的資訊以及在觀察之間的因果關係。

Measurement Pattern及所有建構在其上的樣式,是在建立British National Health Service (NHS)的健保系統時所發展出來的。很明顯的,它們都是依據健保系統的需求所設計出來;但有趣的是在數年後,我利用這些樣式來為美國一個大型的建造商建構一個財務分析系統。在我們的工作中証明開始就採用這些樣式是非常值得的,我想以健保模式為基礎來建構商業財務分析模式是可以理解的,雖然還是要對它們做一些修改,但實際上有許多修改最終還是可以應用在到健保系統上。

分析樣式與商業物件(Analysis Patterns and Business Objects

那麼分析樣式(analysis pattern)及商業物件(business objects)之間的異同點又有哪些?對我而言,主要的不同在於商業物件有特定使用的意味在譯注:原文是prescriptive,而分析樣式則比較具有啟發性譯注:原文是suggestive。如果我買了個為會計系統設計商業物件,那我就得遵循它當初被設計的目的來使用它們。當然我還是可以利用繼承或其他的方式修改它們,但是所能修改的多寡,是取決於當初設計它的人決定開放多少修改的權限給客戶端。分析樣式則是一個模型,這個模型包含了這個樣式為何以如此形式出現的理由,及這個樣式的優點和缺點。在我實作一個樣式前,我可以任意地修改它,如果這個樣式是已經有程式碼的實作的話,我可以用這些程式碼,或者我可以依自己喜好來修改它們。對於樣式最重要的觀念是:重點不是樣式的模型(model)或是程式碼,而是存在其背後的基本原理。

商業物件有許多強過分析樣式的地方,對於商業物件,你只要購買它們,並安裝使用即可,然而對於樣式,你得到的只是個觀念,所以你必需想法子去實作它,即使範例程式被當作是針對樣式用法的說明,也較視其僅是擁有有用的程式碼單元,來得有意義的多

在系統的整合上,商業物件也是比分析樣式為強,兩個使用相同商業物件的系統在整合上應該會比只使用相同樣式的系統為較容易。一個只使用相同樣式的系統,雖然在基本的概念、類別及其互動的方式會十分的相似,但命名方式可能就有不同,所以在整合上還是有所困難。當然使用相同的樣式還是有優點的,例如這些相似性就可以讓人很快的了解這個系統的架構。

這麼說來商業物件看來比分析樣式好太多了,而你可能會懷疑為什麼我們還需要有分析樣式。這兒我提出兩個理由,第一,分析樣式可以用來記錄商業物件的概念,可以用其表現出商業物件的設計方式,及它們如何工作,因而讓它們更容易使用。

第二理由可能比較讓人沮喪,商業物件在某種程度上你必需要遵循它的法則來做事,在我大部分的職場生涯中曾和許多想要找出標準商業方法(如整合data models(共同的資料模組))的人一起工作,整體而言,這些工作最後徒勞無功。我的同事們可能記得在一個大型的case中,我們試著找出對於會計系統的標準定義,這個商業邏輯有13個不相容的定義,而且無法解析它們,而這只是牽涉到一間公司的狀況而已。許多的公司及組織內可能都會有類似的情況出現,有時候搞垮標準化是來自於政策上的考量,有時則是根本是概念上的不同,而這兩種狀況都導致了標準化的失敗。商業物件的特定使用的性質像是把兩面的。樣式在傳播上就比較簡單了,因為它們只是種概念,相對於商業物件,樣式的好處雖然比較少,但是你可能會更了解它們,因此你可以較輕鬆的方式獲得系統的共通性(commonality),而使用商業物件則是一種高需求/高收益的方式。:高需求即商業物件需與需求高度相符,而高收益即因需求高度相符因此馬上可以獲得高度的效益

以這種觀點來看話,其實分析樣式和商業物件是互補的,而我們應該依現況選擇適當的方式來發展這兩種概念。

研究分析樣式後我有另一個想法,討論商業物件其實是討論一個垂直領域(vertical market,即互不相干的特定市場),如健保系統,營造業,金融業…等。但依我在measurement pattern上的經驗而言,事實上用在健保系統上的樣式及商業物件其實是可以用在商業上的金融系統的,而這就是跨越了兩個不同的垂直領域。樣式就像是種診斷的過程,而這個過程其實以經用在許多不同的領域。我相信分析樣式和商業物件最好是由一個抽象的流程組織起來,例如:診斷、會計、設計及交易。我並不十分確定如何去分割它們,或者是這個整體的概念應該是如何,不過我認為這會是個值得去嘗試的方向。


參考文獻(References

[Fowler 96] Fowler, M. Analysis Patterns: Reusable Object Models, Addison-Wesley, Reading MA, in press.

進階閱讀(Further Reading

Since my book is not out until OOPSLA, these give you some pointers to other places where there are examples of analysis patterns, as well as work by other people in this field.

Fowler, M. "Modelling Organisation Structures," Report on Object Analysis and Design, 2,2, (1995), pp. 20­23.
An early paper that discusses the accountability pattern.

Fowler, M., Cairns, T. and Thursz, M. "Observations and Measurement," Report on Object Analysis and Design, 2,3, (1995), pp. 20­24,37.
An early paper that discusses the observation patterns

Fowler, M. "Accountability and Organization Structures," In Pattern Languages of Program Design 2, Vlissides, J.M. et al. ed., Addison-Wesley, (1996), pp.353­370.
A paper that covers the same material as the ROAD article on organisation structures, but uses a more pattern-like form.

Fowler, M. Recurring Events, Portland Pattern Repository, <http://c2.com/ppr/titles.html> , 1996.
A more recent paper on handling such things as 'as every second thursday in June' .

Hay, D. Data Model Patterns: conventions of thought, Dorset House, New York, NY, 1996.
A very similar book to mine, but using a relational modeling technique.

Coad, P., North, D. and Mayfield, M. Object Models: strategies, patterns and applications, Prentice Hall, Englewood Cliffs, 1995.
These patterns are really quite different to mine, at least in intent. They are more abstract and are aiming at trying to generate models, rather than examples of actual models.

Scheer, A.-W. Business Process Engineering: reference models for industrial enterprises, (Second Edition), Spinger-Verlag, Berlin, Germany, 1994.
These are not patterns, but rather a proposed reference model for manufacturing. It is very relational in nature, but a good source of ideas for patterns.