系统怎么划分模块
系统如何划分模块
11.4 系统分析
需求确定之后需要对系统进行整体分析和设计。这包括系统功能的描述、对功能模块的划分和对系统流程的分析。下面首先对系统功能进行描述。
11.4.1 系统功能模块划分
模块分析是描述系统需求的一个过程，需要将需求分析中的感性描述进行抽象，提取出要实现的功能，这是整个系统开发的一个关键过程。分析的根本目的是在开发者和提出需求的人之间建立一种理解和沟通的机制。因此，这个网上订购子系统的需求分析也应该由开发人员和用户或者客户一起完成。由于这里的例子只用于帮助读者学习系统开发的过程及方法，所以对于将要开发实现的网上订购子系统实际上并没有真正的用户或客户，在开发过程中假定笔者就是系统的使用者，并由此提出具体需求。需求分析的第一步是描述系统的功能，以此确定系统的功能需求。
根据以上的用户操作需求，将系统划分如下，并对其模块的划分和功能进行描述。
用户个人信息的显示
注册用户的类别显示
注册用户的电子货币信息显示
注册用户的订单显示
注册用户的消费记录显示
注册用户的充值记录显示
用户个人信息的查询
注册用户的订单查询
注册用户的消费查询
注册用户的充值查询
整个系统的模块结构如图11.6所示。
图11.6 系统模块结构图
高内聚、底耦合
注意接口的设计
系统就是问题域，系统划分过程就是对问题分解过程。
所以明确需求而且对问题域研究透才能划分得好。
最大程度的减少耦合
按业务分类
根据团队成员的实力分配任务
业务和功能距阵
一般是根据功能和应用来划分，也有按技术层面来划分的。
先根据需求划分技术实现的不同层，然后在每个层上面根据功能来划分。层与功能。
这个没有标准，我觉得一般都是按使用软件的部门，或者是软件流程从组来分
一般是根据功能和应用来划分，也有按技术层面来划分的。
如果使用面向对象的方法，应该根据数据划分模块，高内聚原则，一个模块实现对一组相关数据的所有操作。先给数据分类，相关的数据分为一类，然后每个类别用一个模块来处理。 （按功能，按数据）
实际设计中经常根据业务分类的划分模块，比如客户有很多个部门，每个部门用的功能放在一个模块中，这样设计的好处是容易理解，但数据一致性维护会有麻烦。（按角度）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
项目的模块划分(Feature)
划分让测试来分还是让开发来分，结果可能完全不一样的。从测试角度更多地是从界面来划分，从开发角度，更多地从功能性和函数来划分。界面划分和功能性划分在一定程度上是矛盾的。一个界面可能拥有很多功能，一个功能或函数在很多地方都会用到。如果只从界面上考虑，可能会存在一个界面上的功能太多而失去了模块划分的意义。如果只从功能或函数上划分，有可能会存在划分太细或者界面上无法体现的情况。
从以上情况来看，存在2个问题：第一、模块大小的问题；第二、界面上是否体现有些功能。只要我们解决这两个问题，那么测试和开发对划分的模块也就不存在着矛盾了。
模块划分必须遵循以下原则：
一、以界面为基准树状结构
二、大小控制在10MD左右，不得在3—15MD以外。如果一个模块少于3MD，那么可以合并；如果一个模块大于15MD，那么必须再按功能细分。
三、补充隐藏性功能和函数
以上提到树状结构的模块划分。模块划分要逐步细分，部分模块会相互牵连。上级模块和下级模块肯定相牵连，其中任何一个模块变动，所有相牵连的模块都要重新测试
11.4 系统分析
需求确定之后需要对系统进行整体分析和设计。这包括系统功能的描述、对功能模块的划分和对系统流程的分析。下面首先对系统功能进行描述。
11.4.1 系统功能模块划分
模块分析是描述系统需求的一个过程，需要将需求分析中的感性描述进行抽象，提取出要实现的功能，这是整个系统开发的一个关键过程。分析的根本目的是在开发者和提出需求的人之间建立一种理解和沟通的机制。因此，这个网上订购子系统的需求分析也应该由开发人员和用户或者客户一起完成。由于这里的例子只用于帮助读者学习系统开发的过程及方法，所以对于将要开发实现的网上订购子系统实际上并没有真正的用户或客户，在开发过程中假定笔者就是系统的使用者，并由此提出具体需求。需求分析的第一步是描述系统的功能，以此确定系统的功能需求。
根据以上的用户操作需求，将系统划分如下，并对其模块的划分和功能进行描述。
用户个人信息的显示
注册用户的类别显示
注册用户的电子货币信息显示
注册用户的订单显示
注册用户的消费记录显示
注册用户的充值记录显示
用户个人信息的查询
注册用户的订单查询
注册用户的消费查询
注册用户的充值查询
整个系统的模块结构如图11.6所示。
图11.6 系统模块结构图
高内聚、底耦合
注意接口的设计
系统就是问题域，系统划分过程就是对问题分解过程。
所以明确需求而且对问题域研究透才能划分得好。
最大程度的减少耦合
按业务分类
根据团队成员的实力分配任务
业务和功能距阵
一般是根据功能和应用来划分，也有按技术层面来划分的。
先根据需求划分技术实现的不同层，然后在每个层上面根据功能来划分。层与功能。
这个没有标准，我觉得一般都是按使用软件的部门，或者是软件流程从组来分
一般是根据功能和应用来划分，也有按技术层面来划分的。
如果使用面向对象的方法，应该根据数据划分模块，高内聚原则，一个模块实现对一组相关数据的所有操作。先给数据分类，相关的数据分为一类，然后每个类别用一个模块来处理。 （按功能，按数据）
实际设计中经常根据业务分类的划分模块，比如客户有很多个部门，每个部门用的功能放在一个模块中，这样设计的好处是容易理解，但数据一致性维护会有麻烦。（按角度）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
项目的模块划分(Feature)
划分让测试来分还是让开发来分，结果可能完全不一样的。从测试角度更多地是从界面来划分，从开发角度，更多地从功能性和函数来划分。界面划分和功能性划分在一定程度上是矛盾的。一个界面可能拥有很多功能，一个功能或函数在很多地方都会用到。如果只从界面上考虑，可能会存在一个界面上的功能太多而失去了模块划分的意义。如果只从功能或函数上划分，有可能会存在划分太细或者界面上无法体现的情况。
从以上情况来看，存在2个问题：第一、模块大小的问题；第二、界面上是否体现有些功能。只要我们解决这两个问题，那么测试和开发对划分的模块也就不存在着矛盾了。
模块划分必须遵循以下原则：
一、以界面为基准树状结构
二、大小控制在10MD左右，不得在3—15MD以外。如果一个模块少于3MD，那么可以合并；如果一个模块大于15MD，那么必须再按功能细分。
三、补充隐藏性功能和函数
以上提到树状结构的模块划分。模块划分要逐步细分，部分模块会相互牵连。上级模块和下级模块肯定相牵连，其中任何一个模块变动，所有相牵连的模块都要重新测试