感受
目前创新互联已为近千家的企业提供了网站建设、域名、雅安服务器托管、网站托管运营、企业网站设计、麻山网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
在刚接触软件开发工作的时候，每次接到新需求，在分析需求后的第一件事情，就是火急火燎的打开数据库（DBMS），开始进行数据表的创建工作。然而这种方式，总是会让我在编码过程中出现实体类设计疏漏的地方，导致我在写业务代码时，还回头去反复的修改数据表和实体类。为了规避这样的情况，我学习期间发现了UML中关于类图的知识点，它让我知道，作为编码者在分析需求后，做的第一件最基本的事情应该是进行面向对象分析，然后使用UML绘制类图的方式进行面向对象的设计。在类图绘制完之后，使用类图与组员沟通设计思想，分析设计的可行性，在项目组一致达成共识后才进入后面的动手环节。
以上这种，通过面向对象分析和设计来绘制类图的工作习惯，我一直延续至今。因为，它不仅能保证软件构建的稳定性，还能提升我们面向对象的思想和实践能力。在实际中，极少数的情况下，公司会聘用专门的设计人员为你提供设计方案，更多的情况是，程序员要担任设计和编码的综合性工作，所以我认为掌握UML类图，是一名程序员的技能标配。
三个层次
在标准的软件工程建模当中，类图实际上根据三个层次划分为了三种类型的类图，根据使用顺序分别为：概念层类图、说明层类图和实现层类图。概念层用于业务建模阶段，着重于对问题领域的概念化理解；说明层用于概念模型阶段，主要考察类的交互涉及哪些接口；实现层用于设计阶段，主要考虑类在代码技术层面的实现细节。本文主要主要以实现层的类图为主，因为实现层的类图是最常用的，并且它是直接影响到我们实际的编码工作的，下面我会针对它涉及的绘制方式、类之间的关系展开详细讲解。
UML类图的基本语法是很简单的，可能懂点编程的人在不系统学习的情况下，借助绘图工具都可以绘制出来。但在实际的业务需求中，充斥着各种晦涩的业务概念、事物，要从其中准确无误的提炼出有利于业务系统的类，并非一件简单的事情。
对于类的识别，并没有很具体的步骤、公式进行照搬硬套，往往只能通过自身的经验和面向对象的造诣去识别类。并且识别类往往也不是一蹴而就的，还要结合类与类之间的关系、业务的使用场景，反复推敲，才能逐步得到合适的类型。对此我只能提供一些概念性的经验心得，读者可以选择性的参考，并不作为一个标准。
类的识别很大程度上需要依靠“边界”，这是一个复杂的概念，你可以简单理解它相当于一个范围，设定边界可以让我们知道能做什么事情，和不能做什么事情。并且边界的设定会决定我们看待事物的视角和抽象事物的层次。对于类的识别而言，其边界可参考当前的系统的目标、业务场景等，有了清晰的边界，可以缩小类的识别范围，不在是天马行空，毫无根据。
如果不通过边界确定一个角度，那么对于同一事物，通过不同的角度会提炼出不同的类型。就拿我们自身举例，从职业的角度来看我们则是程序员，从国家的角度来看我们则是中国人，从动物的角度来看我们则是人类。所以我们必须要通过边界来确定一个角度，从而清晰的分析获取有利于业务系统的类型。
