软件系统架构

软件系统架构（共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.1 模式描述

不管你选择哪种实现,有几个常见的核心概念都需要进行了解。第一个概念是独立部署单元。如图4-1所示，微服务架构的每个组件都作为一个独立单元进行部署，让每个单元可以通过有效、简化的传输管道进行通信，同时它还有很强的扩展性，应用和组件之间高度解耦，使得部署更为简单。

也许要理解这种模式，最重要的概念就是服务组件。不要考虑微服务架构内部的服务，最好是考虑服务组件，从粒度上讲它可以小到单一的模块，或者大至一个应用程序。服务组件包含一个或多个模块（如Java类），这些模块可以提供一个单一功能，例如为特定的城市或城镇提供天气情况，或也可以作为一个大型商业应用的一个独立部分，例如火车票的余票查询系统。在微服务架构中，正确设计服务组件的粒度也是一个很大的挑战。在接下来的服务组件部分对这一挑战进行了详细的讨论。

微服务架构模式的另一个关键概念是它可能是一个分布式的架构，这意味着架构内部的所有组件之间是完全解耦的，并通过某种远程访问协议（例如， JMS, AMQP, REST, SOAP, RMI等）进行访问。这种架构的分布式特性是它实现一些优越的可扩展性和部署特性的关键所在。

微服务架构另一个令人兴奋的特性是它是由其他常见架构模式存在的问题演化来的，而不是作为一个解决方案被创造出来等待问题出现。微服务架构的演化有两个主要来源：使用分层架构模式的单体应用和使用面向服务架构的分布式应用。

提示 : 单体应用, 即一个应用就是一个整体。

从单体应用到微服务的发展过程主要是由持续交付开发促成的。单体应用通常是由紧耦合的组件组成，这些组件同时又是另一个单一可部署单元的一部分，这使得它繁琐，难以改变、测试和部署应用。这些因素通常会导致应用变得脆弱，以至于每次有一点新功能部署后，如果由于这些新功能引发了异常，那么整个应用就不能运行。微服务架构模式通过将应用分隔成多个可部署的单元（服务组件）的方法来解决这一问题，这些服务组件可以独立于其他服务组件进行单独开发、测试和部署。

另一个导致微服务架构模式产生的演化过程是由面向服务架构模式（SOA）应用程序存在的问题引起的。虽然SOA模式非常强大，提供了无与伦比的抽象级别、异构连接、服务调度，并保证通过IT能力调整业务目标，但它仍然是复杂的、昂贵的,它很难理解和实现，对大多数应用程序来说它过于重量级。微服务架构通过简化服务概念，消除调度需求、简化服务组件连接和访问来解决复杂度问题。

1.2 模式拓扑

虽然有很多方法来实现微服务架构模式,但三个主要的拓扑结构脱颖而出，最常见和流行的有:基于REST API的拓扑结构,基于REST的应用拓扑结构和集中式消息拓扑结构。

基于REST的API拓扑

基于REST的API拓扑适用于网站，通过某些API对外提供小型的、自包含的服务。这种拓扑结构,如图4 - 2所示,由粒度非常细的服务组件（因此得名微服务）组成，这些服务组件包含一个或两个模块并独立于其他服务来执行特定业务功能。在这种拓结构扑中,这些细粒度的服务组件通常被REST-based的接口访问，而这个接口是通过一个单独部署的web API层实现的。这种拓扑的例子包含一些常见的专用的、基于云的RESTful web service，大型网站像Yahoo, Google, and Amazon都在使用。

图 4-2

基于REST的应用拓扑结构

基于REST的应用拓扑结构与基于REST API有所不同，它通过传统的基于web的应用或者客户端应用来接收客户端请求，而不是通过一个简单的API层。如图4-3所示，应用的UI层是一个web应用，可以通过简单的基于REST的接口访问单独部署的服务组件。该拓扑结构中的服务组件与基于REST API拓扑结构中的不同，这些服务组件往往会更大、粒度更粗、代表整个业务应用程序的一小部分，而不是细粒度的、单一操作的服务。这种拓扑结构常见于中小型企业等复程度相对较低的应用程序。

图 4-3

集中式消息拓扑

微服务架构模式中另一个常见的方法是集中式消息拓扑，如图4-4所示。该拓扑与前面提到的基于REST的应用拓扑类似，不同的是基于REST的应用拓扑结构使用REST进行远程访问，而该拓扑结构则使用一个轻量级的集中式消息中间件（如，ActiveMQ, HornetQ等等）。不要将该拓扑与面向服务的架构模式混淆或将其当做SOA简化版，这点是极其重要的。该拓扑中的轻量级消息中间件（Lightweight Message Broker）不执行任何调度,转换,或复杂的路由;相反,它只是一个轻量级访问远程服务组件的传输工具。

集中式消息拓扑结构通常应用在较大的业务应用程序中，或对于某些对传输层到用户接口层或者到服务组件层有较复杂的控制逻辑的应用程序中。该拓扑较之先前讨论的简单基于REST的拓扑结构，其好处是有先进的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。与集中式代理相关的单点故障和架构瓶颈问题已通过代理集群和代理联盟（将一个代理实例为分多个代理实例，把基于系统功能区域的吞吐量负载划分开处理）解决。

图 4-4

1.3 避免依赖和调度

微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合）。然而,服务组件粒度过细将导致额外的服务调度,这可能会导致将微服务架构模式变成一个复杂、容易混淆、代价昂贵并易于出错的、重量级的面向服务架构。

如果你发现需要从应用内部的用户接口或API层调度服务组件，那么很有可能你服务组件的粒度太细了。同样的，如果你发现你需要在服务组件之间执行服务间通信来处理单个请求,要么是你服务组件的粒度太细了，要么是没有从业务功能角度正确划分服务组件。

服务间通信，可能导致组件之间产生耦合，但可以通过共享数据库进行处理。例如，若一个服务组件处理网络订单而需要用户信息时，它可以去数据库检索必要的数据，而不是调用客户服务组件的功能。

共享数据库可以处理信息需求，但是共享功能呢？如果一个服务组件需要的功能包含在另一个服务组件内，或是一个公共的功能,那么有时你可以将服务组件的共享功能复制一份，因此违反了DRY规则。为了保持服务组件独立和部署分离，微服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余，这在大多数业务应用程序中是一个相当常见的问题。小工具类可能属于这一类重复的代码。

提示 : DRY，即don’t repeat yourself.

如果你发现就算不考虑服务组件粒度的级别，你仍不能避免服务组件调度,这是一个好迹象,可能此架构模式不适用于你的应用。由于这种模式的分布式特性，很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务,这对此相对简单而优雅的架构模式来说，显著增加了复杂性。

1.4 注意事项

微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的、单独部署单元,使用微服务架构模式构建的应用程序通常更健壮,并提供更好的可扩展性,支持持续交付也更容易。

该模式的另一个优点是,它提供了实时生产部署能力，从而大大减少了传统的月度或周末“大爆炸”生产部署的需求。因为变化通常被隔离成特定的服务组件，只有变化的服务组件才需要部署。如果你的服务组件只有一个实例，你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署,一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间，将服务组件的多个实例进行交换，允许应用程序在部署期间保持持续可用性（分层架构模式很难做到这点）。

最后一个要重视的考虑是，由于微服务架构模式可能是分布式的架构，他与事件驱动架构模式具有一些共同的复杂的问题，包括约定的创建、维护，和管理、远程系统的可用性、远程访问身份验证和授权等。

1.5 模式分析

下面这个表中包含了微服务架构模式的特点分析和评级，每个特性的评级是基于其自身特点，基于典型模式实现的能力特性,以及该模式是以什么闻名的。

特性评级分析整体灵活性高整体的灵活性是能够快速响应不断变化的环境。由于服务是独立部署单元,因此变化通常被隔离成单独的服务组件,使得部署变得快捷、简单，

核心银行系统架构设计与选型 篇3

【摘要】通过分析国内外核心银行系统的现状、考虑未来银行业务发展趋势的客观要求，提出一些核心银行系统架构的设计原则及进行核心银行系统选型的影响因素。

【关键词】核心银行系统、架构设计、soA、大前置

【中图分类号】TP393.1 【文献标识码】A 【文章编号】1672-5158（2013）04-0112-01

随着外资银行在中国不断开展业务，中国的银行业面对日趋一体化的世界经济竞争越来越激烈。核心银行业务系统的架构设计是否合理，对于加强银行业务操作的管理和控制、保留优质客户、银行规避风险和降低风险等方面起到不可估量的作用。

一、核心银行系统发展现状

（一）核心银行系统的定义

核心银行系统是银行业务系统的交易处理的中心，大家所熟知的存款、贷款等业务的操作都是要在核心银行系统中完成的。核心银行系统的范畴包括：客户管理、储蓄、贷款、代理产品、支付结算产品、会计账务处理、总账、批量处理等。

（二）国内核心银行系统的发展历程

核心银行系统的发展经历了三个阶段：第一阶段是指自动的会计系统，核心系统是信息化的会计系统。第二阶段是指自动的交易系统，系统是自动生成的数据系统。第三代系统是指“一本帐”和“一个中心”，以客户为中心，集成了交易处理、产品创新、客户信息管理等多种应用集群。针对目前核心业务系统越来越复杂，有的架构设计师提出了“瘦核心”概念。

二、核心银行系统架构设计

（一）架构设计分析

核心银行系统的架构设计目前有：面向"SOA"的架构设计、基于J2EE架构的B/S结构设计、以“业务、语义、服务”三层架构设计、基于大前置架构设计。下面就四种架构进行简单描述：

面向“SOA”的架构设计：这是一种以“业务驱动服务，服务驱动技术，服务为中心”为原则的架构设计。面向服务的架构体系是目前最流行的架构体系，它为企业的IT架构提供了充分的灵活性和标准性，以适应市场的快速变化并降低成本，银行内部的不同的应用系统通过SOA实现协同工作。

基于J2EE架构的B/S结构设计：C/S结构分为客户端和服务器端两层架构设计，尽管能有效降低网络通信和服务器的处理量，但升级系统客户端程序比较复杂，且也容易受连接数及网络情况的限制。这样基于J2EE架构的B/S结构（注：“浏览器”和“服务器”两层）就很有吸引力，它简化了客户端程序，能有效进行权限管理并保护数据平台。

以“业务、语义、服务”三层架构设计：负责处理用户的业务请求的是业务层，它是核心系统的应用平台，包括客户信息管理、多维度的管理信息等，并产生相应的服务需求描述。核心银行系统对外提供服务都是服务层定义和发布的。语义层的功能是实现业务和系统的语义信息进行交换，提供需求与实体会话的语言界面。

大前置的架构：采用“高内聚低藕合”的设计原则并在企业应用集成理论的指导下建立一个综合前置系统，实现银行各应用系统的有效集成，这种架构设计的优点是方便应用系统模块的修改和新增，这也符合“瘦核心设计思想”。通过提供统一的接口标准，实现与银联系统、支付结算、信贷管理系统的实时交互。

（二）架构设计原则

分析国外先进核心银行系统发展历程和现状，对比现代国内外各银行的核心银行系统建设，归纳一些设计原则：

第一，参数化设计。将一些成熟的业务产品进行抽象，提取相同的产品基本要素作为参数，通过组合参数并进行配置快速开发新的业务产品。该设计思想，减少了产品变更的范围，增加了产品组合灵活性，是目前较先进的设计思想之一。

第二，会计独立。核心本质就是实现“全行一本帐和大会计”的思想，系统由独立的子系统完成会计处理功能，采用最新的会计科目，并为会计准则的变更预留接口。

第三，以客户为中心，面向服务的设计思想。通过建立专门的客户信息管理系统对不同客户提供差异化的服务，比如利率、费率等，从而能实现利率市场化。

第四，全行统一柜员的管理。通过采用柜员卡系统实现全行柜员号统一，可以在不同的系统或角色中使用，也可以跨地区使用，并且有丰富的授权管理来加强内控管理。

第五，安全设计要完备。如何合理、可靠、高效的实现数据传输和存储的安全性，是系统需要建立的安全保护体系中必须考虑的问题。目标是：存储传递敏感数据、防止网络交易数据的截取重发、数据库中的数据防篡改。

第六，前端系统功能弱化。尽量使营业网点的前端系统简单化，减少维护和升级的复杂度，通过控制中心的监控系统进行全面监控。

第七，模块化设计。在核心银行系统的开发设计过程中尽量采用成熟的模块，以前中后三个平台为基础，降低不同模块之间的耦合度，并把大量功能重复、处理逻辑复杂的部分集成到平台中进行处理。

第八，国际化战略。目前金融领域的竞争日趋激烈，核心银行系统的设计要考虑国际化战略带来的影响，方便在国外开设银行分支机构，支持多语言、多币种。

第九，整体解决方案灵活设计。核心银行系统的架构要考虑技术架构的可扩展性，业务流程的灵活性，不能设计成一个大而全的产品，而应是建立灵活应用架构之上的—个整体解决方案，方便多个应用产品的集成。

三、核心银行系统的选择标准

随着技术的发展和竞争的加剧，特别是在中国加入WTO后，国内很多银行面临核心系统的更新换代，对于如何选择国外的核心银行系统解决方案，可以从以下四个方面加以考虑：

（一）企业的战略规划

由于核心银行系统的决策会涉及到整个企业十年甚至更长时间的业务战略方针的制定，因此其间需要考虑的不仅应包括公司的员工和系统，还要考虑到所有的客户。核心银行系统的决策通常是以最新的业务战略和策略为起点，不仅能推动所有的业务发展，而且还应能适应技术的不断更新发展。该计划要确定在银行未来中，哪些是需要变革的关键领域，并且从市场驱动的角度来确定具体的机会。同时，那些过去由于技术和管理上的限制而被视为“受禁”的领域也应该重新评定，找到每一个关键的业务机会并将其分解为诸多要素，以便进一步确定计划中制定的目标。

（二）方案的业务功能

在确定了战略规划和业务需求后，银行就可以对照业务需求了解市场上的核心银行系统方案。这是一个业务功能适配的过程，企业可以快速地根据各个方案对业务的符合程度产生优先顺序，将那些不能严格符合业务需求的产品要在这个阶段的决策中排除。

一个好的核心银行系统方案需要提供足够的灵活性以适应现有的和未来的业务需求，正是这些业务需求决定了企业的选择，因此可以说方案的业务功能是决策的首要关键。

（三）方案的技术和架构

业务的功能性需求得到满足后，需要进一步从技术水平、架构设计两方面评估核心银行系统产品。核心银行系统的技术平台包括硬件和软件两方面都必须考虑可靠性、健壮性、稳定性，并适应新技术、新业务的发展具备很好的兼容性和可扩充性。系统的业务需求功能由技术手段来实施，构成整个核心银行系统的重要的组成部分。

核心银行系统的组成可能来自不同供应商提供的不同组件，也可能所有的组件由一个供应商集成和协调在一个特定的技术平台上，但无论是哪种方式都要认真考虑系统的集成性、兼容性、可维护性、安全性、性能和成本的问题。

（四）厂商的选择

银行在选择业务符合程度较高的产品之前需要对产品的供应商进行审核与评估，遵循“质量，成本，交付与服务并重”的原则。首先，确认厂商具有一套稳定有效的质量保证体系及具备提供银行所需产品的能力；其次，对产品进行价值与成本分析，通过招标或价格谈判实现成本节约；最后，确认厂商有足够的人力物力在确定的时间内向银行提供产品。

四、总结

“双向评价评价系统”的软件架构 篇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

1、面向公司战略目标诉求进行架构设计、规划及管控，支撑变革蓝图与变革路标设计;

2、主导公司级项目的业务架构及业务解决方案设计，负责业务需求的转化及2B流程有效拉通;

3、支撑变革、流程、信息化项目中架构的评审，实现架构原则和标准的落地及日常执行;

4、参与公司IoT架构设计与项目实施工作;

5、变革与流程信息化治理体系建设与优化，引导变革解决方案建设实施，提供公司架构治理的方向和策略建议。

任职资格:

1、本科及以上学历，理工科背景优先;

2、优秀的沟通和理论联系实际的能力，精通企业架构及流程管理方法论;

3、熟悉房地产行业流程管理***实践和业界流程管理最新发展趋势优先;

4、8年以上工作经验，3年以上大中型企业的变革、流程、过程改进部门工作经验或咨询公司流程管理咨询经验，5年以上房地产行业相关领域工作经验优先;

5、拥有或曾通过以下一种或多种认证(或同等认证)者优先：

- TOGAF Architect

- PMP

软件系统架构 篇6

关键词：抽样调查系统；体系结构

中图分类号：TB 文献标识码：A doi：10.19311/j.cnki.1672-3198.2016.06.086

计算机辅助抽样管调查系统体现了信息化时代中以技术手段为先，融合传统理论的发展思路。借用电话、网络等信息化发展手段，计算机辅助的抽样调查系统将能够具有更加灵活的调研方式、更加自动化的调研流程以及更加标准化的调查程序。可以说，随着抽样调查技术在国内外的学术机构和市场研究机构中的广泛应用，信息化手段更多地成为革新抽样调查技术必不可少的桥梁。因此，如何有效地引入现有的信息化手段，充分地利用电话或网络的现代通讯技术，使抽样调查能更适用于信息化时代，这成为了摆在调查研究者面前的最大问题。而软件作为保障系统顺利运行的精髓，也是保障系统能顺利运行的必要条件。因此，想熟练地运用计算机辅助的抽样系统进行调研，就有必要对该系统软件进行充分的解构与分析。与计算机辅助的抽样系统硬件构成类似，系统的软件架构也可以有两个层面。

1系统软件的外围层面

计算机辅助抽样调查的外围指软件的架构，它指由不同的软件开发商推出的抽样调查软件。在外围层面上的软件，无论由哪家软件厂商生产，一般都包括抽样调查管理台、抽样调查监控端、抽样调查访问端以及问卷设计器几大模块。

1.1管理台

管理台是抽样调查系统中调研管理人员对整个系统管理的平台。它集成了以下功能模块：（1）系统设置模块，对整个系统进行设置。（2）项目管理模块，对项目进行管理。（3）样本管理模块，按调查者的要求在总体中选取样本。（4）人口分布管理模块，按设定的人口分布状况选取被访问对象。（5）访员管理模块，对访问人员进行管理。（6）属性配额、问题配额设置，通过该模块可根据某一属性或者某一类为题来设定访问对象的数量。（7）禁用电话号码管理/网络IP管理模块，可禁止使用系统内的某些电话线路。（8）问卷设置模块，可设置选择访问所需问卷。（9）样本统计模块，这个模块主要是在被访问对象总体中选取样本，并对样本的数据进行统计分析。（10）访员统计模块，对团队内参与电话访问的工作人员的工作量和其访问对象的信息，进行统计分析的功能性模块。（11）答卷统计模块，对访问的结果进行相关统计分析。（12）答卷导出模块。

1.2监控端

监控端就是为了使系统运行顺畅，对整个系统内的各个部分，进行监督和控制的子系统。监控端通常包括以下模块：（1）项目监控模块，此模块是对系统所要运行的项目整体进行监控。（2）样本监控模块，对要访问的样本进行监控。（3）访员监听、监看模块，通过这个模块，系统管理者可以全程监听和监看访员对受访者的音频和视频访问。

1.3访问端

访问端是执行视频或音频访问的执行端，它主要由电脑自动或手动拨号模块、访问执行两个模块构成。系统管理者可根据需要，运用此模块的功能来选择拨通受访者的电话或者音频、视频终端进行访问，还可以设定定时预约访问，录音等功能。通常设有如下模块：（1）电脑或手动拨号模块。（2）执行访问模块。（3）设定约访模块。（4）设定拨号异常和访问异常结束模块。

1.4问卷设计器

访问问卷是一个访谈、访问的核心是灵魂。抽样调查的目的是要根据定问卷对受访者进行访问。问卷设计器通常包括以下几个主要模块：（1）设计问卷模块。（2）自动差错和对错误进行定位模块。（3）设定调试参数模块。（4）调试问卷模块。（5）问卷导入/导出模块。（6）打印问卷模块。

2系统软件的内核层面

内核层面指的是CATI系统所用的数据库，它包含了系统执行项目中的所有数据。依据不同的系统建设规模，可搭配不同的数据库。目前，常见的被系统用来搭配的数据库有三套。

2.1 Oracle数据库

Oracle在数据库领域一直处于领先地位。Oracle关系数据库系统是目前世界上流行的关系数据库管理系统，适用于各类大、中、小、微机环境，能在所有主流平台上运行，完全支持所有的工业标准。

2.2 SQL Server数据库

SQL Server是Microsoft公司推出的数据库管理系统。它是一个杰出的数据库平台，可用于大型联机事务处理、数据仓库，以及电子商务等。

2.3 MySql数据库

系统架构设计考虑 篇7

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.

关于对数字油田软件系统架构研究 篇8

各行各业数字化的产生是现代科技发展的必然趋势, 油田作为生产比较复杂的部门发展数字油田更是势在必行, 数字油田的建立综合了石油地质学、项目管理以及通讯技术等多种科学技术, 多种学科之间相互结合, 形成了良性的互动, 为实现数字油田软件系统提供了强有力的保障, 实现了数字油田的科学化管理和生产, 推进了我国油田事业的发展。

一、数字油田概述

我们的石油资源非常丰富, 但我国石油资源越来越短缺, 是由于不合理的开发利用, 随着科学技术的不断发展和社会的进步, 数字化的油田开发和管理是一个有效的方法缓解资源短缺的局面[1]。所以上面的管理和协作应用程序非常复杂, 主要包括通信信息技术、石油工程、地质学和管理等许多复杂的问题, 软件开发技术在数字油田的发展起着重要的作用。

对于数字油田油田大量复杂的信息管理和信息收集等方面的建设已基本完成, 但在实际应用和效果没有达到预期, 国内许多学者都提出这样一个数字化的推进思路油田的软件系统, 即:在一个三维空间, 技术数据和业务逻辑模型, 以搜集资料, 并符合业务规则和协同工作为目标, 建立这样一个软件系统平台的思想基础[2], 结合世界IT和科技进步的数字化油田系统架构的深入研究和开发。

二、数字油田软件系统构架

2.1数字油田软件系统构架的设计原则

(1) 实现油田资源的共享和协调系统之间的工作。数字油田的软件系统应该建立在硬件系统之上, 协调硬件和软件复杂的信息和数据收集系统来协调, 结构, 预计将在资源共享的环境中, 在科学和商业的各个领域相应的技术专家管理人员, 建立资源和环境良好的相互协调。

(2) 具有时效性。由于数字油田的软件系统是收集大量的复杂信息和实时的整合过程数据, 为了实现高效的生产, 并需要技术人员和管理人员来自不同学科的快速分析信息处理与共享, 结合变化的外部环境油田开采和实时控制等生产活动和管理活动。

(3) 具有设计规则一致的原则。任何行业的设计应具有统一的要求, 它可以是迟的环境, 影响从做均匀的要求, 减少不必要的损失所带来的复杂问题等因素的原则。同样, 数字油田的软件系统的开发和建设也不例外, 需要有统一的标准和规则的约束和规范。

2.2数字油田软件系统架构的四个阶段

(1) 处理物理资源阶段。 (2) 处理数据资源的阶段。 (3) 业务逻辑服务的阶段[3]。 (4) 实现应用的阶段。应用阶段是被应用到实际的可视化阶段, 数字油田的软件系统。它是前一阶段的基础上, 按照既定的规则需要一系列的应用和目的。应用阶段是基于业务逻辑的服务框架, 根据业务需求和一系列应用, 如业务逻辑组件:合作研究的工作环境, 工作区的生产管理, 探索和决策支持系统的开发。

三、结论

综上可见, 数字油田的建立综合了石油地质学、项目管理以及通讯技术等多种科学技术, 多种学科之间相互结合, 形成了良性的互动, 为实现数字油田软件系统提供了强有力的保障, 通过不断完善深入的实践和应用, 为石油工业的未来发展的共同开发以及其他行业提供了实现的应用方向。我相信, 通过有效地促进科研路数字油田的软件系统架构设计, 能够提升中国石油工业的发展, 是具有国际先进水平的网络技术的发展和应用的技术, 实现了数字油田的科学化管理和生产, 推进了我国油田事业的发展。

参考文献

[1]马涛, 许增魁, 王铁成, 李阳明.数字油田软件系统架构研究[J].信息技术与信息化, 2010 (06) .

[2]孙旭东, 陈历胜, 李玲, 杨玉军, 陈述腾.数字油田业务对象模型设计方法[J].大庆石油学院学报, 2012 (01) .

IPTV的系统架构分析 篇9

IPTV简介

Internet Protocol Television,简称IPTV,国内一般直接翻译为交互式网络电视。这是一种在互联网技术特别是宽带技术逐渐成熟的环境下,利用有线网络传输多媒体信号的电视服务,主要受众是家庭用户。IPTV业务是伴随着宽带互联网的高度发展和通信技术的不断进步,逐渐兴起的一项利用宽带互联网为基础设施和信道来传送电视内容的新兴的互联网增值业务(1)。

作为一种交叉性技术,IPTV自应用初期就没有一个官方的权威定义,商业行为的竞争中诸多的宣传页误导了大众,很容易引起概念混乱,最常见的是部分厂商将IPTV的概念等同于网络电视。按照目前的形势来看,IPTV受到以安卓智能机顶盒为代表的网络媒体服务软硬件的冲击较大,加上之前它的定位只是传统电视业务的补充和软性延伸,客户需求本来就不是很大,短时间内不可能全面动摇现有电视行业的基本格局。

IPTV的技术特点

国际电信联盟给IPTV的概念强调了其在可控制、可管理的IP网上运营模式。具体是指通过可控、可管理、安全传送并具有Qo S保证的无线或有线IP网络,提供包含视频、音频、文本、图形和数据等业务在内的多媒体业务。简单来说,通用的IPTV协议方面就是基于IP网络,在电视平台上提供对流媒体承载的交互式服务。它的突出特点是可控性和资源丰富性。由于是广电部门和通信行业的共同推进,IPTV能为用户提供电信级的稳定服务,同时多媒体资源的丰富性能够得到很好的保证(2)。毫无疑问,这是具有简便易用特性的多媒体电视交互体验。

考虑到IPTV的关键技术的支撑部门是电信运营商,所以具有稳定的电信级服务质量。IPTV的系统分层方式很多,下面这种五层结构是比较常见的:

(1)系统的核心是为用户直接提供流服务的子系统;

(2)系统的入口和用户直接可见的交互界面是电子节目单服务子系统。

(3)系统处理源资源格式的是媒体处理子系统(3)。

(4)对资源进行采集和编排管理的是媒体管理子系统。

(5)负责媒体资源管理和价格核算的是运营支撑子系统。

IPTV系统架构

与网络电视相比,最明显的一点是网络电视运行在互联网上,这在很大程度上被认为是不可控的。如果需要在单一的技术方面之外更加系统地了解IPTV的业务架构,可以根据使用设备的功能不同将这个IPTV系统的相关组件按照媒体、服务、运营和终端分为四部分。在这里是舍弃了IP承载层的,因为它不是IPTV系统架构独有的,是一切网络结构通信的基础。但如果要明确地界每一层所包含的设备,则需要根据不同的建设方案具体分析。它的业务相关性也很大,不同的架构工程师的设计可能会存在不同。

1其共性的特点为:

(1)整个IPTV系统架构的基础是媒体平台层,它的组成服务器一般主要涵盖的是一些多媒体资源、交互类游戏以及付费点播信息等业务。

(2)服务支持层的主要任务是对IPTV相关服务进行控制和双向认证。在线类业务的服务支撑层按照通信系统的结构划分,应该采用分布式结构,合理控制网络的拓扑。

(3)运营支撑层为业务运营和网络管理服务,关系着用户的数据信息和其他重要资料。与这些业务相关的网络管理中心是系统的后台服务核心架构。它的功能属于OSS的功能模块,包括客户管理、计费账务管理和媒体资产管理。

(4)终端层一般指的是机顶盒等信宿解码接收端组件。提供客户端软件和媒体解码播放,同时与服务器通信认证。它是惟一用户家庭可见的设备,在设计上应该考虑经济性、美观性、实用性等。

2同时,IPTV系统遵必须守现在的IP协议才能保证系统的可靠性和稳定性。在IPTV的网络分层的结构上,是把它特有的组件和服务加载在Internet的通信基础上。

(1)骨干层是部署相应的OSS和网管系统的数据中心;

(2)城域网层部署分布式的媒体工作站;

(3)接入层部署相应的终端设备。

结束语

IPTV的逻辑结构与传统的互联网架构之间的差异性并不是很大,只是传统的宽带技术和广电信息平台的有机结合。与互联网不同的地方主要在于逻辑架构下的功能模块依据IPTV的业务和客户需求做出了相应的扩展或者调整。国内的IPTV的发展充满了机遇,但是挑战更大,如何让这种新的传播力量和便利的技术更好的服务于大众,是我们所掩盖关注和予以解决的。熟悉IPTV的技术特点和系统架构,对更好的了解IPTV的部署方式和业务发展都有很好的指导作用。

注释

1郭剑峰,陈小波,陈潇君,陈祖爵.具有负载分享的P2P IPTV重迭网络的设计[J].电子技术应用,2014,01:107-110.

2王艳秋.三屏合一下IPTV运营架构设计[D].吉林大学,2013.

关于软件架构的理论综述 篇10

关键词：软件构架,概念,发展历程,局限性

1 概念

在计算机发展的早期,大型计算机系统主要是被设计应用于非常狭窄的军事领域。在这个时期,研制计算机的费用主要由国家财政提供,研制者很少考虑到研制代价问题。随着计算机市场化和民用化的发展,代价和成本就成为投资者考虑的最重要的问题之一。

20世纪50年代,软件成本在整个计算机系统成本中所占的比例为10%———20%。但随着软件产业的发展,软件成本日益增长。相反,计算机硬件随着技术的进步、生产规模的扩大,价格却不断下降。这样一来,软件成本在计算机系统中所占的比例越来越大。到20世纪60年代中期,软件成本在计算机系统中所占的比例已经增长到50%左右。

60年代的软件危机使得人们开始重视软件工程的研究。起初,人们把软件设计的重点放在数据结构和算法的选择上,随着软件系统规模越来越大、越来越复杂,整个系统的结构和规格说明显得越来越重要。软件危机的程度日益加剧,现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说,对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择己经变得明显重要得多。在此种背景下,人们认识到软件架构的重要性,并认为对软件架构的系统、深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径。

1.1 软件架构

软件架构,亦称软件体系结构,它是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。它是一个系统的草图,描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。

在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。直到今天,软件架构还没有一个统一的定义。本文引用IEEE Working Group on Architecture的解释:“系统在其环境中的最高层概念”。从这个定义上考虑,架构不仅仅是结构,它还应包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。

鉴于软件架构的特殊地位,在设计一个系统之前就必须对它的软件架构进行详细设计及构造,以软件架构作为后续工作的基石。一旦这个架构决定下来就不应轻易地进行更改,这是关系到整个系统设计的成败。因此,软件架构的设计,必须经过非常慎重的研究和考察。

1.2 软件框架

说到架构,有必要提一下软件框架。框架的定义是:它是一组相互协作的类,对于特定的一类软件,框架构成了一种可重用的设计。软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构,不同领域的软件项目有着不同的框架类型。框架的作用在于:因为提取了特定领域软件的共性部分,因此在此领域内新项目的开发过程中代码不需要从头编写,只需要在框架的基础上进行一些开发和调整便可满足要求。对于开发过程而言,这样做会提高软件的质量,降低成本,缩短开发时间,使开发越做越轻松,效益越做越好,形成一种良性循环。

框架不是现成可用的应用系统。它只是一个半成品,需要后来的开发人员进行二次开发,实现具体功能的应用系统。框架不是“平台”,平台概念比较模糊,它可以是一种操作系统,一种应用服务器,一种数据库软件,一种通信中间件等。因此,平台在应用中主要指提供特定服务的系统软件,而框架更侧重了设计,开发过程,或者可以说,框架通过调用平台提供的服务而起的作用。

框架不是构架。架构确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。框架比架构更具体,更偏重于技术细节。确定框架后,架构也随之确定,而对于同一架构(比如Web开发中的MVC),可以通过多种框架来实现。

2 发展历程

早在19世纪60年代,诸如E·W·戴克斯特拉就已经涉及“软件架构”这个概念了。自90年代以来,由于在Rational Software Corporation和Microsoft公司内部的相关活动,“软件架构”这个概念开始越来越流行起来。

卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garland于1996年写了一本叫做“Software Architecture Perspective on an Emerging Discipline”的书,提出了软件架构中的很多概念,例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。从学者们所关注的角度不同,逐渐出现了逻辑架构、物理架构、系统架构等软件架构的分类。多层的软件架构逐渐成为主流,一个典型的软件系统都分为表现层、业务层、数据层等多个层次,来满足不断发展的软件系统的业务需求。随着现代企业对IT基础设施的依赖增大,整个企业的业务可能都会基于Internet或Intranet进行运作,因此,出现了MIS、ERP、SCM等应用系统。在这些复杂的应用系统中,软件架构至关重要,它必须保证软件系统的后期扩展性,来延长系统的生命周期,并与其它系统通过EAI或其它方式进行集成。同时还出现了“企业软件总线(Enterprise software Bus,ESB)”的架构,它试图通过确立软件模块间的、独立于技术、统一的企业级通信标准,从根本上解决应用程序的集成问题。与此同时,一些软件架构开始尝试使用CORBA等中间件解决系统异质问题,这些都为后来软件架构的研究提供了很好的路线图。

3 现状及其局限性

经过几十年的发展,软件架构的研究取得了一定的成果。然而,在研究中仍然面临着很多不易解决的问题,在面对统一的软件架构这个问题时一时还缺少标准的答案。在过去的软件系统中,由于设计不合理,接口不规范等问题,造成系统与系统间甚至是子系统与子系统间的相互通信困难,资源共享不顺畅,整合困难,容易出现所谓的“信息孤岛”和“应用孤岛”。软件架构的设计中通常都缺乏灵活性,产生了“Monolithic”设计,在设计与灵活的应用需求脱节。但在上世纪九十年代后期,这个问题逐渐被学者们所重视,一个好的软件架构应能提供灵活的扩展机制、丰富的接口、共享应该共享的信息等,这是一个良好设计的软件架构的规范,但由于技术间差异性的普遍存在,大多数系统间即便有良好定义的接口也难以得到其他系统的使用。CORBA、DCOM、EJB等中间件的出现为统一接口层的出现提供了可能。但抛开某些中间件的灵活性易用性不谈,这些异构的中间件之间的统一访问又产生了新的问题,即中间件的异构性问题。又由于新旧系统混杂,异构系统、不同的平台、开发技术、开发商、多个版本并存等问题,使得软件系统很难被重用,不可避免地需要被重写。此时,统一的软件架构得到前所未有的关注。

SOA是一种较新的软件架构,它最早在1996年被提出,但是由于当时软件实现相关技术的不足,一直未能获得发展。后来由于在分布式技术、程序设计方法学、业务计算能力等方面的长足发展,使得SOA作为“现代应用开发领域最重要的课题”被提了出来,许多研究机构、大学、软件企业都将其作为研究重点。IBM、BEA、微软等公司和机构都提出了实现SOA的新技术。尤其是一些机构联合提出以Web Service Architecture作为实现SOA的标准,这使得SOA在标准化之路上迈出了一大步,但还有很长的路要走。SOA仍远没有达到成熟的地步,甚至还没有一个获得公认的定义,研究工作大都处于理论研究阶段。

在国内,SOA还是一个新鲜的事物,虽然近两年来关于SOA的报道经常见诸各种媒体,但是炒作概念的成分居多,并没有多少实用成果。研究中,面向服务、面向组件、面向对象的理论研究成果也并不多,关于SOA的著作更是少见。在实践领域,虽然有一些国内企业提出了SOA的概念性产品,但仍很少看到其SOA系统的成熟应用的案例。由此可见,国内对SOA的研究还处于初级阶段。

然而,由于企业用户业务需求的不断变化,要求企业IT系统必须成为一个适应力强的竞争体,能随着企业环境的变化而改变,并具备柔性扩展、随时支持业务流程变化的基础功能。因此目前的很多行业,例如政府、电信、金融、医疗等等,都需要实施SOA。

SOA作为一种方兴未艾的技术,虽然很不成熟,而且具有一定的不确定性,然而这并没有阻碍SOA技术的不断发展,已有大量的国际软件公司和标准化组织对其投入了大量的资源进行研究。作为一种新型的软件开发架构,SOA具有非常大的优势,它放弃了极易带来技术差异性的“以技术为中心”的细粒度实体,而转向“以业务为中心”的服务,这符合按需计算的发展潮流,尤其适用于大规模的企业级应用开发。随着互联网络的进一步发展,分布式应用的不断普及,SOA的应用会更加的普遍并被人们所接受,成为一种最重要的软件架构。可以预见,SOA的发展会对软件设计思想产生非常大的影响并对分布式企业应用的不断普及起到巨大的推动作用。

参考文献

[1]李莉.基于自适应构件的软件架构研究[J].惠州学院学报(自然科学版),2008;3

[2]龚爱斐.基于虚拟化架构的软件开发与测试环境自动化[J].自动化与信息工程,2008;2

[3]曾仁京.集群负载的分布式软件构架分析与设计[J].福建电脑,2008;7

RNP系统仿真验证平台架构研究 篇11

关键词：飞行管理系统 综合导航系统 RNP 仿真平台

中图分类号：V249.3 文献标识码：A 文章编号：1674-098X（2015）08（b）-0082-02

随着航空器机载设备能力的提高以及卫星导航等先进技术的不断发展，国际民航组织（ICAO）提出了基于性能的导航（Performance Based Navigation， PBN）概念。PBN包含导航设施、导航规范和导航应用等方面。其中导航规范规定了导航系统的功能、性能和传感器等方面的要求，是PBN实施的关键。其包含所需导航性能（RNP）规范和区域导航（RNAV）规范。RNP定义了飞机在一个确定的航路、空域或区域运行时所需的导航性能，对导航的精度、完好性、连续性和可用性提出了要求。RNP是未来航行系统（Future Air Navigation System， FANS）和下一代航空运输系统（Next Generation Air Transportation System， NexGen）的重要技术。RNP的引入体现了航行方式从基于传感器导航到基于性能导航的转变。RNP标准对包括飞行管理系统（FMS）、自动飞行系统、导航传感器等航空电子系统的结构与性能提出了新的要求。设计符合RNP规范与标准的飞机系统架构，并开发对应的仿真平台，用于RNP系统进行验证和评估，将为现代客机的研发提供重要的辅助作用和技术支持。

1 RNP系统仿真验证平台设计目标

RNP系统仿真验证平台主要实现飞机RNP相关的核心子系统的功能仿真，包括飞行管理系统[1]、高性能综合导航系统[2]、显示系统[3]和飞控系统[4]等。再加上飞机模型和环境模型，构成一个闭环系统，来进行RNP系统的性能分析、评估和验证。RNP系统仿真验证平台通过飞行管理系统执行飞行计划、轨迹预测、性能计算以及飞行导引的核心功能，并与飞控系统和高性能综合导航系统模块进行数据通信和指令传输，实现系统的实时闭环仿真。同时，高性能综合导航系统融合各导航设备的数据，对RNP系统整体的性能评估、分析和验证，实现RNP性能监测和告警。RNP性能仿真验证平台应具备以下主要功能：

（1）仿真RNP核心子系统的功能。

（2）仿真飞机模型及运行环境模型。

（3）提供可视化、交互式的仿真环境。

（4）实现RNP系统整体性能的综合评估、分析及验证。

（5）实现RNP核心子系统模块的功能性和原理性仿真与系统集成，辅助系统的设计及验证。

2 RNP系统仿真验证平台的架构

2.1 RNP系统集成平台架构

RNP系统集成平台的逻辑架构如图1所示。

飞机仿真模块可以包括飞机模型、飞控系统、电源系统、液压系统、发动机系统和自动油门系统。

真实航电设备和数据采集设备可以为部分或全部的机载真实航电系统。

飞控系统仿真模块包括自动飞行和飞行指引系统。

2.2 RNP系统仿真验证平台架构

2.2.1 RNP系统仿真验证平台系统模型

为实现平台设计目标，RNP系统仿真验证平台需要由多个系统模型组成，见图2。

（1）高性能综合导航系统模型：是多传感器的导航系统，主要实现：多种导航传感器信息融合、导航模式管理、无线电导航台的自动调谐和RNP性能评估与监测告警等功能。

（2）飞行管理系统（FMS）模型：主要实现飞行计划、轨迹预测、性能计算以及飞行导引的等核心功能。

（3）显示模型：主要实现电子飞行仪表系统仿真（包括主飞行显示、导航显示、告警显示等），人机交互界面仿真等功能。

（4）ISA模型：是国际标准大气（ISA）的模型。主要仿真随飞行高度变化的地球大气的压力、温度、密度和粘稠度等数据。需符合ICAO Doc 7488规范。

（5）大气扰动模型：主要仿真在各飞行阶段的风和气流扰动的影响，和在起飞和着落阶段的下击暴流的影响。

（6）飞机模型：是一个6自由度的飞机模型，主要仿真飞机的运动状态。其输出所有的飞机动态参数。

（7）发动机模型：主要仿真发动机性能和推力等参数。

（8）主飞行导引系统（AFGS）模型：其包括自动驾驶和自动油门功能的仿真。主要产生横滚和俯仰姿態指令、航向指令和推力或速度指令等。

（9）飞行控制系统（FCS）模型：其用于控制飞机，主要实现将控制指令转换成实际的飞机控制信号。

（10）气象预测模型：用于仿真各种气象环境。

2.2.2 RNP系统仿真验证平台架构

RNP系统仿真验证平台架构如图3所示。该架构描述了各系统模型间的逻辑关系和接口关系。

这里将对平台的软件设计做一些规范性的研究，不对硬件环境的要求进行阐述。

2.3 RNP仿真验证平台软件系统架构

2.3.1 模块化软件设计

所有的仿真软件需依据模块化开发。模块化的程度根据RNP系统各分解模块来决定，使改变任一模块对其他模块的影响降到最低。模块化软件的设计是至上而下的软件设计方法，其强调把RNP系统仿真软件系统分解到独立的、可互换的功能模块，使每个模块来执行唯一的期望功能。模块化软件应该满足下面一些要求：

（1）每个模块的结构应该简单易理解。

（2）每个模块的执行易于改变，不会影响其他模块的运行。

（3）每个模块易于修改，不会对模块间的接口产生变动，或尽可能的减少对接口的影响。

2.3.2 RNP仿真验证平台软件架构

RNP仿真验证平台软件系统架构由多个顶层软件模块组成，见图4。每个顶层软件模块可以分解成多个底层软件模块。

3 结语

该文介绍了RNP系统仿真验证平台架构设计。随着新航行系统的发展，RNP系统越来越显示其重要性。RNP系统仿真验证平台的建设，有助于开展对RNP系统的设计、性能评估及验证工作。同时对RNP系统的性能和功能需求提供了有效的仿真验证手段。

参考文献

[1]宗军耀.大型客机飞行管理系统功能研究[J].科技创新导报，2011（32）：210-211.

[2]宗军耀，郑智明，张琛.基于RNP运行的机载综合导航系统的架构和功能分析研究[J].中国高新技术企业，2014，（25）：7-8.

[3]Ian Moir，Allan G Seabridge. Civil Avionics Systems[M]. rofessional Engineering Publishing UK，2003.

基于软件架构的回归测试 篇12

首先由于软件总在时刻变化着, 软件的不断演化, 例如软件的开发、维护、升级都需要修改一些软件的结构和代码, 而人类对软件的要求也从未停止过。软件的每次改变都会引入潜在的风险, 这是软件演化的缺陷。其次, 人类对软件变化有了一些新的要求, 关心软件修改后的功能是否达到预期以及原有的功能是否被损害[1,2,3]。

针对以上要求, 选择使用回归测试来解决。回归测试是一种验证已变更系统的完整性与正确性的测试技术。

2 回归测试的定义及意义

回归测试是对之前已测试过、经过修改的程序进行重新测试, 以保证该修改没有引入新的错误或者由于更改而发现之前没有发现的错误。

回归测试的意义是: (1) 保证软件维护时未更改的代码功能不会受到影响。 (2) 保证软件模块区域和持续维护过程与回归测试的协作关系, 使得回归测试成为一个每月、每周、每日的常规活动。 (3) 实现软件整个生命周期的测试。

3 回归测试

首先简单介绍传统的基于代码的回归测试选择方法的作用, 以便了解软件架构回归测试选择方法的基础。关注于选择性的回归测试方法, 然后再重新采用相同的逻辑步骤来提出一种基于软件架构的回归测试方法 (在第四部分提出) 。

回归测试的目的在于验证修改的软件并确定不会在先前测试的代码中出现新的错误。传统的方法是把它分解为两个阶段。 (1) 测试软件P相对于一种指定的测试集T。 (2) 当推行了一种新版本P′时, 对已修改的版本P′的回归测试提出P′相对于测试组T′是正确的可靠性。

在最简单的回归测试方法中, 有一种叫做复制所有的测试。T′中包含T中的所有在T中的测试用例, 并且P′运行在T′上。在回归测试选择方法上, T′被选出作为一种跟T相关的子集, 假设有t∈T, t包含于T′, 如果它有可能在P′中生成的结果与在P中不同。对不同回归测试选择方法的实证研究和分析在文献[4]中提出, 加上对不同行为的识别需求。

本文着重研究如何为P′选择一种相关的测试用例子集, 又叫做回归测试选择问题, 描述一种回归测试选择方法, 它是在软件架构层面上而不是在代码层面上。换句话说, 用选择架构化的层面测试用例代替选择代码层面的测试用例。

4 基于软件架构的回归测试

基于软件架构的回归测试包含以下两个阶段: (1) 基于软件架构的测试。特别地, 应用一种基于软件架构的一致性测试方法。 (2) 基于软件架构的回归测试选择。这个阶段被分解以满足目的1和目的2。

图1总结了基于软件架构一致性和回归测试所需要的行为。本文主要研究基于软件架构的回归测试。

4.1 基于软件架构的一致性测试

这项工作是基于软件架构一致性测试的一般框架的, 目的是测试已给出的软件架构实施的一致性。

这个框架分为5个步骤, 如图1中间的部分所示。

第0步:它开始于软件架构规范的拓扑学和行为学, 这里的行为通过一种基于机器的形式体系状态来模仿。下面, 利用标签的过渡 (LTS) 来模仿组件的行为。

第1步:提出了一个通过观测得到的方法为了实现一种测试标准, 这种标准来源于与测试目的相关视角在软件架构中, 而是把无关的行为从这个视角中隐藏起来。标签的过渡 (LTS) 模型被提取出来, 就产生了一种抽象标签的过渡 (ALTS) , 用来说明只有这样高层的行为/组件是需要测试的。

第2步:一种基于架构层面的测试用例 (ATC) 以架构事件的有序序列被定义了, 这种事件是当一个确定的初始事件执行的时候期望发生的架构事件。此定义分解为两个关键词:行为序列, 它代表了所期望的行为和初始事件, 它是允许发生的结构化输入。获得一个ATCs充分集合需要得到一个合适的包含了ALTS完整路径的集合[5]。

第3步:自然地, 这样的ATCs与可执行的代码层面测试用例截然不同, 因为在软件架构和代码之间的差距。处理这个问题通过一种“绘图”方法, 它能够将软件层面函数的测试转化为代码层面测试用例。

第4步:最后, 代码运行在可识别的测试用例上。通过分析执行的踪迹来决定系统在所选择的结构测试中实施得是否正确, 采用结构化的模型作为一种测试数据库来识别代码用例成功或失败。

这样的方法已经得到公认, 但是重复的测试行为对于系统的发展而言无疑花销太大了, 因此需要以更少花销开发一种基于软件架构的测试方法。本文提出一种方法来处理系统的发展, 重复使用原始的测试结果来重新测试已修改的结构并以更少的花销来完成。

4.2 目的1:测试对于初始软件架构P′的一致性

让假设基于软件架构一致性的测试已经提出P符合已给出的软件架构的一致性。当P进化到P′之后, 如何来测试P′对于相同架构的一致性。采用的方法是将基于软件架构测试方法和现存的基于代码的回归测试方法相融合的。通过一种行为图表, 代码层面的回归测试能够与基于软件层面的一致性测试相融合来选择一个新的测试套组T′:

A:产生图表P, 大多数普通的用于代码回归测试的方法是为了通过图表来结构化地表达P。在修改之后, P′也被描述成一张图表。在软件架构中, 图表也通过组合成分行为的LTS模型来获得, 同时在结构中结构化那些成分组织。

B:把GP和GP′相比较, 在基于回归测试的传统代码中, 通过比较P和P′的代码图表, 识别代码的改变怎样影响到图表中。在软件架构中, 这种改变根据在LTS中节点和边来识别。

C:记录覆盖范围, 通过测试用例的执行测试历史记录被构建出来。通过测试用例在P上执行代码的过程, 记录一连串的节点/电弧。

D:测试用例选择P′。从测试历史和图表比较中积累的信息被应用于识别将要在P′中再次运行的T中的测试用例。如果在t∈T中P的执行包含了在P′中修改的节点, 那么t需要在P′中重新运行。

一旦T′被选择了, t′∈T′就在P′中运行并把结果收集起来, 然后和一种数据库相比较来确定测试是失败还是成功。与基于传统代码方法的一种主要的区别是, 在基于软件架构回归测试的数据库是软件结构自己本身。事实上, 当t′在P′中运行的时候, 如果它的执行不允许所期望的情况再次出现, 那么测试会失败。更多情况, 代码层面的测试用例总是被形式化的函数和结构化的需求驱动得很好。

期望从这个方法中得到的好处有两层: (1) 作为传统的回归测试, 为P′减少了测试套组的规模, 剪掉了所有在P′中不需要被再次应用的那些测试。 (2) 当发现了一致性错误的时候, 能够搜集关于如何来适应初始架构的信息。

4.3 目的2:测试进化得到的架构的一致性

让再次假设基于软件架构一致性测试已经声明了P的实施应符合已给出的软件架构。采用的方法是根据比较两者的架构的规范来识别软件结构改变/未改变的位置。结构和行为的改变都被考虑在内。特别的, 对于S和S″的LTSs被比较之后的区别通过两张图表 (利用一种“diff”算法) 来识别。在一次与基于回归测试传统代码相似的改革中, 无论什么时候一个ATC在S″中被修改的LTS软件架构中遍历一次的时候, 它需要在S″中重新测试。图1 (最左边) 总结了目的2如何通过不同的行为被意识到。

a:新的软件架构规则。演变的系统S″被结构化的规则提出。

b:测试标准。测试标准 (之前应用在S中) 被用在S″上。

c:比较。架构的规则与识别出的拓扑改变相比较 (也就是增加的/删除的组件或修改的配置) 和行为的改变 (也就是经过改变的部件)

d:为S″选择结构化的测试用例。那些来自于软件架构的被结构的改变影响的ATCs被选择在P″上重新测试, 为了S″的实施。注意到任何在这步丢弃的ATC都可以代表很多被消除的代码层面的测试用例, 因此很大程度上减少了重复测试的花销。

e:识别代码层面测试用例。一旦已经识别了需要用在S″中的回归测试ATCs, 为了S″需要把架构的测试用例转化到代码层面的测试用例, 以便为了P″选择T″。这一步类似于在第三步中基于软件架构的测试。

f:测试执行。在T″已经被S″选择之后, 需要在P″中运行T″然后评估执行基于软件架构回归测试的结果。这一步跟第四步中基于软件架构的测试很相似。

摘要：当对可靠的系统结构化的时候, 除了通过构建的方式来改善系统的可靠性 (如容错和多余的机制) 外, 对于系统的评估也同样重要, 并由此来认可系统的可靠性。现有很多不同的方法来评估系统的可靠性, 测试因而成为一种重要的方式。目前关于软件结构测试的工作表明, 应用一致性测试技术产生可信度是可能的, 这种可信度是在软件架构中可期望的行为, 指定了架构描述语言。这项工作中, 探讨了为了减少重复测试而修改系统的费用, 回归测试可以怎样被系统化地应用在软件架构层面上, 评估了进化的系统的回归测试性。考虑了评估“自顶向下”和“自底向上”等进化方法, 是否通过简单修改就能够符合初始的架构, 这样的修改是否能够符合进化的架构。将回归测试应用在软件架构层面上将有助于评估和认定其是否具有更高的可信度。

关键词：软件架构 (SA) ,可靠性系统,回归测试,分析

参考文献

[1]R J Allen, R Douence, D Garlan.Specifying and Analyzing Dynamic Software Architectures[C]//Proceedings of the1998Conference on Fundamental Approaches to Software Engineering (FASE’98) , March 1998.

[2]S Beydeda, and V Gruhn.Integrating White-and Black-Box Techniques for Class-Level Regression Testing[C]//Proceedings COMPSAC2001, 2001:357-362.

[3]A Bucchiarone, H Muccini, P Pelliccione, and P Pierini.Model-Checking Plus Testing:From Software Architecture Analysis to Code Testing[C]//Proceedings International Work on Integration of Testing Methodologies (ITM’04) , October2004.

[4]UCI.The C2Style[EB/OL].http://www.ics.uci.edu/pub/arch/c2.html.