[全程建模]类图与时序图作用的对比讨论

一个十多年做技术的朋友 13:37:42

在？

青润 13:54:43

在。

一个十多年做技术的朋友 13:55:18

有没有什么工具可以直接把时序图代码生成出来？

青润 13:56:22

时序图是没有代码的，只有类图才实际关联代码。

时序图只是帮助把类图中的方法调用关系展现出来，辅助完成类图开发的作用。

一个十多年做技术的朋友 13:56:46

流程图呢？

一个十多年做技术的朋友 13:57:09

我最关注的是流程图、时序图、状态图

青润 13:57:34

流程图——状态活动图是用于绘制用户业务细节或者类内部复杂算法表现的，在设计模型中就是辅助进行微代码开发和设计的时候使用。

一个十多年做技术的朋友 13:58:03

能直接生成代码不？

青润 13:58:20

不能，只有类图才是实际关联代码生成的。

一个十多年做技术的朋友 13:58:30

好的，谢谢

青润 13:58:38

不客气，呵呵。

一个十多年做技术的朋友 14:02:58

只生成类图作用不大啊

青润 14:09:35

类图是核心，它串连了所有的设计模型相关的东西，通过类图可以直接把时序图和协作图推导出来的。

一个十多年做技术的朋友 14:10:07

那地方不容易出错

青润 14:10:22

不容易出错？哪地方？

一个十多年做技术的朋友 14:10:27

类定义

一个十多年做技术的朋友 14:10:34

容易出错的是逻辑代码

一个十多年做技术的朋友 14:10:50

我在考虑自己生成时序图的代码

一个十多年做技术的朋友 14:11:09

看上去可以把单元测试代码也生成出来

青润 14:11:27

其实类图如果定义清楚了，通过时序图或者协作图开发过程中对类图的细化，就可以实现类图中所有逻辑关系的清晰表达。

单元测试用例和代码都可以通过这个自动生成的。

青润 14:11:52

时序图生成的代码也是类图生成的，时序图自身就是类图的一个衍生物，或者表达方式而已。

一个十多年做技术的朋友 14:11:54

结合mock

一个十多年做技术的朋友 14:12:00

不一样的

青润 14:12:15

这一点，你肯定搞错了。

一个十多年做技术的朋友 14:17:31

类图只描述类之间的关系

一个十多年做技术的朋友 14:17:57

不能描述逻辑

青润 14:19:58

其实逻辑关系是隐藏在里面的。

你如何才能考虑清楚这些类间的关系，都是通过时序图和协作图才能获得的。这两者是相辅相成的，但是核心就是类图。

类间关系中已经包含了全部的时序图的内容——这一点是很久以前就被证明的事情。

一个十多年做技术的朋友 14:20:40

类图如何描述调用顺序？

青润 14:21:35

类图不直接描述调用顺序。

那你说，你写的代码如何描述调用顺序的？

一个十多年做技术的朋友 14:21:51

时序图可以描述

青润 14:22:10

类间关系中已经包含了全部的时序图的内容——这一点是很久以前就被证明的事情。

一个十多年做技术的朋友 14:22:21

但我提的这点没有被包含

青润 14:22:48

你非要分离的看待类图和时序图，你是不是也要完全分离的看待你的设计和业务流程呢？

青润 14:23:07

你的代码和最后的软件包是不是也是完全独立的？、

青润 14:23:15

没有了类，哪儿来的时序图？

青润 14:23:24

时序图中每一个对象是什么？

青润 14:23:37

设计模型中的时序图。

青润 14:23:52

不是有些人把时序图放在需求分析中的使用方式。

一个十多年做技术的朋友 14:24:13

你的意思是时序图是类图的补充

青润 14:24:58

这句话里面我已经说过这个意思了。

青润 14:19:58

其实逻辑关系是隐藏在里面的。

你如何才能考虑清楚这些类间的关系，都是通过时序图和协作图才能获得的。这两者是相辅相成的，但是核心就是类图。

一个十多年做技术的朋友 14:25:34

但我现在关注的是这个补充部分，如何自动生成代码

一个十多年做技术的朋友 14:25:46

单元测试也需要对函数的调用顺序进行测试

青润 14:25:54

我说了，只有类图才对应生成代码。

一个十多年做技术的朋友 14:26:10

所以我才来请教啊

青润 14:26:25

晕倒。

一个十多年做技术的朋友 14:26:32

我在考虑通过时序图生成代码的可行性

青润 14:26:49

时序图本身没有基础，它就是类对象之间关系的表达。

青润 14:27:34

如果你自己做一个工具，也可以，面向过程的方式，可以通过关系生成代码来实现你的业务目标。

那你的分析目标就不是类，而是过程。这当然没问题，也可以解决实际的业务问题。

一个十多年做技术的朋友 14:28:29

对于是不是面向对象我不是很关注

一个十多年做技术的朋友 14:28:57

面向对象只是代码组织的一种方式

一个十多年做技术的朋友 14:29:14

和字典一样，可以按笔画排序，也可以按拼音排序

一个十多年做技术的朋友 14:30:24

如果能把代码组织好，我愿意选择面向过程，因为它思想简单，容易上手

青润 14:33:27

我并没有说面向过程不好。

我只是说，如果你要这样做，那就应该用这样的思考方式和实现方式来实现。

目前所有的此类工具都是oo的工具，他们都不能通过sequence diagram生成代码，如果要做，就只能你自己来做一个这样的工具了。

一个十多年做技术的朋友 14:33:48

嗯

一个十多年做技术的朋友 14:33:55

我关注文档和代码的一致性

一个十多年做技术的朋友 14:34:05

否则在这个上面要花费很多的精力

一个十多年做技术的朋友 14:34:22

最好文档就能直接生成代码

青润 14:36:27

如果你要做代码文档的一致性，你应该看一下我书中从需求到代码之间影射关系的那部分文字。

可以说，我现在完全可以做一个工具实现需求的任何一个变动直接对代码产生影响。

而且需求按照我定义的文档规则编写后，可以直接映射出有多少个对象，这些对象有多少主要的方法——在一定的架构模式下就可以实现，对于不同的架构模式也可以通过分析获得不同的实现方法数量和类型。

一个十多年做技术的朋友 14:37:50

是，先要设计好软件框架