UML在软件开发过程中的运用 系统模块划分的正确性 文档的意义
- 本人喜欢用UML来分析问题与表达思想,但一直没考虑如何利用UML的各种图形,更好地向别人表达自己的思想。在系统分析的时候,以前我喜欢用顺序图,但今天听同事的一番话,了解到,在系统算法与流程设计上,活动图和状态图起的作用与表达的清晰度上,要比顺序图强。以前在做系统分析时,特喜欢用用例图,但是都没把用例间的关系(依赖、组合、聚合、实现等)描述清楚,以致于这些用例图在后面没起到更大的作用。
- 在系统设计阶段,今天培训的重点落在了模块设计的封装原则与层次划分技巧上。
- 目前流行的MVC设计模式与回调函数的使用,对于应用框架(struts,spring,hibernate等)来设计开发系统的人来说,都是比较熟悉的,但是在使用上,我们经常走入误区,表现在层次划分不正确,最常见的是dao层的方法写在service层上。
- 对模块或功能的封装上,我们要做到的是,尽可能的把公用的方法都做成接口,供别人使用,让系统的代码更简洁,更高效。
- 分析一下目前使用springside这框架来开发的ebop系统,发现这框架在代码编写方面,也存在不少不够科学的地方,具体体现在系统权限管理模块的dao上面,一些方法的设计上,从属关系不好,如要获取通过用户ID获取其role,这样的方法getRoleByUserId,应该写在RoleDao里,这样,可以减少user与role的偶合。
- 在这里想总结一下个人在系统设计上的认识:
- 系统的高内聚低偶合,要实现这一点,系统在设计时,功能划分必须清晰,可以把系统的功能模块以用例图的形式来描述,注意要描述清楚各用例间的关系,看是否有依赖太强的或功能重复的。目前流行起来的webservice,它在解决旧有系统改造时偶合度太高的问题上是有优势的,但是开发一个功能较为单一的,参与开发的人员并不多的系统,用它,就有点牛刀杀鸡的感觉。
- 系统的分层,原则是层次划分准确,不混乱,持久层,业务层,表现层,这三层结构中,目前用得最多的MVC框架,这时候,很容易陷入“接口奴隶”的陷阱。比如,在用spring时,如果一个只是完成调用简单cuid操作的业务类,没有复杂数据处理的业务逻辑,功能这么单一,还写个interface,然后再实现,那它的spring配置文件配起来就不直观,并且增加工作量,在测试时也不够直观。
- 数据库设计时,我认为最低限度也得符合第三范式,我们遇到的一个问题是,不同人在开发自己负责的模块时,由于时间关系,经常会忽略掉别人负责的模块的数据表设计,往往就使数据库出现冗余,但有时候为了方便程序的开发,我们也不会百份百的遵守第三范式。
- 我觉得tapestry这个框架的思想是不错,但是它与.NET的组件式开发真的无法比,如果一定要积累一些组件,方便日后项目的使用,我觉得现在的ZK是一个值得考虑的框架。
- 最后,我认为不能够为了追求某种新思想而改变原由的,已经成熟的思想,不然的话,在没有熟悉的情况下,用这还没成为你的思想的思想去设计系统,这系统会out of your control。