西門(313***50)11:25:30
潘老师，请教个问题，
如果要把系统划分成若干个子系统，在作系统用例的时候，是否要确定好子系统边界，并把相关的用例归入到子系统中？
JinPJ(270***96)11:26:48
感觉应该先分析用例，在做系统拆分。这样才能靠近高内聚，低耦合
西門(313***50)11:27:47
我已经把用例作好了，现在要按业务线及技术线把系统切成不同子系统
西門(313***50)11:29:53
把这个系统用例放一起，有几十个，再加上一些关系，成蜘蛛网了
广李福财(74***11)11:30:21
子系统是不是取名为用例包好一点呢？
潘加宇(3504847)11:31:17
子系统按照类划分，和用例无关。复习第一章，图1-1
潘加宇(3504847)11:32:12
第5章，5.5.3 错误：玩弄"子系统"
潘加宇(3504847)11:32:30
@广李福财(74***11)
你掌握得很好
西門(313***50)11:33:35
就是在作用例时候不考虑子系统这样的问题？
广李福财(74***11)11:37:04
也遇到过这种按业务线或者技术线的，我比较偏向于对业务所涉及的组织(某单位的不同业务部门)单独作为要改进的组织来进行切分分析。
如果只是作为一个整体来，感觉越整越复杂。
@潘老师，不知道这种方式是否合适？
西門(313***50)11:37:15
执行者有很多，系统用例间还有些包含，继承关系，所以就变蜘蛛网了
西門(313***50)11:39:44
我再复习一下第五章
潘加宇(3504847)11:44:04
怎么会越整越复杂？
例如，客户说要一个闹钟，这个功能，那个功能。照实写需求就是了。结果偏偏把闹钟的零件单独一个个写"需求"？其实，你是卖闹钟的，不是卖零件的。零件可以买，可以用现成的，零件的选择和组装也是灵活的，可以随便改的
归根结底，还是没有学会从卖的角度看需求。
潘加宇(3504847)11:45:31
把每行代码当成需求更简单
潘加宇(3504847)11:45:49
复习5-6章
潘加宇(3504847)11:47:06
第五章：背后可能隐藏着这样的问题：开发人员的设计能力太弱。做设计时只是把需求直通通地映射，缺乏抽象能力，当然会害怕用例变多了。开发人员没有掌握有序、系统地抽象的能力，当发现"此处似乎可以抽象"时，迫不及待想露一手，因为他害怕此时不露一手，没准以后露一手的能力和机会就消失了。这和小孩刚学习一个新东西，什么地方都想表现一下是类似的。
广李福财(74***11)12:26:34
潘老师一针见血，我反思一下自己，有时确实有这样的做法，谢谢潘老师