130. 只有在單向結合關係上，才標示出方向性(Indicate Direction Only on Unidirectional Associations)
131. 避免標示出不可航性(Avoid Indicating Non-Navigability)
--------------------
特別注意的是，結合點端的標記在新版的UML2版中有所變動，與UML1版略有不同。請看到圖113的範例，這是UML規格書上的範例，我重新繪製用來說明此處的概念。先談UML2版，結合關係的箭頭端，代表具有可航性；打個小叉叉，就是不可航；單純直線，代表還未指定可航或不可航。
圖113: UML規格書中的範例
所以，再回頭看到圖113的例子中：
1. AB是雙向結合。
2. CD是兩端都不具有可航性。
3. EF還未指定兩端是否具可航性，還是不具有可航性。
4. GH為單向結合，可由G航行到H。
5. I端還未決定可否航行，可以確定的是，可由I航向J。
UML2版這樣定義之後，其實就很清楚了。不過，由於UML1版不是這樣定義的，所以實務上混淆著UML1版和UML2版的情況下，就容易造成誤解。
我們來看原先UML1版的定義，只有兩種情況：有箭頭或沒箭頭。有箭頭就是可航行，沒箭頭就不可航行。所以，如果以UML1版來解釋圖113的話：
1. AB是雙向結合。
2. CD無法解釋，小叉叉是UML2版的新符號。
3. EF也是雙向結合。
4. G端無法解釋，H端具有可航性。
5. IJ是單向結合，由I端航行到J端。
當年UML1版給了兩套表示法，只是實務上都採用第一套表示法：
1. 直線代表雙向結合；單箭頭代表單向結合。
2. 雙箭頭代表雙向結合；單箭頭代表單向結合。
回到實務上來說，畫雙箭頭或小叉叉太繁瑣，所以現在都還是沿用單箭頭表示單向結合，直線表示雙向結合的表示法。到目前為止，多數的UML工具都還是採用直線代表雙向結合、單箭頭代表單向結合，也因此，指南130和指南131才會建議不用雙箭頭、也不用小叉叉標記。
--------------------
132. 只有在有改變時，才重新繪製繼承而來的結合關係(Redraw Inherited Associations Only When Something Changes)
--------------------
談到一般化關係所帶來的繼承效果，許多人都只知道屬性與操作的繼承，忽略了結合關係也可以被繼承下來。比方說，在圖114範例中，個人父類別與密碼類別之間的結合關係，就可以透過一般化關係繼承給存戶子類別與投資人子類別，繼承下來的情況如圖115所示。
圖114: 結合關係也可以繼承
圖115: 繼承而來的結合關係
通常，不需要特別繪製出繼承下來的子結合，除非是繼承而來的子結合有所改變，這時便如指南132所建議的，需要把子結合繪製出來。延續上述的範例，如果銀行規定投資人需要設置兩組密碼，比一般的存戶多一組密碼，如圖116所示。在這種情況下，就需要將子結合繪製出來，以便能夠更改個體數目，如圖117所示。
圖116: 個體數目改變了
圖117: 繼承而來的結合關係改變了
其實，結合關係之間也可以擺放一般化關係，就跟類別之間的一般化關係圖示一樣，如圖118所示，只不過多數的UML工具都沒有支援這樣的表達方式。
圖118: 結合之間的一般化關係
--------------------
133. 詢問個體數目的上下限(Question Multiplicities Involving Minimums and Maximums)
--------------------
其實，個體數目在反映企業規則，所以它很可能會隨著時間而變動，必須對它保持開放性的詢問。比方說，在上述的銀行範例中，過去銀行規定，無論是存戶或投資人只需要設置一組密碼。可是後來，因為提高了安全機制，所以更動了原先的企業規則，在新的企業規定中，投資人必須比存戶多設置一組密碼，變成設置兩組密碼才可以。
<上一篇><下一篇>
0 回應:
張貼意見