软件方法(下)分析和设计第8章分析 之 分析类图——知识篇(20211227更新)
软件方法(下)分析和设计第9章分析 之 分析类图——案例篇(20211228更新)
问题时间: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
第五章:背后可能隐藏着这样的问题:开发人员的设计能力太弱。做设计时只是把需求直通通地映射,缺乏抽象能力,当然会害怕用例变多了。开发人员没有掌握有序、系统地抽象的能力,当发现"此处似乎可以抽象"时,迫不及待想露一手,因为他害怕此时不露一手,没准以后露一手的能力和机会就消失了。这和小孩刚学习一个新东西,什么地方都想表现一下是类似的。
广李福财(74***11)12:26:34
潘老师一针见血,我反思一下自己,有时确实有这样的做法,谢谢潘老师