业务序列图上等待响应怎么画

Alan 2020-5-14 12:41

1133.png

各位同学,对于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->是虚线。这样修改是否更恰当

1134.png

UMLChina潘加宇

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

把握好抽象级别就行了

1135.png
weixinpanjiayu2