69. 如果參與者出現在使用案例中，則可以在參與者與使用案例之間放置結合關係(Indicate an Association Between an Actor and a Use Case if the Actor Appears Within the Use-Case Logic)
--------------------
在使用案例圖中，參與者與使用案例之間的實線，無論帶箭頭與否，都稱之為「結合關係」(association relationship)，如圖42所示。
圖42: 結合關係
參與者與使用案例兩者之間的結合關係代表著，參與者在該使用案例的執行期間，會與系統交換資訊、彼此互動，以便完成整個使用案例。簡言之，整個使用案例的執行期間，其實就是參與者與系統相互對話的互動過程。
--------------------
70. 參與者與使用案例之間的結合關係線上，避免出現箭頭(Avoid Arrowheads on Actor–Use-Case Relationships)
--------------------
參與者與使用案例之間的結合關係，用來代表參與者與系統雙方的「通訊關係」(communication relationship)。特別注意，有許多人誤以為這條關係線是用來表達資訊或資料流向，其實這是個誤解。也正因為這樣的誤解，讓原著作者認為最好少用箭頭。
以最原始的定義來看，結合關係既然代表溝通關係，那麼帶箭頭的結合關係便可以解釋為單向溝通，可是反觀現在的系統，鮮少是單向溝通。比方說，我們去使用自動櫃員機時，一開始螢幕上可能出現請插入晶片金融卡的訊息，然後我們依照指示逐步輸入資料給自動櫃員機，這就是一種典型的雙向溝通。
也因為現在的系統多半是雙向溝通，所以帶箭頭的結合關係在使用案例圖中就沒多大用處了。不過，我倒是在實務上或教學上，都建議使用單向的結合關係，用以分辨參與者扮演的是啟動角色還是支援角色。
請看圖43基金系統的範例，投資人是設定扣款日期使用案例的啟動者，所以帶箭頭的結合關係線由參與者指向使用案例，代表投資人是扮演啟動角色的參與者。
「時間」參與者將啟動自動扣款申購當期基金使用案例，代表這個使用案例是系統定時啟動的，而這個使用案例的支援者為綜存系統。由於，綜存系統是扮演支援角色的參與者，所以帶箭頭的結合關係線由使用案例指向參與者，代表綜存系統是支援者。
圖43: 帶箭頭的結合關係
<上一篇><下一篇>
0 回應:
張貼意見