1.介绍
【使用uml的方式】
把uml当做草图sketch。顺向工程forward engineering在写代码前会绘制uml。而逆向工程reverse engineering根据已有的代码绘制uml来帮助理解。
把uml当做设计图blueprint是为了完整性completeness。在顺向工程中工作是构建详细设计的设计师会绘制设计图来让程序员更好的写代码实现。这个设计需要足够完整，里面所有的设计决策design decisions都被列出laid out，让程序员能够轻松的照着做而只需要一点点思考（the programmer should be able to follow it as a pretty straightforward activity that requires little thought）。
【标记和元模型notation and meta-model】
记号notation就是在模型中的图形材料graphic stuff，比如类图中的class、association、multiplicity。
方法论者寻找方式来提供方法的严谨性而不想牺牲其用处，一种方式就是定义一个元模型meta-model：经常是一个类图，定义该语言的观念。
【uml图】
activity procedural and parallel behavior
class class, features, and relationships
communication interaction between objects; emphasis on links
component structure and connections of components
composite structure runtime decomposition of a class
deployment deployment of artifacts to nodes
interaction mix of sequence and activity diagram
object example configuration of instances
package compile-time hierachic structure
sequence interaction between objects; emphasis on sequence
state machine how events change an object over its life
timing interaction between objects; emphasis on timing
use case how users interact with a system
2.开发过程
当你听到人们讨论uml，你经常听他们讨论统一软件开发过程（RUP = rational unified process）。
【迭代iterative和瀑布模式watarfall process】
两者必要的区别是你怎样将一个项目分解成小块（small chunk）。
瀑布模式分解项目基于活动activity。开发软件，需要进行某些活动：需求分析、设计、写代码、测试。我们1年的项目可能有2月的分析阶段、4月的设计阶段、3月的编写代码、3月的测试阶段。
迭代模式通过功能子集subsets of functionality来分解项目。你可将一年分层多个3月迭代。第一个迭代中，你完成需求的1/4，并进行1/4的完整的软件周期循环：分析、设计、代码、测试。第一个迭代完成的时候，你有一个完成了1/4功能需求的系统。
你也可以混合模式，阶段交付staged delivery：分析和高级设计先以瀑布模式完成，然后代码和测试分成迭代完成。
一个跌代的普遍技术是使用时间限制time boxing，这强制一个迭代在一个固定时间长度完成。
·自动化回归测试automated regression tests：允许你很快检测出在你做改动时引起的问题。一个好的规则是单元测试的代码和产品代码差不多大。
·重构refactor
·持续集成continuous integration：保持一个团队同步team in sync，避免惨痛的集成循环painful integration cycle。
【预测和适应计划predictive and adaptive planning】
使用预测计划，一个项目有两个阶段：第一个阶段完成计划而且很难预估，但第二个阶段更好预估因为计划已经完成。
使用适应性计划，预测被视为错误的。我们需要面对现实，在一个软件项目中会有持续的改动。改动是被项目的交付者deliver控制的，但尽管项目可控，但不可预测。
但适应性计划也进行计划，但这些计划被当做一个基线baseline来评估assess改变带来的结果 而不是对未来的预测。适应性计划过程可以固定fix价格。
两条建议：
·不要做预测性计划，除非你有精确的需求而且你有自信他们不会严重的改变。
·如果你得不到精确、稳定的需求，使用一个适应性计划方式。
一个适应性计划当然需要一个迭代过程。
【敏捷开发agile process】
敏捷是一个涵盖性术语，包括共享同一个公用的值value和准则principle的集合 的许多过程。这些过程的例子有：极限编程extreme programming(XP)，scrum，功能驱动开发feature driven development(FDD)，crystal，DSDM(dynamic systems development method)。
敏捷过程很好的适应他们的本质nature，也是非常以人为中心。他假设一个项目的成功的关键因素是项目中人们的质量和他们怎样更好的以人类的方式工作在一起。
敏捷开发倾向于使用短的、时间限制的迭代，经常1个月或更少。因为他们不附加太多重心到文档上，他们不把uml绘制蓝图blueprint mode。他们大多把uml用作草图sketch mode。
敏捷开发少于形式，认为形式ceremony让改变变得困难，并违背有天赋的人的成果works against the grain of talented people。
【统一软件开发过程rational unified process】
尽管rup叫过程，但实际上是一个过程框架，提供一个词汇和宽松的结构来谈论过程。用rup第一件事是选择一个开发案例development case：你将在项目中使用的过程。
所有RUP项目应该有下面4个阶段：
·inception开端 给一个项目一个初始的评估evaluation。这里你决定是否提交足够的钱去做一个详细制作elaboration phase
·elaboration 指出项目的主要用例，并迭代开发软件。at the end of elaboration, you should have a good sense of the requirements and a skeletal working system that acts as the seed of development.In particular, you should have found and resolved the major risks to the project
·construction 继续构建过程，开发足够的功能以发布
·transition 包括不同的不需要迭代的后期活动，包括部署到数据中 心、用户培训等。
【找到项目合适的过程fitting a process to a project】
模式：describe common ways of doing things and are collected by people who spot repeating themes in designs.模式是一些设计的例子。
在每个迭代的最后，进行一次迭代回顾iteration retrospective。团队集合一起考虑事情进展怎样、能够怎样改善。列出下面3类：
·keep保持：进行得好的事情，确保继续
·problem问题：工作不好的方面
·try尝试：进程中用于改善的改变changes to your process to improve it
【在过程中找到合适的uml】
【需求分析】
指出软件的用户和消费者想要系统做的，可能需要的uml技术：
·用例：描述用户和系统怎样交互
·例图：从概念角度，是构建一个领域严格词汇的好方式
·活动图：展示组织的工作流，显示软件和人类活动的交互，显示用例的内容
·状态图：如果一个概念有一个有趣的生命周期，且不同的状态和事件会改变状态
需求分析最重要的是合用户和消费者交流。记住重要的是用最少的标记来绘制uml。
【设计】
有用的技术：
·类图：从软件角度，显示类和相互联系
·时序图：为普遍场景scenario。从用例中找出最重要和有趣的场景，来指出在软件中发生了什么
·包图：显示软件的大规模组织
·状态图：类的复杂生命历史
·部署图：软件的物理布局
【文档】
package diagram makes a good logical road map of the system.帮助我理解系统的逻辑片、看到其中的依赖关系、更好的控制他们。 部署图显示高级的物理图。
如果一个类有复杂的生命周期行为，绘制一个状态机来描述。
如果引入一个特别复杂的算法，我考虑使用一个活动图，只要他能让我更好的理解这块代码。
如果发现概念来了很多次，我使用模式pattern来抓取其基本思想。
写文档的一个重要事情是你没有采用的设计选项和你没有选择的原因。