问题时间：2013/12/6
西門(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 第五章：背后可能隐藏着这样的问题：开发人员的设计能力太弱。做设计时只是把需求直通通地映射，缺乏抽象能力，当然会害怕用例变多了。开发人员没有掌握有序、系统地抽象的能力，当发现"此处似乎可以抽象"时，迫不及待想露一手，因为他害怕此时不露一手，没准以后露一手的能力和机会就消失了。这和小孩刚学习一个新东西，什么地方都想表现一下是类似的。
