被弱化的模块分解

在一些实施软件工程的单位里,软件的模块分解的功能被极大地弱化。

 

模块分解仅用来满足项目估计的需要

由于实施了CMM,要进行项目策划首先就要进项目估计,而要进行项目估计就要进行产品的WBS分解——模块分解,通过估计各模块的规模,导出项目进度。然后,模块分解似乎就功成身退了,在后续的软件开发过程中再难觅其芳踪。

 

模块分解简单化,一个功能需求就是一个模块

有些开发人员的模块分解极其简单粗暴,完全按照功能需求来分解模块,有多少功能需求就分解多少模块,甚至不会考虑将非功能需求融入到模块当中。

 

这些做法违背了“模块分解”方法创立的初衷。

在解决真正大规模的问题时,软件工程人群使用“模块分解”来帮助将整体复杂度降低到一个可管理的水平。通过将系统分解成松散耦合的模块,整体的复杂度得到了降低,并且各个模块可以独立地开发。

 

要真正发挥出模块分解的功能,就要在覆盖用户需求的基础上,满足降低软件复杂度,为后续开发和维护带来便利。

 

要做好模块分解,不要按功能来分解模块,而是按照专业领域进行分解。

 

许多人可能有过经验,面对一堆功能性需求,多个不同的需求可能要放到同一个模块里,而某个需求又需要分解到多个模块里去实现。

 

比如一个词典软件(类似金山词霸的软件),通常有查询词典的功能需求和添加用户词库的功能需求,显然不可能简单地为这两个功能各分解一个模块。查询界面和添加用户词库的界面处理部分会被划成一个模块,而对词典的数据管理(查询,添加等)部分会被划分成另外一个模块。

 

仔细观察上面所说的词典软件的模块分解就会发现,所划分的两个模块属于不同的专业领域,一个是交互领域(图形界面),另一个是数据管理领域(数据结构与算法)。       

 

通过观察大量的软件的模块分解情况,其实可以发现绝大部分模块都是按照专业领域来分解的,这些专业领域包括软件公共领域的各个子领域,软件所处理业务的专业领域及其子领域等。

 

软件公共领域常见的子领域有数据结构算法,图形界面,IO处理,网络通信,数据库,加密,安全,图像处理,数学算法等,当然这些子领域还可以进一步划分出更小的子领域来。

 

软件所处理业务的专业领域则是指具体的业务方面所属的专业领域,如财务软件的业务包括了财务专业领域,CAD软件业务包括了机械制图方面的专业领域等。

 

这些不同专业领域内的内容都是被划分到不同的模块里,没有人会在同一个模块里同时实现网络通信和数据结构算法的功能。这样可以得到模块分解的一个最基本的原理:

不能在同一模块中实现两个不同专业领域的内容

 

推论1:按专业领域分解的模块是高内聚,低耦合

推论2:按专业领域分解的模块是可复用的

推论3:按专业领域分解的模块是可扩展的

推论4:按专业领域分解的模块是可维护的

 

关于模块分解的基本原理可点击阅读全文查看。

 题图来自网络。

 微信号:IdeaofSE

 

发表评论

登录后才能评论
服务中心
服务中心
联系客服
联系客服
返回顶部