概要设计包括哪些内容

一、概要设计和详细设计的区别

1、概要设计实现软件的总体设计、模块划分、用户界面设计、数据库设计等等；详细设计则根据概要设计所做的模块划分，实现各模块的算法设计，实现用户界面设计、数据结构设计的细化，等等。

2、 概要设计阶段通常得到软件结构图 ， 详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等 。

3、概要设计阶段：把软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块间调用关系和接口。在这个阶段，各个模块可以分给不同的人去并行设计。

详细设计阶段：依据概要设计阶段的分解，设计每个模块内的算法、流程等。在详细设计阶段，设计者的工作对象是一个模块，根据概要设计赋予的局部任务和对外接口，设计并表达出模块的算法、流程、状态转换等内容。

4、概要设计里的功能应该是重点在功能描述，对需求的解释和整合，整体划分功能模块，并对各功能模块进行详细的图文描述。

详细设计则是重点在描述系统的实现方式，各模块详细说明实现功能所需的类及具体的方法函数，包括涉及到的sql语句等。

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

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

2、详细设计必须遵循概要设计来进行。必须遵循概要设计的层次关系的，先后逻辑关系。详细设计和概要设计一样，每个模块的详细设计文档都应该独立成册。

概要设计的目标是描述软件模块的外观以及处理逻辑。模块对外暴露的服务接口，以及需要引用的接口，接口标识，接口的访问协议，接口描述都属于模块的外观，其他的模块通过这些接口和模块打交道，自然需要在概要设计阶段对接口做细致的刻画，初此之外，对于关键的模块，外观还应该说明模块的非功能属性，比如并发处理能力，数据吞吐量以及接口调用的反馈时长等等。处理逻辑是指模块从输入到输出的转换过程，描述其转换算法。无论通过何种图例和表现形式，只要能够清晰地说明模块外观和处理逻辑描述，就是好的概要设计。 概要设计过程一般包括四块内容，这四块内容都是围绕着外观和处理逻辑这两个目标进行。第一部分是模块划分，把架构设计中划分的业务模块按照开发模式迭代细化，拆分成符合高内聚低耦合的功能模块。第二部分是接口描述，重点要放在刻画模块内外部交互的接口形式。第三个部分是模块的逻辑描述，最后一个部分逻辑模型设计，包括数据库的逻辑模型设计以及值对象的概要说明。 模块划分 模块划分的粒度很难确定，不同的设计师会用不同的划分策略，相同的一组功能聚集有人会分为2个功能模块，有的人可能划分为4个或者更多。模块的粒度越大，对模块的维护成本就越大，因为修改模块的任何一个点，都有可能更新整个模块；而且越难以解决模块复杂耦合的问题，随着产品的维护，模块内的耦合会越来越严重，有些是因为新的需求引起模块内联系的增加，而有些是缺少硬约束下采用最直接的方式修改代码造成的。当然也不是模块划分的越小越好，因为小粒度的模块虽然降低了模块自身的维护成本，但过多的模块会增加模块间关系维护的成本以及系统管理的复杂性。 通常来看，模块划分要符合开闭原则和高内聚和低耦合的原则。开闭原则强调的是维护频度不同的功能不要放在同一个模块内，比如有些需要本地化的功能可以通过接口和实现分离的方式划分为业务模块和二次接口实现模块。高内聚和低耦合的原则强调的是把内部关联紧密和外部交互比较单一的功能划分成一个模块。 同时鉴于模块划分的重要性，建议尽可能把模块划分的工作前移到架构设计阶段，一方面架构设计团队的整体素质比较高，另外一方面架构设计师更能够站在全局的视角合理地划分模块。 接口描述 接口描述应该清晰地说明接口的类型，访问方式，接口的入参和出参。通常在概要设计阶段不考虑物理实现，不需要描述的非常详细，之所以如此关照接口，原因在于通过清晰的接口描述为流程逻辑和后面的详细设计建立一个硬约束。模块内的数据流和控制流的入口和出口都能限定在这个约束之内，方便评审的时候能及时发现设计中存在的问题。 逻辑描述 逻辑描述的目标是说清楚从输入到输出的转换过程。根据不同的模块的特点，可以选用不同的描述形式，对于以数据流为主的模块，可以使用数据流图，控制比较复杂的可以使用数据流图或者IPO图，而对于规范使用UML的项目可以考虑使用活动图。 可能有人会很疑惑在设计中没有谈到是用面向对象方法还是结构化的方法，这可是关键的方法论问题。确实，软件研发的坛子里面除了哪种语言更好的话题以外，最容易挑起纷争的就是结构化分析与设计和面向对象分析与设计之争了。我在这里不做结论，只做一个评说。结构化分析设计出现的比较早，那时候软件的主要使用场景更多是科学计算或者自动化控制，典型的特点是用户交互界面简单，更多是批处理的作业方式，更多关注程序的处理过程是否正确高效。随着PC机时代的到来，人机交互界面在软件中占有越来越重要的地位，原来的一套软件只有一个操作员，而现在可能有很多的使用者，为了清楚地描述不同人群对软件的诉求，业务用例应运而生，这就是面向对象的起点。不同的基因决定了他们各擅道场，一个擅长于后台计算的产品设计，另一个长于面向客户服务的产品设计。 在设计中，我们可以根据需求把两者的特点灵活地结合在一起，比如算法密集的处理模块，我们可以采用数据流图，而对于和外部交互比较复杂的模块，可以引入用例图标识模块支持的使用场景。 逻辑模型的设计 逻辑模块的设计主要是数据库的设计和值对象的设计。对于数据库的逻辑模型，可以统一设计，模块中添加引用。也可以在模块中针对所引用的库表独立描述。这两种方式都可以，如果库表结构比较复杂的建议统一建模，而比较简单的模型可以采用分开描述，提升模块设计的可读性。数据库建模现在已经比较成熟，这里不再多说。 模块的输入输出，以及中间的数据对象，我们统称为值对象，在概要设计阶段的重点是描述值对象的关键属性。需要注意的一点是值对象要和处理逻辑对应起来，特别是处理逻辑中的数据流，出口入口数据，都要在值对象上加以描述。

一、概论1、编写目的2、编写背景3、对系统的大致描述二、业务概述和逻辑设计1、对系统几大主体的描述2、对系统几大业务流程描述3、用UML对其进行总体描述三、技术架构在此章决定使用那种技术体系，具体的技术有那些，描述他们之间是怎么协同运作的。四、功能模块设计描述系统有那些主要功能，这些功能应该用何种技术，大致是如何实现的五、接口设计六、应急系统设计七、安全设计描述系统应该具有的安全级别，以及达到此安全等级的所采用的技术措施八、运行环境设计从硬件网络方面描述概要设计的目的就是希望一个从来没有接触过的人一看就能从各个方面都对系统的作用，功能，实现方面有一个大概了解，并为以后的各类详细设计文档提供一个指引和方向。

概要设计与详细设计的区别如下：

1、概要设计的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型.

2、详细设计是软件工程中软件开发的一个步骤，就是对概要设计的一个细化，就是详细设计每个模块实现算法，所需的局部结构。在详细设计阶段，主要是通过需求分析的结果，设计出满足用户需求的嵌入式系统产品。

3、概要设计阶段通常得到软件结构图 ， 详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等 。

4、详细设计阶段就是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。

扩展资料

设计是把一种设想通过合理的规划、周密的计划、通过各种感觉形式传达出来的过程。人类通过劳动改造世界，创造文明，创造物质财富和精神财富，而最基础、最主要的创造活动是造物。设计便是造物活动进行预先的计划，可以把任何造物活动的计划技术和计划过程理解为设计。

设计（Design）是为构建有意义的秩序而付出的有意识的直觉上的努力。更详细的定义如下：

第一步：理解用户的期望、需要、动机，并理解业务、技术和行业上的需求和限制。

第二步：将这些所知道的东西转化为对产品的规划（或者产品本身），使得产品的形式、内容和行为变得有用、能用，令人向往，并且在经济和技术上可行。（这是设计的意义和基本要求所在）

参考资料：百度百科-设计

软件系统的开发是按阶段进行的，一般划分为以下阶段：可行性讨论；需求分析；系统设计(概要设计、详细设计)；程序开发；编码，单元测试；系统测试；系统维护。 软件开发过程中要明确各阶段的工作目标、实现该目标所必需的工作内容以及达到的标准。只有在上一个阶段的工作完成后，才能开始下一阶段的工作。 1.可行性讨论 明确系统的目的、功能和要求，了解目前所具备的开发环境和条件，论证的内容有：① 在技术能力上是否可以支持；② 在经济上效益如何；③ 在法律上是否符合要求；④ 与部门、企业的经营和发展是否吻合；⑤ 系统投入运行后的维护有无保障。 可行性讨论的目的是判定软件系统的开发有无价值。分析和讨论的内容形成“系统开发计划书”，主要内容有： (1) 开发的目的及所期待的效果； (2) 系统的基本设想，涉及的业务对象和范围； (3) 开发进度表，开发组织结构； (4) 开发、运行的费用； (5) 预期的系统效益； (6) 开发过程中可能遇到的问题及注意事项。 2、系统需求分析 系统需求分析是软件系统开发中最重要的一个阶段，直接决定着系统的开发质量和成败，必须明确用户的要求和应用现场环境的特点，了解系统应具有哪些功能、数据的流程和数据之间的联系。需求分析应有用户参加，到使用现场进行调研学习，软件设计人员应虚心向技术人员和使用人员请教，共同讨论解决需求问题的方法，对调查结果进行分析，明确问题的所在。需求分析的内容编写成“系统需求分析报告”。 3.系统设计 可根据系统的规模分成概要设计和详细设计两个阶段。 概要设计包括：① 划分系统模块；② 每个模块的功能确定；③ 用户使用界面概要设计；④ 输入输出数据的概要设计；⑤ 报表概要设计；⑥ 数据之间的联系、流程分析；⑦ 文件和数据库表的逻辑设计；⑧ 硬件、软件开发平台的确定；⑨ 有规律数据的规范化及数据惟一性要求。 系统的详细设计是对系统的概要设计进一步具体化，其主要工作有：① 文件和数据库的物理设计；② 输入输出记录的方案设计；③ 对各子系统的处理方式和处理内容进行细化设计；④ 编制程序设计任务书。程序说明书通常包括程序规范、功能说明、程序结构图，通常用HPIPO（Hierarchy Plus Input Process Output）图描述。 4、程序开发 根据程序设计任务书的要求，用计算机算法语言实现解题的步骤，主要工作包括：① 模块的理解和进一步划分；② 以模块为单位的逻辑设计，也就是模块内的流程图的编制；③ 编写代码，用程序设计语言编制程序；④ 进行模块内功能的测试、单元测试。 程序质量的要求包括：① 满足要求的确切功能；② 处理效率高；③ 操作方便，用户界面友好；④ 程序代码的可读性好，函数、变量标识符合规范；⑤ 扩充性、维护性好。 降低程序的复杂性也是十分重要的。系统的复杂性由模块间的接口数来衡量，一般地讲，n个模块的接口数的最大值为n(n-1)/2；若是层次结构，n个模块的接口数的最小值为n-1。为使复杂性最小，对模块的划分设计常常采用层次结构。要注意编制的程序或模块应容易理解、容易修改，模块应相互独立，对某一模块的修改应对其他模块的功能不产生影响，模块间的联系尽可能少。 5.系统测试 测试是为了发现程序中的错误，对于设计的软件，出现错误是难免的。系统测试通常由经验丰富的设计人员设计测试方案和测试样品，并写出测试过程的详细报告。系统测试是在单元测试的基础上进行的，包括：① 测试方案的设计；② 进行测试；③ 写出测试报告；④ 用户对测试结果进行评价。 6、文档资料 文档包括开发过程中的所有技术资料以及用户所需的文档，软件系统的文档一般可分为系统文档和用户文档两类。用户文档主要描述系统功能和使用方法，并不考虑这些功能是怎样实现的；系统文档描述系统设计、实现和测试等方面的内容。文档是影响软件可维护性、可用性的决定因素，有句话讲，系统编程人员的每一张纸片都要保留，所以文档的编制是软件开发过程中的一项重要工作。 系统文档包括：开发软件系统在计划、需求分析、设计、编制、调试、运行等阶段的有关文档。在对软件系统进行修改时，系统文档应同步更新，并注明修改者和修改日期，如有必要应注明修改原因，应切记过时的文档是无用的文档。 用户文档包括：① 系统功能描述；② 安装文档，说明系统安装步骤以及系统的硬件配置方法；③

软件文档中概要设计也称“总体设计”，是开发人员在明确用户需求（要什么）后对系统的一个总体考虑（明确系统目标、设计原则，初步考虑数据库设计和功能设计），国家关于这方面有相关标准（概要设计说明书（GB8567-88））。

在具体实践中可以按下列提纲撰写内容：

1．引言

1.1编写目的

[说明编写这份概要设计说明书的目的，指出预期的读者。]

1.2背景

a.[待开发软件系统的名称；]

b.[列出本项目的任务提出者、开发者、用户。]

1.3定义

[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]

1.4参考资料

[列出有关的参考资料。]

2．总体设计

2.1需求规定

[说明对本系统的主要的输入输出项目、处理的功能性能要求。包括]

2.1.1系统功能

2.1.2系统性能

2.1.2.1精度

2.1.2.2时间特性要求

2.1.2.3可靠性

2.1.2.4灵活性

2.1.3输入输出要求

2.1.4数据管理能力要求

2.1.5故障处理要求

2.1.6其他专门要求

2.2运行环境

[简要地说明对本系统的运行环境的规定。]

2.2.1设备

[列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能。]

2.2.2支持软件

[列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。]

2.2.3接口

[说明该系统同其他系统之间的接口、数据通信协议等]

2.2.4控制

[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。]

2.3基本设计概念和处理流程

[说明本系统的基本设计概念和处理流程，尽量使用图表的形式。]

2.4结构

[给出系统结构总体框图（包括软件、硬件结构框图），说明本系统的各模块的划分，扼要说明每个系统模块的标识符和功能，分层次地给出各模块之间的控制与被控制关系。]

2.5功能需求与系统模块的关系

[本条用一张矩阵图说明各项功能需求的实现同各模块的分配关系。]

2.6人工处理过程

[说明在本系统的工作过程中不得不包含的人工处理过程。]

2.7尚未解决的问题

[说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。]

3．接口设计

3.1用户接口

[说明将向用户提供的命令和它们的语法结构，以及相应的回答信息。]

[说明提供给用户操作的硬件控制面板的定义。]

3.2外部接口

[说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持系统之间的接口关系。]

3.3内部接口

[说明本系统之内的各个系统元素之间的接口的安排。]

4．运行设计

4.1运行模块组合

[说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块的支持软件。]

4.2运行控制

[说明每一种外界的运行控制的方式方法和操作步骤。]

4.3运行时间

[说明每种运行模块组合将占用各种资源的时间。]

5．系统数据结构设计

[不涉及软件设计可不包含]

5.1逻辑结构设计要点

[给出本系统内软件所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。]

5.2物理结构设计要点

[给出本系统内软件所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系、设计考虑和保密条件。]

5.3数据结构与程序的关系

[说明各个数据结构与访问这些数据结构的各个程序之间的对应关系。]

6．系统出错处理设计

6.1出错信息

[用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。]

6.2补救措施

[说明故障出现后可能采取的变通措施。]

6.3系统维护设计

[说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。]

概要设计是一个设计师根据用户交互过程和用户需求来形成交互框架和视觉框架的过程，其结果往往以反映交互控件布置、界面元素分组以及界面整体板式的页面框架图的形式来呈现。这是一个在用户研究和设计之间架起桥梁，使用户研究和设计无缝结合，将对用户目标与需求转换成具体界面设计解决方案的重要阶段。 [1]

概要设计的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型，与计算机无关。

（1）层次图。层次图用来描绘软件的层次结构。一个矩形框代表一个模块，方框间的连线表示调用关系。如图，最顶层的方框代表正文加工系统的主控模块，它调用下层模块，完成正文加工的全部功能。第二层的每个模块完成正文加工的一个主要功能。

（2）HIPO图。HIPO图是IBM公司发明的“层次图加输入/处理/输出图”。层次图加上编号称为H图。在层次图的基础上，除最顶层的方框之外，其余每个方框都加了编号。层次图中每一个方框都有一个对应的IPO图（表示模块的处理过程）。每张IPO图应增加的编号与其表示的（对应的）层次图编号一致。IPO图是输入/加工/输出图的简称。

（3）结构图。结构图是Yordon提出的进行软件结构设计的工具，结构图和层次图类似，一个方框代表一个模块，框内注明模块的名字或主要功能。方框之间的直线（箭头）表示模块的调用关系。用带注释的箭头表示模块调用过程中来回传递的信息，尾部是空心的，表示传递的是数据，实心的表示传递的是控制。

我们如何判别一些项目内容如下：

1.切勿别人对项目的夸赞。

2.较真的去查询项目的一些点。

3.查询是否是新的，过没过时。

在项目管理的流程中，每个阶段都有自己的起止范围，有本阶段的输入文件和本阶段要产生的输出文件。同时，每个阶段都有本阶段的控制关口，即本阶段完成时将产生的重要文件也是进入下一阶段的重要输入文件。每个阶段完成时一定要通过本阶段的控制关口，才能进入下一阶段的工作。

1、需求分析

相关项目分析员向用户初步了解需求，然后用相关的工具软件列出要开发的项目的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。

2、概要设计

开发者需要对软件项目进行概要设计，即项目设计。概要设计需要对软件项目的设计进行考虑，包括项目的基本处理流程、项目的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

3、详细设计

在概要设计的基础上，开发者需要进行软件项目的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件项目各个层次中的每一个程序（每个模块或子程序）的设计考虑，以便进行编码和测试。

4、编码

在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度。

5、测试

测试编写好的项目。交给用户使用，用户使用后一个一个的确认每个功能。软件测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试。

在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。

一、问题的提出

概要设计写什么？概要设计怎么做？

如何判断设计的模块是完整的？

为什么说设计阶段过于重视业务流程是个误区？

以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确？

结构化好还是面向对象好？

以上问题的答案请在文章中找。

二、概要设计的目的

将软件系统需求转换为未来系统的设计；

逐步开发强壮的系统构架；

使设计适合于实施环境，为提高性能而进行设计；

结构应该被分解为模块和库。

三、概要设计的任务

制定规范：代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。

总体结构设计：

功能（加工）－>模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；

模块层次结构：某个角度的软件框架视图；

模块间的调用关系：模块间的接口的总体描述；

模块间的接口：传递的信息及其结构；

处理方式设计：满足功能和性能的算法

用户界面设计；

数据结构设计：

详细的数据结构：表、索引、文件；

算法相关逻辑数据结构及其操作；

上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）

接口控制表的数据结构和使用规则

其他性能设计。

四、概要设计写什么

结构化软件设计说明书结构（因篇幅有限和过时嫌疑，在此不作过多解释）

任务：目标、环境、需求、局限；

总体设计：处理流程、总体结构与模块、功能与模块的关系；

接口设计：总体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）

数据结构：逻辑结构、物理结构，与程序结构的关系；

模块设计：每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；

运行设计：运行模块组合、控制、时间；

出错设计：出错信息、处错处理；

其他设计：保密、维护；

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 非功能性需求

五、概要设计怎么做

结构化软件设计方法：

详细阅读需求规格说明书，理解系统建设目标、业务现状、现有系统、客户需求的各功能说明；

分析数据流图，弄清数据流加工的过程；

根据数据流图决定数据处理问题的类型（变换型、事务型、其他型）；

通过以上分析，推导出系统的初始结构图；

对初始结构图进行改进完善：所有的加工都要能对应到相应模块（模块的完整性在于他们完成了需求中的所有加工），消除完全相似或局部相似的重复功能（智者察同），理清模块间的层次、控制关系，减少高扇出结构，随着深度增大扇入，平衡模块大小。

由对数据字典的修改补充完善，导出逻辑数据结构，导出每种数据结构上的操作，这些操作应当属于某个模块。

确定系统包含哪些应用服务系统、客户端、数据库管理系统；

确定每个模块放在哪个应用服务器或客户端的哪个目录、哪个文件（库），或是在数据库内部建立的对象。

对每个筛选后的模块进行列表说明。

对逻辑数据结构进行列表说明。

根据结构化软件设计说明书结构对其他需要说明的问题进行补充说明，形成概要设计说明书。

OO软件设计方法：

在OOA基础上设计对象与类：在问题领域分析（业务建模和需求分析）之后，开始建立系统构架。

第一步是抽取建立领域的概念模型，在UML中表现为建立对象类图、活动图和交互图。对象类就是从对象中经过“察同”找出某组对象之间的共同特征而形成类：

对象与类的属性：数据结构；

对象与类的服务操作：操作的实现算法；

对象与类的各外部联系的实现结构；

设计策略：充分利用现有的类；

方法：继承、复用、演化；

活动图用于定义工作流，主要说明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等问题，交互图把人员和业务联系在一起是为了理解交互过程，发现业务工作流中相互交互的各种角色。

第二步是构建完善系统结构：对系统进行分解，将大系统分解为若干子系统，子系统分解为若干软件组件，并说明子系统之间的静态和动态接口，每个子系统可以由用例模型、分析模型、设计模型、测试模型表示。软件系统结构的两种方式：层次、块状

层次结构：系统、子系统、模块、组件（同一层之间具有独立性）；

块状结构：相互之间弱耦合

系统的组成部分：

问题论域：业务相关类和对象(OOA的重点)；

人机界面：窗口、菜单、按钮、命令等等；

数据管理：数据管理方法、逻辑物理结构、操作对象类；

任务管理：任务协调和管理进程；