前言
我們搞技術的有很多誤區，比如經常陷入純技術鉆牛角尖的爭辯，而全然不顧業務場景，技術活做太多，經驗一籮筐，但是有時會疑惑，這些經驗是否適合其他自己沒有經歷過的新系統呢？我們在技術設計路線上走得太久，容易迷失方向，什么是設計不足；什么是過度設計，如何把握這個度？
在對待項目上，有一種極端是認為每個項目都是特殊的，不可能和其他項目有共同之處；這算是一種經驗主義吧。 甚至有些程序員唯大項目不做，認為只有大項目才能鍛煉自己，做過大項目的認才是牛人。
這些誤區都是因為我們軟件基礎知識的缺失，沒有人告訴我們，大小不同項目是否有共同點？ 我們現在做的項目需求是處于所有項目需求領域中何種位置？為滿足這個業務需求我高質量高效率完成了這個軟件系統，那么在這個軟件系統中體現的解決方案是否適合其他項目中其他類似的需求呢？
以前，通過設計模式我們已經完成了設計上重用，再通過重用框架，可以更高效粒度高大地更高質量地實現大部分系統， 但是，看上去同一個業務需求，在不同的項目，每次還是需要我們對這些框架進行重新組織設計，哪怕它們有些相同之處， 例如： 在電子購物系統中有商品和用戶兩種重要元素，商品本身是一個物，而且可能有層次類別區分；商品和用戶必然發生關系；在論壇系統中也存在帖子和用戶兩個元素，帖子是一個物，本身也有 類別區分，每個帖子必然和一個用戶發生聯系。這兩個系統使用J2EE實現，當我墻薪７治鍪�，发现彼此之间隐约有一些共同之处。緡撳架构时又粠V婕暗獎硐植�、业伟d愫統志貌閔杓�，两諊`負醵伎梢允褂孟嗤募芄谷紓⊿truts+Jdon+Hibernate） 等等。
那么，能不能省卻我們在每個項目上都會這些類似相同的需求重新再做一次設計架構呢？如果設計模式重用是針對一個具體設計場景而實現的重用，現在我們幾乎不再滿足這種細粒度的低效重用效率，如果我們能抓助軟件源頭：業務需求，總結出某一類問題的共同之處，那么與之相聯系的整個解決方案 也許就能夠得到重用，這種重用粒度更大，從而更高帶來開發效率。
但是，有一個問題：不同項目的業務需求之間到底是否有共同之處？大項目和小項目的業務需求是否有共同之處？ 我們每做一個項目，是否可以達到一葉知秋的效果呢？
業務需求在我們軟件系統一般用Model來統指，筆者曾經提出：域建模、模式和框架是Java軟件的三個大方面， 其中域建模起著關鍵龍頭作用，如何分析業務需求，如何實現正確的類圖（建模）表達，是決定整個系統成敗所在。更有這樣的觀點：No model,no patterns ,then no framework Model代表業務場景，沒有業務需求，就沒有設計模式，也沒有框架。
幾年前誕生的MDA是在這個方向進行了探索，很多先驅大師更在這方面進行了理論探索，如果說OO是對現實世界的一種抽象，那么MDA是比OO更加抽象的一種技術或方法論�！拔覀冊谝粋�軟件革命的開始，它象90年代我們看到的面向對象編程從傳統過程語言中抽象出來一樣�！�
原型archetypes
原型一詞來自于希臘語archetypo (arcetupo), 意味著 "original pattern." （原始模式）
比如英雄這個原型在美國或在中國看上去可能不一樣，但是英雄就是英雄，我們還是能夠很快地總結出英雄的一些特點。 因為原型是人類組織、總結和概括客觀世界的基本概念，我們完全有理由在軟件開發領域應用這些概念。
業務原型business archetypes
OO軟件系統是對業務領域（business domain）的思考抽象并進行管理操作，注意業務領域這個概念，我們相信應該能在業務領域中發現原型，或者在軟件系統；或者這些系統模型中。我們稱這種原型類型為業務原型（business archetype）
一個業務原型應該是一個在業務領域或商業軟件系統持續發生并且普遍存在的最初級的事物。
Party是一個業務原型例子，一個Party代表可標識的、可定位的單元或單位，這些單位有正常的 狀態。 通常一個Party用來表示某個人或某個組織。所有商業系統都或多或少有Party概念。
原型之間是相互交互的，Party, Product, 和 Order是每個虛擬商業系統的基本概念，在這個商業系統中，你可以賣產品或服務。我們將這些原型之間的協作看成是業務原型模式(business archetype patterns).
業務原型模式business archetype pattern定義：它是在業務領域或商業軟件系統持續發生并且普遍存在業務原型之間的協作。
原型（Archetypes）和分析類（analysis classes）區別
分析類（analysis class）是代表問題域中一種即時抽象，它對應真實世界的業務概念。
設計類（Design class）是一種達到可以實現程度的類。分析類是用于理解業務；而設計類用于理解技術解決方案，例如設計模式。分析類是從問題域（業務需求）中提取的，并沒有具體實現特點； 而設計類包含來自問題域（業務需求）和解決域（e.g., J2EE, .NET, or Web services）的特性， 從設計模式的使用特點可以了解這些，有人曾經單純拿出一段if else語句，而不考慮問題域； 就試圖使用某個模式替代這段if else，這就是因為他沒有認識道設計類的這個特點。
原型總是比正常的分析類更加抽象，屬于位于目前抽象層次的更高端，因此，通常原型模式可以生成一個或多個分析類。
原型模式和分析模式的關系怎樣，原型模式是分析模式嗎？不是，從定義范圍上看，原型模式有很多特性看上去要比分析模式多。分析模式是首先由Matin Fowler提出并定義如下："分析模式是一組概念，這些概念代表業務建模中一個普遍的構建，它也許和一個域相關；或跨越多個域。 其中并沒有任何原型的概念。
原型模式比分析模式要更加豐富，體現以下幾點：
原型模式可以使用UML來表達（Together中可以實現）； 原型模式可以作為一種平臺獨立Model（PIM）適合MDA開發流程； 而這些分析模式則都不可以。
四色原型
四色原型是誕生于90年代，現在被廣泛使用的一種系統分析方法，如Borland的Together架構師版，準確地說，是由Peter Coad 和 Mark Mayfield首先提出[Coad92],然后由David North拓展[Coad95-97]
- moment-interval
- role
- catalog-entry-like description
- party, place or thing
前面已經說過，域建模是整個軟件系統的龍頭，在現代Java技術如JiveJdon3.0開始之前，我們都是需要領域建模，也就是在UML中畫出類圖，然后標記上類圖四種關系（關聯、依賴、繼承和實現），但是這些只是UML圖的表面，只是一種畫圖技巧，就象CAD畫圖一樣，你可能沒有被告知：這個類圖是怎么出來的？為什么選用關聯而不是依賴，這些實際都屬于分析領域的知識，而四色圖可以說為我們這種分析提煉提供了一種模板或分析框架，這樣我們可以按圖索驥去分析每個陌生的系統，我們擁有強大的分析方法工具。
moment-interval archetype
這是一個很重要的原型，重要在于時間概念上：某個時刻(moment)或一段很短時間(interval)內. 意味在某個時刻發生的事情因為業務要求或合法性原因需要跟蹤；或者過一段時間以后，應該是很短的時間，可以幫助我們尋找到它。
賣東西是在某個時刻發生的，它有發生日期和時間。租賃行為是在一段時間內發生，從開始出租和歸還所租物品；預定也是持續一段時間，什么時候預定；什么時候過期等。
這些我們都使用moment-interval原型來表達，UML圖如下：
Moment-intervals是和組件模型捆綁在一起，代表了組件模塊關注的核心和靈魂，在一個Model中，Moment-intervals經常封裝的是最關鍵的方法，為讓其顯目，moment-interval的UML圖我們使用粉紅顏色表示。在代碼上用@標識符標識：
/** @archetype moment-interval*/
public class Sale {
public BigDecimal calcTotal(){
}
private int number;
private Date date;
}
在任何領域中，我們都能尋找moment-intervals原型并且開始建模，在原材料資源管理系統中，我們可以這樣對待從報價單（RFQ）到購買訂單（PO）直至發票，在一個制造管理系統中，我們也就可以將一個計劃的過程和步驟分析到實際過程和詳細步驟。
原型在幫助指導建模方面一個有效方式是：它能標識那些被包含在Model模型中的類（Classes）以便于區分，原型不只是簡化了類的區別；原型還可以區分類的行為職責（responsibilities），例如類的屬性，方法等。
role archetype
角色原型比較容易理解，任何一個系統都需要人或某個組織介入運行，例如論壇系統需要注冊者角色發言；銷售訂單需要業務員角色制定，等等。
這里有一個Party原型定義：它表示一個可標識、可定位的單元，這個單元有自己正常的狀態并且能夠自主控制自己的一些行為，通常情況下，人或組織是一種Party，但象護照，身份證等注冊性標志等都可以作為Party。
注意，并不是說Party或人或組織就是Role原型，必須Party或人或組織參與一種活動后才為角色，就象張三在電影中表演皇帝，他只有參與電影表演才是皇帝角色；李四在XX公司的角色才是經理，他只有參與這家公司運作才是角色經理；否則他們只是一個Party原型。
所以，Role角色是Party扮演的（a role that a Party plays），Party是角色Role的扮演者（role-player）。
當我們在建模時，對于一個角色扮演者，可以有他自己的核心屬性如名稱、年齡（以人為例子），也可以有與業務相關的方法，比如一個小店，當店老板去收錢時，他的角色就是收銀員（cashier），此時可以將與收銀員角色相關業務特點加于其上；當然，同時他也可以是老板（Owner）角色。那么下圖中authorizedFor方法就是參與每個角色的行為，當他作為某個角色被授權登錄后，與此角色相關的業務特點就應用在他身上。
大家已經注意到了：角色原型在UML中是使用黃顏色標識的。角色模型是第二重要的原型，所以使用黃色。
我們已經知道，Party是一個又自主行為、能夠控制自己行為的表示，如人或組織，還有其他沒有自主行為的表示，也就是某個地方或位置或某個事情，我們一般稱( place, or thing)，不但Party可以成為角色，而且 place或thing也可以成為角色，比如，一個商品Product可能又兩種角色：在銷售過程中商品；正在使用的商品。
party, place, or thing archetype
上面我們說過，party place或thing都可以成為角色原型，注意到角色原型中的UML圖，party圖是以綠色表達。
Party表示有自己正常的狀態并且能夠自主控制自己的一些行為，通常情況下，人或組織是一種Party，但象護照，身份證等注冊性標志等都可以作為Party。
Place or thing表示一樣不會說話沒有行為的東西，例如商品，當然這個商品可以扮演不同角色，既可以是零售的一個電源插座；也可以批發系統中的一個電源插座，它是被賣的，可能在不同業務系統被賣的方式不一樣。
description archetype
種類description原型其實是第三重要的原型，一般情況下，它類似目錄級別catalog-entry-like的種類，例如某個商品電源插座屬于家用電器這個種類，當然家用電器又屬于電器這個目錄，是一個樹形的目錄結構。例如論壇中帖子和回帖之間也是一種種類原型。
比如你的紅色�？怂故歉Ｌ厣a的一輛轎車，它有車牌號、購買日期、顏色和里程表等，這些代表Thing原型，那么作為轎車這個種類來說，它有一些種類屬性，例如：生產廠家、生產批號、適用顏色等，這些屬性是轎車這類所有車輛都共有的。
在設計模式這個實現級別，我們通常使用組合模式來實現種類原型。
Description原型在UML中使用藍色表達。
四色原型圖
每個原型圖有屬性和連接（關聯 依賴等關系）兩個部分組成。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
