A Recurring Duties Analysis Pattern

循環債務分析樣式

Lubor Sesera Softec, Ltd。

Kutuzovova 23, 831 03 Bratislava, Slovakia

e-mail: lubor@softec.sk

翻譯:巫明遠

摘要

此論文主要是為了解決一個複雜的債權(obligations)系統中,循環債務 (recurring financial duties)所產生的疑難問題。本文建議將債權從當事人(party)分離(decoupling)出來,並且在固定的時間點從債權中產生債務(duty)。在此種方法下產生的債務,具備所有必須的資料,以及指定這個債務的付款金額。藉由此法,該債務和他們該付的付款金額,可以在任何時候被輕易的查核。此分析樣式是從保險業中興起,但是可以應用於其他領域,例如貸款、分期付款、以及政府社會補助(state social support)。它不僅跟金錢進帳有關也跟未償貸款有關。

動機

一家保險公司和一個客戶簽訂保險合約並收取保險費。該保險合約通常在某一段時間內是有效的,且客戶不需要一次便將全部的保險費付清。該保險公司在任何一個時間點,想要知道應收保險費總合;以及實際上已經真正拿到的保險費數目。為了讓此種需求單純以及有效,保險帳單(premium prescriptions)在固定的時間點產出(例如:每天晚上)。[註1] 圖 1 是用 UML [Booch+ 1998]舉例描述從保險合約中分解保險帳單的類別圖:

背景

當一方與另一方有債務關係。 這些債務起因於雙方間的訂單、合約或協定,或者是起因於法律制定的法律文件(例如: 政府補助金的核准申請書)。在此論文中我們使用一個抽象概念『債權(obligation)』來代表上述的那些文件。債務通常是循序不斷的,然而,所支付的金錢數目卻因為狀況的不同而有些差異。每個當事人與其他許多相關的當事人,可以有許多的債權關係。此外,此軟體系統可以安裝在雙方,即付費方及相對的收費方。

問題

如何在這樣複雜的系統中,便利快速且有效的找出任何特定時間點下的債務及其應付款?

相關限制

  1. 此系統相當複雜: 一個當事人可以同時擁有許多依照狀況而不同的債務,且這些狀況還會因時間而改變。

  2. 使用者想要簡單的模型(Models)。太多類別的模型是相當難以了解和維護的。

  3. 債務和他的應付款在使用者互動操作下,必須快速準確的回應。

  4. 該模型必須夠靈活,能容納多樣化的債權,當事人和應付款。

解決方案

從債權中分解各別的債務。這包含一個可以定期產生債務的作業(Operation)。 每次執行該作業,均能產生該時段內合法的債務。 在債務中紀錄所有必須的資料,以便未來不需要重新計算,把應付款指定給這類的債務。

需求[註2]

  1. 定義債權型態:

    由一個領域專家定義包含限制和總金額的債權型態,限制包含以下:

  2. 管理債權:

    一個資料登錄者產生一個債權或管理其更新。 管理債權除了管理債權本身外,還包括管理當事人、角色、付款的方法等。

  3. 產生債務:

    一個會計師(或是系統時鐘)執行函式自動產生債務,此函式藉由確認債權中所記載的啟始日期和頻率值來運作。

  4. 處理應付款:

一個會計師處理債務的應付款。系統幫忙確認當事人和其支付過的債務。

結構

副樣式(Subpattern) (中心概念)

超樣式(Superpattern)

參與類別

此樣式包含兩種抽象層次的類別:知識層級含(Obligation type、 Party role type、 Condition、 Amount) 和操作層級(前述以外的其他的類別)。

在知識層級中,ObligationType 和 Conditions 是有結合關係(associate)存在的,這些 Conditions 是應用於在 Obligations 生命週期中,各種狀態下的這種型態的 Obligations。 Conditions 有許多種類:驗證 obligation,選擇 duty 總金額,以及在產生 duty 時循環驗證。此外,ObligationType 被指定為可支付的總金額,這個總金額就是一個債務。Amout 可以是確切的數字,或者是一個函式的參數 (例如:保險業的費率(percentage tariff)等)。如果許多 Amounts 被指定給一個 ObligationType, Amounts 藉由 conditions,在產生 duty 時作評估,來辨別彼此。最後,ObligationType 明確說明允許的 party roles。

操作層級由使用個案中需求所指定的三組類別組成:

  1. Obligation 及其結合的資料

    如同在背景(請參閱前)所略述的,obligation 為代表各式各樣(合法)文件的抽象個體(例如:合約、訂單、申請書等)[註3] 它是從 party 中分解出來的,因為一個 party 可以同時擁有數個 obligationt (例:一個客戶可以跟同一家保險公司簽訂數個保險合約)。Obligation 可以擁有成分(例:assured risks 是保險合約的的一部分)。 我將這種可能性利用圖三的遞迴聚集表達出來。obligation 藉由parties 的 roles 和實際的 parties 結合。通常,obligation 可以和許多 party roles 結合。 舉例來說,想想在政府社會補助[註4]下,所有家庭成員和他們所扮演的 roles,一定需要在家庭零用金申請書(family allowance application)中提到。

    主要的相對 party,如受款人宣告一個支付 obligation 的方法,以用來確認 payments,或其他 party 知道相對去哪裡付款。付款的方式(WayOfPaying)是個抽象類別。銀行帳戶、信用卡、一個郵遞位址(postal address)等,是它具體子類別的範例。

  2. Duty

    duty 是一個當事人對另一個當事人的應收帳款或債務。它是從 obligation 產生出來的。 Duty 結合某個時間區段,且擁有所有必須的資料,特別是那些有風險及重新計算很浪費時間的資料,尤其是錢的總合。

  3. Payment

    payments 擁有某個 party 實際的應付款。以應收帳款來說,它被指定給收款人。以債務來說,它被指定給受領者。 當一個 party 可以利用數種付款的方式,此指定作業間接的利用 paying 物件.。此外,payment 結合其有關的 duties。以應收帳款來說,有一種特定的演算法隱藏於其後。它由兩個步驟來實行:第一,它定義了收款人(使用資料庫宣告付款的方式),然後它找出 duties。產生相關的連結(例:個別對 WayOfPaying 或 Duty)是每個步驟的結果。

合作

圖四的循序圖描繪了「產生 duty」這項需求。 為了簡單,該圖沒有呈現出繼承和例外(exceptions)。 訊息中的參數用引號包起來代表其傳入一個實值(direct value) (相對於傳入一個必須要計算的參數,例:一個變數的值或運算式)。

會計人員從 Obligation 類別所控管的批次函式開始執行。 generateDuties 函式歷遍了 obligations 的集合[註5](譯註:就是有個集合裡頭有很多 obligations)。首先,它嘗試去找出是否有 duty 應當在所指定的時段內產生(obligation 可能早已經到期,duty 早就已經被產生等)。 接下來, conditions 被評估(某些屬性的正確性可能已經失效)。

之後,總金額就被算了出來。 如果有許多 amounts,實際的總金額需要依照 conditions 來產生。最後,duty 就產生了。圖四的訊息是用來定義圖三中類別的操作。

後續推論

使用循環債務樣式有利也有弊:

  1. obligation 從 party 中分解出來。 在很多應用領域中,這種分法對於領域專家或者是軟體開發者是相當習以為常的(例:在保險業中有明確的合約)。在其他領域中,這可能會造成小部分的困擾(例:在我們國家中,公司向 Nation Labour Offices 支付 duties 並不需要有合約[註6])。

    從 party 中分解 obligation 是必要的,特別是當一個 party 可以同時擁有許多 obligations。否則了話,這些實體是可以被合併的。

  2. Obligation 可以在其每個特定角色中包括數個 parties。這種情形的例子很少(例:之前所提及的家庭零用金例子)。 許多時候,一個 party 就夠了(例: 某 party 為是使用此軟體系統 party 的對立方)。在這種情形下此樣式可以更簡化。

  3. 此樣式略述出一個宣告,這個宣告代表 conditions 和總金額。然而這個樣式對於這個議題沒有更詳細的考量。在我們開發的政府社會補助軟體系統[Phare 1999]中,這些 conditions 被更詳細的說明以及實作。遺憾的, 那些呈現方式(representation)太過於因應用程式不同而不同,有些甚至已經是現代的法規了。

  4. 此樣式假設 payments 被指定給 duties。在某些系統中這是不必要的:他們只需要平衡所有 payments 的總合和 duties 的總合。 然而,許多系統必須要更加精確。將 payments 指定給 duties 可以是相當複雜的工作: 一個 payment 可以支付許多的 duties 且一個 duty 可以被許多的 payments 支付(這說明了圖三中 Duty 和 Payment 多對多的重要性)。 Payments 如何指定給 duties 的演算法,屬於相當的領域特定知識,或說是公司的特性;因此,此處只將可能性描繪出來。

  5. 在此模組中並沒有把歷史呈現出來。[註7] 舉例來說,一個 party 隨後可以改變其 obligation 中的一些屬性。因為這種改變,duties 的計算方式從那時開始改變,但並不影響到之前的 duties。 之前的屬性值應當被保存以便歷往的 duties 可以在未來的任何時間點被查核。類似地,知識層級類別(如condition、 amount 等)的歷史也應當同樣的被保存下來。

已知使用

循環債務分析樣式在保險業的使用是相當平常的。我們已經在我們的公司使用它來開發傳統保險(如資產保險)[Koop 1999][註8][Sesera 2000b] ,和社會保險(如健康保險,失業保險)的軟體系統[Health 1996]。

此樣式應可應用在租賃和分期付款領域,既使我們沒有明確的參考資料。

前述的所有樣式運用皆考量收入(應收帳款)。 然而,此樣式也可以被使用在未償貸款(負債)上。 例如,我們曾在 ISOP 政府社會補助資訊系統中使用它[Phare 1999] [Sesera+ 2000a]。圖五顯示出循環債務樣式在政府社會補助系統的應用。

相關樣式

循環債務樣式使用Fowler’s Accountability pattern ([Fowler 1997] p.25) 當作子樣式,如:Obligation 和相對是 Accountability,而 Obligation Type 相對是 Accountability Type。 如同我們允許 obligation 和 它所屬的 parties 有多對多關係,我們改變了Accountability pattern 將之變為Contract Roles pattern (from [Hay 1996] p107)的風格。

Martin Fowler 提出另一種「循環」樣式,叫做 Recurring Events [Fowler 1996]。 他的樣式的目的和我們的並不相同。他的樣式注重在許多不同的事件,發生在不同的時段循環,而沒有提到任何(金融)債務。相反地,我們的目標在於金融債務,而不是何時他們的產生是否依據進度。所有種類的債務通常都是一起且規律的產生(例:每天或每禮拜一次)。如果需要了話,這些樣式是可以被一同使用的(結合在一起)。此循環債務樣式也提出了暫時的議題(temporal issue)。 Obligation 和 Duty 結合擁有值的時效期。如果它們是明確的,它們每一個都是 Temporal Association pattern [Carlson+ 1999]中 Temporal Association entity 的特例。

循環債務樣式從保險業中興起。Wolfgang Keller 可能是第一個提供某些對此領域有價值的樣式[Keller 1998]。 然而,他的樣式是屬於不同種類的。 首先,他的樣式是特定於保險業,而我們的樣式較通用。其次,他的樣式通常較粗魯(coarse-grained)(例:保險價值鏈)而我們的樣式較細緻。主要的差異在於所關心的主題。

Keller 特別強調於知識層級,對產品定義的相關議題(相關樣式如: Product Tree、 Object Event Indemnity 等。) 和政策 (Policy as Product Instance) , 而我們的重點在於操作層級,也就是收入。

感謝

我想要感謝我的指導教授 Ed Fernandez,他所提出的精闢評論,以及他在審查此論文所提供的一切。我也對於 Stephen Sebesta 所提出的評論感到感激。

參考文件

[Booch+ 1998] Booch, G。, I。 Jacobson, and J。 Rumbaugh。 Unified Modeling Language User Guide。 Addison-Wesley, 1998。

[Carlson+ 1999] Carlson, A。, S。 Estepp, and M。 Fowler。 Temporal Patterns。 In: Pattern Languages of Program Design 4。 Addison-Wesley, 1999。

[Hay 1996] Hay, D。 Data Model Patterns: Conventions of Thought。 New-York: Dorset House, 1996。

[Fowler 1996] Fowler, M。 Recurring events, PLoP’96。

[Fowler 1997] Fowler, M。 Analysis Patterns: Reusable Object Models, Reading, MA: Addison-Wesley, 1997。

[Gamma+ 1995] Gamma, E。, R。 Helm, R。 Johnson, and J。 Vlissides。 Design Patterns: Elements of Reusable Object-Oriented Software, Reading, MA: Addison-Wesley, 1995。

[Health 1996] Information System of the General Health Insurance Company。 1996 (in Slovak)。

[Keller 1998] Keller, W。 Some Patterns for Insurance Systems。 PLoP’98。 Also at:  http://ourworld.compuserve.com/homepages/WofgangWKeller/

[Koop 1999] Software system for the Kooperativa insurance company。 1999 (in Slovak)。

[Phare 1999] Information System of the State Social Support。 Phare # 951801, 1999。

[Sesera+ 2000a] Sesera, L。, A。 Micovsky, J。 Cerven, J。 Architecture of software systems: Analysis Data Patterns。 Textbook。 Slovak Technical University, 2000 (in Slovak) (in print)。

[Sesera 2000b] Sesera, L。 Analysis Patterns。 (Invited talk。) In: SOFSEM’2000。 Lecture Notes in Computer Science series, Springer-Verlag, 2000 (in preparation)。


註釋

  1. 當然,保單也可以依照需要才被交互的產生

  2. 使用使用個案來表達。

  3. Obligation 可以被想成 Fowler’s Accountability [Fowler 1997]中的一個特例。

  4. 至少在斯洛伐克為如此。

  5. 為了更精準,我們應該也介紹集合類別(collection classes)或類別函式。但為了簡潔,它在此被省略。

  6. 然而,Obligation 類別是需要的,因為一個 party 可以同時支付許多 duties。

  7. 雖然對於某些範圍它被藏在背景。

  8. Kooperativa 保險公司 Wiener Stadtische Versicherung 的一家子公司。