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潘加宇你这个图如果说的是现状的情况，这样如实描述是对的。外星人来了，也不更改现状就是如此的事实。把握好抽象级别就行了
