第5章描述了表示法-UML图，分为两大类，即描述静态结构的结构图和描述动态行为的行为图。在这不一一列举，实践地时候可以去查如何使用相应的表示法。这些表示法可不是一出来就一成不变的，而是需要经历概念模型、逻辑模型和物理模型的演变，在项目开发的不同阶段使用不同的模型。
问题：1. 这么多的表示法，我们在实践中都要一一画出吗？
2. 在项目开发的不同阶段，都应该相应地使用哪些表示法。
对于问题一，答案是不必使用全部表示法，就像RUP过程理论一样，它是力求一种通用的理论，但在实际的项目过程中，往往是理论的子集。对于问题2，后面会结合实战来分析。
第6章描述了软件开发过程，首先描述了成功项目的特征：存在很强的架构愿景（从本质上讲，好的架构应该是面向对象的，由组件构成）；应用了管理良好的迭代、增量式开发生命周期。追求理性的开发过程，理透不同开发过程的关键方面，倡导核心观念是理解不同实践过程的关键。过程被定义为宏观过程和微观过程，它们不同在于宏观过程关注的是总体软件开发生命周期，而微观过程关注的是具体的分析和设计技术。我们以RUP生命周期为基本，参考其他。
宏观过程，宏观过程确定了系统将以演进式的方式，通过不断优化，最后得到产品系统。其过程可以从两个维度进行描述，即内容和实践--做什么和什么时候做。内容维度描述了角色、任务和工作产品，也可以从科目（需求、分析与设计、实现、测试、部署+项目管理、配置和变更管理、环境）来描述，从逻辑上对内容进行分组。时间这一维描述了这个过程的生命周期，可以从里程碑（范围已理解、架构已稳定、系统已准备好进行最终用户测试、系统已准备好进行部署）、阶段（初始、细化、构造、移交）和迭代的角度来描述。
微观过程（即宏观的分析与设计科目），如我们从两个维度来描述宏观过程一样，我们也将从两个关键的维度来描述微观过程，即抽象层次和内容（活动与工件）。在微观过程中，传统的分析阶段和设计阶段被有意地模糊了，取而代之的是进行不同层次的抽象，形成以连续光谱。分析关注的是行为，而不是形式；设计时创造一些元素，它们提供了分析元素所要求的行为。架构和组件的确定过程对于微观迭代具有指导意义。组件与架构比起来抽象层次更低。具体的活动包括去顶元素、确定元素间的协作、确定元素间的关系、确定元素间的语义，相应的每轮活动都会产生相应的工件。
第7章聚焦于面向对象开发实战，例如人员管理、发布管理和质量保证。可能对于技术人员来说，这些主题极度乏味，但它们是成功建造复杂软件系统必须面对的现实。
1. 风险管理与制定计划
2. 人员配备。面向对象资源配置一般比传统的方式要少，很多工作不是大爆炸式的。其项目中主要有三类角色：项目架构师（复杂演化和维护系统架构）、组件主管（对项目进行最初的抽象，组件主管是一个类聚集与之相关的机制的最终拥有者，同时也负责在系统演化过程中对系统进行测试和发布）、应用工程师（通常完成一项或两项职责）。在更大型的项目中，还需要其他不同的开发角色来完成工作。
3. 配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。软件配置管理可以提炼为三个方面的内容：版本控制、变更控制和过程支持。
4. 建立复用制度。
。。。
