《UML大战需求分析》-读后感二

活动图将流成分解为一个一个的活动，通过活动的先后顺序来展示流程，而状态机图是从某个事物的状态是如何转变的角度来展示流程，首先确定事物，然后找出状态，状态之间的箭头叫转换，箭头上的文字说明了是什么事情导致状态发生的变化，每一句说明文字都带有主语流程涉及两种以上的角色时应该说明什么角色什么事情导致状态发生变化，不想明或者不好说明转换的具体原因只想表达状态A可以转换为状态状态B，那么可以只画箭头，不加说明。达到该状态后流程直接进入结束状态。
   用例的主执行者在收集工作刚开始时和系统将要发布之前的一段时间内是重要的，二在这两个时间段之间他们是不重要的“....詹妮站在银行的ATM机前，天色很晚。她已经输入她的PIN，正在寻找确认按钮.....”，主执行者是詹妮，目标是在天色黑的情况下很快找到ATM机的确认按钮。
    执行者的范围可以从系统的项目相关人员，用例的主执行者，被设计系统本身，用例的辅助执行者，内部执行者，在例子中公司没有注意系统的项目相关人员，导致系统没有提供完全的服务修改请求蜂拥而至。朱执行者是直接触发用例的执行者组织人或者是和该组织有关系的人，通过这些来描述用户主要场景，与我自己认知不同的是我认为用例必须用用例图来表示，不过语言文本的表示也是挺清晰的，一个编写良好的用例应该具有可读性，无论是业务人员还是软硬件开发人员还是设计人员都可以通过用例来描述需求，关接下来范围是指真正被讨论的系统是什么，主执行者谁有药实现的需求，层次指目标的高低，主成功场景一切都成功的情况下，在第一个一个人准备通过万维网购买股票的情况中这个用例应该是一次处理就能完成的目标处于用户级的目标而第二个则不能从一次中完成，需要多不的处理显然处于概要的目标，两个用例的共同之处有最小保证和成功场景和扩展场景扩展是执行过程中可能遇到的意外情况于用例黑盒子就是不用太关心具体的细节，说的挺对不同的方法适用于不同环境，软件的规模不同对用例的正规程度的要求也是不同的，正规的就按用例模式一项项添加场景，定义，而非完整的是只就场景进行描述，从用例中可以看出部分或者说是主要的需求，用例的目的原来是针对用户，让用户提前知道新系统是什么样的对于可行的需求大纲包括目的和范围、使用的术语、用例等等

之所以需求如此难是因为客户一方希望少出钱功能尽可能多，而软件公司的想法是多拿钱少干活，客户的想法是不断变化的，但这种变化总体是想最后目标迈进的，刻舟求剑的故事说明了对不断变化的客户想法让他们签字确认是无意义的，客户不断的提出问题时一种双赢的效果，说明客户在一直应用此软件，从而软件公司也能得到自己想要的经济等方面的‘赢’。客户肯定是对自己的领域了解的所以开始时他们的需求认知高于软件开发人员不过只有后来开发人员的需求认知高于客户才能真正把软件做好。需求分析的核心是解决软件有没有用的问题而软件设计的核心是解决软件开发成本的问题，越是底层的用户越容易提出需求规格的问题，越是高层越是容易提出需求方面的问题，需求与UML的结合，可以利用结构型的UML图对客户业务进行结构建模，对业务概念等静态结构进行系统化的梳理和提炼，就是对业务概念的梳理和提炼叫做结构建模，业务流程叫做行为建模。
关于面向对象和面向过程，开始的编程就是一行行孤独的代码，后来对于处理复杂的问题只是一行行代码显得杂乱，后来出现了方法，对一些行为的封装，通过调用方法来实现操作目的，后来结构化大型的软件已经不能仅仅通过函数调用来满足，面向对象的C++应运而生。