「軟體需求分析與塑模」- 物件合作

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

實現 (realize) 軟體資訊系統功能,從物件導向 (object-oriented) 的觀點來看待時,系統內部的主要組成元素是「物件」,也可以稱為「個體 (instance)」。可以想像軟體系統內部就是由擔任各種不同職掌的類型物件,為實現某一特定功能,在動態期間 (run-time) 的互動合作來協力完成。

關於物件如何分類 (classify),這就是所謂物件導向結構設計的議題。分類作得好,讓系統具有低耦合 (low coupling) 、高內聚 (high-cohesion)的特性,如此系統的應變更具彈性、延展性,並得以提昇再利用性的高度價值。

參考下圖範例,是利用 UML 循序圖 (sequence diagram) 表達實現「餐飲管理系統」其中「點餐」系統功能的物件合作 (object collaboration) 情形。程式開發人員應該可以很容易對應至程式碼的類別 (class) 與方法 (method) 的實作。

圖例、實現「點餐」系統功能的物件合作循序圖

軟體結構設計是屬於系統的內部結構設計議題,而需求分析則是站在系統外部的觀點來看待系統所提供的服務 (系統功能),這是完全不同的兩種構面,不能混為一談。一般在需求分析階段,是會把系統當成「黑箱 (black blox)」來看待,只專注在外界 (人或外部系統) 如何與系統的溝通互動,至於系統內部如何組織分類與實作,那就會由結構與程式設計師來負責的。

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

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

實現企業層級系統功能的主要組成元素是「人」,也就是多個不同角色的內部工作者 (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) 繪製傳統人工「訂購-出貨」作業流程。從該案例可以得知,這一連串從訂購到出貨的活動,會有多個不同組織部門的工作人員參與。當完成這一連串活動後,即滿足主要的企業需求-「訂購商品」。

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

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

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

系統 (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,參閱後述的章節內容。

安裝 ArchLinux @Windows 10 子系統 (WSL)

其實 Windows 10 早在去年就已具有可以在 Windows 環境下執行 Ubuntu 的機制,但還很陽春,效能不佳,問題多多。但從 Windows 10 1803 版本釋出後,WSL (Windows Subsystem for Linux) 已修正諸多問題並大幅提昇執行效能,使其執行原生 Linux 系統於 Windows 10 環境下成為可便利運行的方案。

所以,WSL 到底是什麼?這篇 Arch Wiki 上說明得很清楚:

「Windows 10 包含一個模擬 Linux 內核的子系統,使得 windows 可以運行 Linux 原生應用程序。這個子系統有點像反過來的 Wine,但是它比 Wine 更加底層。默認情況下,此子系統使用 Ubuntu 用戶空間,但是它可以被替換成 Arch。你需要使用一個現有的 Arch 安裝去構建一些軟件包。」

我個人是相當偏好 ArchLinux,因為可以高度客製化。安裝 ArchLinux 於 WSL 下相當簡單,因為國外已經有大神整理成安裝執行包,詳見 Github-ArchWSL。安裝該執行包前,需要先啟動 WSL 功能,使用 Administrator 開啟 PowerShell 命令列視窗,執行下列指令:

> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

重新啟動,然後下載上述 ArchWSL 安裝包,解壓縮並置於準備安裝的目錄下 (我是設定於 C:\Linux\ArchLinux 目錄下)。再來依照執行 ARCH.exe,靜待安裝過程 (非常快),然後完成。

閱讀全文 »

[實作筆記] ASP.NET Core Identity 2.1 – 安裝與設定(一)

主要是為了方便授課上講授 TDD.NET 如何應用 Mock 隔離測試的觀念,所以打算藉由 ASP.NET Core Identity 2.1 驗證與授權 (Authentication and Authorization)的機制併整合訂購系統 (核心邏輯/資料庫存取位於另一專案)的案例,來展示 單元測試 (Unit Test)搭配 Mock 隔離的程式碼範例。

另外為了測試資料庫方便可攜供學員可以直接使用,所以打算不再使用具名的 SQL Express 檔案 (連線字串問題,多個專案要指定絕對路徑,不方便複製),而只使用 SQL Express LocalDB (預設位於 C:\使用者\使用者帳號目錄內),然後再以 Code First Migration 方式與 Seed Data 方便初始建置資料庫表格與測試資料,這些留待後續系列文章再作說明。

本系列文章並非是完整的 Step by Step 教學文,而僅是一份實作筆記,主要記錄了實作過程中一些重點摘要。同時也提供了一份程式碼範本,供個人以及對相關議題有興趣的讀者參考。

程式碼範本以 Git 版控儲存於 Github 儲庫:kenming/aspdotnet-core-identyity-2dot1-practice-note
每一個階段會標注 Tag 標籤方便提取研究與切換版本。

先簡單說明下 ASP.NET Core Identity,它是微軟所提供被歸為 ASP.NET Web 端的一個「會員 (Membership)」系統,提供給應用系統開發人員方便具有登入 (Login)驗證名稱與密碼的機制。它很明顯是 Client/Server 的 2-tier 分層方式所開發的系統,但還好因為 Login 這類機制係屬於「非功能性 (Non Functional)」需求,所以也不至於會干涉到應用系統關於「功能性需求 (如處理訂購、追蹤訂購等系統功能)」的耦合 (coupling)。未來可以全部抽換掉 Identity 而不影響到應用系統的主結構 (當然還是要稍稍花一些整合設計的心思)。

個人仍覺得 ASP.NET Identity 即便到 2.1 版本,但安裝與設定程序仍嫌繁瑣,而且從 1.X、2.0 到 2.1,每一次的安裝與設定方式大都不一樣,預期後續版本仍會有持續的變動震盪。所以更顯然絕對不要撰寫與問題領域 (problem domain)相關的邏輯在該專案內,這點從個人後續提供的範例就可以看到如何避免。

本篇文章先著重在如何安裝 Core Identity 2.1,然後新增「Scaffold Identity Item」,並修改些預設的登入選項參數 (如密碼長度),然後執行預設的首頁 (index)並選擇註冊 (register)帳號並執行登入 (login)。

閱讀全文 »

軟體思維顧問

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

Personal