详细设计和概要设计的思考

        概要设计面向需求分析的结果，通常而言是系统用例图。系统用例图可以帮助分析人员确定系统边界，明晰系统功能，利于概要设计过程中分析系统的组成部分。概要设计可以了解为将系统用例图（需求文档）向程序框架转化，这个阶段不涉及程序语言，只是以程序员的思路转化需求，即实现了需求和程序员眼中的系统构建之间的转移。这个时期，对程序员产生的结果主要是模块划分与系统功能的对应。模块的划分不一定是完善的，细节的，而是对系统粗略的程序员感知。

        详细设计阶段，面向的是模块和用例图。这个时候的用例图不再是系统用例，而是更细层次的用例如功能用例，更多使用的是时序图。同样的，这个阶段的模块不再是粗略的，系统级别的模块，而是更细致的，体现出“模块如何实现功能”这样的更小的模块。

         这个阶段，开始展现的是系统的交互细节。系统的交互即涉及到模块的划分和模块间的相互作用和时序。这种相互作用主要实现的是业务逻辑。

        这个阶段的有利工具除了能反映系统功能的用例图，反映交互顺序的时序图，还有更贴近程序员的数据流图。数据流图可以帮助我们很好的界定模块的功能边界和模块间的接口。

        详细设计考察的是设计人员的能力。设计过程是不断反复，完善的过程，设计人员的能力决定了重复修改的次数和修改的影响。

 

        在任务分配上，以前的误区是以功能需求为导向的。“某某某，去实现某个功能”。现在才发现这样的思维是我们项目无法顺利分配，开发完成后难于维护的一个主要原因。举个例子如下：

        在一个农庄里面，一块地种葡萄，一块地种苹果，种葡萄和苹果都需要肥料，所以还有个地方是生产肥料的。于是我派A去种葡萄，B 去种苹果。A需要肥料了，就在肥料地上建了产葡萄肥料的工厂，B在那建了产苹果肥料的工厂。结果，A，B都实现了要求的生产水果的功能，但是肥料就有可能出现混乱。

         体现在我们的系统中，是同一个class中，存在几个类似的函数完成类似的功能。这个就是典型的按功能划分任务的结果。功能实现人员不考虑模块的概念-- 或者有模块，但是没有考虑过，需要功能的时候，就在所谓功能模块中添加自己需要的接口。这样的结果，就是导致模块只是功能的聚合，功能之间可能有重复等。并且，最要命的是，每个人都了解或修改了几个模块，不利于模块的内聚和优化，更没有人清楚的知道，这个模块到底实现了那个接口，这极大的增加了维护难度。

       一个合理的分配方案是，按照模块分类。A,B负责自己的土地（不能在肥料用地上瞎忽悠），C负责肥料生产。A，B需要肥料时，向C请求，C来合理安排。比如，A需要磷肥和氨肥，B需要磷肥和钾肥，那么，C只需要生产磷肥，钾肥和氨肥，这样，不用重复建设，并且，C很清楚肥料的生产过程。

      作为设计人员，或者是项目负责人，比较适合的角色就是农场主。他有如下任务：

     1.概要设计：划分系统模块。即划分农庄的功能区域：苹果区，葡萄区，肥料区。

     2.详细设计：思考并管理模块间的关系。这个时候，可以不要求完全把握各模块的接口，而只需要确定各个模块的功能定义和它们之间的

合作关系，具体的合作接口（细节）不用预先设计。

          一定要注意：模块的定义必须确定，即概要设计必须合理，细小模块的划分必须合理。比起模块功能内聚，更重要的是：不该模块内处理的，必须向管理者提问：谁来提供我的需要！

        详细设计的更多任务是在协调的过程中完成的：A需要肥料，必须告诉农场主，农场主告诉C，C返回他的决定（由C实现），农场主把C的结果告诉A，这样，A 知道了C，农场主也了解了整体。在B告诉农场主，农场主告诉C之后，C可能会调整给A的接口，比如，把磷肥和氨肥混合改成磷肥氨肥单独提供，这样，可以节省磷肥的生产部件，具体怎么安排，还是有C处理。农场主只是负责记录，修改这些接口。

         需要注意的情况是，这个阶段必须首先要求模块功能定义合理、明确，要求人员主动参与，并且必须脱离代码去考虑交互，最后产生接口的稳定、详细的定义。一个可以依靠的工具就是时序图和用例图。为实现一个功能，系统中是时序图或用例图规约下的各个模块之间的调用，现实中，是几个程序员之间的沟通。 这样，无生命的模块就变成了有生命的人，人代表模块做沟通，形成群体自治，即系统。所有功能流转之后，各个模块负责人就能清晰的获得模块的具体功能，并组织好功能，同时，详细设计也完成了。

        责任是什么？责任是系统划分的一种方法，在任务分配上，它也是一个很好的策略，虽然，从简单来讲，它就是：特定模块专人实现。但是，我们实验室开发的时候，可以把详细设计下放到小组，这样，能够弥补实验室设计人员经验不足的问题，促进大家对系统的主动了解。

        需要注意：

        底层代码和核心业务逻辑必须由核心人员实现

        

          设计人员在干什么？做需求，做系统分析，做模块分析，做任务分配。详细设计在哪？在任务分配中不断完善，充分利用群体自治。

          杜绝按功能分配任务。

          编码必须放在最后实现时才考虑，其他时候，一概以用例或时序或数据流图为导向工作。

          模块交互时，要涉及具体语言的特性。