[個案研討] 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)。
  • 過早把資訊系統角色帶入。

繼續閱讀 »

簡單聊聊軟體設計的 SRP (Single Responsibility Principle) 原則

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

SRP, Single Responsibility Principle (單一責任原則)

這是上星期課堂中,當我解釋 Multi-tier MVC 分層結構時,聽到學員告訴我的。

哈,這是我第二次遇到學員有告訴我這個術語,看來都蠻熟悉 Martin 在 "Agile Software Development, Principles, Patterns, and Practices" 一書內所提到的幾個軟體設計原則。

不過當我問他們工作上是否至少有把 UI 與 Logic/Data Acess 層分離? 沒有!還是全都攪在一起,沒有人講究上述分層的 "基本責任分派"。

沒有「知行合一」,確實實踐並從實務中體會與調整作法,那麼,學會 "背" 這些術語是沒啥用處的!

其實也只有一個字需要真正了解:責任 (responsibility)。

o Web UI (view & ui controller) / Standalone UI:Presentation (只負責傳送與回傳已運算資訊)。

o Domain Controller:負責控制流程 (control flow)。

o DAO (data access object)/ Adapter:負責連結資料庫/外部系統。

o Entity (或稱 business) Object:負責處理邏輯運算。

確實理解 "responsibility" 這個術語可不是用背的,而是身體力行,從過程當中去體會該術語的「真諦」。

從原點出發,一個詞彙可通一堆觀念。如當確實做好單一類別的責任分派時,所得到的效果就是「高內聚力 (high cohesion)」—責任明確。

開源免費下載-完整設計模式 (design patterns) 程式碼(C#.NET)/UML Model 檔

關於爾後我們 HSDc. 軟體設計顧問所開設的課程,除了教材內容尚無開放以外,其它包括完整可執行的程式碼、UML Model 檔,均以開源方式 (open source)免費供下載。

所有開源文件的釋出 (release),均可以透過加入 FB社團-軟體設計鮮思維 獲取最新的訊息。而所有的程式碼/UML Model,我們則是一律統一放置於 GitHub,當然在 README 文件上我們會附上基本的操作說明。

以後這些開源文件,尤其是案例程式碼,我們均會不定期持續版本更新。讀者可以透過 Git 工具隨時作同步更新。

目前提供了兩份開源文件:

另外補充關於上述設計模式 (Design Patterns)案例的說明。

在 C#.NET 程式碼部分 (Java/Spring 版本後續會另行公布),包含了完整 23 個設計模式範例;而關於 UML Model,則還增加了以周遭生活案例的塑模 (modeling),讓每一個設計模式的目的更容易理解。

關於 C#.NET 程式碼的結構部分,主要分為兩個專案 (project):一為 Web MVC by ASP.NET;另一為 Control by POCO (plain-old CLR objects)。

關於本案例的設計模式物件分層結構,可以參考下圖:

圖、圖、設計模式的物件分層結構

圖、設計模式的物件分層結構

繼續閱讀 »

Design for Interface 的生活案例-沖煮咖啡的介面設計

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

GoF Design Pattern 一書開宗明義即提及:Design for Interface!

軟體的介面設計很重要的一個精神就是:不要重新造輪子!!
如果引用某些 3rd party library/framework 的功能,要懂得利用介面與主系統隔閡掉,如此才能造成 PnP (Plug & Play)的效果。

舉個生活的範例。88度C 的主要服務是銷售糕點與咖啡,其中咖啡服務 (需求分析)需要系統有個結構元素-咖啡機 (結構設計)來實現。

咖啡機的目的是沖煮咖啡 (Interface 規格),而購置某品牌的考量可能有:1.成本低 2.穩定/快速 3.好喝

如果購買的 A牌咖啡可能故障或沒達成上述需求,那麼就直接抽換掉,可能送修或改購置另一品牌的咖啡機即可 (但前提是不應影響到主系統的服務)。

咖啡機故障/效能不佳等因素,88度C 這個系統的設計/開發人員不可能也沒必要把咖啡機打開去維修或更改電路/零件吧?

現實生活上應用這類介面規範的案例非常多,主機板透過 PCI Express (介面)可插入各品牌顯示卡即是一例。(主機板設計人員不用考量顯卡的實作)

但回歸軟體資訊系統,不懂得介面設計,直接侵入 (hack)到 3rd party library/framework,想要把輪子改得更好甚或重新造輪子。這樣不僅耗工做沒啥意義的事情,且造成主系統與這些 3rd party 的嚴重耦合 (coupling),導致不容易/無法抽換,因而造成主系統的主要服務更為僵化難以應變的後果!

圖、範例-從Twitter畫面操作找出 Use Cases

圖、範例-沖煮咖啡的介面設計

[系統分析] 從 GUI 畫面分析使用者的操作目的 (Use Cases) – 以 Twitter 為例

這是上一期「系統分析設計與實作」課程的一位美女學員-Isis 的案例作品。她對 Use Case (使用案例)用於系統需求分析情有獨鍾,而且相當積極的學習與詢問問題。

不過可能待在業界許久,一開始對 Use Case 這類講究目標導向的分析方法並不容易理解,總是不自覺就鑽入到細節,或是聯想到實作面議題。所以就不容易抓到 Use Case 的分析主軸-界定參與者 (actor)使用系統的操作目的,以及實現該目的的操作程序。

我使用了幾種方法,包括如何從企業流程的分析找出使用案例,或要求綜覽閱讀 Use Case 的經典名著「Writting Effective Use Case」(再針對她提問的問題回應),甚至乾脆從某一個實際的專業問題領域 (problem domain)著手,但效果仍不彰。

畢竟大部分軟體人員少對所謂的「抽象 (abstraction)」技能下功夫。抽象是需要經由思考、閱讀、觀察等長期日積月累才得以鍛鍊而成的。

所以換一種較具象的方法,從現實各網站的使用者操作畫面中,完成下列的系統分析工作:

  • 界定系統範圍 (system boundary),並給予系統命名。
  • 規劃功能模組 (functional module),這是邏輯性的功能分類。
  • 從每一張畫面表單,透過所提供的資訊,以及要求使用者輸入的資料欄位中,藉以分析其背後的操作目的,也就是使用案例。

我先給她系統規模較小的 Twitter 案例,要她完成上述三項重點工作,而先不用撰寫使用案例陳述 (use case description)。雖然使用案例陳述才是實現系統功能的主要程序,但可以先等系統功能的界定有了初步釐清與共識後再來描述相對的實現步驟,這對使用 Use Case 分析的 SA 而言,比較能有循序的分析節奏,才不致亂了套。

耶!!這方法還真對 IS 的性向,不到兩天就完成了我看了也覺得很有創意的分析。經由她的首肯,我就把她的案例作品分享上來。

圖、範例-從Twitter畫面操作找出 Use Cases

圖、範例-從Twitter畫面操作找出 Use Cases

繼續閱讀 »

第 1 頁 / 共 241 頁123456789101112...203040...最後一頁 »