最近在写一个使用XMPP协议(gtalk和jabber使用的) 即时通讯的客户端，在.net下使用了一个Open Source库ags. 这个库是基于Windows Socket异步方式来做底层架构的。这就存在NUnit的使用问题，

如果按照一般Unit使用过程，在客户端发出请求后，因为异步原因，会不等接收数据的delegate事件被调起，Test函数就会提前退出。

为此到网上海google了一番，均无此法，后来搜到一封网上的英文mail，mail里写了几行好像测试异步访问Web服务器的测试程序，没头没尾看不出究竟干什么的（他们是讨论一个feature问题），但里面几行给了我很大提示，其中有一行

 if (!reset.WaitOne(timeout, true))

这似乎就是我要寻找的提示，嗯用线程同步信号不错，估计可以解决，经过2个小时反复试验终于出炉啦,呵呵!

大体程序如下：

static ManualResetEvent reset;

private const int timeout = 3000;

[TestFixtureSetUp]

public void FixtureSetUp()

{

reset = new ManualResetEvent(false);

}

[TestFixtureTearDown]

public void FixtureTearDown()

{

reset.Close();

}

[Test]

public void TestConnect()

{

。。。。。

msgControl.Connect(connectInfo);

Assert.AreNotEqual("", msgControl.Status);

msgControl.RecvStringEvent += new RecvStringCallback(msgControl_RecvStringEvent);

reset.Reset();

// note for some reason r.AsyncWaitHandle.Wait won't work as expected

// if (!r.AsyncWaitHandle.WaitOne (timeout, true))

if (!reset.WaitOne(timeout, true))

{

if (recvTimes == 0)

{

Assert.Ignore("Timeout");

}

else

{

Assert.AreEqual(8, recvTimes, "not recv 8 times");

}

}

Assert.IsNotNull(message, message);

}

private int recvTimes = 0;

void msgControl_RecvStringEvent(string msgText)

{

recvTimes++;

message = msgText;

if (recvTimes > 9)

{

recvTimes = 0;

reset.Set();

}

}

希望能对编写异步通讯的人有所帮助

mantis 的网站 http://www.mantisbt.org/

今天安装了一个bug 跟踪系统， mantis。非常清爽，主要有以下好处：

1、用php写的系统，安装方便，不用像 bugzilla 那样安装那么多perl支持；

2、系统相对简单轻磅，使用简单；

3、出色的多语支持，对于对日开发等公司非常合适；

安装：

本人在安装了其他免费的php系统后，安装mantis直接在页面，敲入路径立刻成功。就是后来注册用户时，它要把密码通过mail发到个人，需要在config中配置smtp mail （mantis使用的是phpmailer）。配置完后一切OK。

以下是使用的图片：

登陆界面：


其中视图界面：

如图，它的多语支持非常出色：

1、可以使用utf-8为内码，这样可以多种语言并存；

2、每个用户可以自定义界面语言；

这是设置语言地方;

这是修改后日文界面：

答:

学习Java环境,了解一下关键字(十分关键尽量深入):

Java、JRE、JDK、J2ME、J2RE、J2EE、JVM

JAVA_PATH、JAVA_HOME

JAR

Package、ClassPath

ClassLoader

Javac,Javaw

Java Applet,JavaBean,EJB

*问:开始进入学习需要如何渐进掌握Java基础?

答:

1. 学习Java基础语法
2. 后了解Java面向对象语法及其特性，这期间要先对面向对象编程基础知识有所了解，重要的一点是要学会掌握Interface使用和其应用场景
3. 学会理解Java出错输出的Call Stack
4. 学会基本调试，log方法
5. 理解学会Exception的用法

还有就是要掌握Java的基础类库

*问:注意掌握那些Java的基础类库?如何快速掌握？

*问：推荐两本入门书籍可否？

• SUN－JAVA2核心技术
• 蔡学镛推荐的是Oreilly的《Exploring Java, 2nd Edition》
• 《OReilly-Java.in.a.Nutshell,4th.Edition》

               古语有云 ：大家好，才是真的好

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先生要大干一场，欲知详情，请听下回分解

般若菩提 2005-12-05 14:01 发表评论

]]>

GEF源码分析（四） GEF 消息转义 ___ Tool的作用

接着上一节：

我们先解决如下问题：

在界面操作过程中，我们希望面对的是边框调整事件，图形移动事件，或者是编辑文本事件，而不是原始的鼠标和键盘事件？

术语定义：

系统UI事件：        一般由某些计算机人机交互硬件发出信号，并且经操作系统理解后产生的事件，例如：原始的鼠标的移动、点击和键盘的敲击事件等。

UI业务语义事件： 由系统UI事件和其它UI业务语义事件触发，由UI业务代码理解后产生的事件（操作系统不可理解，同时无任何领域的业务语义），如2D图形的尺寸调整，2D图形的点击，2D图形的移动。

（其实不仅限于事件的转义，包括UI的改变，也需要由系统UI语义转换到UI业务语义来使用）

UI业务语义事件在Controller控制中的优点是易于理解、维护和扩充，具体的主要有以下方面：

a.减少系统UI事件判断逻辑部分代码的重复。比如在Controller部分代码无需分步着大量逻辑重复的代码，当鼠标移动时去判断究竟是一个2D图形的尺寸改变，还是一个2D图形的移动，还是一组2D图形的移动，还是2D图形DragAndDrop的动作。

b.Controller部分的代码语义明确。在Controller内部处理代码和接口中直接面对的是UI业务语义，如图形的移动，图形的尺寸改变，这样、代码易于理解、调试等。

b.Controller部分代码无需为系统UI事件保存状态。如2D图形的移动中，如果这些事件直接在Controller中处理，从开始MouseDown,到MouseMove，到MouseUp过程中，在Controller中要集中保留这样众多状态，极易造成Controller代码具体多头职责的症状，从而患上严重的精神分裂:)。

于是乎GEF的FrameWork有给出以下的解决方案：

图A

如上图A：

GEF通过Tools(根interface是Tool)，当然在视图上的Menu和Toolbar是通过Action发出，这个是eclipse的Workbench机制，在此就不讨论了。以下是Tool的类继承树：

图B

从上图B可以看出

从Tool继承的这些类均处理一个或者一类UI业务语义事件，其中需要保留中间状态的子类均以XXXTracker形式出现。

首先这些Tool的实现类通过Tool的接口（上图右边），接收界面来的事件，然后调用内部handleXXX，这样通过内部函数getTargetRequest()[createTargetRequest()]和getSourceRequest()[createSourceRequest()]，把系统UI事件转换为UI业务语义事件叫Request（如图C）。至此Tool会通过调用相关联的EditPart的接口将UI业务语义事件通知到EditPart中。于是在Controller(EditPart)中仅仅需要理解处理Request对象。

图C

下面以ResizeTracker代码为例：

class ResizeTracker

protected Request createSourceRequest() {

ChangeBoundsRequest request;

request = new ChangeBoundsRequest(REQ_RESIZE);

request.setResizeDirection(getResizeDirection());

return request;

}

protected Command getCommand() {

List editparts = getOperationSet();

EditPart part;

CompoundCommand command = new CompoundCommand();

command.setDebugLabel("Resize Handle Tracker");//$NON-NLS-1$

for (int i = 0; i < editparts.size(); i++) {

part = (EditPart)editparts.get(i);

command.add(part.getCommand(getSourceRequest()));

}

return command.unwrap();

}

protected void eraseTargetFeedback() {

if (!getFlag(FLAG_TARGET_FEEDBACK))

return;

if (getTargetEditPart() != null)

getTargetEditPart().eraseTargetFeedback(getSourceRequest());

setFlag(FLAG_TARGET_FEEDBACK, false);

}

protected boolean handleButtonUp(int button) {

if (stateTransition(STATE_DRAG_IN_PROGRESS, STATE_TERMINAL)) {

eraseSourceFeedback();

eraseTargetFeedback();

performDrag();

}

return true;

}

最后还有个问题是

Tool这些事件接口，如何从Viewer传递过来的呢？

我画了一个简要的类图

图D

参照上图，下面罗列重要代码：

大家主要以下两方面

一、创建这些关键事件处理链的过程（注意图上的粗体文字）；

二、消息从SWT中Canvas实例传递到Tool过程（图D中注释标签的顺序）；

class GraphicalEditor

public void createPartControl(Composite parent) {

createGraphicalViewer(parent);

}

protected void createGraphicalViewer(Composite parent) {

GraphicalViewer viewer = new ScrollingGraphicalViewer();

viewer.createControl(parent);

setGraphicalViewer(viewer);

configureGraphicalViewer();

hookGraphicalViewer();

initializeGraphicalViewer();

}

protected void setGraphicalViewer(GraphicalViewer viewer) {

getEditDomain().addViewer(viewer);

this.graphicalViewer = viewer;

}

class EditDomain

public void addViewer(EditPartViewer viewer) {

viewer.setEditDomain(this);

if (!viewers.contains(viewer))

viewers.add(viewer);

}

class GraphicalViewerImpl

public void setEditDomain(EditDomain domain) {

super.setEditDomain(domain);

// Set the new event dispatcher, even if the new domain is null.  This will dispose

// the old event dispatcher.

getLightweightSystem()

.setEventDispatcher(eventDispatcher = new DomainEventDispatcher(domain, this));

}

private final LightweightSystem lws = createLightweightSystem();

class ScrollingGraphicalViewer

public void setEditDomain(EditDomain domain) {

super.setEditDomain(domain);

// Set the new event dispatcher, even if the new domain is null.  This will dispose

// the old event dispatcher.

getLightweightSystem()

.setEventDispatcher(eventDispatcher = new DomainEventDispatcher(domain, this));

}

class LightweightSystem

public void setEventDispatcher(EventDispatcher dispatcher) {

this.dispatcher = dispatcher;  //在此Shapes例子中是DomainEventDispatcher

dispatcher.setRoot(root);

dispatcher.setControl(canvas);

}

protected void addListeners() {

EventHandler handler = createEventHandler();

canvas.getAccessible().addAccessibleListener(handler);

canvas.getAccessible().addAccessibleControlListener(handler);

canvas.addMouseListener(handler);

canvas.addMouseMoveListener(handler);

canvas.addMouseTrackListener(handler);

canvas.addKeyListener(handler);

canvas.addTraverseListener(handler);

canvas.addFocusListener(handler);

canvas.addListener(SWT.MouseWheel, handler);

……

setEventDispatcher(getEventDispatcher());

}

class EventHandler

implements MouseMoveListener, MouseListener, AccessibleControlListener, KeyListener,

TraverseListener, FocusListener, AccessibleListener, MouseTrackListener,

Listener

{

…

public void keyPressed(KeyEvent e) {

 //在此Shapes例子中是DomainEventDispatcher

getEventDispatcher().dispatchKeyPressed(e);

}

…

public void mouseDoubleClick(MouseEvent e) {

getEventDispatcher().dispatchMouseDoubleClicked(e);

}

…

public void mouseMove(MouseEvent e) {

getEventDispatcher().dispatchMouseMoved(e);

}

public void mouseUp(MouseEvent e) {

getEventDispatcher().dispatchMouseReleased(e);

}

…

}

这样、在图A中Request发送到EditPart机制做了简要的探讨。

学习了Tool产生Request的机制，可以帮助我们调试GEF，同时如果在大家自己的程序中需要有新的UI交互类型，也可以试着建立自己的Tool类产生新的Request，这样在自己的EditPart产生对应的Command,这样就可以处理实现新的UI交互类型。

在下一篇我们探讨一下有关图A中的EditPart如何产生Command，以及执行Command问题。

包含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进度板等。

从小处建立团队规则。

菩萨慈眉＋金刚怒目

合理公平分配任务

培训引导大家

合理安排任务

有效的时间管理

多多鼓励表扬

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

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

不要加班。

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

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

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

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

勇于面对困难

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

不能过分追求完美

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

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

充满好奇、勇于探索

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

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

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