寫好使用案例 (Use Case)有什麼好處?

上個月我在「工研院」授課時,其中一位較為資深的程式開發人員問的問題: 我感覺不到寫好使用案例 (Use Case) 有什麼好處?

別誤會,這位年輕的開發人員並沒有惡意,我也認識他一陣子了。他的確是有感而發,覺得在工作上,從以前透過一般的需求規格書,到現在開發時導入 使用案例 的分析需求技術,但是,他並沒有感受到因為這樣而有加快程式撰寫的速度,反而還覺得縛手綁腳,經常需要受到規範。

這個問題,可比想像得還難以回答。 是為了可以有效保存需求分析的資產? 還是為了系統的彈性 (flexibility)? 前者似乎有道理,但如此對現在正進行的開發專案好像沒有說服力,甚至開發人員還覺得為了要補足這些需求文件,反而拖累了開發的速度;後者的系統彈性問題,我則是很確定與寫得好需求分析文件沒什麼直接的關係,彈性度的考量,與軟體的結構設計 (structure desgin)才是更主要的關鍵。

思考許久,我是以為,寫的好使用案例最直接的關鍵是: 影響到專案開發整個流程的節奏!

以使用案例為導向 (use case driven)的開發模式,我的體會是越來越能感受到那個所謂的 "driven" 這個字眼。 短線專案的特性,幾乎是偏以需求為優先。而使用案例的分析,其本質上仍是屬於功能 (functional)性的分析。只是有別於模組化的功能樹分析模式,後者的功能模組,耦合性 (coupling) 太重,容易牽一髮而動全身,所以在需求分析階段,會耗費許多時間在分析共用模組的考量;而使用案例,是一種目標導向 (goal-oriented)的功能分析方式。 每一個使用案例,都可以看待成是系統在某一段期間 (session),可以滿足使用者使用系統的目的。 所以每一個使用案例,是可以個別被獨立開發,也就是說,UC-A 與 UC-B 甚至可以交付給不同團隊並行開發。而至於兩者若有共用性的議題的考量,則是延宕到結構設計階段再來討論即可。因為在需求分析階段,不用花太多時間在共用議題的考量上,所以可以很快速地實現 (realize)功能需求。

能抓得好與定義得好一個一個的橢圓使用案例,就能以該使用案例為開發單位。 這麼說好了,甚至可以把該使用案例就當成是一個迷你系統,然後來串連出整個開發的程序與產出。 例如,針對一個使用案例,就會設計一個位於中間層 (middleware)的控制型物件 (control object),並從使用案例的敘述 (use case description)中,找出該物件應承擔的行為 (behavior),然後再轉化成更詳細規格、程式語言的方法 (method)。 定義好控制物件與其應有的行為,就可以知道需求分析是容易並可以無縫式地轉移到實做階段,並快速地界定出程式碼的骨架 (sketletion),再來就是補足細節、實做邏輯、連結資料庫或外部系統 等等…。

閱讀全文 »

關於庫存管理以 “Boundle(綑)” 為單位的結構設計

上星期參觀「東和鋼鐵」的煉鋼生產過程,收穫頗多。 除了感受到現場工作人員需要忍受酷熱危險的工作環境,而仍是那麼地辛勤工作,不禁敬佩與慚愧,應要能更珍惜自身的工作;另外一個收獲就是,總算看到了我們對「東鋼」設計企業物件類別圖時,一些概念術語中,關於到 "物 (Item)" 的實體呈現。

像在現場上我們就看到以 "捆 (Boundle)" 為單位的鋼材。 可能像長條形的凹型鋼是以三根為一捆,在入庫/出庫(出貨) 時就是以一捆一捆為單位來管理。 在庫存管理時,每一捆都會給一個序號 (serial number),但一根一根的鋼材並不需要為其作追蹤管理,所以並不需要給予編號;若某一捆的某一根鋼材有瑕疵,就是換掉再綁入該捆即可;每一捆的鋼材規格可能會不一樣,可能有 "凹型鋼"、"馬蹄鋼"、"T型鋼" (想像的規格) 等。

所以當時看到已綁成捆的鋼材,我問 Ringle 說 "捆 (Boundle)" 應該是屬於 "特定項目 (Specific Item)" 吧? Ringle 說沒錯,而且在類別設計時,並不需設計一個 "鋼材" 的 特定項目 類別。 所以有趣的一個問題是,當看到一捆有三根鋼材,若共有三捆時要入庫,在庫存管理系統內,會有幾個物件? 答案可不是 3x3=9 個 instances (個體),而是只有三個 instances,而所屬類別就是 "Boundle"。

"Boundle" 的規格 (Specification)資訊紀錄在哪裡呢? 此時自然會有一種 "產品 (Product)" 類型的類別被挖掘出來。 在庫存系統中,會有個 "成品" 的類別被設計出來,並紀錄著各種鋼材等項目的規格資訊。

每一次的出庫、入庫都需要記錄相關的資訊,所以會設計 "入庫"、"出庫" 兩種類別。 而這類型的物件就是所謂以交易為核心 "Transcation Pattern (交易樣式)" 中的交易物件。

再來,若要查詢現在庫存的數量,該找誰問呢? 此時就會有個 "庫存 (Inventory)" 的類別來擔負 "查詢庫存數量" 的責任。 有意思的是,"庫存" 類別在古早以人工來紀錄的時代以來,就是等同於 "帳冊" 的角色,而這在我的認知算是在電腦系統內 "Log" 類型 這樣的一種角色。 不過 Ringle 倒是很肯定的告訴我,是 "Log" 沒錯,而在 "Transaction Pattern" 中,這仍是屬於 "Specific Item" 的類型。

基本上,一個以鋼材物料的庫存系統主要組成結構元素的輪廓就慢慢浮現出來了,先略過 "人 (Role)", "地 (Place)" 的類別設計,一個基本的 UML 概念類別圖 (Conceptual Class Diagram)如下圖:

庫存系統的概念類別圖
圖、庫存系統的概念類別圖

閱讀全文 »

「UML 協同團隊合作開發」問題與內容勘誤回覆

讀者 Pogi 很細心地在 「Ringle 即將出版的新書─ UML 協同團隊合作開發」一文中,提出他對閱讀了該書之後所發現的問題。 在此我也特請原作者 Ringle 在此針對所提的問題作回覆。

請問有提供勘誤表回饋網址或mail嗎?

  • 43頁:
    一般化關係:是不是應該說明一般、特殊化關係的方向性?
    整體-局部關係:聚合跟組合的圖看起來都是實心的。
  • 44頁:
    相依性關係:圖示錯了。
  • 45頁:
    圖3-2的內容跟前面訪談結果不一致,特助有說跟住院事件相關的人員:醫生、護士、櫃台人員,但是類別圖卻沒有櫃台人員。

Ringle 的回覆如下:

謝謝你那麼仔細地看這本書,有關您所問的問題,分別說明如下:

  1. 43頁:
    一般化關係:是不是應該說明一般、特殊化關係的方向性?
    照您所說的,我會在下一版中加入一個說明:「病床」類別是「非健保病床」與「健保病床」類別的一般化。
    另,聚合的部分應該為實心,這是在校稿時忽略掉了。
  2. 相依關係的部分也是一樣的。這幾個部分,主要是由於書籍的美編重新改過了原來的稿子所造成的,不過我在校稿時也沒有發現,謝謝你的指正。
  3. 有關類別圖與訪談結果並沒有不一致。「櫃臺人員」主要是屬於「Actor」的性質,並不屬於類別圖中所需關心的問題。
    對於特助來說,他並非軟體設計人員,因此,他只是忠實地說明他所看到的現象,但設計人員應該要針對他的回答加以思考並過濾,而非全盤接收。

從 Google 書籤看標籤與資料夾的設計觀 ─ 設計篇

如果我是某大軟體公司的主管,要應徵軟體結構性的設計人員 (偏對技術性,而非需求分析),一般的職稱是稱之為 系統設計師 (SD, System Designer),或者號稱為架構師 (Architect)、資深技術人員等。 若他們在履歷表上寫著擅長或懂 "O-O (Object Oriented)" 或 "UML"、結構設計 等,那麼,我不會考他們什麼 UML 語法還是 設計樣式 (Design Pattern) 等等。 那只是 "背書" 而已,一點意義都沒有。 要背書的話,不如直接給個電腦上網,然後要應徵人員展現如何透過 Google 查詢找到如何實做設計樣式的方法還比較實在。

我會提供的考題,必然是針對應徵人員 "自我思考推理" 的能力驗證,答案的正確性完全不重要,重要的是你為什麼是這樣表達設計的,能否自圓其說。 具有獨立思考能力的設計師,這才是人才!

所以,我會提供一個如這樣的考題:

Google 書籤 (bookmark)是利用 標籤 (Tag)來作分類的。 一個書籤可以被 "標記" 為一到多個標籤,相對來說,一個標籤可以有一到多個書籤。 另外,標籤是不會含有子標籤 (Sub-Tag) 的。

如果我要改良 Google 書籤的設計,希望能再加上 "資料夾 (folder)" 的管理觀念,也就是說書籤必然會 "放" 在某一個資料夾目錄內 (也只能是唯一),而某一個資料夾可以擁有一到多個書籤,同時資料夾也能再包含子資料夾 (Sub-folder)。

同樣類似的應用,可以延伸至部落格 (Blog)的本文 (Content)與標籤、目錄 (category)的結構設計。

請你利用 UML 類別圖,來表達出關於 書籤、標籤與資料夾的結構關係,並簡單說明你的設計想法。

上述的考題是一個 "需求陳述",應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述,那麼也可以再佐以範例,來解釋什麼是 書籤、標籤與資料夾的概念。

老實說,我是以為,這類的結構設計應該算是很基礎的了,事實上,答案也比想像得意外簡單。 但是,我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員,最直接給我的答案就是說: 這不就是 "複合結構 (composite structure)" 樣式的應用嗎? 不管你說什麼,反正先把設計圖畫出來再說吧。 結果呢,也真的如我所料,表達不出所以然,真的就只是在背書而已。 最大的盲點,就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起,而其實這兩個是一點關係都沒有的;甚至有些還執著在因為 標籤與書籤 的多對多關係,所以又拉出了一個所謂的 "關聯類別 (Association Class)",卻又說不所以然,越弄越複雜。 因為既然是表達想法,所以類別圖自然是表達 概念 (concept)與概念之間 的關係,而至於那個多對多的關聯類別,是在更細節性的規格設計實做階段再來討論即可,太早論及,反而模糊了要突顯的概念。

表達這類結構性的設計圖,要先找出核心的類別是什麼。 在本例中, "書籤 (bookmark)" 即為本文主體,是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連,而是各自與 書籤 建立關係,那麼,這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖:
閱讀全文 »

從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇

我使用 Google 書籤已有一年多餘的時間了,並非是為了好用,而是為了 "可攜性"。 因為我有多臺電腦,而且也常在外面透過筆電或 Vm 上網,也常切換 IE or Firefox Browser,書籤的管理,就變得是一個問題了。 而使用過眾多的書籤管理同步工具,仍是覺得相當麻煩,所以還是回歸到使用最簡單,Google 所提供的書籤管理機制,只要上網登入 Google 帳戶後,就可以存取網路上的書籤,相當便利。

先看看我的書籤是如何規劃的吧,參考下圖。

圖 . Google 書籤的管理規劃-01
(點擊圖片鏈接看原圖)圖 . Google 書籤的管理規劃-01

先瞭解一件事, Goodle 書籤的管理,是沿用 Google 平台傳統的機制,就是利用 TAG (標籤)來組織分類。 Gmail 是如此, Bookmark 也是如此。

所以,我若要 Bookmark 某個遊戲網站的書籤,TAG 大概就是標記如 "Game" 名稱之類的。 那麼當遊戲類的書籤一多的時候,又該如何管理呢? 舉個例,我光是當時玩「魔獸世界」時,保存相關的書籤就有近百個之多,所以你可以同時標記的 TAG 可以有 "Game", "魔獸世界" 兩個;而若是圍棋的書籤則可以標記 "Gmae", "圍棋" 兩個。 當標記的 TAG 越來越多時,你會發現到標籤的顯示會相當凌亂。 若你希望某個書籤雖然是標記成多個 "TAG",但又希望這些 TAG 的顯示有些關聯性,那麼,就可以如我上圖這樣的規劃一般,就是把 TAG 標記為 "Game", "Game_圍棋", "Game_魔獸世界" 這般,這樣的話在書籤的顯示上就能有循序性的列表了。

閱讀全文 »

「UML 團隊開發流程與管理」新書正式出版(6/12)

Ringle 的新書:「UML 團隊開發流程與管理」確定於 6/12 由「悅知文化」正式出版。 現在有活動優惠,在 6/12 前預購均享有 7 折優惠。

UML團隊開發流程與管理 UML團隊開發流程與管理
-----------------------------------
作者: 賴信仁
出版社:悅知文化
ISBN:978-986-6761-90-4

本書特色:
這是一本將理論與實務作完美結合的書。以案例分析的方式,告訴讀者如何透過UML正確表達軟體設計的精神,同時搭配工具軟體與Lab單元,讓讀者可以從做中學,在練習的過程中,確實瞭解軟體開發的過程。

內容簡介:
對於軟體設計的初學者來說,面對大量的資訊,往往不知從何處開始下手。本書係根據作者多年的授課經驗寫作而成,特別針對有以下需求的讀者,提供學習的指引:

■ 想要瞭解UML及其應用時機的讀者:
本書第一部份,設計了一個完整的案例,並且將UML的十三張圖應用在該案例中,利用Q&A的方式,深入淺出地說明UML 13張圖的基本精神及其應用,讓剛開始接觸UML的讀者可以透過實際案例瞭解UML。

■ 想要知道如何在實際專案中應用UML的讀者:
本書的第二部分,設計了另一個完整的案例,並搭配工具軟體,配合UML、MDA以及實際的程式碼,讓進階的讀者可以瞭解,應該如何在實際的專案中應用UML。而且在每個章節中,都提供LAB練習,讓讀者可以「從做中學」。

■ 想要知道軟體開發團隊如何合作的讀者:
本書的第三部分,作者設計了一個團隊合作的情境,透過一個虛擬專案的進行,讓讀者可以瞭解團隊中的各個角色,以及如何挑選適合的工具來幫助自己完成工作,以及如何善用工具,讓團隊合作能夠更簡單、更順利。

■ 想瞭解Enterprise Architect如何使用:
Enterprise Architect是一套完整的UML支援工具,完整支援UML 2.1的13張圖形,並且Support多種程式語言及資料庫,且提供了非常多的客製化空間。本書主要使用該套工具進行實作,並介紹該軟體的操作及客製化技巧。

「UML 團隊開發流程與管理」新書封面完稿
(點擊圖片鏈接看原圖)「UML 團隊開發流程與管理」新書封面完稿

※ 延伸參考:
o 「UML 協同開發管理」新書序言 Preview
o Ringle 即將出版的新書─「UML 協同團隊合作開發」

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal