原型基本概念

板桥里人 https://www.jdon.com 2006/2/12（转载请保留）

前言

　　我们搞技术的有很多误区，比如经常陷入纯技术钻牛角尖的争辩，而全然不顾业务场景，技术活做太多，经验一箩筐，但是有时会疑惑，这些经验是否适合其他自己没有经历过的新系统呢？我们在技术设计路线上走得太久，容易迷失方向，什么是设计不足；什么是过度设计，如何把握这个度？

　　 在对待项目上，有一种极端是认为每个项目都是特殊的，不可能和其他项目有共同之处；这算是一种经验主义吧。 甚至有些程序员唯大项目不做，认为只有大项目才能锻炼自己，做过大项目的认才是牛人。

　　这些误区都是因为我们软件基础知识的缺失，没有人告诉我们，大小不同项目是否有共同点？ 我们现在做的项目需求是处于所有项目需求领域中何种位置，为满足这个业务需求我高质量高效率完成了这个软件系统，那么在这个软件系统中体现的解决方案是否适合其他项目中其他类似的需求呢？

　　以前，通过设计模式我已经完成了设计上重用，现在通过重用框架，几乎更方便地更高质量地实现大部分系统， 但是，看上去同一个业务需求，在不同的项目，还需要我对这些框架进行组织设计， 例如： 在电子购物系统中有商品和用户两种重要元素，商品本身是一个物，而且可能有层次类别区分；商品和用户必然发生关系；在论坛系统中也存在帖子和用户两个元素，帖子是一个物，本身也有 类别区分，每个帖子必然和一个用户发生联系。

　　这两个系统使用J2EE实现，当我们进行建模分析时，发现彼此之间隐约有一些共同之处。具体架构时又会涉及到表现层、业务层和持久层设计，两者几乎都可以使用相同的架构如（Struts+Jdon+Hibernate） 等等。

　　那么，能不能省却我在每个项目上都会这些类似相同的需求重新再做一次设计架构呢？如果设计模式重用是针对一个具体设计场景而实现的重用，我们几乎不再满足这种细粒度的低效重用效率，

　　如果我们能抓助软件源头：业务需求，总结出某一类问题的共同之处，那么与之相联系的整个解决方案 也许九能够得到重用。

　　不同项目的业务需求之间到底是否有共同之处，大项目和小项目的业务需求是否有共同之处？ 我每做一个项目，是否可以达到一叶知秋的效果呢？这样，才能用我有涯生命博取无涯知识彼岸！

　　业务需求在我们软件系统一般用Model来统指，我曾经提出：域建模、模式和框架是Java软件的三个大方面， 更有这样的观点：No model,no patterns ,then no framework Model代表业务场景，没有业务需求，就没有设计模式，也没有框架。

　　几年前诞生的MDA是在这个方向进行了探索，很多先驱大师在这方面进行了探索，其中本人推荐 Building Better Software with Archetype Patterns and UML一书更具权威，和GOF设计模式同等重要，如果说GOF设计模式开辟了OO对象设计新时代，那么这本书将开辟后十年的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开发流程； 而这些分析模式则都不可以。

四色原型

　　由Peter Coad 和 Mark Mayfield首先提出[Coad92],然后由David North拓展[Coad95-97]

  1. moment-interval archetype
  2. role archetype
  3. "catalog-entry-like description" archetype
  4. "party, place or thing" archetype.