软件概要设计（转）

通常说来，需求分析属于软件定义方面 
而概要设计、详细设计属于软件开发的阶段 

按照传统软件工程的软件过程,区别以下: 
1.需求分析--产生   软件功能规格说明书,须要肯定用户对软件的需求,要做到明确、无歧义。不涉及具体实现方法。用户能看得明白，开发人员也可据此进行下面的工做（概要设计） 
2.概要设计--产生   软件概要设计说明书，说明系统模块划分、选择的技术路线等，总体说明软件的实现思路。而且须要指出关键技术难点等。 
3.详细设计--产生   软件详细设计说明书，对概要设计的进一步细化，通常由各部分的担当人员依据概要设计分别完成，而后在集成，是具体的实现细节。理论上要求能够照此编码

 

 

软件概要设计作什么，怎么作

1、软件设计通常流程： 
一、先前的软件需求分析阶段，已经搞清楚了 “要解决什么问题”，并输出了《软件须要说明书》。这时一切都是理想。
二、如今进入概要设计阶段，重点说清楚“整体实现方案”，肯定软件系统的整体布局，各个子模块的功能和模块间的关系，与外部系统的关系。有一些研究与论证性的内容。并输出《软件概要设计说明书》。这时一切都是概念。
三、最后进入详细设计阶段，重点说清楚“每一个模块怎么作”，是“程序”的蓝图，肯定每一个模块采用的算法、数据结构、接口的实现、属性、参数。并输出《软件详细设计说明书》。这时一切都是实现。

2、《概要设计说明书》的通常结构: 
   一、总述：需求或目标（讲一下事情的起源）、环境、局限；
           ----主要交代背景与大环境。(非重点)
   二、整体设计：从全局的角度说一下 整体结构、功能、处理流程、有哪些模块、模块间的关系；
           ----使读者有“全局”观，为下一步深刻各个模块作好准备。
   三、外部接口：整体说明外部用户、软、硬件接口(可用资源)；(这个接口不是java的interface) 。
           ----使读者了解能够利用的外部资源。
   四、模块设计：每一个模块“作什么”、简要说明“怎么作”（输入、输出、处理逻辑、与其它模块或系统的接口），处在什么逻辑位置、物理位置； (重点)
   五、数据结构：逻辑结构、物理结构（存储在数据表中，仍是缓存中）；  
   六、容灾设计：出错信息、出错处理； （可选）
   七、监控设计：运行模块组合、控制、时间；（可选）
   八、用户界面设计：（可选）
   九、安全设计：（可选）
   十、其它设计：（可选）
   十一、制定规范（附录）： 设计原则,代码规范、接口规约、命名规则。--是小组协同开发的基础

3、模块设计是重点，多说几句： 
   能够写如下内容：
   一、模块描述：说明哪些模块实现了哪些功能；
   二、模块层次结构：可使用某个视角的软件框架图来表达；
   三、模块间的关系：模块间依赖关系的描述，通讯机制描述；
   四、模块的核心接口：说明模块传递的信息、信息的结构；
   五、处理方式设计：说一些知足功能和性能的算法；

4、怎么使用概要设计： 
   一、用来评价整体设计的可行性。
   二、用来检查设计的模块是否完整，保证每个功能都有对应的模块来实现。
   三、用来评估开发工做量、指导开发计划（在不写详细设计的状况下）。

5、最后提醒: 
   一、概要设计阶段过于重视业务流程是个误区.
   二、概要设计阶段过于重视细节实现是个误区.

 

 

摘要：   本文是在概要设计实践和学习中的一些心得与学习笔记，但愿与你们分享，若有不妥之处欢迎指正。   关键字：   概要设计，结构化，OOD 正文：   在需求明确、准备开始编码以前，要作概要设计，而详细设计可能大部分公司没有作，有作的也大部分是和编码同步进行，或者在编码以后。所以，对大部分的公司来讲，概要设计文档是惟一的设计文档，对后面的开发、测试、实施、维护工做起到关键性的影响。   1、问题的提出   概要设计写什么？概要设计怎么作？   如何判断设计的模块是完整的？   为何说设计阶段过于重视业务流程是个误区？   以需求分析文档仍是以概要设计文档来评估开发工做量、指导开发计划准确？   结构化好仍是面向对象好？   以上问题的答案请在文章中找。   2、概要设计的目的   将软件系统需求转换为将来系统的设计；   逐步开发强壮的系统构架；   使设计适合于实施环境，为提升性能而进行设计；   结构应该被分解为模块和库。   3、概要设计的任务    制定规范：代码体系、接口规约、命名规则。这是项目小组从此共同做战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，你们就有了共同的工做语言、共同的工做平台，使整个软件开发工做能够协调有序地进行。   整体结构设计：   功能（加工）－>模块：每一个功能用那些模块实现，保证每一个功能都有相应的模块来实现；   模块层次结构：某个角度的软件框架视图；   模块间的调用关系：模块间的接口的整体描述；   模块间的接口：传递的信息及其结构；   处理方式设计：知足功能和性能的算法   用户界面设计；   数据结构设计：   详细的数据结构：表、索引、文件；   算法相关逻辑数据结构及其操做；   上述操做的程序模块说明（在前台？在后台？用视图？用过程？······）   接口控制表的数据结构和使用规则   其余性能设计。   4、概要设计写什么   结构化软件设计说明书结构（因篇幅有限和过期嫌疑，在此不做过多解释）   任务：目标、环境、需求、局限；   整体设计：处理流程、整体结构与模块、功能与模块的关系；   接口设计：整体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）   数据结构：逻辑结构、物理结构，与程序结构的关系；   模块设计：每一个模块“作什么”、简要说明“怎么作”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；   运行设计：运行模块组合、控制、时间；   出错设计：出错信息、处错处理；   其余设计：保密、维护；   OO软件设计说明书结构   1 概述   系统简述、软件设计目标、参考资料、修订版本记录   这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不许备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需说起。需求规格说明书对于这部分的内容来讲是很重要的参考，看看其中明确了的功能性以及非功能性的需求。 这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特色和功能。在随后的文档部分，将解释设计是怎么来实现这些的。   2 术语表   对本文档中所使用的各类术语进行说明。若是一些术语在需求规格说明书中已经说明过了，此处不用再重复，能够指引读者参考需求说明。   3 用例   此处要求系统用用例图表述（UML），对每一个用例（正常处理的状况）要有中文叙述。   4 设计概述   4.1 简述   这部分要求突出整个设计所采用的方法（是面向对象设计仍是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）   4.2 系统结构设计   这部分要求提供高层系统结构（顶层系统结构、各子系统结构）的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。   4.3 系统界面   各类提供给用户的界面以及外部系统在此处要予以说明。若是在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，能够指引读者参考需求说明。若是系统提供了对其它系统的接口，好比说从其它软件系统导入/导出数据，必须在此说明。   4.4 约束和假定   描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。   另外若是本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种状况下，要求清楚地描述与本系统有交互的软件类型以及这样致使的约束。   实现的语言和平台也会对系统有约束，一样在此予以说明。   对于因选择具体的设计实现而致使对系统的约束，简要地描述你的想法思路，通过怎么样的权衡，为何要采起这样的设计等等。   5 对象模型   提供整个系统的对象模型，若是模型过大，按照可行的标准把它划分红小块，例如能够把客户端和服务器端的对象模型分开成两个图表述。在其中应该包含全部的系统对象。这些对象都是从理解需求后获得的。要明确哪些应该、哪些不该该被放进图中。全部对象之间的关联必须被肯定而且必须指明联系的基数。聚合和继承关系必须清楚地肯定下来。每一个图必须附有简单的说明。   6 对象描述   在这个部分叙述每一个对象的细节，它的属性、它的方法。在这以前必须从逻辑上对对象进行组织。你可能须要用结构图把对象按子系统划分好。   为每一个对象作一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。若是对象是存储在持久的数据容器中，标明它是持久对象，不然说明它是个临时对象（transient object）。   对每一个对象的每一个属性详细说明：名字、类型，若是属性不是很直观或者有约束（例如，每一个对象的该属性必须有一个惟一的值或者值域是有限正整数等）。   对每一个对象的每一个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（若是不是特别简单的话）。若是对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法须要访问或者修改的属性。最后，提供能够验证明现方法的测试案例。   7 动态模型   这部分的做用是描述系统如何响应各类事件。通常使用顺序图和状态图。   肯定不一样的场景（Scenario）是第一步，不须要肯定全部可能的场景，可是必须至少要覆盖典型的系统用例。不要本身去想固然地创造场景，一般的策略是描述那些客户能够感觉获得的场景。   7.1 场景（Scenarios）   对每一个场景作一则条目，包括如下内容：   场景名：给它一个能够望文生义的名字   场景描述：简要叙述场景是干什么的以及发生的动做的顺序。   顺序图：描述各类事件及事件发生的相对时间顺序。   7.2 状态图   这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每一个对象画一个状态图，但事实上会致使太多不指望的细节信息，只须要肯定系统中一些重要的对象并为之提供状态图便可。   8 非功能性需求   5、概要设计怎么作   结构化软件设计方法：   详细阅读需求规格说明书，理解系统建设目标、业务现状、现有系统、客户需求的各功能说明；   分析数据流图，弄清数据流加工的过程；   根据数据流图决定数据处理问题的类型（变换型、事务型、其余型）；   经过以上分析，推导出系统的初始结构图；   对初始结构图进行改进完善：全部的加工都要能对应到相应模块（模块的完整性在于他们完成了需求中的全部加工），消除彻底类似或局部类似的重复功能（智者察同），理清模块间的层次、控制关系，减小高扇出结构，随着深度增大扇入，平衡模块大小。   由对数据字典的修改补充完善，导出逻辑数据结构，导出每种数据结构上的操做，这些操做应当属于某个模块。   肯定系统包含哪些应用服务系统、客户端、数据库管理系统；   肯定每一个模块放在哪一个应用服务器或客户端的哪一个目录、哪一个文件（库），或是在数据库内部创建的对象。   对每一个筛选后的模块进行列表说明。   对逻辑数据结构进行列表说明。   根据结构化软件设计说明书结构对其余须要说明的问题进行补充说明，造成概要设计说明书。   OO软件设计方法：   在OOA基础上设计对象与类：在问题领域分析（业务建模和需求分析）以后，开始创建系统构架。   第一步是抽取创建领域的概念模型，在UML中表现为创建对象类图、活动图和交互图。对象类就是从对象中通过“察同”找出某组对象之间的共同特征而造成类：   对象与类的属性：数据结构；   对象与类的服务操做：操做的实现算法；   对象与类的各外部联系的实现结构；   设计策略：充分利用现有的类；   方法：继承、复用、演化；   活动图用于定义工做流，主要说明工做流的5W（Do What、Who Do、When Do、Where Do、Why Do）等问题，交互图把人员和业务联系在一块儿是为了理解交互过程，发现业务工做流中相互交互的各类角色。   第二步是构建完善系统结构：对系统进行分解，将大系统分解为若干子系统，子系统分解为若干软件组件，并说明子系统之间的静态和动态接口，每一个子系统能够由用例模型、分析模型、设计模型、测试模型表示。软件系统结构的两种方式：层次、块状   层次结构：系统、子系统、模块、组件（同一层之间具备独立性）；   块状结构：相互之间弱耦合   系统的组成部分：   问题论域：业务相关类和对象(OOA的重点)；   人机界面：窗口、菜单、按钮、命令等等；   数据管理：数据管理方法、逻辑物理结构、操做对象类；   任务管理：任务协调和管理进程；   第三步是利用“4＋1”视图描述系统架构：用例视图及剧本；说明体系结构的设计视图；以模块形式组成包和层包含概要实现模型的实现视图；说明进程与线程及其架构、分配和相互交互关系的过程视图；说明系统在操做平台上的物理节点和其上的任务分配的配置视图。在RUP中还有可选的数据视图。   第四步是性能优化（速度、资源、内存）、模型清晰化、简单化（简单就是享受）。   6、概要设计的原则   整体原则和方法：由粗到细的原则，互相结合的原则，定性分析和定量分析相结合的方法，分解和协调的方法和模型化方法。   要系统考虑系统的通常性、关联性、总体性和层次性。   分解协调：目的是为了创造更好的系统。系统分解是指将一个复杂的系统分解为若干个子系统，系统协调一是系统内协调，即根据系统的总结构、总功能、总任务和总目标的要求，使各个子系统之间互相协调配合，在各个子系统局部优化基础上，经过内部平衡的协调控制，实现系统的总体优化；   屏蔽抽象：从简单的框架开始，隐含细节；   一致性：统一的规范、统一的标准、统一的文件模式；   每一个模块应当有一个统一命名的容易理解的名字；   编码：由外向内（界面－>核心）；   面向用户：概要设计是对于按钮按下后系统“怎么作”的简要说明；   模块、组件的充分独立性、封闭性；   同时考虑静态结构与动态运行；   每一个逻辑对象都应当说明其所处物理对象（非一一对应）；   每一个物理对象都有合适的开发人员，而且利于分工与组装。（详细说明见本人另外一篇文章：系统构架设计应考虑的因素）；   确立每一个构架视图的总体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口；   软件构架与使用的技术平台密切相关，目前经常使用的平台有J2EE、.NET、CORBA等等，所以具体的软件构架人员应当具有使用这些平台的软件开发经验；   经过需求功能与设计模块之间的列表对应，检查每一个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现（模块）的完整性，同时能够检查重复和没必要要的模块。   在需求调研分析过程当中对业务处理过程了解的完整性和准确性很是重要。调查了解清楚全部的业务流程才能设计出适合各流程业务节点用户业务特色和习惯的软件，使开发出来的软件更受欢迎。固然在进行软件概要设计时，要尽可能排除业务流程的制约，即把流程中的各项业务结点工做做为独立的对象，设计成独立的模块，充分考虑他们与其余各类业务对象模块的接口，在流程之间经过业务对象模块的相互调用实现各类业务，这样，在业务流程发生有限的变化时（每一个业务模块自己的业务逻辑没有变的状况下），就可以比较方便地修改系统程序模块间的调用关系而实现新的需求。若是这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块调用规则便可。   7、概要设计的重要输出   编码规范：信息形式、接口规约、命名规则；   物理模型：组件图、配置图；   不一样角度的构架视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；   系统整体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；   两个不可忽视的输出：   与需求功能的关系：对于需求中的每个功能，用哪一层、哪一个模块、哪一个类、哪一个对象来实现（一对多关系）；反过来，应当说明将要建立的系统每一层、每一个模块、每一个对象、每个类“作什么”，他们是为了帮助实现哪些功能（一对多关系）。（需求的颗粒度在一开始每每是比较粗的，所以根据功能点对于总体项目规模的估计或获得项目WBS其偏差范围也是比较大的。更为重要的缘由是，需求每每不是编码工做分解的准确依据，由于一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，所以只有在概要设计完成之后才能准确地获得详细设计或编码阶段的二次WBS，并估计较为准确的总体项目规模。）   逻辑与物理位置：每一个对象在逻辑上分别落在哪一层、哪一个模块、哪一个类；在物理上每一个模块、每一个对象、每个类放在哪一个应用服务器或客户端的哪一个目录、哪一个文件（库），或者是创建在数据库管理系统中的什么东东（过程、函数、视图、触发器等等）。   8、结构化与面向对象方法特色比较   1. 从概念方面看，结构化软件是功能的集合，经过模块以及模块和模块之间的分层调用关系实现；面向对象软件是事物的集合，经过对象以及对象和对象之间的通信联系实现；   2. 从构成方面看，结构化软件＝过程＋数据，以过程为中心；面向对象软件＝（数据＋相应操做）的封装，以数据为中心；   3. 从运行控制方面看，结构化软件采用顺序处理方式，由过程驱动控制；面向对象软件采用交互式、并行处理方式，由消息驱动控制；   4. 从开发方面看，结构化方法的工做重点是设计；面向对象方法的工做重点是分析；可是，在结构化方法中，分析阶段和设计阶段采用了不相吻合的表达方式，须要把在分析阶段采用的具备网络特征的数据流图转换为设计阶段采用的具备分层特征的结构图，在面向对象方法中则不存在这一问题。   5. 从应用方面看，相对而言，结构化方法更加适合数据类型比较简单的数值计算和数据统计管理软件的开发；面向对象方法更加适合大型复杂的人机交互式软件和数据统计管理软件的开发；

 

 

 

概要设计与详细设计的区别

概要设计就是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每一个模块的功能等等。同时，还要设计该项目的应用系统的整体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。 
详细设计阶段就是为每一个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。

概要设计阶段一般获得软件结构图 
详细设计阶段经常使用的描述方式有：流程图、N-S图、PAD图、伪代码等

概要设计和详细设计

在软件设计中，你们常常问到的一个问题是：概要设计应该怎样一个概要法，详细设计应该怎样一个详细法？ 
这个问题在公司内部常常有人问。如今陈述一下。 
咱们公司的研发流程是瀑布型的，这个模型中的分析、设计阶段是基于经典的结构化方法。 

结构化设计方法的基本思路是：按照问题域，将软件逐级细化，分解为没必要再分解的的模块，每一个模块完成必定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。模块的概念，和编程语言中的子程序或函数是对应的。

这样一来，设计能够明显地划分红两个阶段： 

概要（结构）设计阶段：把软件按照必定的原则分解为模块层次，赋予每一个模块必定的任务，并肯定模块间调用关系和接口。 
详细设计阶段：依据概要设计阶段的分解，设计每一个模块内的算法、流程等。

概要设计阶段：

在这个阶段，设计者会大体考虑并照顾模块的内部实现，但不过多纠缠于此。主要集中于划分模块、分配任务、定义调用关系。模块间的接口与传参在这个阶段要定得 十分细致明确，应编写严谨的数据字典，避免后续设计产生不解或误解。概要设计通常不是一次就能作到位，而是反复地进行结构调整。典型的调整是合并功能重复的模块，或者进一步分解出能够复用的模块。在概要设计阶段，应最大限度地提取能够重用的模块，创建合理的结构体系，节省后续环节的工做量。 

概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据，各个模块的详细设计就能够并行展开了。

详细设计阶段:

在这个阶段，各个模块能够分给不一样的人去并行设计。在详细设计阶段，设计者的工做对象是一个模块，根据概要设计赋予的局部任务和对外接口，设计并表达出模块的算法、流程、状态转换等内容。这里要注意，若是发现有结构调整（如分解出子模块等）的必要，必须返回到概要设计阶段，将调整反应到概要设计文档中，而不 能就地解决，不打招呼。详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。一个模块一篇详细设计文档。

概要设计文档至关于机械设计中的装配图，而详细设计文档至关于机械设计中的零件图。文档的编排、装订方式也能够参考机械图纸的方法。 
咱们公司对模块的认识和传统定义有所不一样，认为是较大的软件功能单元才能够称做模块。这种认识使你们对概要设计和详细设计的分工产生了混乱的理解，下降了文档的可用性，应该予以纠正。 
概要设计中较顶层的部分即是所谓的方案。方案文档的做用是在宏观的角度上保持设计的合理性。

有的项目采用面向对象的分析、设计方法。可能在概要设计、详细设计的分工上疑问更多。其实，面向对象的分析、设计方法并无强调结构化方法那样的阶段性，所以通常不引入概要、详细设计的概念。若是按照公司的文档体系，非要有这种分工的话，能够将包的划分、类及对象间的关系、类的对外属性、方法及协做设计看作 概要设计；类属性、方法的内部实现看作详细设计。

1.需求分析--产生软件功能规格说明书,须要肯定用户对软件的需求,要做到明确、无歧义。不涉及具体实现方法。用户能看得明白，开发人员也可据此进行下面的工做（概要设计）。 
2.概要设计--产生软件概要设计说明书，说明系统模块划分、选择的技术路线等，总体说明软件的实现思路。而且须要指出关键技术难点等。 
3.详细设计--产生软件详细设计说明书，对概要设计的进一步细化，通常由各部分的担当人员依据概要设计分别完成，而后在集成，是具体的实现细节。理论上要求能够照此编码。

概要设计和详细设计的区别与联系

软件设计采用自顶向下、逐次功能展开的设计方法，首先完成整体设计，而后完成各有机组成部分的设计。

根据工做性质和内容的不一样，软件设计分为概要设计和详细设计。概要设计实现软件的整体设计、模块划分、用户界面设计、数据库设计等等；详细设计则根据概要设计所作的模块划分，实现各模块的算法设计，实现用户界面设计、数据结构设计的细化，等等。

概要设计是详细设计的基础，必须在详细设计以前完成，概要设计经复查确认后才能够开始详细设计。概要设计，必须完成概要设计文档，包括系统的整体设计文档、以及各个模块的概要设计文档。每一个模块的设计文档都应该独立成册。

详细设计必须遵循概要设计来进行。详细设计方案的更改，不得影响到概要设计方案；若是须要更改概要设计，必须通过项目经理的赞成。详细设计，应该完成详细设计文档，主要是模块的详细设计方案说明。和概要设计同样，每一个模块的详细设计文档都应该独立成册。

概要设计里面的数据库设计应该重点在描述数据关系上，说明数据的前因后果，在这里应该结合咱们的一下结果数据，说明这些结果数据的源点，咱们这样设计的目的和缘由。详细设计里的数据库设计就应该是一份完善的数据结构文档，就是一个包括类型、命名、精度、字段说明、表说明等内容的数据字典。

概要设计里的功能应该是重点在功能描述，对需求的解释和整合，总体划分功能模块，并对各功能模块进行详细的图文描述，应该让读者大体了解系统做完后大致的结构和操做模式。详细设计则是重点在描述系统的实现方式，各模块详细说明实现功能所需的类及具体的方法函数，包括涉及到的sql语句等。

 

概要设计，详细设计之间的关系是什么？

Q:
个人见解：
概要设计只说明系统有多少个模块，各模块之间的接口和个模块自己的功能
详细设计说明某个具体模块如何实现，粒度应该比程序略高一些

可是问题来了，各个模块之间是有层次关系的，也有前后逻辑关系。这就说明，在概要设计中，还必须考虑模块的实现细节，不然，你怎么知道这个模块下面要划分子模块？你怎么知道各子模块的调用顺序？
这就说明，概要设计和详细设计是重叠进行的，而软件工程书上说的确是顺序进行的，不知道是否是个人理解有问题。

举个例子，例如排序程序，若是设计2个模块：
一个主模块用于排序子模块用于交换2个变量，主模块调用子模块，可是子模块是怎么设计出来的呢？确定是你先想到了用冒泡等排序方式的时候须要交换数据，这已经考虑了主模块足够多的细节，彷佛属于"详细设计"了，可是目前进行的是概要设计，这就产生了我所说的重叠的状况。

A:

看看上面的帖子，有意思的居多。

上面也有朋友说到用建筑的例子来比喻。

软件的概要设计，主要是创建软件系统的总体架构，也就是咱们在盖房子时候，须要先将房子的整个架子构建起来。

软件的详细设计，主要是将软件系统的各个部分的具体设计方法、逻辑、功能采用文字方式进行表述。这样在实现过程当中，Coding人员原则上严格按此进行代码实现便可。

这样的一个最为简单的例证：咱们能够将代码交付第三方来作。验证与跟踪采起设计来。

我看上面还有一个朋友说：快速作代码。这个自己没有值得批评之处。但只要想一下，你写的代码没有任何设计思想、文档留下的状况，一旦你离开，如何维护？从新设计吗？仍是花费几倍人力去研究你写的几千/万，甚至几十万行代码？若是是这样的，你没错，关键是大家老板太对了，钱算什么。

软件设计说明书

 

通常说来，需求分析属于软件定义方面 
而概要设计、详细设计属于软件开发的阶段 

按照传统软件工程的软件过程,区别以下: 
1.需求分析--产生   软件功能规格说明书,须要肯定用户对软件的需求,要做到明确、无歧义。不涉及具体实现方法。用户能看得明白，开发人员也可据此进行下面的工做（概要设计） 
2.概要设计--产生   软件概要设计说明书，说明系统模块划分、选择的技术路线等，总体说明软件的实现思路。而且须要指出关键技术难点等。 
3.详细设计--产生   软件详细设计说明书，对概要设计的进一步细化，通常由各部分的担当人员依据概要设计分别完成，而后在集成，是具体的实现细节。理论上要求能够照此编码

 

 

软件概要设计作什么，怎么作

1、软件设计通常流程： 
一、先前的软件需求分析阶段，已经搞清楚了 “要解决什么问题”，并输出了《软件须要说明书》。这时一切都是理想。
二、如今进入概要设计阶段，重点说清楚“整体实现方案”，肯定软件系统的整体布局，各个子模块的功能和模块间的关系，与外部系统的关系。有一些研究与论证性的内容。并输出《软件概要设计说明书》。这时一切都是概念。
三、最后进入详细设计阶段，重点说清楚“每一个模块怎么作”，是“程序”的蓝图，肯定每一个模块采用的算法、数据结构、接口的实现、属性、参数。并输出《软件详细设计说明书》。这时一切都是实现。

2、《概要设计说明书》的通常结构: 
   一、总述：需求或目标（讲一下事情的起源）、环境、局限；
           ----主要交代背景与大环境。(非重点)
   二、整体设计：从全局的角度说一下 整体结构、功能、处理流程、有哪些模块、模块间的关系；
           ----使读者有“全局”观，为下一步深刻各个模块作好准备。
   三、外部接口：整体说明外部用户、软、硬件接口(可用资源)；(这个接口不是java的interface) 。
           ----使读者了解能够利用的外部资源。
   四、模块设计：每一个模块“作什么”、简要说明“怎么作”（输入、输出、处理逻辑、与其它模块或系统的接口），处在什么逻辑位置、物理位置； (重点)
   五、数据结构：逻辑结构、物理结构（存储在数据表中，仍是缓存中）；  
   六、容灾设计：出错信息、出错处理； （可选）
   七、监控设计：运行模块组合、控制、时间；（可选）
   八、用户界面设计：（可选）
   九、安全设计：（可选）
   十、其它设计：（可选）
   十一、制定规范（附录）： 设计原则,代码规范、接口规约、命名规则。--是小组协同开发的基础

3、模块设计是重点，多说几句： 
   能够写如下内容：
   一、模块描述：说明哪些模块实现了哪些功能；
   二、模块层次结构：可使用某个视角的软件框架图来表达；
   三、模块间的关系：模块间依赖关系的描述，通讯机制描述；
   四、模块的核心接口：说明模块传递的信息、信息的结构；
   五、处理方式设计：说一些知足功能和性能的算法；

4、怎么使用概要设计： 
   一、用来评价整体设计的可行性。
   二、用来检查设计的模块是否完整，保证每个功能都有对应的模块来实现。
   三、用来评估开发工做量、指导开发计划（在不写详细设计的状况下）。

5、最后提醒: 
   一、概要设计阶段过于重视业务流程是个误区.
   二、概要设计阶段过于重视细节实现是个误区.

 

 

摘要：   本文是在概要设计实践和学习中的一些心得与学习笔记，但愿与你们分享，若有不妥之处欢迎指正。   关键字：   概要设计，结构化，OOD 正文：   在需求明确、准备开始编码以前，要作概要设计，而详细设计可能大部分公司没有作，有作的也大部分是和编码同步进行，或者在编码以后。所以，对大部分的公司来讲，概要设计文档是惟一的设计文档，对后面的开发、测试、实施、维护工做起到关键性的影响。   1、问题的提出   概要设计写什么？概要设计怎么作？   如何判断设计的模块是完整的？   为何说设计阶段过于重视业务流程是个误区？   以需求分析文档仍是以概要设计文档来评估开发工做量、指导开发计划准确？   结构化好仍是面向对象好？   以上问题的答案请在文章中找。   2、概要设计的目的   将软件系统需求转换为将来系统的设计；   逐步开发强壮的系统构架；   使设计适合于实施环境，为提升性能而进行设计；   结构应该被分解为模块和库。   3、概要设计的任务    制定规范：代码体系、接口规约、命名规则。这是项目小组从此共同做战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，你们就有了共同的工做语言、共同的工做平台，使整个软件开发工做能够协调有序地进行。   整体结构设计：   功能（加工）－>模块：每一个功能用那些模块实现，保证每一个功能都有相应的模块来实现；   模块层次结构：某个角度的软件框架视图；   模块间的调用关系：模块间的接口的整体描述；   模块间的接口：传递的信息及其结构；   处理方式设计：知足功能和性能的算法   用户界面设计；   数据结构设计：   详细的数据结构：表、索引、文件；   算法相关逻辑数据结构及其操做；   上述操做的程序模块说明（在前台？在后台？用视图？用过程？······）   接口控制表的数据结构和使用规则   其余性能设计。   4、概要设计写什么   结构化软件设计说明书结构（因篇幅有限和过期嫌疑，在此不做过多解释）   任务：目标、环境、需求、局限；   整体设计：处理流程、整体结构与模块、功能与模块的关系；   接口设计：整体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）   数据结构：逻辑结构、物理结构，与程序结构的关系；   模块设计：每一个模块“作什么”、简要说明“怎么作”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；   运行设计：运行模块组合、控制、时间；   出错设计：出错信息、处错处理；   其余设计：保密、维护；   OO软件设计说明书结构   1 概述   系统简述、软件设计目标、参考资料、修订版本记录   这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不许备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需说起。需求规格说明书对于这部分的内容来讲是很重要的参考，看看其中明确了的功能性以及非功能性的需求。 这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特色和功能。在随后的文档部分，将解释设计是怎么来实现这些的。   2 术语表   对本文档中所使用的各类术语进行说明。若是一些术语在需求规格说明书中已经说明过了，此处不用再重复，能够指引读者参考需求说明。   3 用例   此处要求系统用用例图表述（UML），对每一个用例（正常处理的状况）要有中文叙述。   4 设计概述   4.1 简述   这部分要求突出整个设计所采用的方法（是面向对象设计仍是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）   4.2 系统结构设计   这部分要求提供高层系统结构（顶层系统结构、各子系统结构）的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。   4.3 系统界面   各类提供给用户的界面以及外部系统在此处要予以说明。若是在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，能够指引读者参考需求说明。若是系统提供了对其它系统的接口，好比说从其它软件系统导入/导出数据，必须在此说明。   4.4 约束和假定   描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。   另外若是本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种状况下，要求清楚地描述与本系统有交互的软件类型以及这样致使的约束。   实现的语言和平台也会对系统有约束，一样在此予以说明。   对于因选择具体的设计实现而致使对系统的约束，简要地描述你的想法思路，通过怎么样的权衡，为何要采起这样的设计等等。   5 对象模型   提供整个系统的对象模型，若是模型过大，按照可行的标准把它划分红小块，例如能够把客户端和服务器端的对象模型分开成两个图表述。在其中应该包含全部的系统对象。这些对象都是从理解需求后获得的。要明确哪些应该、哪些不该该被放进图中。全部对象之间的关联必须被肯定而且必须指明联系的基数。聚合和继承关系必须清楚地肯定下来。每一个图必须附有简单的说明。   6 对象描述   在这个部分叙述每一个对象的细节，它的属性、它的方法。在这以前必须从逻辑上对对象进行组织。你可能须要用结构图把对象按子系统划分好。   为每一个对象作一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。若是对象是存储在持久的数据容器中，标明它是持久对象，不然说明它是个临时对象（transient object）。   对每一个对象的每一个属性详细说明：名字、类型，若是属性不是很直观或者有约束（例如，每一个对象的该属性必须有一个惟一的值或者值域是有限正整数等）。   对每一个对象的每一个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（若是不是特别简单的话）。若是对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法须要访问或者修改的属性。最后，提供能够验证明现方法的测试案例。   7 动态模型   这部分的做用是描述系统如何响应各类事件。通常使用顺序图和状态图。   肯定不一样的场景（Scenario）是第一步，不须要肯定全部可能的场景，可是必须至少要覆盖典型的系统用例。不要本身去想固然地创造场景，一般的策略是描述那些客户能够感觉获得的场景。   7.1 场景（Scenarios）   对每一个场景作一则条目，包括如下内容：   场景名：给它一个能够望文生义的名字   场景描述：简要叙述场景是干什么的以及发生的动做的顺序。   顺序图：描述各类事件及事件发生的相对时间顺序。   7.2 状态图   这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每一个对象画一个状态图，但事实上会致使太多不指望的细节信息，只须要肯定系统中一些重要的对象并为之提供状态图便可。   8 非功能性需求   5、概要设计怎么作   结构化软件设计方法：   详细阅读需求规格说明书，理解系统建设目标、业务现状、现有系统、客户需求的各功能说明；   分析数据流图，弄清数据流加工的过程；   根据数据流图决定数据处理问题的类型（变换型、事务型、其余型）；   经过以上分析，推导出系统的初始结构图；   对初始结构图进行改进完善：全部的加工都要能对应到相应模块（模块的完整性在于他们完成了需求中的全部加工），消除彻底类似或局部类似的重复功能（智者察同），理清模块间的层次、控制关系，减小高扇出结构，随着深度增大扇入，平衡模块大小。   由对数据字典的修改补充完善，导出逻辑数据结构，导出每种数据结构上的操做，这些操做应当属于某个模块。   肯定系统包含哪些应用服务系统、客户端、数据库管理系统；   肯定每一个模块放在哪一个应用服务器或客户端的哪一个目录、哪一个文件（库），或是在数据库内部创建的对象。   对每一个筛选后的模块进行列表说明。   对逻辑数据结构进行列表说明。   根据结构化软件设计说明书结构对其余须要说明的问题进行补充说明，造成概要设计说明书。   OO软件设计方法：   在OOA基础上设计对象与类：在问题领域分析（业务建模和需求分析）以后，开始创建系统构架。   第一步是抽取创建领域的概念模型，在UML中表现为创建对象类图、活动图和交互图。对象类就是从对象中通过“察同”找出某组对象之间的共同特征而造成类：   对象与类的属性：数据结构；   对象与类的服务操做：操做的实现算法；   对象与类的各外部联系的实现结构；   设计策略：充分利用现有的类；   方法：继承、复用、演化；   活动图用于定义工做流，主要说明工做流的5W（Do What、Who Do、When Do、Where Do、Why Do）等问题，交互图把人员和业务联系在一块儿是为了理解交互过程，发现业务工做流中相互交互的各类角色。   第二步是构建完善系统结构：对系统进行分解，将大系统分解为若干子系统，子系统分解为若干软件组件，并说明子系统之间的静态和动态接口，每一个子系统能够由用例模型、分析模型、设计模型、测试模型表示。软件系统结构的两种方式：层次、块状   层次结构：系统、子系统、模块、组件（同一层之间具备独立性）；   块状结构：相互之间弱耦合   系统的组成部分：   问题论域：业务相关类和对象(OOA的重点)；   人机界面：窗口、菜单、按钮、命令等等；   数据管理：数据管理方法、逻辑物理结构、操做对象类；   任务管理：任务协调和管理进程；   第三步是利用“4＋1”视图描述系统架构：用例视图及剧本；说明体系结构的设计视图；以模块形式组成包和层包含概要实现模型的实现视图；说明进程与线程及其架构、分配和相互交互关系的过程视图；说明系统在操做平台上的物理节点和其上的任务分配的配置视图。在RUP中还有可选的数据视图。   第四步是性能优化（速度、资源、内存）、模型清晰化、简单化（简单就是享受）。   6、概要设计的原则   整体原则和方法：由粗到细的原则，互相结合的原则，定性分析和定量分析相结合的方法，分解和协调的方法和模型化方法。   要系统考虑系统的通常性、关联性、总体性和层次性。   分解协调：目的是为了创造更好的系统。系统分解是指将一个复杂的系统分解为若干个子系统，系统协调一是系统内协调，即根据系统的总结构、总功能、总任务和总目标的要求，使各个子系统之间互相协调配合，在各个子系统局部优化基础上，经过内部平衡的协调控制，实现系统的总体优化；   屏蔽抽象：从简单的框架开始，隐含细节；   一致性：统一的规范、统一的标准、统一的文件模式；   每一个模块应当有一个统一命名的容易理解的名字；   编码：由外向内（界面－>核心）；   面向用户：概要设计是对于按钮按下后系统“怎么作”的简要说明；   模块、组件的充分独立性、封闭性；   同时考虑静态结构与动态运行；   每一个逻辑对象都应当说明其所处物理对象（非一一对应）；   每一个物理对象都有合适的开发人员，而且利于分工与组装。（详细说明见本人另外一篇文章：系统构架设计应考虑的因素）；   确立每一个构架视图的总体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口；   软件构架与使用的技术平台密切相关，目前经常使用的平台有J2EE、.NET、CORBA等等，所以具体的软件构架人员应当具有使用这些平台的软件开发经验；   经过需求功能与设计模块之间的列表对应，检查每一个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现（模块）的完整性，同时能够检查重复和没必要要的模块。   在需求调研分析过程当中对业务处理过程了解的完整性和准确性很是重要。调查了解清楚全部的业务流程才能设计出适合各流程业务节点用户业务特色和习惯的软件，使开发出来的软件更受欢迎。固然在进行软件概要设计时，要尽可能排除业务流程的制约，即把流程中的各项业务结点工做做为独立的对象，设计成独立的模块，充分考虑他们与其余各类业务对象模块的接口，在流程之间经过业务对象模块的相互调用实现各类业务，这样，在业务流程发生有限的变化时（每一个业务模块自己的业务逻辑没有变的状况下），就可以比较方便地修改系统程序模块间的调用关系而实现新的需求。若是这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块调用规则便可。   7、概要设计的重要输出   编码规范：信息形式、接口规约、命名规则；   物理模型：组件图、配置图；   不一样角度的构架视图：用例视图、逻辑视图、进程视图、部署视图、实施视图、数据视图（可选）；   系统整体布局：哪些部分组成、各部分在物理上、逻辑上的相互关系；   两个不可忽视的输出：   与需求功能的关系：对于需求中的每个功能，用哪一层、哪一个模块、哪一个类、哪一个对象来实现（一对多关系）；反过来，应当说明将要建立的系统每一层、每一个模块、每一个对象、每个类“作什么”，他们是为了帮助实现哪些功能（一对多关系）。（需求的颗粒度在一开始每每是比较粗的，所以根据功能点对于总体项目规模的估计或获得项目WBS其偏差范围也是比较大的。更为重要的缘由是，需求每每不是编码工做分解的准确依据，由于一个需求的功能点可能对应多个代码模块，而多个需求的功能点也可能只对应一个或少数代码模块，同时还有软件复用等因素要考虑，所以只有在概要设计完成之后才能准确地获得详细设计或编码阶段的二次WBS，并估计较为准确的总体项目规模。）   逻辑与物理位置：每一个对象在逻辑上分别落在哪一层、哪一个模块、哪一个类；在物理上每一个模块、每一个对象、每个类放在哪一个应用服务器或客户端的哪一个目录、哪一个文件（库），或者是创建在数据库管理系统中的什么东东（过程、函数、视图、触发器等等）。   8、结构化与面向对象方法特色比较   1. 从概念方面看，结构化软件是功能的集合，经过模块以及模块和模块之间的分层调用关系实现；面向对象软件是事物的集合，经过对象以及对象和对象之间的通信联系实现；   2. 从构成方面看，结构化软件＝过程＋数据，以过程为中心；面向对象软件＝（数据＋相应操做）的封装，以数据为中心；   3. 从运行控制方面看，结构化软件采用顺序处理方式，由过程驱动控制；面向对象软件采用交互式、并行处理方式，由消息驱动控制；   4. 从开发方面看，结构化方法的工做重点是设计；面向对象方法的工做重点是分析；可是，在结构化方法中，分析阶段和设计阶段采用了不相吻合的表达方式，须要把在分析阶段采用的具备网络特征的数据流图转换为设计阶段采用的具备分层特征的结构图，在面向对象方法中则不存在这一问题。   5. 从应用方面看，相对而言，结构化方法更加适合数据类型比较简单的数值计算和数据统计管理软件的开发；面向对象方法更加适合大型复杂的人机交互式软件和数据统计管理软件的开发；

 

 

 

概要设计与详细设计的区别

概要设计就是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每一个模块的功能等等。同时，还要设计该项目的应用系统的整体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。 
详细设计阶段就是为每一个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。

概要设计阶段一般获得软件结构图 
详细设计阶段经常使用的描述方式有：流程图、N-S图、PAD图、伪代码等

概要设计和详细设计

在软件设计中，你们常常问到的一个问题是：概要设计应该怎样一个概要法，详细设计应该怎样一个详细法？ 
这个问题在公司内部常常有人问。如今陈述一下。 
咱们公司的研发流程是瀑布型的，这个模型中的分析、设计阶段是基于经典的结构化方法。 

结构化设计方法的基本思路是：按照问题域，将软件逐级细化，分解为没必要再分解的的模块，每一个模块完成必定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。模块的概念，和编程语言中的子程序或函数是对应的。

这样一来，设计能够明显地划分红两个阶段： 

概要（结构）设计阶段：把软件按照必定的原则分解为模块层次，赋予每一个模块必定的任务，并肯定模块间调用关系和接口。 
详细设计阶段：依据概要设计阶段的分解，设计每一个模块内的算法、流程等。

概要设计阶段：

在这个阶段，设计者会大体考虑并照顾模块的内部实现，但不过多纠缠于此。主要集中于划分模块、分配任务、定义调用关系。模块间的接口与传参在这个阶段要定得 十分细致明确，应编写严谨的数据字典，避免后续设计产生不解或误解。概要设计通常不是一次就能作到位，而是反复地进行结构调整。典型的调整是合并功能重复的模块，或者进一步分解出能够复用的模块。在概要设计阶段，应最大限度地提取能够重用的模块，创建合理的结构体系，节省后续环节的工做量。 

概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据，各个模块的详细设计就能够并行展开了。

详细设计阶段:

在这个阶段，各个模块能够分给不一样的人去并行设计。在详细设计阶段，设计者的工做对象是一个模块，根据概要设计赋予的局部任务和对外接口，设计并表达出模块的算法、流程、状态转换等内容。这里要注意，若是发现有结构调整（如分解出子模块等）的必要，必须返回到概要设计阶段，将调整反应到概要设计文档中，而不 能就地解决，不打招呼。详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。一个模块一篇详细设计文档。

概要设计文档至关于机械设计中的装配图，而详细设计文档至关于机械设计中的零件图。文档的编排、装订方式也能够参考机械图纸的方法。 
咱们公司对模块的认识和传统定义有所不一样，认为是较大的软件功能单元才能够称做模块。这种认识使你们对概要设计和详细设计的分工产生了混乱的理解，下降了文档的可用性，应该予以纠正。 
概要设计中较顶层的部分即是所谓的方案。方案文档的做用是在宏观的角度上保持设计的合理性。

有的项目采用面向对象的分析、设计方法。可能在概要设计、详细设计的分工上疑问更多。其实，面向对象的分析、设计方法并无强调结构化方法那样的阶段性，所以通常不引入概要、详细设计的概念。若是按照公司的文档体系，非要有这种分工的话，能够将包的划分、类及对象间的关系、类的对外属性、方法及协做设计看作 概要设计；类属性、方法的内部实现看作详细设计。

1.需求分析--产生软件功能规格说明书,须要肯定用户对软件的需求,要做到明确、无歧义。不涉及具体实现方法。用户能看得明白，开发人员也可据此进行下面的工做（概要设计）。 
2.概要设计--产生软件概要设计说明书，说明系统模块划分、选择的技术路线等，总体说明软件的实现思路。而且须要指出关键技术难点等。 
3.详细设计--产生软件详细设计说明书，对概要设计的进一步细化，通常由各部分的担当人员依据概要设计分别完成，而后在集成，是具体的实现细节。理论上要求能够照此编码。

概要设计和详细设计的区别与联系

软件设计采用自顶向下、逐次功能展开的设计方法，首先完成整体设计，而后完成各有机组成部分的设计。

根据工做性质和内容的不一样，软件设计分为概要设计和详细设计。概要设计实现软件的整体设计、模块划分、用户界面设计、数据库设计等等；详细设计则根据概要设计所作的模块划分，实现各模块的算法设计，实现用户界面设计、数据结构设计的细化，等等。

概要设计是详细设计的基础，必须在详细设计以前完成，概要设计经复查确认后才能够开始详细设计。概要设计，必须完成概要设计文档，包括系统的整体设计文档、以及各个模块的概要设计文档。每一个模块的设计文档都应该独立成册。

详细设计必须遵循概要设计来进行。详细设计方案的更改，不得影响到概要设计方案；若是须要更改概要设计，必须通过项目经理的赞成。详细设计，应该完成详细设计文档，主要是模块的详细设计方案说明。和概要设计同样，每一个模块的详细设计文档都应该独立成册。

概要设计里面的数据库设计应该重点在描述数据关系上，说明数据的前因后果，在这里应该结合咱们的一下结果数据，说明这些结果数据的源点，咱们这样设计的目的和缘由。详细设计里的数据库设计就应该是一份完善的数据结构文档，就是一个包括类型、命名、精度、字段说明、表说明等内容的数据字典。

概要设计里的功能应该是重点在功能描述，对需求的解释和整合，总体划分功能模块，并对各功能模块进行详细的图文描述，应该让读者大体了解系统做完后大致的结构和操做模式。详细设计则是重点在描述系统的实现方式，各模块详细说明实现功能所需的类及具体的方法函数，包括涉及到的sql语句等。

 

概要设计，详细设计之间的关系是什么？

Q:
个人见解：
概要设计只说明系统有多少个模块，各模块之间的接口和个模块自己的功能
详细设计说明某个具体模块如何实现，粒度应该比程序略高一些

可是问题来了，各个模块之间是有层次关系的，也有前后逻辑关系。这就说明，在概要设计中，还必须考虑模块的实现细节，不然，你怎么知道这个模块下面要划分子模块？你怎么知道各子模块的调用顺序？
这就说明，概要设计和详细设计是重叠进行的，而软件工程书上说的确是顺序进行的，不知道是否是个人理解有问题。

举个例子，例如排序程序，若是设计2个模块：
一个主模块用于排序子模块用于交换2个变量，主模块调用子模块，可是子模块是怎么设计出来的呢？确定是你先想到了用冒泡等排序方式的时候须要交换数据，这已经考虑了主模块足够多的细节，彷佛属于"详细设计"了，可是目前进行的是概要设计，这就产生了我所说的重叠的状况。

A:

看看上面的帖子，有意思的居多。

上面也有朋友说到用建筑的例子来比喻。

软件的概要设计，主要是创建软件系统的总体架构，也就是咱们在盖房子时候，须要先将房子的整个架子构建起来。

软件的详细设计，主要是将软件系统的各个部分的具体设计方法、逻辑、功能采用文字方式进行表述。这样在实现过程当中，Coding人员原则上严格按此进行代码实现便可。

这样的一个最为简单的例证：咱们能够将代码交付第三方来作。验证与跟踪采起设计来。

我看上面还有一个朋友说：快速作代码。这个自己没有值得批评之处。但只要想一下，你写的代码没有任何设计思想、文档留下的状况，一旦你离开，如何维护？从新设计吗？仍是花费几倍人力去研究你写的几千/万，甚至几十万行代码？若是是这样的，你没错，关键是大家老板太对了，钱算什么