四色原型四种角色如何交互呢？

直接问问题不太好，我写写我目前能写出来的代码，就举个维修电脑的例子吧。
首先是ppt电脑类:
package com.neu.edu.ppt;
import com.neu.edu.desc.ComputerDesc;
//ppt
public class Computer {
private String seriesNumber;
private float price;
private ComputerDesc computerDesc;
//省略get set方法 要不太长了

}

Desc类：应该是对电脑类的描述吧，不太确定
package com.neu.edu.desc;
public class ComputerDesc {
//型号
private String type;
//类型
private String form;
}

Role类：出毛病的电脑
package com.neu.edu.role;
public class ComputerMaintain {
private String bug;
}

MI：
package com.neu.edu.mi;
import java.util.Date;
import com.neu.edu.role.ComputerMaintain;
public class Maintain {
private Date maintainDate;
private String result;
//下面这个属性不知道应不应该包含？
private ComputerMaintain computerMaintain;
public String findReason(ComputerMaintain computerMaintain) {
return "";
}

public void maintainComputer(ComputerMaintain computerMaintain) {

}
}

现在就是有一个严重的问题，就是如何让电脑类Computer进入到角色（Role），然后完成电脑的毛病查找和维修。求大牛指点。先感谢了。真的太想学会四色原型了。大牛们帮帮我吧。

你很厉害，四色原型直接干出代码。

四色原型是对需求的一种分析，并不能一步到位映射到代码，特别是Java代码，映射到Scala或JS倒是有可能，也要结合DCI再进一步细化一下。

在静态语言中，可以在Role的构造函数(contructor)将PPT传入；或者将Role设计为事件监听器（Listener)，通过设值函数(setter)将Listener传给PPT。Role/Desc与PPT是相对独立的，静态方法的缺陷在于无论采用哪种方法，PPT或Role都有一个略显多余的字段，动态语言可以克服这一些缺陷，但仍不够完美，动态语言的灵活性缺失了静态语言的约束性。这需要平衡与取舍。

在《领域驱动设计之我见》一贴的后半部分，我使用自己的“四象图”（建模原语：模型、结构/状态特征、行为/功能特征、场景）来包容“四色原型”、“DDD"、"DCI”等割裂分析、设计、实现的方法论。

你的问题属于“凝聚特征”这一开放的课题，如果你熟悉GoF的设计模式，其7个结构型模式，都可以用来凝聚状态或结构特征；11个行为型模式，都可以用来凝聚行为或角色特征。比如事件监听器的基本思想与观察者模式如出一辙。

与“凝聚特征”相对应的“剥离特征”这一开放的课题，也值得探讨，我认为你上面“剥离特征”(Desc和Role)的思路就可能存在问题。剥离特征的基本思路有两个：一致性与交互性。“一致性”剥离“状态或结构特征”(Desc)，“交互性”剥离“行为特征”(Role)。

强调一下，特征凝聚与剥离属于开放的课题，不要局限于我上面的建议，尽管我认为这是思考的基本方向。事实上，特征剥离的思路不止“一致性”与“交互性”，特凝聚的方式也不止“结构型”和“行为型”的设计模式。

GoF模式缺少时间的概念，没有思考并行模式，其背后的世界观是“事物观”。而四象图这一方法论背后的世界观可以从“事物观”迁移到“事实观”，这要求四个术语的定义要回归到其数学描述上去，特征剥离的思路“一致性”与“交互性”仍然有效，但也有其它的方法，这里我就不再多论述。因为“事实观”(最早由uda1341提出的Fact-Oriented Programming)的普及程度远不如(Object-Oriented Programming)。

例子很简单，特征单一，凝聚的方式，就用简单的构造传参示意一下。注意我剥离特征的思路（一致性与交互性），这很重要，这个环节出错了，凝聚特征将失去基本的意义。代码是用普通编辑器编写的，可能出现拼写错误，而且这个例子的需求语义不够清晰，我只能想象补充一下，仅供讨论。

模型, 你可以理解四色原型的PPT

public class  Computer {     
	private String username;	
	private String boughtTime;
	private String price; 
	private String brand;      
	private ComputerConfiguration cc;
	// getter/setter
	public Computer(String username, String boughtTime, String price, String brand, ComputerConfiguration computerConfiguration) {
		this.username = username;
		this.boughtTime = boughtTime;		
		this.price = price;
		this.brand = brand;
		this.computerConfiguration = computerConfiguration;			
	}
}

结构特征或状态特征，你可以初步理解为四色原型的Desc

publilc classs ComputerConfiguration {
	private String cpu;
	private String keyboard;
	private String hardDisk;
	private String memory;
	private String motherBoard;
	private String monitor;      
	// getter/setter
}

行为特征或功能特征，你可以初步理解为四色原型的Role

public class ComputerInRepairing{
	private String reason;	// 哪里坏了
	private String orderNo; // 订单编号
	private String startTime; // 送来修理的时间
	private String endTime; // 修理完的时间
        private String chargedPrice;//收费价格
	
	private Computer computer;
	
	
	public ComputerInRepairing(Computer computer) {
		this.computer = computer;
		this.startTime = new Date();
	}	
       // getter/setter	
}

场景，你可以初步理解为四色原型的MI。

pubic class RepairComputer {
       private ChargeStrategy;  // 收费策略
       private String repairer; // 修理人

	public void repair(ComputerInRepairing computer) {
             // repaire the computer
             // charge to customer
	}

}

场景规约，你可以初步理解为DDD的Specification。

public class ChargeStrategy {
	public String repairHardDisk() {
              return "50$";
	}

	public String repairMotherBoad() {
             return "20$";
	}
 }

感谢banq大的回答O(∩_∩)O~
让banq见笑了，我看四色模型在分析需求的时候，写出来的4种颜色的模型，很像交互图里面的类，我就一个直接可以转化成java代码。现在我知道了四色原型是用来做需求分析的。但是四色原型分析完了该做什么呢，下面我就不知道了？是不是四色原型得出的相当于分析类呢？然后再在这个分析类的基础上，来确定最后要编写的类？但是我怎么感觉还是可以转化成java代码呢？就比如下面jdon007不就是写出来了吗。还是因为我这个例子比较简单，分析类Computer直接就是最终的了，所以才能写出来呢？

太感谢jdon007了，写了这么多。我看了3遍，学到了不少东西。下面总结下我的理解，不对的地方还请指点哈。

1.对于类和类之间的聚合关系原来我不太懂如何处理，现在可以使用设计模式中的7个结构模式来指导编程。

2.对于剥离特性，首先是一致性剥离，从ppt当中找到一致的状态(属性)和操作这些属性的方法，将他们剥离到新的Desc中，对于“交互性”剥离，我们就来找特征的行为，在这里就是坏了的电脑，它需要送去维修等的行为(新的电脑不用修，那是坏了电脑的事)。这样我们就能剥离出来一个坏了的电脑的角色Role。

以上的总结，我是首先确定PPT，然后扩展出来desc和role。不知道对不对。

修正一些错误。

模型, 你可以理解四色原型的PPT

public class  Computer {     
	private String username;	
	private String boughtTime;
	private String price; 
	private String brand;      
	private ComputerConfiguration computerConfiguration;
	// getter/setter
	public Computer(String username, String boughtTime, String price, String brand, ComputerConfiguration computerConfiguration) {
		this.username = username;
		this.boughtTime = boughtTime;		
		this.price = price;
		this.brand = brand;
		this.computerConfiguration = computerConfiguration;			
	}
}

结构特征或状态特征，你可以初步理解为四色原型的Desc

publilc classs ComputerConfiguration {
	private String cpu;
	private String keyboard;
	private String hardDisk;
	private String memory;
	private String motherBoard;
	private String monitor;      
	// getter/setter
}

行为特征或功能特征，你可以初步理解为四色原型的Role

public class ComputerInRepairing{
	private String reason;	// 哪里坏了
	private String orderNo; // 订单编号
	private String startTime; // 送来修理的时间
	private String endTime; // 修理完的时间
        private String chargedPrice;//收费价格
        private String repairer; // 修理人
	
	private Computer computer;
	
	
	public ComputerInRepairing(Computer computer) {
		this.computer = computer;
		this.startTime = new Date();
	}	
       // getter/setter	
}

场景，你可以初步理解为四色原型的MI。

pubic class RepairComputer {
       private ChargeStrategy;  // 收费策略       

	public void repair(ComputerInRepairing c) {
             // repaire the computer
             // charge to customer
	}
}

场景规约，你可以初步理解为DDD的Specification。

public class ChargeStrategy {
	public String repairHardDisk() {
              return "50$";
	}

	public String repairMotherBoad() {
             return "20$";
	}
 }

基本是这样的。此外，我还要强调一点，场景规约非常重要，这基本上是业务价值的体现。企业应用开发，场景规约一般是制定好的，所以只需要描述清楚即可。

而如果你是场景规约（协议）的设计者，那么场景规约将是重点，还可能是难点。

没有见笑，讨论讨论。分析和设计是战略和战术的区别，分析是判断向南向北，有木有的问题，战略是选择对的事情，战术是把事情做对。

四色原型侧重于战略，就电脑维修这个需求，我个人感觉好像你在套四色时不是完全对，也可能你没有把你套四色的场景角度说清楚。

如果说Role是黄色的帽子，那么PPT是戴帽子者，当然戴帽子的不一定是人(party)，可以是地方(place)或事情(thing)，比如一个建筑物这个地方可以扮演餐厅角色，也可以作为犯罪现场角色，；一个事情也可以扮演角色，如果你可以与之交谈交互，可以移动它，可以坐在它上面，站在上面。

电脑维修这个需求关键是谁去修，是电脑自己修自己，还是人去修的问题。

下午又回去琢磨了一下四色原型。现在属性的划分大致有一定的认识了，个人感觉方法行为是跟随属性在一起的。但是看到color uml书P11页的一段话，我就又开始糊涂了。

原话如下：
在架构性的特征中还包括方法。蓝色的描述架构性将确定对应的绿色的参与方-地点-物品的数额，找到可以获取的物品，计算可以获取的数量，计算明细的综合，列出对应的参与方地点物品。它有一些静态的类方法，目的是列出所有描述，并确定所有描述的数额。

现在有一个问题，现在desc被ppt所包含了，但是为什么得到ppt的方法等要放在desc中呢？我认为是不是应该放在另外一个地方，比如专门有一个仓储用来得到数据库中的数据，然后制造成对象？

书上下面的话和上面的基本一样（绿色的参与方地点物品确定它对应黄色角色的数额。），方法放的位置和我想的位置都不一样。请问这么放置方法有什么根据呢？

书中的原话：
An archetype’s characteristics include methods (Figure 1-7).
一个原型的特点是其包含方法。

A blue description assesses across its corresponding green parties, places, or things: finds available; calculates quantity available; calculates total for a detail (with quantity and unit of measure); and lists its corresponding parties, places, or things.
蓝色的DESC考量其相应的PPT：找到可用的PPT；计算可用的数量；计算详细的总和（包含数量和计量单位）；列出其相应的PPT。

It also has static class-level methods (underlined, with behavior across all the objects in the class) to list all descriptions and to assess across all description.
蓝色的DESC也有一些静态的类方法（值得强调的是，是类中所有对象共同的方法），列出和评定所有的描述信息。

英文原文看不出，“得到ppt的方法等要放在desc中”。可以看出的的是DESC描述和存取PPT的一些数量信息，对象级别的信息：比如每一本书的页数、章节数等；类级别的信息：比如总共有几本书等。

你引用的“原话”，翻译可能有问题，很难想象你竟然看懂了。最好看原文，我上面的翻译仅作参考，因为我的英文水平也很一般，勉强可以看一些简单的英文技术书籍。

“这个找到可用的PPT”这句话，我理解成了是desc从数据库中加载PPT(当然在考虑类的时候不应该考虑到数据库，就先假设是从数据库加载到的一个对象)。可能是这一点跟原文的意思有些出入吧，我认为加载应该是仓促(比如一个工厂类)来干的活。不知道您是怎么理解这个“找到可用的PPT”的，能举个例子吗？

就比如第二章那个物料资源部分(P32)的图，物料的desc向MalresSupplySource请求得到active的Supplier(Role)。这个地方我就总把这3个框框看成是java类，然后考虑代码。请问下他们之前如何转化呢。为什么我这么想有问题呢。最让我忍不住直接想成类的是，框框下面竟然有方法名(getActiveSupplier)。

总结下，现在遇到的问题就是，如何从四色图转化到实体类然后转化到代码呢？
[该贴被mistbow于2011-08-26 19:33修改过]

比如图书管有《Java Modeling in Color with UML》一书，DESC类中的描述可以有这么一个字段 boolean hasStock; // 判断是否还有库存，即找到可用的PPT(书）；也可以有boolean count; // 判断此书有几本，即计算可用的数量。

之前图书馆建模代码中的DESC只是个摆设，因为不重视，致使没有透彻理解，所以也没发挥其应有的作用。现在我觉得Book的DESC应该计成如BookCounter(boolean hasStock, int count) 类才有点意义。

建议了解“四象图”，四象图比四色原型具有更大的“理想”，其基本目标之一是作为“界面、领域、数据库的分析、设计、实现”的原语，指导这些工作的完成。这些工作是每个人都要了解或掌握的，四象图就是从这些工作中，提炼出的一套原语。

目前我使用这套原语指导这些工作，效率提高了不少。原语有不足之处，比如场景规约/协议部分将讲的不多，实际上这里头也大有文章（相当于剧本的编写）。现在我也有些基本想法，只是尚没有通过相对完整的代码案例来验证。企业应用开发，场景规约部分一般会比较简单一些，因为是现成的，不需要从无创造出来（发明或发现），只需要照着现实写即可。

原语的目标虽大，但操作起来却也易如反掌，一只笔，一张纸，一横一竖，四象图就画出来，然后你在四个象上画些画，写些字。拟完草稿、草图，打开编辑器，输入代码，修正一些错误，润色优化一下，工作就完成了一大半。看我的描述，程序员似乎变成了打字员，有点悲催呀。不过我们编程的目标不就是解放劳动力吗？我们为用户解放劳动力，就不能为自个偷点懒，解放一下自己的劳动力？

经您这么一说，真的想学习下。有什么资源吗？上google搜没搜到。