讀者對使用案例的幾個提問 (針對另文「三論博客來的使用案例分析」)

網友 Thomas,在我個人發表過的一篇文章:「三論「博X來」— 訂購商品與結帳是否是同一個使用案例?」,提問了對使用案例分析的幾個相當不錯的問題與觀點。 老實說,這讓我精神為之振奮起來,已經許久沒有人與我討論使用案例分析的議題了。 我曾提及,使用案例是易學難精,沒有把握基本精要與原則,很難把圖給畫好 (不容易界定出系統範圍),更何況是用純文字來寫出需求陳述。而且,使用案例如同學習圍棋一樣,每一個階段的學習與思考,又能再有著對其本質更深一層的體悟。 相對來說,應用在實務的需求分析上,也會來得更為得心應手。

這裡就 Thomas 所提問的問題,獨立出來另以本文來回覆。 同時也算是對上述該篇文章的補充論述。

您好:
對與你的無私與熱心真的令人佩服
看了你這篇文章感覺上有一個地方有點不解之處,想跟您請教一下
一般來說 使用 Use Case 時最怕受傳統結構化的影響,而將 Use Case 畫成功能分解,但看了你的 Use Case Diagram 的圖,其中訂購商品這個 Use Case 又去 include 查詢商品資訊及放入購物車,坦白講感覺有點像是功能分解的方式,要是我畫這張圖,我可能只會有查詢商品資訊及放入購物車,不會有一個訂購商品這個 Use Case,查詢商品是使用者一進來就會使用的功能,對使用者來講是一個獨立的價值,他就是喜歡逛逛而已,而放入購車又可視為一個獨立的需求,至於訂購商品應該是一個企業流程,這個企業流程包含很多有價值的事情,實在不適合當成一個 Use cASE 反而比較適合成為此 uSE Case 的系統邊界,除非你這張 use case 的層級是在討論企業層級的 use case,而不是在討論 系統層級的 use case
不知您以為我的觀點是否正確
謝謝

關於上述問題的回覆:

  1. 我們要先對使用案例的本質弄清楚。Use Case 確然就是功能分解!! (這點最重要,要先分清楚使用案例的分解方式為何)
  2. 與傳統的模組化功能分解不一樣的是,模組化的功能分解係以功能樹 (functional tree)的方式將大功能分解成小功能,每一個小功能又各自分解更小的功能,直至每一個小功能可以成為一個開發的單位為止。
  3. Use Case 的功能分解,係以目標導向 (Goal-oriented) 的方式,從使用者 (參與者)的角度,在特定的期間 (session) 內,能完成他對系統的操作期望。每一個 Use Case,均可以被視為是一個迷你的系統,是可以被各自獨立來實現 (realize)。
  4. 回至本例,我在圖中係凸顯了系統需滿足使用者兩個主要的功能 (期望),一為訂購商品;另一為結帳商品。 至於為何是分為兩個使用案例,我已在文內有敘述。
  5. 為何我是把主要的 UC 名稱定為「訂購商品」而不是「放入購物車」,原因在於我想凸顯它是 參與者 (Actor) 操作系統的一個重要目的。若用英文命名,會更為恰當。名稱即為 「Place a Order」,如此也比較不至於從字面上引起誤解。 另外,可要注意的是,「訂購商品」正是該資訊系統最重要的交易型使用案例,若把它拿掉,那麼這個資訊系統的價值可就完全不見了。 (其實,我在文內均已有描述這樣的論點,您可以再仔細研讀。)
  6. 「訂購商品」與「訂購業務流程」是兩個完全不同的層次,一個是資訊系統操作層級;另一為業務流程層級。 兩者我其實是各自分開來表達的。前者我利用使用案例圖,後者我是利用業務流程圖的。 可以參考我另外一篇文章:「從企業流程(活動)圖找出資訊系統的使用案例。
  7. 至於為何在圖形上,「訂購商品」會包含 (include) 兩個 Sub-UC (一為查詢商品,另一為放入購物車)? 我在文內其實特別還說明,我是把這兩個 Sub-UC 視為是參與者在「訂購商品」期間內,重要的子程序。
  8. 那麼,「查詢商品」是否可以被視之為另外一個獨立的 Use Case? 答案是 Yes! 但是,可不要把「查詢商品」與在「訂購商品」內所包含的「查詢商品」混在一起。 前述已提,每一個使用案例,是可以被獨立來實現的。 一個獨立的 UC 與另一個被包含的 UC 雖然可能有著相同的程序,但是,在 Use Case 的需求分析階段時,儘量不要去涉及到公用的議題,而是留待到結構分析設計的階段。
  9. 最後,所謂的企業層級的使用案例,與資訊系統層級的使用案例,其實這個就是系統邊界界定的問題了。 幾年前寫過一篇:「從鳥瞰的觀點看 Use Case Diagram」,可以參考之。

【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 C#.NET (11/01, 54 Hrs)

課程相關資訊:
http://www.hsdc.com.tw/course_signup/20081101_sa_sd_to_implement_by_cs_dot_net

【台北場】2008/11/01 起,每週六白天,每次上課為六個小時(AM 9:30~PM 4:30),共九個星期。
o 預定上課日期:11/01, 11/08, 11/15, 11/22, 11/29, 12/06, 12/13, 12/20, 12/27 。

*** 上一期(2008/06/14~08/09) 頗受好評的「系統分析設計與實作」課程完美告一段落,緊接著 HSDc. 團隊預定於 11/01 推出本年度第二期系統分析/設計課程,並且將實作內容部分(上一期為 Java/Spring)改為利用 C#.NET/LINQ Framework 實現,也期能服務利用 .NET 平台開發的軟體人員,能具有完整系統分析、設計至實作的觀念知識與技能。 (本課程均提供免費再次旁聽乙次的機會,所以學員可以一次付費,即可享有同時瞭解兩個平台(.NET/J2EE)的實作產出方式) ***

HSDc. 於 2008 年度推出了完整的系統分析、設計至實作的課程,期能協助軟體開發人員在現實的工作中,能瞭解完整的開發流程與各個角色的工作執掌與產出。在基於以架構為中心來建立團隊具共識的整體觀下,能聚焦在適切開發單位的功能點內,快速地從需求分析導出到實作,找出並克服開發過程中,包括溝通、技能與技術等風險因子。而後基於這樣的框架目標內,得以對系統的結構作重整,卻又不至於影響已有的功能前提下,得以對程式碼施以重構的技巧,讓系統更有延展度與彈性。

傳統系統分析與設計的課程,經常是「昧於現實」,將需求分析/結構設計與程式碼實作拉得太遠,而造成軟體設計與實作的不一致。殊不知,所謂的軟體塑模與程式碼的實作必然是軟體系統的一體兩面,在軟體開發過程中,必然是要保持一致性,所以設計是要作精,而不是籠統的文件報告。關於文件,只是利用工具的文件產出功能,將平時已確實所作的設計,產出美輪美奐的文件報表而已。不要為文件而文件,還去加班熬夜,傷了身體,又浪費生命在不必要的地方,實在沒有意義。

還有系統開發與實作也不是「妥於現實」,利用 IDE 工具從 Web/Windows Form 直接連接資料庫的這種開發方式,只是讓軟體人員變得更笨,只要需求變動就導致牽一髮而動全身,系統是不會有任何的延展與彈性的。最起碼的一點設計良心,又能處在國內嚴苛的環境中,對於短線時程的專案,先將系統的命脈—企業邏輯的核心,全給統籌集中在中間層,也就是企業邏輯層—先求有! 再來才是求好!— 待系統能確實上線,能滿足使用者的需求後,再則老闆與客戶對開發團隊有了信心,肯給予更多的資源—包括人跟錢,團隊的技能也有了增長與更好的溝通默契。外在與內涵的條件均俱足下,就可以專致於對系統結構的重整,並對程式碼施以重構的技巧,而又不會影響既有的功能前提下,讓系統更具可重用性與延展性,甚而轉成產品以服務更多同類型性質的客戶,又能快速的客製化每一個單位的特殊化需求。

基於這樣的理念,我們主張系統分析與設計是要「務實」,不是「昧於現實」,也不是「妥於現實」,而是在現實與理想中找到那一個平衡點。所以課程規劃是分為兩個階段。第一個階段就是捕捉系統功能需求,快速設計,立即產出程式碼。重點就是要瞭解如何作好系統的需求分析與對應到程式碼的實作。本階段需要培訓的技能有物件導向的基礎知識、從使用者角度看待系統時的外部功能分析,抓出適切的功能點開發單位、從畫面、中間層物件到連結資料庫的實作能力等。還有,一定要配套的兩個設計措施,一為撰寫測試案例與功能測試程式碼,實現自動化的測試機制;另一為活用分析類別,先利用中間層的控制類別,集中與控管從畫面與資料庫而來的企業邏輯。 第二個階段就是傳統系統分析所說的 SD(System Design), 傳統是以資料庫的 E-R(Entity-Relation) 分析,在物件導向則是稱為領域模型的建立—包括找出物件與適切的分派責任。這可不是一件容易的事,事實上應該說要具備的抽象能力要相當高,所以為何我們覺得那種 SA->SD->PG 開發流程是不務實的,因為 SD 很難作得好,然後還要 PG 去等該階段的產出,又大部分是不正確,可以說是浪費開發資源與時間。程式碼可以直接反應功能的需求,但不一定要等結構分析,集中在控制控制類別的好處就是,我們可以很容易地對結構作重整、對程式碼作重構,卻又不會影響既有上線的功能。本階段的重點當然就是對所謂結構的分析技能培養,我們會兩種方式,一為從需求抓名詞的傳統方法、另一為揭露出以交易為核心的交易樣式,可以輕易地抓出一大串的企業元件。

總的來說: 作好功能需求分析-> 影響系統能不能做出來 ; 作好結構分析-> 影響系統有沒有彈性

觀念的傳授、設計的圖形化塑模表達、程式碼的實作三層次,是我們對於系統分析設計與實作課程的基本原則與態度。修習本次系統分析的學員們,也可以拿到完整的教材、完整案例的 Model 檔與實作程式碼的對應。程式碼是以 C#.NET 再搭配最夯的 LINQ Framework,當然,要直接對應 .NET 的實作程式碼,那也是相當直覺不是難事。我們期能讓學員們上完課後,能以我們所提供的案例,包括設計模型與程式碼,當成範本而可以應用於工作實務上,甚而可以創造所屬自己的 “Pattern”。 HSDc. 軟體開發團隊,關心每一位軟體人員的持續成長...。

————————————————————————————————————–
§報名資訊:

授課日期:
 o 2008/11/01 起,每週六白天,每次上課為六個小時(AM 9:30~PM 4:30),共九個星期。課後並留半個小時供學員自由提問。
 o 預定上課日期:11/01, 11/08, 11/15, 11/22, 11/29, 12/06, 12/13, 12/20, 12/27 。
 o 遇國定假日或颱風等因素,則延至下一週上課日(本中心會主動通知學員),以此類推。

o 由於本站線上報名系統尚未測試啟用,煩請報名學員填寫下列資料報名 (下列欄位前為 * 者請務必填寫),並以 Email 寄至: service.hsdc@gmail.com
  ————————————————————————————-
  * 姓名:
  * 電子郵件:
  * 聯絡電話:
  任職公司與職位:
  備註(請填上如 ATM 轉帳帳號(後五碼即可)與新生或舊生等資訊):

  ————————————————————————————-
 o 報名經確認後,本站即會寄送確認通知信給報名學員。
 o 報名系統分析與實作班學員,請先以 ATM 轉帳預約費用($1000),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。
 o ATM 轉帳帳號: 新光銀行 (103) 帳號: 0772-50-100979-9
 o 本課程上課學員需滿 20 人以上,若未達上課人數則延期至下一梯次開課,已報名學員,本中心會電話通知,並主動辦理退費(或可保留至下一梯次)。

 授課地點:
  o 開羅會議中心,地址:台北市光復南路65號B2 (光復南路、市民大道交接口)。
  o 參考交通與地圖。 http://www.hsdc.com.tw/education/cario_map

 §課程費用:
  o $14800 (含稅)。 (同等課程原價學費為 $25,000 以上)
  o 曾經上課過本公司的「單元系列課程」學員,優惠 $12800 (含稅)。 (請記得註明為舊生,本公司查詢確認即以優惠算)
  o 三人同行,或同時報名另一單元課程,亦比照舊生的優惠折扣,每位只需$12800 (含稅)。
  o 曾於上一期上課的學員,仍可以免費旁聽本期課程。 (保留 9 名學員名額,並請攜帶原上課講義。)
  o 大學/研究所 資訊相關科系講師、助教或教授,出示相關證明,我們會以建教合作方式計費。(請另以電話聯絡)
  o 清貧或由家扶中心推薦,能出示相關證明,所有費用 免費!!
————————————————————————————————————–

§課程名稱:系統分析設計與實作—活用 UML 塑模 與 C#.NET (54 Hrs)
閱讀全文 »

DoDAF 案例規劃與演練《2》— OV5 (Operational Activity Model)

OV-5 — Operational Activity Model,可說是等同於傳統的企業的業務流程 (Business Process)描述, 在經由一連串的操作 (Operation)所組成的工作流程 (Workflow)後,以履行某一個業務標的或任務 (Mission)。

OV-5 的表達可說是幾乎與 UML 活動圖表達一般,它會描述在諸多活動之間包括 性能 (capibility), 活動 (activity, 或稱為工作, task), 輸入/輸出流 (I/O Flow)等資訊。

為了呈現某一連串活動所組成的活動圖,其目的為何,則可以利用企業層級的使用案例 (Business Use Case)來表達。

OV-5 精要 (Essential)筆記:

  • 利用企業層級的使用案例圖 (Business-level Use Case Diagram) 表達系統的規劃範圍。(本範例為 JFC 系統,亦即將聯合作戰指揮部當作系統)
  • 從使用案例可以看出:
    • 系統觸發事件的主要參與者 (primary actor),與系統的支援性參與者 (supporting actor)。
    • 系統所提供的服務 (service),每一個系統服務即為一個使用案例 (use case)。
  • 區分系統 “內” 與 “外” 時的好處在於:
    • 外部觀點即為功能性的需求分析,是站在外面看待如何 “用” 系統。
    • 內部觀點則著重在系統內部的組成結構元素,一般即以所謂物件導向的分析設計思維。
  • dodaf_ov5_business_usecase
    圖 1、OV5 – Business Use Case (點擊圖可察看原圖)

  • 作業活動圖 (Operational Activity Diagram)的重點在於表達什麼人(角色, role),在什麼時候,做什麼樣的事情(活動, activity),以及這些活動之間的流程關連。
  • 本張視圖的關鍵為呈現 “整體性的業務流程 (business process)”。
  • dodaf_ov5_operational_activity_model
    圖 2、OV5 – Operational Activity Model (點擊圖可察看原圖)

※延伸參考
 o DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)
 o 聊聊 DoDAF/MoDAF 規格與實作議題

DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)

對於大型系統利用 DoDAF 規格的架構規劃,其實均有個共同的特點,也就是有多個節點(Node)、多個資訊系統(Information System)。 包括軍事領域的聯合作戰指揮系統、以及政府單位防救災系統的架構規劃等,均是有這樣的特點:如何表達表達多個節點之間的關連性、如何表達多個資訊系統之間的互動。

兩個主要的觀點: Operation View and System View。 又依照每個觀點所涵蓋的層次(layer) 與 功能性質的不同,又分為 OV1~OV7, SV1~SV11。 有趣的是,即使是 Operation View,也會利用如 UML 的循序圖(sequence diagram),如 OV6,來表達節點之間的動態互動情形。 而 UML 循序圖一般是被用來表達軟體系統內部,參與物件之間的互動合作關係。 其實這隱含什麼意思呢? 很簡單的道理! 在 Operation View,也可以運用物件導向分析的手法,與 System View 所不同的只有:一個是把 Node 當物件;另一個是把 System 當物件;但是相同的是:兩者均用物件導向分析設計的思維來作塑模(Modeling)

依據「DoDAF Deskbook v1」的建議,Architecture View 的開發步驟可以參考如下圖的各種視圖的先後開發順序。 當然,這不會是絕對的,對我而言,在抓這類大型系統的架構時,首要就是要先能界定出系統的整體框架。當把某一個設計的目標框架,界定為一個系統時,就會分出 “外” 與 “內”,而兩者的分析手法與看待系統的角度就會不一樣了。 “外” 重視的是 “用”,所以會觀察系統所提供的服務,而服務就會衍生出,系統應該提供什麼 “介面(interface” 讓外部的參與者來用;再來 “內” 重視的就是系統的組成元素,這就是屬於結構分析的角度。結構分析觀察的兩個重點是,一個為靜態的結構關係、另一個就是,在動態為了完成某一個 “用” 的功能服務時,會有哪些元素的參與、它們彼此之間又是如何傳遞訊息的。 最終,你就會發現到,到底是如何 “界定” 某一個框架為一個系統,會是架構師最大的課題與其必備的素養了。

DoDAF_Architecture_View 建議開發步驟
圖 1、 摘錄自「DoDAF Deskbook v1 p.2-5」

從上圖中可以看出, 「DoDAF Deskbook」所建議的開發步驟,是以 AV1 開始觸發、以 AV2 涵蓋所有的視圖。 事實上,AV-1 是什麼呢? “Overview and Summary”。 其實它就是一份 SAD(System Architecture Document)。 文件內容大概就是包含了專案的目的、專案的描述與說明、架構規劃的標的、情境、任務、願景與目標 …等。 也就是說,在未來展開這個系統的規劃時,範圍與目標均是在該文件所描述的範圍之內。 AV-2 呢? “Integrated Dictionary”,它就是未來在涵蓋所有的視圖內,經常會使用的術語(terminology),要能給予一個明確的定義及其該字彙的意涵。

所以, “All-View” 只是文件的報告而已,真正的第一張視圖是 OV1— “High Level Operational Concept”。 這一張也可以說是要能涵蓋所要規劃系統全貌最大格局的視圖了。 它是給指揮官以上的層級所看的概念性視圖,所以盡量不要以技術面的角度來表達這張視圖。 參考下圖:

DoDAF_OV1_Conceptual_Diagram
圖 2、OV-1— 高階概念視圖

閱讀全文 »

四述「博X來」訂購系統 — 撰寫使用案例需求陳述

從使用案例圖中,可以明確地定義出系統的設計範圍—系統需提供哪些服務(每一個功能點服務即為使用案例)、誰會來使用系統、系統是否需要其它系統的支援。這對開發團隊的每一個成員,能具有整體性的共識,是相當有助益的。 再來就是決定優先開發的使用案例,通常那是對系統的利益關係人(stakeholder)而言,最有價值的,優先開發! 屬於企業服務層級的系統,屬於商業交易型的使用案例,通常是最具有價值的。 以「博X來訂購系統」為例,《訂購商品》與 《結帳商品》兩個使用案例,會是該系統最有價值的需求服務,參考如下圖1。

圖 1、找出價值最高的使用案例優先開發
圖 1、找出價值最高的使用案例優先開發

對於需求分析師(requirement analyst,RA)而言,為每一個使用案例來寫出使用案例的需求陳述(use case description)才是最重要的。 使用案例敘述要能寫得好的訣竅就在於,只專注描述參與者(actor)與系統的互動對話;也可以這麼說,當參與者(一般為使用者)在使用系統上線的期間(session),RA 要能觀察出參與者與系統會有幾次的訊息傳遞(message passing),然後將之寫成具散文格式的動作步驟,到完成最後一個步驟時,系統即能滿足參與者使用系統的目的。

閱讀全文 »

三論「博X來」— 訂購商品與結帳是否是同一個使用案例?

這一次倒不是要 “批判” 博X來的訂購系統,而是想藉由該資訊系統,來聊聊需求分析的設計議題...

我們知道,博X來的訂購系統,存在的最大價值,就是提供客戶「訂購商品」的服務,而為了滿足客戶最終能買到所訂購的商品,所以會有包括如「放入購物車」、「快速結帳」等程序。如果妳是一位需求分析師(RA, Requirement Analyst),那麼在分析以使用案例 (use case)為功能點單位 (functional point)的時候,妳會分析出 “多少顆” 使用案例呢 (只涉及到上述討論訂購商品的範圍)?

我經常思考這類的需求分析議題,也曾就該問題與其他資深分析師討論,有人認為是兩個,也有人認為是一個,當然也有人認為是三個、四個…等。 好像是見仁見智,沒有所謂標準明確的答案。 我是在想,能否有一種簡易判斷的 “準則”,來決定使用案例是一個或多個呢? 老實說,從諸多國外名家 (包括創始者 Ivar Jacobson)對使用案例的定義,我仍不容易釐出那個準則,所以我是想透過觀察使用案例的行為,來找出那個判斷的原則為何。

先觀察實體書店一般的購物程序:客戶走入書店,瀏覽與選擇欲購買的商品 (書籍),並放入購物籃內 (拿在手裡也算,代表已準備好欲購買的商品),並拿到櫃臺,結帳並付款。

所以幾個使用案例呢? 我肯定是認為一個:《購買商品》,因為客戶來這個系統 (實體書店)的主要目的就是 購買商品,而為了滿足該目的,他必須經常放入購物籃、結帳等程序,而且整個交易事件的程序 (從放入購物籃到結帳)是有持續的,約幾分鐘到幾個小時就可以完成 (注意此點)。關於傳統書店使用案例圖的表達,可以參考下圖1。

圖 1、實體書店購買商品的使用案例圖
圖 1、實體書店購買商品的使用案例圖

在使用案例圖的表達上,看起來好像是三個使用案例,其實本質上只有一個:《購買商品》。這裡利用《include》這個 stereo type,只是來凸顯《放入購物籃》與《結帳商品》這兩個子程序而已。

再回到博X來網路訂購系統來看,那麼是否訂購商品的程序與傳統實體書店的購買商品程序是一樣的呢? 看起來很像,都有 放入購物籃 (網路上稱為購物車) 與 結帳 兩個程序。只有一點不一樣,放入購物車 與 結帳 可以是兩個不同時間點的交易事件。什麼意思呢? 當客戶瀏覽商品資訊,若是看到打算購買的商品,就把它放入到購物車內,但是客戶並不需要馬上結帳,他可以等過幾天再決定是否結帳。所以很明顯的觀察到,這是兩個可以在不同時間點個別可以獨立完成的交易 (這一點與實體書店不一樣)。 (不過,這兩個交易事件好像又有些關連存在,要 結帳 前必須先有商品 放入購物車,關於此點,留待後述來討論。)

所以,我的觀察與心得是什麼? 我會以為,若是可以獨立在某個時間點可以完成的交易事件,我會把它就視為是一個使用案例。或者再用更通俗的一句話來說,就是參與者在使用這個系統,從上線到離開的過程,可以 “一氣呵成” 地來完成一個功能案例,該功能案例就可以獨立成為一個使用案例。 所以,博X來訂購系統對於 訂購商品 的主要目標上,會有幾個使用案例? 我是會把它切為兩個:《訂購商品》與《結帳商品》,參考下圖2。

閱讀全文 »

軟體思維顧問

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

Personal