漫談「模式驅動架構」 (二)

作者：
CIM - PIM - PSM 樣式

在「漫談模式驅動架構」(一)中我們談到，OMG將MDA建構成CIM-PIM-PSM樣式，程式則由PSM轉換(transformation)而成，這是依照一種較合宜而方便的觀點(viewpoints)所形成的樣式，事實上MDA卻允許有其他的觀點，而產生其他的樣式，但CIM-PIM-PSM樣式的重點在於其提供「事務分離」的概念，因此我們仍然以大家接受的OMG樣式來漫談 ，實際運作時，該樣式可以延伸成CIM-PIM-PSM-Code 。

何謂CIM，CIM有時稱為「範疇模式」(domain model)或「業務模式」(business model)，用來描述業務系統，但本身並非軟體，這個模式表示系統的關鍵需求，以及描述問題範疇的字彙(vocabulary)，但不涉及系統的細節，一般物件導向系統分析方法就可用來建構這個模式，PIM就是依據這個模式而產生。

PIM是表示業務邏輯(business logic)的模式，這個模式顯示系統的工作內容，但不涉及與任何特殊技術平台(technology platform)的關係，如EJB，.NET或關聯性資料庫等，PIM類似OOA的分析模式(analysis model)但更為詳盡完整，每一種業務只有一種PIM。至於PSM則結合PIM所擬定的規格來顯示系統將如何在特殊技術平台上實作，因此它是由PIM轉換而來，程式則由PSM轉換而得。PIM，PSM與程式之間的轉換可以用人工，但一般皆使用MDA工具來擔任，因人工不但費時而且可能出錯。在此我們引用Booch等人的所謂「MDA宣言」(The MDA Manifesto)來支持這個觀點，宣言有三點：(1) Direct representation; (2) Automation; (3) Open standards，因篇幅關係我們不在此地詳談這三點宣言，因為自動化涉及MDA的運用甚巨，因此我們希望強調第(2)點 - 自動化轉換。以上說明對於不熟悉物件導向軟體工程的人士可能較為抽象，也許下圖(雖然不很完整)可以協助了解MDA的運作方式：

（點圖形放大）

圖中我們同時將MDA與傳統的發展過程做比較，兩者之間的生命週期差異不大，但MDA主要特點在於 PIM->PSM->Code的自動化轉換，保養是在PIM而不是程式，PIM是唯一代表業務邏輯的模式，可以轉換成多種PSM與程式模式(對MDA而言，程式也是一種模式)，這項特點影響到：
  • 發展者只要發展PIM而非撰寫程式，以提升生產力
  • 因保養在高抽象層次的PIM，因此保養較易
  • 加速反覆與漸增(iterative and incremental)週期，符合敏捷方法的概念
  • 因為改變模式相當於改變軟體，因此MDA方法可支持「敏捷軟體發展」(agile software development)，(我們將在下期漫談敏捷MDA)

當然自動化模式轉換須仰賴MDA工具，讀者如果想知道世界上有那些公司提供MDA工具，以及那些單位使用MDA成功的範例，可查看OMG的網站(http://www.omg.org/mda)。

屬人生「古來稀」族群，現在頭銜：國立中央大學資訊工程系(所)榮譽教授。謹希望借重「輕鬆談軟工」部落格讓學界、工商界以及具有決策權的官員注意軟體工程對各行各業的影響，進而重視台灣軟體工業的發展。

留言

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

從種樹小故事看流程改善

作者：
今天上課前突然想到一個故事，稍作改變後用來跟學生講解流程改善。 某公司聘用一個員工上種樹，他需要鋤頭挖洞，將樹植下，最後再用鏟子把地鏟平。以他的速度一天只能種十顆樹，比老闆預期的進度差太多，於是老闆又聘了兩個人來幫忙，速度提昇了兩倍。 [from work harder to work smarter] 但是這樣的速度還是不夠快，而成本又太高已經沒有經費在聘用員工，只好想辦法進行流程改善。他仔細觀察三個員工的工作方式，發現花在工具的抽換花了太多的時間。於是他重新更換了三個人的工作：A 只做挖洞的動作，B 隨後將樹植下, C 隨後在將地鏟平。這樣的工作模式可以省去更換工具的時間，更棒的是，每個人更能夠把自己的工作做的專精，效率又提高了兩成。 [但，小心成為官僚流程] 這樣的流程跑了很久，員工來來去去換了許多次，但都保持一定的高效率。一天，老闆去看工地，發現A 挖玩洞後，C 緊接著把洞補起來填平，老闆生氣的說：『你們在做什麼？B君呢？』 『喔，他今天請假了』A 說。 最後這個笑點看似誇張，但在企業流程卻常見。許多人習慣了只知道follow 流程去做，卻不之所以然，所以很容易鬧出笑話。另一方面企業也常常不重視流程的教育訓練，所以常常空有好流程卻無法發揮最大的效用。
閱讀完整內容