問題陳述—外包程式碼的結構驗收問題
- 客戶(發包單位)可以透過自動化的功能測試碼來驗證系統功能的正確性，這是屬於系統外觀的驗收範疇。但是，客戶又如何來檢驗外包廠商(承包單位)有依據承包契約(Contract)內的設計藍圖來施工(Coding)，確保系統內部的結構(Structure)設計，而不是以沙拉油桶混充建材，偷工減料？
從客戶端的角度來思考對策與解決方案
- 系統內部結構設計的檢驗重點是什麼？
- 能利用利器將程式碼反轉(Reverse)成為視覺化的模型，最好就是標準的 UML 圖，而得以方便與快速來作結構的檢驗。
- 這個利器若能同步反應設計圖與程式碼的變更，那就更理想不過！
- 因為設計圖與程式碼能透過該利器保持一致性，兩者成為系統的一體兩面：程式碼反應實做；設計圖反應視覺化的模型設計，更因之而能成為標準、實在、確實、非作假的設計產出(Artifacts)文件(Documents)了。
系統結構設計的檢驗核心—相依性分析
- 兩個元素之間的關係，稱為相依性(Dependency)。
- A 元件(Component)呼叫(call) B 元件所提供的服務(service)，兩者之間構成了相依的關係 — A 相依於 B。
- A 元件相依於 B 元件，代表當 B 元件變動時，會造成 A 元件的連帶變動。但反之則否(A 元件變動，不會影響到 B 元件)。
圖、範例-A 元件相依於 B 元件
相依性分析的目的與元素的單位
- 讓元素之間相依性降低(低耦合性，Low Coupling)，變動的影響不大。
- 相依性分析的元素(或可稱之為元件，Component)單位
- 類別(Class)
- 套件(Package)
- 模組(Module)
- 子系統(Sub-System)
- 單一系統
- 系統與其它系統(如透過 Web Service 介面連接)
範例：巨觀的相依性分析 — 2-tier 的結構分析
- Form AP 直接連接資料庫撈資料處理—Form AP 相依於資料庫。
- 當資料庫的 DB Schema 變動時，會連動影響所有連接該資料庫的 Form AP。
- 因沒有明確定義企業邏輯(Business Logic)的所在處，若位於 Form AP 處，則以 scripts 處理之；若位於資料庫內，則以 stored-procedure 處理之。這也意味了企業邏輯相依於 Form 或 資料庫的實體機制。
圖、兩層式(2-tier)的結構
範例：巨觀的相依性分析 — 3-tier 的結構分析
- 企業系統的核心 — Problem Domain Model。
- 由於 Problem Domain Model 沒有相依於任何元素，所以，包括 UI Form、資料庫系統等均可以各自抽換而不會連動影響。
圖、三層式(3-tier)的結構
範例：微觀的相依性分析—分析類別的結構設計分析
（縮略圖，點擊圖片鏈接看原圖）
Hello william:
“設計” 與 “自動化” 的對比，在於軟體有太多太多的東西是無法被自動化給取代的；畢竟，軟體涵蓋了哲理、藝術、工程與創意等等成分因素。
不過，系統的實做可不一定是繁雜瑣碎的層次，我個人從沒有看輕這一層。只是，人(能)力有限，無法涉及、涵蓋太多的層面，這也是我一直在強調仍需要團隊的知識分工，比較有機會能包容廣度與深度。
您所提的關於檢驗套件的相依性等展示，那當然是有啦。
因這些我覺得算是蠻基本的 Demo，所以並沒有明顯突出來說明。 🙂
其實看到您的報名，以及看了您的 Blog，我大概也預期您應該是有興趣於如 Pattern and MDA 等議題。
關於 MDA，那的確是未來幾場研討會，必然會提的主題重點。
對了，有機會我到蠻希望能與您見個面，一起喝杯咖啡聊聊。許多的議題，我個人也蠻想請教您的意見。 ^_^
其實我也知道以現在的軟體工具技術而言，reverse engineering 本來就還只能在很低很瑣碎的層次。（這是我中長期的研究興趣之一。）
其實我自己也比較傾向於您所說的「以啟發性的方式來引導學員自我反思」授課風格。
只不過我看到這次系列講座的綱要，在在強調與 Borland 的 JBuilder + Together 工具的搭配，強調這些軟體工具能在以下數個地方出力：
既然講座大綱都這麼寫了，自然不能怪我們有「經常需要 “眼見為憑”，也希望能有具體的工具來協助呈現」的預期心理啦。 🙂
順便提一下我當初參加 6/25 那場次的動機吧。
該講座是隸屬於「UML2.0/EA 軟體設計系列講座」的第五場。看到這個總系列名稱，我預期這系列講座將不只是介紹 OO 軟體設計觀念，更會大量以貴公司代理的 EA 做為具體落實的手段。正好這陣子我在 survey 各大場的 MDA 佈局及現況，所以報名去觀摩一下。
可惜當天，除了「Design Pattern 與 UML Tool 的結合」場次較合乎預期之外，「boundary design」場次並沒有很符合事先公佈的綱要第 2、3 兩點：
當然啦，您講的 state diagram 也很精彩，只是我先入為主有了錯誤的預期。
當天我本來也想留下來與您一聊，只是晚上還有事。
Hi william:
上次研討會沒看過您，後來透過 Tommy(一位戴眼鏡忠厚老實有與你聊那一位) 才知道您也有來，沒有與您交談，挺可惜的。
1. 第一個問題是，您可以思考，透過各種 Tool Reverse 的機制，到底該Reverse “What”？ 而那個 “What” 是值得設計人員該觀察的？
程式碼是實做的產出，而，business level 層次，諸如您所提及的 business uc，涵蓋了設計者的思維，”something” 是無法被具化的，那並非是能透過 “工程化” 的機制就可以正向/反向 來達成的。
2. 可能您會失望了，對於工具層面的操作，是由我們另一位 partner Ringle 來負責的，個人是比較少涉及至工具的操作面。
至於，您所提及的軟體自動化的實作例，我個人是比較傾向以啟發性的方式來引導學員自我反思(這是在我們 UML 講座系列，個人的表達風格)，而非往工具、how-to 的方向走。
不過，畢竟，太多的人們經常需要 “眼見為憑”，也希望能有具體的工具來協助呈現。所以，您所提的這樣的現象，我會很希望能與一些 “實作面” 的高手(例如 Tommy)來配合，而會有更 “具體” 的產出來呈現。 🙂
問題是：以現在的 Together + JBuilder，有辦法 reverse 到 business use cases/business objects 層次嗎？
現場會大量的 demo，而不是像 6/25 那場的 boundary design 和 state diagram 都缺乏軟體自動化的實作例。
還在考慮要不要報名這兩場…