2011年10月20日

1.4.6-一般化關係

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.6-一般化關係

系統分析師透過類別定義屬性和操作,所以日後針對同類別的一群物件,就可以使用相同的方式對待它們。不過有時候,這些物件並不是全然相同,可能大部分的屬性和操作相同,但是少部分的屬性和操作卻不同。在這種情況下,類別之間的一般化關係(Generalization)就派上用場了。

現在我們先來看一段模擬情境,體會系統分析師在訪談期間可能遇到的情況,隨後我們才說明如何使用一般化關係。當系統分析師訪談到申購基金的主題時,立即理解到「申購交易」是一項很重要的概念。所以,系統分析師檢核了成為候選物件的兩項要件,我們在前面曾提及:

1.在企業運作過程中,企業人員會使用到的專業事物或概念。
2.而且,在資訊化時,系統也會用到,或者需要保管。

客戶申購基金時,企業人員確實會使用到申購交易的概念,符合前述要件1。而且,在資訊化時,系統也需要保管每一筆的申購交易,符合前述要件2。「申購交易」同時符合上述兩項要件,所以系統分析師將它列為候選物件,並且讓所有的申購交易物件歸屬於同一類別,如圖1-4所示。


圖1-4: 申購交易類別

企業人員說:申購交易有兩種,一種是單筆申購,另一種是定期定額申購。

系統分析師問:這兩種有什麼不同呢?

企業人員答:單筆申購比較簡單,就跟我們平常買東西,一次買斷的情況相同。客戶單筆申購某檔基金100,000元,買斷,我們給客戶申購交易的憑証號碼,交易就結束。定期定額申購,比較像是一種約定,客戶可以跟我們約定每月的15號,自動從指定扣款帳戶支出5,000元申購某檔基金。每月15日定期,每次5,000元定額,指定某檔基金,指定某個扣款帳戶,經過這樣的約定之後,每個月就會定期定額自動支出一筆資金來申購基金。

系統分析師問:那客戶可以更改定期定額的約定嗎?

企業人員答:隨時可以改啊!

系統分析師問:可以更改哪些項目?

企業人員答:可以改扣款日期、投資金額、扣款帳號,還有扣款情況。


圖1-5: 三個申購類別

系統分析師定義出三個申購類別,相較起來,申購交易屬於一般類別(Generalized Class),單筆申購與定期定額申購屬於特殊類別(Specialized Class),如圖1-5所示。

因為,系統分析師把單筆申購與定期定額申購裡,通用的屬性與操作記錄到申購交易類別,所以申購交易類別定義了通用且一般性的屬性與操作。至於,單筆申購與定期定額申購兩者獨有且特殊的屬性與操作,當然還是記錄在兩者自己的類別裡。所以,相較於申購交易的一般性,我們將申購交易歸屬於一般類別,而將單筆申購與定期定額申購歸屬於特殊類別。

系統分析師可以透過檢核下列兩項要件,判斷是否採用一般化關係:

1.在企業領域的專業概念裡,特殊物件必須「是一種」(a kind of)一般物件。
2.多種特殊物件裡,有部分通用的屬性與操作,也有部分獨有的屬性與操作。

上述的「是一種」要件,必須遵守企業概念。舉例來說,我們可以接受「休旅車是一種汽車」,但是很難接受「遙控車是一種汽車」。因為遙控車是玩具,不是汽車,或許說「遙控車是一種玩具汽車」,會比較符合企業領域裡的專業概念。

請看圖1-6,系統分析師經過下列思考決定使用一般化關係:

1.單筆申購是一種申購交易,定期定額申購也是一種申購交易。或者說,申購交易可以分為兩種,一種是單筆申購,另一種是定期定額申購。(符合上述要件1)

2.單筆申購與定期定額申購裡,都需要記錄申購日期、信託金額、扣款帳號、憑証號碼這四項屬性,以及必須執行計算手續費這項操作,這些屬性與操作屬於通用部分。看起來單筆申購確實比較單純,沒有特殊的屬性和操作。不過,定期定額申購就不是這麼單純了,它多了扣款日期、投資金額、扣款情況這三項屬性,以及多了一個約定異動的操作。(符合上述要件2)


圖1-6: 類別之間的一般化關係

在一般化的過程中,我們將特殊類別裡頭通用的屬性和操作記錄到一般類別裡,因此透過一般化關係,特殊類別可以繼承(Inheritance)一般類別裡的通用屬性與操作。由於特殊類別透過繼承,可以直接重用(Reuse)一般類別裡的屬性、操作和方法,節省開發成本。變動發生需要改版時,也只需要改版一般類別,節省維護成本。

請看圖1-7裡的特殊類別,我特別將繼承來的屬性與操作一併列出,而且使用網底區分。


圖1-7: 從申購交易類別繼承而來的屬性與操作

沒有留言: