《uml大战需求分析》阅读笔记06

                《uml大战需求分析》阅读笔记06

 这次我主要读了uml大战需求分析的最后两章，并且对这本书有一个总结

总的来说，UML的作用就是进行结构建模和行为建模，使整个需求分析快速而全面不会产生太大的纰漏，根据这两种建模，是整个软件的编写脉络清晰可见。需求分析的作用无非就是明确项目背景，找到用户或者说涉众，解析项目业务流程，明确并解决客户问题。而UML就是用来解决后面三个问题，UML说到底是一种工具，使我们的工作变得方便而且不容易出纰漏，作者在讲解的时候，都会给出一些小的实例，是讲解更生动，通过例子也更容易理解，相信后面的实际运用的例子会更加精彩。

之所以需求如此难是因为客户一方希望少出钱功能尽可能多，而软件公司的想法是多拿钱少干活，客户的想法是不断变化的，但这种变化总体是想最后目标迈进的，刻舟求剑的故事说明了对不断变化的客户想法让他们签字确认是无意义的，客户不断的提出问题时一种双赢的效果，说明客户在一直应用此软件，从而软件公司也能得到自己想要的经济等方面的‘赢’。客户肯定是对自己的领域了解的所以开始时他们的需求认知高于软件开发人员不过只有后来开发人员的需求认知高于客户才能真正把软件做好。需求分析的核心是解决软件有没有用的问题而软件设计的核心是解决软件开发成本的问题，越是底层的用户越容易提出需求规格的问题，越是高层越是容易提出需求方面的问题，需求与UML的结合，可以利用结构型的UML图对客户业务进行结构建模，对业务概念等静态结构进行系统化的梳理和提炼，就是对业务概念的梳理和提炼叫做结构建模，业务流程叫做行为建模。
关于面向对象和面向过程，开始的编程就是一行行孤独的代码，后来对于处理复杂的问题只是一行行代码显得杂乱，后来出现了方法，对一些行为的封装，通过调用方法来实现操作目的，后来结构化大型的软件已经不能仅仅通过函数调用来满足，面向对象的C++应运而生。两个用例的共同之处有最小保证和成功场景和扩展场景扩展是执行过程中可能遇到的意外情况于用例黑盒子就是不用太关心具体的细节，说的挺对不同的方法适用于不同环境，软件的规模不同对用例的正规程度的要求也是不同的，正规的就按用例模式一项项添加场景，定义，而非完整的是只就场景进行描述，从用例中可以看出部分或者说是主要的需求，用例的目的原来是针对用户，让用户提前知道新系统是什么样的对于可行的需求大纲包括目的和范围、使用的术语、用例等等

    最后总结一下结构图有六种，行为图有七种。这本书中的所有内容都不能全部都信，都要按照自己的理解来消化知识。