輕鬆談軟工

從7月份起，我陸續發表了3+1篇有關MDA的介紹文章，其中+1這篇是：『利用「原型樣式」快速發展軟體』一文，對於這種快速發展軟體的方式可能一般人不太熟悉，但無妨。對於這幾篇MDA相關的文章，讀者反應卻十分冷淡，可能與文章的內容有關，其實我盡可能不談理論，只談一些觀念與技術。這一篇「MDA續篇」仍然不涉及太多的理論敘述，但仍然無法避免，我盡可能平述基本理論概念。我假設讀者已看過3+1等四篇文章，對於MDA的輪廓諒有所了解，這篇文章希望補充一點MDA的基本原理。 MDA的基本原理： 下圖顯示MDA之所以可用的原因。 (點選放大) 圖中，除CIM->PIM的轉換須依賴人工技巧之外，其他模式轉換通常可借助工具來作業 (註： M2M = Model-to-Model，M2C = Model-to-Code)。對於MDA而言，模式間的轉換有重要的意涵，就是在較高抽象層次(abstraction level)作分析，也就是建構PIM，設計的抽象層次較低，程式的產生更低，從高抽象層次轉換到低層次的作業則盡可能借助自動化工具(理由已如3+1文章內所述)，例如M2M以及M2C則自動化轉換，這種不同抽象層次的作業完全符合所謂「事務分離」(separation of concern - SoC)的架構法(architectural approach)，SoC可以讓業務分析者集中在業務邏輯的分析與設計而不必考慮系統的細節，簡言之，分析者只要管好(包括發展與保養)PIM即可，為達到這種SoC，OMG因此定義不同抽象層次的觀點(view)，即CIM、PIM、PSM、與Code (OMG的MDA樣式並不包括Code)。 MDA是軟體發展的一種骨架(framework)，因此適用於你所使用的任何軟體發展方法，例如你可以用傳統的分析與設計法，或敏捷模式化(agile modeling)，或+1文章內所談的「原型樣式」(archetype patterns)來描述CIM與製作PIM，所以不用改變你所學的東西，就如Grady Booch所說的：公司要訓練MDA專家並無困難，也就是說只要懂一點UML而且仍然可保持所學，以減低訓練費用，同時，使用MDA技術尚可加速ROI。(註：最近有人提議使用OMG最近所提供的Business Process Modeling Notation (BPMN) 來描述C

物件導向設計是近十年來軟體工程很重要的課題，除了物件程式設計的技巧、方法論、設計流程以外，工具也是相當重要。在Rational Rose 被IBM併購之前我就使用過它的 UML 設計工具，當時它是我電腦的必備軟體之一，因為不只是上課、做系統需要，我甚至會用它來做一般事務的知識管理。 但隨著UML的快速改版，Rose的改版速度也相當的快，不僅如此，價格飆升也相當的快，快到我追不到。於是，我開始改用open source的一些方案，例如 ArgoUML以及在 Eclipse 上的UML。然而，這些系統的穩定性都不夠。後來，在資訊處中開始使用搭配 power builder 的 power designer，雖然功能與穩定性不錯，但推廣的狀況卻不是很好。 這幾年的感覺是，不要太拘泥於軟體工具的選擇，應該回歸到設計的本質， 其實紙筆就是最好的工具，相互討論就是最好的方法論 。軟體工具採用反而造成相互討論的困難，對設計造成傷害。一群人圍在圓桌上討論設計圖才是最重要的。 用紙筆做UML的設計還是有技巧的。過去我劃類別圖時先劃上一個像『目』的圖案 -- 其中最上面的格子寫上類別名稱、第二個格子寫上屬性、第三個格子寫上方法名稱 -- 但這個方法不好。因為屬性與方法的個數會在討論的過程中不斷的新增，所以固定大小的『目』造成了許多的不便。如左上圖的『F』則保留討論上的彈性，你可以在討論的過程中不斷的加上屬性與類別名稱，且名稱的長度也不會受限。直到你的設計告一段落（例如討論好一些 sequence diagram）才將F關住，成為『目』。 我特別將『F』設計成一個圖形，藉此，傳達軟體設計上『互動』、『敏捷』、『慎重』的重要性。工具依舊是重要的，但在設計初期的時候。我還是強烈的建議使用紙筆來做腦力激盪。

最近景氣不好，許多公司的MIS部門開始接受到上級的指示，把部門內的產品做一些包裝拿到外面去賣。賣不好，部門的人事可能就得精簡。這對MIS部門的確是晴天霹靂，景氣好的時候公司需要大量的電腦化支援，所以雇用了不少的人，現在人力過剩也是事實，只好硬著頭皮來賣產品。 但是從支援部隊轉換為賺錢部隊並不是一件容易的事，個人認為需要考慮幾點。從  開發者   來看，應考慮幾點 心態調整。 過去的MIS主要以支援為主，不是主要的生產部隊，績效的評估從模糊的『服務績效』變成明確的『獲利績效』。MIS人員是否做好了心理準備？ 面對客戶 。過去MIS人員僅要面對自家公司的人員，自己人好說話，軟體有bug也可以互相容忍一下; 或者是習慣性的接受同公司的任何修改請求。現在必須全新的體認開發者與客戶之間的商業關係，制度化的客服與變更流程顯得更重要。 在產品方面，或可從下面幾點來看： 產品的獨立性 。MIS 所開發的產品通常並不完全，而是搭配其他購入的產品共同存在（所以MIS人員的職責有一部份就在於整合自家產品與商業產品）。顧客要的是一整套的解決方案，而不會單一的產品，所以你得與商業產品搭配一起販售，這時候利潤的計算與分配、甚至於是合作模式都需要好好的計畫。 企業機密 。MIS所開發的產品多半伴隨著企業邏輯，應該要考慮企業機密的問題。如果企業的弱點或漏洞隨著產品一起出去，讓競爭者有機可乘，便倒賠了一把。 產品的品質 。 為了配合公司的業務流程，MIS所開發的系統多半是修修改改的，架構、功能、實作方法都相當複雜，若要當成產品來賣，恐怕得好好整理一下。 在管理方面應該考慮 產品或專案 。MIS主管可能會有這樣的誤解：A公司與我們業務相同，我們可以將我們的產品直接或微幅修改後賣給他們。在這樣的狀況下，產品的價格會壓的很低。殊不知每個公司都有自己的文化、作業流程，軟體系統移植後一定需要很多的修改，成本一定不會太低。也就是說，主管所認為可以大量直接販售的產品其實是一個誤解，應以專案的方式進行。所以專案管理的能力得重新訓練才行。 組織調整。 需不需要將開發團隊由原有的MIS部門切割出來？切割的好處是MIS可以專心的服務原有公司，不需要為業務煩心。但原有系統的設計是分散在所有員工的腦袋中，要做清楚的切割的確有困難度。如果沒有切割開來，就得避免MIS員工在服務與客戶之中迷失，不能因為重服務而失了客戶，也不能因為