在学习UML这门课之前,我一直心底有一个疑问,那就是我们和那些所谓的程序员速成班培训出来的程序员到底有什么差别,都是写代码,那我们在大学里学习的意义是什么呢,直到我学习了UML这门课。我才知道写代码并没有想象中的那么简单,对于同一个功能,肯定有着多种不同的实现方法,而这些方法也肯定有优劣之分。我们之所以不像外面那样的培训班一样速成,是因为我们需要锻炼自己去写出高质量的代码,我觉得这就是我们学习的意义。
其实在上UML课之前,我以为UML跟C++和java一样是一门编程语言,直到经过老师的介绍,我才知道UML的全称是Unified Modeling Language,他不同于C++,java这些编程语言,他是统一建模语言。UML是一种用于可视化描述系统,具有广泛用途的建模语言。作为一种标准化的图形语言,在软件工业中被用于软件系统部件的具体化,可视化,结构化描述以及撰写文档,同样在商业模型中也得到应用。
UML虽然不是一门程序设计语言,但他的重要性是不可忽视的。他的重要性主要体现在:使复杂的软件设计更为简单,也能够实现像OOP(面向对象编程)这一类被广泛应用的概念;用理解起来可能更容易的图来描述,避免了大量的文字;使表达和交流概念或系统结构变得更容易;在一张图中就能够描绘出整个系统;程序员实用类图来描述实际需求时,可让问题更加清晰明了,实现起来更容易。
很多人或许会说直接写代码要比画图分析什么的快多了,但我认为UML在分析和设计阶段十分重要。在学完职责分配原则和了解过一些设计模式过后,我更加坚定了我的想法。或许对于一个小项目来说,实现的方式有很多种,无论是哪一种,可能会有人觉得只要能够实现功能就是可用的,就是好的。但如果是一个比较庞大的项目呢?如果在具体写代码时某个类的职责过于庞杂,那么必定会给系统带来很大的压力。或者说每个类之间的关系特别复杂,那么当后续需要更改某个类的时候,必定会影响到其他的类,带来十分高昂的维护成本。而GRASP的九个原则:信息专家原则,创造者原则,低耦合原则,高内聚原则,控制器原则,多态原则,纯虚构,中介原则,受保护变量原则可以在一点程度上很有效地解决这些问题。
UML这门课程让我学会了话UML的五大类,共九种图:
- 用例图:从用户角度描述系统功能,并指出各功能的操作者。
- 静态图:包括类图和对象图。类图描述系统中类的静态结构,不仅定义系统中的类,表示类之间的联系,如关联、依赖、聚合等,也包括类的属性和操作,类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
- 行为图:描述系统的动态模型和组成对象间的交互关系,包括状态图和活动图。状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件,状态图是对类图的补充,活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并进行活动。
- 交互图:描述对象间的交互关系,包括时序图和协作图。时序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;协作图描述对象间的协作关系,协作图跟时序图相似,显示对象间的动态合作关系。除显示信息交换外,协作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用时序图;如果强调上下级关系,则选择协作图。
- 实现图:包括组件图和部署图。组件图描述代码部件的物理结构及各部件之间的依赖关系,组件图有助于分析和理解部件之间的相互影响程度;部署图定义系统中软硬件的物理体系结构。
UML也同时让我自己去了解了统一过程,这部分老师并没有详细地讲,我自己查阅资料了解了一些。RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段、细化阶段、构造阶段和交付阶段。每个阶段结束于一个主要的里程碑。每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。
说实话在了解GRASP,设计模式,统一过程后,我觉得UML是一门十分重要的课。但是我在知乎上看到了一个“UML现在有什么用?”的问题,上面的许多高赞答案都是在说UML的用处并不大。甚至有人说UML是糊弄人的东西。但我却不这么认为,判断知识有没有不能仅凭这自己以前的经历,或许有些人用UML的地方并不多,所以他认为UML的用处并不大,但是谁又能肯定的说你以后不会用到UML的建模方法和思想呢?我觉得我们学习的眼光应该长远一点。不管如何,我在UML结课后,仍然会继续学习UML,因为我认为他是十分有用的,虽然目前为止我并没有过参与大型项目的经历,但确实在UML建模后,我对一些问题和业务逻辑有了更深刻的认识,我相信他能帮助我提升我自己的能力,加油!