培训感想

昨天参加完公司软件部的培训，把感想记录一下。

UML在软件开发过程中的运用

系统模块划分的正确性

文档的意义

1. 本人喜欢用UML来分析问题与表达思想，但一直没考虑如何利用UML的各种图形，更好地向别人表达自己的思想。在系统分析的时候，以前我喜欢用顺序图，但今天听同事的一番话，了解到，在系统算法与流程设计上，活动图和状态图起的作用与表达的清晰度上，要比顺序图强。以前在做系统分析时，特喜欢用用例图，但是都没把用例间的关系（依赖、组合、聚合、实现等）描述清楚，以致于这些用例图在后面没起到更大的作用。
2. 在系统设计阶段，今天培训的重点落在了模块设计的封装原则与层次划分技巧上。
• 目前流行的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。
3. 文档，这个是本人比较弱的一方面，这与以前做项目的时候，文档都交给别人写，自己只写程序有关，这段时间一直在努力提高这方面的能力，因为文档的阅读性远比程序高，这点在目前的项目开展中深有体会，以前看〈〈编程珠玑〉〉里说的，最好的文档是程序，总以为那是对的，但是我忽略了不是任何人都关心你的程序与系统设计，而是关心这系统的功能与特性，而这些方面，却是代码不能直接明了的说明的。文档在软件功能里，其地位非常重要，一份好的文档，能解决或避免很多在软件开发过程中出现的问题，从而达到提高生产率的效果。