【iThome 連載單元—2】界定清晰的系統範圍與責任–以土地公廟的系統分析為例

前言

e化的軟體系統開發,已不再如傳統 MIS 的資訊系統開發模式,經常是假設所開發的系統是單一,系統全是由自己從頭到尾所負責來實做完成的。如今 e化系統的開發,更會面臨多個應用系統的整合,團隊內部,可能只是承包實做某整合系統的一小塊範圍,但又需要整合其它的應用系統,在這樣的情況下,團隊必須對所承包的系統,有明確清晰的範圍,才有可能釐清系統所該擔負的責任,以及是如何與其它系統的訊息溝通。

筆者擔任架構師在輔導整合開發專案時,經常會利用 “使用案例圖(Use Case Diagram)” 來界定系統開發的範圍(System Boundary)。明確界定範圍之後,好處多多,可以讓團隊的內部成員能對系統全貌有一致性的認知,也能據此找出使用該系統的參與者(Actor),以及參與者使用該系統的目的(Goal),同時也能區分出系統的 “內” 與 “外”,這可是非常重要,如此才能知道什麼是該作、什麼不需要作。

所謂的 “外”,即代表從系統的外部觀點來看待系統,是從使用者的角度(View)來看待與應用系統之間的互動,又不致干涉到系統實作(how-to)的內部,所專注的僅是在於與系統溝通時訊息(Message)的“進(Request)”與“出(Response)”,也就是從使用者的角度來看時,應用系統是一個 “黑箱(Black-box)”。所以外部觀點,就是表達了系統的需求面,在需求分析階段,分析師要能捕捉(capture)到使用者對系統的期待或想法,也就是要能取得使用者的需求,是相當重要的工作。而使用案例,便是一種極佳的工具,可以容易正確地來捕捉到使用者的需求,又不致陷入於實作的細節內,造成分析癱瘓(analysis paralysis)。

至於 “內”,代表著就是系統內部的結構(Structure),而所謂的結構,必然是由系統內部的靜態(static)元素所組成,從問題領域(Problem)的觀點來看,這些元素係源自於該領域的概念術語,稱為實體(Entity),每一個實體均有所需儲存的資訊,以及應盡的責任,例如 “訂購(Order)”,就是在訂購系統中,非常重要的一個實體,它儲存了訂購相關的資訊,以及必須負擔 “計算訂購總額” 的責任。其實呢,系統分析的工作,目的就在於:如何找出這些 “元素(或稱之實體)”,並賦予每一個元素的責任,這稱之為 “責任分派(Responsibility assign)”,然後系統分析/設計師動態組合這些元素,配合實體平台的服務元件,來滿足系統外部的功能需求。也就是說,靜態面的結構元素,與功能面的行為(Behavior)描述,均是屬於系統分析師的範疇。幾個主要的產出,包括類別(Class)圖、循序(Sequence)圖、資料庫的 E-R(Entity-Relationship)圖,是屬於系統分析/設計師(SA/SD)所該負責的的範疇。

筆者以一個比較淺顯又接近現實生活面的例子,來說明如何利用使用案例圖界定系統範圍,以釐清系統與其內部元素的責任。同時並利用 UML 循序圖,表達系統內部元素之間是如何動態合作,來完成系統的功能需求(使用案例)。

土地公廟的許願–利用使用案例圖界定系統範圍

每次看到使用案例的橢圓形與使用案例所要凸顯的目的,就聯想到,使用案例就如同去道教的廟宇,向神明祈求,並在心裡許願,以求得平安、健康、財富與愛情...等等各種願望。道教的神明,各據地方的廟祀,各司其掌,保佑地方眾生的平安。

使用案例與崇信道教的信眾至廟宇許願,有許多相似之處,例如:

  • 眾神明所居住的廟宇,就如同寫使用案例時,需界定系統範圍。 廟宇=系統。
  • 信徒向神明許願,信徒就是使用系統(廟宇)的參與者(Actor),而所許的願就是使用案例(Use Case)。
  • 許願後還願,是一種契約(Contract),契約就是一種交易(Transaction)。道教是崇尚交易的信仰,向神明許願,若神明滿足信徒的願望,信徒是要還願的;這就如同系統能滿足參與者使用系統的目的(Goal),那麼,每一個所滿足的使用案例就是一個交易,每一個交易是要向客戶計價收費的。
  • 信徒向神明許願,不需要瞭解神明是如何能達成信徒的願望,最終只要能完成你所許的願即可;這如同參與者使用系統的使用案例,不需要瞭解系統是如何(How-to)完成參與者的使用案例,只要能滿足其目的(Goal)即可。

舉個例子,來說明如何利用使用案例 “塑模(Modeling)” 信徒的許願,一段簡單的文字敘述如下:
「兩個信徒,到烘爐地福德宮土地公廟許願。其中信男許的願是 “求得大樂透明牌”;信女許的願是 “求得子息”。」

初期的系統分析,界定系統是 “南山福德宮(烘爐地土地公廟)”,參與者有兩個:一個是 “信男”,另一個是 “信女”;使用案例是 “求得大樂透明牌” 與 “求得子息”,參考下圖1。

南山福德宮廟使用案例圖
圖1、南山福德宮廟使用案例圖

土地公如同人間的里長一般,是屬於地方的行政官員,職司庇佑地方升斗小民包括求財、出外、入厝、動土、農作物的收成、家畜的繁衍...等,但是卻非執掌婦女的生育,這應該是註生娘娘的職掌才對呢。怎麼辦?既然信女都向土地公求子生育了...。

經過玉皇大帝左右手三官大帝(其角色如同系統分析人員)的作業協調與分派,確定求得子息的願望需交由註生娘娘才能完成其目的。但總不能直接在土地公廟拒絕該信女的願望吧?所以,其未來生得子息的實現會轉由註生娘娘來負責的。註生娘娘也是系統,但是祂並不屬於土地公廟的管轄,所以是屬於外部的系統,也就是土地公廟的 “支援性參與者(Supporting Actor)”。

第二次的使用案例系統分析如下圖2。

南山福德宮廟使用案例圖(新增註生娘娘的外部參與者)
圖2、南山福德宮廟使用案例圖(新增註生娘娘的外部參與者)

信男與信女都不需要知道土地公是如何(How-to)達成他們的願意,最終就是只要能滿足其願望即可。所以,信女也根本不需要知道 “求得子息” 的實際工作是由土地公轉派交付給註生娘娘來實現(Realize)的。

若是想知道系統是 “如何” 實現其願望,那麼,就勢必要 “打開” 土地公廟的系統,探究其內部是由哪些人員來協調、互動與合作,以完成信徒們所交付的願望。

實現信眾們的許願–系統內部的結構分析與分派責任

找出工作人員、分派工作人員的職掌,就如同系統分析中的找出元素、分派元素的責任(Responsibility assign),這是屬於系統內部的結構分析與設計(Structure Analysis/Design)範疇。

我們可以利用循序圖(Sequence Diagram),來表達系統內部中,有哪些元素會參與完成一個使用案例。循序圖內,就是明確地表達參與使用案例的元素彼此之間的協調與合作。

每天有那麼多信眾來許願,土地公可無法一人就可以獨立來完成所有信眾們的願望,這樣責任太重了,萬一土地公要休假或是生病了怎麼辦? 所以土地公顯然會分派責任給祂下轄的隨從們,協調、互動與合作來實現(Realize)其願望(使用案例)。

若信眾們會把他們的許願寫在籤紙上,並請廟公轉交給神明,那麼,廟公就是擔任著窗口的角色(Façade),當然,也有可能信眾們是直接在心中許願,藉由心意傳達給土地公,那麼,土地公就是擔任窗口(Facade)的角色,同時,祂也是控制者(Controller),當接收到信眾們的許願訊息(Message)後,土地公將該訊息交付給文隨從,而文隨從又將訊息輸入至祂的樂透邏輯演算機,來取得明牌號碼 (至於準不準,那是另外一回事了;) )。內部物件之間的合作,我們可以利用 UML 循序圖(Sequence Diagram)來表達,如下圖3。

求得大樂透明牌的循序圖
(縮略圖,點擊圖片鏈接看原圖)圖3、求得樂透明牌的循序圖

又,土地公接到信女 “求得子息” 的許願,因執掌生育是屬於註生娘娘的司掌的範疇,所以土地公派祂的坐騎 “虎爺”,將該訊息送到註生娘娘那,以實現其願望。

“虎爺” 負責對外界神明的聯絡,所以祂是屬於 “邊界(Boundary)” 的角色,也可說是屬於 ”調變器(Adapter)” 的角色,參考下圖4的循序圖。

求得子息的循序圖
圖4、求得子息的循序圖

結論

界定系統範圍,找出使用該系統的參與者,並記錄參與者使用該系統的目的。若為完成該參與者的目的,而經分析後,確認為了要完成該目的,需要外部系統的協助,自然,就需要傳遞訊息給外部的系統。請記得,系統與外部系統的溝通,是透過 “訊息(Message)” 來溝通,在實做面的層次上,也就是透過 “介面(Interface)” 的呼叫。

筆者以為,系統分析與設計是一件饒富於創意又有趣的工作,從以上的案例,可以發現到,系統分析人員,要能在心中 “想像” 軟體應用系統的內部,是由一群有生命的 “個體(Instance)” 所共同協力互助,來完成一件件由系統所交付的任務(也就是需求)。系統分析者,就有如電影導演的角色,依據劇作家撰寫的劇本(Scenario),安排與賦予每一個演員(Actor)的角色與責任。有了演員們之間的互動、共同合作,才得以完成一齣齣的戲。

文章導覽

   

共有 7 則迴響

  1. Hello 123:

    從信男的角度,完全不需要知道是否有支援性參與者,那是土地公廟(系統)內部的事情,與信男是無關的。

    循序圖是表達了系統內部要完成某一項工作(求明牌)時,”誰” 會來參與該工作的分配與執掌。

  2. 信男是否要有財神或橫財神的支援性參與者呢???

    多謝您的循序圖使我收獲不少^^

  3. Hello Joshua:

    請記得一件事,資料庫是在各個應用系統下的 “私有” 倉儲。

    為何無法直接變動 Table? 這是設計者沒有分清楚 Logical and Physical 的設計。

    為何 Hibernate 是透過 XML 來 “mapping” 資料庫的 Table? 這也是封裝的一種運用,如此而已。

  4. hello
    克明兄,请教一下关于你说的主机板模式
    用 进销存 模组举例
    进销 一般都会直接异动 库存 的table
    如果这样子的话,换用别家的库存模组的话,可否达成模组替换呢?
    主机板模式又如何处理这个问题呢?

  5. Hi 賢智:
    謝謝您的稱讚。
    不過,這個案例不僅僅是 “概念性的架構” 喔,我早已同時寫出 Java and C#.NET 程式碼,並且與 Model 檔同步,用來教授學員的。 ^^

    Hi CGS:
    謝謝,不過,不是要先懂 UML,UML 後懂都沒關係,但要能有軟體設計的思維在心中。

  6. 克明,看得出你的用心耕耘,這個概念性的架構,讓你說得很明白。只可惜用文字去描述案例的內容,總沒有你口述的精彩。畢竟文字總有使用上的極限。我離開這個領域太久了,要不然會很想去聽你的課。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *