分系统的界定对软件开发的影响？
　

---

我在写一个软件系统的总体报告。

我本来划分了两个分系统：分系统A和分系统B。分系统B包括子系统B1,B2,B3。
我的同事也是按照这个划分在分组坐开发。

现在我在补写一个系统总体设计报告。我要告诉领导我这个系统包括几个分系统。它们互相是怎么协同起来共同完成任务的。领导希望我说明白，分系统B输出什么数据，给分系统A，分系统A又输出什么结果，诸如此类。

写的过程中，我发现原来那种划分很不便把问题说清楚。原来那种划分没有很明确的数据的流动。

现在我打算把B2中的一个子模块B21挪到A中（只是在说法上挪，实现还是按原来实现），把B21作为一个框架把我原来马马虎虎归为一类的一些小软件工具合成一个真正的有接口的分系统。（因为原来A中的各个模块都是可执行程序，互相没有数据交流，而且是通过B21调用执行的）。

这样子，我感觉能把问题说清楚了。但是，我这种说法上的变动可能会引起我同事的反感，觉得我又在改设计，其实没有。（其实，我心里也有点打鼓，到底有没有影响现在的开发).

至少有一点是要返工了。我们公司要求每个软件配置项都要有全套的需求文档和设计文档，我这里思路变了，这些文档得跟着变。

大家说说，我这样做该也不该。利弊？

如果需求变动了,觉得需要改设计,就要改设计

Martin fowler的"设计已死",就是指随着时间的推移,随着对问题认识的不断深化,随着需求和外界环境的变化,不断地得到适应新形势的设计

无数事实证明,固定的,前置的设计,不能适应革命形势变化的需要

打固定靶,打移动靶,和在战场上有效地保护自己并消灭敌人,所需的处理问题的方式是不一样的

孙子说:"水因地而制流，兵因敌而制胜。故兵无常势，水无常形，能因敌变化而取胜者，谓之神。"

希望您的同事能理解更改设计的必要性,也希望您能给出足够的理由说服他

谢谢sealv。

我已和我同事说了。我的同事基本同意。但我也惴惴然。因我是头儿，他们即使心里不同意，也会尽量附和我。

这次分系统的重新调整对开发影响不大。原来是哪个组在做的事还是谁在做。因为开发不是严格按分系统组织的，而是按软件配置项组织的。

我现在只是名义上把若干软件配置项从一个分系统挪到另一个分系统。有些相关文档要修正，我同事也基本达成共识去改。

让我头疼的是，我现在需在领导要的这份文档里说明白分系统之间的接口。但说句实在话，我对接口没有明确的概念。

接口在软件上应该表现为可被其他系统调用的函数，体现的是功能的封装和信息的提供。

这样写写似乎又有思路了。

刚才又试着想了想，比如数据处理分系统和办公自动化分系统之间的关系。我是这么分析的，请朋友们帮着看看行不行：

数据处理分系统为办公自动化分系统提供数据处理服务。它的服务以可执行程序形式存在。即办公自动化分系统可直接调用该可执行程序。它的接口就是其可执行程序本身，不带参数。

这样对不对呢？

唉，好没思路。

或者？数据处理分系统提供信息采集接口。办公自动化分系统的信息经该信息采集接口进入数据处理分系统，被统一处理？

第二种似乎更有道理些，大家帮判断一下？

你说的接口，我理解为部件之间的约束和调用关系。
对功能进行分包的管理，就出现了包之间的约束和调用关系，可以通过这种方式发现耦合问题，本着内聚-耦合的思想，应减少包与包的约束和调用。
你在之前提到的将Bxx模块调整，我想是为了减小耦合吧。
若包之间的关系稳定了，那么一个可复用的部件的诞生就很有希望了。而接口就是此部件对外的联系。

一个大的系统常常由一些子系统组成,这些子系统各自完成一些职责.而分系统的职责就是通过接口来描述的.

整个系统的工作被分解成一些部分,由各个子系统完成.确定子系统就是确定工作细分的边界.子系统A以什么方式接受什么数据,进行什么处理,以什么方式输出什么数据.子系统B又如何如何.一切都像真实世界中发生的一样.

子系统的接口,就是对外描述了子系统的职责.它回答了一个问题:这个子系统要做什么?

子系统的实现则说明子系统是如何完成其职责的.

以一个持久层子系统为例,它的职责是将所有业务对象持久,也许留有save,get,query等几个接口,供业务层来调用.而隐藏在这个接口之后的,则是持久层的实现方式,可能是直接通过jdbc,也可能是使用了某种O/R mapping框架

接口的另一层含义是,实现的方式可能有很多.

做什么?接口
怎么做?实现
　

 分系统（子系统）和对象的异同
　

---

分系统的颗粒度要比对象大（比如其职责如果用一个对象来实现将非常复杂）；分系统特别适合于表示物理上部署节点可分布的那些组件。一个系统到底可以分成多少个分系统是没有任何固定模式的，困难之处是如何划分分系统。rup中的领域模型、分析模型，非常重要的目的之一就是为了能够指导设计阶段划分分系统或packages。