利用『原型樣式』快速發展軟體

作者：
「所有具優良結構的物件導向軟體架構，其內部都充滿樣式(patterns)」，Grady Booch這句話乃是提供本人寫這篇輕鬆談的動機。其實，在各種行業中，製作複雜系統時樣式往往扮演重要的角色，由樣式所建構的軟體具有彈性、模組化、可重用以及易解的特性，軟體系統如具有這些特性則不旦能夠符合需求，而且能夠輕鬆反應需求變更，我想這種軟體應該就是品質好的軟體。樣式有許多類型，如分析樣式(analysis patterns)，架構樣式(architectural patterns)，設計樣式(design patterns)，程式樣式(idioms)，或「原型樣式」(archetype patterns)等等。本文所要談的是，原在『漫談「模式驅動架構」(二)』中所設計的MDA過程(CIM->PIM->PSM->Code)，我們將利用原型樣式改變成為：

選用業務原型樣式->產生PIM->自動化轉換成PSM->自動化產生程式

CIM則成為選用適當原型樣式的指引，這個過程的重點在於PIM的產生，適應原型樣式產生的PIM比一般標準的物件導向分析與設計(OO analysis & design)快速而且簡單，符合敏捷精神。本文約略來談談利用「原型樣式」快速發展軟體。

何謂原型(archetype)？有多種定義，這裡所談的原型是指「一種原始的(primordial)事物或環境，這些事物或環境前後一貫地重覆發生，而且被認為具有普遍性的觀念或狀況」，如果這些事物或環境是指業務範疇與業務軟體系統，則稱為「業務原型」(business archetypes)，業務原型之間的合作(collaborations)則稱為「業務原型樣式」。Jim Arlow與Ila Neustadt提供9種業務原型樣式，包括：Party，PartyRelationship，CRM，Product，Inventory，Order，Quantity，Money，以及Rule等業務原型樣式，這些原型樣式皆重覆發生在業務範疇之內，你/妳可以現用或經修改這些原型樣式來建構分析模式，這種技術稱為 「元件基塑模」(component-based modeling)。我們利用經修改的Order原型樣式發展Order Processing System範例，這個範例登載在Journal of Software Engineering Studies Vol. 2, No. 1, March 2007, Section 6，為節省部落格篇幅不在這裡重述，有興趣的讀者可觀看軟體工程學會網頁：

http://jses.seat.org.tw/index.php/jses/articale/view/34/22

有關樣式，一般人比較熟悉的可能是架構樣式與設計樣式，光看這篇報導也許不太容易了解所謂原型樣式以及其應用，讀者如果具備物件導向知識可參考：Jim Arlow and Ila Neustadt, Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, Addison-Wesley, 2004。我個人認為利用原型樣式產生PIM，迅速而且簡單，可以縮短發展過程並且保證品質，因此提供讀者這篇輕鬆談參考，希望因此對這種「另類」發展軟體應用系統方法產生興趣。

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

留言

張貼留言

這個網誌中的熱門文章

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
閱讀完整內容

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) 式兩種表示法。採用連續表示法
閱讀完整內容

談談OCP

作者：
圖片
看到「好人難為」一文，主角是一位專班學生，看來他似乎很委曲，因此我在意見箱內提議，他可以好好研究一下軟體設計的第一原則：Open-Closed Principle (OCP)，或許可以解決他的困擾，這件事涉及到軟體工程的教育與訓練的問題，也就是說，學以致用的問題，因此有必要寫一篇短文以OCP為例，來談談軟體設計原則的運用，這些原則並非軟體發展的食譜(cookbook)，而是發展者必須放在心裡的「指引」(guideline)，這種指引必須落實成為diciplines，其他如設計樣式(design patterns)也具有指引特性，因此才能廣泛運用，也就是說，可以重覆使用(reuse)，學習時最好蒐集一些範例，可能有助於這些設計原則或樣式的運用，有如念法律的人必須研究一些判例一樣，學習軟體發展方法時也不例外。 OCP是物件導向方法的核心，1988年由Bertrand Meyer在他的著作" Object-Oriented Software Construction "一書提出，它是說：「軟體實體必須能夠延伸但不能修改」(Software entities should be open for extension but closed for modification)，換言之，必要時可以延伸軟體實體的功能但不必修改它，該軟體實體可以是類別、模組、功能、程式、或組件，完全看你用在何處。Meyer的原意是說，類別實作(或程式)除了須要除錯外，如要改變功能或增加新功能時不得改變父類別(superclass)，而由子類別(subclass)來達成，子類別可以利用繼承(inheritance)機制重用父類別的屬性或作業元，但可改變或增減其功能，因此繼承不旦可以重用父類別的實作，同時可以延伸原功能，該子類別的介面可以異於父類別的介面，這是一般具有物件導向的人所熟悉的繼承機制。 到1990年代OCP被重新定義為，新介面可以繼承自「抽象類別」，但非繼承實作部分，原介面不得修改，也就是說，你設計的組件或模組不能改變，當需求改變時，你可以增加新程式以延伸該模組的功能，但不能改變你也許認為十分完美而能作業的原程式，請看下圖(R.C. Martin)， 左邊圖形表示，如果Client想使用另一個Server時，Client必須改變，因為兩者皆是concrete，這樣就不
閱讀完整內容