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

11-08-25 mistbow
四色原型的帖子基本都看了一遍,COLOR UML那书也看了一些。感觉还是迷糊哇。哪位大牛可不可以再讲讲四色是怎么设计的啊,虽然知道是什么人在什么地方做了什么事,但是它们之间如何交互还是不太了解,求大牛解惑啊。急切等待大牛的回答55555。最好有点代码这样能好理解些。嘿嘿

2
mistbow
2011-08-25 21:41
直接问问题不太好,我写写我目前能写出来的代码,就举个维修电脑的例子吧。

首先是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),然后完成电脑的毛病查找和维修。求大牛指点。先感谢了。真的太想学会四色原型了。大牛们帮帮我吧。

banq
2011-08-26 09:48
你很厉害,四色原型直接干出代码。

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

jdon007
2011-08-26 09:55
2011年08月25日 21:41 "@mistbow"的内容
就是如何让电脑类Computer进入到角色(Role),然后完成电脑的毛病查找和维修。 ...

在静态语言中,可以在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;			
	}
}
<p>

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

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

行为特征或功能特征,你可以初步理解为四色原型的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	
}
<p>

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

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

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

}
<p>

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

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

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

[该贴被jdon007于2011-08-26 10:38修改过]

mistbow
2011-08-26 10:57
感谢banq大的回答O(∩_∩)O~

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

mistbow
2011-08-26 10:59
太感谢jdon007了,写了这么多。我看了3遍,学到了不少东西。下面总结下我的理解,不对的地方还请指点哈。

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

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

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

jdon007
2011-08-26 11:02
修正一些错误。

模型, 你可以理解四色原型的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;			
	}
}
<p>

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

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

行为特征或功能特征,你可以初步理解为四色原型的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	
}
<p>

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

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

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

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

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

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

jdon007
2011-08-26 11:07
2011年08月26日 11:02 "@jdon007"的内容
我是首先确定PPT,然后扩展出来desc和role。 ...

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

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

banq
2011-08-26 11:21
2011年08月26日 10:57 "@mistbow"的内容
让banq见笑了,我看四色模型在分析需求的时候,写出来的4种颜色的模型,很像交互图里面的类,我就一个直接可以转化成java代码 ...

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

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

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

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

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

原话如下:

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

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

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

jdon007
2011-08-26 18:43
2011年08月26日 17:15 "@mistbow"的内容
现在有一个问题,现在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的一些数量信息,对象级别的信息:比如每一本书的页数、章节数等;类级别的信息:比如总共有几本书等。

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

mistbow
2011-08-26 18:50
2011年08月26日 18:37 "@jdon007"的内容
蓝色的DESC考量其相应的PPT:找到可用的PPT;计算可用的数量;计算详细的总和(包含数量和计量单位);列出其相应的PPT。 ...

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

mistbow
2011-08-26 19:32
2011年08月26日 17:15 "@mistbow"的内容
分析和设计是战略和战术的区别,分析是判断向南向北,有木有的问题,战略是选择对的事情,战术是把事情做对。 ...

嗯,受教了。再请问一个问题,我现在已经设计出来一个四色原型,那么之后我如何才能转化成代码呢?现在看color uml这本书,总忍不住把这彩色的小框框想想成java的类。

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

总结下,现在遇到的问题就是,如何从四色图转化到实体类然后转化到代码呢?

[该贴被mistbow于2011-08-26 19:33修改过]

jdon007
2011-08-26 20:48
2011年08月26日 19:32 "@mistbow"的内容
找到可用的PPT ...

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

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

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

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

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

mistbow
2011-08-26 21:23
2011年08月26日 20:48 "@jdon007"的内容
建议了解“四象图”,四象图比四色原型具有更大的“理想”,其基本目标之一是作为“界面、领域、数据库的分析、设计、实现”的原语,指导这些工作的完成。这些工作是每个人都要了解或掌握的,四象图就是从这些工作中,提炼出的一套原语。 ...

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

猜你喜欢
2Go 1 2 下一页