UML OCUP_Foundamental 題型Reveiw與解析 <2>

Classes 的考題

Classes 的考題部分,當然都是針對 UML 的結構(structure)部分。包括最基本的元素(element),以及 Comment, Relationship, Namespace, Multiplicity, Expression, Constraint, Feature, Package, Interface, Dependency …等,這些都是可以被類別化(Classifier)而成為類別(Class)的。考題當然就是針對前述所提及的定義部分,以及圖形語法部分,而圖形語法,考最多的大概就是這些類別之間的關連(association), 還有多重性(Multiplicity), 相依性(Dependency) 等部分,尤其許多考題,是直接就出自於這些類別術語解釋最後面的範例(Examples)部分。關於一些 Classes 的圖形語法的考題,我把所記得考過的部分列舉幾題較具代表性的,然後以簡單的說明來解析該問題的意義。

Q1. 下列圖形中,Unique 代表的意義為何?

圖1. Multiplicity 的考題
圖1. Multiplicity 的考題

Ans:
A MultiplicityElement also includes specifications of whether the values in an instantiation of this element must be unique.

※解析
{Unique} 與 {Order} 是屬於多重性(Multiplicity)對值(Value)的一種限制,圖一當 Account 限制為 {Unique},則代表 Account 的多重值(multivalue),每一個被具化(instantiation)元素(element)的值都必須是唯一的;若限制為 {Ordered},則代表每一個被具化元素的值都必須依循序性(sequential)的方式來排列。

多重性可以同時有 {Unique} 與 {Order} 的限制,視兩者的組合與否,其集合型態的名稱則會不一樣,可參考表一。

isOrdered

isUnique

Collection Type

false

true

Set

true

true

OrderedSet

false

false

Bag

true

false

Sequence

表1. Collection Types for Properties

Q2. 參考下圖2,Types 套件(Package)內的元素係被ShoppingCart 利用 <<import>> 的方式來存取;而 Auxiliary 套件內的元素,則是被 ShoppingCart 利用 <<access>> 的方式來存取;然後,ShoppingCart 再被 WebShop 以 <<import>> 來存取。那麼,WebShop 可以存取哪些套件呢?

圖2. Package 相依性(Dependency) 的考題
圖2. Package 相依性(Dependency) 的考題

Ans:
WebShop 可以存取 ShoppingCart 與 Types 兩個套件內的元素。

※解析
這是屬於 Package 相依性(Dependency)的語法解釋問題。<<import>> 代表的是 “public” 的套件存取;而 <<access>> 則是 “private” 的套件存取,如同圖二的表達,Auxiliary 套件內的元素是被 ShoppingCart 以 <<access>> 的關鍵字(keyword)來存取使用,而未來則不能再透過 ShoppingCart 套件來被其它套件給存取;反之 <<import>> 則可以。


Q3. 參考下圖3,下列陳述,何則是正確的?

圖3. {xor} constraint 的考題
圖3. {xor} constraint 的考題

Ans:
Account 同時僅能連結 Person 與 Corporation 之一,而不能兩者同時連結,也不能兩者都沒有。

※解析
這是屬於 {constraint} 的考題,{constraint} 可以以自然語言或程式語言來表達元素、元素與元素之間的限制說明。上圖3,則是限制被用在關連(association)上,而其限制的意義,則依其 {constraint} 內的敘述,如 {xor} 代表著的就是兩者的連結,只能有其一。

Q4. 參考圖4,空心菱形代表的意義為何?

圖4. association 的考題
圖4. association 的考題

Ans: ternary association (三元關連)

※解析
Team, Year, Player 類別三者互為關連,此為三元(ternary)關係,在類別圖中係以空心菱形來表達之;而 Player 又有連結指向 Year,此兩者的關係為二元(binary)關係。

Q5. 參考圖5,請選擇適當的陳述(單選題)。

圖5. Association-ends with various adornments 的考題
圖5. Association-ends with various adornments 的考題

Ans:

  • Names a, b, and d on three of the ends.
  • Multiplicities 0..1 on a, * on b, 1 on the unnamed end, and 0..1 on d.
  • Specification of ordering on b.
  • Subsetting on d. For an instance of class C, the collection d is a subset of the collection b. This is equivalent to the OCL
    constraint: context C inv: b->includesAll(d)

※解析
adornments 的意義為 “裝飾”,這是考你對於在 association 的端點(end)的語法表達問題。{subsets b} 代表著的是 d (role-name)為 b 的子集合。 (老實說,這題考出來我根本不會,我是用猜的,沒想到讓我給猜對了。!^^ )

Q6. 參考圖6,Bank 類別底下有利用一個四方形框住(accountNo)的符號,其意義為何?

圖6. association 的考題
圖6. association 的考題

Ans: Qualified Association (限定關連)

※解析
這仍是屬於關連(association)的表示法,限定關連(Qualified Association)的語法是用在關連,而非類別。它是被使用在 “1對多” 或 “多對多” 的關連上。上圖6的意思為 Bank 係利用 accountNo 來辨識(identify) Person。

Q7. 參考圖7,下列陳述,何者為真?(單選題)

圖7. permit dependency 的考題
圖7. permit dependency 的考題

Ans:
the Employee class grants access rights to Executive objects. This means that executive objects may access the private properties of salary and homePhoneNumber.

※解析
相依性(Dependency)的考題蠻多的,尤其是在 stereotype 的表達上。以上圖7為例,<<permit>> 代表了 Employee 類別內的所有屬性(properties),均可被 Executive 類別來存取。

Q8. 參考圖8,下列陳述,何者為真?(單選題)

圖8. use dependency 的考題
圖8. use dependency 的考題

Ans: a Order class requires the Line Item class for its full implementation.

※解析
這仍是相依性的語法表示考題。<<use>> 代表著 Order 類別需要 LineItem 類別的完整實現。若是用在 Iterface 的表達中,就是一種 <<required>> 的關係。

Q9. 參考圖9,下列陳述,何者為真?(單選題)

圖9. Interface 的圖示表示語法的考題
圖9. Interface 的圖示表示語法的考題

Ans:
Isensor is the required interface of TheftAlarm as well as the provided interface of ProximitySensor

※解析
這是屬於 Interface 的圖示表示語法的考題。這該算是基本常識,應該要知道,因為會大量應用在 “Component Diagram”或 “Composite-Structure Diagram” 中。起碼要知道 “凹型(socket)” 代表著是 “required” 的介面表示;而 “球型(ball)” 則表示著是 “provided” 的介面表示。 兩者形成了一種 “ball and socket” 的關係。

文章導覽

   

共有 8 則迴響

  1. Hello Michael Tsai:
    您可以換個角度來思考本題目:
    「哪個時候,輔助性(Auxillary)的套件,只能被直接引用它的套件來存取,而不准透過其它的套件來存取?」
    有可能一個情境是:
    「Auxillary 套件是為工具(Utility)或單元測試框架,且是位於 ShoppingCart 套件內的子套件(Sub-Package)」,所以它只能被所謂的 “父套件(Parent-Package)”,存取使用而已。」
    當瞭解設計上的需求後,再來就是會想知道如何在圖上以及在程式碼上該如何表達。如此而已!
    至於那個什麼 “access” 的語意,是被規範在 UML 的標準規格而已,是 UML 工具廠商必須依循的規格。至於對於 Developer ,自由度很高,若要問我,該如何表達上述這樣的問題與情境,我個人對於是否要瞭解 “access”,根本不會太在乎,充其量利用 Note 註解,甚或創造所屬自己團隊專用的 “語意” (stereo type) 就好囉。
    要不是為了考證照,我是不會太在意這類問題的,意義實在不大,對設計也不會有啥幫助的。 🙂
    不過倒是可以藉由這樣的問題,來觸發思考到底在現實上的軟體開發時,是否會有類似這樣的情境。這個時候,會比較有幫助一些。 ^^

  2. 謝謝您的回覆。

    《access》的語意….我不知道有沒有理解錯誤,它應該跟匯入參考的遞移性有關,而不是一旦標示了《access》,某個套件裡面的 public 元素就非得經過特定套件才能存取。

    我的理解是 B access A,A 裡面的 public 元素會”出現” 在 B 裡面,而 C 若有 import B,則 B 中出現的 A 的元素並不會出現在 C 裡面。access 的語意就僅此而已,也就是說,那不代表 C 就不能存取 A 的 public 元素了。儘管圖上沒有標 C 和 A 的關係,不待它不可以存取,只是它 “還沒用到” 而已。

    如有誤解之處,還請版主指正。Thanks 🙂

  3. Hello Michael Tsai:
    那是 UML 規格的語法限制,是那個 《access》的語意,要說為什麼,就是規格的限制,如同你認為 publice 可共用存取、private 無法被呼叫,道理是一樣的囉。

  4. 您好:

    我對 Q2 的答案有疑問….

    答案寫 WebShop 可以存取 ShoppingCart 與 Types 兩個套件內的元素。
    但我不了解,WebShop 為何不能存取 Auxiliary 套件內的元素?
    題目並沒有說明 Auxiliary 套件內的元素是 public 還是 private,如果是 public,那麼 WebShop 當然可以存取 Auxiliary 內的元素,只是必須以 full qualified name 的方式參考那些元素罷了。不是嗎?

發佈回覆給「毛怪」的留言 取消回覆

發佈留言必須填寫的電子郵件地址不會公開。