穩健分析是ICONIX開發方法中的第三個步驟,SA在繪製循序圖之前,需要先透過穩健圖(robustness diagram)決定有哪些物件將參與使用案例。
一般的UML初學者對穩健圖會比較陌生,所以接下來,我們會先談穩健圖的概念,隨後才會繼續討論編號8和9的分析癱瘓警訊,以及討論採用穩健分析的十項好處。
穩健圖
一旦採用了穩健分析之後,可以迫使系統分析師在繪製穩健圖時,重新檢視使用案例敘述,同時加入更多的物件思維,也因此可以更順暢地移動到純物件化的類別圖與循序圖設計上頭
分析癱瘓警訊
善用穩健圖但不濫用,千萬記得它是讓整個開發流程得以從使用案例分析順暢推進到循序圖設計的催化劑,不需要浪費時間把穩健圖做得細緻又完善。
穩健分析的十大好處
穩健分析不是UML2標準的一部分,所以使用者比較少。難得原著作者使用穩健分析多年,所以很值得看看在他的實務經驗中,穩健分析可以帶給開發人員什麼樣的好處。穩健圖
在穩健分析中,主要將物件依用途分為三種,分別為邊界物件,還有控制物件(control object)和實體物件(entity object),其圖示如圖1。
圖1:邊界物件、控制物件及實體物件
簡單來說,邊界物件在處理系統內外的溝通,控制物件主要用於控制流程,至於實體物件則用來保存重要的領域資料和規則。所以,當系統在執行使用案例時,系統外界的參與者會透過邊界物件,來跟系統內部的控制物件溝通,或者跟實體物件溝通,如圖2所示。
圖2:使用案例與物件
以圖3的登入會員使用案例為例,我們設計了一張如圖4的穩健圖,簡單說明購物網站在執行登入會員的使用案例時,系統外部的顧客會先接觸到「登入畫面」(LoginForm)這個邊界物件。然後,登入畫面邊界物件會呼叫「登入流程」(LoginFlow)控制物件,以便執行登入流程。登入流程控制物件在執行登入流程期間,會呼叫「會員」(Member)實體物件,以便驗證會員代號和密碼。會員的身分驗證通過之後,登入流程控制物件會產生一個名為「歡迎頁面」(WelcomePage)的邊界物件,用以顯示一小段歡迎詞。
圖3:登入會員
圖4:穩健圖
對於UML初學者,很可能對圖1中的三種物件感到陌生。不過,熟知UML演進歷史,或者熟知使用案例創始人Ivar Jacobson先生著作的讀友們,應該對邊界物件、控制物件和實體物件感到十分熟悉。因為,早在1992年,使用案例創始人Ivar Jacobson先生出版的《Object-Oriented Software Engineering:A Use Case Driven Approach》一書中,便已經提出這三種物件來建構分析模式的技術了。
不過,當時「邊界物件」不是這個名稱,而是稱為「介面物件」(interface object),為了避免與元件技術中的「介面」(interface)概念混在一起,所以才更名為邊界物件,但是概念和圖示倒是都沒有改變。此外,實體物件的圖示有變動,原先只有圓形,後來才在圓形底下加了一橫槓。新舊版名稱與圖示相比較,如圖5所示。
圖5:新舊版圖示與名稱
雖然,在新版的UML2中,並沒有正式收錄這三種物件,不過在許多的UML工具或者UML書籍中,倒是都有支援這項概念。比方StarUML這套著名的免費UML工具,就有支援穩健圖。
圖6:StarUML
在ICONIX方法中,原著作者用穩健圖來表達動態觀點,同時也拿它來做為使用案例模式與循序圖之間的銜接橋樑,如圖7所示。
圖7:穩健圖
實務上,使用案例模式與循序圖之間,確實有很大的鴻溝。很多UML/OOAD專案從使用案例技術入手,看似入門容易,專案成員不需要花太多時間或費用學習物件導向思維,卻產生另一個後遺症——建完使用案例模式之後,不知如何繪製類別圖和循序圖。
還記得我曾提到過,真實的開發流程其實比較貼近循環星形法,但是對於UML初學者而言,經常會感到無法順暢地,從使用案例敘述移動到類別圖和循序圖處,如圖8所示。也因此,原著作者在ICONX方法中,試圖引進穩健圖的技術,來改善這段開發流程的順暢度。
我推想造成這個鴻溝的主因,很可能是物件導向的思維不夠熟捻,導致建構出來的使用案例圖,和撰寫出來的使用案例敘述,都不夠物件化,也就因此到了要移動到純物件化的類別圖和循序圖設計時,會覺得力有未逮。
一旦採用了穩健分析之後,可以迫使系統分析師在繪製穩健圖時,重新檢視使用案例敘述,同時加入更多的物件思維,也因此可以更順暢地移動到純物件化的類別圖與循序圖設計上頭。
圖8:使用案例模式與類別圖及循序圖之間的鴻溝
分析癱瘓警訊
此處我們將繼續討論十五條分析癱瘓警訊中,編號8和編號9這兩條跟穩健圖有關的警訊。
分析癱瘓警訊8別試著用穩健圖進行細部設計。(Don't try to do detailed design on robustness diagrams.)
分析癱瘓警訊9別浪費時間,想把穩健圖做得盡善盡美。(Don't waste time perfecting your robustness diagrams as your design evolves.)
在ICONIX方法中,原著作者將穩健圖定位在銜接使用案例模式和循序圖,它只是個手段而非目的,真正的目的是產出循序圖,而非產出穩健圖。再者,穩健圖本身也不適合呈現設計細節,至少相較於循序圖,循序圖確實比較能夠呈現細膩的設計。
或許正因如此,原著作者才會列出這兩條分析癱瘓警訊,提醒系統分析師善用穩健圖但不濫用,千萬記得它是讓整個開發流程得以從使用案例分析順暢推進到循序圖設計的催化劑,不需要浪費時間把穩健圖做得細緻又完善。穩健分析的十大好處
由於,穩健分析不是UML2標準的一部分,所以使用者比較少。難得原著作者使用穩健分析多年,所以很值得看看在他的實務經驗中,穩健分析可以帶給開發人員什麼樣的好處。
好處1在撰寫使用案例時,穩健分析可以迫使你使用一致的風格。(It forces you to write your use cases using a consistent style.)
好處2在撰寫使用案例時,穩健分析可以迫使你使用正確的口吻。(It forces you to write your use cases in the correct voice.)
使用案例敘述不是UML2標準的一部分,所以沒有標準的寫法,自由度高,正因如此,所以它容易上手,但一體兩面的是,它也容易流於風格不一、物件化不足,所以難以銜接後續的類別圖與循序圖。
由於,穩健圖採用了邊界物件、控制物件和實體物件的三物件觀點,而且還定義了三種物件之間的溝通規則。所以,一旦套用了穩健分析的技術之後,便可以優化使用案例敘述,不僅添加了物件導向思維,同時也強化了使用案例敘述風格的一致性。
至於,邊界物件、控制物件和實體物件之間的溝通規則為何,我將在好處4中為你說明。
好處3 針對每個使用案例,穩健分析可以提供合理且完整的檢驗。(It provides sanity and completeness checks for the use cases.)
穩健分析主要提供四項功能,如下:
1. 合理性檢驗—在為使用案例繪製穩健圖時,由於加入了物件觀點,所以可以檢驗出這個使用案例敘述是否合理、是否可行。
2. 完整性檢驗—在為使用案例繪製穩健圖時,由於需要再一次重新檢視使用案例敘述,因此可以發現之前遺漏的替代流程。
3. 持續發現物件—在為使用案例繪製穩健圖時,很可能會發現有些事項沒有物件負責,因此發現了新的物件。在這種情況下,可以將新發現的物件回饋到領域類別圖中,讓領域類別圖在穩健分析的階段仍然可以持續更新。同時,如果遇到使用案例敘述中的物件名稱,與領域類別圖中的類別名稱,兩者有不一致的情況,也可以於此時同步更新。
4. 初步設計—穩健圖內的物件,以及物件之間的連結,都可以對應到循序圖內的物件。所以,可以說,在繪製穩健圖時,其實也就是在進行循序圖的初步設計了。
由上述可以發現,系統分析師在進行穩健分析的過程中,將重新檢驗並同步更新使用案例模式和領域模式。原著作者甚至認為,針對每一個使用案例和穩健圖必須同時通過下列三項檢驗步驟,否則不能算是完成了使用案例敘述及穩健圖,檢驗步驟條列如下:
1.加入物件觀點之後,重新閱讀並更新使用案例敘述中的主要流程與替代流程。
2.確認主要流程與替代流程中所涉及的物件,以及物件之間的連結,都有出現在穩健圖中。
3.使用案例敘述與穩健圖之間要有清晰的對應。
好處4 穩健分析可以讓你將語法規則套用在使用案例上頭,像是「參與者只能夠與邊界物件溝通」之類的。(It allows you apply syntax rules (for instance, "Actors talk only to boundary objects") to your use cases.)
穩健圖內的三種物件與參與者,四者之間的溝通規則一共有九條,四可五不可。請看圖9,穩健圖允許的四條溝通規則,條列如下:
1.參與者與邊界物件兩方可以互動。
2.邊界物件與控制物件兩方可以互動。
3.不同的控制物件之間可以互動。
4.控制物件與實體物件兩方可以互動。
圖9:四條允許的溝通規則
再看到圖10,穩健圖不允許的五條溝通規則,條列如下:
1.參與者與控制物件兩方不可以互動。
2.參與者與實體物件兩方不可以互動。
3.不同的邊界物件之間不可以互動。
4.邊界物件與實體物件兩方不可以互動。
5.不同的實體物件之間不可以互動。
圖10:五條不允許的溝通規則
好處5 穩健圖比循序圖更好畫,而且也更容易閱讀。(Robustness diagrams are quicker to draw and easier to read than sequence diagrams.)
穩健圖是否比循序圖更好畫,見仁見智,況且現在都用UML工具來製圖,所以有沒有更好畫,其實也無妨吧。
至於,穩健圖是不是比循序圖更容易閱讀,這也很難說,因為循序圖涵蓋的資訊量較多,當然閱讀上就會比較吃力。再者,如果穩健圖包含較多的物件時,其實也不好判讀,況且穩健圖採用網狀的陳列方式,一旦複雜起來,恐怕會比循序圖的柵欄狀的陳列方式,更難以閱讀吧!
好處6 穩健分析能夠協助你依據MVC思維來分解物件。(It helps you partition objects within a Model-View-Controller paradigm.)
著名的MVC(Model-View-Controller)概念普遍應用在許多設計上,它將物件分為三類,分別為:模式物件(Model)、視圖物件(View)和控制器物件(Controller)。比方說,應用領域裡重要的資料,就可以對應成模式物件。再者,使用者接觸到的螢幕畫面或是網頁,都是常見的視圖物件。
至於,控制器物件則通常位於視圖物件及模式物件之間,用以溝通兩者。控制器物件可以切開視圖物件與模式物件之間的連動性,讓模式物件可以同時支援多種不同的視圖物件。
在MVC之前的設計,通常不分職責地將所有的事情設計在一塊,物件又要處理畫面設計,又要去資料庫撈資料,還要做運算。這樣的設計造成很多問題。比方說,物件負責的事情太多,太過複雜是無法避免的,不僅難以開發,更是難以維護。領域裡面的專業規則分散在各個物件裡,無法集中管理,日後當然不易維護。再者,物件變動頻率提升,畫面變動、流程變動、資料或規則變動,通通都會影響到同一個物件。更別說重用(reuse)了,無法切成小塊,根本無法讓其它設計重用。
採用MVC的設計之後,每個物件的工作單純化了。擅長設計畫面的開發人員就專門設計視圖物件,擅長設計領域資料與規則的開發人員專門設計共用的模式物件。而且,還可以平行開發視圖物件和模式物件,再設計控制器物件來結合兩者即可。
如此一來,變動也會被封裝在某種物件裡,不再會有牽一髮而動全身的情況。比方說,使用者嫌畫面太單調,想要換個畫面,只需要換掉視圖物件,其餘物件不受影響。領域裡的專業規則改變了,如薪資的計算公式改了,只需要更新模式物件即可。如果是流程的變動,也只需要更新控制器物件,不影響其餘物件。
其實,邊界物件的概念繼承自視圖物件,控制物件的概念繼承自控制器物件,實體物件的概念則繼承自模式物件。因此,採用了穩健圖,其實也就採用了MVC思維了。
好處7對於主從系統,穩健分析能夠協助你依照「畫面—邏輯—儲庫」框架來將物件分層。(It helps you layer objects in a GUI-Logic-Repository framework for client/server systems.)
如果,我們將MVC概念擴大應用在系統中,便形成了「畫面—邏輯—儲庫」(GUI-Logic-Repository)三層式架構的基礎概念。簡言之,把系統也分為MVC三層:視圖層(畫面)的系統負責提供高親和力的人機介面,模式層(Repository)的系統專門維護領域的專業知識,控制器層(邏輯)的系統負責居中指揮並協調其它兩層。由於,每一層系統裡的物件也是採用MVC概念,所以由外到內、由大到小皆採用MVC概念,形成風格一致的系統設計。
比方說,一個線上購物的系統,就很適合套用MVC三層式架構,如圖11所示。會員透過瀏覽器連上購物網站,下載購物網頁。所以,購物網站是個視圖層的系統,專門負責提供人機介面。當會員選定了商品並進行結帳時,購物網站會傳遞訂購訊息給控制中心。控制中心是個控制器層的系統,負責協調視圖層與模式層的系統。接著,控制中心會調用模式層的系統,執行訂購流程,並且取得訂單號碼回傳給購物網站。最後,購物網站會負責將訂單編號放到網頁裡,並且回傳到會員的瀏覽器上。
圖11:畫面─邏輯─儲庫
好處8在開始進入設計階段之前,穩健分析讓你可以橫跨所有使用案例,查看是否有可以重用的地方。(It allows a reuse pass across all your use cases before you begin design.)
在進行穩健分析的過程中,能夠重新檢視所有的使用案例,發現跨使用案例的物件,並且將這些新發現的物件加到類別圖中。仔細看到圖12,在繪製穩健圖的時候,會同步更新類別圖,隨後才會真正進入設計階段。
圖12:穩健圖
好處9穩健分析提供概念性的物件觀點,讓我們可以追蹤系統服務(使用案例)與系統運作(循序圖)之間的關係。(It provides traceability between what the system does (use cases) and how the system works (sequence diagrams), using a conceptual object view.)
好處10穩健分析填補了分析(使用案例)與設計(循序圖)之間的語意間隙。(It plugs the semantic gap between analysis (use cases) and design (sequence diagram).)
總結來說,由於穩健圖處於使用案例與循序圖之間,所以不僅能夠連結兩者,同時還能夠填補兩者之間的間隙。
熱門新聞
2024-11-29
2024-12-02
2024-11-30
2024-12-02
2024-11-29