<<UML大战需求分析>>阅读笔记(2)

<<UML大战需求分析>>阅读笔记(2)》

此次读了uml大战需求分析的第三四章，我发现这本书讲的特别的好，由于这学期正在学习设计模式这本书，这本书就讲究对uml图的利用，突然发现uml特别有用处，而且作用特别的大，它可以在写代码之前，可以对代码有一个很好的框架分析。

对于第三章的内容来说，作者通过分析业务的模式，来了解uml图，面向对象比面向过程更高级，无需注重结构化编程和编程基本功。面向对象编程就是把代码放进一个个类中而已。将业务概念直接转变为类，赋予合适的属性和操作，就可以解决问题。需求阶段的建模与设计阶段的建模有很大的区别。需求建模是对业务和需求的提炼，优秀的需求建模是设计建模的良好开始，但是一个优秀的设计模式还需要考虑更多的设计上的事情，并不是将业务模型直接转化为设计模型就可以解决问题的。通过学习类的作用，什么是类，什么是类图，以及如何来识别一个类，类主要包括直线关系，也就是关联关系，包含关系，继承关系，以及作者说的所谓的依赖关系，类是某一样东西的抽象，但是对象是一个具体的东西，需求分析时，我们接触的是一个个具体的东西，比如说见到一个个具体的人，接触到一份份具体的业务数据等，这些具的东西其实就是对象。而我们分析需求不能就事论事，我们需要将这些对象提炼为类，这样的分析才更具有代表性。软件系统并不是用来解决具体某次事件中的一些问题,而是希望能够解决某一类问题。

类图是进行结构建模的重要工具，可对需求分别进行结构建模和行为建模，帮助我们更加透彻的理解客户业务，整合出符合系统目标的需求规格。对活动图的分析业务的流程中，活动图可以发现一些问题，通过这些问题你可能会牵扯出一大堆的业务逻辑，引发更深入的思考。在对活动图进行规划时，要开始画一些流程，明确该流程要达到怎样的业务目的，该流程有什么样的角色参与，哪些是主要的角色，排除异常，画出正常情况下的流程，这就是流程的主干，通常是线性的流程，线性流程是指一条线从头走到尾的流程。中间没有分支，明确流程主干中的活动涉及的角色，逐步增加分支流程，关键的分支流程都应该分析出来，但是要注意并不需要画出所有的异常情况，必要时通过注解或者一些文字说明，要控制活动的粒度，画出反映当前情况的流程，再画出优化后的流程，对比前后的差异，整理出业务需要调整的地方，客户管理需要改善的地方，尽快与客户确认。整体上规划好所有流程并优化好每一个流程是难度很高的工作，需求分析工作其实也是业务流程整合与优化的咨询工作，我们要为客户提供用价值的需求方案。