“高内聚、低耦合” ---- 软件模块划分的目的
软件模块划分应基于什么原则进行呢?
基于功能划分、基于层次划分、基于专业划分、基于需求划分?
当前常见的划分方式为基于专业领域的划分,如:用户操作GUI,数据处理、网络接口等专业领域划分。按专业领域划分确实可以解决很多实现上的问题,这里指的是功能上的实现。
实现了在同一模块中不允许存在两个不同专业领域的内容的要求
更有利于模块的实现
有了该划分是否就足够了呢?多年的项目经验告诉我这的确还不够。
模块划分清楚后各个模块能够实现它的功能,但我们要的是一个完整的产品,是一个多模块的有机结合,但只是将多模块堆积在一起往往!=产品。为什么会这样呢?
这里显然存在某些问题
缺少需求设计、缺少需求实现、缺少了需求管理。有需求提出、需求验收,但缺少一系列的中间环节,这显然就存在问题。
需求设计
回顾你的软件架构,在架构文档里能清楚看到模块描述,但也能看到客户的需求么?
需求实现
当你在实现软件时,考虑了模块功能如何实现,但也考虑的客户需求如何实现么?
需求管理
项目过程中我们在跟踪某个模块的实现,但有跟踪客户需求的实现么?
架构上缺少客户需求的设计、客户需求的划分,自然会缺少客户需求的实现、也缺少客户需求的管理。
因此软件模块的划分
实现上需要基于专业领域的划分
管理上需要基于客户需求的划分
软件模块划分应基于什么原则进行呢?
基于功能划分、基于层次划分、基于专业划分、基于需求划分?
当前常见的划分方式为基于专业领域的划分,如:用户操作GUI,数据处理、网络接口等专业领域划分。按专业领域划分确实可以解决很多实现上的问题,这里指的是功能上的实现。
实现了在同一模块中不允许存在两个不同专业领域的内容的要求
更有利于模块的实现
有了该划分是否就足够了呢?多年的项目经验告诉我这的确还不够。
模块划分清楚后各个模块能够实现它的功能,但我们要的是一个完整的产品,是一个多模块的有机结合,但只是将多模块堆积在一起往往!=产品。为什么会这样呢?
这里显然存在某些问题
缺少需求设计、缺少需求实现、缺少了需求管理。有需求提出、需求验收,但缺少一系列的中间环节,这显然就存在问题。
需求设计
回顾你的软件架构,在架构文档里能清楚看到模块描述,但也能看到客户的需求么?
需求实现
当你在实现软件时,考虑了模块功能如何实现,但也考虑的客户需求如何实现么?
需求管理
项目过程中我们在跟踪某个模块的实现,但有跟踪客户需求的实现么?
架构上缺少客户需求的设计、客户需求的划分,自然会缺少客户需求的实现、也缺少客户需求的管理。
因此软件模块的划分
实现上需要基于专业领域的划分
管理上需要基于客户需求的划分