本文为个人原创，转载请注明出自：http://jackma.cnblogs.com/
Author：JackMa
在阅读完第一部分“绪论”后写写读书笔记，整理了一下思路，同时记录一些有用的信条。本文根据第一部分的内容和个人的思路分五节，同时也尽量使整篇文章可以作为一篇独立的介绍文章。
- 1、一些技术主题的关系。
- 2、软件工程的一堆术语。
- 3、Iterative VS Waterfall 及Iterative教条。
- 4、敏捷建模实践经验。
- 5、浅谈UP。
1、全书的核心和各技术主题的关系
首先给出一张图说明各核心内容和各主题的关系。
首先OOA（Object Oriented Analysis）和OOD（Object Oriented Design）是整本书的核心。显然OOA只是需求分析的一部分所以被包含在其中。而DP（DesignPatter）和GRASP（General Responsibility Assignment Software Pattern）是职责驱动设计（Responsibility-Driven Design）原则，是OOD中的经验和典范，所以在OOD之中。
脱离开发环境和过程去谈论分析设计是空洞的。整个介绍需要一些案例作为背景。OOA/D在开发的过程中应何时使用，如何使用，显然需要一个语境。而迭代开发（IterativeDevalopment）和UP（UnifiedProcess）就是这样一个描述OOA/D实践的语境。所以上图的一个大背景是ID和UP。在旁边的四个小框是分析设计中的一些关键步骤，而去掉“定义”二字则会是我们需要获得的制品。
在图中另一个大的部分是UML（Unified Modeling Language），统一建模语言，是一种图形法。是我们在分析设计中一种沟通、思考、表达的工具。而UML紧紧通过一些制品和整个开发发生关系。Craig Larman也一再表示，不要将UML看得很重，不会因为使用了UML,分析设计就会得到很大提升或改善。UML isn't Silver Bullet。方法和思想才是最重要的，UML紧紧是工具。所以Craig Larman也建议UML作为草图使用。同时强调UML作为不同的透视图（概念、规格说明、实现）的使用。
对于两个核心当然要着重的说明一下概念：
Analysis：强调的是调查研究而非解决方案。
OOA：在问题领域内发现和描述对象。
Design：满足需求的概念上的方案。
OOD：定义软件对象以及它们如何协作实现需求。
用一句话说明书的内容，就是要教给我们OOA/D中的“荒岛”技能：熟练地为软件对象分配职责。
2、软件工程的一堆术语
第二节着重搞清楚迭代、过程、UP、敏捷这些概念及关系。
迭代（Iterative）是相对瀑布（Waterfall）而言的。相信学过软件工程的都多少有了解。在这里我更倾向将它们看作是一种价值观。是信奉经典的waterfall还是先进的Iterative？
软件开发过程（software development process）：描述了构造、部署及维护软件的方式。属于方法论层面。或者抛开一些概念，过程就是描述怎样做的。强调的是How。又或者说，根具信念的不同，过程就分为Iterative和waterfall两种了。
UP：是一种流行的、OO的、迭代的开发过程。
RUP：则是Rational公司对UP作精化后的产物。
AgileUP：UP是十分灵活和开放的，它鼓励引进其他迭代方法中有用的实践。而引入了大量敏捷（Agile）实践和方法的UP，就称为AgileUP（敏捷UP）。
3、Iterative VS Waterfall 及Iterative教条
Iterative和Waterfall我们都耳熟能详了，但是书中的一段话绝对震撼的让我们重新认识“一直以来，成功/失败的研究表明，瀑布模型和软件项目高失败率具有极大关系，对它的推广源于信念和风闻，而不是具有统计意义的证据。研究证实，迭代方法与较高的成功率、生成率和低缺陷率具有关系”。这样就再次提醒我们实践出真知（即便这对段话）。详细的介绍，众多的论据都是要表明一个论点“You should use iterative development only on projects that you want to succeed.——Martin Fowler”
以下是一些Iterative的教条：
- 迭代是固定时间的或时间定量的，而系统是增量式增长的。
- 迭代输出的不是实验性或即将丢弃的原型，迭代开发也不是构造原型，输出的是最终系统的产品子集。
- 大部分迭代方法建议迭代时间在2-6周之间。
- 迭代的关键思想是时间定量(timeboxed)。
- 快速地实施一小步的方式可以得到快速的反馈，团队可以从反馈中挖掘出至关重要和实际的观点，并修改和调整对需求或设计的理解。
- 如果你发现自己在“迭代”项目中出现开发前确认大多数需求，编程前试图创建完整、详细的规格说明或UML模型和设计，那么说明瀑布思维已经无情的折磨着这个项目。
4、敏捷建模实践经验
- 建模和模型的目的主要用于理解和沟通，而不是构建文档。
- 只需要对涉及空间中不常见、困难和棘手的一小部分问题建模和应用UML。
- 尽可能使用简单的工具。最好在白板上画UML草图，使用数码相机捕获图形。
- 不要单独建模，而是结对或三人在白板上建模。同时记住建模的目的是发现、理解和共享大家的理解。小组成员要轮流画草图，以使每个人都参与其中。
- 并行的创建模型。例如可以同时勾画动态的交互图和静态的类图。
- 使用简单、常用的UML元素。UML细节是否精准并不重要，关键是建模者能够互相理解。
- 所有模型都可能使不准确的，最好只是将其视为一次探索。
- 可发者应该为自己进行OO设计建模，而不是创建模型图后交给其他编程者去实现。
5、浅谈UP
UP的核心思想：短时间定量迭代、进化和可适应性开发。
UP的一些关键实践 ：
- 在早期迭代中解决高风险和高价值的问题。
- 不断地让用户参与评估、反馈和需求。
- 在早期迭代中建立内聚的核心框架。
- 不断地验证质量；提早、经常和实际地测试。
- 在适当的地方使用用例。
- 进行一些可视化建模（使用UML） 。
- 认真管理需求。
- 实行变更请求和配置管理。
UP阶段（Phase）：
UP项目将工作和迭代组织为四个阶段：初始（Inception）、细化（Elaboration）、构造（Construction）和移交（Transition）。
注意和WaterFall的阶段不同，UP在每一个阶段都包含多个科目（活动）。只是每个阶段中各个科目的工作量不同，侧重不同。以下是一幅概要的各个阶段的科目工作量图。
UP科目（discipline）和制品（artifact）:
科目（discipline）：科目是在一个主题域中的一组活动（及相关制品）。
制品（artifact）：是对所有工作产品的统称，如代码、Web图形、数据库模型、文本文档、图、模型等。
（注意UP的一个关键内涵是：“所有活动和制品都是可选的”。或许除了代码^o^。）
在书中只关注三个科目中的制品：业务建模、需求和设计。
Agile UP
以下是一些在UP上采用敏捷方法的示例：- 使用UP活动和制品的简集。
- 需求和设计是在一系列迭代中，是基于反馈而产生的。
- 以敏捷建模实践应用UML。
- 对于整个项目不应有详细计划。应该制订估计结束日期和主要里程碑的高阶计划（阶段计划）。 不要对里程碑详细定义细粒度的步骤。只能预先对一个迭代制订更为详细的计划
后语
感觉本书的绪论写得很不错。有如一幅OO和UP的鸟瞰图。一个美丽的公园地图已经到手了。接下来就按照推荐的路线图进行游览吧。继续写好游记。只希望工作上不要太紧张。