Alan 2020-5-14 12:41

各位同学，对于1.3 1.6 在需求规约这样写

系统请求A系统处理XXX，

系统等待B系统发送分析结果

这样合理不？ 还是要拆成1.6拆成另一个用例，但是用户对引入系统的期望是反馈xxx结果，拆成两个用例不大恰当

UMLChina潘加宇

所有的消息，往下追究，都是异步的，难道1.1就不需要时间吗，也可以分两截来画。

关键是分清楚从涉众的视角看，哪些是“不这样不行”，哪些是“这样也行”。

如果涉众认为系统做完1.3，就可以告一段落了，不必再等待，不这样不行！那就是按照图上画。

如果如果涉众认为系统必须做到1.7才算告一段落，不这样不行！1.4-1.6是不存在的，因为涉众不在意。

如果如果涉众认为系统必须做到1.7才算告一段落，开发团队设想了一个1.4-1.6的实现方案……想也没用，因为做需求的时候，开发团队必须被杀光，系统是外包给外星人做的。

另外业务序列图上的消息的抽象级别是：“系统之间的协作”，比“对象之间的协作”要大，很可能业务序列图上的一条消息，就映射某系统的一个用例，然后在分析设计时演化出该系统内对象之间调用的很多条消息。

“系统等待”这样的语句如果描述的是意念，那就不要写，除非“等待”是系统必须做的行为（以后可能映射成wait（10000）之类的代码）。写清楚外面告诉系统什么，系统做什么，系统告诉外面什么。

图画得不错，自学能画得这样，有一定的水准了

Alan 2020-5-14 15:32

了解，谢谢潘老师，我再消化下，涉众希望是到1.7 这步， 1.4-1.6 画出来，是之看看答疑里说摄像机拍到什么就画什么，但是陷入了先实现的细节

UMLChina潘加宇

序列图一开始照这样画也行了，但映射的系统用例就是一个

Alan

嗯嗯，我觉得用例应该一个，书上说箭头指向系统的就是系统的用例，所以我在这里就有疑问，没处理过这种情况

UMLChina潘加宇

对的，序列图也改过来更好

Alan

虽然A不能响应，但是调用A时，其实是有期待的，这里应该有扩展？

UMLChina潘加宇

你是说用例规约里？调用外系统肯定有扩展，因为外系统是不受控制的

Alan

是的，说的是用例规约，在软件方法的P214 , 如果不从外系统那里得到任何结果，这个外系统就不是辅执行， 严格来说，是不能从A系统得到结果。但涉众期望在这里能得到结果

UMLChina潘加宇

有结果啊，这个结果就是对方接收了1.3，扩展条件是：A无响应，而不是A搞不定

Alan

我知道我的问题了， 因为系统调用A后，得不到响应，这个是实现，写需求时不要考虑实现

UMLChina潘加宇

这里面还是一样的，期待到什么目标。

系统已经发出消息，例如：系统播放一段声音给外面某人听，外面这个人听不听得到，系统不想管也管不着。

另一种：

系统发出消息，并感知到外系统已经收到

Alan 2020-5-14 15:59

并感知到外系统已经收到-----嗯，这里的感知外系统已经收到，并不是说要A系统回一个消息包，只要能感知外系统即可, 怎么实现，是开发人员的事

Alan 2020-5-15 9:35

如果如果涉众认为系统必须做到1.7才算告一段落，不这样不行！1.4-1.6是不存在的，因为涉众不在意。----我鄱了下书，这个说法可能不大恰当，业务用例由组织中各个系统的协作完成，要如实反映有哪些系统参与了这个业务用例片断的实现

没有1.4，业务用例不能实现，不这样不行，同时也为下一次改进提供了“现状”

把1.6修改成虚线，表示消息通知，就像A叫B借钱给C，B->是虚线。这样修改是否更恰当

UMLChina潘加宇

你这个图如果说的是现状的情况，这样如实描述是对的。外星人来了，也不更改现状就是如此的事实。

把握好抽象级别就行了