qiuyong: 2019-1-11 12:45

我来公司两个月了。公司有一套零售门店系统，领导让我负责在现有系统基础上开发，像这种"遗留系统"，UML建模的知识还用得上吗，或者使用上有没有不同？

潘加宇：

"遗留系统"是一个从开发人员视角定义的术语，大致意思是（1）这个系统已经出现了比较长一段时间（2）这个系统的代码不是我写的（3）很可能接下来我要负责做一些事情来改进或集成这个系统。

（3）是最关键的。符合（1）和（2）的系统非常多。各个岗位的工作人员已经出生了几十年，符合（1），代码是老爸老妈先用DNA编码打底，老师升级了十几年，符合（2），只不过不符合（3）。公司里用的Word软件，已经发布了N年，符合（1），代码是微软的程序员写的，符合（2），只不过不符合（3）。

在《软件方法》书中，我们在很多地方都提到了开发人员视角带来的各种建模错误。特别是在前言和第1章中提到：

我们分别从四个工作流来看看有无区别。

（1）业务建模

业务建模是从目标组织的视角来观察和建模。这里的目标组织不是贵公司，而是通过引进零售门店系统改进其流程的组织，例如某母婴用品连锁店。

从目标组织的视角看，看到的是很多人肉系统（业务工人）和非人肉智能系统（业务实体）在交互以完成组织的用例。

图上所有的系统都是"遗留系统"。其中某个系统是贵公司开发的，其他系统可能是他们的父母和老师开发的，也可能是其他公司开发的，也可能是猫、狗、外星人开发的，对于组织来说，系统怎么来的无所谓，对组织的价值有帮助就行。

在这个现状之下，目标组织下一步该如何改进，应该根据愿景来决定。

可以不改进；
可以在原有某系统上改进；
可以是引进新的业务工人代替旧的业务工人，例如淘汰35岁以上的员工，替换为20多的小鲜肉；
可以是引进新的业务工人代替旧的业务实体，例如引进真人美女服务员代替冷冰冰的自助机和顾客交互；
可以是引进新的业务实体代替旧的业务工人，就是所谓的电脑代替人了；
可以是引进新的业务实体代替旧的业务实体，也就是所谓的电脑系统升级换代。

同样，改进是由猫、狗、外星人、贵公司或其他公司负责，对于组织来说是无所谓的。

业务建模工作流的建模，和贵公司或你无关。

（2）需求

假设改进的方案定了，在某个现有业务实体上做改进或者引进新的业务实体。需求工作流就是描述现有业务实体上的新责任细节或者所引进的新业务实体的责任细节。

和业务建模工作流一样，这些责任细节，由涉众利益来决定，最终实现由猫、狗、外星人、贵公司或其他公司来负责，和需求无关。

用生病类比。某人得了某病，需要某种治疗才能治愈。即使患者无钱支付治疗费用，或者所有医生都冬眠了，也不会影响这一点。并不存在"没有医生给我治病，所以我的病就消失了"。

（3）分析

如果要改进的系统刚好是贵公司开发的系统，或者目标组织负责人决定从贵公司那里引进新的系统，这时，这个改进和贵公司扯上了关系。

如果贵公司负责人觉得，需求约定的系统责任，外包给外星人来实现更合算，那事情到此为止，就没有分析设计的事情了。

如果贵公司负责人没联系上外星人，觉得还是自己做更好，而且分配给你做，这个事情才会和你有关系。

接下来，你就开始分析了。

按照某种分析方法学（例如面向对象分析方法），系统要提供需求约定的某个责任，应该有哪些的类来协作完成，如何协作完成，全部是逻辑上的思考。在分析工作流，我们认为系统中的对象在一个虚的"对象空间"中运行。这个空间不是内存，也不是硬盘，只是人脑中的一个逻辑空间。

分析工作流的结果（分析类图、分析序列图、分析状态机图）和"目前是否有了一些代码"无关，也就是说，和"遗留"不"遗留"无关。

针对很多企业应用和互联网应用来说，UML建模应用到分析工作流足够了（参见《软件方法》第1章）。

也就是说，应用UML建模，和"遗留"无关。

（4）设计

到了设计工作流，才和"遗留"有关系。

设计工作流需要思考：为了实现分析的结果，已有的代码哪些可以利用以及如何利用。

思考的方法和思考如何利用已有数据库来完成分析界定的实体类责任或者如何利用已有的Vue.js来完成分析界定的边界类责任并无区别。