即便是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页的高浓缩论文都可以通过小步慢跑的形式学完,那么其他再浓厚的学术性材料,只要慢慢啃,终究有一天可以做完。你看,学门吃饭的手艺,就是那么简单,哪里有想象的那么复杂,那么多让你却步的想象,都是纸老虎,微微一戳就破。
往期精彩: