GEF源码分析（六） GEF 的EditPart的职能分离 __ 跨国时尚媒体集团广告部门 的故事 二

GraphicalEditPart先生当天安排了部门及会议计划。经过EditPart部门紧张有奏的准备会议讨论的资料，第三天、按时8:30开会。

GraphicalEditPart先生还如往常，准时提前5分钟坐在会议室前边角上。他喜欢部门的小伙子们，虽然这些小伙子们做事情时常有些不周，但是他更欣赏他们的活力和富有创造激情。所以、每每开会时，他更愿坐在旁边听这些小伙子们的意见，“相比较当个威武的军队长官，我更意是一个严格又和蔼的优秀教练”GraphicalEditPart先生常常如此提醒自己不要越俎代庖。

部门干将小李主持会议，简短阐明会议主题和要求后，（为了提高会议效率会议每人最多5分钟发言，最后20分钟讨论时间，5分钟GraphicalEditPart先生做总结）。

小王首先站起发言：“目前我们EditPart部门，虽然，主要任务有明确定义，但是内部的工作流程不明确，没有可依章程。...”。

“是呀，公司目前还没有我们部门的标准操作手册，很多问题都有很大随机性，工作的好坏过于依赖人员本身的工作能力，这十分不利于人员的内部流动以及新人员的补充”我们的GraphicalEditPart"教练"满意的点点头。

小魏起来补充一下：“由于我们内部每个人的做事方法，都是各有一套绝活，流程不一致，经常导致在工作对上下层通知协作出现问题。在水平部门沟通时，也常常不流畅”。这是个大学刚毕业十分活泼的小姑娘。

“为什么大家总是觉得女的职员不好，看多有灵气的一个小姑娘呀，又是个好苗子。”GraphicalEditPart"教练"此时内心中的自我形象简直就是华佗再世，那感觉真有点飘飘然乎，GraphicalEditPart先生不由自主地晃了晃脑袋。

接下来其它人纷纷发言：

“工作经验很难相互交流，积累与提高。很难在部门级对工作流程等进行优化，缺乏专业化。”

“我们经常要和Figure部门一起工作，跟踪操作执行。这很是浪费工作时间，尤其是当某个工作需要很长时间，或者中间经常需要和客户交流反馈一段时间，这样非常影响工作效率。”

“对于客户的问题很难快速根据现有的经验模式形成解决方案，虽然我们公司服务态度和广告质量高于其它公司，但是经常由于反应速度太慢，活被其它公司从中抢了去，销售部门常常抱怨我们部门速度太慢。”

“公司在相应客户需要操作过程中，很难针对客户某个需求重新调整。客户常常抱怨在制作过程中很难做些小的改动。”

……

由于GraphicalEditPart先生管理小师的带领，EditPart部门的会议总是简短有效。1个小时多几分钟大家都把问题简明扼要的表达出来。

小李环顾下四周“最后，由GraphicalEditPart部长总结一下今天的会议”。

一直沉默的GraphicalEditPart先生站了起来，十分精神，也环顾了一下四周，清了清嗓子。

“首先、我要自我检讨一下，这一年多总是忙乱于紧急的小事情当中，很久没有收集大家的建议和反馈了，这十分不利于我们部门的发展。今天大家举出很多目前部门的问题，这些充分反映了大家对部门的业务熟悉程度，我相信，这是因为大家十分关注公司的未来，希望公司越办越好，而不是怨天尤人的牢骚，可能有些领导会觉的这是找毛病对领导不满，在我这里，我今天在一次明确表明，我十方鼓励大家，欢迎大家将一些意见反馈给我，希望大家不仅仅是简单反馈在工作中的直接困难，而且经过自己的思考提炼写成简洁的文书给我，最好发挥自我主动和创造性提出一些变革建议。这些东西将是我们部门及公司潜在的珍贵的财富，同时也是我们部门未来发展方向的一个重要部分。”

“今天的会议大家主要是针对我们部门的问题，希望会后大家再从公司整体考虑这些问题，以及未来扩充EditPart部门会带来什么问题，比如大家可以参考我们当初成立时遇到那些问题，这些问题将来如何避免或减少。”

“按计划，会后，小李，小孙，小丁，小黄还有我，将总结今天会议，同时、制定出未来部门组织变革的策略。在此期间，希望大家踊跃的将自己的想法创意于我们交流。”

“还有一件事情，今天要批评一下小丁同事，现在开会不迟到了，但是，不仅没发言、我看你从开会就一直看前天发的材料，为什么不提前准备，这是耽误大家每个人的时间，下不为例。今后、小李你在部门规章里加一条，部门开会前必须提前阅读理解会议材料，凡违反者，包括我在内一律站到会议室角落站着阅读完资料后，在回会议座位。我的话完了。”

小丁满脸通红，不由地低着头，双手捂住了腮帮，不敢喘气了，恨不得有个地缝钻进去。

“今天会议结束。”小李宣布。

会后根据小孙的会议记录，很快的小李几个人总结出以下的一个鱼骨图。

什么是因果图？

因果图的发明者 Kaoru Ishikawa 是一名管理专家，其最初的目的是改进车间的质量控制工作。正如以下示例所示，因果图还能表达其他环境中的因果关系。

 

由于因果图的形状很像鱼的骨架，所以它又称作鱼骨图。鱼的脊骨上几根最大的鱼骨表示主要的原因类别。
例如，在本例中，主要的原因类别有盎格鲁人/朱特人、丹麦人、萨克逊人和诺曼底人，这些种族群体都想控制英格兰，从而导致了该战争的爆发。

主要类别中的较小鱼骨表示主要的原因。例如，在本例中，在萨克逊人这个类别方面，黑斯廷斯战争的主要原因在于公元 1051 年萨克逊王爱德华许诺将王位传给威廉一世。

您还可以在主要原因上添加次要原因。

已存在一个三角图形EditPart，我们想重用它,但是我们还需要增加（或删去）边框可调整的特性，如何保证无需重新建立一个新的EditPart，或者做出丑陋的继承，当功能不断组合后，出现无数子EditPart类?

如何由框架自动完成Undo及Redo功能？

话说在某个跨国时尚媒体集团中国区广告部门（这是一家主营平面广告的广告公司，听说董事长是个年仅办百的老头GraphicalEditor先生，来自赫赫有名的eclipse基金财团），有目前主要有两个子部门EditPart(广告策划部)和Figuer(平面设计部)。

EditPart部长是一位中年充满信心和活力GraphicalEditPart先生。

Figuer部长是一位与部门名同名的广告主设计师美丽青春的Figure小姐。

EditPart部长GraphicalEditPart目前主要肩负着三项任何：

• 处理由其他部门中的Model人员送来各销售部门广告需求；
• 做出具体的平面设计策划交给Figure小姐，由Figure小姐负责画出充满激情的平面广告；
• 读阅客户要求与反馈的Request文书，这些文书是由Tool（情报收集部门）收集客户的反馈及要求，经过专业的整理与分类而成（上篇我们以及探讨过了）

 

由于公司扩大了业务，投入市场的产品种类比以往增加了三倍，EditPart部长工作变得异常繁忙有些快压垮了，感觉自己快成为整日驮着重物年迈的驴子，“是不是自己老了”GraphicalEditPart先生开始常常怀疑自己了。

这天，EditPart部长收到总部一封信：

 

GraphicalEditPart先生：

     首先我代表公司感谢您这些年勤奋出色的工作。我们公司在中国短短三年的营业额增长了四倍，同时EditPart中国部门在此期间获得了公司最有活力部门奖，这些成绩都与您的努力是分不开的。据我们了解，您在EditPart部门这三年中，实施了几项富有创意的制度改革，如成立Tool情报收集部门，推广后大大提高了整个公司EditPart部门业务处理能力。为了进一步扩大业务，公司在未来的两年里将在世界各地尤其是中国增加40%的区域广告部门，正如您所知道目前公司对于EditPart部门的组织规划以及责任制度还有很多不完善之处，这将十分不利于区域部门扩展的计划。故我委托您做出《未来广告部组织的规划》计划书，本月底将邀请您来总部参加组织规划与变革方案的评审会，届时将会对您的计划书进行评审。如通过评审，公司所有广告部将会按照您的计划书进行变革。

                      祝愿世界明天的舞台，因我们而变得更加美好、充满激情与想象

 

                                                                                          CEO GEF

 

“噢！太棒了，这封信来的真是及时，如果再继续如此的话，我要压垮了，只好另谋它职了。嗯，这回我要好好地写这个计划书。这样，身上担子总算有减轻的希望。有上司的赏识，我要一展宏图一番。”GraphicalEditPart不由自主拍了下桌子自言自语后，张开双臂，砰地一下仰靠在椅背上，深深地出了口气，双目轻合工作的压力似乎片刻间消失，顺手戴上了他那十分酷毙的太阳镜，小声打开旁边CD，噢，夏威夷之夜，感觉自己此时就在夏威夷带着墨镜躺在金黄、松软、温暖的沙滩，吹着口哨，热情似火的太阳穿过太阳镜，越过眼皮，将几缕模糊的光芒带入眼中（其实是他那高瓦的吊灯），海风习习（旁边的电风扇），在享受着这片刻宁静天堂感觉，激情创意不断涌出，啊，久违了的感觉。

 

开干！迅速的打开他喜爱的脑图软件 -- Mindjet Manager，记录下脑中的构思，画下如下计划要点：

 

看来GraphicalEditPart先生要大干一场，欲知详情，请听下回分解

[新闻]Windows Live视频邮件9月9日开始测试]]>

如果要建立可编辑2D图形程序，比较基本的要有以下几个主要需求

• 一方面我们有一个model对象组，这些包含了拥有一些业务以及UI展现上的数据；
• 另一方面我们有一个视图它将包含一组可视化对象，这些可视化对象定义了如何在屏幕上描绘；
• 用户能够使用鼠标和键盘修改图形视图。这需要在程序的内部通过某种方式建立在UI对象和model关联方式，透过二者的关联，当视图发生改变时，需要引发model改变，而model也有可能由于某种业务逻辑发生改变，需要通知放映到视图上。

这样我们就提供给用户一个图形交互的方式来修改业务model，具有这种能力的程序我们可以称之为可编辑2D图形程序（a graphical editor）。

上一篇讨论到在GEF框架中形成了三个对应的树状对象模型。

为了达到之上的需求，GEF通过EditPart如上图建立了View和model之间的关联关系。

于是问题随之而来：

这些树状对象模型 如何？何时？创建

尤其困难的是通过怎样简捷的方法在EditPart中建立它们的关联呢？

GEF给出如下答案：

从上图可以看出在GEF是通过EditPartFactory根据以存在的Model 来创建并设置不同的EditPart。

EditPartFactory的接口如下：

EditPart createEditPart(EditPart context, Object model);

其中model是Object类型，因此可以看出在GEF对model没什么过多的约束，context是于要创建的EditPart有关联的EditPart，例如是将要创建EditPart的Parent。

这样GEF通过一下时序图就非常轻松的（学起来可不轻松:(）,根据model对象框架建立了另外两个EditParts和Figures树状体系。[链接]见下附图 时序图。

其中在创建过程中重要的方法：

class ShapesEditor

class ShapesEditPartFactory

public EditPart createEditPart(EditPart context, Object modelElement) {

// get EditPart for model element

EditPart part = getPartForElement(modelElement);

// store model element in EditPart

part.setModel(modelElement);

return part;

}

/**

* Maps an object to an EditPart.

* @throws RuntimeException if no match was found (programming error)

*/

private EditPart getPartForElement(Object modelElement) {

//根据不同的model产生不同EditPart

if (modelElement instanceof ShapesDiagram) {

return new DiagramEditPart();

}

if (modelElement instanceof Shape) {

return new ShapeEditPart();

}

if (modelElement instanceof Connection) {

return new ConnectionEditPart();

}

throw new RuntimeException(

"Can't create part for model element: "

+ ((modelElement != null) ? modelElement.getClass().getName() : "null"));

}

class ShapeEditPart

public void setModel(Object model) {

if (getModel() == model)

return;

this.model = model;

}

protected IFigure createFigure() {

IFigure f = createFigureForModel();

f.setOpaque(true); // non-transparent figure

f.setBackgroundColor(ColorConstants.green);

return f;

}

/**

* Return a IFigure depending on the instance of the current model element.

* This allows this EditPart to be used for both sublasses of Shape.

*/

private IFigure createFigureForModel() {

//根据不同的model创建不同的figure

if (getModel() instanceof EllipticalShape) {

return new Ellipse();

} else if (getModel() instanceof RectangularShape) {

return new RectangleFigure();

} else {

// if Shapes gets extended the conditions above must be updated

throw new IllegalArgumentException();

}

}



 

至此、我们就得到了树状的MVC框架，但是，还是有些问题没有解决：
例如、已存在一个三角图形EditPart，我们想重用它,但是我们还需要增加（或删去）边框可调整的特性，如何保证无需重新建立一个新的EditPart，或者做出丑陋的继承，当功能不断组合后，出现无数子EditPart类?
在界面操作过程中，我们希望面对的是边框调整事件，或者是编辑文本事件，而不是原始的鼠标和键盘事件？
希望EditPart能够自动无误地把事件通知到相应的父及子EditPart中，同时能够按照正确的顺序对事件做出响应?
如何由框架自动完成Undo及Redo功能？
.....

包含GEF的Editor创建时序图

以eclipse网站上例子A Shape Diagram Editor为例

GEF如同其他的一些framework一样，是一个复杂庞大（有点夸张）的，当我们想使用驾驭它时，就必须全面的理解其整体构架及其运作过程。这需要我们的毅力和敏锐。旅途开始了….

GEF主要的任务是针对2D图形编辑操作，如下图。

为了使GEF能够广泛的用于种类繁多2D图形编辑领域，GEF就必须建立一个严格的易扩充/易组合/易重用的MVC框架（当然这种分解细化功能对象的方法思想，我们可以用在其它的地方，其它领域、其他语言如C#上）。

那么如果设计 这个 严格的MVC框架(对于Model是严格的独立，它不依赖与View和Controller) 以及 此框架 如何 达到 易扩充/易组合/易重用 的特性。下面我按照自己拙劣的思路，以麻雀之眼度鸿雁之志啦

对于MVC中

View部分：GEF理所当然要使用自家的东东Draw2D。利用Draw2D的Figuer作为自己的View。

Model部分：往往内部包含了千差万别、不可预知的商业信息。因此、GEF框架应该尽量减少约束（在下面将详细说明约束）。

Controller部分：EditPart/Draw2D的Figure/Model这三个树状对象模型，在EditPart中将建立了与其对应的Draw2D的Figure/Model结点 建立一一关联的关系。

这样产生的构架如下：

思考：

为什么Controller要同View一样采用树状结构呢？

当Controller以树状的形式存在，这样便于功能分解（这个道理有点像 在类设计中 复合优于继承 一般）

这样每一结点的Controller(即EditPart) 仅需要处理

• 自身逻辑功能
• 管理子Controller
• 必要时通知父Controller

尤其当用户需要在图形界面编辑界面中，需要使用多种不同UI行为规则的2D元素（例如不同的形状块，不同行为的连线等）组合来完成工作时（例如类似Visio这样的界面），这种构架的优势就显露无疑。

未完待续….(下面要探讨如何产生上述三个树状模型等。)

GEF学习笔记（一） eclipse的GEF相关项目说明

首先、感谢八进制的辛勤劳动和奉献。这几天开始对GEF发生兴趣，八进制的GEF系列对我学这些的帮助很大入门很快。自己也就顺手把周末学习的东西记录下来。帮助后来学人。我会把这几天所学陆续写出希望大家支持。目前、正在为八进制例子发愁，我对NodePart增加了ResizeEditPolicy，但是不知为何鼠标拖动时有个灰色的区域在随着变化，但鼠标释放时，NodeFigure的尺寸不发生变化，是否是因为在refreshVisuals中固化了Size，代码学习中….

eclipse的GEF相关项目说明。

各项目的简介：

Draw2D：建立了2维的图形库(树状图形部件Figure)，负责显示2维的图形展示。

GEF：     （Graphical Editing Framework）建立标准的MVC构架，代码利用Draw2D作为自己的View部分，主要代码实现复杂的树状(于Model分别对应)      的控制器。实现的框架具有很高的可复用等特性，例如：将图形部件功能分解为多个EditPolicy，这样使用者可以通过installEditPolicy接口来定制，以及扩充自己的某一功能特征。

EMF:      （Eclipse Modeling Framework）首先在一个轻量级项目以及项目初期开发，Model常常采用拥有Property的Java对象来简单明了表示【即 Plain Old Java Objects (POJOs)】。EMF定义了一套Ecore元模型，使得Model具有易于维护、易于扩充、易于数据交换等特性的Model Framwork。因此、在实际中大型的项目中往往会采用Draw2D＋GEF＋EMF的方式来实现整体的MVC模式。例如：ROSE的最新版本 IBM.Rational.Software.Architect就是采用了这种构架。

GMF：    （Graphical Modeling Framework ）使用了GEF和EMF，建立了两个之间的桥梁框架，同时实现了一些领域上的典范应用，如UML图，甘特图，脑图等。（项目正在进行中这些功能还未完备。可以用来参考以实现自己的一个标准的GEF＋EMF的应用）。

各项目依赖关系：

如上图：使用者可以有以下几种用法：

EMF: Model管理层

Draw2D: 二维图形展现

Draw2D ＋ GEF: 二维图形的简单编辑模块

Draw2D ＋ GEF ＋ EMF： 二维图形的编辑模块

Draw2D ＋ GEF ＋ EMF ＋ GMF：基于GMF提供的图形编辑功能之上扩展

打造软件团队

我们还是一个团队吗？

共同认可的明确的目标

合理的分工与协作

积极的参与

互相信任

良好的信息沟通

高度的凝聚力与民主气氛

学习是一种经常化的活动

项目团队的作用

（1）更有效地实现目标

（2）可满足成员心理需要

（3）使个人得到更快的进步

（4）较强的凝聚力

（5）提高决策的质量

打造软件团队

我们是怎样的团队？

不同条件下如何选择适应的团队文化？

球队团队文化更适于软件开发团队

团队分工交流中我们有那些方式与之不同？

打造软件团队

项目管理仅仅是项目经理的事情吗？为什么？

软件团队中项目经理应该如同带兵打仗军官班长？还是教练？

为什么？军官班长和教练在团队运作中有何不同之处？

何时需要特种分队的运作方式？

打造软件团队

项目管理－－驾驶、管理轮船

项目经理－－组团、掌舵、管家婆

打造软件团队

共同认知

合作才能成功

项目组成员形成团队不仅是项目成功的保证而且也能满足成员的需求

打造软件团队

激励团队

让大家主动投入

打造软件团队

从项目开始的第一天

从项目计划的制定就建立一个共同目标和激励“团队”活动

打造软件团队

认清自我、审视团队

量力而行

打造软件团队

合适的人在合适的位置为项目的基础

注意人员比例

因才用人善驱驰

打造软件团队

纵观全局、把握重点

找出项目中关键点和关键风险，形成简单有效解决方法

项目负责人处于夹缝位置

对未来的目标有坚强的意志

建立平等气氛团队、形成团队精神

要权威，不要霸权

去除位置在上心理

任劳任怨、不强功名

为大家服务、打造轻松有效开发环境

认真负责，勇于承认错误，勇于承担责任。

对上级尽量承担责任，内部处理具体问题

协调大家有效沟通。

建立透明的监督检查机制。如特色监督小组、FDD进度板等。

从小处建立团队规则。

菩萨慈眉＋金刚怒目

合理公平分配任务

培训引导大家

合理安排任务

有效的时间管理

多多鼓励表扬

一切表扬在先，公证有效有限的批评。

关怀大家个人生活，了解团员情感状态。

不要加班。

项目开发过程中，不断监视调整风险列表；

善于观察、保持警觉提前发现问题；

学会和各种官僚主义等打交道

关键时勇于对此质疑、有力抵制

勇于面对困难

关键时要有壮士断腕式果断，必要时砍去一些十分诱人但不是核心必须的功能点。

不能过分追求完美

开始和中间阶段要和大家轻松一下，鼓舞士气。（尽管可能有种种滞后压力和不良现状）

软件领域更是不断更新成长、没有长期避风港.

充满好奇、勇于探索

和大家不断共同自我学习培训、提高，相互学习

对于新的开发思想和方式，要在小范围实践

祝愿大家，通过长期共同努力。打造出一个有共同的认知，熟悉内部工作流程、沟通方式、思考讨论模式等高素质高效的团队

强烈推荐!!!

比较科学客观。大家试验一下。

我测试的人格类型是： ENTJ（外向，直觉，思维，判断）

您的工作中的优势：

　　◆ 能看到事情的可能发展情况及潜在的含义

　　◆ 有创造性解决问题的天资，能客观地审查问题

　　◆ 有追求成功的雄心和干劲

　　◆ 对于在工作中胜任和胜出有强烈的动机

　　◆ 自信并且具有天生的领导才能

　　◆ 标准高，工作原则强

　　◆ 能创造方法体系和模式来达到自己的目标

　　◆ 敢于采取大胆行为，有不达到目的誓不罢休的势头

　　◆ 能逻辑地分析地做出决定

　　◆ 擅长从事技术性工作，学习新东西的接受能力强

您工作中可能存在的不足：

　　◆ 对那些反应不如你敏捷的人缺乏耐心

　　◆ 唐突，不机智，缺乏交际手段

　　◆ 易于仓促做出决定

　　◆ 对一些世俗的小事没有兴趣

　　◆ 有想去改变那些根本没有必要去改变的事物的倾向

　　◆ 不愿意花时间适当地欣赏、夸奖同事或者别人

　　◆ 对那些既定地问题不愿意再审视

　　◆ 易于过分强调工作，从而损害了家庭的和谐

但如果仅应付制度，完成过场，则大家只感其累无有利处。

故而根据本人经验拟定一CodeReview细则，希望对大家有所帮助，同时恳切求大家意见经验。

1、确保一周之内必须有一次至少四十分钟CodeReview

2、各小组人数不要超过10人，每组至少有一人有熟练编辑经验，同时具有局部模块设计能力，并且此人作为   小组组长，最好能保证一个CodeReview小组成员来自一个开发组。

3、CodeReview总体粗分可以分为：

A、分析每人代码是否符合编程规范等

B、分析经典有缺陷代码

C、分析经典优秀代码

D、通过分析部分代码来映射反观设计要点

E、分析代码现场实施重构

4、每5次CodeReview中必须保证 D或E 至少两次

5、每次CodeReview需要提交一份记录，包含到会者会议时间

    A/B/C时罗列讨论到的编程规范等名称

    D时要对讨论的大纲记录

    E时罗列重构方法名称

6、A/B要由组长组织，由小组成员轮流发言。C/E 组长参与讨论。D 组长主持，成员为辅。D/E还需要定期邀请其他有经验人员主持。

7、A/B/E 依据的代码，均可以由组员各自都提供，组长挑选。

来自Ergoweb

在2005年11月3日, 一个全世界性连续事件将通过“Making it easy”为主题，旨在促进以用户为中心的设计。

Human Factors International (HFI) 被选中作为每年世界可用性日的带头发起人. 可用性设计职业协会正在组织这个事情，并且HFI世界范围内的参与将帮组提升世界可用性日的影响范围.

原文请参考：

http://www.ergoweb.com/news/detail.cfm?id=1159 

世界可用性日网站：
http://www.worldusabilityday.net 

   交互性设计越来越壮大了！

周一，公司派我去杭州出差。刚住进宾馆，我就接到了老婆的电话：“老公，大事不好。今天咱们小区混进了几个贼，咱家也被光顾了。”我跳了起来，问：“丢东西了吗？有没有报警？”“家里被翻得乱七八糟，衣橱里的1000块钱没了。还丢了什么东西我正在清理，警察下午来看过了。”老婆听出了我的焦急，赶紧安慰我：“好在那几个贼已经被警察抓住了，现在让各家尽快报失窃清单去。”我松了一口气，赶快命令老婆： “快去看看床头挂的那张结婚照。画框后面有一个用双面胶粘住的红包。”老婆搁下电话。两分钟后，问：“我把画框取下来看了，什么也没有。”如此神仙难料的地方都能找到，看来今天遇到的绝不是普通的蟊贼。

     我赶紧叫老婆再去卫生间看看：“马桶水箱靠墙那面有个缝，塞了一个塑料袋，你看看还有没有。”十分钟后，老婆打来电话：“没有，是不是你记错了地方？”我焦急地说：“不可能。出差前我还检查过。整整4000块钱，全是连号的百元新钞。那是去年我从公司发给我发的技改奖里扣下来。”

     “就这些了吗，还有没有忘记的？”老婆在电话里追问。“没有了，只有这6000块钱。你一定要把那些钱的特征跟警察讲清楚。”我提醒老婆。老婆冷笑道：“好的。感谢你在本次家庭防盗演习中的出色表现。”我听完差点儿晕过去。

[少时好坏]
小的时候我们关注那个是好人！那个是坏蛋！

[中时对错]

大了我们知道没有绝对的好人和绝对的坏人，关注做的事情是对还是错，内心想法目的是对是错

[老时因果]

又大了些我们知道没有绝对的对和绝对的错，不同时空，不同角度、不同出发点、不同观察点，往往会有不同的结论。我们开始在意这些东东的前因后果。

       经典老书，无需多言

       用浅显经典的例子讲述了几乎面向对象敏捷开发所有主要的相关技术的应用。

《UML和模式应用（原书第2版）》

       "人们经常问我，引导他们进入00世界的最佳图书是哪一本。读过本书之后，它已经成为我的惟一选择。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　---MartinFowler

这本书本人认为有以下特色：

1、本书是带领读者在具体的迭代开发过程中，进行论述OO软件的UP迭代开发过程。不会出现以前知道有莫一UML视图不知道何处使何处用。

2、本书重实际一不是类似ROSE公司出的带有公司宣传偏见问题，二不是学院派有未来学术目标的导向。

3、书中设计软件开发个个方面的组合，并且、这些各自方面的分量在书中恰到好处。

4、仔细阅读，书中的每句都是作者用心所著，几乎句句良言，尤其方框标出的更是有深刻含义，很少废话。

例如、目前我们小组正在进行收集Use Case阶段，借鉴了本书发现了很多以前Use Case上的错误认识。

1、用例图和用例关系是用例工作中的次要部分。用例本身是文本格式文档，用例工作意味着书写文本。（以前专注于Rose中的小人和椭圆以及为了连线和其箭头争论不休）。用例建模的新手（或学院派）的一个普遍标志是，专心于用例图和用例关系，而不是文本。顶级用例专家（如Anderson、Flower、Cockburn）不太重视用例图和用例关系…

2、一个值得注意的地方是 一个常见的用例错误是：定义了许多低级别上的用例。这些用例只相当（基本业务过程）EBP中的一个简单步骤、子功能或子任务。我目前理解的EBP是用户（角色可能是外部系统）通过这个用例可以明确到达某个用户目标，并且这个目标完成对用户就有可度量的业务价值。例如、用户登陆一般情况下就不是一个用例而是一个过程而已。正如书中所说，如果CEO问起来：“你今天干什么了？”你回答：“我登陆了20次！”他不会留下什么印象。登陆是为了完成其它有用的事情而服务的。因此我们发现诸如，读取插件清单文件是一个过程等等（因为要做纯UI平台系统，所以必须涉及界面否则应尽量避免用例对界面描述）

此书目前仍在摸索中，今后有什么心得在和大家交流。如果大家对此书或Use Case有什么心得也交流交流？