系统架构设计考虑（共8篇）
系统架构设计考虑 篇1
一、与构架有关的几个基本概念
1、模块
模块(Module)是一组完成指定功能的语句,包括:输入、输出、逻辑处理功能、内部信息、运行环境(与功能对应但不是一对一关系)。
2、组件
组件(Component)是系统中相当重要的、几乎是独立的可替换部分,它在明确定义的构架环境中实现确切的功能。
3、模式
模式(Pattern):指经过验证,至少适用于一种实用环境(更多时候是好几种环境)的解决方案模板(用于结构和行为。在UML中:模式由参数化的协作来表示,但UML不直接对模式的其他方面(如使用结果列表、使用示例等,它们可由文本来表示)进行建模。存在各种范围和抽象程度的模式,例如,构架模式、分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如,对于系统结构设计,我们使用层模式;对于分布式系统,我们使用代理模式(通过使用代理来替代实际的对象,使程序能够控制对该对象的访问);对于交互系统,我们使用MVC(M模型(对象)/V视图(输出管理)/C控制器(输入处理))模式。模式是针对特定问题的解,因此,我们也可以针对需求的特点采用相应的模式来设计构架。
4、构架模式
构架模式(Architectural pattern):表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责,并且包括用于组织其间关系的规则和指导。
5、层
层(Layer):对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层,从逻辑上将子系统划分成许多集合,而层间关系的形成要遵循一定的规则。通过分层,可以限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。(层是对构架的横向划分,分区是对构架的纵向划分)。
6、系统分层方法
(1)常用三层服务:用户层、业务逻辑层、数据层;
(2)多层结构的技术组成模型:表现层、中间层、数据层;
(3)网络系统常用三层结构:核心层、汇聚层和接入层;
(4)RUP典型分层方法:应用层、专业业务层、中间件层、系统软件层;
(5)基于Java的B/S模式系统结构:浏览器端、服务器端、请求接收层、请求处理层;
(6)某六层结构:功能层(用户界面)、模块层、组装层(软件总线)、服务层(数据处理)、数据层、核心层。
7、构架
构架(Architecture),愿意为建筑学设计和建筑物建造的艺术与科学):在RUP中的定义:软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互;《软件构架实践》中的定义:某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构,他们组成软件的各个部分,形成这些组件的外部可见属性及相互间的联系;IEEE 1471-2000中的定为:the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution,构架是系统在其所处环境中的最高层次的概念。软件系统的构架是通过接口交互的重要构件(在特定时间点)的组织或结构,这些构件又由一些更小的构件和接口组成。(“构架”可以作为名词,也可作为动词,作为动词的“构架”相当于“构架设计”)。
8、构架的描述方式
“4+1”视图(用例视图、设计视图、实现视图、过程视图、配置视图)是一个被广为使用的构架描述的模型;RUP过程的构架描述模板在“4+1”视图的基础上增加了可选的数据视图(从永久性数据存储方面来对系统进行说明);HP公司的软件描述模板也是基于“4+1”视图。
9、结构
软件构架是多种结构的体现,结构是系统构架从不同角度观察所产生的视图。就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样,软件构架也表现为多种结构。常见的软件结构有:模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。
二、构架设计应考虑的因素概览
模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。
1、程序的运行时结构方面的考虑
(1)需求的符合性:正确性、完整性;功能性需求、非功能性需求;
(2)总体性能(内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响);
(3)运行可管理性:便于控制系统运行、监视系统状态、错误处理;模块间通信的简单性;与可维护性不同;
(4)与其他系统接口兼容性;
(5)与网络、硬件接口兼容性及性能;
(6)系统安全性;
(7)系统可靠性;
(8)业务流程的可调整性;
(9)业务信息的可调整性;
(10)使用方便性;
(11)构架样式的一致性。
注:运行时负载均衡可以从系统性能、系统可靠性方面考虑。
2、源代码的组织结构方面的考虑
(1)开发可管理性:便于人员分工(模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响)、利于配置管理、大小的合理性与适度复杂性;
(2)可维护性:与运行可管理性不同;
(3)可扩充性:系统方案的升级、扩容、扩充性能;
(4)可移植性:不同客户端、应用服务器、数据库管理系统;
(5)需求的符合性(源代码的组织结构方面的考虑)。
三、程序的运行时结构方面的考虑
1、需求的符合性
正确性、完整性;功能性需求、非功能性需求软件项目最主要的目标是满足客户需求。在进行构架设计的时候,大家考虑更多的是使用哪个运行平台、编成语言、开发环境、数据库管理系统等问题,对于和客户需求相关的问题考虑不足、不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求或非功能性需求,就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否则,架构设计应以满足客户所有明确需求为最基本目标,尽量满足其隐含的需求。(客户的非功能性需求可能包括接口、系统安全性、可靠性、移植性、扩展性等等,在其他小节中细述)。
一般来说,功能需求决定业务构架、非功能需求决定技术构架,变化案例决定构架的范围。需求方面的知识告诉我们,功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务构架,以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术构架要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计,结合功能需求和非功能需求,我们就可以确定一个需求的范围,进而确定一个构架的范围。
这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和可靠性问题的小小的例子:此系统的需求本身是比较简单的,就是将某城市的某业务的全部历史档案卡片扫描存储起来,以便可以按照姓名进行查询。需求阶段客户说卡片大约有20万张,需求调研者出于对客户的信任没有对数据的总量进行查证。由于是中小型数据量,并且今后数据不会增加,经过计算20万张卡片总体容量之后,决定使用一种可以单机使用也可以联网的中小型数据库管理系统。等到系统完成开始录入数据时,才发现数据至少有60万,这样使用那种中小型数据库管理系统不但会造成系统性能的问题,而且其可靠性是非常脆弱的,不得不对系统进行重新设计。从这个小小的教训可以看出,需求阶段不仅对客户的功能需求要调查清楚,对于一些隐含非功能需求的一些数据也应当调查清楚,并作为构架设计的依据。
对于功能需求的正确性,在构架设计文档中可能不好验证(需要人工、费力)。对于功能需求完整性,就应当使用需求功能与对应模块对照表来跟踪追溯。对于非功能需求正确性和完整性,可以使用需求非功能与对应设计策略对照表来跟踪追溯评估。
“软件设计工作只有基于用户需求,立足于可行的技术才有可能成功。”
2、总体性能
性能其实也是客户需求的一部分,当然可能是明确的,也有很多是隐含的,这里把它单独列出来在说明一次。性能是设计方案的重要标准,性能应考虑的不是单台客户端的性能,而是应该考虑系统总的综合性能;
性能设计应从以下几个方面考虑:内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响;
几点提示:算法优化及负载均衡是性能优化的方向。经常要调用的模块要特别注意优化。占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题文件过大时应当分解为若干部分,让用户先把主要部分显示出来。
3、运行可管理性
系统的构架设计应当为了使系统可以预测系统故障,防患于未然。现在的系统正逐步向复杂化、大型化发展,单靠一个人或几个人来管理已显得力不从心,况且对于某些突发事件的响应,人的反应明显不够。因此通过合理的系统构架规划系统运行资源,便于控制系统运行、监视系统状态、进行有效的错误处理;为了实现上述目标,模块间通信应当尽可能简单,同时建立合理详尽的系统运行日志,系统通过自动审计运行日志,了解系统运行状态、进行有效的错误处理;(运行可管理性与可维护性不同)。
4、系统安全性
随着计算机应用的不断深入和扩大,涉及的部门和信息也越来越多,其中有大量保密信息在网络上传输,所以对系统安全性的考虑已经成为系统设计的关键,需要从各个方面和角度加以考虑,来保证数据资料的绝对安全。
5、系统可靠性
系统的可靠性是现代信息系统应具有的重要特征,由于人们日常的工作对系统依赖程度越来越多,因此系统的必须可靠。系统构架设计可考虑系统的冗余度,尽可能地避免单点故障。系统可靠性是系统在给定的时间间隔及给定的环境条件下,按设计要求,成功地运行程序的概率。成功地运行不仅要保证系统能正确地运行,满足功能需求,还要求当系统出现意外故障时能够尽快恢复正常运行,数据不受破坏。
6、业务流程的可调整性
应当考虑客户业务流程可能出现的变化,所以在系统构架设计时要尽量排除业务流程的制约,即把流程中的各项业务结点工作作为独立的对象,设计成独立的模块或组件,充分考虑他们与其他各种业务对象模块或组件的接口,在流程之间通过业务对象模块的相互调用实现各种业务,这样,在业务流程发生有限的变化时(每个业务模块本身的业务逻辑没有变的情况下),就能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里,则连程序代码都不用修改,只需修改数据字典里的模块或组件调用规则即可。
7、业务信息的可调整性
应当考虑客户业务信息可能出现的变化,所以在系统构架设计时必须尽可能减少因为业务信息的调整对于代码模块的影响范围。
8、使用方便性
使用方便性是不须提及的必然的需求,而使用方便性与系统构架是密切相关的。Win CE(1.0)的失败和后来改进版本的成功就说明了这个问题。Win CE(1.0)有太多层次的视窗和菜单,而用户则更喜欢简单的界面和快捷的操作。失败了应当及时纠正,但最好不要等到失败了再来纠正,这样会浪费巨大的财力物力,所以在系统构架阶段最好能将需要考虑的因素都考虑到。当然使用方便性必须与系统安全性协调平衡统一,使用方便性也必须与业务流程的可调整性和业务信息的可调整性协调平衡统一。“满足用户的需求,便于用户使用,同时又使得操作流程尽可能简单。这就是设计之本。”
9、构架样式的一致性
软件系统的构架样式有些类似于建筑样式(如中国式、哥特式、希腊复古式)。软件构架样式可分为数据流构架样式、调用返回构架样式、独立组件构架样式、以数据为中心的构架样式和虚拟机构架样式,每一种样式还可以分为若干子样式。构架样式的一致性并不是要求一个软件系统只能采用一种样式,就像建筑样式可以是中西结合的,软件系统也可以有异质构架样式(分为局部异质、层次异质、并行异质),即多种样式的综合,但这样的综合应该考虑其某些方面的一致性和协调性。每一种样式都有其使用的时机,应当根据系统最强调的质量属性来选择。
四、源代码的组织结构方面的考虑
1、开发可管理性
便于人员分工(模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响:一个好的构架同时应有助于减少项目组的压力和紧张,提高软件开发效率)、利于配置管理、大小的合理性、适度复杂性;
(1)便于人员分工-模块独立性、层次性
模块独立性、层次性是为了保证项目开发成员工作之间的相对独立性,模块联结方式应该是纵向而不是横向,模块之间应该是树状结构而不是网状结构或交叉结构,这样就可以把开发人员之间的通信、模块开发制约关系减到最少。同时模块独立性也比较利于配置管理工作的进行。现在有越来越多的的软件开发是在异地进行,一个开发组的成员可能在不同城市甚至在不同国家,因此便于异地开发的人员分工与配置管理的源代码组织结构是非常必要的。
(2)便于人员分工-开发工作的负载均衡
不仅仅是开发出来的软件系统需要负载均衡,在开发过程中开发小组各成员之间工作任务的负载均衡也是非重要的。所谓工作任务的负载均衡就是通过合理的任务划分按照开发人员特点进行分配任务,尽量让项目组中的每个人每段时间都有用武之地。这就需要在构架设计时应当充分考虑项目组手头的人力资源,在实现客户需求的基础上实现开发工作的负载均衡,以提高整体开发效率。
(3)便于人员分工-进度安排优化
进度安排优化的前提是模块独立性并搞清楚模块开发的先后制约关系。利用工作分解结构对所有程序编码工作进行分解,得到每一项工作的输入、输出、所需资源、持续时间、前期应完成的工作、完成后可以进行的工作。然后预估各模块需要时间,分析各模块的并行与串行(顺序制约),绘制出网络图,找出影响整体进度的关键模块,算出关键路径,最后对网络图进行调整,以使进度安排最优化。
有个家喻户晓的智力题叫烤肉片策略:约翰逊家户外有一个可以同时烤两块肉片的烤肉架,烤每块肉片的每一面需要10分钟,现要烤三块肉片给饥肠辘辘、急不可待的一家三口。问题是怎样才能在最短的时间内烤完三片肉。一般的做法花20分钟先烤完前两片,再花20分钟烤完第三片。有一种更好的方法可以节省10分钟,大家想想。
(4)便于人员分工-预防员工人员流动对开发的影响
人员流动在软件行业是司空见惯的事情,已经是一个常见的风险。作为对这一风险的有效的防范对策之一,可以在构架设计中考虑到并预防员工人员流动对开发的影响。主要的思路还是在模块的独立性上(追求高内聚低耦合),组件化是目前流行的趋势。
(5)利于配置管理(独立性、层次性)
利于配置管理与利于人员分工有一定的联系。除了逻辑上的模块组件要利于人员分工外,物理上的源代码层次结构、目录结构、各模块所处源代码文件的部署也应当利于人员分工和配置管理。(尽管现在配置管理工具有较强大的功能,但一个清楚的源码分割和模块分割是非常有好处的)。
(6)大小的合理性与适度复杂性
大小的合理性与适度复杂性可以使开发工作的负载均衡,便于进度的安排,也可以使系统在运行时减少不必要的内存资源浪费。对于代码的可阅读性和系统的可维护性也有一定的好处。另外,过大的模块常常是系统分解不充分,而过小的模块有可能降低模块的独立性,造成系统接口的复杂。
2、可维护性
便于在系统出现故障时及时方便地找到产生故障的原因和源代码位置,并能方便地进行局部修改、切割;(可维护性与运行可管理性不同)
3、可扩充性
统在建成后会有一段很长的运行周期,在该周期内,应用在不断增加,应用的层次在不断升级,因此采用的构架设计等方案因充分考虑升级、扩容、扩充的可行性和便利。
4、可移植性
不同客户端、应用服务器、数据库管理系统:如果潜在的客户使用的客户端可能使用不同的操作系统或浏览器,其可移植性必须考虑客户端程序的可移植性,或尽量不使业务逻辑放在客户端;数据处理的业务逻辑放在数据库管理系统中会有较好的性能,但如果客户群中不能确定使用的是同一种数据库管理系统,则业务逻辑就不能数据库管理系统中
达到可移植性一定要注重标准化和开放性:只有广泛采用遵循国际标准,开发出开放性强的产品,才可以保证各种类型的系统的充分互联,从而使产品更具有市场竞争力,也为未来的系统移植和升级扩展提供了基础。
5、需求的符合性
从源代码的组织结构看需求的符合型主要考虑针对用户需求可能的变化的软件代码及构架的最小冗余(同时又要使得系统具有一定的可扩展性)。
五、写系统构架设计文档应考虑的问题
构架工作应该在需求开发完成约80%的时候开始进行,不必等到需求开发全部完成,需要项目经理以具体的判断来评估此时是否足以开始构建软件构架。
给出一致的轮廓:系统概述。一个系统构架需要现有概括的描述,开发人员才能从上千个细节甚至数十个模块或对象类中建立一致的轮廓。
构架的目标应该能够清楚说明系统概念,构架应尽可能简化,最好的构架文件应该简单、简短,清晰而不杂乱,解决方案自然。
构架应单先定义上层的主要子系统,应该描述各子系统的任务,并提供每个子系统中各模块或对象类的的初步列表。
构架应该描述不同子系统间相互通信的方式,而一个良好的构架应该将子系统间的通信关系降到最低。
成功构架的一个重要特色,在于标明最可能变更的领域,应当列出程序中最可能变更的部分,说明构架的其他部分如何应变。
复用分析、外购:缩短软件开发周期、降低成本的有效方案未必是自行开发软件,可以对现有软件进行复用或进行外购。应考虑其对构架的影响。
除了系统组织的问题,构架应重点考虑对于细节全面影响的设计决策,深入这些决策领域:外部软件接口(兼容性、通信方式、传递数据结构)、用户接口(用户接口和系统层次划分)、数据库组织和内容、非数据库信息、关键算法、内存管理(配置策略)、并行性、安全性、可移植性、网络多人操作、错误处理。
要保证需求的可追踪性,即保证每个需求功能都有相应模块去实现。
构架不能只依据静态的系统目标来设计,也应当考虑动态的开发过程,如人力资源的情况,进度要求的情况,开发环境的满足情况。构架必须支持阶段性规划,应该能够提供阶段性规划中如何开发与完成的方式。不应该依赖无法独立运行的子系统构架。将系统各部分的、依赖关系找出来,形成一套开发计划。
六、总结
系统构架设计和千差万别的具体的开发平台密切相关,因此在此无法给出通用的解决方案,主要是为了说明哪些因素是需要考虑的。对于每个因素的设计策略和本文未提到的因素需要软件构架设计师在具体开发实践中灵活把握。不同因素之间有时是矛盾的,构架设计时需要根据具体情况进行平衡。
摘要：本文从程序的运行时结构和源代码的组织结构两个方面探讨了系统构架设计应考虑的各种因素,列举了系统构架设计文档应考虑的一些问题。
关键词：构架,设计,考虑
参考文献
[1]冀振燕编著,UML系统分析设计和应用案例[M].人民邮电出版社,2004.
[2]杨远红编著,通信网络安全技术[M].机械工业出版社,2006.01.
[3][美]Katharine Whitehead编著,王海鹏译,基于组件开发[M].人民邮电出版社,2003.9.
[4][美]里克特编著,李建忠译,Microsoft.NET框架程序设计[M].清华大学出版社.2003.11.
系统架构设计考虑 篇2
1、核心业务代码模块的开发;
2、负责整体框架设计和业务设计;
3、负责对开发人员的技能培训;
4、负责对新技术的调研;
5、负责初中级应用运维工程师技术指导和培训;
6、负责部门知识库的建立和文档编写。
岗位要求：
1、具有面向对象分析、设计、开发能力(OOA、OOD、OOP)，熟悉流行架构原理(SOA/J2EE、分布式等)，并在此基础上设计产品框架;
2、精通java,eclipse基础、熟悉主流开源框架、熟悉前端交互技术(Ajax、Css3及H5)，了解前端主流框架(jQuery、EasyUI、Extjs等);
3、熟悉SQL Server,Oracle、MySql、PostgreSQL等主流数据库并了解其特性，熟悉Apache、Tomcat、Weblogic，Ngix，haproxy等主流中间件，能够根据需要设计及调整部署结构;
4、熟悉ActiveMQ等消息中间件。
系统架构设计考虑 篇3
关键词：技工院校；学生工作管理系统；架构设计
我国正处于现代化转型时期，网络通讯技术和计算机技术被广泛应用于各个领域，在此时代背景下，充分借助现代化网络信息及计算机技术构建数字化校园，是各大院校发展的必然趋势。
一、构建技工院校学生工作管理系统的功能性
从整体院校管理工作来看，为了保证技工院校管理工作能够高效、高速、高质的开展，并在此过程中谨遵“与时俱进、求实创新、以人为本”的工作原则，就必须要以科学发展观为指导思想，充分应用现代化计算机技术，构建学生工作管理系统，为学生提供更高效更完善的服务。由此可见，在技工院校中构建学生工作管理系统有着关键性作用，具体来讲可以从以下几个方面分析：
1.构建技工院校的学生工作管理系统能够满足学生信息的管理要求
在管理学生日常事务过程中运用工作管理系统，能够全面、系统的存储学生的学费信息、个人信息、家庭信息，就个人信息方面学生可以根据其自身情况进行更改，校方管理员则可以对学生所修改信息的时间段进行设置，学生对自己信息的修改需要控制在信息管理员所设置的时间范围内，而在学费信息方面，信息管理员需要根据所查询学生的姓名、学年、年级、专业、院系、学号等各项信息组合查询的方式搜索学生相关信息。
2.构建技工院校的学生工作管理系统能够满足学校数据统计分析的管理要求
在技工院校中，数据统计分析管理主要分为两个方面，一方面是数据查询一方面是统计分析，在此过程中数据查询功能能够满足思想教育模块中的入党申请、入党培训、入党积极分子、预备党员等相关数据的存储和查询。而统计分析功能则主要是针对技工院校思想教育开展过程中的一系列信息，进行深入的分析并根据分析结果科学制定报表，递交上级领导，使其能够全面了解和掌握学院开展思想教育所取得的成果。
二、针对技工院校中学生工作管理整体流程展开分析
针对我国某地职工院校展开考察，了解到常规技工院校三年学制中等学级学生的管理工作流程主要分为五个步骤，具体如下：
1.针对新生报名所进行的管理工作
由于技工院校的教育具有职业性特点，决定了其一般采用自主招生的方式开展招生活动，并且在招生录取过程中存在不同程度的变动性，针对此情况职工院校应当对各专业新生报名情况进行详细、全面、实时的统计，一旦出现报名情况与原计划不相符时，学校应当及时根据统计所反映的情况调整下学期招生计划及教学安排等一系列工作。
2.针对新生报到所进行的管理工作
针对新生报到环节，通常需要学校多方部门合作办公，新入校学生一般对学校情况较为陌生，因此需要对其报到流程进行明确、详细的引导。就学校信息管理工作而言，新生报到环节是采集学生信息、掌握学生各方面情况的关键环节，应当全面、清晰的记录好学生的相关信息，为后期管理工作建立良好基础。
3.针对学生在校学习阶段所进行的管理工作
通常情况下，技工院校学生在校学习的时间为两学年。在此过程中，对于学生进行的管理工作主要分为五个方面：①学生学籍管理；②技能鉴定管理；③操行评定管理；④教学评议管理；⑤学生成绩管理。
4.针对学生顶岗实习期间所进行的管理工作
当技工院校学生升至三年级时，需要参与企业的顶岗实习，在此阶段学生要走出校园真正踏入企业进行更职业化的培训和学习。在此过程中，学校会安排相关班主任对学生在企业中具体学习情况进行跟踪，以便校方等够及时、全面的了解和掌握学生表现，倘若学生未能在第二学期中通过相关考试并获得相应技能证书，则在学生顶岗实习期间将其召回继续参加考试。
5.针对学生毕业期间所进行的管理工作
当学生结束三年学习之后，并且在获得相关职业证书和获得认证前提下，学校将上上级部门报批毕业学生情况，在经过上级部门审核之后统一制作并颁发相关毕业证书。
三、技工院校学生工作管理系统的功能分析及架构设计
技工院校学生工作管路系统主要是结合技工院校教育特点而构建的网络办公系统。通过上述对技工院校管理工作流程的介绍和分析，可将技工院校中学生工作管理系统分为十一个，分别是：系统管理子系统、招生注册管理子系统、顶岗实习管理子系统、学生评议管理子系统、学籍管理子系统、领导办公子系统、技能鉴定管理子系统、操行评定管理子系统、毕业管理子系统、成绩管理子系统、基本信息管理子系统，且每个系统具有其相应功能，以下就技工院校中常用系统功能进行分析。
1.技工院校基本信息管理子系统
该管理系统主要作用于学校班级、教师、专业等信息的维护和管理，其功能主要包括增加班级、教师、专业等信息，以及对班级、教师、专业信息进行修正和查询。
2.技工院校招生注册管理子系统
该管理系统主要作用于新生报名情况的管理和维护，其功能主要包括新生预报名情况、报名情况查询、学生预分班情况、新生报到注册情况、注册查询、入校费用收取情况等一系列情况的管理和查询。
3.学生成绩管理子系统
该管理系统主要作用于学生成绩的维护和管理，其功能主要包括成绩的授权和录入、学生考试成绩的录入、学生补考成绩的录入、学生成绩自主查询、学生成绩的统计和分析、补考情况查询、补考名单的导出和下载、查询学生成绩报表。
结束语
现阶段，全国各大高校相继构建了学生工作管理系统，有效提高了学校在处理学生信息过程中的工作效率以及工作质量，不仅为学生提供了便捷的服务也在很大程度上降低了相关管理人员的工作量，在学校整体信息管理工作中发挥了重要作用。
参考文献：
[1]杨雨帆.技工院校学生工作管理系统架构设计研究[J].职业，2013，（17）：43-44.
[2]苏茂芳.高职院校学生工作管理平台的设计与实现[D].湖南大学，2013.
[3]周明锋.技工院校学生就业管理系统的设计与实现[D].山东大学，2009.
民用飞机刹车系统架构设计的考虑 篇4
电传操纵系统的优点是结构简单,体积重量小,易于安装和维护,操纵灵敏度高,无滞后现象以及便于和机上其他系统交联,大多数现役民用飞机都采用电传操纵-液压作动的刹车系统。该文分别阐述了正常刹车系统与停留/应急刹车系统的设计方式,希望能为国内民机刹车控制系统设计上提供技术支持。
1 系统原理分析
某型民机的正常刹车为数字式电传刹车系统,具有人工刹车功能、自动刹车功能、止转刹车功能、差动刹车功能、防滑保护、接地保护、轮间保护、BIT功能以及与其他系统通讯功能,正常刹车系统由脚蹬位移传感器、自动刹车选择开关、切断阀、刹车控制阀、转换阀、液压保险、压力传感器、机轮速度传感器、刹车控制组件BCU等组成。刹车系统原理如图1所示。
由图1可知,某型民用飞机脚蹬正常刹车由驾驶员操纵刹车脚蹬实现,在正/副驾驶的脚蹬下,均安装有刹车脚蹬位移传感器。刹车时,安装在刹车脚蹬下的脚蹬位移传感器输出与脚蹬位移成正比的电信号给刹车控制组件BCU,BCU首先打开切断阀,接通液压油路,然后控制刹车控制阀输出刹车压力给刹车装置,同时机轮速度传感器将机轮的转速信号送给BCU,BCU通过对比运算,控制输出到刹车控制阀的电流信号大小,从而调节刹车压力。通过刹车控制组件的调节使作用于刹车装置的刹车压力与跑道摩擦系数水平相匹配,从而达到较高的刹车效率。
停机/应急刹车系统是人工操纵推拉手柄、钢索传动、液压作动的系统。飞行员操作手柄,手柄通过钢索传动打开停机/应急刹车阀,接通液压油路,转向阀在液压油压力作用下接通停机/应急刹车管路与刹车压力输出管路,最后将刹车压力输出给刹车装置。
2 机型特点分析
采用左/右刹车脚蹬不联动设计,优势在于防止刹车脚蹬卡阻带来的影响,劣势在于左右座驾驶员无法相互感知对方的刹车作动,当驾驶员刹车动作错误时,另一名驾驶员无法及时纠正对方的动作。当左右驾驶员同时操作刹车脚蹬时,同侧(例如左座左脚蹬与右座左脚蹬)脚蹬信号送给BCU后进行处理,取刹车脚蹬行程大者执行刹车。由于左右驾驶员的操作力以及物理惯性力不一样,可能存在一只脚踩深,一只脚踩浅的情况,导致飞机可能出现差动刹车的情况。当脚蹬正常刹车和应急刹车手柄同时使用时,正常刹车管路中的切断阀、刹车控制阀将打开,应急刹车管路中的停机/应急刹车阀也将打开,转向阀的阀芯在两路液压刹车油路的压力作用下,最后选择输出脚蹬正常刹车压力和手柄应急刹车压力中的大者。此时,飞行员无法直观判断正常刹车系统工作还是应急刹车系统工作。在上述情况下,刹车控制盒BCU会自动抑制刹车压力反馈功能,系统故障检测能力将受影响。对于该类的刹车设计,可以通过飞行员飞行手册中明确规范其相关操作,防止出现上述描述的现象发生。
3 运营风险评估
为准确评估脚蹬正常刹车和应急刹车手柄同时使用的风险,下面分4种情况进行分析。
(1)地面停机:在地面停机情况下,无安全风险。
(2)地面低速滑行:地面低速滑行(空速35 kn及以下)时,无安全风险。
(3)地面高速滑行:地面高速滑行(空速35 kn以上)时,由于脚蹬正常刹车和应急刹车手柄同时使用,机轮刹车可能处于无防滞保护的状态,有刹车压力过高导致机轮爆胎的风险。
(4)着陆前:正常刹车有接地保护功能,即着陆前即使踩刹车脚蹬,正常刹车也不会输出刹车压力;而应急刹车没有该项功能,若在着陆前拉停留应急刹车手柄建立刹车压力,此时会出现warning级的着陆构型告警信息“CONFIG PARK BRAKE”,飞机将带无防滑的刹车着陆,机轮可能会抱死接地,容易发生爆胎情况。
4 现役主流机型相关设计情况
4.1 A320飞机
A320刹车控制系统采用正常-备份刹车架构,详见刹车原理图2。正常刹车系统由绿液压系统供压,备份刹车系统和停留刹车系统由黄液压系统或刹车蓄压器供压。使用停留刹车,需将停留刹车手柄放到“ON”位,停留刹车选择活门就会打开,压力输出到机轮,将飞机机轮刹死[2]。
4.2 B737系列飞机
B737飞机刹车控制系统采用正常-备份刹车架构。正常刹车系统由B液压系统或刹车蓄压器供压,备份刹车系统由A液压系统供压。当B液压系统压力低或失效时,A液压系统将自动向备份刹车系统供压。B737施加停留刹车时,需将脚蹬踩到满行程后,再拉起停留刹车手柄,通过系统内部的棘爪机构将脚蹬连杆保持在刹车位,并关闭停留刹车关断活门,堵住回油油路[3]。
4.3 ERJ190-100飞机
ERJ190-100刹车系统采用内-外系统架构,停留/应急刹车系统采用钢索传动的机械形式,当拉起停留应急刹车手柄后,刹车指示灯亮,见图3。
4.4 总结
现役主流机型刹车系统架构设计见表1。
由上述可知,现役主流干线民用飞机的刹车系统都采用正常刹车与备份刹车的架构,支线民用飞机的刹车系统大多采用内-外刹车与停留/应急刹车的架构。
5 结语
通过该文分析,目前现役支线民用飞机刹车系统的设计大多采用内-外刹车与停留/应急刹车的架构,这样的设计成本低、维修和架构简便等优势,符合支线客机设计的需求,但也存在人为因素考虑不周,在飞行体验上略差,需要在手册加限制来弥补人为差错,后续设计机型时可多考虑从设计初期明确相关需求,较多地考虑客户的使用需求以及驾驶舱人机工效的需求。
参考文献
[1]刘永军,薛东青,姜逸民.某民用飞机应急刹车系统权衡研究[J].科技资讯,2010(32):61-62.
[2]杨宗卫.浅析A320系列飞机刹车系统工作原理[J].价值工程,2014(30):87-88.
系统架构设计考虑 篇5
这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类 和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里 不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架 构都是必须要面对的。
这里讨论一下大型网站需要注意和考虑的问题
1、海量数据的处理
众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加 几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是 几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。
2、数据并发的处理
在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然 而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及 缓存策略。
另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。
3、文件存贮的问题
对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是 对文件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是 一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。
也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度 如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。
所以我们不得不承认，文件存贮是个很不容易的问题
4、数据关系的处理
我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。
5、数据索引的问题
众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本 会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。
索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题。
6、分布式处理
对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个 绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。
7、Ajax的利弊分析
成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处 理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。
8、数据安全性的分析
对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了(比如我们 知道的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来 之后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实 现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空 间和qq空间的群发了。大家愿意试试，实际上并不是很难。
9、数据同步和集群的处理的问题
当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问 题了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒 或者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题。
10、数据共享的渠道以及OPENAPI趋势
系统架构设计考虑 篇6
[关键词]网络在线考试；详细设计；架构
详细设计中的一个主要任务就是架构设计。根据需求阶段的规划，进行网络在线考试系统的架构设计时，选择了三层架构。由于使用三层架构进行系统开发的基础是要搭建系统框架。本文将从三层架构的介绍入手，通过完成基于三层架构的“在线考试系统”框架的搭建，让读者掌握三层架构的搭建过程。该过程重点在于表示层、逻辑层、会话层的构建及用户创建各层之间依赖关系的模型层的实施。难点在于实施模型层过程中的各个实体类的创建。
1.三层架构模式的介绍
在早期开发应用程序时大多数是基于Windows模式设计，在这种环境中一般程序设计人员设计考试系统时主要是采用C/S架构完成。程序一般时运行在一个局域网内，采用两层架构的设计思路就可以完成要求。而对于这种模式的考试系统对于学生使用地域上产生了很大的影响，必须要组织学生在同时同地完成考试。为此，提出基于Web模式设计考试系统是可以解决这些问题的。对于采用Web模式开发的考试系统之前有使用ASP、PHP、JSP等工具完成的，当然这些开发工具各有各自的优点和缺点，本文主要讨论的是开发的架构，对于具体采用的语言不作分析和研究。
无论程序设计人员采用何种开发工具，目前在对于网络编程中使用的架构是客户端、业务处理端以及数据存储端的三层架构。使用这种严格的三层架构来对应用软件进行开发时将极大的提高了程序模块化设计，提高了应用软件运行的效率。当然采用这中架构设计的软件在今后的扩展和维护上也带来了很大的好处。
从应用软件开发技术角度上说，三层架构的“三层”是指用户界面表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）。
（1）用户使用的界面一般称为客户端或表示层
客户端是用户直接与应用软件建立关系的窗口，用户对软件需要完成的基本操作以及实现数据的输入输出等都是通过客户端完成的。
（2）业务处理端又称为逻辑层
对应用软件的业务处理都通过逻辑层完成的，业务的处理效率以及执行的优劣情况都是通过业务层来实现，因此逻辑层将承担非常重要的任务。程序设计人员开发开发时需要投入大量的精力在对程序的业务处理端。对于不同的开发语言在业务端的建立有不同的方法，可以通过创建类库、Web Service等形式完成对业务处理代码的封装。对于复杂的业务处理可以建立业务应用程序，加入中间件技术等完成。
（3）数据访问层
数据对于应用软件是必不可少的，所有的应用软件都会采用数据库作为系统中实现交互处理的数据存储。数据访问主要是为用户提供数据交互的平台，程序员可以通过在数据库中创建各种数据操作对象完成相关操作，比如创建存储过程、视图、角色等。
2.网络在线考试系统设计
在线考试系统的架构：先创建解决方案（取名Online），在解决方案下创建4个项目：第1个项目是用户界面表示层（取名OnlineWeb）；第2个项目是业务逻辑层（取名OlineBll）；第3个项目是数据访问层（取名ONlineDal）；除了这3个项目之外，还有一个模型成（取名OnlineModels）。下文将逐个给出各个层次中的每个程序的设计考虑。
本程序对考试系统的分析主要分为3个功能部分：用户登录、考生考试和交卷部分。各部分分别调用多个模块。
（1）验证模块
一般应用程序都有验证模块，通过验证模块可以防止非法用户对管理系统的使用。验证模块的设计不仅是用户使用系统的通道，更是对系统数据保护的重要措施。在验证模式的实现时可以加入防止SQL注入、SSL加密等技术以提高其安全性。
（2）时间控制模块
对于考试系统，需要模拟传统的考生时间规定。在考试系统中能够自动完成时间的设定以及对时间的控制等功能。考生只能在规定的时间内作答，当考试时间达到设定的值将能够对考生进行提醒和锁定考试。
（3）生成试卷模块
考试系统中一个重要的模块就是生成考试试卷，对于考试试卷的生成原则是需要根据设定的难易程度完成自动组卷。生成试卷的形式可以是传统的考试试卷形式，也可以是带答题卡的试卷形式。
3.总结
系统任务是根据需求分析阶段产生的规格说明书导出系统的实现方案。在本任务中基于概要设计说明书来实施目标系统的设计过程。本文简述了网络在线考试系统架构设计时采用三层架构，将整个业务划分为：用户界面表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）。目的是为了在系统开发过程中实现系统各个模块的“高内聚，低耦合”。
参考文献
[1]张仁龙，李晓华.计算机基础课程考试系统的设计[J].北京农学院学报，2007（S1）
[2]李美满.基于COM技术的通用考试系统的设计与实现[J].计算机工程与应用，2007（01）
[3]闫薇，尹心平.VBA技术在计算机基础考试系统设计中的应用[J].齐齐哈尔大学学报，2006（03）
[4]付细楚，邹北骥.基于组件的考试系统的研究与实现[J].计算机工程，2005（24）
[5]叶青，徐春凤.数据库原理无纸考试系统的设计与实现[J].长春理工大学学报，2005（02）
系统架构设计考虑 篇7
飞机制造商努力为新飞机降低重量和电源消耗;同时市场要求飞机制造商降低研制成本和缩短开发周期, 为了实现新飞机的竞争优势, IMA架构被引入航电系统设计中。本文针对联邦式架构过渡到IMA架构过程中需要考虑的因素, 分别进行了探讨。
1 联邦式架构与IMA架构的区别
IMA架构提供共享的计算资源、通信资源和输入输出接口, 这些资源能被分开不同航电功能所使用。由于IMA平台本身具有的健壮的分区机制, 驻留在IMA平台上的航电功能可以由不同安全等级, 不同设计保证等级的功能组成。相反, 联邦式的架构中, 每个航电功能均有特定的独享的计算资源 (处理器、数据通信和接口) , 这些计算资源驻留独立的LRU或LRM中。
2 联邦式架构转变到IMA架构的好处
IMA系统架构允许系统集成者优化整个系统计算资源, IMA系统的益处就植根于这些优化活动中。
2.1 IMA系统优化备份计算资源的分配
在资源分配过程中, 系统集成者通过操作配置表, 来动态管理预留的系统资源, 从而保障系统灵活性。IMA系统资源库的灵活性, 允许IMA系统资源的备份资源能更有效的利用, 这将减少总的系统备份资源, 以提供给将来的系统功能的增加升级。
2.2 IMA系统优化了设备的重量和电源消耗
由于IMA系统采用共享计算资源的模式, 共享处理器、共享输入输出接口, 使硬件及其相关的冷却组件、线缆等物理资源的减少, 转化为整个飞机的重量和电源消耗的减少。
2.3 IMA巩固了开发成果
硬件的合并后, 巩固了开发成果, 开发者只需将注意力集中在驻留软件的开发上, 不仅减轻了开发负担, 同时降低了取证的难度, 降低了开发成本、缩短了开发周期, 从而降低了项目风险。
2.4 开放的IMA架构增加了开发效率和市场竞争力
开放的IMA架构采用开放的系统接口, 允许多个不同的组织共同努力降低整个系统的开发成本和时间成本。它能促进广泛的工业参与, 使IMA组建的开发遍布于多个应用领域, 使那些在某些IMA组件上非常专业的低投入的小公司参与到飞机设备的开发设计中。
3 联邦式架构转换到IMA架构需考虑的因素
3.1 获取系统级的集成工具和程序
系统集成为系统优化提供了很多益处, 同时, 也带来了系统集成的复杂性。系统集成者要相信有利系统集成的工具和程序, 他们就能完成重要的集成任务。这些任务包括接口定义与管理、资源分配与管理以及系统构型确定与分析。成功参与B787项目的IMA系统供应商都强调, 系统集成活动的重要性, 在IMA系统集成的活动中, 遍及所有功能系统级集成过程是IMA架构中重要组成部分。系统集成工具和程序步骤必须能有效准确地管理系统集成活动。配置IMA飞机的取证和安全性分析活动依赖于已经证明的集成能力。
3.2 系统集成工具和程序的重要责任
系统集成者有四大重要任务, 它们是系统接口定义、资源分配过程、系统配置以及降低更改成本。
系统接口定义是IMA平台关键的任务。IMA架构的ICD (Interface Control Document) 比联邦式架构的系统更为复杂详细、这增加了ICD确认和验证的复杂度。如果ICD没有被定义清楚, 则系统开发者就缺少对系统的了解与认识, 增加了系统集成的难度, 许多集成问题只有在系统集成的末期才会被发现, 此时, 对系统更改大大增加时间和经济成本。因此, 用于管理ICD的系统集成工具和程序, 必须具有非常高的可信度。
资源分配是IMA平台的另外一个重要任务。IMA平台提供系统计算资源共享, 这些资源被分配给每个驻留功能。资源分配过程需要系统集成者给每个驻留功能一个初始的资源分配, 然后仔细分析, 保证平台能提供这些资源, 但是又有过度分配。系统资源分配过程需要准确的系统模型和值得信任的分析方法, 用于计算系统利用率和性能。
系统配置为IMA平台的第三个重要任务。IMA平台本身是可配置的, 每个组件均由可加载的配置表所配置。IMA架构需要健壮的工具将资源配置模型转换为可加载的配置数据项, 将这些数据项加载进每个组件。配置工具被用来支持取证, 必须满足严格的开发和测试标准。
系统集成工具和程序必须支持降低系统更改成本的需要, 为了满足较低更改成本的要求, 配置工具必须具备分析配置表变化的能力, 并且表明已经通过了取证的交付物的考验, 其更改只限于受影响的驻留功能内。
3.3 IMA系统应支持遗留系统的数据传输
由于时间成本的限制, 并非所有的航电功能够适合IMA平台资源共享, 因此, 通过传统的数据接口, 支持传统的系统设备的功能和数据传输, 对IMA系统设备的开发非常有益。只是IMA系统的集成者应想清楚, 他希望那些航电功能驻留在IMA平台里, 以保证足够多的系统驻留在IMA平台里。
3.4 建立具有全球化视野的组织架构
驻留功能系统设计人员必须参与到资源分配到谈判中, 以便获取可他们所负责的驻留功能所需的资源。IMA系统的组织架构必须符合的文化氛围应当是, 不同的驻留功能的设计人员, 都擅长优化整个IMA系统的功能的集成工作, 而不仅仅是自己负责设计的功能上。否则, 不可能在资源分配中找到全球化的驻留功能的优化解决方案。
总之, IMA系统的开发依赖于合理的组织架构, 该架构必须能为所有的驻留功能提出优化的解决方案。
3.4.1 IMA改变了资源管理的方法
共享计算资源的IMA平台, 需要所有的系统开发者和所有系统集成者共同工作, 实现最优化的集成方案。资源管理的方法应是直截了当的, 项目组织架构和相关的合同应适合于IMA项目的管理。
3.4.2 系统优化的内在动力不同
在IMA架构中, 整个IMA系统优化的任务被分割给不同的公司, 可能跨越同一个公司的不同部门和组织。每个公司都有优化自己负责功能的内在动力, 而是想着优化整个IMA系统功能。因此, 为了实现全球化的优化方案, 必须采用激励机制, 使每个功能的优化都符合整个IMA系统的优化。
3.4.3 对待备份资源应有新视角
在资源共享的IMA架构中, 备份资源用于整个集成系统, 而不是单个的驻留功能。本质上来说, 备份资源可以用于所有驻留功能的功能升级。这就允许系统集成者在分配资源的时候具有很大的灵活性, 减少了单个系统设备配置的增长需求。系统集成者负责保证每个驻留功能分配到合理的资源和性能。
对于集成者来说, 利用适当的工作和程序, 完成合理的资源分配相当重要。同时, 集成者需向驻留功能开发者表明, 他们的驻留功能分配到足够的资源。系统集成者和驻留功能开发者需知道备份资源是怎样被分配和被优化的过程。
3.4.4 决定使用开放的IMA架构还是非开放的IMA架构
开放的IMA架构利用公开的接口类型, 符合公共领域的接口定义;非开放的IMA架构是客户化的定制接口。具体选用哪种架构, 需考虑一下四个方面的因素:确定谁将作为驻留功能的开发者;谁将做为驻留功能系统集成者;权衡工业支持的开发和内部开发之间关系;权衡IMA系统受单个飞机制造商支持还是受多个飞机制造商支持。
4 结束语
IMA架构允许系统集成者优化备份计算资源的分配, 优化所有的驻留航电功能。同时, IMA架构从设备重量降低和电源消耗减少中获益。系统集成者要充分信任系统集成工具和程序;改变资源管理的方法;权衡是否采用开放的IMA系统架构。在IMA集成过程中, 各参与方都应具有全球化的视野。
摘要：本文指出了从联邦式架构过度到IMA (Integrated Modular Avionics) 架构过程中需要考虑的因素。联邦式架构使用分布式的航电功能, 每个功能驻留在其自己的LRU (Line Replaceable Unit) 或LRM (Line Replaceable Module) 中, 而IMA架构使用了具有高完整性, 健壮的分区机制, 同时能驻留多个不同安全等级的航电功能, 这些功能同时共享一个计算平台, 不仅提高了计算资源的效率, 同时节省了重量和电源消耗。本文还提出了使用IMA架构的益处和资源管理的方法。
关键词：IMA架构,驻留功能,联邦式架构
参考文献
[1]RTCA DO-297 November 8, 2005.Prepared by SC-200 2005, RTCA Inc.[Z].
[2]ARINC REPORT 651-1.Published:November 7, 1997[Z].
系统架构设计考虑 篇8
关键词：城域网；网络阅卷；分析与设计
中图分类号：TP393 文献标志码：A 文章编号：1673-8454（2014）06-0071-03
近年来，随着宽带网络校校通的持续建设与不断发展，教育城域网作为一个地区教育网络的中枢和骨干，承担着越来越重要的教育教学和教育管理的核心应用。在做好网络运维管理与安全保障的同时，如何主动适应新形势，充分发挥城域网络专网专线的优势，整合分散的资源，将信息化与教育管理核心业务融合，扬州教育人开动脑筋，创辟工作路径，创革工作方法，创新工作机制，将原来分散各县区的采用局域网方式的网络阅卷充分整合，构筑起千人在线、实时监控、安全迅捷的网络阅卷大平台，在省域实现了首次真正意义上的大市范围的中考网络阅卷。
一、基于城域网架构的网络阅卷的SWOT分析
在2012年确定采取基于城域网架构的中考网络阅卷方式前，我们开展了可行性分析，主要采用SWOT分析方法。
1.优势
一是城域网阅卷的基础设施相对完备。扬州市教育城域网始建于2003年，采取了“胖中心、瘦终端、高带宽”的建设理念和MPLS _VPN建设模式，随着业务承载量的发展，不断调整优化，形成了较为成熟的、完备的网络。与此同时，扬州教育城域网和运营商建立了良好的互信关系和沟通协调机制。
二是城域网阅卷的实际价值前景光明。通过利用城域网网络资源开展教育质量检测和中考网络阅卷，可以真正构建起统一评分标准、统一阅卷进度、统一阅卷尺度、统一成绩发布等四个“统一”的评价系统，确保中考的公正性、公信力、公平度，让考生安心、家长舒心、社会放心。
2.劣势
城域网阅卷没有先例可供参考，利用城域网架构开展阅卷这种方式在全市乃至全省都是首试，之前没有成功的范本和案例作为参考，一切都需要从零起步，从头研究，从速推进，从严落实。同时，城域网阅卷存在安全薄弱环节，一旦出现单点故障，所有的阅卷活动必须中止，其返工的工作量巨大，不能保证按时完成阅卷任务和发布成绩，将直接导致家长的焦虑情绪和社会的信任危机，严重影响教育声誉和政府形象。
3.机遇
往年中考已经采用局域网阅卷方式，积累了一定的经验。往年在各个县（市、区）已有利用局域网开展阅卷的成功基础，只不过地理位置各自分散、网络结构相对隔离，但随着网络技术的不断发展，软硬件的高速更新，安全管理的不断强化，完全有可能移植到城域网上来。另外，在初期调研考试和质量检测中，城域网方式已经开始试水。相关软件系统已经进行过三次大规模阅卷的模拟测试和实战演练，经推算完全能够为中考阅卷服务。项目上线可以也必将为全市4万多名考生提供公正、公信、公平的保障平台。
4.挑战
中考关联着千家万户，反映着教育质量，连接着教育民生。城域网阅卷是一项复杂的系统工程，需要各个方面的统一配合，协同作战，过程中存在着的任何风险和安全隐患必须得以有效控制和彻底排除。经测算，阅卷教师的阅卷终端到阅卷服务器，其间共有12个关节点，任何一个节点上出问题都会带来重大影响。特别是流量的控制、安全的控制、并发的控制，网络阅卷只能成功不许失败。
综上分析，基于城域网架构的网络阅卷系统的设计既是一种尝试，也是一项创新；既要看到前途的光明，也要看到道路的曲折；既不能盲目乐观，认为无外乎是将局域网转换为城域网，而不周密思考精心计划，也不能“难”字当头，畏首畏尾，而不大胆尝试放手去做。应该牢牢抓住网络安全这个核心，突破网络并发这个瓶颈，充分发挥优势，迅速弥补弱势，通过技术与管理双管齐下，安全与性能双轮驱动、阅卷点与中心端双向配合，抓住机遇，趁势而上。
二、基于城域网架构的网络阅卷的系统设计
城域网架构的网络阅卷和传统方式的最大区别就在于网络安全，网络安全同样也要依靠设计。网络安全领域的一句名言就是“三分技术、七分管理”，充分说明了安全也要依靠管理和技术方面的设计。
1.管理方面的三项设计
（1）设计拓扑结构，体现过程管理
网络设计的逻辑起点在其拓扑结构。设计中，我们在中心端、服务器前增加专门安全设备（VPN），审计设备及安全和性能监控平台（见图1）。安全设备的作用在于保证阅卷下载内容和上传数据的完整性、一致性和保密性，重在事前预防；审计设备可以详尽记录访问行踪，便于事后追查；安全和性能监控平台随时反馈流量，捕捉现场数据，做到事中监测。在此拓扑优化设计中还要考虑多个运营商的备份链路，以强化保障。
（2）设计技术选型，实施分级管理
系统设计中技术选型的原则是安全第一，性能优先，速度保障，同时考虑高可用性、健壮性和冗余性。为此，我们将该系统的设计定位为“一个中心、三级管理”。“一个中心”即在城域网网络中围绕最核心的阅卷服务器，做好阅卷服务中心的安全配套、建设与管理，“三级管理”即第一级做好城域网与运营商之间的链路传输和安全管理，第二级做好运营商与阅卷点学校的链路管理，第三级做好学校内部的链路传输和安全管理。确定最优技术选型之后，就要对方案的各个环节开展联调，实施压力测试，如图2、图3所示。
（3）设计安全制度，落实责任保障
安全离不开安全制度的制定和设计。中考网络阅卷期间，执行最严格的管理制度，人员进入机房前必须刷卡通过门禁系统，进入机房后全程视频监控，离开机房须将工作内容登记，全程具有可追溯性，确保数据万无一失。网络阅卷是一项系统工作，必须依靠各个部门和相关人员的密切配合和协调。技术上，召开协调会，明确设备提供商、链路运营商的各自责任。业务上，召开联席会，从试卷入库扫描直到最后生成数据，明确几方职责，确保业务岗位没有空缺，管理空间没有死角，安全链条没有松动。
2.技术方面的三项设计
（1）访问控制技术
针对阅卷点制作ACL列表，做好安全系列设备的访问控制限制，实施双人管理密码的策略。阅卷点的共享访问由教师机控制，具体操作为，通过右键点击“网上领居”，打开计算机的“网络连接”对话框，右键点击“外网链接”属性，点击“高级”选项，如图4所示。在“高级”选项中，钩选“Internet连接共享”选项下的两个对话框，如图5所示。
点击“确定”按钮，完成“本地链接”共享设置，完成后对话框如图6所示。
（2）安全检测技术
在网络阅卷过程中，时刻不能放松对各项设备的及时检测和监控。在交换机中开放镜像端口，采用协议分析软件或嗅探器（如sniffer、wireshark等），采用网络流量监控软件（如prtg、mrtg等）。当然最基本的方法也是最管用的，打开任务管理器，就可以发现CPU、内存、网络吞吐、进程、线程的运行和使用情况，如图7所示。
（3）安全备份技术
任何设备和应用都会“生老病死”，有其生命周期，要求保持其“基业长青”，就要考虑好冗余备份和灾难恢复问题。我们采取的策略是实时备份和定期阶段备份相结合、热备份与冷备份相结合、系统备份和数据备份相结合的方式，不但考虑设备备份，也考虑链路备份、人员备份等等。确保网络阅卷的系统不因设备宕机而损坏，网络阅卷的数据不因停电而消失，网络阅卷的业务不因链路中断而受影响，切实做到随机应变、有备无患。
三、结束语
囿于篇幅和安全因素，本文并未就基于城域网的网络阅卷系统的技术细节完全展开，谈的仅仅是整体架构分析与设计，在系统分析层面和技术框架上做了比较粗浅的阐释，所述的内容不涉及考务安排，和阅卷具体采用的软件也无任何关联。实际上，笔者深知，在这一框架下还有许多值得深究和改进的地方，如利用虚拟化的技术，实现服务器的集群和资源分配；采用专业灾备系统，实现在线备份与迁移；采用云框架云资源云服务的理念，建设阅卷云，把中考阅卷这一重要资源放大，把紧缺的安全技术充分发挥，实现学校学业质量检测的常态化等等。可以预见，随着大数据和云技术的深入研究和实作推进，基于城域网架构的网络阅卷必将拥有更光明的应用前景。