UML图绘制的注意点和实例分析
先百度一下，Unified Modeling Language (UML)又称统一建模语言或标准剑魔语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
UML可以看做用于系统设计阶段给开发做参考的一种方式，其很多图需要用到面向对象程序的思维。画UML图是产品经理的必备技能之一。
废话不多说，本文介绍一下最常见的几个UML图类图、用例图、状态图、序列图、活动图，以及一个并不属于UML，但也有很大作用的数据流图。每张图详细介绍一下画法、注意点和具体案例。相关的概念、元素等则简单介绍。
一、类图
类图是UML图中看起来最复杂的一个图。它与数据库和面向对象编程的联系比较紧密。没学过面向对象或者数据库的同学刚开始画类图可能比较吃力。
一句话介绍一下类类即相同属性、操作、关系和语义的对象的描述。类的组成属性、操作。
类图描述系统中类的静态结构。它的作用是定义系统中的类, 表示类之间的关系(关联, 依赖, 聚合等),描述类的内部结构(属性, 方法等)。一个类长什么样看下图。
类图有涉及到面向对象的知识，在此不一一叙述。图中有些看不懂的名词请自行百度。
类之间通过关系连接起来。类图中的关系很多，在此介绍最常见的关联关系。关联关系是一种拥有的关系，它使一个类知道另一个类的属性和方法。关联关系的类通过箭头连接起来。
狼蚁网站SEO优化分析具体案例公司图书管理系统，包括借书、还书、申请买书的操作。借书过程员工发起借书申请，由行政人员去图书馆拿书给员工。还书买书类似。后面的图也是用这个案例。
这幅图就是借书系统的类图。要简化的话可以将可见性符号和属性的类型省略。图中的空心三角形应该为箭头。
员工、书、订单三个类比较容易理解，代表了三个抽象的实体。借书类则是员工和书之间借书行为的一个抽象，连接了员工和书，记录了借书这个状态中的一些信息，以及借还书操作。买书同理。
列几条类图绘制的要点。
类的操作是针对类自身的操作，而不是它去操作人家。比如书这个类有上架下架的操作，是书自己被上架下架，不能因为上架下架是管理员的动作而把它放在管理员的操作里。 两个相关联的类，需要在关联的类中加上被关联类的ID，并且箭头指向被关联类。可以理解为数据表中的外键。比如借书和书，借书需要用到书的信息，借书类需包含书的ID，箭头指向书。 由于业务复杂性，一个显示中的实体可能会被分为多个类，这是很正常的，类不是越少越好。类的设计取决于怎样让后台程序的操作更加简单。比如单看逻辑，借书类可以不存在，它的信息可以放在书这个类里。借还书的书的上架下架完全不是一回事，借书类对借书的操作更加方便，不需要去重复改动书这个类中的内容。，如果书和借书是1对多的关系，那就必须分为两个类。 类图中的规范问题，比如不同关系需要不同的箭头（本文只介绍了1种关系），可见性符号等。二、用例图
用例图是最常见的一种图。用例图概括了用例中角色和系统之间的关系，描述了系统功能需求，角色和系统的交互以及系统的反应。
用例图有参与者、用例、关系组成。参与者就是系统中的用户身份。用例是系统中的一个功能的概括。关系是参与者或者与用例的联系。其中关系可以分为关联、泛化、包含和扩展4种关系。关系的运用是用例图最难的部分。4种关系的说明
关联是参与者和用例之间的关系，用箭头；
泛化是参与者与用例或用例之间的关系，意思是特殊化。比如吃饭和吃晚饭。两者的本质是一样的。符号用空心的三角形。箭头为被指向。 包含是用例之间的关系，意思是一个用例包含另一个子用例。子用例是必须存在的，没有子用例则功能不能完成。符号在箭头的线上加<还是上面那个图书管理的案例
行政人员和员工是参与者，中间的这些是用例。这幅图用例之间大部分都是包含关系，比如借书包括申请、查找、借阅这三个子用例，都是必须的。而图书续借不是必须的，只是扩展的用例。批量购书是购书的一个特例，和购书本质是相同的，作为泛化的关系。
绘制的注意点
用例之间的关系，尤其是包含和泛化的区别，可以这样区分，试着把包含的用例让泛化的用例来包含后，看看是不是同样成立 箭头指向，泛化和扩展的指向和包含是反的 用例的表达是动词+名词的形式，只有一个动作或者名词的不是用例。比如所有书籍，是否可借等表述就不是用例。三、状态图
状态图是UML中相对比较简单的一张图，用得也没前两种图多。状态图是描述一个实体基于事件反应的动态行为，显示了该实体所有可能的状态，以及事件发生时状态的转移条件。
一句话，状态图就是把类的状态的改变连城一张图。状态图的元素包括状态、转移和动作。元素的形式如下图所示，黑点分别为起始点，矩形为状态，箭头上时状态改变的动作和事件。