接口管理平台概要设计（接口服务管理）

本篇文章给大家谈谈接口管理平台概要设计，以及接口服务管理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享接口管理平台概要设计的知识，其中也会对接口服务管理进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何做概要设计?
• 2、系统概要设计怎么写？
• 3、学生信息管理系统 概要设计怎么写
• 4、如何看待软件概要设计
• 5、系统概要设计模板

如何做概要设计?

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

系统概要设计怎么写？

软件文档中概要设计也称“总体设计”，是开发人员在明确用户需求（要什么）后对系统的一个总体考虑（明确系统目标、设计原则，初步考虑数据库设计和功能设计），国家关于这方面有相关标准（概要设计说明书（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提出的进行软件结构设计的工具，结构图和层次图类似，一个方框代表一个模块，框内注明模块的名字或主要功能。方框之间的直线（箭头）表示模块的调用关系。用带注释的箭头表示模块调用过程中来回传递的信息，尾部是空心的，表示传递的是数据，实心的表示传递的是控制。

学生信息管理系统 概要设计怎么写

一、弄清楚系统要实现什么功能，比如老师基本信息维护、学生基本信息维护、课程信息维护、学生考试成绩维护 等等 这就是传说中的需求分析
二、把这些功能划分车不同的模块 搞清楚各个模块之间的关系 搞清楚各个模块之间如何交互 这就是传说中的概要设计 定义各个模块的属性、接口等信息 这就是传说中的系统设计
三、设计数据结构 创建数据表
四、开始编写各个模块的代码
五、测试
六、写论文、答辩

如何看待软件概要设计

在需求明确、准备开始编码之前接口管理平台概要设计，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。
一、问题的提出
概要设计写什么？概要设计怎么做？
如何判断设计的模块是完整的？
为什么说设计阶段过于重视业务流程是个误区？
以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确？
结构化好还是面向对象好？
以上问题的答案请在文章中找。
二、概要设计的目的
将软件系统需求转换为未来系统的设计；
逐步开发强壮的系统构架；
使设计适合于实施环境，为提高性能而进行设计；
结构应该被分解为模块和库。
三、概要设计的任务
制定规范：代码体系、接口规约、命名规则。这是项目小组今后共同作战的基础，有接口管理平台概要设计了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。
总体结构设计：
功能（加工）－模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；
模块层次结构：某个角度的软件框架视图；
模块间的调用关系：模块间的接口的总体描述；
模块间的接口：传递的信息及其结构；
处理方式设计：满足功能和性能的算法
用户界面设计；
数据结构设计：
详细的数据结构：表、索引、文件；
算法相关逻辑数据结构及其操作；
上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）
接口控制表的数据结构和使用规则
其他性能设计。
四、概要设计写什么
结构化软件设计说明书结构（因篇幅有限和过时嫌疑，在此不作过多解释）
任务：目标、环境、需求、局限；
总体设计：处理流程、总体结构与模块、功能与模块的关系；
接口设计：总体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）
数据结构：逻辑结构、物理结构，与程序结构的关系；
模块设计：每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；
运行设计：运行模块组合、控制、时间；
出错设计：出错信息、处错处理；
其他设计：保密、维护；
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的重点)；
人机界面：窗口、菜单、按钮、命令等等；
数据管理：数据管理方法、逻辑物理结构、操作对象类；
任务管理：任务协调和管理进程；

系统概要设计模板

引用百度百科 概要设计

1 引言

1.1编写目的

说明编写这份概要设计说明书的目的接口管理平台概要设计，指出预期的读者。

1.2背景

说明：

a．待开发软件系统的名称；

b．列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站（中心）。

1．3定义

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

1.4参考资料

列出有关的参考文件，如：

a．本项目的经核准的计划任务书或合同，上级机关的批文；

b．属于本项目的其他已发表文件；

c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2 总体设计

2.1需求规定

说明对本系统的主要的输入输出项目、处理的功能性能要求，详细的说明可参见附录C。

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运行环境

简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定，详细说明参见附录C。

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

2.2.2支持软件

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

2.2.3接口

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

2.2.4控制

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

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

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

2.4结构

用一览表及框图的形式说明本系统的系统元素（各层模块、 子程序 、 公用程序 等）的划分，扼要说明每个系统元素的 标识符 和功能，分层次地给出各元素之间的控制与被控制关系.

2.5功能需求与程序的关系

本条用一张矩阵图说明各项功能需求的实现同各块程序的分配关系：E.2.7E.2.7..

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补救措施

说明故障出现后可能采取的变通措施，包括：

a.后备技术说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术；

b.降效技术说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工记录；

c.恢复及再启动技术说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。

6.3系统维护设计

说明为接口管理平台概要设计了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。 各个程序之间的对应关系，可采用如下的矩阵图的形式； 关于接口管理平台概要设计和接口服务管理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口管理平台概要设计的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口服务管理、接口管理平台概要设计的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。