在OO开发中，至关重要的能力是熟练地为软件对象分配职责。

在面向对象分析中（OOA），强调的是在问题领域内发现和描述对象。OOA关注从对象的角度创建领域描述，OOA的结果可以表示为领域模型。需要注意的是，领域模型并不是对软件对象的描述（区别于软件中的对象类），它是真实世界领域中的概念和想象可视化。

在面向对象设计（OOD）中，强调的是定义软件对象及它们如何协作以实现需求。（类图与顺序图）

迭代开发是OOA/D成为最佳实践的核心。建议迭代的时间在2-6周之间，小步骤、快速反馈和调整。迭代的一个关键思想是时间定量，或时长固定。
1、在第一次迭代之前，召开第一个时间定量的需求工作会议（两天）。业务和开发人员需要出席。
   a、高阶需求分析。仅仅确定用例和特性的名称，以及关键的非功能性需求（性能，可伸缩性等等）。
   b、通过架构师和业务人员，从高阶列表选择10%列表项（例如，30个用例名中的10%，3个）。这3个用例      需要具备：具有重要的架构意义；具有高业务价值；具有高风险（例如，可处理500个并发交易）。标      识这3个用例：UC2，UC11和UC14。
   c、剩下的一天半对这3个用例的功能和非功能性需求进行详细的分析。
2、在第一次迭代之前，召开迭代计划会议，选择UC2，UC11和UC14的子集，在特定的时间内（例如，四周）    进行设计、构造和测试。要注意，并不是在第一次迭代中就要构造全部的3个用例，可以将其分解为一系   列更为详细的迭代任务。
3、在三到四周内完成第一次迭代（严格遵守时间）
   a、在开始的两天内，开发者在架构师指导下分组进行建模和设计工作。白板，UML草图，界面、讨论。
   b、编程。注意UML草图只是参考
   c、测试
   d、结束前一周，检查是否能够完成初始迭代目标，如果不能，缩小迭代范围。
   e、最后一周的周二，冻结代码，集成和测试所有代码，建立迭代的基线。
   f、周三上午，演示此局部系统，展示早期可视进展，要求反馈。
4、在第一次迭代即将结束时（最后一周的周三周四），召开第二次需求会议，对上次会议的所有资料进行复   查和精化。然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，一到两天详细分析。这项工   作完成后，大约20-25%的用例得到了详细记录。
5、周五上午，举行下一迭代的迭代计划会议。
6、相同步骤2次迭代。
7、反复四次迭代和五次需求会议，这样在第四次迭代结束后，可能已经详细记录了80-90%的需求，但系统只   实现了10%。
8、大概推进了整个项目过程的20%。up里，属于细化阶段。此时，可以估计整个项目的工作量和时间。
9、一般不再需要需求会议，需求已经稳定了。接下来是一系列为期三周的迭代，在最后一个周五召开的迭代   计划会上选择适宜的下一步工作。
  
早期的迭代要致力于核心架构的构造，应该首先处理困难的和具有风险的事物。

建模（构建UML草图）的主要目的是为了理解，而非文档。只需对设计中不常见、困难和棘手的一小部分问题建模和应用UML。不要单独建模，而是结对（或三个人）在白板上建模。并行的创建模型（例如，类图和顺序图交替开始）。UML细节是否精准不重要，重要的是人员能够互相理解。坚持用最简单、常用的UML元素。开发者应该为自己进行OO设计建模，而不是创建模型图后交给其他人实现。

UP的核心思想是：短时间定量迭代、进化和可适应性开发。

初始阶段是建立项目共同设想和基本范围的比较简短的起始步骤。包括确定大部分用例名称，对10%的用例进行分析，关键的非功能需求的分析，业务案例创建和开发环境的准备。包含第一次需求研讨会，并为第一次迭代制定计划。要解决的主要问题：涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究。

用例是文本形式的情节描述，特别注意，用例是文本不是图形！用例建模主要是编写文本的活动，而非制图。用例名称应使用动词开头。
参与者的三种类型：主要参与者，协助参与者，幕后参与者。
用例的三种常用形式：摘要，非正式，详述（在第一次需求会中，详细的编写其中少量（例如10%）的具有重要架构意义和高价值的用例）。用例应该包含所有涉众关注点的事物。
准则：
以无用户界面的本质风格编写用例；排除用户界面而关注参与者的意图。
编写简洁的用例。
编写黑盒用例，不对系统内部工作、构件或设计进行描述。而是通过职责来描述系统。
采用参与者和参与者目标的视点。
这些天主要在做一些翻译的事情。周日的时候抽了半天时间给一本书做了一章的试译。似乎并不是太意外，编辑今天告诉我试译没有通过，与他们的要求还有一定的差距。然后他把他批注过的试译发给了我。看得出编辑是一个非常负责任的人，几乎所有的句子都被他详细的review过。总结了一下原因：
1.没有经验。这是我第一次翻译书，犯了很多常识性错误。例如少用被字句，章号用阿拉伯数字，图题和图中需  要翻译的英文应该对应，我、你、你的这些代词，能不翻译尽量不要翻译等等。
2.对专业知识不熟悉。这本书是关于swing,java2d\3d的，而自己在这方面没有什么经验，只是使用过Swing，这  样就使一些专业术语翻译很不到位。对英文的理解会存在问题。
3.自己翻译的理解问题。一些句子不通顺，不好理解，措辞的不当。其实这个问题我认为主要是匆忙不负责任引  起的。
尽管被cut了，但我认为自己还是学到了很多东西的：一些常用的翻译技巧和注意事项，对相关知识不熟悉时不要随便翻译，遇到难度的句子要做批注，翻译完毕后一定要review等等。感谢华章图书的编辑，他让我懂得许多。也让我长长出了口气：不用再去网上找java2d/3d方面的文档和书籍，不用狂补相关的知识。另外要感谢的是阿敏总司令，是他介绍给我这个机会，但是我没有把握住。
翻译，并不是一件简单的事情。
UML有三种使用方式：用作草图绘制，用于蓝图绘制，用于程序编制。
倾向于将UML用于草图绘制，绘制草图的实质是选择，重点是进行交流，常用的介质是白板。
草图是故意不完备的，要突出重要的信息。草图是探究性的，蓝图是定义性的。草图用于正向工程（设计阶段），蓝图用于逆向工程（根据已有的代码导出）。详细文档应该根据代码生成。

UML最重要的是类图和顺序图。

瀑布风格和迭代风格
瀑布风格是基于活动来分解项目的，迭代风格根据功能子集来分解项目。
迭代的一种常用技术是时间框定法，迫使各次迭代的时间长度固定。通过定时搁置功能，使人们能够在搁置日期和搁置功能之间进行明智的选择。

敏捷过程是强适应性的过程。敏捷方法强调项目成功最重要的因素是人的素质以及人之间的良好协同，敏捷方法倾向使用时间框定的短小迭代。每一次迭代结束时要进行一次迭代回顾。

RUP本质上是一个迭代过程，分为四个阶段：初始，细化，构造，移交。
需求分析最重要的是与用户及客户的交流。

类图
类图表述系统中各个对象的类型以及其间存在的各种静态关系。
对不重要的事（如日期或布尔值，一般说，值类型）使用属性，对较为重要的类使用关联。
非常反感那些除了一组域及其get/set方法没有行为的类。如果你在利用get方法重复调用数据，这预示着某一行为应该移往具有数据的对象。
依赖应该单向，依赖越少越好，特别谨慎循环依赖，尤其反对包间的循环依赖。对类使用依赖最常见的情形是阐明瞬间关系，比如，把一个对象作为参数传递到另一个对象时。
不要试图使用对你可用的所有图示法，保持图示简单，集中考虑关键方面。绘制类图时总以使用某种形式的行为技术为宜。

顺序图
尽量省去回送。
单一职责，提倡分布式控制（把处理分散到多个对象里去）。
减少过程式编程，如if/else，改用多态解决类似问题。
把顺序图看作各个对象如何交互的形象化表示而不是一种对控制基理的建模方法。顺序图擅长示明对象间的协作，不擅长于示明行为的精确定义。

CRC卡
CRC的一个重要部分是认识职责。任意一个类都可以用少量职责对其概括。对具有三项以上职责的卡片提出质问，是否应该把类分解，或把职责合并成一个更高层次
的概述。
工作流开发已经有一段时间了，这里把自己的一些想法小结一下。仅仅就工作流引擎来说，不包括一些外围的实现，例如流程定义器，管理控制，工作项列表等。
工作流引擎其实就是一个状态机，只不过在状态变化的过程中加入了其他一些工作。我把工作流引擎的职责理解为以下四个方面：
1、对工作流模式的支持。
   这无疑是最重要的部分，状态的变迁往往取决于不同模式的选择。支持的模式越多则客户的开发代码会越少。衡量一个工作流引擎的技术水准很大程度取决于引擎支持模式的多少。
2、工作流变量的传递和转换。
   工作流引擎通过工作流变量与外部应用交互，工作流变量在各个活动节点以及父流程与子流程之间传递。变量除基本类型（String,int等）以外，也需要支持一些复杂的数据类型（例如对象，以一种配置映射的方式）。这里还涉及到一个上下文的问题。
3、任务项的分配。
   任务项的分配往往和工作流组织权限联系起来，其实工作流组织权限存在的目的就是决定任务项分配，决定由谁来完成这个工作项。工作项涉及到的内容也比较多，比如工作项的回退，撤回等等。
4、调用外部应用。
   单纯的表单推动已经不再适用，活动节点本身需要支持许多的业务操作，而这些操作与引擎本身是无关的，与外部的应用有关，所以就需要引擎提供一种调用外部应用的机制。外部应用可以是javabean,webservice,rcp等等形式。
除去上述四方面还有一些外围的工作：例如时间服务，节点的事件机制等等。
对客户而言，他们需要的仅仅只有两个接口：任务项管理接口（比如提交任务项，委派任务项等等）和流程状态管理接口（比如启动一个新的流程实例，推动流程流转等等）。在理想的情况下，给用户提供一个封装完全的提交页面和父类Action也是很好的一种方法。
今天终于有空看看了Fielding的rest论文，没有看完，很多文字确实难懂，但有些还是很有感触的，做个记号。
一个软件架构是一个软件系统在其操作的某个阶段的运行时元素的抽象。
架构元素：组件，连接器，数据，配置。
架构风格：一组协作的架构约束。
一种特定的架构可以由多种架构风格组成。
关键关注点的架构属性
性能
最佳的应用性能是通过不使用网络而获得的。这意味着对于一个基于网络的应用，最高效的架构风格是在可能的情况下能够将对于网络使用减少到最少的架构风格。
可伸缩性
表示在一个主动的配置中，架构支持大量的组件或大量的组件之间交互的能力。
简单性
对组件之间的功能分配应用分离关注点原则。使得单个的组件足够简单，更容易被理解和实现。
可修改性
基于网络的系统的一个特殊的关注点是动态的可修改性，它要求在对一个已部署的应用做出修改时，无需停止和重启整个系统。包括：可进化性，可扩展性，可定制性，可配置性，可重用性。
可见性
能够通过限制必须使用通用性的接口，或者提供访问监视功能的方法，来影响基于网络的应用中交互的可见性。在这种情况下，可见性是指一个组件对于其他两个组件之间的交互进行监视或仲裁的能力。
可移植性
能够在不同的环境下运行。
可靠性
当在组件、连接器或数据之中出现部分故障时，一个架构容易受到系统层面故障影响的程度。