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

UML英文全拼是unified modeling language 就是统一建模语言。
 UML就是一种软件开发中帮助我们设计的标准，虽然说是建模语言但是它是图形，图形能更清楚的表达我们对软件的想法。UML不仅可以服务于开发人员它也能很好的为做需求的人员服务，并且通过UML能更好的和客户沟通。
  UML图的分类有结构型的图（类图、对象图、构件图、部署图、包图），行为型的图（活动图、状态机图、顺序图、通信图、用例图、时序图），两者分类的根据是结构型的图是某种结构在某段时间内饰静态的、稳定的，而作为型的图是动态的。
  类图，由属性方法组成，标题是类名，而对象图同样由属性和方法构成不同的是它的标题是对象就是类的实例化后的对象，构件图，就是用来描述软件内部物理组成的一种图，比如一个权限构件由逻辑、数据操作、数据库提供数据构成，部署图，用来描述系统如何部署，本系统和其他系统是什么关系的一种图，节点表示物理设备，节点之间的线条表示节点间的物理连接关系，包图，就是为了避免类太多导致图太乱而将类图打包的一种结构型的图。
  活动图，表达一个顺序流程，以起床为例， 实心圆开始然后起床然后洗漱然后吃早餐然后出门上班最后市环形圆结束，状态机图，是从某个物品的状态如何变化的角度来展示流程以请假条为例
可以看到矩形框里对应的请假条的状态，而线条上的是到达这个状态的动作或者是条件动作，顺序图，一个事情分几个环节，由几个角色分工完成点菜为例
 
用例图，表达的是某种角色通过系统能够做什么
 
时序图，表示某种东西的状态随时间变化而变化的一种图
接下来是需求，之所以需求如此难是因为客户一方希望少出钱功能尽可能多，而软件公司的想法是多拿钱少干活，客户的想法是不断变化的，但这种变化总体是想最后目标迈进的，刻舟求剑的故事说明了对不断变化的客户想法让他们签字确认是无意义的，客户不断的提出问题时一种双赢的效果，说明客户在一直应用此软件，从而软件公司也能得到自己想要的经济等方面的‘赢’。客户肯定是对自己的领域了解的所以开始时他们的需求认知高于软件开发人员不过只有后来开发人员的需求认知高于客户才能真正把软件做好。需求分析的核心是解决软件有没有用的问题而软件设计的核心是解决软件开发成本的问题，越是底层的用户越容易提出需求规格的问题，越是高层越是容易提出需求方面的问题，需求与UML的结合，可以利用结构型的UML图对客户业务进行结构建模，对业务概念等静态结构进行系统化的梳理和提炼，就是对业务概念的梳理和提炼叫做结构建模，业务流程叫做行为建模。
关于面向对象和面向过程，开始的编程就是一行行孤独的代码，后来对于处理复杂的问题只是一行行代码显得杂乱，后来出现了方法，对一些行为的封装，通过调用方法来实现操作目的，后来结构化大型的软件已经不能仅仅通过函数调用来满足，面向对象的C++应运而生，C++以类的实例对象为操作对象类里面是一些相关的属性和方法，可以将现实中的一些实体比如人，学生直接写为一个类，类的属性和方法对应于人的属性和行为，类之间的关系，一种是直线型，含义是他们之间有关系但是不能确定是什么关系，由直线相连的两个实体有数量的对应关系。软件设计的角度来理解带箭头的线 由类A可以导航到B，因为A中的一个成员变量保存的是对B的引用也就是由类A可以找到类B，软件需求的角度分析 从请假单可以找到请假者。
包含关系
实心和空心的菱形均表示包含关系，菱形一边较粗所以表示大的包含者，没有菱形的表示被包含者，空心表示弱包含，部门没有了员工照样存在，实心菱形表示强包含部门没有了员工也就不存在了。
 继承关系
 依赖关系，依赖关系不一定是没有香烟烟鬼就不能生存了，也可以是对于某件事，依赖者需要被依赖者的协助来完成，文件夹与文件的关系用类图来表示一个是文件夹包含文件另一个文件夹同样包含文件夹就是自己就是自包含，关联关系同样支持此类定义，这就形成了递归。