系统接口设计（系统接口设计文档怎么写）

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

本文目录一览：

• 1、接口设计怎么写？
• 2、工科硕士论文的框架
• 3、电子酒店门锁管理系统软件接口要怎么设置呢？
• 4、在结构化分析方法中软件的功能由什么表示
• 5、求操作系统接口：Windows命令接口 设计（C++编的） 谢谢
• 6、系统概要设计模板

接口设计怎么写？

接口设计包括三个方面：一、用户接口用来说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。二、外部接口用来说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。三、内部接口用来说明本系统之内的各个系统元素之间的接口的安排

工科硕士论文的框架

工科硕士论文的框架

我们在写硕士论文之前，都需要制定一个框架，明确要写内容，如何安排结构与逻辑，才能确保论文写作工作有条不紊进行。但需要注意的是，框架只是普遍意义的写作思路和基本框架，各位同学在写作时，可以按照此框架整理自己的思路，具体拟订写作提纲时，应根据实际情况进行增减和调整，不一定完全按照此框架写。下面我们以工科硕士论文为例，详细分析硕士论文的框架怎么安排。

摘要

摘要只需要说明三个方面的内容：（1）首先是论文要解决什么问题（系统开发通常是为了解决现实应用中的某些问题，这个就是论文工作的动机，这个首先要定义清楚。可以简单说一下研究背景但不能多，一两句话即可）；（2）其次是论文对这一问题做出了哪些贡献（一般来说，工程硕士论文的贡献包括两个方面：一是完成了需求分析、概要设计、详细设计、编码与测试等工作，建立了实际的应用系统；二是针对系统开发中的某些技术问题提出了自己的解决方法并进行了验证。到时展开一下分几点说明即可）；（3）论文工作的意义（所开发的系统、所提出的技术解决方法有什么理论意义和实用价值。）

摘要只需要说明上面三个内容，除此之外的文字都不要写在摘要中。

第1章 绪 论

1.1 研究背景与研究意义

说明选题背景、意义（这个事做成了有哪些好处？）

1.2 国内外研究现状

只说与论文工作相关的，分类讨论

1.3 本论文的目标与主要内容

先说一下论文的总体目标，然后叙述一下主要工作内容，最后特别说明一下本人独立承担的工作内容

1.4 论文的组织结构

第2章相关技术概述

本章不是必须的，可省略

2.1 引言

说明一下本章准备讨论哪些相关技术？为什么讨论这些技术（而不讨论其他的）？

2.2 ××技术

每个相关技术要总结归纳，不必涉及太多的细节。细节问题可以通过参考文献方式给出引用即可。另外有些大家都知道的技术不必在这一章中讨论，比如什么是B/S结构等

2.3 ××技术

2.4 ××技术

2.5 本章小结

第3章系统需求分析

需求分析要自顶向下描述，重点是功能需求。如果需求很简单，可以合并到“系统总体设计”一章中，作为引言之后的第一节。

3.1 引言

3.2 系统建设目标

3.3 系统功能需求

功能需求要注意和后面设计之间的对应关系。比如是否所有功能都在后面设计中得到满足了？尤其是你自己独立承担的模块对应着系统的'哪几个功能需求，这个自己要心里有数。

3.4 系统性能需求

3.5 系统其它需求

3.6 本章小结

第4章系统总体设计

系统概要设计。总体设计重点要说明系统的软件体系结构（模块结构，这个结构是后面所有内容的依据，后面几章包括你自己承担的内容都要能对应到这个模块结构中来）、工作流程、接口设计、数据库设计……。概要设计通常只是你参与的工作，不是你论文的重点，但这部分内容必须要有，因为有了它大家才能准确了解你独立承担的模块在系统中位置和作用。

4.1 引言

介绍一下本章目的是什么，重点准备讨论哪些内容

4.2 系统模块结构设计

4.3 系统工作流程

工作流程是按功能需求来设计的，即某个功能需求需要利用哪些模块按什么样的流程才能满足，用图表示。自顶向下设计。

4.4 系统接口设计

包括模块内部接口和系统外部接口（用户接口）。模块内部可能是通过数据库来交互的，外部接口用可能是文件等等。

4.5 数据库设计

要有概念模型、逻辑结构和物理结构设计

4.6 本章小结

第5章系统详细设计

详细设计重点讨论你自己独立承担的模块，一般有2－3个模块

5.1 引言

介绍一下本章目的是什么，重点准备讨论哪些内容

5.2 系统详细设计概述

可以总体上说一下整个系统的详细设计过程、方法

5.3 ××模块详细设计

你独立承担的第一个模块

5.3.1输入输出

5.3.2程序流程

或算法伪码、序列图等等

5.3.3数据结构

涉及的数据结构

5.3.4约束条件

模块输入输出、处理过程等需要满足的约束条件，比如要求输入的文件必须是XML文件，要求FTP上传时服务器上必须有public目录等等

5.4 ××模块详细设计

你承担的第2个模块，内容同5.3

5.5 关键技术分析与解决

如果有多个关键技术突破，则分几个小节写。本部分非必须，若有则更好。

5.5.1 问题定义

5.5.2 已有方法及不足

5.5.3 本论文采用的方法

5.5.4 实现结果与效果

5.6 本章小结

第6章关键模块的实现与测试

讨论你独立承担模块的实现与测试结果。本章如果内容不多，可以和上一章“系统详细设计”合并，作为详细设计之后的一节或两节。

6.1 引言

6.2 系统实现技术概述

简要介绍一下整个系统的实现技术，比如采用了SSH框架？基于MVC架构？基于C/S和B/S混合架构？等等。让大家了解你系统的总体实现思路。

6.3 ××模块的实现

可以给出具体的类设计和类之间的关系，然后给出运行实例

6.4 ××模块的实现

另一个模块，与上同

6.5 实现中的难点问题与解决

本部分非必须

6.6 系统测试

给出测试方案、测试用例、测试结果与分析。此处最好能给出你自己模块的测试结果，不行也可以给出整个系统的测试结果。注意测试的结果主要是看是否与前面需求相符，因此在测试结果分析中注意对需求满足程度的讨论。

6.6 本章小结

第8章结束语

8.1 论文工作总结

8.2 未来工作展望

参考文献

;

电子酒店门锁管理系统软件接口要怎么设置呢？

引言：在当今社会越来越多的人，注重门锁的安全性能是否得高，因为如果需要确保自己资金的安全。像门锁管理也需要达到国家的标准，避免非法分子能够进入家中进行偷盗。那么对于酒店的前景也是非常好的，酒店的行业发展越来越趋近于现代化。所以这个时候就需要注重自己的装修是否能够达到安全性能高的，所以这样的情况下，才能够给自己的生活有一定的保障。不会留下安全隐患，危害以后的生活。那么电池酒店门锁管理系统软件接口要怎么设计呢？在这里，小编有以下几点建议，希望能够帮助大家解决问题。

需要分析材料

不同的材料，它的性能往往是大不相同的，选择好的材料能够有利于他的使用寿命，进一步加强。同时也能够保证它在配合安装时能够发挥它的作用，在管理系统能力上也能够更加的强，所以在电子酒店门锁管理系统软件的接口需要合理的设计。分析材料的性能，找寻正确的方法来进一步安装。总的来说，要想安装管家的接口需要分析材料的。

咨询技术人员

如果在电子酒店门锁管理系统软件接口想要设计一个良好的方案，这个时候就需要咨询相关的技术，能源来为进一步解答。如果给出合理化建议，帮助提高门锁管理系统的安全形容这样就有有利于酒店的持续发展。同时也能够吸引更多的人来住进酒店，这会给酒店带来巨大的经济收益。所以可以咨询相关的技术人员，进一步确立。

询问父母

父母也能够在这方面给予孩子一些常识，毕竟在社会上磨炼了许多年，所以有许多合理化建议，可以给孩子进行沟通和交流。如果在电子酒店门锁管理系统软件接口方面上有疑惑，可以咨询父母。

在结构化分析方法中软件的功能由什么表示

接口设计
分类
模块间的接口设计（内部接口）
软件与其他软硬件系统之间的接口设计（外部接口）
软件与用户之间的交互设计
系统的接口设计是由穿过系统边界的数据流定义的
在最终的系统中，数据流将成为用户界面中的表单、报表或与其它系统进行交互的文件或通信
人机交互界面
在设计阶段，必须根据需求把交互细节加入到用户界面设计中，包括人机交互所必须的实际显示和输入
用户界面应具备的特性
可使用性：是用户界面设计最重要的目标。包括使用简单、界面一致、充分提示、快速响应、低运行成本、健壮性等
灵活性：考虑到用户特点。应该使用户接口满足不同用户的要求。对不同的用户，应有不同的界面形式，但不同的界面不应该影响功能
可靠性：用户界面的可靠性是指无故障使用的间隔时间。用户界面应能保证用户正确、可靠地使用系统，保证程序和数据的安全性
界面设计类型
外行型
初学型：需要很多界面支持
熟练型：需要较少的界面支持，但不能处理意外错误
专家型：需要为他们提供能够修改和扩充系统能力的复杂界面
选用界面形式（表格，图形，菜单，对话，窗口等）的时候，应该考虑每种类型的优点和限制，可以从以下方面考察
使用的难易度
学习的难易度
操作速度
复杂程度
控制：人机交互时，由计算机还是由人发起和控制接口
开发的难易程度：该界面设计是否有难度，工作量多大
一个界面的设计通常使用一种以上的设计类型，每种类型与一个或一组任务相匹配
设计原则
一致性
操作步骤少
不要“哑播放”，指使用进度条，加载条等能够证明系统正在运行的标志。
提供Undo功能
减少用户记忆负担
提高学习效率
数据设计
在设计阶段必须对要存储的数据及其格式进行设计
文件设计
适合选择文件存储的情况：
数据量较大的非结构化数据（多媒体）
数据量大，信息松散（历史记录、档案）
非关系层次化数据（系统配置文件）
对数据的存取速度要求极高的情况
临时存放的数据
文件设计的主要工作就是根据使用要求、处理方式、存储的信息量、数据的活动性以及所提供的设备条件等确定文件类型，选择文件媒体，决定文件组织方法，设计文件记录格式，并估算文件的容量
数据库设计
在结构化设计中，很容易将结构化分析阶段建立的数据字典和 实体-关系 模型映射到关系数据库中
数据对象的映射
关系的映射

求操作系统接口：Windows命令接口 设计（C++编的） 谢谢

基于XML的配置文件访问接口设计和实现(1)
目录
摘要
配置文件结构
XmlConfigReader类的实现
XmlConfigReader类的使用
摘要
在进行程序开发过程中,经常要将一些程序设置/使用的信息储存起来.由于这些信息和程序的设置/使用相关,与程序有相当的独立性,所以不可能硬编码到程序中.在这个时候我们选择使用基于Xml的配置文件进行存储.Microsoft的.NET Framework提供了一系列的基于.Config文件的读取的类,如System.Configuration 命名空间提供的AppSettings等类.但是此命名空间提供的类只能对配置文件进行读取,不能进行设置.所以在这里,我们实现自己的一个基于Xml的配置文件的类XmlConfigReader/XmlConfigWriter.
配置文件的结构
为了达到与原有的,系统自带的(.Config)配置文件的兼容性,我们选择使用类似.Config 文件的结构.示例如下:
<?xml version="1.0" encoding="utf-8" ?
<configuration
<appSettings
<add key="TimeOut" value="5000"/
<add key="UserName" value="client7" /
<add key="FileServerPort" value="8050" /
<add key="SpliteCharsForCMD" value=":"/
<add key="SpliteCharsForItem" value=";"/
<add key="SpliteCharsForSubItem" value=","/
</appSettings
<SockBaseSettings
<addd key="ServerIP" value="localhost"/
</SockBaseSettings
</configuration
所有的要设置的信息都放在Configuration节点的子节点(如appSettings/SockBaseSettings)的子节点中,这种结构有助于将不同的设置的信息进行归类/统一.结构和系统的.Config结构基本类似.这样就可以很方便的将此自定义的结构转为.Config文件.
XmlConfigReader类的实现
现在文件的基本结构已完成了,现在就开始编码,完成XmlConfigReader.
由于配置文件是以文件的形式放在硬盘上面的,所以这个XmlConfigReader类在解析Xml文件前得得到文件的路径.
public class XmlConfigReader
{
private string _filepath;
public XmlConfigReader(string filepath){
_filepath = Path.GetFullPath(filepath).ToUpper();
}
}
好,现在可以得到文件路径了.然后就是对配置文件进行解析了.在这里,我们选用.NET Framework提供的System.Xml命名空间中的轻量级的XmlTextReader来对配置文件进行解析.对应的XmlConfigReader中的函数定义如下:
public string Process(string sectionName,string key){
bool inConfiguration = false;
bool inSection = false;
string values;
XmlTextReader reader = new XmlTextReader(_filepath);
while( reader.Read()){
if( reader.IsStartElement()){
if( reader.Prefix == String.Empty)
{
if( reader.LocalName == "configuration")
{
inConfiguration = true;
}
else if( inConfiguration == true){
if( reader.LocalName == sectionName){
inSection = true;
}
else if( inSection reader.LocalName == "add"){
if( reader.GetAttribute("key") == null || reader.GetAttribute("value") == null)
{
throw new Exception(sectionName + " key or value is null");
}
if( reader.GetAttribute("key") == key){
values = reader.GetAttribute("value");
break;
}
}
}
}
}
}
reader.Close();
return values;
}
通过XmlTextReader的Read()函数对Xml文件中的节点进行遍历.同时先判断是否属于configuration节点中,再判断是否属于相应的sectionName中.只有在这两部分同时成立的时候才判断是否是相应的Key.如果是,得到其Value,并返回.
XmlConfigReader类的使用
好了,现在通过XmlConfigReader可以对配置文件进行读取了,这里我们看看实际使用的代码:
public class TestXmlConfigReader{
public void GetValues(){
XmlConfigReader reader = new XmlConfigReader(@"AppConfig.xml");
String Temp;
// Get appSettings username value
Temp = reader.Process("appSettings",”UserName");
// Get SockBaseSettings ServerIP value
Temp = Reader.Process(“SockBaseSettings”,”ServerIP”);
}
}
总结
通过XmlConfigReader类,我们可以很方便的自定义我们自己的配置文件.
基于XML的配置文件访问接口设计和实现(2)
目录
摘要
XmlConfigWriter类的实现
XmlConfigWriter类的使用
摘要
在进行程序开发过程中,经常要将一些程序设置/使用的信息储存起来.由于这些信息和程序的设置/使用相关,与程序有相当的独立性,所以不可能硬编码到程序中.在这个时候我们选择使用基于Xml的配置文件进行存储.Microsoft的.NET Framework提供了一系列的基于.Config文件的读取的类,如System.Configuration 命名空间提供的AppSettings等类.但是此命名空间提供的类只能对配置文件进行读取,不能进行设置.所以在这里,我们实现自己的一个基于Xml的配置文件的类XmlConfigReader/XmlConfigWriter.
XmlConfigWriter类的实现
由于要对配置文件进行写入,而且可能写入的次数比较多.所以这里我们不使用轻便的XmlTextWriter,使用XmlDocument.XmlDocument可以在内存中修改所有的Xml的节点,只有等到显式的调用Save函数的时候才会保存Xml文件.在有大量修改的时候,性能要好一些.
同样的,先实现XmlConfigWriter的构造函数
public class XmlConfigWriter
{
private string _filepath;
private XmlDocument doc ;
public XmlConfigWriter(string filepath)
{
_filepath = Path.GetFullPath(filepath);
doc =new XmlDocument();
doc.Load(_filepath);
}
}
通过构造函数,将配置文件的路径传进去,同时调用XmlDocument的Load方法,将此文件加载到内存中.
这里我们使用的是XmlDocument类.它实现 W3C 文档对象模型 (DOM) 级别 1 核心 (Level 1 Core) 和核心 DOM 级别 2 (Core DOM Level 2)。DOM 是 XML 文档的内存中（缓存）树状表示形式系统接口设计，允许对该文档的导航和编辑.通过XmlDocument,我们就可以很方便的在内存中直接操作节点.
.对配置文件的写入,不外忽三种,一种就是新插入一个节点,一种就是对现有节点的修改,最后一个就是删除现有的节点.我们首先从插入开始入手.代码如下:
private XmlNode CreateXmlNode(string localname){
return doc.CreateNode(XmlNodeType.Element,localname,"");
}
private XmlAttribute CreateXmlAttribute(string localname){
return doc.CreateAttribute("",localname,"");
}
public void AddSection(string section){
XmlNode secNode = doc.SelectSingleNode("/configuration/"+section);
if(secNode != null){
return;
}
doc.DocumentElement.AppendChild(CreateNode(section));
}
public void AddKey(string section,string key,string value){
XmlNode secNode = doc.SelectSingleNode("/configuration/"+section);
if( doc.SelectSingleNode("/configuration/" + section + "/add[@key=\"" + key + "\"]") != null)
{
return;
}
XmlNode chi = CreateXmlNode("add");
XmlAttribute att = CreateXmlAttribute("key");
att.Value = key;
chi.Attributes.Append(att);
att = CreateXmlAttribute("value");
att.Value = value;
chi.Attributes.Append(att);
secNode.AppendChild(chi);
}
对于配置文件的插入,有两种情况,一个就是插入一个新的Section节点(即appSettings/SockBaseSettings这样的节点),一个就是在当前的Section节点下面插入一个新的add节点.在上面的代码中,对于插入节点的操作,都是首先通过doc的SelectSingleNode函数来判断是否已存在此同名节点,如果存在,则直接return,避免创建同名的节点.但是,由于在最终使用的add节点是分属于不同的Section节点的,所以只是判断在同一个Section节点下面的此节点不能同名.
如果不存在同名的节点,就通过secNode.AppentChild函数将此新建的(通过CreateXmlNode函数)节点加入到doc对象中.同时,对于add节点,通过CreateXmlAttribute函数及XmNode.Attributes.Appent函数将其key / value属性加入到此节点中.这样,插入操作就完成了.
接着我们来完成删除操作.删除操作直接通过XmlDocument的SelectSingleNode得到目标节点的父节点,再通过XmlNode.RemoveChild操作将其删除.代码如下:
public void DeleteSection(string section){
XmlNode secNode = doc.SelectSingleNode("/configuration/"+section);
doc.DocumentElement.RemoveChild(secNode);
}
public void DeleteKey(string section,string key){
XmlNode secNode = doc.SelectSingleNode("/configuration/" + section + "/add[@key=\"" + key + "\"]");
if(secNode != null)
{
secNode.ParentNode.RemoveChild(secNode);
}
}
现在开始修改操作.对于修改操作,思路是这样的,首先通过XmlDocument的SelectSingleNode搜索,看是否有满足条件的节点.如果没有,直接return,如果存在,则分两情况.对于add节点,只是直接修改其value属性.对于Section节点,则是通过遍历把其下所有的子节点(add节点)得到,再把此Section节点删除,再生成一个新的节点(这个新的节点的Name就为要设置的值),再把得到的所有子节点再赋给这个新的节点.代码如下:
public void ModifySection(string oldSection,string newSection){
XmlNode secNode = doc.SelectSingleNode("/configuration/"+oldSection);
XmlNodeList list = secNode.ChildNodes;
doc.DocumentElement.RemoveChild(secNode);
secNode = doc.CreateNode(XmlNodeType.Element,newSection,"");
foreach( XmlNode i in list){
secNode.AppendChild(i);
}
doc.DocumentElement.AppendChild(secNode);
}
public void ModifyKey(string section,string key,string value){
XmlNode secNode = doc.SelectSingleNode("/configuration/" + section + "/add[@key=\"" + key + "\"]");
if(secNode != null)
{
secNode.Attributes["value"].Value = value;
}
}
好了,插入,修改,删除操作到现在基本完成了,但是现在还只是在内存中进行操作,还不是对实际的文件进行操作.这个时候,我们就还得通过XmlDocument.Save函数把内存中修改好的Xml文件写入到文件中去.代码如下:
public void Save(){
doc.Save(_filepath);
}
public void Save(string filepath)
{
doc.Save(filepath);
}
XmlConfigWriter类的使用
使用方法很简单.先产生一个XmlConfigWriter对象,通过构造函数把配置文件传进去,再通过Add/Modify/Delete等函数进行操作.代码如下:
XmlConfigWriter Writer = new XmlConfigWriter(@”appconfig.xml”);
Writer.AddSection(“appSettings”);
Writer.AddKey(“appSettings”,”ServerIP”,”localhost”);
Writer.ModifyKey(“appSettings”,”ServerIP”,”127.0.0.1”);
Writer.ModifySection(“appSettings”,”SockBaseSettings”);
Writer.DeleteKey(“SockBaseSettings”,”ServerIP”);
Writer.DeleteSection(“SockBaseSettings”);
Writer.Save();
总结
通过编写XmlConfigWriter,我们学会使用XmlDocument的使用.
基于XML的配置文件访问接口设计和实现(3)
目录
摘要
增加缓存支持
增加配置文件监视
增加ConfigurationSettings类
摘要
前面的两篇中,我们实现了XmlConfigReader和XmlConfigWriter的基本功能.由于XmlConfigReader的实现方式是每请求一次,就去解析配置文件一次,性能很低下.同时,为了更方便使用,我们增加一个ConfigurationSettings类,用来调用XmlConfigReader和XmlConfigWriter,使之用起来和System.Configuration中的类使用方式一样.
增加缓存支持
由于XmlConfigReader的实现方式是请求一次,解析配置文件一次,而且配置文件的信息在程序运行的时会大量使用,这样子显然效率太低.因此,这里就要使用到缓存.
缓存,其实就相当于一个静态的变量,在整个程序运行时是唯一的,通过这样的一个变量,把信息存储到这个变量里面,在程序的其它地方就可以直接得到这个信息了.从而避免了频繁的解析配置文件.这里,我们选择使用Hashtable做为缓存变量.
在MSDN中,我们可以查到System.Configuration命名空间中的AppSettings类返回的是一个NameValueCollection(Key/Value键值对).为了方便使用,我们将配置文件解析后的信息也存成NameValueCollection这样的集合.
这样定义好了后,对于Hashtable中的Key设置为Section节点的名字(appSettings/SockBaseSettings),其Value值即为此节点的所有子节点的NameValueCollection类的对象.
修改代码.给XmlConfigReader增加一个静态Hashtable变量,并修改相关函数.把得到的信息直接以NameValueCollection的形式存入到此Hashtable中.
private static Hashtable confTypes = new Hashtable();
private string rootname;
public void Process(){
XmlTextReader reader = new XmlTextReader(_filepath);
while( reader.Read()){
if( reader.IsStartElement()){
#region Analyze the files
if( reader.Prefix == String.Empty)
{
if( reader.LocalName == "configuration")
{
inConfiguration = true;
}
else if( inConfiguration == true){
if(reader.LocalName == "add")
{
if( reader.GetAttribute("key") == null || reader.GetAttribute("value") == null)
{
throw new Exception(rootname + " key or value is null");
}
AddKey(tables,reader.GetAttribute("key"),reader.GetAttribute("value"));
}
else
{
rootname = reader.LocalName;
}
}
}
#endregion
}
else if ( reader.LocalName == "configuration"){
inConfiguration = false;
}
}
reader.Close();
}
private void AddKey(string key,string value){
NameValueCollection collection ;
if(confTypes.ContainsKey( rootname )){
collection = (NameValueCollection) confTypes [rootname];
}
else{
lock(confTypes.SyncRoot){
collection = new NameValueCollection();
confTypes.Add( rootname,collection);
}
}
collection.Add(key,value);
}
上面代码中,我们修改了Process函数.把原来的直接return结果的地方改成调用AddKey函数.通过一个类成员 rootname临时储存当前的SectionName,通过AddKey把得到的Key/Value加入到Hashtable中.
现在这样修改后,就不能直接通过Process得到我们想到得到的Key的Value了.所以我们再写一个函数,
public NameValueCollection GetCollection(string SectionName){
if( confTypes.ContainsKey(SectionName)){
return (NameValueCollection)confTypes[SectionName];
}
else{
throw new Exception(confName + " is not found in XmlConfiguration files");
}
}
这里,我们直接通过SectionName得到此节点所有的子节点的NameValueCollection集合.这样,我们就可以得到我们想要的值了.
增加配置文件监视
上面的代码实现了配置文件的缓存.大大提高了灵活性.但是存在一个问题,就是,如果配置文件修改了,这个缓存不会自动更新.
要解决这个问题,我们得使用FileSystemWatcher这个类,用来订阅文件修改消息,进而更新缓存.由于在第一次解析前就要把此配置文件加入到监视文件表中,所以我们修改XmlConfigReader,增加一个静态的FileSystemWatcher,用来保存监视文件的对象,增加一个静态的Bool值表明是否修改过.再修改构造函数,使配置文件在一开始就加入到监视列表中.代码如下:
Private static FileSystemWatcher watch = new FileSystemWatcher();
Private static bool isModify = true;
public XmlConfigReader(string filepath){
_filepath = Path.GetFullPath(filepath).ToUpper();
watch.IncludeSubdirectories = false;
watch.Path = Path.GetDirectoryName(filepath);
watch.NotifyFilter = NotifyFilters.Size | NotifyFilters.LastWrite;
watch.Filter = Path.GetFileName(filepath);
watch.Changed += new FileSystemEventHandler(Change_Even);
watch.EnableRaisingEvents = true;
}
由于是通过事件机制实现文件修改通知的,所以我们还要实现Chane_Even这个函数,通过这个函数修改isModify的值.
private void Change_Even(object sender, FileSystemEventArgs e){
isModify = true;
}
这样子,对于配置文件的监视的代码就完成了,现在就是修改我们的GetCollection代码的时候了.
修改后的代码如下:
public NameValueCollection GetCollection(string SectionName){
if( isModify ){
lock(confTypes.SyncRoot){
confTypes.Clear();
Process();
}
isModify = false;
}
if( confTypes.ContainsKey(SectionName)){
return (NameValueCollection)confTypes[SectionName];
}
else{
throw new Exception(confName + " is not found in XmlConfiguration files");
}
}
到现在,整个XmlConfigReader的代码已完成了,可以实现对文件的监视,从而动态修改缓存中的值.
增加ConfigurationSettings类
为了便于使用,我们增加了一个ConfigurationSettings的类,使用他的用法和System.Configuration命名空间中的类的用法一样.代码定义如下:
public class ConfigurationSettings : XmlConfigWriter
{
private static string _filepath = @"AppConfig.xml";
public static string DefaultFilePath
private static XmlConfigReader reader;
{
get{return _filepath;}
set{_filepath = Path.GetFullPath(value);}
}
public static NameValueCollection AppSettings
{
get{
if( reader == null){
reader = new XmlConfigReader(DefaultFilePath);
}
return reader.GetCollection("appSettings");
}
}
public static NameValueCollection GetConfig(string sectionName){
get{
if( reader == null){
reader = new XmlConfigReader(DefaultFilePath);
}
return reader.GetCollection(sectionName);
}
}

系统概要设计模板

引用百度百科 概要设计

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小时内删除侵权内容。