读《UML大战需求分析》前9章之后，我对这本书的了解达到了一个节点。根据这本书的目录以及各章的名称，我将这本书分成了两部分，第一部分是UML的具体使用方法的概括与讲解，第二部分是具体实例深入运用。 读完第一部分，我做了一些整理以及理解。
首先，是各种图的使用。UML图的实际使用情况：
结构性的UML：类图：必用来分析业务概念。
构件图以及部署图：必用来分析IT基础构架、软件架构等方面的需求。
行为型的UML：用例图：必会使用。
活动图、状态机图、顺序图：必会使用至少其中一种来分析业务流程。
其余图很少或者基本不使用。
类图：实际工作中，我们需要将需求调研中了解到的所有业务对象、人物等列出来，画出他们的关系，反复推敲，才能逐步得到合适的业务模型。所以，类图的实际显示让我们全面系统的了解到涉众之间的关系，若有错漏、冗余，也一目了然，减轻了需求分析的负担。
类图让我们基本弄清楚了业务概念，让后我们就应该弄清楚业务流程了，流程三剑客帮了很大忙。
首先是活动图，这个图基本就是我们以前高中数学学过的流程图，而在需求分析中，他有着自己的步骤；1.明确该流程要达到怎样的业务目的？2.该流程有什么角色参与？主要角色是那些？3.排除异常情况（即分支流程），画出正常情况下的流程，也就是主干流程。4.明确主干流程中的活动及角色。5.逐步增加分支流程，关键的分支流程要表达出来，但也不是全部都要写出来（必要时注解说明）。6.适当控制粒度。7.先画整体，再优化。8.对照优化前后，整理出业务冗余或不合理处与客户交流。
接着是状态机图，思维要点：1.流程是围绕什么事物展开的？2.这个人物有什么样的状态？3.当一个状态可以装换成一个或者两个状态时，这表示分支结构。
最后是顺序图，1.从复杂的流程中的分析出一条条流程，然后将每条流程按以下方法进行解析。2.分析出有什么角色参与到这个流程？3.分析各角色在流程中担任的职责和各角色的专业特色。4.将流程分解为角色之间的交互，想清楚各角色之间的“接口”是怎样的。5.用顺序图将这些“交互”组织起来。6.在上述过程中，不断思考业务流程的合理性，是否可优化或重组。
流程图，顾名思义，就是展示流程的图，只有对整个流程有了清晰的思路，才能找到系统需要做到事情，而流程图是这个找到的过程更加形象具体，不至于有大的纰漏；接下来的就是最常用、最不可缺少的用例图了。
用例图：1.精简（在客户能准确理解的基础上）。2.用客户的语言去描述。3.全面而有重点，详述重点、难点。4.立于客户而又高于客户，不盲从。5.细化用例，底层用例的粒度控制大体一致，灵活把握。
用例表： 
部署图、构件图：1.用于描述客户当前的IT架构。2.列出客户在技术框架方面的要求。3.针对第2点的要求，用部署图和构件图来设计新系统的技术框架。4.与客户沟通和确认这些内容：客户IT架构环境需要怎样的构造？新系统将如何部署在客户的IT环境中？ 这两种图通常一起使用，主要用于两种情况：1.待开发的系统与第三方系统、原有系统、某些老系统等交互，这时可用构件图描述交互要求。2.客户对软件设计有特殊要求时，比如：利用客户新引进的工作流引擎等。 这两种图主要用来描述非功能性要求，还有如安全性、易用性、性能等无法用UML描述的非功能性要求，大多用文档的形式描述。
总的来说，UML的作用就是进行结构建模和行为建模，使整个需求分析快速而全面不会产生太大的纰漏，根据这两种建模，是整个软件的编写脉络清晰可见。需求分析的作用无非就是明确项目背景，找到用户或者说涉众，解析项目业务流程，明确并解决客户问题。而UML就是用来解决后面三个问题，UML说到底是一种工具，使我们的工作变得方便而且不容易出纰漏，作者在讲解的时候，都会给出一些小的实例，是讲解更生动，通过例子也更容易理解，相信后面的实际运用的例子会更加精彩。