这两天重温数据建模，发现一篇好论文《基于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页的高浓缩论文都可以通过小步慢跑的形式学完，那么其他再浓厚的学术性材料，只要慢慢啃，终究有一天可以做完。你看，学门吃饭的手艺，就是那么简单，哪里有想象的那么复杂，那么多让你却步的想象，都是纸老虎，微微一戳就破。
--完--