即便是SQL Guy, 也无法逃离UML

Posted dbLenis

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了即便是SQL Guy, 也无法逃离UML相关的知识,希望对你有一定的参考价值。

点击蓝色“有关SQL”关注我哟

加个“星标”,天天与10000人一起快乐成长

这两天重温数据建模,发现一篇好论文《基于UML的高校教务管理系统的分析、设计与实现》

文章86页,从需求分析,系统分析,设计到实现,作者把所有阶段的建模,都用UML 画了一遍。朋友们,实打实的实战操作啊。

这就像是金庸刻意给郭靖安排好的一条路子,每一步都有名师指点,平步青云,走上人生巅峰。

这篇成都理工大学的硕士级毕业论文,把软件开发的方方面面都讲到了,看得我也是乐不思蜀,大呼小叫,居然思路这么清奇,不枉费这几天的投入。

| 想看论文的朋友,加我微信 dbLenis, 回复UML, 我可以分享给你

UML 缘起

在讲解UML建模之前,有必要简要说下RUP。

Rational Unified Process( RUP ), 即统一建模过程。在面向对象软件开发中,经常需要对业务进行分析,继而产生软件设计分析及架构定型。

软件开发是年轻的事物(相比其他产业),它的方法论,经历了各种阶段。

RUP 不过是软件开发的又一条路径而已。现在火热的敏捷开发,也是其中一条。

很多人以为敏捷杀死了 RUP,其实也对,也不对。敏捷充其量只算是误伤,但确实把 RUP打压的连90后,都不认识了。

为弄清楚 RUP,我检索了《极客时间》,知网,维普网等,一路发现了各种优质的资料,比如李智慧老师在极客的课程,各种解释建模的论文,但最近这些年,RUP已经谈的不多。

InfoQ 上,有一篇文章,详细解释了敏捷这几年对 RUP的冲击:

https://www.infoq.cn/article/iuI5l04WvsbCRXa3Ppdw

事实上,RUP 虽然谈的不多,但因RUP而起的UML(Unified Modeling Language),却已经无法被忘记。

UML 会有哪些著名的用途呢,掌握它对设计开发软件,有什么帮助么?好处大了

这要从 UML 为什么会诞生说起。按照 RUP 的思想,软件设计是阶段性的工作。它分成6大步骤:业务建模,需求分析,系统分析与设计,实现,测试和系统配置

在这6大步里,每一步都有中间产物,它的表现形式是多样化的,但一定少不了 UML 图纸。它的7种模型图,对分析需求,展示需求和软件及架构设计都起到一图解千言的作用。

需求分析的模型建立

精准的需求分析,是软件开发的首要重任。

但需求的确认,并不那么一帆风顺。有时,用户直到软件完成,才反应过来,什么是真正想要的功能。所以,敏捷才有了可乘之机。这是后话,以后再说

回到业务需求分析。每个业务分析员最终的产出,可能是一堆阐述需求分析的文字,也有可能是Excel配上模拟的界面。这些都是日常开发中常见的需求分析文档。

但今天要说的是,UML建模,即用UML来做需求的可视化展现,以高校教务管理系统的需求分析为例,业务分析的产出,是这三张UML图:

这个教务管理系统,有三类用户,代表了系统的三个方面。每类用户所需的功能不同,功能之间亦有重叠。

假使用纯文字来表达这三类用户需求,那么程序员读上一小段,就估计要打瞌睡了。而改用User Case(用例图)来表达业务需求,这样双方就一目了然了,比较容易达成共识。

由此可知,在需求分析阶段,BA(Business Analyst ) 的产出物,应当就是用例图。用例图的作用,就是从BA,程序员,测试,架构各个参与者的角度,来描述系统的功能,促使各方,在理解上达成共识。

需求分析完成后,就要开始系统分析。系统分析主要解决的难题是,发现问题定义和解决这些定义所需的类(注意这里是面向对象的软件设计)。

因此这个阶段需要的产物,是系统分析模型。分析模型主要分布在用例视图和开发视图中。

这里有必要简单说下,软件建模中其他3个视图:

四个视图综合起来,就构成一个场景视图,所谓的4+1视图模型,就是这么来的。

很难用理论,去讲解这五张图的概念,用UML图来解释,就一目了然,只要找对这5张视图的通用模板,自然能顺其自然的了解和理解,这5个视图企图说明的内容。

而《软件设计方法论》也明确的表示了,5张视图,可以分别用UML的7个模型图来表示。

所以,RUP虽然淡出了人们的视野,但在RUP建模思想中,创造出来的建模工具,UML却一直留存下来,继续发挥它的余热。

系统分析的模型建立

需求分析阶段过完后,就到了系统分析。此阶段要处理的事情,是把满足解决需求分析中定义的问题的类,都设计出来。

显然,和需求分析阶段的产出模型有很大的不同,系统分析要产出的模型,就和实际编码产出的类及其函数,非常接近,可以说是具体编码的指导手册。

要表达实际编码要求,可以用两种UML模型图,来展现:一,是类似交互,时序,活动等动态图,二是类似类,对象等静态图。前者也可称为用例图,后者也叫开发视图

至于,用例试图,开发视图的表述,是否与李智慧《软件设计方法论》中提到的4+1视图模型一致,我认为用例试图可认为是逻辑视图,开发视图两者等价

抛开概念的诠释,系统分析阶段重要的两个模型,到底怎么呈现,这里还是利用《UML高校教务管理系统》来说明。需求分析阶段产出了用例图,这些用例图怎么转化为系统分析阶段的用例图和开发视图?

首先要求最复杂的系统分析阶段的,给程序员看的动态模型图说起。动态模型,可以由交互图和行为图来展现(我认为,还会有更多的专业图,但这2种图,应该最为常见)。

交互图,由时序图与协作图来表达;行为图,由状态图与活动图来表达。

UML是舶来品,这里的翻译未必全国通用,所以需要注意与其他同义词的区别。通过查询 Wikipedia, 果然可以看到更多的解释:

Structural UML diagram (静态图):

Class diagram

Component diagram

Composite structure diagram

Deployment diagram

Object diagram

Package diagram

Profile diagram

Behavioral UML diagram(行为图): 

Activity diagram

Communication diagram

Interaction overview diagram

Sequence diagram

State diagram

Timing diagram

Use Case diagram

基于这些模型图,每个写出来可能都需要花不少时间。包括写一写图的画法,图的规范,脚本以及线头,加上每种图表达的意思,用在什么场合,还有这些图的组合应用。

但是这些模型图,还真的在用么,还是为了方便今天的我们看懂整个系统设计,或者提供些系统分析的思路?

我觉得两者都有。当针对大型的软件设计,或者多人协作的开发,那么画好设计图,对每一个新人或接手的队员,都是非常友好的上手参考材料。

继续以论文《基于UML的高校教务管理系统的分析、设计与实现》作为背景,讨论系统分析该用什么模型图来表达动态模型。一般动态模型,会使用到时序图,协作图和活动图。

上面这张时序图,反应了学生选课的场景。一个很鲜明的特点,在每一个步骤之前,都有1,2,3……这样的标记,用来标识该步骤的次序。

起初我认为并没有特别严谨的逻辑,选课界面与选课管理,这两者甚至可以放在一起。但我疏忽了,选课管理是个单独的类,而选课界面是界面这个类的对象,分属不同的类,自然应当区别对待。

因此,时序图中尽量拆解最细粒度的类,对于设计是非常有帮助的,可以降低类的耦合性,使得大规模团队合作变得可能。

既然说到设计,每个人的理解和标准都会有些偏差,但总体上来说,应当是做出来的图,大家都可以达到一定的共识。统一思想在任何地方,都是相当重要的战略。

接下来的协作图,在统一思想方面尤其重要,每个开发都应当遵循这样达到共识的协作图,来开发自己的那部分内容。

协作图是个动态模型图,任何实体时间,都应该有双向的动作。具体到要设计哪些类(界面也是类),是设计者定下来的,至于为什么要设计这些类,是基于面向对象软件开发思想设定的。

比如成绩管理界面,成绩管理类和成绩记录,是典型的MVC思想,有Model(成绩记录),Control(成绩管理), View(成绩管理界面),共同组成。

一个大型的软件系统中,必定涉及到更多的协作类场景,如有必要,可以把这些协作场景,都画成协作图,让每个开发都认识自己在整个项目中的位置,以及项目里其他人负责开发的板块。

当然协作图,也不仅仅是作为软件开发时的利器,也可以作为自己去理解一个项目,一个软件时,思考的工具。比如你去看一个源代码,开源的也好,公司的遗留项目也好,你只要能7788的画出协作图,对你理解整个软件就非常有帮助。

有些朋友以为看一遍代码就能理解整个项目,那是不现实的,除非那个项目特别的小,否则还是有必要画一画协作图,时序图等动态模型图,帮你理解。

而且画的越详细,你理解的越深,越广,对你读懂整个项目非常有信心加持。越画越想读,读的越多,越想画出来,这是一条正反馈链路。

动态模型图中,还有一类和协作图看似很接近的模型图,但是它的标记法,有明显的特别之处,它 有完整的起点和终点。

这类图有很明显的规范格式,比如开头,必须是实心点,结尾必须是实心点加一层空圈。再比如,菱形是用作判断的,分叉与合并要加横杆。

当把系统的动态模型图,都逐一画出来后,再确定哪些静态的类图,就容易多了。

此时,开发只要拿着自己负责的部分动态图,就可以设计出软件来。

对着上面设计出来的动态模型图,可以分别由粗入细的设计出这些静态的类图:

比如粗粗的学生选课类:

加上了属性与方法的类图:

类与类之间的交互图:

这三种类,已经把系统软件的组件大致勾勒了出来,剩下的就是编码实现。编码实现属于技巧类和熟练类的活计,这是熟能生巧的经验。

系统设计建模

所有分析类的建模工作,到此都已经完成。接下来是对整个软件项目宏观层面的建模,比如系统分层,子系统划分,组件构成,部署架构等。

比如,现在用到的软件层次是MVC架构:

整个软件系统划分成哪些子系统:

组件之间的关系:

系统在物理架构上的部署:

数据库建模

到这里,软件前端开发的建模已经完成,接下来是对数据库建模。有了上面的需求分析,系统分析与设计,数据库类的建模其实,已经水到渠成。主体的表结构根据静态类图,已经可以设计出来。使用UML就可以完成。

 在数据库ER模型图中,最要紧的是标清楚实体与实体之间的关系,一对一,一对多,还是多对多。

比如学生与院系之间,只能是多对一,表示一个学生只能呆在一个学院,而一个学院则可以容纳N多个学生。

再比如学生与考试成绩,学生会学N门课程,对应的成绩自然有很多,而一份成绩,只能是属于某一个学生的。

再比如学生与老师之间的关系,一个老师可以教很多学生,而一个学生, 亦可跟很多老师求学。

我认为做软件开发,仅仅停留在编码阶段,能做的事情非常有限。更上一层楼,去做一些架构或者接口的事情,那会大大扩展自己的能力边界,带来更多的机会。这值得去尝试。

国庆假期,虽然我每天只花2-3个小时在这篇论文上,看看文字,画画图,但是这种每天都前进一小步的感觉,对我来说感觉非常好。

既然86页的高浓缩论文都可以通过小步慢跑的形式学完,那么其他再浓厚的学术性材料,只要慢慢啃,终究有一天可以做完。你看,学门吃饭的手艺,就是那么简单,哪里有想象的那么复杂,那么多让你却步的想象,都是纸老虎,微微一戳就破。

--完--

往期精彩:

本号精华合集(三)

外企一道 SQL 面试题,刷掉 494 名候选人

我在面试数据库工程师候选人时,常问的一些题

零基础 SQL 数据库小白,从入门到精通的学习路线与书单

以上是关于即便是SQL Guy, 也无法逃离UML的主要内容,如果未能解决你的问题,请参考以下文章

SQL笔记--MySQL高级操作

2007守望者的逃离

守望者的逃离

无法在 VS 2010 中创建 UML C# 类图

51nod 1299 监狱逃离

守望者的逃离