创建一个UML图:

new>Software>UML Model Diagram

左侧 UML Static Structure中包含多数的需要使用的素材 如package, interface, class等

Tips:

1. 连线

可以按住Shift画笔直的线, 也可以点击线条右键format 为线条选择一个样式

2. 快捷键:

缩放: ctrl + 鼠标转动

左右移动 shift + 鼠标滚动

拷贝元素: 按下ctrl拖动

3. 另外可以下载使用Yahoo! Design Stencil Kit:

Yahoo! Design Stencil Kit下载地址:http://developer.yahoo.com/ypatterns/wireframes/

----------Post from: @LiGuoliang.com, 欢迎回来~----------

增量模型融合了线性顺序模型的基本成分(重复地应用)和原型的迭代特征。
增量模型采用随着日程时间的进展而交错的线性序列。每一个线
性序列产生软件的一个可发布的“增量”.例如，使用增
量范型开发的字处理软件，可能在第一个增量中发布基本的文件管理、编辑和文
档生成功能；在第二个增量中发布更加完善的编辑和文档生成能力；第三个增量
实现拼写和文法检查功能；第四个增量完成高级的页面布局功能。应该注意：任
何增量的处理流程均可以结合进原型范型。
当使用增量模型时，第一个增量往往是核心的产品，即实现了基本的需求，
但很多补充的特性(其中一些是已知的，另外一些是未知的)还没有发布。核心产
品交用户使用(或进行更详细的复审)，使用和/或评估的结果是下一个增量的开
发计划。该计划包括对核心产品的修改，使其能更好地满足用户的需要，并发布
一些新增的特点和功能。这个过程在每一个增量发布后不断重复，直到产生最终
的完善产品。
增量过程模型，像原型和其他演化方法一样，具有迭代的特征。
但与原型不一样，增量模型强调每一个增量均发布一个可操作产品。早期的增量
是最终产品的“可拆卸”版本，但它们确实提供了给用户服务的功能，并且提供
了给用户评估的平台。
增量开发是很有用的，尤其是当配备的人员不能在为该项目设定的市场期限
之前实现一个完全的版本时。早期的增量可以由较少的人员实现。如果核心产品
很受欢迎，可以增加新的人手(如果需要的话)实现下一个增量。此外，增量能够
有计划地管理技术风险，例如，系统的一个重要部分需要使用正在开发的且发布
时间尚未确定的新硬件，有可能计划在早期的增量中避免使用该硬件，这样，就
可以先发布部分功能给用户，以免过分地延迟系统的问世时间。

参考资料:

Software Engireering-A Practitioner’s Approach

----------Post from: @LiGuoliang.com, 欢迎回来~----------

场景书写准则

参考书目: Writing Effective Use Cases

----------Post from: @LiGuoliang.com, 欢迎回来~----------

太过自负

•不能容忍别人的意见

•我总是对的

•我吃盐多过你吃米

太过自卑

•没主见

•没责任心

什么样的人适合做Pair Programming

Extreme Programming对实施的程序员提出了更高的要求。这种要求不是技术水平，也不是学历水平也不是工作经验。这种要求是对一个人的心智，道德，修养的更高要求。

     程序员的四怕：

     1) 怕自己看上去傻

     2) 怕被认为是没用的

     3) 怕自己变的不重要（过时）

     4) 怕自己不够好

     Pair Programming中，编码不再是私人的工作，而是一种公开的“表演”。程序员的代码，工作方式，技术水平都变得公开和透明。

XPer的素质

一个XPer应该具备这样一些基本素质：诚实，公正，开明，勇敢和谦卑！在这些素质的基础之上，才是对技术水平，能力和天分等的要求。

•诚实 

•公正

•开明

•勇气

•谦卑

     具备这些素质才能克服“四怕”，才能成为一个成熟和专业的Developer。

如何Pair Programming

•Driver – 写设计文档(Class diagram等)，进行编码(Unit Test and Business Object)等XP开发流程。

•Navigator – 审阅Driver的文档、Driver对编码等开发流程的执行；考虑Unit Test的覆盖程度；是否需要和如何Refactoring；帮助Driver解决具体的技术问题。

•Driver和Navigator不断轮换角色，不要连续工作超过一小时，每一小时休息15分钟。Navigator要控制开发时间。

•主动参与 – 虽然每个Engineering Task都有owner，但不能一旁观者的心态来做。任何一个Task都首先是两个人的责任，也是所有人的责任。没有“我的Code”、”你的Code”或“她的Code”，只有“我们的Code”。

•只有水平上的差距，没有级别上的差异。一个Pair,尽管可能大家的级别资历不同，但不管在分析，设计或编码，双方都拥有平等的决策权利。

•Pairs之间互换Partner。每个Task都应该和不同的Developer配对。

•每隔一天，甚至是半天，互换Partners。但Task的owner因该继续留该Task的Pair中。

•如果Pair中的一人请假，另一人应尽量不要写Production Code。

•Pair一起加班

----------Post from: @LiGuoliang.com, 欢迎回来~----------

双人编程指在一个项目中由两个程序员编写一个软件的技术.每两人在同一台机器上工作，其中一人操作机器的同时另一个在旁边仔细看着代码被编写出来.操作者从战术上关心当前自已在编写的每一行代码，观察者确认语法规范，并从战略上考虑整个程序.他们频繁地交换彼此的角色，并且更快地编写出比单人编写更少错误的代码.并且，这些代码至少被两个以上的开发者所熟悉。

The Practice 实践

Pairing 配对
Pairing begins when the developer responsible for a task asks someone else for help. The rule is: when asked, you must say yes. This does not mean you have to immediately stop what you are doing. Rather it means that you must negotiate a time when you can offer that help and another time when you can get help in return.
双人编程开始于负责某个任务的程序员寻求他人的帮助。原则是：有人来问，你必须说是，不过这不意味着你要马上停下你在做的工作，而是说，可以商定某个时间帮忙，而在另一个时间让对方帮你的忙。

The pair partner does not assume responsibility for the task. That responsibility remains with the task owner. Nor does the pair partner commit to staying with the owner until the task is complete. The pair partner only commits to help.
双人编程的拍档者不对所做的任务承担责任，责任由负责任务的那个程序员承担，，拍档者直到任务完成也不会承诺与任务负责人共同负担任务的责任，只是承诺会帮忙。

One member of the pair becomes the driver, while the other looks on. The driver types in the code, runs the compiler, runs the unit tests, and so forth. The watcher examines each keystroke, each  command, each test result, and offers help and suggestions. Both parties are engaged at all times.
双人编程中的某个成员成为操作者，同时另一个作为观察者。操作者敲代码，编译，做单元测试，观察者检查每一次敲击，每一个命令，每次测试的结果，并提供帮助和建议，整个时间里两边都同样的忙碌。

Sometimes the driver will know best what to do, and the watcher will simply be following along. At other times, the watcher will dictate what to do to the driver. Sometimes the driver will get frustrated and will hand the keyboard to the watcher,thereby switching roles. Other times, the watcher will ask for the keyboard and switch roles. this will happen many times in a pairing session.
有时，操作者知道该如何做到最好，这时观察者就只是随着思路走就行了。反之，观察者可以指示操作者该如何做。有时操作者会思路阻碍做不下去，键盘交给观察者，两者便换了角色。在整个编码过程中，观察者会主动要求键盘输入，从而交换角色，这种情况是经常发生的。

Changing pairs 交换配对

Pair partners are not long term. A typical pairing session will last about half a day. Either partner can opt out of the pair for any reason. When this happens, the owner of the task must find another pair partner. This may mean that it is time for the task owner to pay back a favor to someone who paired with him or her last week. On the other hand, perhaps he or she should ask
someone with the right experience to help with a particularly sticky problem.
双人编程的两个拍档不是长期合作的。一个典型的双人编程会持续大约半天，其中每个拍挡可以以任何理由要求重新选

优点

一、Pair 可以最大化的提高工作效率。 软件开发并不只是程序员堆砌代码的过程，它更多的是一个创新的过程，是一个发现问题、分析问题、解决问题的过程。一个人编程时，往往有了一丝零碎的想法就开始编写代码。写完代码之后，忽然发现这个方案行不通，只好废弃这些代码，重新开始新的想法。当一个人在遇到疑难问题时，很容易走入“死角”。而Pair则不同，一个人有了想法，首先要表达出来，让自己的同伴理解，经过深刻的讨论，一致认可之后才开始编写代码。一个人编写代码，另一个则在旁边思考，会为下一步的工作提出建设性的意见。发现了问题可以及时的指正。大大的提高了代码质量。

一个人一天有效工作时间不超过3－4个小时。两个人一起Pair。一个人编写代码，另一个人则从设计的角度思考下一步的工作，有了想法之后，互相讨论，再互换角色。在开发过程中，设计思考和编码实现不停的进行交换，保持了良好的开发节奏。同时可以互相督促，使彼此更加认真的工作。遇到问题和压力时，可以一起面对，互相鼓励。可以一起分享解决问题的成就和乐趣。

二、Pair 是知识传播的最好途径。 很多软件公司都建立有自己的知识库，有的还建立自己的培训部门，甚至高薪聘请一些专家做技术培训。但发现效果并不理想。培训之后，开发人员面临实际的项目，还是一片茫然。而与有经验的同事一起Pair则是在实际项目中学习，具有非常强的针对性。你学到的不仅是一些技术和技巧，更多是他们思考问题方式、解决问题的方法。和各种不同经验的同事一起Pair，你的经验和能力可以得到快速的提高。

在ThoughtWorks公司，如果你要加入一个项目，完全不用担心它使用的技术和涉及的业务。只要你有一定的基础，和有经验的同事一起Pair能让你很快熟悉和掌握它们。

三、Pair 可以打造出最佳的合作团队。 团队是有组织有计划的，合理有效地利用各种资源，进行最佳的组合。Pair并不是一对固定的伙伴，我们鼓励在团队中经常交换Pair伙伴。这时我们发现，项目不再是一个人的事情，也不是两个人的事情，而是整个团队的事情。

通过Pair，大家可以在最短的时间内完成磨合。Pair很好的促进了团队的沟通交流，经常一起合作Pair的伙伴，彼此了解、熟悉，很多都是工作和生活上的好友。在这样的团队里，大家很乐意互相协助，一起分享知识，分享快乐。

参考资料:

Pair Programming (结对编程) 作者: 作者：钱安川（Moxie） http://www.blogjava.net/moxie/archive/2006/09/14/69714.html
RUP/XP指南:双人编程 http://accp.chinaitlab.com/ACCP/9763.html

Moxie同学把在项目中遇到的developer分为四类。
1、优秀型的Developer。有丰富的工作经验，很好的解决问题能力，善于沟通，有幽默感，还有生活情调。这个不说了，他在任何地方都是受欢迎的。
2、巨大潜力的Developer。没有工作经验，理解能力不错，悟性比较高，人很勤快，爱问问题，脾气也好，懂得尊重其他同事。这类 developer，我们也非常喜欢。我们遇到一个这样的应届毕业生，刚来的时候，只会一些基本的Java知识，他在团队中工作5个月，并已成为客户公司的主力developer了。
3、Trick型的Developer。也许没什么经验，但思维非常活跃，也许喜欢狡辩，也偶尔会指责别人，有点小懒惰，而且会自我感觉非常良好。与这样的develoer合作时候，问题争论会很多，但对问题的理解也会更加深刻。这样的devloper，需要教育提醒。告诉他我们是一个 Team，多用“我们”这个词，你指责别人，别人也会以同样的方式对你。如果能改正这些缺点，他绝对是个好同志。
4、普通的Developer。要么是技术不错，但是理解能力很弱；要么是沟通、理解能力不错，但是工作态度不好，爱混日子。和这样的 developer 一起Pair是要辛苦一些，需要一些技巧。能把你的技术方案，讲得通俗易懂，这也正说明你思考正确和深刻，我们在开发的时候，要善于分解问题，将一个复杂的问题分解，小步前进，这样开发才有一个非常好节奏。工作态度不好的，那就多问问题，逼他思考工作.

----------Post from: @LiGuoliang.com, 欢迎回来~----------

总结自:

The Pragmatic Programmer From Journeyman to Master［程序员修炼之道］Chapter 1
Code Complete 2 [ 代码大全 ] Chapter 33

1. What distinguishes Pragmatic Programmers?

• An attitude, a style, a philosophy of approaching problems and their solutions.
• Think beyond the immediate problem.
• Take responsibility for everything they do.

2. 态度与性格

• 谦虚: 承认自己智力有限并通过学历来弥补, 你会成为更好的程序员. 你越是谦虚, 进步就越快.
• 诚实: 不是高手时不假装时高手. 乐于承认错误. 力图理解编译器的警告, 而非弃之不理. 透彻理解自己的程序, 而不要知识编译看看能否运行. 提供实际的状况报告. 提供现实的进度方案, 在上司面前坚持自己的意见.
• 懒惰: 编写某个工具来完成烦人的任务, 如果这个工具最终节省了事件, 无疑时最具产值的偷懒形式.
• 求知欲: 见5

3. 习惯

• 好习惯很重要, 因为程序员做的发部分事情都是无意识完成的.
• 初涉某事时, 就应端正态度来学. 开始做事情时, 积极思考, 轻松绝对做的好坏. 干了一段时间后, 就会习以为常, 习惯的力量开始起作用.
• 如果没有养成最有效的习惯, 就试着去培养好习惯, 有了新习惯, 坏习惯自然会消失. 但是不能用”没有习惯”来代替”坏习惯”.

4. 规范与纪律

• 向刚毕业的计算机科学学生很难解释为何需要规范和工程纪律. 一些具有创新精神的程序员将各种标准和规范堪称束缚其创造力的东西, 事实正好相反.
• Form is liberating [形式就是解放]
• 坚持代码规范, 才能真正的交流与合作. 这正优秀的程序员之道怎样同别人融洽的工作和娱乐, 代码便于看懂是对团队成员的要求之一.

5.求知欲与知识资产管理

• 与其他行业相比, 软件开发行业的经验比书本知识价值更小. 在其他行业中, 今天工作肿的收获很可能有助于明天的工作. 在软件行业中, 如果不改掉使用先前编程语言的思维模式, 活着不放弃在旧机器上能用的代码性能优化技术, 你的经验还不如没有. 如果你不能与时俱进, 经验不但不会有所帮助, 反而是个累赘.
• 知识资产管理: Inverst regularly, Diversify, Manage risk, Buy low, sell high, Review and rebalance.
• Goals: Learn at least one new language every year, Read a technical book each quarter, Read nontechnical books too, Take Classes, Participate in local user groups, Experiment with different evironments, Stay current, Ger wired.

6.向高手看齐

• 第一级: 入门级    入门者会利用某语言的基本功能, 能够编写类, 子程序, 循环和条件语句, 会使用语言的许多特性;
• 第二级: 中级       中级程序员已经度过入门期, 能利用多种语言的基本功能, 并会得心应手的使用至少一种语言;
• 第三级: 熟练级    熟练级的程序员对语言或环境有着专业技能. 这一级的程序员也许能精通J2EE的盘根错节. 这些程序员时所在公司的活宝, 很多程序员再也不能超过该层次.
• 第四级: 技术带头人  技术带头人具有第三级的专业才学, 并明白变成工作中只有15%用来和计算机交互, 其余都是与人打交道的. 程序员一般只花30%的事件单独工作, 与计算机交互的事件则更少. 技术带头人会为人写代码, 而非为及其. 真正高手所写的代码, 像水晶一样晶莹剔透, 还配有文档, 他们不会浪费其宝贵的脑力, 去重新阻止用一句注释救恩那个说清楚的某块代码逻辑.

再厉害的编码者如果不重视可读性, 通常只能呆在第三级. 有人之所以写出难以看懂的代码,主要是因为其代码质量太差, 他们没有了解透彻所写的代码, 自然无法使之易读.
当初学者或中级程序员不是错, 当熟练级程序员而非技术带头人也无可厚非. 但如果之道自己该如何改进后, 还总是在初学者或是中级程序员阶段徘徊, 就是你的不对了.

----------Post from: @LiGuoliang.com, 欢迎回来~----------