系统软件架构（精选12篇）
系统软件架构 篇1
1 引言
数字油田是油气工业信息化发展的必然结果。1991年, 在《Oil&GasJournal》杂志上出现了智能油田 (SmartField) 词汇及其论述, 这可被认为是数字油田概念的起源。1998年, 美国前副总统戈尔在一次演讲中首次提出了数字地球 (DigitalEarth) 概念。1999年, 大庆油田首次提出数字油田 (Digital OilField) 概念。源于对数字油田目标的期望差异性, 国际各大油公司对数字油田的描述和实施都存在一定的差异性, 还给数字油田取了不同的名字, 如:SmartOilfield (Shell) 、i-Oilfield (Chevron) 、eField或FieldoftheFuture (BP) 、DigitalOilFieldof theFuture (Schlumberger) 等。
数字油田是以信息集成、信息共享和工作协同为主要特征的综合管理系统。建设数字油田, 将油气资源的发现与开发工作从分类资料的顺序处理发展为实时处理, 建立快速反馈的动态油藏模型, 对油田生产过程和经济活动进行动态的把握和快速的控制, 实现实时或近似实时监视和管理油田的所有操作活动。
数字油田是一项涉及多学科的复杂系统工程, 支撑技术涉及信息技术、地学、石油工程、管理学等学科。需要强调的是, 数字油田迅速兴起主要归功于信息技术在网络技术、通信技术、计算技术、数据管理技术、软件开发技术等方面的不断突破、发展和应用。
目前, 数字油田是风靡全球石油工业界的热门词汇。2005年10月, Shell、Chevron等公司在石油工程师协会SPE (SocietyofPetroleum Engineers) 年会上发表了数字油田应用实践案例, 标志着数字油田的发展进入了实际应用阶段[1]。在国内, 最早规划数字油田建设的是大庆油田 (2000年) , 塔里木油田 (2002年) 、胜利油田 (2003年) 、新疆油田 (2003年) 等也相继规划和实施了数字油田建设, 均取得了一定的效果。中国石油2005年开始的“十一五”信息化规划的实施, 全面、有序地支持了数字油田建设。
借鉴数字地球的定义, 陈强、王宏琳先生[2]提出了“数字油田是某油田的虚拟表示, 能够汇集该油田的自然和人文海量信息, 人们可以对该虚拟体进行探查和与之互动”。我们可以看到, 目前的数字油田建设, 已基本实现对油田自然和人文海量信息的汇聚, 但尚未完全达到可以对油田虚拟体的探查和与之互动的能力, 欠缺在哪里呢?
初步分析认为:目前的系统一是对信息整合程度不够, 二是系统集成度和综合能力不高, 三是系统间的协同能力不足, 四是对油田虚拟化表示能力不足。
因此, 我们提出了以业务逻辑模型、技术数据模型和三维空间模型为基础, 以满足业务规则、信息集成和工作协同为目标的构建数字油田统一软件系统平台的思想, 在此基础上, 结合最新的信息技术的发展, 对数字油田统一软件系统体系架构进行探索性研究。
2 数字油田软件系统总体架构设计
2.1 数字油田软件系统架构设计理念
我们倡导数字油田统一软件系统的敏捷性、协同化、实时性等基本理念。因此, 数字油田软件系统架构设计中应体现以下几个理念:
2.1.1 数字油田统一软件系统应具备敏捷性
数字油田软件系统应具备良好的可扩展性, 可快速反应企业经营环境的变化, 能够迅速完成企业所需的新的应用开发与部署。
2.1.2 数字油田统一软件系统是资源共享与工作协同系统
数字油田软件系统建立硬件、软件、数据、知识等资源的共享环境, 为专业技术专家、企业管理专家建立方便、灵活的协同工作环境。
2.1.3 数字油田统一软件系统是实时系统
数字油田统一软件系统将油气勘探与开发过程中的资料处理流程设计为实时处理过程, 强调不同专业的工程师能够快速、动态地获得和共享数据信息, 建立动态数据管理与应用环境, 并据此动态掌握和实时控制油田生产过程和经济活动。
2.1.4 数字油田统一软件系统的建设应该循序渐进
数字油田软件系统是一种复杂系统工程, 投资大, 建设周期长, 可裁剪性尺度大。在数字油田软件系统架构设计中, 要充分考虑这一点, 以便为不同的客户提供不同发展阶段的数字油田软件系统, 灵活实现客户的阶段目标和总体目标。
2.1.5 数字油田统一软件系统建设应遵循统一的规则
遵循统一的规则 (如标准、接口等) 是建设数字油田统一软件系统平台的基础, 是支撑其敏捷性、可扩展性的基本要求。
2.1.6 数字油田统一软件系统建设应具备统一的模型标准
这里的模型主要是指:A、满足业务运行、管理及相互之间联系的业务逻辑模型;B、满足数据存储的技术数据模型;C、满足油田可视化、虚拟化需求的三维空间模型。
2.2 数字油田统一软件系统总体架构设计
简单地说, 数字油田统一软件系统是一个软件系统平台或信息系统的集合体, 对某一个专业系统, 只要遵循上述设计理念, 即可成为数字油田统一系统的组成构件, 并可实现与其他系统的信息交换、共享与互动。
数字油田统一软件系统架构分四个层次:物理资源层、数据资源层、业务逻辑服务框架 (含SOA框架和云计算框架) 、应用层。在数字油田统一软件系统总体架构中, 以SOA[3,4]理念构建平台, 并充分考虑数字油田软件系统应体现敏捷性、实时性、可扩展性等基本需求。数字油田软件系统总体架构如图1所示。
2.2.1 物理资源层
物理资源主要是指计算机、存储器、网络设施、传感器等, 其中传感器特指信息传感器, 用于信息的采集与收集。
在物理资源层, 支撑技术主要涉及计算机技术、数据存储技术、网络通信技术、信息传感技术等。
2.2.2 数据资源层
数据资源层涉及业务规范、业务逻辑、业务数据、空间数据, 以及元数据及数据库等。
数据库一般包括专业数据库、勘探开发主数据库、业务管理数据库、区域研究项目数据库、数据仓库等。
业务逻辑主要指业务规则、业务流程及业务关联关系等。业务逻辑是业务实现以及业务之间信息传递的核心, 它主导或控制了所有业务活动。
空间数据主要是指用来表示空间实体的位置、形状、大小及其分布特征诸多方面信息的数据, 所有业务活动均具有空间及时间属性。
在数据资源层, 支撑技术主要涉及业务建模、数据建模、元数据、数据库、专业数据管理、空间数据建模等技术。
2.2.3 业务逻辑服务框架
业务逻辑服务框架是数字油田统一软件系统架构的核心构件, 只要遵循业务逻辑服务规则和统一的SOA规范构建的业务系统或信息系统, 均能很方便地嵌入到该框架中, 实现敏捷地装配和信息集成。
支持业务逻辑服务框架的核心技术包括统一的SOA架构规范及组件开发及装配技术, 此外, 云计算技术可作为支撑业务逻辑服务框架的新的选件。
组件库组件包括:数据访问组件、专业组件、业务组件、SOA架构基础组件等。
2.2.4 应用层
应用层可以说是数字油田一系列应用场景的实现。应用层是在业务逻辑服务框架的基础上, 按业务需求及业务逻辑装配的一系列应用系统, 如:协同研究工作环境、作业区生产管理、勘探开发决策支持系统等。
3 数字油田统一软件系统建设规范
数字油田作为油田企业信息化建设的复杂系统工程, 涉及的标准体系涵盖信息技术、地学、石油工程、管理等学科。对于构建数字油田统一软件系统, 制定统一的标准规范是实现数字油田敏捷性、协同化、实时性的基础保障。我们认为, 数字油田统一软件系统建设需遵循以下基本标准、规范。
3.1 SOA架构规范
由于数字油田统一软件系统基于SOA理念构建, 因此, SOA架构规范是核心规范之一。遵循简单对象访问协议 (SOAP) 、WSDL、业务流程执行语言 (BPEL) 等SOA领域的国际标准, 可确保其它系统易于融入到数字油田统一软件系统之中。SOA凭借其对松耦合特性的支撑, 使得企业可以按照模块化的方式来添加新服务或更新现有服务, 以解决新的业务需要, 适应企业业务的不断变革与优化。
3.2 业务组件设计应遵循相关的业务规则或规范
业务规则涉及业务类型、业务逻辑、业务流程、业务规范等;大地测量标准 (EPSG) 、石油天然气地质编图规范及图式、工业自动化标准 (如:OPC、ISA等) 等都属于相关规范范畴。
3.3 数据模型与数据交换相关标准
数据模型与数据交换相关标准, 如:POSC、PP-DM、ePOS、WITSML、PRODSML、RESQML、SEG等。
4 数字油田统一软件系统构建的关键技术
基于以上基本理念和架构设计, 要实现将油田已有的信息资源和系统资源集成或融合到统一的数字油田统一软件系统, 我们认为需要SOA架构技术、模型管理技术、系统集成技术、计算技术、身份认证与信息安全等关键技术支撑。
4.1 SOA架构技术
4.1.1 SOA架构是建设数字油田统一软件平台的基础框架
在SOA理念中, 业务被划分 (组件化) 为一系列粗粒度的业务服务和业务流程。业务服务相对对立、自包含、可重用, 由一个或多个分布的系统实现, 而业务流程由服务组装而来。
通过油田业务与SOA现行国际标准及核心组件的有机融合, 实现SOA理念在数字油田统一软件平台框架中落地, 需要解决以下问题:
*基于可按需装配的原则, 统一组件开发规范, 提供统一风格的系列组件;
*依据业务需求, 实现动态的组件装配机制;对于业务的变更, 可灵活、快捷地实现组件重新装配;
*支撑开放的系统集成架构, 除规范新系统的建设外, 还需要实现现有系统的接入, 以及与外部系统的互动。
4.1.2 SOA架构实例——ePlanet
ePlanet平台[5]是北京中油瑞飞信息技术有限责任公司根据中国石油信息系统建设需要研发的具有自主知识产权的软件开发架构, 该平台采用SOA架构技术并遵循标准化、可扩展、面向服务的集成、面向石油行业、高复用设计理念而构建, 主要功能包括提供软件开发所需的基础组件/服务, 支持系统快速设计开发、运行管理和监控维护, 该平台上固化了一批石油行业的通用组件/服务, 是新一代企业级应用软件平台。
ePlanet平台的架构由下至上可分为四个层次:基础组件、SOA中间件、设计开发工具和业务组件。
4.1.2.1 基础组件
ePlanet的基础组件包括流程组件、数据访问、事务管理、全文检索、Ajax处理、权限管理、组织机构、缓存管理和定时任务管理等支持功能实现, 但与具体业务无关的公共组件/服务。
4.1.2.2 SOA中间件
SOA中间件是ePlanet中提供面向服务能力的构件, 包括RF-SOAF、ESB和BPM引擎。
RF-SOAF提供了服务的实现与调用、注册和监控等功能, 整个框架可分为数据访问、服务处理和服务交互三层。
ePlanetESB基于RF-SOAF的协议转换器和消息转换器, 提供对服务的通讯协议转换和数据格式转换。ePlanetESB还提供了接口以嵌入其它厂商的ESB产品, 如JBossESB、IBM WPS等。
ePlanet的BPM Engine扩展了BPEL规范, 支持对服务、事件和人的统一编排, 使得各种不同的服务和人工处理可以按业务需求快速组装成新的流程, 从而实现IT与业务的有机融合。
4.1.2.3 设计开发工具
ePlanet的设计开发工具包括代码生产器、工作流、智能报表和系统定制等四大模块, 对系统功能的实现提供了直接的支持。
4.1.2.4 业务组件
在ePlanet平台中固化了一些具有行业代表性的优秀业务组件/服务以支持应用系统的快速构建。如资源管理、项目管理、办公管理、WITSML (井场信息传输标准标记语言) 服务、综合录井曲线显示、开发图表绘制展示、地震数据显示、标准矢量图件显示、等值线显示等业务组件。
目前, 该平台已经在中国石油工程技术生产运行管理系统 (A 7) 、中国石油矿区服务业务管理系统 (C 4) 、煤层气排采监控软件系统、瑞飞协同办公平台等系统中成功应用。
4.2 业务组件开发技术
业务组件开发应遵循业务规则, 这里的业务规则是指与业务相关的操作规范、管理章程、规章制度、行业标准等。
业务规则实质上也可以理解为一组条件和在此条件下的操作, 是一组准确凝练的语句, 用于描述、约束及控制企业的结构、运作和战略, 是应用程序中的一段业务逻辑, 该业务逻辑通常由业务人员或企业的管理人员利用组件工具进行定制。
4.3 系统集成技术
基于SOA框架, 利用适配器 (Adapter) 、企业服务总线ESB (EnterpriseServiceBus) 和业务过程管理BPM (BusinessProcessManagement) 等技术, 通过服务装配、服务编排、数据服务等过程, 提供面向服务的数据集成、业务集成和应用集成。
4.4 计算技术
4.4.1 网格计算技术
网格计算技术将高速互联网、高性能计算机、大型数据库、传感器、远程设备等融为一体, 为用户提供更多的资源、功能和交互服务。
4.4.2 云计算技术
云计算是并行计算、分布式计算和网格计算的发展, 是虚拟化、效用计算、基础设施即服务、平台即服务、软件即服务等概念混合演进的结果。
数字油田统一软件系统平台的计算服务组件通过将封装好的应用系统与数据发送到云平台, 得到云计算服务。
4.5 身份认证与信息安全
结合企业的统一身份认证系统和信息安全管理策略及相关系统平台, 利用SOA框架中的安全性与可靠性相关协议 (WS-Security、WS-Reliability、WS-ReliableMessaging等) , 实现对用户身份与数据的安全控制。
5 数字油田软件系统应用场景展望
数字油田应用场景广泛, 这里, 我们通过数字油藏、协同工作环境、虚拟化油田等方面展望数字油田软件系统的部分应用场景。
5.1 数字油藏
王宏琳先生对数字油藏定义如下:“数字油藏是油藏的一种虚拟表示, 使得人们可以探测汇集有关油藏的自然和人文信息, 并与之互动”。
我们认为数字油藏应用场景应该具备以下特征:油藏建模及可视化;强调动态性和实时性;共享综合研究成果、井筒数据、油气水生产数据;多学科协同工作, 共同决策。达到科学决策、优化采油工艺、提高采收率的目的。
5.2 协同工作环境
这里的协同工作环境是指为油田各业务间能够协同一致, 高效完成业务活动而提供的统一软件平台。
该平台提供了根据业务流程及业务逻辑组织的相关专业和部门的技术人员、管理人员在跨地域的网络环境上进行协同工作的能力。
协同工作环境应具备以下特征:信息透明, 决策后移;共享资源, 共享知识 (特别是专家知识) ;协同研究, 协同决策;突破专业、部门、地域、系统等方面的限制。达到高效工作、优化流程、科学决策、提高效益的目的。
5.3 虚拟化油田
虚拟化油田是数字油田发展的高级阶段, 它可以全面展示油田的人文、地理、地质等真实环境, 实现油田全业务流程的模拟与虚拟控制。利用其三维虚拟现实场景, 可以在其中进行探查、研究, 并实现与真实油田的互动, 真正消除人、过程与应用之间的距离。
6 结束语
本文提出了一种数字油田统一软件系统架构方法, 为构建智能化的数字油田提供了一种软件实现方面的思路, 期望为未来的数字油藏、协同工作环境等应用场景建设提供一定的借鉴。
需要指出的是, 由于相关研究工作刚刚起步, 尽管北京中油瑞飞信息技术有限责任公司在SOA架构应用上进行了有益的尝试和探索, 但应用范围毕竟有限, 加之石油业务所固有的多元性和复杂性, 要实现数字油田统一软件系统平台的设想, 需要油田的深度参与, 并通过示范工程, 建立切实可行的方法和规范体系, 逐步将数字油田建设由实时性、协同性向虚拟化、智能化推进。
由于作者认识水平有限, 不足之处在所难免, 请有关专家共同研究与探讨。
摘要：中国石油信息化建设经过“十一五”的快速发展, 已由基础建设阶段跨入到应用提升阶段, 纵观各专业在用信息系统, 我们经历了从无到有、从初级到高级的历史性跨越。但面对错综复杂的业务关系, 仅从上游信息系统来说, 我们的系统尚达到理想的期望目标。本文从数字油田整体考虑, 基于业务规则、信息集成、信息共享和工作协同的理念, 提出了构建数字油田统一软件系统平台的设想, 结合最新的信息技术的发展, 给出了建立未来数字油田统一软件系统平台的架构方法, 希望对解决数字油田这样既庞大又复杂的应用系统环境下的软件架构问题起到一个抛砖引玉的作用。
关键词：数字油田,系统架构,SOA,ePlanet平台,云计算,数字油藏,数字盆地
系统软件架构 篇2
1、面向公司战略目标诉求进行架构设计、规划及管控，支撑变革蓝图与变革路标设计;
2、主导公司级项目的业务架构及业务解决方案设计，负责业务需求的转化及2B流程有效拉通;
3、支撑变革、流程、信息化项目中架构的评审，实现架构原则和标准的落地及日常执行;
4、参与公司IoT架构设计与项目实施工作;
5、变革与流程信息化治理体系建设与优化，引导变革解决方案建设实施，提供公司架构治理的方向和策略建议。
任职资格:
1、本科及以上学历，理工科背景优先;
2、优秀的沟通和理论联系实际的能力，精通企业架构及流程管理方法论;
3、熟悉房地产行业流程管理***实践和业界流程管理最新发展趋势优先;
4、8年以上工作经验，3年以上大中型企业的变革、流程、过程改进部门工作经验或咨询公司流程管理咨询经验，5年以上房地产行业相关领域工作经验优先;
5、拥有或曾通过以下一种或多种认证(或同等认证)者优先：
- TOGAF Architect
- PMP
软件架构设计面临新挑战 篇3
IT运行环境正在发生激烈的变化。一方面,由于互联网的普及、Web 2.0的流行以及虚拟化、云计算等技术的出现使得软件所要面对的环境日益复杂,不仅要面对种类更多的数据源,同时也要求软件能支持动态的配置和重组; 而另一方面,IT的普及带来了数据量的剧增,根据IDC的研究,未来5年,企业的结构化数据每年会保持20%的增长,而非结构化数据量的增加则高达60%。数据量急剧增加的一个必然后果是软件越来越大,也越来越复杂。
越来越多的数据、支持更复杂的数据源、软件能自动配置和重组等这些要求最终都需要更灵活和可靠的软件架构来实现,而传统的软件架构显然难以适应新的IT环境。实际上,以前我们设计应用软件架构的前提如今都已经发生了改变,因而软件的架构也需要改变,特别是考虑云计算在未来5年内的普及,我们的软件必须为云计算而设计。
IT成为业务的支柱
过去,IT主要用于完成一些可重复的业务流程的自动化,比如读取某个报表中的数据并对此进行计算。ERP算得上是IT最典型的应用方式,它实现了订单、记账和库存跟踪的自动化,从而大幅度提升工作效率。而如今IT技术的这种应用方式正在发生变化,因为今天的企业所经营的业务已经很难和IT分开。
一个典型例子就是一种在线音乐服务——网络收音机。提出这种业务的公司在一些专业人士的帮助下为它的客户提供定制的音乐,它们会跟踪每个客户的收听习惯和听完音乐后的反馈,以保证它们为每个客户推送的都是客户喜欢的节目。很显然,没有强大的IT基础设施和计算能力作为保证,这项服务是不可能实现的。
而物联网的兴起更是推动了应用软件的变化,使得软件从人机交互为主到全面的自动化。应该说,到目前为止,大多数计算都是由人类活动发起的,比如订购了一个商品、访问一个网页等等。而未来,由各种各样的设备(如传感器)发起而非人类活动发起的计算会越来越多。比如,如今智能电表在很多城市得到普及,它取代了传统的人工抄表方式,省时省力。方便的背后是因为它主动发起了很多操作: 这种智能电表与电力公司的数据中心相连,它自动地把账单信息上传到电力公司的数据中心。除此之外,它还能实时地记录用户的电力使用细节,这些信息能帮助电力公司了解某个用户使用电力的情况,从而制定相应的价格策略。这与每月仅仅读取一个用电数相比,要传输和处理的数据量多了很多,也使得后台的处理工作量大了很多,最终必然会影响后台的软件架构。
架构设计需应对四个挑战
应用程序需要处理的数据量、数据类型以及应用程序的应用场景的变化,给未来的应用软件设计带来很多挑战。具体来说,有四个方面:
应用程序负载变化大。工作任务变化和工作环境的复杂都使得应用程序的负载变得不可预测。比如,酒店传统的高峰时段是每天早上(主要为退房)和下午4～9点(入住)。而在未来,业务的多样化将使得应用程序随时都有可能出现高负荷。也就是说,应用程序将是全天候处于工作状态,而不仅仅只在某几个小时。
用户接口类型更加复杂。过去很多应用程序是面向人的,因此非常重视人机交互,比如会有很大的显示屏以方便用户输入,而如今数据来源趋于多样化,除了人工输入外,更多时候是来自于其他应用程序、传感设备或者来自用户上载的文件或者之前根本没有想到过的某个数据源。因此,在接口方面除了传统的服务接口、上载接口还要考虑各种终端或者外设的输入,除了单数据的输入还要考虑批量上载。相应地,在应用程序的架构设计时就必须把各种新的数据流考虑进来。
要支持移动应用。过去的应用程序通常都工作在一个相对稳定的场合,与外部的连接通常也是可靠的,而架构设计通常也是基于这样的前提设计的。而今,随着无线网络的普及,无线应用越来越多,而在无线网络中,连接并非一定是可靠的。比如,用户正在一个急驶的出租车中,他所使用的服务可能随着位置的变化很快不可用。因此,程序必须充分考虑这一点,即在网络联通时能快速获得所需的数据,一旦中断能保护好工作“现场”,以待下次网络恢复时继续。
应用程序的拓扑结构更复杂。数据处理规模的不可预测,要求软件架构的设计必须改变。比如,很多程序开始大量使用内存缓存数据以提高处理速度,而不一定把每个都保存到数据库。而且,应用程序复杂常常是与异步处理和计算密集性的任务相伴相随的,这时通常都会用到消息队列,在应用程序的软件架构时都必须考虑到这些问题。
从软件架构开始支持云计算
为了保证应用系统能够满足企业未来的新需求,特别是支持云计算,对于新的软件系统有必要在软件架构上做好准备。建议可以从以下几个方面进行考虑:
1.对应用软件中准备使用的中间件(或组件)进行重新评估。现有大多数中间件是面向静态环境进行设计的,通常采用手工配置,偶尔进行升级。这些中间件一般都有一个配置文件,人工进行流程编排。中间件启动时,先读取这个配置文件,然后根据文件要求完成规定的任务。未来,随着云计算环境的普及,不断会有新的连接加入也会有连接退出,这就会导致与中间件的连接关系发生变化,上述手工方式就开始显出不足来。为此,未来的架构必须支持在线调整中间件在流程中的关系、能动态增加和删减连接。
2.在软件的设计和开发过程中时刻牢记负载平衡。很多应用软件支持在Web服务器层的负载平衡,但进行负载均衡的时候要求所连接的组件数量固定而且IP地址也是固定的。而实践中,负载变化的幅度可能很大,所以应用软件的每个部分都应是可扩展的,也就是说要支持动态的负载均衡,在设计应用软件架构时不能先假定只有一个或者几个组件。
3.不要忘了可扩展性。可扩展性一直是设计软件架构时应该考虑的,只是未来软件的可扩展问题可能变得更重要。换句话说,未来的软件必须要有能支持2倍、3倍甚至10倍负载的能力,因为将来软件的应用软件放到云环境中后,负载会变得不可预测,为此必须特别注意可能存在的性能瓶颈,而且要考虑好如何在程序运行的过程中解决可能存在的问题。事实上,如果设计时不考虑到可扩展性,未来的软件架构将很难应对超出的负载。
“双向评价评价系统”的软件架构 篇4
关键词：双向评价,软件,架构
1 引言
所谓软件构架,是指软件开发人员根据用户提供的理论构想,专门设计的技术流程。软件架构不但决定着开发人员采用何种技术手段实现用户所提出的理论构想,而且也关系到所开发软件实现方式的可行性、先进性、实用性和可操作性[1,2,3]。因此,一部理想软件的开发,必须从建立软件构架入手,只有做到这一点,才能实现所开发软件的预期目标。本文结合“双向评价系统”的开发,就此问题谈一些具体做法,供大家参考借鉴。
2 软件系统概述
2.1 软件系统架构模式
“双向评价系统”是基于校园信息系统(Campus-Wide Information Systems,CWISs)平台的浏览器/服务器(Browser/Server)结构的管理信息系统(Management Information System,MIS)。它利用校园网提供的Web服务,使用简单、一致的浏览器接口,实现评价数据的采集、汇总和共享。与Windows 2000 Advanced Server同时提供的因特网信息服务(Internet Information Server,IIS)就是功能强大的Web服务器。IIS提供对动态网页(Active Server Pages,ASP)的支持。“双向评价系统”主要由ASP页面及数据库管理系统组成。系统客户端配置Windows XP+IE 6作为基本运行支持环境。
2.2 数据库选用
可供选择的数据库管理系统较多,如Access、SQL Server等。根据该系统的应用需要并考虑到数据库维护等的问题,我们选用了功能强大而又易于维护的Access数据库系统。
2.3 ASP页面开发
ASP包含服务器脚本(主要使用Java Script,VBScript)、对象和组件。目前流行的网页开发工具,如Front Page 2003等,均支持ASP开发。使用Front Page,利用脚本语言和内建的对象、组件,可以非常有效地实现对评估数据的访问和更新,也可以得到较友好的用户界面。有条件的可以使用微软的Visual Inter Dev,它提供创建和维护Web站点的开发环境,并且与SQL Server紧密集成,可以直接设计和修改数据库的数据表。评价系统中使用到的内建对象主要有:
1)Application Object-这个对象表示的信息可以与ASP应用程序的所有用户进行共享。
2)Request Object-表示由浏览器发向服务器的所有信息,包括表单变量和查询字符串。
3)Response Object-表示由服务器发向浏览器的所有信息,包括由ASP网页发送的HTML内容。
4)Server Object-用于启用服务器上不同的工具函数。
5)Session Object-表示有关特定用户会话的信息。比如登录系统的用户、用户单位及用户角色等,见图1。
3 评价系统主要功能及角色划分
3.1 评价系统功能设置
评价系统可对各类人员,如学员、教员(同行)、专家、领导所作评价数据的采集。并按指定方式,进行数据汇总,生成各类汇总结果。主要适用于平常教学不同方面的水平衡量、所设立教学优胜奖的最终结果统计和对8个方面的满意度进行汇总。同时,系统还可以进行各种评价意见和建议的汇总,得到来自各个层面的合理建议和需要解决的问题,便于教学管理部门及时发现问题。
3.2 用户角色划分及功能
根据系统登录用户在教学评价中担负的任务,将用户划分为4种不同的角色,并对不同的角色授予不同的功能或权限。包括:
1)学员:参与教学评价,包括课堂理论教学、实验教学、教学课件,参与满意度评价。
2)教员:主要指讲师和助教,作为同行参与课堂理论教学、实验教学、教案质量、教学课件质量等评价,参与满意度评价,参与对本教研室承担课程进行维护,参与在教研室范围内对上述项目进行自查自评。
3)专家:主要指教授和副教授,作为专家进行课堂理论教学、实验教学、教案质量、教学课件质量等教学质量评价,参与满意度评价,参与对本教研室承担课程进行维护,参与在教研室范围内对上述项目进行自查自评。
4)领导:包括校领导、部(处)领导、训练部(处)机关参谋和学员队管理干部。作为领导对课堂理论教学、实验教学、教案质量、教学课件质量等教学质量进行评价,负责对评价结果、评价意见建议进行通报和总结讲评,如果需要经系统管理员许可,也可以参与满意度评价。
3.3 系统管理员主要任务
系统管理员作为超级用户应指定专人担任,专门负责评价系统后台数据的管理。包括数据备份、系统设置、系统用户角色称谓维护、专业管理、部门管理、用户管理、课程管理、ABCD等级系数维护、设置教学评价项目、设置各教学评价项目指标体系、设立教学优胜奖项目、设置满意度评价项目、设置满意度评价内容等。也可以发布系统广播、撰写规范制度。原则上,系统管理员不参与教学评价及满意度评价,如系统授权许可,也可以参与相关测评。
4 系统数据库结构
系统采用了Microsoft Access数据库。根据系统功能要求,设计了16个数据表。
1)ABCD等级系数abcd,见图2。
2)教学质量评价项目aspect,见图3。
3)满意度评价项目asp2,见图4。
4)教学质量评价结果erecord,见图5。
5)教学优胜奖winner,见图6。
6)教学质量评价指标idx,见图7。
7)满意度评价项目idx2,见图8。
8)课程名称lessons,见图9。
9)专业名称major,见图10。
10)满意度评价记录satisfaction,见图11。
11)系统广播news,见图12。
12)用户角色roles,见图13。
13)制度规范rules,见图14。
14)系统设置systemsetting,见图15。
15)部门列表units,见图16。
16)用户列表users,见图17。
参考文献
[1]董剑利,黄应堂,李小明,等.数据库网站技术的发展和应用[J].甘肃教育学院学报,2000,14(3):54-57.
[2]姚亚军,黄应堂.试卷分析计算机应用软件的研究与开发[J].甘肃教育学院学报,2002,16(1):33-35.
软件架构师个人简历 篇5
姓 名： YJBYS 性 别： 男
出生年月： 1988-10-25 目前所在地： 湖南
------- 求 职 意 向 -------
寻求职位： java软件工程师
求职地区： 湖南 工资待遇： 4000
到岗时间： 随时到岗
自我评价： 为人诚恳、自信，工作中踏实、沉稳、积极进取且有耐心。
服从上级安排且有良好的团队合作精神。
学习能力很强，敢于面对困难和挑战。
具有良好的心理素质和抗压能力，能适应加班。
------- 工 作 经 验 -------
就职公司： 湖南信息科技有限公司 公司行业： 信息技术和互联网(计算机软硬件,通讯)
就职时间： 1月到6月 就职部门： 软件部
公司性质： 民营/私营企业/非上市公司 就职职位： 软件架构师
工作描述： 参与J2EE项目的设计和编写，进行后台的日行维护和数据更新。
技能专长： 1.熟练使用JSP、Servlet、Jdbc等进行Java Web的编程开发。
2.熟悉Struts、Hibernate、Spring、Ibatis等框架，能熟练的.进行SSI或SSH整合开发。
3.熟悉JavaScript、jQuery等框架;掌握Ajax异步技术，并能应用其进行开发。
4.熟练使用Eclipse、MyEclipse、VS等IDE开发工具。
5.熟练应用Apache、Tomcat、WebLogic等服务器进行Java Web的开发配置和部署。
6.熟悉Oracle、Sql Server ，了解MySQL等数据库应用开发。
7.熟练运用SVN、CVS版本控制工具进行项目的配置管理。
8.了解UML统一建模语言，能够使PowerDesigner等建模工具。
9.熟悉Linux的基本操作。
基于B/S架构的软件项目开发 篇6
关键词：B/S架构；C/S架构；实际应用
中图分类号：TP311.13
1 前言
随着Web的蓬勃发展，网络结构模式也开始改变，B/S架构也就孕育而生。由于传统的C/S网络结构模式存在着种种问题，从而促使了B/S架构的兴起。人们在基于C/S架构的基础之上，提出了一种具有三层模型的结构，也就是对C/S架构的一种改进。随着B/S架构的广泛应用，掌握和了解B/S架构成为软件开发技术人员的必须具备的知识。
1.1 C/S架构
Client/Server（客户机/服务器）架构，是人们所熟悉的一种软件系统体系结构，通过将任务合理分配给客户机端与服务器端，降低了系统的通讯开销，两端硬件环境的优势可以得到充分的利用。在早期的应用软件开发中，大多数软件系统是把C/S架构作为设计标准的第一选择。C/S架构的的交互性强、可靠性高、有良好的数据处理能力，但是其客户维护成本高，工作量大，软件升级比较麻烦。
1.2 B/S架构
Browse/Server（浏览器/服务器）架构，它是在原有的C/S架构上进行了扩展。B/S构架的软件系统特点：浏览器只需安装在客户机上；服务器端则安装数据库（DB，Data Base）、客戶层浏览器和所有的数据；从逻辑上可分为三层，客户层浏览器、WEB服务层和DB服务器层。
客户机层的作用是实现用户界面在客户端浏览器中显示。浏览器显示从Web服务器端传输来的数据，然后用相应的HTML标记和CSS来实现。不仅如此，浏览器还得读取用户录入的数据，然后把校对后的录入信息上传于Web服务器。
Web服务器层是B/S的主要功能实现，其主要负责分析并处理由客户端浏览器传送来的数据，执行其相应的程序并把结果传回于客户端浏览器。Web服务器不只是为客户端服务，它还调用有关的数据访问接口对象来访问DB服务器中相应的数据，所以Web服务器层拥有大量的数据访问对象例如COM、ADO等。
DB服务器是核心，为其他技术提供访问DB的技术，并且可以完成对DB的各种操作，比如修改、删除、查询DB等功能。DB服务器是服务于Web服务器，按其请求从DB中提取或者删除相应数据。
1.3 B/S架构软件和C/S架构软件的区别
B/S架构和C/S架构有很多不同之处：硬件环境、对安全的要求、软件重用，用户接口、处理问题、系统维护、信息流、程序的架构等。C/S的传统客户服务器两层架构具有升级难、灵活性差、维护工作量大等缺点，已经难于满足如今快速发展的信息网络技术的要求。而C/S被B/S所取代最大的原因就在于B/S架构的客户端免维护，节省了成本，适用于大多数的用户群，适应各种情况。
采用B/S架构来设计和开发软件优势在于：（1）无需开发客户端软件，维护和升级简单方便，只要把完善的功能集中于Web服务器，依据不同且多样的功能设置好对应组别的用户权限就行了；（2）跨平台操作也是B/S的优势，任何一台机器只需要安装有IE、360等浏览器软件就可以访问系统；（3）因为B/S架构的开放性和可扩充性，所以B/S架构的限制也很少。
总之，B/S架构在根本上弥补了两层模式的C/S架构的不足，是应用系统体系架构上的一次重大变革。
2 B/S架构软件的实际应用
在现实生活中，我们用到许多基于B/S架构开发的软件，其在通信、管理以及OA等很多行业应用广泛，如网上银行、城市消防联网、学生信息管理系统等。下面以学生信息管理系统的设计为例，来说明一下基于B/S构架的软件开发。
学生信息管理系统是一个基于B/S架构的Web应用系统，用户可以在客户端使用浏览器给指定的Web服务器提出服务的请求，Web服务器通过HTTP协议把所需文件资料传给用户，且在浏览器上显示出来。该系统主要有两种用户：学生与系统管理员，把其分成两个模块：学生模块与管理员模块，独立设计2个模块的功能，再将他们融于总的控制模块中，其功能可因用户的不同而有所不同，学生可以用学号来查询成绩、班级等相关信息。同时，管理员可通过Internet对相关数据进行查询、修改、录入、删除等操作。此外，管理员不仅可以查看学生的相关信息如年级、学籍等，还能够对成绩、档案和课程安排等信息进行简单的管理。
2.1 B/S软件开发工具
B/S软件开发同网站开发一样，需要利用很多前后台开发工具，现在对学生信息管理系统开发工具列举如下：
ASP（Active Server Pages）指动态服务器页面，是微软开发的一个脚本程序来替代CGI，能够和DB与其他程序进行交互。ASP内含于IIS（Internet Information Services 互联网信息服务），可把VB SCRIPT或JAVA SCRIPT语言编写的服务器端脚本嵌入Web页面。在ASP中利用ADO（ActiveX Data Objects）可方便地访问DB，并有效地对DB进行处理。
该系统采用的是MS SQL 2000为DB系统，微软Windows2003服务器版本系统是其操作系统，IIS5.0/6.0是其Web服务器。
2.2 B/S架构的实例设计
经过上述分析，可将学生信息管理系统分成三层结构来实现，如图2所示。
在学生信息管理系统设计中，Web服务器层的程序设计是整个系统开发的主要部分，其是由Windows Server2003和IIS与全部的学生处理程序ASP文件和.htm文件构成。当某个学生在客户端要求查询信息时，由HTTP协议向服务层处的IIS要求下载文件，IE所要求下载的文件会经过ISS判断，如果是ASP文件，ISS就会执行该文件并把执行的结果返回于IE，如果不是，则直接将文件下载给IE。
以上是基于B/S架构软件项目开发设计中的一个实例，由于篇幅限制，我就不详细说明其他部分设计了。
3 结束语
综上所述，B/S架构软件项目开发是互联网发展的形势所趋，从实际应用中，可以看出B/S架构管理软件更为高效、方便、快捷。
参考文献：
[1]苗壮.基于WEB的学生收费管理系统的设计与实现[D].电子科技大学.2010
[2]肖满生.基于ASP技术和B/S构架的Web应用系统设计模型[J].中国高教论丛.2003
作者简介：赵巧玲（1991-），女，四川绵阳人，本科，研究方向：软件工程。
关于对数字油田软件系统架构研究 篇7
各行各业数字化的产生是现代科技发展的必然趋势, 油田作为生产比较复杂的部门发展数字油田更是势在必行, 数字油田的建立综合了石油地质学、项目管理以及通讯技术等多种科学技术, 多种学科之间相互结合, 形成了良性的互动, 为实现数字油田软件系统提供了强有力的保障, 实现了数字油田的科学化管理和生产, 推进了我国油田事业的发展。
一、数字油田概述
我们的石油资源非常丰富, 但我国石油资源越来越短缺, 是由于不合理的开发利用, 随着科学技术的不断发展和社会的进步, 数字化的油田开发和管理是一个有效的方法缓解资源短缺的局面[1]。所以上面的管理和协作应用程序非常复杂, 主要包括通信信息技术、石油工程、地质学和管理等许多复杂的问题, 软件开发技术在数字油田的发展起着重要的作用。
对于数字油田油田大量复杂的信息管理和信息收集等方面的建设已基本完成, 但在实际应用和效果没有达到预期, 国内许多学者都提出这样一个数字化的推进思路油田的软件系统, 即:在一个三维空间, 技术数据和业务逻辑模型, 以搜集资料, 并符合业务规则和协同工作为目标, 建立这样一个软件系统平台的思想基础[2], 结合世界IT和科技进步的数字化油田系统架构的深入研究和开发。
二、数字油田软件系统构架
2.1数字油田软件系统构架的设计原则
(1) 实现油田资源的共享和协调系统之间的工作。数字油田的软件系统应该建立在硬件系统之上, 协调硬件和软件复杂的信息和数据收集系统来协调, 结构, 预计将在资源共享的环境中, 在科学和商业的各个领域相应的技术专家管理人员, 建立资源和环境良好的相互协调。
(2) 具有时效性。由于数字油田的软件系统是收集大量的复杂信息和实时的整合过程数据, 为了实现高效的生产, 并需要技术人员和管理人员来自不同学科的快速分析信息处理与共享, 结合变化的外部环境油田开采和实时控制等生产活动和管理活动。
(3) 具有设计规则一致的原则。任何行业的设计应具有统一的要求, 它可以是迟的环境, 影响从做均匀的要求, 减少不必要的损失所带来的复杂问题等因素的原则。同样, 数字油田的软件系统的开发和建设也不例外, 需要有统一的标准和规则的约束和规范。
2.2数字油田软件系统架构的四个阶段
(1) 处理物理资源阶段。 (2) 处理数据资源的阶段。 (3) 业务逻辑服务的阶段[3]。 (4) 实现应用的阶段。应用阶段是被应用到实际的可视化阶段, 数字油田的软件系统。它是前一阶段的基础上, 按照既定的规则需要一系列的应用和目的。应用阶段是基于业务逻辑的服务框架, 根据业务需求和一系列应用, 如业务逻辑组件:合作研究的工作环境, 工作区的生产管理, 探索和决策支持系统的开发。
三、结论
综上可见, 数字油田的建立综合了石油地质学、项目管理以及通讯技术等多种科学技术, 多种学科之间相互结合, 形成了良性的互动, 为实现数字油田软件系统提供了强有力的保障, 通过不断完善深入的实践和应用, 为石油工业的未来发展的共同开发以及其他行业提供了实现的应用方向。我相信, 通过有效地促进科研路数字油田的软件系统架构设计, 能够提升中国石油工业的发展, 是具有国际先进水平的网络技术的发展和应用的技术, 实现了数字油田的科学化管理和生产, 推进了我国油田事业的发展。
参考文献
[1]马涛, 许增魁, 王铁成, 李阳明.数字油田软件系统架构研究[J].信息技术与信息化, 2010 (06) .
[2]孙旭东, 陈历胜, 李玲, 杨玉军, 陈述腾.数字油田业务对象模型设计方法[J].大庆石油学院学报, 2012 (01) .
系统软件架构 篇8
无人机 (简称UAV) 是一种体积小、重量轻、安全性好、成本低廉、可携带多种任务设备、执行多种任务, 、并能重复使用的无人驾驶航空器[1,2]信息化技术不断进步, 无人机在现代电子战中获得了迅猛发展。飞行控制系统软件做为无人机的核心软件, 对无人机系统至关重要。在顶层软件设计时, 采用先进合理的软件架构, 对飞控软件完成系统功能、提高系统性能, 降低错误出现概率、提高软件可靠性和安全性有很大益处。
1 软件需求分析
在设计软件之前, 需要针对系统的软件部分调查、分析用户和利益相关方的需要, 在飞控系统内, 需要通过机载软件实时完成对无人机的控制和命令响应, 在地面软件进行人机操作和状态显示, 具体需求分析如下。
1) 需要具有机载软件;
2) 需要具有地面软件;
3) 机载软件需要是实时操作系统, 快速完成控制和命令响应;
4) 机载软件具有基本通信功能, 可和测控电台进行通信、并可读写端口信息;
5) 机载软件具有自主飞行控制功能;
6) 机载软件具有传感器管理功能;
7) 机载软件具有执行机构输出能;
8) 机载软件具有应急处理功能;
9) 地面软件具有地图显示及飞行状态显示功能;
10) 地面软件具有飞行计划拟订、保存、上传功能;
11) 地面软件具有飞行控制功能;
12) 地面软件具有传感器设置和显示功能;
13) 地面软件具有遥测数据显示功能;
14) 地面软件具有飞前检查功能;
15) 地面软件具有日志记录和重演功能, 并根据不同权限可以提供日志记录、查询、修改、删除、报表查看功能;
16) 地面软件界面简洁、直观、友好, 便于用户操作。
2 软件系统组成
2.1 软件CSCI (计算机软件配置项) 划分
飞控软件由机载软件和地面软件两个CSCI组成, 其软件体系结构图如图1。
1) 机载软件
机载软件融于飞行控制计算机硬件平台中, 通过飞控计算机硬件模块与无人机外围设备、机载传感器以及执行机构连接, 采集无人机的外围设备的状态信息和机载传感器输入信息, 按照设计的飞行控制方案, 实时解算出对外围设备和执行机构的控制量, 并通过硬件接口模块对外为设备和执行机构输出控制。
2) 地面软件
地面显控软件运行在WINDOW XP下, 是自驾仪和用户之间的人机接口, 主要实现的功能有:无人机地面飞行任务的设定;无人机地面链路状态和传感器设备工作状态的确认;无人机执行机构方向设置舵机校准参数表、进行舵机测试、脉冲激励响应试验;设置IMU传感器的安装方位欧拉角、GPS天线到IMU的位置参数、磁传感器校准及大气传感器的初始误差;设置遥测接收频率;设置高度极限, GPS、数据链及手动指令的超时设置, 设置应急航路点及应急处理程序及动作等功能。
3 软件模块划分
3.1 机载软件模块划分
机载软件采用Vx Works实时操作系统, 主要划分为六个功能模块。
1) 自主飞行
无人机爬升到一定高度, 进入自主导航飞行。自主导航飞行是指由控制系统自动控制无人机按照规定的航向飞行。航线由多个航点构成, 飞行控制计算机根据传感器采集到当前的飞行高度、经纬度、航向等信息, 计算出无人机预定的航线和实际的位置以及预定航向和实际航向的偏差, 协调控制升降舵、方向舵和副翼舵, 完成无人机按照预定航线飞行的任务。
2) 遥自切换管理
当无人机接收到接收机传送的自主遥控切换指令时, 无人机进入目测遥控飞行模式。在该模式下, 飞机操控手可根据目测的无人机飞行姿态和高度, 操控舵面, 完成飞机遥控飞行任务。当飞控计算机接收到地面站发出的自主遥控切换指令时, 无人机进入地面站遥控飞行模式。当目测遥控和地面站遥控同时请求遥控权操作飞机飞行时, 优先处理目测遥控飞行请求。
3) 应急处理
飞行控制计算机对全系统中设备和飞行状态进行监测, 根据地面制订的应急处理措施, 对其中的典型故障进行自动优选处理。对出现故障及时提示地面控制人员, 地面人员可根据实际情况优先决策和应急处理
4) 执行机构输出
执行机构的控制指令输出是完成无人机执行机构的输出, 执行机构输出包括:升降舵、方向舵、副翼舵、襟翼舵、油门、点火盒和前轮舵。
5) 传感器管理
飞行控制系统的传感器主要包括: (1) 高度空速传感器; (2) 惯导组合导航设备。机载软件中的传感器数据综合处理模块, 完成传感器采集到的高度和速度信息到飞控计算机的通信, 并进行比较选择输入。当在GPS故障模式下, 选用高度空速传感器作为控制系统的高度输入。
6) 链路数据管理
按照约定的通信协议控系统发送过来的数据信息[3]并将无人机各状态信息打包, 完成无人机状态数据的下传。
3.2 地面软件模块划分
地面软件运行在WINDOW XP下, 主要划分为九个功能模块。1) 飞前检查
飞行前检查模块的主要功能是在无人机飞行前对飞机状态的检查, 主要包括舵机控制面的测试、电池电压和电流的检查、飞行任务计划的检查、应急任务的检查、无人机传感器组状态的检查和一些其它检查及系统初始数据设置界面, 舵面检测、留空时间设置等。
2) 地图显示
地图显示的主要功能是显示地图, 并提供对地图的放大、缩小、漫游、测距操作, 显示当前鼠标位置的地理坐标, 显示当前飞机位置及航线。
3) 航线管理
插入航路点、编辑航路点、删除航路点。新建飞行计划、保存飞行计划、查看飞行计划、修改飞行计划、删除飞行计划、读取飞行计划、发送飞行计划。
4) 遥控飞行
在地面站进行遥控飞机飞行状态, 包括爬升, 平飞, 下滑, 向左, 向右, 直飞状态。
5) 系统参数设置
系统参数设置模块主要由以下5个模块组成:通信模式设置模块、控制律设置模块、舵面设置模块、传感器设置模块和应急处理设置模块。
6) 系统参数显示
显示时间、供电、板内温度、记录仪状态、参数锁定、数据链、系统版本信息。
7) 遥测状态显示
显示传感器状态数据, 实时显示传感器采集的无人机飞行数据[4], 主要包括温度、静压、动压、三轴陀螺角速度、三轴加速度、角偏差、加速度偏差、磁传感器。显示实时飞行参数, GPS数据、姿态数据、大气数据、风速、AD采集、燃油、高度、导航、导航滤波、磁航向。
8) 飞行状态图形显示
图形方式显示当前飞机的状态。
9) 记录重演
按照定义格式记录当前命令控制、系统状态、遥测数据、飞行姿态信息到文件, 存储到本地硬盘, 并可以在本地离线重演。
4 小结
本文从软件副总设计师角度介绍了小型无人机飞控软件需求分析、系统架构、模块划分, 界面。工程应用实践证明, 该软件功能齐全、模块划分合理, 可靠性高, 取得了很好的效果。
参考文献
[1]王泉, 张学宏, 周敏刚, 黄晖.无人机飞控软件测试方法研究[J].航空计算技术, 2008, 3.
[2]宁金星, 卢京潮, 闫建国.基于VC++的无人机飞控地面站软件的开发[J].计算机测量与控制, 2009, 17 (3) .
[3]吴益明.无人机遥控遥测数据的实时处理研究[J].计算机测量与控制, 2006, 14 (5) :681-682.
系统软件架构 篇9
首先简述了MVC模型的原理和标识,基于该模型提出了多层增强MVC模型的概念,深入探讨该模型的原理和结构,以及基于新模型开发系统的优势。接着详细阐述了平台的具体实现,分别包括业务实体层、数据访问层、业务逻辑层、控制层、视图层等各层的设计与实现。
2 MVC模型基本原理
MVC即Model-View-Controller,它是一个设计模式,它强制性地使应用程序的输入、处理和输出分开。使用MVC应用程序被分成3个核心部件:模型、视图、控制器。
这样一个应用被分3个层———模型层、视图层、控制层,如图1所示。
2.1 视图(View)
是用户看到并与之交互的界面。
2.2 模型(Model)
表示企业数据和业务规则。在MVC的3个部件中,模型拥有最多的处理任务。例如它可能用象EJBs和Cold Fusion Components这样的构件对象来处理数据库。
2.3 控制器(Controller)
控制器接受用户的输入并调用模型和视图去完成用户的需求。
3 多层增强MVC模型原理
在3层MVC的架构基础上为了进一步细化各层功能,使得各层的功能职责变得更为内聚,尽可能地消除各层间的耦合度。得到如下结构,如图2所示。
从图3中来看,初步应该可以看出这是MVC的设计模式。前面的“显示层”就是MVC模式中的V,也就是View。作用是用来展现界面给用户的。第二个“交互层”就是MVC模式中的C,也就是Control控制层,用来处理请求的控制转发的。后面的4个层,就是属于MVC模式中的M部分了,即Model逻辑处理层。
3.1 数据层
从后往前看,“数据层”指的就是应用中的数据所存放的地方。例如,数据可以存放到数据库中,也可以存放到文件中等。
3.2 持久层
这一层的作用就是用来访问数据层,根据不同的数据存储方式,来实现不同的访问方式。
3.3 领域层
领域层的最大作用就在于从持久层获取领域对象信息,然后进行业务逻辑运算,实现代码的复用。
3.4 应用层
本层主要作用是将显示层的请求进行转发,将显示层的数据进行转换,并交由交互层进行处理。之后再将交互层获得的结果转换成显示层可识别的数据结构,交由显示层予以处理。
再往下就是交互层。交互层也是MVC模式中的C部分。
3.5 交互层
交互层也叫控制层(Command),这一层的作用主要就是:
(1)转发业务请求,错误处理,异常处理,页面导向。
(2)用户与系统之间的交互管理,提供用户层的展现逻辑和对应用层的接口访问。
(3)这一层还包含单点登入,会话管理,用户输入的逻辑校验,错误处理。信息提示等等。不过这些大部分不需要开发人员再次进行控制,而是由框架内置进行处理。
(4)是显示层的统一接入点。并在这一层里面使用配置文件来实现反转控制(IOC)。同时由分层的原则决定,它只和下一层应用层打交道,并向显示层提供访问接口。
3.6 显示层
显示层又称为客户层或者展现层。它的作用就是使得系统最终用户使用界面和设备,负责数据的展现。这一层的就是用户能够直接体验到的一层,即是用户看到的页面。
由于是用户直接看到的一层,所以这一层有一些主要的要求:
(1)界面美观大方,风格统一,交互性好。
(2)界面要符合用户的使用习惯
(3)尽量减少与后台的交互,出于分层的设计决定,这一层只作数据的展现,不做任何其他的无关的工作。
(4)只与下一层交互层,即Control层打交道,这个是分层的原则。
4 各层间调用流程
现在来看一下各层之间的调用流程,如图3所示。
还是以一个销售商品的业务为例子来说明一下整个流程。
首先用户在界面上看到的就是一个商品信息录入的界面,这也就是一层显示层。主要是采用JSP来展现页面。
当用户输入完对应的商品信息,并将提交请求后,由控制层(command)进行负责请求的转发,并调用下一层应用层(service)的对应的接口来完成商品销售的业务。这个时候前台的数据对象(viewbean)在就被传递到了应用层的实现类里面。
在service层里面进行整体的事务控制后,就调用下一层领域层(domain)里面对应的商品录入的接口以及发货通知等接口。
这个时候,就由各个领域层的实现类来处理对应的业务逻辑运算了。例如保存所订购的商品的信息时候,需要调用持久层提供的对应的接口来实现数据的存储。这就到了持久层,在这一层里面要做的就只是对资源的纯粹的访问。例如指保存订购的商品的信息到数据库中去。
这个数据库就是存放资源的数据存储层。
数据保存完成后,就将保存的信息返回到了领域层,然后领域层在根据信息进行其他的业务逻辑处理。处理完成后,在将结果返回给应用层。
最后应用层把得到的结果做一下转换,把后台的逻辑对象(databean)转换成为在前台展现的视图对象(viewbean)。并将这个对象交给交互层来处理。交互层(CMD)得到视图对象后,就进行页面的定向,决定用户在提交了商品订购请求后应该看到什么样的页面展现。
最后变又回到了显示层,一般指的是JSP页面上,然后在这个页面上进行数据的展现。整个流程的大致顺序就是这样。
5 配置文件
各层之间的初始化和调用依赖于Spring的架构配置文件。通过配置文件采用Ioc依赖注入的机制,使得数据流可在各层顺利地流转,jsp页面在提交或获取数据时也必须通过配置文件寻找对应的处理类。
配置文件内容如下所示:
参考文献
[1]孙卫琴.精通Struts:基于MVC的Java Web设计与开发[M].北京:电子工业出版社,2004.
[2]陈臣,王斌.研磨设计模式.北京:清华大学出版社.
系统软件架构 篇10
煤矿安全监控系统已广泛应用于煤矿企业的安全生产和监测监控, 给煤矿企业带来了良好的社会效益和经济效益。新版KJ95N型安全监控软件系统以Microsoft .Net Framework为运行平台, 在满足国家及行业标准的前提下, 针对用户的要求定制了一整套适合煤矿现场使用特点的功能, 同时对整个系统架构进行了优化。本文将对新版KJ95N型安全监控软件系统的应用架构进行介绍和分析。
1 系统应用层面的整体构架
新版KJ95N型安全监控软件系统架构如图1所示。监控主机负责与各分站交换控制命令、配置信息及实时数据, 并对上传信息进行综合处理;监控备机采用在线热备方式, 对分站上传数据进行实时处理;网络服务器实时与监控主机进行数据交换, 同时负责向外发布数据或提供对外数据接口, 供第三方应用。监控工作站、网络客户端可以从网络服务器上获取实时数据, 并对实时数据进行直观展示, 同时也可以从网络服务器上查询历史数据, 对历史数据进行统计分析。
2 系统特点
(1) 采用模块化设计, 增强了系统的可维护性、扩展性以及开放性, 使系统的可控性大大提高。目前已实现监控的模块有安全生产监控、人员监测、瓦斯抽放、语音及电子牌指示等, 以及其它系统或装置的接口, 如主扇风机在线监测、提升机在线监测、核子秤、胶带机信息汇接及水泵控制信息汇接等。
(2) 采用.NET平台、智能客户端技术, 可以将胖客户端应用程序 (C/S) 的优点和瘦客户端应用程序 (B/S) 的部署与可管理性优点结合起来, 使之在资源的利用上达到优化平衡, 充分利用本地资源和享受本地用户体验, 具备离线连接能力及智能部署和自动更新能力。
(3) 支持多路多通道并行传输方式, 可大大缩短数据交换时间, 摒弃了以往风险集中的单通道传输方式, 为故障快速诊断、缩短故障处理时间及系统的安全性、稳定性提供了保障。
(4) 基于XML的开放式矢量化图形系统, 提供专业级的图形处理功能和页面开发能力, 支持多种图形格式, 以逼真的画面再现煤矿监控现场。
(5) 支持网络互联、GPRS分级报警功能 (手机短信) , 不仅可快速告知所需人员, 同时支持组播、分级播报、消息通知及报警解除等多项功能。
(6) 系统预警模块支持趋势预报、门限预报、突变预报等。
3 系统应用构架的实现方式
目前, 一般软件系统的表现方式有 B/S (瘦客户端) 和C/S (胖客户端) 之分, 它们都具有各自的优点和缺点。而新版KJ95N型安全监控软件系统采用了有别于B/S结构和C/S结构的SmartClient (智能客户端) 方式。下面对这3种结构方式进行对比分析。
B/S结构的优点: (1) 易于部署。采用B/S结构的系统只需在Web服务器上一次部署, 无需到客户机上进行任何部署, 客户机即可浏览到相关应用。 (2) 易于变更管理。当程序需要升级时, 只需在Web服务器上进行一次升级, 客户机无需做任何额外的工作, 即可获取到最新的应用。 (3) 广泛覆盖。服务器部署完成后, 凡是与服务器网络相连的地方, 任何在线的客户机都可以浏览到相关应用, 不受地域限制。
B/S结构的缺点: (1) 依赖网络。采用B/S结构的系统必须在客户机在线时才能使用系统的各项功能。 (2) 疲乏的用户体验。由于浏览器技术的限制, 客户端的使用体验难以提升, 给用户带来操作上的麻烦。 (3) 开发复杂。在浏览器上要想实现丰富的交互功能, 需要大量的脚本实现, 而由于脚本的技术限制, 给开发和调试带来很大困难。
C/S结构的优点: (1) 丰富的用户体验。利用强大的客户端资源, 采用C/S结构的系统客户端提供丰富的界面展现能力和交互能力。 (2) 开发效率高。客户端程序采用完全面向对象的高级语言, 编写简单, 调试方便。 (3) 快速响应。客户端程序可以充分利用客户机的本地资源, 并且利用网络资源的效率也更高。
C/S结构的缺点: (1) 部署困难。以往的客户端程序需要人工到各个客户机上执行安装操作, 如果客户端使用量较多, 则部署的工作量会很大。 (2) DLL地狱。由于技术的限制, 之前的客户端如果使用系统共享DLL文件的话, 当需要版本更新时, 可能会与其它也使用该DLL文件的程序产生冲突, 从而带来无法解决的所谓DLL地狱问题。 (3) 明显痕迹。安装客户端程序时, 有可能需要向系统注册表、目录等处添加许多信息, 而当卸载时, 这些信息又会遗留在系统中, 从而产生大量的无用信息。
从以上分析可看出, B/S和C/S方式都存在不同程度的缺点, 并且其中某些缺点对于用户来说可能是不可接受的, 比如B/S结构的用户体验比较差, 而C/S结构的部署很不方便等。
基于.NET Framework的SmartClient技术可以将C/S胖客户端应用程序的优点和B/S瘦客户端应用程序的部署和可管理性优点结合起来, 使之在资源的利用上达到某种平衡[1]。与B/S或C/S相比, SmartClient技术融合了它们的优点, 而摒弃了它们的缺点。SmartClient是易于部署和管理的客户端应用程序, 它们通过统筹使用本地资源和到分布式数据资源的智能连接, 为用户提供快速响应和丰富的交互式体验。SmartClient应用程序因功能级别的不同而呈现出多种形式, 但所有SmartClient应用程序都具有的一个特性就是具有利用本地资源的能力;SmartClient的离线功能不仅可以在移动方案中使用, 而且其桌面解决方案也可以利用离线体系结构来更新后台线程上的后端系统, 从而保持用户界面的响应并改善最终用户体验。总结起来可以概括为3点, 即充分利用本地资源和享受丰富的用户体验, 以及智能部署和自动更新。
4 结语
SmartClient作为一种新兴的架构, 结合了胖客户端和瘦客户端的优势, 代表了下一代客户端软件技术应用的发展方向[2]。新版KJ95N型安全监控软件系统正是采用这种最新的SmartClient架构, 极大地方便了程序的部署和更新。随着现代科学技术的发展, 新的技术手段必将更多地应用到煤炭行业, 高可靠性、智能预测预报算法、过程数据无缝交换、无主或多主控制策略等技术必将是新一代监控子系统技术的发展方向。
参考文献
[1]屈迟文.智能客户端技术研究与实现[D].成都:西南交通大学, 2008.
大型集团信息系统架构研究 篇11
存在的问题
这些大型集团建立之初，并无统一的信息化整体规划，大企业、好企业较早应用成熟的信息系统，而小企业、困难企业根本没有任何信息系统。既不能把已有的系统推倒重来，全集团使用一个集中系统；更不能对没有信息系统的企业置之不理。要把信息化应用水平不一样的企业，统一到一个水平很难。已有信息系统的企业，由于建设时间不相同、购买系统厂商不一致，存在“C / S”、“B / S”体系异构，存在O r a c l e、S Q L S e r v e r、D B 2等数据库异构，存在E R P、C I MS、C R M等应用系统、软件厂商、数据结构的异构，要在众多异构环境下，实现集团内数据采集、系统集成很难。而且，信息系统应用孤岛的情况依然突出，难以集中。集团总部各业务部门或因上级要求、或因内部管控需要，独立使用专业信息系统，在总部形成“部门孤岛”；下属单位因专业领域不同，各自使用适合本单位流程的信息系统，在集团内形成“企业孤岛”。要把多年积累的“信息孤岛”集中，整合集团“部门孤岛”和“企业孤岛”很难。
这导致集团管控上下冲突，难以协同。一方面集团希望加强对下属企业管控，防止经营风险；另一方面，下属企业强调市场瞬息万变，需要灵活应对。这样，在推行统一规划、统一标准、信息集成、数据采集时，遇到各种阻力，需要各方保持一致很难。再加上，集团总部没有完整集团信息系统，对所属各单位信息统计是一个“月后”、“年后”报表，“问题”发现总是在统计报表数据出来之后。集团管控，只是一个静态监管、事后监管，而不是“过程”监管、“事中”监管，要做到集团决策和集团监管及时有效很难。
发展趋势
应用趋向集中，企业趋于分散，是大型集团公司目前发展的趋势，因此大型集团公司信息化建设需要新的信息技术、新的应用系统和新的解决方案。建立一种能够集成现有单组织信息化系统，同时能够覆盖全集团成员的多组织、跨行业大型集团信息化应用系统的需求越来越多。比如，向大集团协同发展，集团办公“网络化”趋势越来越普遍；向大集团优势发展，集团决策“智能化”趋势越来越强烈；向大集团物联发展，集团两化“一体化”趋势越来越迫切；向大集团“云”发展，集团资源“虚拟化”趋势越来越显现。
因此大型集团信息化需要首先解决全集团统一，解决信息“有无”问题。集团信息化建设必须集团单位全部纳入，统一规划、统一标准，才能发挥和体现集团整体信息资源优势。在此基础上，要完成全系统集成、全应用的集中、全成员协同、全过程监控。大型集团信息化需要解决集团部门和集团下属单位使用不同厂商的不同系统，应用不同的数据库，形成的“异构”数据、遗留系统的问题。集团部门和集团下属单位的已有系统，形成的“部门孤岛”、“应用孤岛”，需要全集团进行分类统计、通盘考虑，集中解决。集团总部和下属单位需要上、下协作、信息同步，将使用集成门户、单点登录、视频会议、公文流转等现代综合办公系统，解决上、下不同步的问题。最能体现集团信息系统是否有成效，就是通过信息系统，实现过去手工报表的“事后”监管，转变为“事中”监管，从而实现全过程动态监管。
至于大型集团到底需要哪些应用功能？这些应用数据从何而来？面对集团下属单位各种应用现状与存在的问题，如何既能满足当前大型集团的信息需求，又能够适应未来I T发展，确立系统功能和架构非常重要。
架构选择
大型集团信息系统应用功能来自于大型集团本身的特点和管控模式，经过对大型集团信息需求研究、分析，大型集团信息化应用功能至少包括“十大应用功能、十类角色权限”的基本要求。按内容应有以集团人力（党群）、集团财务（经营）、集团资产（收益）为核心的基本功能，实现上级国资委要求集团公司具有“管人、管事、管资产”的三个基本职能；应有以集团领导决策系统为“点”、以集团协同OA为“面”，以“点”带“面”，实现全集团员工应用系统的局面；应有集团战略、集团科技、集团供应链、集团综合业务等专业系统；还应有集团网络数据库支撑系统。大型集团业务系统根据集团管控模式不同，可以架构不同的应用功能。按终端角色权限划分，应满足如下十类个性需求：最高权限，集团董事长、总经理；其次，要有集团副职、集团部门正职、集团部门副职、集团部门员工应用需求；同时，还要有下属单位正职、下属单位副职、下属单位中层、下属单位员工应用需求；以及其他用户需求（最低权限）；对于副职和部门人员还要区分主管和非主管权限。
基于以上需求来看，大型集团信息系统架构需要考虑总体架构、应用架构、数据架构、网络架构等基本架构容。
信息系统总体架构有四种选择：完全集中、完全分布、“集中+分布”和私有云。大型集团（局级）公司采用完全集中，或完全分布的系统架构，都不能满足大型集团的应用需求；集团“私有云”目前还没有成熟的应用系统。因此，确定“集中+分布”的方式，是大型集团考虑信息系统总体架构时比较现实的方案，也是今后发展到集团私有云最有效的途径。要实现“集中+分布”的架构，最理想的方法是基于S O A的架构。通过分析大型集团信息化建设现状与需求特点，本文研究了大型集团信息系统（基于S OA）的总体框架，包括表现层：集团集成门户；服务层：集团服务总线和集团数据总线；应用层：集团决策、集团人力、集团财务等应用系统；支撑层，集团网络系统。
由于完全针对中国特有的“政改企”大型集团（局级）的应用方案还没有。因此，选择大型集团的信息系统架构尤为重要，它是项目实施成功的关键。大型集团应用架构包括基础技术层（OS、DB、中间件）、业务应用层（集团财务、人事、资产）、决策管理层（领导决策、权限管理）和集成门户层。基础技术层除了网络管理、数据库、操作系统等支撑系统外，还包括用来解决异构系统、异构数据的中间件；应用业务层首先要满足大型集团“管人、管事、管资产”的基本功能；其次要满足集团领导决策和集团协同办公“点、面”结合功能；再次根据大型集团管控模式，要满足其他重点业务系统；集成门户层是将集团部门（如上级要求）专业系统和其他应用系统，通过集成设置，实现单点登录，集成应用。
系统软件架构 篇12
系统测试的目的主要是验证系统的功能和性能是否满足设计要求,发现系统的实际应用效果是否与系统定义相符合。系统测试是检验软件质量的重要手段,软件质量的检测一方面要检查软件的设计是否合理、编码是否准确,另一方面要看软件的系统测试是否全面。在软件开发和应用中,很多编码上的错误很难发现,只有通过后期的系统测试才能被发现,所以软件系统测试在保证软件质量方面有着重要作用。在不同的环境下,软件系统的测试方法也有所差异,本文就基于B/S架构的Web软件系统测试进行探讨。
1 基于B/S架构的Web软件系统
B/S体系结构的应用原理是:用户通过浏览器将操作请求发送给网络上的服务器,服务器对接收的信息进行分析、处理后将用户所需要的信息发送至浏览器。相比二层的C/S体系结构,B/S体系结构只是从客户机的任务中将事务处理逻辑模块分离出来,并单独组成一个任务应用层,该方式将负荷分配给Web服务器,可以极大减轻客户机的压力。B/S架构的一个明显特点就是简化了客户端,只需要安装通用的浏览器软件,不需要在客户机上设置多个客户应用程序,所以整个系统安装过程非常简单,网络结构非常灵活,而且系统的开发和维护简单。B/S体系结构的特殊性意味着系统的测试也需要采用不同的方法。基于B/S架构的软件系统以网页表单的方式进行界面展示,服务器承担了系统的大部分工作,客户端对后台服务的访问通过浏览器实现,而且只能够完成浏览、查询、数据输入等比较简单的功能操作,同时还采用Cookies形式保存用户信息。Web软件系统的开发需要以HTTP协议和HT-ML为依据,这就决定了此类软件都要遵循统一的结构。图1是一个典型的基于B/S架构的Web软件系统结构。
2 基于B/S架构的Web软件系统测试
基于BS架构的Web软件系统测试涉及到多方面内容,包括可行性测试、性能测试、功能测试、安全性测试、兼容性测试等等。相比传统的软件测试,基于BS架构的Web软件系统测试内容侧重点明显不同,测试过程需要用户参与,不仅要检查系统的运行是否按照设计要求,还要评价系统在各种浏览器上的显示效果,尤其要进行系统的安全性和可行性测试。
2.1 系统可行性测试
可行性测试其实就是检测用户对系统的理解程度和使用效果,类似于系统的可操作性测试,涉及到系统的功能、系统的发布、用户与系统的交互效果。系统可行性测试主要包括导航测试、图形测试、内容测试、界面测试等。
系统可行性测试方法:(1)通过页面走查的方式检查系统页面是否符合要求,测试不同分辨率下页面的显示效果,如果发现有不符合要求的地方应交给设计人员进行调整;(2)根据数据定义文档来检查表单项的内容设计效果;(3)通过浏览查看方式检测动态网页。
(1)导航测试。系统导航是对系统页面中用户操作方式的描述,可以在不同的连接页面之间,也可以在按钮、窗口等不同的接口控制之间。系统的导航测试主要是检测系统是否易于导航,系统导航的界面设计是否直观,是否可以通过主页面实现对系统主要内容的存取,系统是否需要搜索引擎或者网站地图帮助,另外还需要检测系统的页面结构设计、导航设计、菜单设计以及连接方式的风格是否一致,是否可以让用户通过导航直观地了解系统的主要内容。
(2)图形测试。网页的构成主要包括两种元素,即文字和图片。图片在网页应用中有着重要作用:(1)美化网页;(2)进行广告宣传。但在系统运行过程中,网络传输的数据量是有一定限制的,所以网站的图片数量也不能无限大。图片在网页上的位置也有一定要求,不能随意放置,要符合页面的审美要求。图形测试主要是检测系统中图形是否具有应用价值,图形或者动画的放置位置是否符合要求,页面上的文字应用风格是否一致,页面的背景、前景以及字体颜色应用是否搭配,网页中图片的大小设置是否合适,图片的质量是否达到要求,以及图片的应用格式(一般是JPG或者GIF压缩)是否符合。
(3)内容测试。内容测试主要是用文字处理软件对系统文字信息进行检测,检验系统文字信息是否具有一定的相关性、准确性,信息是否真实可靠,信息是否存在语法错误或书写错误,是否能够在当前的页面找到相关的信息列表等等。
(4)界面测试。界面测试主要是检测用户在浏览Web应用系统时,对系统的整体界面是否感到舒适、直观,是否能够凭直觉找到信息,系统整体设计风格是否一致。
2.2 系统功能测试
基于B/S架构的Web软件系统功能测试主要包括链接测试、表单测试、Cookies测试、设计语言测试以及数据库测试,采用的方法主要有黑盒测试、白盒测试、边界测试或者越界测试。功能测试是验证产品功能是否与产品需求规格一致,不需考虑系统内部软件的实现逻辑。功能测试是系统测试最重要、最基本的内容,要求测试人员全面了解产品的需求规格和业务功能,设计出高效的测试方案。
(1)链接测试。链接的主要功能是实现页面切换,并引导用户找到所需要的页面。在基于B/S架构的软件系统中,链接是一个非常重要的特点,链接测试3个内容:(1)检测页面链接的准确性;(2)检测所链接的页面是否存在;(3)确定Web系统中不存在没有设置链接的孤立页面。
(2)表单测试。表单测试是对系统运行过程中,服务器所接收到的表单信息是否正确进行检测。例如用户在登录系统时需要填写用户信息,在表单中的用户名和密码条框中设置要输入数字的地方是否也可以输入字母,输入后系统是否会提示出错。如果表单采用了默认值,就需要对默认值的正确性进行检测。如果表单输入限定了某些值,则需要继续测试。
(3)Cookies测试。Cookie是指服务器暂存在计算机上的信息资料,主要用于存放用户应用系统时的信息。当用户浏览网站时,服务器会向用户的计算机上发送一些Cookies形式的资料,以便服务器能够很好地辨认用户的计算机。如果系统有Cookies应用,就需要对Cookies的功能和性能进行测试,检测Cookies是否正常工作,是否准确、有效地保存,是否受到系统其它操作的影响。
(4)数据库测试。数据库为系统的管理、运行以及数据存储提供空间。数据库测试主要是检测数据输出的准确性、数据的一致性。用户在提交表单时所填写的信息不正确可能导致数据一致性出错,网络速度过慢或者程序设计缺陷则可导致数据输出错误,数据输出错误和数据一致性错误是系统数据库发生的两个重要错误。
2.3 系统性能测试
性能测试是保证软件系统质量的重要测试内容,涉及到的测试内容较多,主要包括3个方面,即客户端、网络以及服务器端的性能测试。客户端性能测试包括数据量测试、速度测试、并发性测试等,主要检测客户端的应用性能;网络上的测试主要内容是利用相关技术进行网络预测、网络性能分析;服务器端的测试在于实现对服务器系统、设备性能的全面监控,可采用工具或命令进行监控。上述三者有效结合才能实现系统的高性能运行。性能测试常用工具有webload、was、ewl等。
(1)链接速度测试。链接速度测试是基于B/S架构的软件系统性能测试的重要内容。在基于B/S架构的软件系统应用中,软件的功能主要是通过服务器实现的,服务器将系统信息发送至客户端,客户端通过对信息的浏览实现各种应用操作。因此,基于B/S架构的软件系统对链接速度有很高的要求。如果系统对用户的页面访问需求响应时间超过5s,则用户很可能因为没有耐心等待而放弃本次访问。一般情况下,系统网页的链接速度与入网的方式与很大关系,例如宽带上网、电话拨号上网等各种上网方式的链接速度各有千秋。当系统响应速度太慢时,用户往往还没有浏览到信息就需要重新登录,而且链接速度慢也是导致数据丢失的重要原因。
(2)负载测试。负载测试就是检测系统在一定需求范围内是否能够正常工作,例如系统允许多少用户同时访问,如果访问数量过大会出现什么情况。负载测试一般需要在实际网络环境中测试,因为在因特网上有足够量的访问用户,才能获得准确可信的测试结果。
(3)压力测试。压力测试包括表单测试、登录测试以及其它信息输出情况测试。检测在一定访问数量压力下系统的反应,以及系统的压力极限和故障恢复能力,检测系统在较大访问压力下是否会发生崩溃。黑客在对系统进行攻击时通常会对系统提供错误的负载,让系统发生崩溃,并在系统重启时获得存取权,以此对系统实施攻击。
2.4 客户端兼容性测试
系统的兼容性缺陷引起的问题往往比较微妙,很难被发现,系统的兼容性测试经常被忽略。系统兼容性测试方法一般是创建兼容性矩阵,测试过程中需要考虑以下几个问题:(1)系统能够在哪些操作系统环境下运行;(2)系统能够与哪些类型的数据库进行数据交换;(3)系统能够在哪些硬件配置环境中运行;(4)系统能够与哪些软件系统协同工作。客户端兼容性测试主要包括平台测试、浏览器测试。平台测试需要在系统发布之前进行,系统使用哪一种操作系统往往由系统的配置决定。同一应用可能在某些操作系统中能够正常运行,但却无法在其它操作系统中运行。浏览器测试主要是检测浏览器的显示效果。
2.5 系统安全性测试
系统安全性测试主要是检测系统安全机制的有效性,验证系统内部的安全机制能否保护系统免受非法攻击。系统的安全性不仅是指系统能够抵挡住正面攻击,还要能经受来自侧面和背面的攻击,如此才能保证系统资源的安全性。系统安全性测试内容主要有:(1)对用户名和密码信息进行测试,检测系统对登录信息大小写是否敏感,对输入次数有没有限制,在没有登录系统的情况下是否能够直接浏览页面;(2)检测系统是否对登录状态有时间限制,用户登录后一段时间是否需要重新登录才能正常使用;(3)检测系统访问信息是否被写入日志,是否能追踪;(4)检测安全套接字中密码设置的正确性,以及信息是否完整;(5)检测服务器端脚本的管理应用是否设置权限,以免成为黑客攻击系统的漏洞。
3 结语
本文从系统可行性测试、功能测试、性能测试、兼容性测试以及安全性测试等方面对基于B/S架构的Web软件系统测试进行了探讨。基于B/S架构的软件测试是一个复杂的系统工程,相比传统的软件测试有很大差别,整个测试内容要保证全面性、充分性,并扎实地完成系统测试,这样才能通过系统测试体现软件的应用效果,保证软件质量。
摘要：软件测试是检验软件系统质量的重要手段,在不同环境下,软件系统的测试方法也有所差异。相比传统的软件测试,当前应用广泛的B/S体系结构软件系统测试有很大不同。该此类型的系统测试主要包括可行性测试、性能测试、功能测试、兼容性测试以及安全性测试等。
关键词：软件测试,B/S,Web
参考文献
[1]李志峥,杨社堂.基于B/S结构下的软件系统测试研究[J].科技情报开发与经济,2006,16(7):232-234.
[2]陈技能.软件测试技术大全---测试基础流行工具项目实战[M].北京:人民邮电出版社,2009:159-160.
[3]单良.校园网环境下的Web软件测试方法研究[J].鸡西大学学报,2009(6):62-64.
[4]刘锦.基于B/S架构的Web应用软件系统测试研究[J].科技广场,2013(9):39-42.
[5]廖非凡.B/S架构的Web应用系统软件测试研究[J].科技风,2008(11):76-82.
[6]宋俊雅,王鹏彪,黄俊爽,等.B/S结构软件的系统测试技术[J].科技信息,2010(10):247-248.