在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%）的具有重要架构意义和高价值的用例）。用例应该包含所有涉众关注点的事物。
准则：
以无用户界面的本质风格编写用例；排除用户界面而关注参与者的意图。
编写简洁的用例。
编写黑盒用例，不对系统内部工作、构件或设计进行描述。而是通过职责来描述系统。
采用参与者和参与者目标的视点。


http://www.blogjava.net/ronghao 荣浩原创，转载请注明出处：）