上高中的时候，经常使用一些软件，觉得这些软件挺有意思的，就一直很好奇系统这个东西是怎么构建出来的。直到后来，大学的时候上了一门叫做系统分析与设计的课程，从UML开始再到用Spring Boot和Vue写一个系统，慢慢的有一点点的概念，但是还是感觉迷迷糊糊。研究生的时候有一门类似的课程再学一遍的时候，我才意识到，其实系统怎么做出来的这个问题，UML中就有一部分的答案。
如果有一面白板，我们每想到一个主意就在上面增加一些数据，这样的话，当需要查看有关的数据的时候，就可以在这个白板上进行查看。将这个信息传递和记录的过程电子化，就是我们的系统了。因此我们需要考虑清楚：用什么存储+怎么查看的问题。而比如在UML的类图中，其实就说明了用什么来存储的问题，也说明了类和类之间的关系。而怎么查看？怎么用？就可以在用例描述和系统序列图中进行查看。因此其实UML的这些部分就能解释系统实现的原理。因为一班我们会使用一些框架来实现系统，因此还有一部分系统实现的原理，则是去理解那些框架。
为什么要用框架呢？因为很多是重复性的工作，能减少些工作量就减少些。且模块化后的框架相反是不容易出啥错的。
不过在上UML的时候会发现其实五个阶段中（计划，分析，设计，实现，维护），前面的阶段也会有很多的图。但是前面阶段产生的图基本上是对于现状和需求的梳理，只有到设计阶段的图才是一种产品。因为按照这个产品，我们就可以开始来写系统了。
这样的产品主要有三个：1）用例描述。可以详细的解释，用户进行了什么操作，系统给出了什么反应。 2）类图。表明系统内的信息是怎么存储的，之间的关系是什么，有什么方法。 3）系统序列图。说明了具体的编程的过程中的请求和数据传递的情况。这三个产品需要满足如下的要求：1）可以实现在现实中的需求 2）可以直接用来辅助implement阶段的开发。因此前期能够把这个图做出来，且能满足条件，得到团队的共识，那么开发起来就少了很多麻烦。
记得第一次开发的时候，大家都是各自画完各自的图后，开始做自己的用例，然后系统合并的时候就十分的痛苦了（现在感觉挺滑稽的）。要是那个时候能意识到其实UML也是产品和系统的构建方式说明的话，就应该把类图这个产品做出来，并且大家讨论得到共识，再去开发实现功能。