Blog

[美食推薦] 吃了會讓人感動的台北溫州街家常菜小店-生囍食堂

前兩個月我與蓁妮常到位於師大附近的「欒樹下書房」上網做事待一整個白天 (那裡真是個舒適悠閒的好地方)。有時中午過去想在附近用餐,但我那挑嘴的女兒曾經我陪她走了快半個小時全沒找到她滿意的餐館,讓我有夠氣噗噗的。

不過有次從泰順街轉位於「殷海光故居」的巷口時看到這好小一間「生囍食堂」,好奇之餘入內一看,黑板上的菜單竟讓我家蓁妮可以接受,所以就來嘗看味道如何。
20180906_132548

菜單很簡單,就是只有「豬、雞、魚」三種套餐,然後會隨她們早上到市場採購的食材來決定當天的主餐菜色,相當特別。
20180906_132530

20180906_125747

也有不含主餐的菜飯,老實說,胃口不大的光點這菜飯就足夠了,三菜一湯超級豐富,況且白飯或十穀飯可以吃到飽,真是佛心來著。
20181026_123351

第一次我與蓁妮各點了一份豬滷肉與黃魚套餐,天哪~餐點送過來時我嚇了一跳,這也太過豐盛了吧,竟然連湯都是附上香菇雞湯 (每次的湯會不一樣,但肯定都有主食在其內)。
20180906_125703

這樣一份如此豐盛的套餐,豬與雞一律是 NT$220,魚大約是 NT$290,實在也太過超值超值了。
20181012_130451

這次我家蓁妮超乎平時的挑嘴說,邊吃邊直說好吃好吃。飯後她說,以後她肯定要一週至少來一次的,這樣的餐館一定要支持不能讓它關閉的。 :)

蓁妮還特別到粉絲團留言讚道:
「很簡單,也很不簡單的家常料理,上次造訪時點了豬和魚套餐,配菜豐富(香菇雞湯、茄子夾地瓜、杏苞姑、炒地瓜葉),還有一碗十穀紫米飯搭上清爽的綠茶。第一次親身感受到食物真的有治癒人心的力量。」

20181026_122219

我已經太多年沒有在外面的餐館可以吃到如此讓人感動莫名豐盛的家常菜了,確實會讓人頓時充滿了幸福感與感恩的心情。
20180906_125810

不過這店的空間實在太小,裡面才幾張餐桌,所以過去前務必要先電話訂位才可。
20181026_122223

飯後我與蓁妮就會走到斜對面的「殷海光故居」散散步消化下,院宅內可真是鬧中取靜,又可以了解翻閱下「殷海光」的生平故蹟,引懷思念。
20180906_132741

20180906_132732

「軟體需求分析與塑模」- 跨多個作業流程的塑模

本文收錄於 我的電子書「軟體需求分析與塑模 – 第二章、企業流程的分析與塑模」。

每一個作業流程,有各自不同特定的企業目的 (specific business goal)。例如:

  • 訂貨流程的特的目的為讓交易有效率且安全可靠。
  • 出貨流程的特的目的為及早可將貨品交付到客戶手中。
  • 採購流程的特的目的為從供應商取得低成本、高品質的商品。

企業經營者/高階管理者、系統相關的利益關係人 (stakeholder)、乃至於系統開發團隊,希能透過這些作業流程看到較巨觀 (macro view)、更具整體的全貌 (Whole View),如此可得以有效地作整體性的架構規劃與設計。

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

由Erickson以及Penker所提出的一個活動圖的擴充型態(stereotype),稱之為「Erikson-Penker 企業擴充模型」(Erikson-Penker Business Extension)。(《Business Modeling with UML: Business Patterns at Work》, Manus Penker & Hans-Erik Erikson, 2000, p.57),該設計圖形最適切用來描述跨多個作業流程之間的關聯與各自的企業目的。

這個圖形中,主要是將與作業流程相關的重要人、事、物以及這個流程所要達成的目標做一個連結;不過有關企業流程的內部細節,通常在這張圖中不會有過多的介紹,以免失焦 (內部的活動細節會由 uml 活動圖表達)。

Erikson-Penker企業擴充模型簡介

下圖即對 Erikson-Penker (底下簡稱火箭圖) 的企業擴充模型的重要元素作說明。

圖、Erikson-Penker 企業擴充模型的主要圖形元素

 

閱讀全文 »

[備註] Visual Studio 2017 跑 x64 單元測試的設定

最近申請到「群益報價/下單 API」,也下載了 C#.NET 的範本,但卻是用 Visual Studio 2010 編譯的專案,花了一個多小時手動編輯 .csproj,總算可以在 Visual Studio 2017 開啟執行

不過範本寫得非常之亂,典型的全把所有邏輯寫在 Windows Form 類別。實在看不下去,準備把一些主要呼叫的 API (Login,下單,報價) 重整下,從 Windows Form 全抽離出來,並撰寫單元測試 (unit test) 方便測試。

群益API 是採以 COM 相對底層機制所撰寫的,使用前要先註冊該元件 (SKCOMLib)。我直接採用 x64 64位元的處理器架構,完全不考慮 32位元,還好群益都有提供。

程式撰寫挺簡單,但執行單元測試卻出了問題,只要將「目標平台 (target platform)」改為「x64」就會出現一些很怪的錯誤訊息。原來以為是呼叫 COM 出了問題,甚至打電話問了群益的資訊部人員,但他們竟然說沒聽過單元測試,程式沒有從 Form 開始就看不懂。挖哩,不過他們確信 COM 元件沒有問題,看來還是出在環境設定上。

查找解決文與 Try-Error 大半個下午,總算,就是只要在 Visual Studio 2017 選單「測試」→「測試設定」→「預設處理器架構」改為「X64」就 OK 啦!

Visual Studio 2017 跑 x64 單元測試的設定

「軟體需求分析與塑模」- 企業層級系統塑模的範疇

本文收錄於 我的電子書「軟體需求分析與塑模 – 第二章、企業流程的分析與塑模」。

把企業/組織當成系統作需求分析,其系統功能的實現 (realization),由於涵蓋作業的時間長,且會有多類角色的參與者 (participant) 參與期間,以組成一連串的協力活動 (activities)。

而關於企業多人使用的資訊系統,如 MIS (Management Information System)、ERP (Enterprise Resource Planning)、電子商務 (e-commerce)、電子服務平台 (e-service platform) …等,也常需先分析與描述為達成企業某一特定目的 (specific goal) 需求時,原來傳統人工作業的活動,這往往是未來為分析資訊系統功能的前置引導作業。

所以對於「活動」流程的表達,必然是對於企業本身、企業層級的資訊系統等的系統需求分析,是一種必要的開發儀式。

前一章節已提及,單一特定目的作業流程適於採用 UML 活動圖 (activity diagram) 記錄;而表現多個作業流程之間的關聯性,則適於採以「erikson-penker」uml 流程擴充圖來表達。本章節針對這兩種設計圖,就語法與操作應用上作詳細的說明。

另外特別強調的,需求分析師在描述作業流程,盡量不要加入「資訊系統」的參與, 原因有二 [註1]:

  1. 不容易界定資訊系統的開發/維護範圍。
  2. 不容易瞭解會有幾個資訊系統的參與。

[註1] 資訊系統範圍的界定與系統的切分,係由擔任系統整體架構規劃的架構師 (architect) 所負責。需求分析師在初期並不容易瞭解資訊系統的責任,所以最好不要在作業流程的表達加入資訊系統的角色,以免容易造成混淆。

所以作業流程,適合描述的是傳統的人工作業,也就是所有的參與者必定是「人」或「組織」所擔任的角色 (role)。

至於資訊系統的系統功能 (system functions) 分析,會採以較適合的塑模技術,例如使用案例模型,這在後續章節即會詳述。

企業流程與資訊系統功能的分析與描述,這裡採以「MSS」三層次的塑模分析方法,如此可以有效表達在人工與資訊系統的「活動-系統功能」間的關係,並得以讓設計圖表現得簡潔,自然能形成一種層次分明、井然有序的設計框架。

  • M-Multiple Process (跨多個作業流程)。
  • S-Single Process (單一作業流程)。
  • S-System Function (資訊系統功能)。

「軟體需求分析與塑模」- 區分功能性需求與非功能性的需求

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

所謂的功能性需求 (functional requirements) 即是使用者需要系統能為他做什麼。這往往是顯而易見的,因為,使用者可以清楚的看到系統為他服務並會有回應。例如在一個訂購系統中,功能性需求有:

  • 系統接受顧客的訂購 (系統功能-place order),並且會通知倉管該產品庫存量是否充足。
  • 系統會對前一日的訂購在當夜會產生統計報表 (系統功能-process order summary report)。

系統的功能性需求源自於開發或維護中系統的問題領域 (problem domain)。例如「電子商務系統」,功能性需求有「處理訂購」、「追蹤訂購」…等。

功能性需求需直接滿足於使用系統的操作人員或相關利益關係人 (stake holder),它是屬於系統的「顯性價值」,是與企業的需求有直接的關聯。

功能性需求的分析技術即為本書內容的重點。各類軟體開發方法論均有提供如何分析系統功能的技術。例如 Agile (敏捷式) 的「user story」、SCRUM 的「backlog」,以及行之有年的「use case (使用案例)」。本書的系統功能分析主以「使用案例」的分析技術來捕捉系統功能性需求。它既能包容其它需求分析的技術,又能很順暢橋接到結構設計與程式寫碼實作,這在後續的章節即會詳述,並會以案例研討的方式舉例說明。

非功能性的需求 (non-functional requirements) 往往是使用者所感受不到系統有直接提供服務並有回應。非功能性的需求是總體 (global) 的、模糊 (fuzzy) 的一些因素而導致系統整體的良好運作。例如:

  • 系統要能處理超過1千人以上線上訂購書籍的效能 (performance issue)。
  • 系統為了要能應付日增的交易處理,所以必須要能具備延展性 (scalability issue)。
  • 系統的登入 (logon) 須具有密碼加密的機制 (security issue)。

系統的非功能性需求源自於開發或維護中系統的解題領域 (solution domain)。例如「電子商務系統」採以「JEE (Java Enterprise Edition) + Spring Framework」的實作解題技術框架。

非功能性需求是屬於系統的「隱性價值」。它不容易被直接感受到,只有當碰到系統整體性的震盪 (如多人操作存取時的效能與穩定問題、帳戶安全性問題)時,系統的品質問題與危機意識等才會浮現出檯面。

一般非功能性需求較被列為實作面的考量,例如下列幾個實作議題:

  • 多人上線時的交易效能與穩定性。
  • 安全性的考量。
  • 分散式溝通議題。
  • 延展性議題。
  • 異地備援/災難重建議題。

非功能性需求並非採以上述所提及的系統功能分析 (如 use case) 技術,一般它可能僅以清單列表的方式註記並列為系統的一種約束 (constraint) 即可。

「軟體需求分析與塑模」- 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」系統其中「轉帳」系統功能的實現。系統分析師可以用此來表達參與者與系統/外部系統之間的訊息傳遞的互動關係。

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

圖例、實現「轉帳」系統功能的系統循序圖 (描述系統功能實現的塑模)
軟體思維顧問

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

Personal