「軟體需求分析與塑模」- UML 應用於需求分析的技術

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

UML (Unified Modeling Language) 係由 OMG (Object Management Group) 所制定的一種以圖形作為軟體塑模 (modeling) 的標準。UML 2.X 規格總共制定了 14 種涵蓋軟體包括結構面與行為面的設計圖,其中適用於需求分析的設計圖主要有兩種:

  • 活動圖 (activity diagram):描述單一作業的業務流程。
  • 使用案例模型 (use case model):紀錄與描述系統功能。包含使用案例圖 (use case diagram) 與使用案例敘述 (use case description) 。

UML 活動圖比較適合描述單一作業流程內部的活動。所謂的「單一」業務流程係指在該流程內諸多活動的協力合作,以完成某一特定的企業目標 (specific business goal)。例如「請購流程」,它的目的在於:決定優先順位的供應商;而至於「採購流程」,它的目的在於:採購高品質的物料。

這些各有不同目的的作業流程,彼此之間可能會有某些關聯存在。例如上述的 「請購流程」,它會產出一請購確認的資訊,然後再將其傳入至「採購流程」。

利用活動圖並不適合描述有多個作業流程之間的關係,因為它揭露了作業流程內部的活動。描述過多的細節反而會失去多個作業流程之間關係表達的焦點。

適合描述多個作業流程的關聯的設計圖,可以利用UML for Erikson-Penker 企業擴充模型 (uml business extension model) 。下圖即為一個電子化採購系統關於「請購」與「採購」的「火箭圖」[註1]。

[註一] 因為 Erikson-Penker 語法內關於作業流程的圖示呈現的是一種 IPO (Input-Process-Output) 類似火箭的圖樣,所以簡稱為「火箭圖」。

圖例、請採購業務流程擴充模型圖 (多個作業流程的塑模)

圖例、請採購業務流程擴充模型圖 (多個作業流程的塑模)

圖例、請購作業流程活動圖 (單一作業流程的塑模)

圖例、請購作業流程活動圖 (單一作業流程的塑模)

至於資訊系統的系統功能分析,則以使用案例圖 (use case diagram)來作為塑模的表達。它很容易可以界定出系統開發/維護範圍、外界 (使用者/外部系統)與系統的關係。

圖例、電子化採購系統使用案例圖 (系統功能的塑模)

圖例、電子化採購系統使用案例圖 (系統功能的塑模)

另外也會使用系統循序圖 (system sequence diagram),表達參與者 (actor,一般指使用系統的人/角色,以及支援服務的外部系統。) 與系統之間的互動訊息 (message)。

系統循序圖是一種系統功能「實現 (realization)」的表達。如下圖 描述的是「Web ATM」系統其中「轉帳」系統功能的實現。系統分析師可以用此來表達參與者與系統/外部系統之間的訊息傳遞的互動關係。

圖例、實現「轉帳」系統功能的系統循序圖 (描述系統功能實現的塑模)

圖例、實現「轉帳」系統功能的系統循序圖 (描述系統功能實現的塑模)

「軟體需求分析與塑模」- 流程與活動

本文收錄於 我的電子書「軟體需求分析與塑模 – 第一章、需求分析概觀」。

實現企業層級系統功能的主要組成元素是「人」,也就是多個不同角色的內部工作者 (internal worker) 在不同的時間點合作接續以完成所屬職掌的工作。

當為了履行一個企業需求,可能需一連串的活動 (activities) 循序接力達成。當然活動的執行需要有特定的參與人員,也就是會有多種不同角色 (role) 或組織 (organization) 參與。這一連串的活動即構成作業流程 (business process)。

Jacobson 為企業流程 (business process) 作了一個簡單的定義:

Put simply, a business process is the set of internal activities performed to serve a customer.
Object Advantage》, Ivar Jacobson, 1994
(簡單地說,企業流程就是要能夠服務客戶的一連串企業內部的活動)

而關於「活動 (activity)」的定義 (from Wiki):

Activity is a major task that must take place in order to fulfill an operation contract.
(活動是一個必須履行的主要工作,為以滿足一個操作上的契約。)

參考下圖範例係利用 UML 活動圖 (activity diagram) 繪製傳統人工「訂購-出貨」作業流程。從該案例可以得知,這一連串從訂購到出貨的活動,會有多個不同組織部門的工作人員參與。當完成這一連串活動後,即滿足主要的企業需求-「訂購商品」。

圖例、傳統人工訂購-出貨作業流程

案例研討-關於客戶單位維修作業流程的系統分析

** 本文同步發表於 FB 社團-軟體設計鮮思維 **

這是月初的授課—「系統需求分析與整理」,其中一位上課學員拿他們的實際案例提供參考的。

先來瞧瞧這張看似很複雜的作業流程圖,主要是要描述當客戶單位提出報修需求時,維修單位的報價與維修的相關作業活動。

圖、原稿—客戶維修報價作業流程

圖、原稿—客戶維修報價作業流程

這是一張典型 SA 所繪製的業務流程 (business process)圖,是否使用 UML 語法來表示,那並不重要。最主要的問題是,大多單位往往都認為這類業務流程的表達,必須要描述得很「精確」,才可以轉移到實作的階段。所以為了要能取得「精確」的結果,就需要不斷地開會與確認 (還含時常爭執各據的論點),秏上個把個月才能有產出,然後再轉移到實作階段。

但是無論再如何精細,我發現到有一個相當有趣的現象,在這類環境下的 Programmer,往往都還是覺得不夠精細。

越是想表達得精確,Programmer 越會嫌不夠精確!

這就是典型的瀑布式 (waterfall)系統分析。這類所謂「精確」的業務流程圖,耗費太多在需求分析的時間,且由於描述了太多細節,反而讓實作寫碼不容易抓到適切的焦點,因而導致 Programmer 不知道如何寫出較具「彈性」可包容變動細節的程式碼,當然相對日久也就會把不精確的細節當成是一種無法 Coding 的藉口。

所以,上述如此好像「鉅細靡遺」的設計圖,主要的問題在哪裡? 其實簡單的說,它早已違背了軟體設計至高無上的原則—封裝 (encapsulation)。

  • 把資料細節呈現出來 (資料導向的思維)。
  • 設計圖內描述了企業邏輯 (business logic)。
  • 過早把資訊系統角色帶入。

閱讀全文 »

大業務流程塑模的MSS三層次原則

越是大型公司的 IT 資訊單位,無論是外包或是自行維護/開發的系統,在作「需求分析」階段時,往往都會表達到所謂的「業務流程 (Business Process)」。

甚麼是業務 (或稱為企業)流程? 這裡節錄 Jacobson 《Object Advantage》一書中,將企業流程定義為:

Put simply, a business process is the set of internal activities performed to serve a customer.(《Object Advantage》, Ivar Jacobson, 1994, p. 3)
(簡單地說,企業流程就是要能夠服務客戶的一連串企業內部的活動)

或者更簡單的解釋,業務流程表達的就是:某個人在某個時間點所作的某件事 (而這些事會呈現出關聯性與先後順序)。

而甚麼是「大業務流程」?簡單的說,就是業務流程範圍更為廣泛,參與的人更多,所涵蓋的時間更長。而且往往因為現實上基於功能執掌,還是不同部門或不同地點就有不同的作業規範與範疇,但彼此這些作業之間仍需要連串在一起。

例如,物流零售業領域,為了表現出從門市的「訂貨/退貨」,到總部的「進貨/出貨」,乃至於轉入財會單位的「帳務處理」,每一個業務範疇,就有其作業流程/作業規範;而把「訂貨/退貨」→「進貨/出貨」→「帳務處理」等作業流程串聯成更大的流程,即為所謂的「大業務流程」。

我走訪過許多大型的 IT 單位,包括顧問輔導或教學等。檢視從該單位 SA (System Analyst, 表示為需求分析師)所整理的業務流程設計圖,無論是使用傳統的流程圖 (flow-chart),甚或採用 UML 語法所表達出來的活動圖 ((activity diagram),幾乎普遍是存在兩大問題:

  1. 想要利用一張圖表現出所有的細節。
  2. 把資料作為主體,呈現的就是資料傳遞的流程。

第二個問題最難解,這裡牽涉到的就是「資料導向 (data-oriented)」 vs. 「服務導向 (service-oriented)」的分析/設計態度。

若從上述對業務流程的定義,或是後續利用使用案例 (use case)的分析技術,國外軟體大家的最佳實務經驗 (best practices),均是偏向「服務導向」的開發模式。簡而言之,就是將資料封裝 (encapsulate)至服務之內,如此可避免過早揭露繁瑣的細節。

第一個問題則比較容易調整,主要就是把握住一個最基本的原則:設計圖要能維持「簡潔」

「簡潔」的目的在於要能適切突顯出「焦點」之所在,而把諸多繁瑣的細節給封裝住。待決定集中的焦點後,再來才是將其內部「剖開」,探究細節的組成與關聯性。

而要能達成簡潔,就需要考量兩個構面-「廣度」與「深度」,要讓設計有「層次感」。

簡而言之,「廣度」考量的是所涵蓋的範圍;「深度」則是考量所揭露出細節的精細度。

以「大業務流程」的設計呈現,我這裡推薦採用「三層次」的表達,我把它稱為 MSS (Multiple - Single - System) 塑模表示法

  • M (Multiple) Process-表達多個業務流程 (Business Process)之間的關聯性,利用「Erickson Penker (俗稱火箭圖) 流程擴展語法」表達。
  • S (Single) Process-表達單一業務流程內的作業活動 (activities)。利用 UML 「活動圖」表達。
  • S (System) -表達資訊系統所擔負的功能。利用 UML「使用案例 (use case)圖」表達。

閱讀全文 »

軟體思維顧問

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

Personal