这里谈到的是系统间的调用关系与分析模型中边界类的区别，另外还提到了在分析模型和设计模型中的一点区别。
2013-03-26
福州-Thomas 男9:45:31
我想问问，在分析类中，如果某个控制类需要和第三方通信，那么第三方应该当作一个边界，那么在画图的时候是 控制类发送消息到 第三方的边界类去？
北京 青润10:57:12
这应该是接口类，不是边界类。
北京 青润 10:57:46
接口类属于非UI类型的类，有人把它划作边界类来定位。
北京 青润 10:58:12
但是一般情况下，边界类指的就是UI相关的用户操作界面类。
福州-Thomas 男 15:18:56
分析类不是只有3种类型吗
福州-Thomas 男 15:19:08
边界 控制 实体， 哪里的接口类？
福州-Thomas 男 15:25:49
分析类时序图，在搞支付平台，我们对接 支付宝等，别的子系统再接我们平台
北京 青润 15:25:54
这个要看你的整体架构设计是在哪一层进行数据通信的。
北京 青润 15:26:08
一般来说这样的数据通信不可能在界面层。
福州-Thomas 男 15:26:14
嗯
福州-Thomas 男 15:26:22
在 service层
北京 青润 15:27:29
这个接口的提供属于外部连接的实现，也就是系统内的逻辑关系体现，要看你的整体的架构实现思想。
一般来说都应该是在控制层进行的实现。
福州-Thomas 男 15:27:30
界面有可能在 子系统，我们是做个支付的黑匣子系统，只对外暴露出 SOA 接口，子系统调用我们的接口 与支付宝对接
北京 青润 15:27:38
也就是mvc中的c中进行实现。
北京 青润 15:27:57
到了设计模型阶段才会根据情况分离出来接口类和具体的实现关系。
福州-Thomas 男 15:28:28
哦，我们的 C 在实现时也会是个 serivce，没有 web mvc框架
北京 青润 15:28:38
两个子系统或者子模块之间应该是c-c的调用关系。
北京 青润 15:28:57
那就不要在分析模型阶段谈设计模型的事情
北京 青润 15:29:24
不管它将来是什么形式，每一个阶段都要做自己的事情，跨阶段做开发的结果往往是得不偿失的。
福州-Thomas 男 15:29:44
那你在画支付用例 的分析类时序图时候， 和支付宝对接 不用表示吗
北京 青润 15:30:19
分析模型要有分析模型的形态，只需要标记出来这里连接一个支付系统即可。
福州-Thomas 男 15:31:34
那这个 支付系统 是 另外的一个 UML元素，还是 边界类来表示？ 按道理说 第三方支付系统相对我们的支付平台也就是个边界，我们发请求给它
北京 青润 15:32:16
自己的团队内部统一，可以通过一个message to self，上面加一个标签标识即可。
福州-Thomas 男 15:33:36
那为什么不能把它当作一个边界类呢
北京 青润 15:33:56
它本来就不是一个边界类，你为什么非要当作边界类呢？
福州-Thomas 男 15:34:35
相对于我们自己的系统来说 它就是个边界啊，我们在这个边界之外 向它发送消息
北京 青润 15:34:46
那是系统之外。
北京 青润 15:34:57
这是系统间关系调用。
福州-Thomas 男 15:35:11
哦，
Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE转载于:http://blog.itpub.net/257598/viewspace-757344/
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
