1.前言感受
在刚接触软件开发工作的时候,每次接到新需求,在分析需求后的第一件事情,就是火急火燎的打开数据库(DBMS),开始进行数据表的创建工作 。然而这种方式,总是会让我在编码过程中出现实体类设计疏漏的地方,导致我在写业务代码时 , 还回头去反复的修改数据表和实体类 。为了规避这样的情况,我学习期间发现了UML中关于类图的知识点,它让我知道,作为编码者在分析需求后,做的第一件最基本的事情应该是进行面向对象分析,然后使用UML绘制类图的方式进行面向对象的设计 。在类图绘制完之后,使用类图与组员沟通设计思想,分析设计的可行性,在项目组一致达成共识后才进入后面的动手环节 。
以上这种,通过面向对象分析和设计来绘制类图的工作习惯,我一直延续至今 。因为,它不仅能保证软件构建的稳定性,还能提升我们面向对象的思想和实践能力 。在实际中,极少数的情况下,公司会聘用专门的设计人员为你提供设计方案,更多的情况是,程序员要担任设计和编码的综合性工作,所以我认为掌握UML类图,是一名程序员的技能标配 。
三个层次
在标准的软件工程建模当中,类图实际上根据三个层次划分为了三种类型的类图,根据使用顺序分别为:概念层类图、说明层类图和实现层类图 。概念层用于业务建模阶段,着重于对问题领域的概念化理解;说明层用于概念模型阶段,主要考察类的交互涉及哪些接口;实现层用于设计阶段 , 主要考虑类在代码技术层面的实现细节 。本文主要主要以实现层的类图为主,因为实现层的类图是最常用的 , 并且它是直接影响到我们实际的编码工作的,下面我会针对它涉及的绘制方式、类之间的关系展开详细讲解 。
2.类的识别UML类图的基本语法是很简单的,可能懂点编程的人在不系统学习的情况下,借助绘图工具都可以绘制出来 。但在实际的业务需求中 , 充斥着各种晦涩的业务概念、事物,要从其中准确无误的提炼出有利于业务系统的类,并非一件简单的事情 。
对于类的识别 , 并没有很具体的步骤、公式进行照搬硬套,往往只能通过自身的经验和面向对象的造诣去识别类 。并且识别类往往也不是一蹴而就的,还要结合类与类之间的关系、业务的使用场景,反复推敲,才能逐步得到合适的类型 。对此我只能提供一些概念性的经验心得 , 读者可以选择性的参考,并不作为一个标准 。
类的识别很大程度上需要依靠“边界”,这是一个复杂的概念,你可以简单理解它相当于一个范围,设定边界可以让我们知道能做什么事情,和不能做什么事情 。并且边界的设定会决定我们看待事物的视角和抽象事物的层次 。对于类的识别而言,其边界可参考当前的系统的目标、业务场景等,有了清晰的边界 , 可以缩小类的识别范围,不在是天马行空 , 毫无根据 。
如果不通过边界确定一个角度 , 那么对于同一事物,通过不同的角度会提炼出不同的类型 。就拿我们自身举例,从职业的角度来看我们则是程序员,从国家的角度来看我们则是中国人 , 从动物的角度来看我们则是人类 。所以我们必须要通过边界来确定一个角度,从而清晰的分析获取有利于业务系统的类型 。
![面向对象的照妖镜——UML类图绘制指南](http://img.zhejianglong.com/231018/041I52C7-0.png)
文章插图
例如,你需要在一个网课教育系统中,分析上课的场景中会有哪些类型 。如果你不考虑边界(网课教育系统中的上课场景),那么你可能天马行空的分析出:男人、女人这些类型 。这样分析出的类型和属性显然对系统毫无意义 , 也无法为业务提供价值 。如果你考虑到了边界(网课教育系统中的上课场景) , 那么你分析出的类型必然是在这个边界内有利于业务的:老师、学生 。
对于分析类中的成员(属性、操作)也可以利用边界来分析 。还是以上面的网课教育系统为例,如果不考虑边界,很可能会对老师类和学生类分析出:体重、身高、发量等无意义的属性 。只有你充分考虑边界,你就会注重系统的目标、业务的场景,分析出对业务有价值的属性,例如学生类的选修课程、老师类的教龄等 。
如果你对边界的概念还是比较模糊,那么你可以在识别类的时候,尝试将当前的系统目标、业务场景看作一个边界,从而选择合适的角度 , 去提炼出对业务系统有价值的类型 。
推荐阅读
- 树链剖分 HYSBZ1036 [ZJOI2008]树的统计
- 奥比岛手游抢凳子的技巧是什么
- 史前文明小说排行榜-关于史前文明的小说
- 传奇3祖玛阁怎么走,传奇3祖玛阁走法(传奇3去祖玛阁教主的走法)
- 如何找到赚钱快又多的工作(最苦最累最赚钱的工作)
- 文盘Rust -- struct 中的生命周期
- 一个C#开发者学习SpringCloud搭建微服务的心路历程
- 英雄联盟手游能力者的试炼挑战活动介绍
- 钻头硬度划分 钻头硬度排名
- 雅诗兰黛眼部精华怎么才能用到底下的部分_雅诗兰黛眼精华怎么用完