【企業軟體委外】外包程式碼的結構驗收問題

問題陳述—外包程式碼的結構驗收問題

  • 客戶(發包單位)可以透過自動化的功能測試碼來驗證系統功能的正確性,這是屬於系統外觀的驗收範疇。但是,客戶又如何來檢驗外包廠商(承包單位)有依據承包契約(Contract)內的設計藍圖來施工(Coding),確保系統內部的結構(Structure)設計,而不是以沙拉油桶混充建材,偷工減料?

從客戶端的角度來思考對策與解決方案

  • 系統內部結構設計的檢驗重點是什麼?
  • 能利用利器將程式碼反轉(Reverse)成為視覺化的模型,最好就是標準的 UML 圖,而得以方便與快速來作結構的檢驗。
  • 這個利器若能同步反應設計圖與程式碼的變更,那就更理想不過!
  • 因為設計圖與程式碼能透過該利器保持一致性,兩者成為系統的一體兩面:程式碼反應實做;設計圖反應視覺化的模型設計,更因之而能成為標準、實在、確實、非作假的設計產出(Artifacts)文件(Documents)了。

系統結構設計的檢驗核心—相依性分析

  • 兩個元素之間的關係,稱為相依性(Dependency)。
  • A 元件(Component)呼叫(call) B 元件所提供的服務(service),兩者之間構成了相依的關係 — A 相依於 B。
  • A 元件相依於 B 元件,代表當 B 元件變動時,會造成 A 元件的連帶變動。但反之則否(A 元件變動,不會影響到 B 元件)。

範例-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)的結構
圖、兩層式(2-tier)的結構

範例:巨觀的相依性分析 — 3-tier 的結構分析

  • 企業系統的核心 — Problem Domain Model。
  • 由於 Problem Domain Model 沒有相依於任何元素,所以,包括 UI Form、資料庫系統等均可以各自抽換而不會連動影響。

三層式(3-tier)的結構
圖、三層式(3-tier)的結構

範例:微觀的相依性分析—分析類別的結構設計分析

分析類別的結構設計分析
(縮略圖,點擊圖片鏈接看原圖)

文章導覽

   

共有 4 則迴響

  1. Hello william:

    “設計” 與 “自動化” 的對比,在於軟體有太多太多的東西是無法被自動化給取代的;畢竟,軟體涵蓋了哲理、藝術、工程與創意等等成分因素。

    不過,系統的實做可不一定是繁雜瑣碎的層次,我個人從沒有看輕這一層。只是,人(能)力有限,無法涉及、涵蓋太多的層面,這也是我一直在強調仍需要團隊的知識分工,比較有機會能包容廣度與深度。

    您所提的關於檢驗套件的相依性等展示,那當然是有啦。
    因這些我覺得算是蠻基本的 Demo,所以並沒有明顯突出來說明。 🙂

    其實看到您的報名,以及看了您的 Blog,我大概也預期您應該是有興趣於如 Pattern and MDA 等議題。

    關於 MDA,那的確是未來幾場研討會,必然會提的主題重點。

    對了,有機會我到蠻希望能與您見個面,一起喝杯咖啡聊聊。許多的議題,我個人也蠻想請教您的意見。 ^_^

  2. 其實我也知道以現在的軟體工具技術而言,reverse engineering 本來就還只能在很低很瑣碎的層次。(這是我中長期的研究興趣之一。)

    其實我自己也比較傾向於您所說的「以啟發性的方式來引導學員自我反思」授課風格。

    只不過我看到這次系列講座的綱要,在在強調與 Borland 的 JBuilder + Together 工具的搭配,強調這些軟體工具能在以下數個地方出力:

    • 以 Together 進行 Use Case 設計
    • 建立 Use Case Functional Test
    • 利用 Together 產生測試程式碼框架
    • 以 JBuilder 開發測試程式
    • 運用 JBuilder 檢視程式碼與套件之相依性
    • 運用 Together 反向工程產生類別圖與套件圖
    • 修正設計圖並同步至程式碼
    • 以 Together Report Tool 產出開發文件

    既然講座大綱都這麼寫了,自然不能怪我們有「經常需要 “眼見為憑”,也希望能有具體的工具來協助呈現」的預期心理啦。 🙂

    順便提一下我當初參加 6/25 那場次的動機吧。

    該講座是隸屬於「UML2.0/EA 軟體設計系列講座」的第五場。看到這個總系列名稱,我預期這系列講座將不只是介紹 OO 軟體設計觀念,更會大量以貴公司代理的 EA 做為具體落實的手段。正好這陣子我在 survey 各大場的 MDA 佈局及現況,所以報名去觀摩一下。

    可惜當天,除了「Design Pattern 與 UML Tool 的結合」場次較合乎預期之外,「boundary design」場次並沒有很符合事先公佈的綱要第 2、3 兩點:

    1. Boundary Design
    2. 快速建構 Software Boundary
    3. 使用 Open Source 為範例實作

    當然啦,您講的 state diagram 也很精彩,只是我先入為主有了錯誤的預期。

    當天我本來也想留下來與您一聊,只是晚上還有事。

  3. Hi william:
    上次研討會沒看過您,後來透過 Tommy(一位戴眼鏡忠厚老實有與你聊那一位) 才知道您也有來,沒有與您交談,挺可惜的。

    1. 第一個問題是,您可以思考,透過各種 Tool Reverse 的機制,到底該Reverse “What”? 而那個 “What” 是值得設計人員該觀察的?
    程式碼是實做的產出,而,business level 層次,諸如您所提及的 business uc,涵蓋了設計者的思維,”something” 是無法被具化的,那並非是能透過 “工程化” 的機制就可以正向/反向 來達成的。

    2. 可能您會失望了,對於工具層面的操作,是由我們另一位 partner Ringle 來負責的,個人是比較少涉及至工具的操作面。

    至於,您所提及的軟體自動化的實作例,我個人是比較傾向以啟發性的方式來引導學員自我反思(這是在我們 UML 講座系列,個人的表達風格),而非往工具、how-to 的方向走。
    不過,畢竟,太多的人們經常需要 “眼見為憑”,也希望能有具體的工具來協助呈現。所以,您所提的這樣的現象,我會很希望能與一些 “實作面” 的高手(例如 Tommy)來配合,而會有更 “具體” 的產出來呈現。 🙂

  4. 問題是:以現在的 Together + JBuilder,有辦法 reverse 到 business use cases/business objects 層次嗎?

    現場會大量的 demo,而不是像 6/25 那場的 boundary design 和 state diagram 都缺乏軟體自動化的實作例。

    還在考慮要不要報名這兩場…

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *