「軟體需求分析與塑模」- 什麼是系統功能

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

系統 (system) 是由一組互動 (interacting) 或獨立的元件 (component) 所組成的整合體 (integrated whole)。

系統功能 (system functions),即為某一整合體所提供給外界 (參與者或外部系統)的一連串服務 (services)。

把企業 (business) 當成一個整合體,並藉以分析該整合體所提供的功能需求,以及組成該整合體的組成元素。這樣以企業為標的的分析塑模方式,稱為「企業塑模 (business modeling)」。

把資訊系統 (information system) 當成一個整合體,並藉以分析該整合體所提供的系統功能,以及組合該整合體的結構元素。這樣以資訊系統為標的的分析塑模方式,稱為「資訊系統塑模 (information system modeling)」。

把企業或資訊系統當為一個整合體,便可以採用相同的手法,如利用 UML (Unified Modeling Language) 語法,來分析系統需求。

「企業」與「資訊系統」兩者的關係即為,「資訊系統」為組成「企業」內部結構的其中之一的元素 (element)。而當把焦點轉移至資訊系統,探究其中所提供的系統需求 (系統功能)時,則再將「資訊系統」這個結構元素放大,並從「外」的需求分析,與「內」的結構設計來看待資訊系統的分析、設計,乃至於實作了。

參考上節範例,「診療服務」為企業的系統需求,如果企業架構師規劃了三個資訊系統 (組成元素) 的支援,參考如下圖,架構師可以利用 UML 使用案例圖表 (use case diagram) 規劃每一個資訊系統各有其需實現的系統功能,以及資訊系統之間的關係是透過介面 (interface)的連接達成所謂的「SOA (service-oriented architecture)」架構。

圖例、表達資訊系統的系統功能

至於資訊系統是如何實現系統功能,又如何連接其它外部系統,那就是所謂的系統 (這裡就是指資訊系統了) 結構設計與實作的議題了。

「軟體需求分析與塑模」– 企業需求源自於企業價值

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

企業需求要能提供價值 (value),如此才得以讓企業有獲利行為而能永續經營。

「價值」的呈現取決於在創新、成本、效率等因子的調和。這些因子經常是由內部工作者 (internal-worker)、產品、系統、軟體與流程 (process)等所提供並滿足其需求。最終目的當然在於讓企業創造「利潤 (profit)」。

例如,「仁心慈善醫院」是一家企業 (business),其中最主要的核心價值係提供 「醫療」的服務 (service)。為了提供「醫療」這個主要服務,企業內部必然會有多個內部工作者的協同合作,包括「醫師」、「護士」、「藥劑師」、「行政人員」… 等;涵蓋的作業流程可能有「掛號」、「看診」、「住出院」、「領藥」… 等;且為了增進處理效率與節省人力,會導入由 產品/軟硬體 所組成的資訊系統 (information system),成為工作者的協力夥伴。

除了文字陳述紀錄外,可以藉由視覺化的圖形塑模 (visualization diagram modeling),更容易表達焦點。

例如,我們可以使用 UML「使用案例圖 (use case diagram)」表達企業所提供的主要服務 (企業層級的系統功能),以及使用「業務流程圖 (business process diagram)」表達實現 (realize) 企業系統功能的主要組成元素 (內部工作者、資訊系統、主要作業流程)。

圖例、表達企業提供的主要服務

圖例、表達實現企業需求內部的主要組成元素

關於 UML (unified modeling language) 的基本介紹,以及應用在企業與資訊系統需求面的分析 Know-how,參閱後述的章節內容。

實作 Enterprise MVC 巨觀結構的 POC-觀念篇

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

關於 POC (Proof of Concepts)的說明,可參考:「淺論架構的 POC (Proof of Concepts)」。

關於系統結構設計 (system structure design),個人把它分為兩個構面來看:巨觀與微觀 (Macro/Micro View)

巨觀結構設計是基於現實系統的分散議題-展示層 (如 Web UI)、永續儲存機制 (如 關聯資料庫),所提出核心業務邏輯應不相依於特定實體元件與實作連結技術的解決方案。這裡推出最實用具應變與可重構的實體分層框架-Enterprise MVC (Model-View-Control)模式 (並非是廠商針對 Web 端提出的 Web MVC 技術),讓系統主結構 (業務邏輯/資料存取)有效隔離展示層與永續儲存機制的直接耦合 (coupling)。

微觀結構設計則是傳統物件導向所談及從領域概念模型 (domain conceptual model),導出到軟體物件與資料模型 (class/data model)。這裡使用的分析設計技能包括了運用 Peter Coad 的「交易模式 (Transaction Pattern)」與 GoF 四人幫的「設計模式 (Design Patterns)」。有別於古典OO 一開始就要求較完整的設計 (太過理想化),現今系統開發則更為務實-運用重構 (re-factoring)的技巧,持續逐漸地重整系統,效果即是簡潔易維護的程式碼 (clean code)。而伴隨著重構的一項必要機制與紀律就必然要求一開始就要撰寫單元測試程式碼 (unit test code)。

上述兩個構面是互補的。軟體主結構一開始就不會實作於特定的UI/資料庫端,以最純淨的 POCO/POJO (plain-old CLR/Java Object)物件來實作,如此才有機會得以實施後續的重構,而重構則取決於某一功能的複雜度與價值來評估,進而創造出系統整體的再利用價值。

本文著重於巨觀結構分層界定與實踐,藉以驗證巨觀結構 POC 的可行性。觀念說明利用 UML 設計圖表現巨觀分層結構;實作則各以 C#.NET 與 Java/Spring 實現一個極小的案例來貫穿整個系統的分層結構元素。

C#.NET 採以 ASP.NET Web MVC 與 E-F (Entity Framework)實作;Java/Spring 則採以 Spring Web MVC 與 傳統 JDBC (也可改 Hibernate Framework)實作。兩者會再佐以 UML 循序圖 (sequence diagram),來輔助解讀案例執行時物件之間的互動合作關係。

巨觀分層結構基本責任界定

把主要分層結構當成元件 (component)看待,以界定各元件主要的責任 (responsibility)。

Enterprise MVC 主要元件責任界定

閱讀全文 »

論述軟體三大基礎觀念-封裝、一般/特殊化 (繼承)、介面/多型

這是看到 PTT Soft_Job 版區一位網友的貼文:[請益] 我這樣解釋OOP對嗎?。原來我已在「FB-軟體設計鮮思維社群」針對此貼文已寫一篇文論述,在此邊我也把回文作個備存,然後再加上一些些心得分享。

剛入門所謂 OO → 連帶等同所謂「物件導向」觀念實作與設計觀念時,幾乎各類 OOP 入門書籍均會談論到此三大術語:封裝 (encapsulation)、繼承 (inheritence)、介面 (interface)/多型 (polymorphism)。看似簡單的術語,卻可能連多數鑽研多年實作的程式開發人員,還不容易真正體會這些觀念的意涵與作用。

即使入這軟體開發行業多年,仍會發現到,軟體大師們的著作,從最早期的 GoF 四人幫「設計模式 (Design Pattern)」,至近幾年「重構 (refactoring)」、「Clean Code」等著作,幾乎都是含繞在上述三大觀念的解釋與實踐。所以也就是說,這三大觀念可以說是要窮究一輩子的研究、思考與實踐力行的,它沒有絕對的標準答案,但也不見得好像很虛妄抓不到。每一段時期的經歷與學習,就可能會對其有著不同的想法與心得體會。

以現在個人入行軟體開發這行業約莫10來年,主要專職於軟體顧問輔導與教學,就以現階段綜合學習、觀察、反思與經驗等,來對這三大術語發表純文字的論述。可能又等 5~10 年後,當又有不同的體認時,再來對比現在的論述,作心得的補充或修正了。 :)


花了三個多小時撰寫這篇 PO 在 PTT soft_job 版,關於 OOP 的三個主要觀念:封裝, 繼承, 介面/多型。

這裡特別提醒下,程序語言用書很喜歡用「繼承」這字眼來解釋 OOP,其實那很容易誤導,常會用 父母生子 這種觀念看待。適切的用語用 "擴展 (extend)" 較適合。UML 稱之為 一般化/特殊化更是合理。

閱讀全文 »

[個案研討] FTP Server 是否可為企業系統的外部系統?

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

月初在內湖某大電視購物/網購平台總部的資訊單位授課。喔,先誇讚下,約有50來位的學員,上課過程大都蠻踴於提問且活潑,可說上得挺順暢愉快。

其中在談及使用案例模型 (use case model)的需求架構分析時,關於外部系統的定義,個人特別強調會是透過介面 (interface)的整合,如透過 web service or message service 等),而不會是透過資料庫的整合方式。

然後其中有位學員就問了,如果連結外部系統是透過 FTP,也就是開發中的系統這邊為 FTP Client,然後以批次定時處理的方式,傳送到外部單位的 FTP Server,對方也是採用批次自動處理的作法,把接收下來的檔案作解析處理。

這樣 FTP Server 是否是開發中系統的外部參與者 (actor)?我倒是沒想到現在會有這樣的作法,最初的直覺當然不會是。

不過課程休息時,再仔細想想,回歸到所謂外部系統整合的定義,是否有透過介面來連結? 事實上,FTP 的 Client/Server 是有的 (當然就是透過 FTP 協定),且兩邊系統之間並未透過手動操作,而確實是系統對外部系統之間有達成自動化的整合 (雖然是透過批次處理的方式)。

為何會有這麼「low」的作法?其實這與實作技術沒有太大關係,而是因為當要與外部單位的系統作整合時,外部單位總會有「安全性」的考量,不一定願意釋放出可讓系統直接呼叫的介面。

閱讀全文 »

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

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

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

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

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

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

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

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

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

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

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

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

閱讀全文 »

軟體思維顧問

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

Personal